3 ms·

> e.g. If they ask you to merge sorted arrays and you don't know that Heap sort is the best way to do it, you've lost the interview no matter how clear your tho

> e.g. If they ask you to merge sorted arrays and you don't know that Heap sort is the best way to do it, you've lost the interview no matter how clear your thought process is. Not because the interviewer is not watchful. But because your competition has solved it with Heap Sort. So even if both of you demonstrated a clear thought process, the other person gets the job, because s/he is more prepared. Sadly, there's a ton of very qualified software engineers that make up this "competition" that you speak of, and still lose. Meanwhile, there's another group of people that realize how ridiculous proving yourself in that way every few years throughout the course of one's career is, become sales engineers, and make more money. They also don't have to have a whiteboard pissing contest anymore over such things. I really wonder if lawyers who have been practicing for 7 years, or consultants from the Bain's and McKinseys of the world get asked questions about classes they took in junior year of undergrad when they interview.

soham 10y ago
Your frustration is justified. However, there is no flawless interview process. You could try and read this for more context: http://www.gayle.com/blog/2015/6/10/developer-interviews-are-broken-and-you-cant-fix-it http://www.gayle.com/blog/2015/6/10/developer-interviews-are... Having been on the other side for quite a long time, I can assure you that despite best efforts by some very well meaning and smart people, this is the only process that has stuck around (and is still growing). That's because it's the most convenient method to interview at scale. When a company is very small and/or only hiring one or two engineers a quarter, choice of interviewing method doesn't really matter a whole lot. You will have enough time to interview people and any method you follow will give you a decent candidate. But when you are a coveted company with a strong candidate pipeline and are tasked with hiring 25 engineers a quarter (which was the case with the leadership team I was a part of), or thousand at Google scale, you need a process that is fast, efficient and convenient. You don't necessarily need a process that's best for candidates; as long as the process filters in enough candidates, and doesn't waste much of your team's time, you're good. There are some other reasons this process has stuck around, but that's one main reason. I don't see it going away any time soon.

soham 10y ago

Your frustration is justified. However, there is no flawless interview process. You could try and read this for more context: http://www.gayle.com/blog/2015/6/10/developer-interviews-are-broken-and-you-cant-fix-it http://www.gayle.com/blog/2015/6/10/developer-interviews-are... Having been on the other side for quite a long time, I can assure you that despite best efforts by some very well meaning and smart people, this is the only process that has stuck around (and is still growing). That's because it's the most convenient method to interview at scale. When a company is very small and/or only hiring one or two engineers a quarter, choice of interviewing method doesn't really matter a whole lot. You will have enough time to interview people and any method you follow will give you a decent candidate. But when you are a coveted company with a strong candidate pipeline and are tasked with hiring 25 engineers a quarter (which was the case with the leadership team I was a part of), or thousand at Google scale, you need a process that is fast, efficient and convenient. You don't necessarily need a process that's best for candidates; as long as the process filters in enough candidates, and doesn't waste much of your team's time, you're good. There are some other reasons this process has stuck around, but that's one main reason. I don't see it going away any time soon.