In a 1 hour technical interview, I was given 2 problems. I solved 1 problem and didn't have time to complete the second one. Did I fail?

we give our main problem first, and then add follow up questions (which are often on the form: generalization of the problem, or optimization of the solution). In this case getting these extra questions is nice but it’s really about the first question.

  Hr Classes   Apr 20, 2024   0   34  Add to Reading List

As a preamble, I would urge you to not overthink this. You pass the interview if you’re told you’ve passed. There is such a difference between how you perceive your performance and how your interviewer evaluates it that how well you think you’ve done is rarely relevant. The only things that you can control are: did you feel you came prepared? Did you feel you’ve done a good job identifying the problem? Are you happy with the code you wrote? those are things you can potentially improve on. But for the rest, what’s done is done and the dice are cast.

Now to answer your question - that’s not enough information to tell.

In a coding interview of 1 hour, you have 50 minutes of exercise. Interviewers want to make the most of these 50 minutes. How to do that?

For harder problems, candidates can go in whatever direction at first. Some of these explorations make sense but won’t get them closer to a solution. Some candidates however can get lucky and be on the right path from the get go.

While there is some skill involved in getting the right intuition, in many cases (and especially at more junior levels) this is mostly luck and it doesn’t make sense to reward candidates who were luckier, and let otherwise good candidates waste time.

So, a common strategy is to ask a “starter question” which is very simple, but sets the candidates on the right path. An added benefit is that it gives a quick signal of the coding style of the candidate. Because “starter questions” are conceptually very simple, the output is easy to use as evidence of good or poor coding practice.

In that case, solving that first question doesn’t give enough signal to determine that the candidate is good enough. One way to determine if you’re in that situation is, after you answer that question - if you didn’t know the solution, but you got the right idea, could you have solved it in a couple of minutes? if yes, you just answered a “starter question”.

Sometimes, we give our main problem first, and then add follow up questions (which are often on the form: generalization of the problem, or optimization of the solution). In this case getting these extra questions is nice but it’s really about the first question. Most candidates won’t have time for follow up questions. Likewise - if the problem you solved takes time even to implement, for instance if a good solution is not trivial and would take over 20–30 lines of code, then you probably solved a “main” problem.

Another case - and I personally have never done that but I know some interviewers like this style - is ask several short questions, each of which can be done in 10–15 minutes. In this case, the next question will not be a direct continuation of the first one.

Finally, there are problems which are so hard that most candidates don’t solve them, and still it’s possible to tell good candidates from less good ones in how they’ve approached them.