My on-site technical interview sessions are about 45 minutes each, but the engineers' attention span during coding sessions lasts about 35 minutes. So, after eliminating the introduction and the explanation of the question, you should aim to complete the code with correct results within 25-30 minutes. The thinking process does not count; only code with a correct output counts. They stated very clearly that the code needed to be correct.

My second coding question was on system integration. After googling the necessary system calls for Ruby, I started coding with the top search result. On the first run, the system blocked. Good practice dictated that I verify the connectivity, and I spent 8 minutes eliminating some important possibilities. I realized time was running out, so I asked if I could have more help. The interviewer responded, "I told you already, but you are not listening." When high pressure is applied to a candidate, subtle suggestions can be missed, and there are many other unrelated messages. There were a few more remarks that I considered unprofessional or unfair. At the end, he suggested a particular system call, and then the integration code worked. Unfortunately, he also ended the interview even though it had started 5 minutes late. After he left, I managed to finish the business code in 5 minutes and emailed it to the recruiter, but I knew it would not count.

At first, I blamed bad luck for finding the wrong Ruby API on Google. However, on the way home, I realized I should have had more faith in Google searches than in their homegrown system component used for interviews. I replicated the reason why the API call was blocked in 5 minutes and duplicated their component. The initial Ruby code worked with most common systems but not theirs, because of how they wanted it to function. Their approach is not common for distributed and scalable systems and therefore only occurred to me later.

Their interview standard has reached a very unhealthy level. The second coding question had too many variables for things to go wrong in a real-life scenario. With the time constraints, luck becomes a more dominant factor rather than a real-life approach. There is a chance the bar has been set too high, causing more top candidates to fail while more unqualified individuals pass. The technical community is small, and sharing interview questions is far more common.

I will not be a good candidate for them. Only the first interview contained real-life, industrial-strength issues. For the rest of the technical interviews, you should check out those online sites posting brain-teasing programming questions. I start to wonder why we need to spend 4 years in college. Experience will not pull you ahead of others. To hack those interviews, it would be easier to spend a few months intensively on those sites instead.