1

Talking while coding in an interview

Profile picture
Anonymous User at Taro Community2 years ago

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?

87
2

Discussion

(2 comments)
  • 2
    Profile picture
    Meta, Pinterest, Kosei
    2 years ago

    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.)

    • So before I get into coding, you should be talking a lot, lots of back and forth
    • Once I get into coding, I stay quiet for 1-2 minutes at a time while I write code. After a few minutes, I'd check back and try to summarize the code I wrote, or what I'm about to write. This gives the interviewer the ability to interject and offer feedback.

    In general, you should not have more than 5 minutes of silence in an interview.

  • 2
    Profile picture
    Staff SWE at Google, ex-Meta, ex-Amazon
    2 years ago

    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.