. Restate the question for them and seek affirmation. You might actually be surprised to find you don’t fully understand what they’re asking for.
There is no situation in which restating the problem will hurt you — it shows you can articulate a problem and gives you time to think it through a bit while you discuss. Furthermore, starting the discussion this way will help quell some nerves that might otherwise manifest while trying to solve the actual challenge.
This is free and you should take advantage of it. Simply ask if there are any test cases that the function should pass. Your interviewer might be expecting you to ask this question, so it might be necessary.
In other words, in the worst case the interviewer will tell you to continue without actually offering feedback. In the best case, the interviewer might actually point out logical flaws in your pseudocode that will give you some serious benefit when transitioning to actual code.
At this point, don’t hesitate to ask if your solution looks good! If it doesn’t they might offer some tips to improve it. All of this communication scores points for you — you’ll seem articulate and easier to work with if you’re willing to objectively discuss ways to improve your work.
The answer might be “no, I’d like to see if you can solve it from here on your own,” but it also very well might be a “yes” with a useful tip!
you can ask if there is anything in particular you should prepare. They very well might give you hints like specifying the language in which they’ll ask questions, the number of questions, the style of question
## We’re All Human
Your interviewer has probably seen quite a few candidates sweating it out, but possibly very few open who openly discuss problems in a conversational manner. If you can achieve this, you’ll be in great shape.
wait until the interviewer is done explaining the problem. Ask any clarifying questions, and then tell your interviewer:
“Okay, got it. If it’s okay with you, I’m just going to take a minute or two here and think about the problem, and then I’ll start talking.”
one side of the whiteboard, where it’s visible but won’t get in the way. You don’t need to be verbose, just get the steps in order and somewhat readable.
Even if we never make it to writing code, many interviewers will consider this a solution to the problem. It proves that we understood the problem, devised the correct solution, and are well on our way towards implementing it in code.
So don’t waste time memorizing keywords in your interview prep. Focus on the big picture
If you are given criticism in an interview, you need to take it and be grateful for it. No snide remarks, no “oh, I was gonna do that in a second anyway”, no anger or raised voice.
there are plenty of things that fall into that category beyond mere coding prowess.
knowing that you’ve done all you can to prepare helps you stay calm and cool, and increases your chances of success. And afterwards, regardless of the outcome, knowing that you could not have reasonably done more to prepare helps you feel proud of your work and start moving towards your next goal.
## Review your work
if you have the time, review your code as you would in a peer review. Show the interviewer that you are committed to producing accurate, high-quality work, and that they can trust you to do so without being prompted.