My on-site technical interview sessions are about 45 minutes each but the engineers’ attention span on coding sessions last about 35 minutes. So after eliminating the introduction, the explanation of the question, you should time yourself to have a complete code with correct results within 25-30 minutes. The thinking process does not count. Only code with correct output counts. They said very clear the code need to be correct. My second coding question is on a system integration coding problem. After googling the needed system calls for Ruby, I start coding with the top search result. On the first run, the system is blocked. Good practice told me to verify the connectivity and I spend 8 minutes to eliminate some important possibilities. I realize time is running fast. So I ask whether I can have more help. He said “I told you already but you are not listening”. When you put high pressure on the candidate, some subtle suggestion is not obvious and there are many other un-related messages. There are a few more remarks that I consider not professional or fair. At the end, he suggested me for a particular system call. Then the integration code works. Unfortunately, he also end the interview even though it was started 5 minutes late. After he left, I managed to finish the business code in 5 minutes and I emailed the code to the recruiter. But I knew it would not count. At first, I blame bad luck of finding the wrong Ruby API on the google search. But on the way home, I realized I should have more faith in google search than their home grown system component used for interviews. I replicate the reason why the API call is blocked in 5 minutes and duplicate their component. The first Ruby code does work with most common systems but not theirs because the way of how they want it to work. Their approach is not common for distributed and scalable system and therefore only popup later in my head. Their interview standard has reached a very un-healthy level. The second coding question have too many variables of going wrong in real life. With the time constraints, luck becomes a more dominate factor rather than a real life approach. There is a chance that the bar has raised too high that more top candidates are failing while more cheaters pass. The technical community is small. Sharing interview questions are far more common. I will not be a good candidate for them. Only the first interview contains real life industrial strength issues. For the rest of technical interviews, you should check out all those online site posting brain teasing programming question. I start wonder why we need to spend 4 years college. Experience will not pull you ahead of others. To hack those interviews, it will be easier of spending a few months intensively on those site instead.