In a coding interview, can you explain the approach first and then when you move to code, not explain or talk?
I tried to talk while coding in an interview. But I found writing code fast and well was difficult then.
What does an ideal interview look like, in your opinion?
I almost never write code until I have some level of agreement with the interviewer about my approach. (They may not think my approach is correct, but at least they should understand it.)
In general, you should not have more than 5 minutes of silence in an interview.
If you’re struggling with idea to code in time limit, including taking short (10-15s) breaks to say what you’ll do first, or note you’ll return to clean something up, ask if you should write out all preconditions checks, etc… I feel like getting much more familiar/comfortable with the language you work in, algorithm implementation, and so on. Also, take shortcuts. Say methodX does X, and say if there’s time you’ll come back to it. If it’s obvious but tedious that should be fine.
I am saying this because the typing part should be the least intensive. Talking it out, taking direction or getting input on what should be prioritized, etc is more relevant than the code you write. Quiet time will possibly have interviewer tune out, or be inclined to ask their own questions, interrupting at an inopportune time. If you take your own breaks to talk, you stay in control of the timing.
I’m not saying I never said I was inclined to hire someone that coded quietly, but the code is the least interesting part, and just table stakes. How you reason, how fast you can pivot, showing you think through options thoroughly, etc is so much more important, and raw code doesn’t tell that story.