Why is there a huge difference between algorithm questions in a technical interview and the actual software development?
Why is there a huge difference between algorithm questions in a technical interview and the actual software development?
There shouldn’t be. If someone is asking you to implement a red-black tree algorithm, and you’re not specifically interviewing for a languages/compilers position, they’re probably not a great interviewer. A good interview question should take a real-world problem that the team has recently solved and scale it down to something that is tractable in about 30 minutes. Algorithms and data structures are very important to answering these questions, and it’s critical to understand things like what operations a data structure supports and the time complexity of the chosen algorithm, but they are fundamentally tools to solve the problem and not the problem itself. This is how Google, Microsoft and other tech giants interview. Some smaller companies have heard that we ask “algorithms” questions, taken this to mean that we ask for the details of algorithm implementation, and structured their own interviews accordingly, but this is a terrible way to interview candidates.
There is one exception besides language development: many interviewers open with a warm up question, which is usually a very simple algorithms question like “find the most common number in an array of integers” designed to take 5–10 minutes for most candidates. These questions serve two purposes. First, they get the candidate over their jitters and get their mind in the right space for the real questions. Second, they identify really bad candidates. A common and damning piece of interview feedback is “the warm-up question took 30 minutes instead of 10”. Occasionally you can detect a very good candidate on the warm-up question if they ask very insightful questions, such as “is the length of the array less than MAX_INT?”, although this will always be confirmed with subsequent questions. When a candidate fails a warm-up question, the interviewer will likely give them a much easier and different second question, just in case it was a fluke (it rarely is).