Item — HN Reader

>> “Hmm, I wonder if I could … … … no, never mind, I’ll just do this instead.”

I can either think OR talk, I can't do both at the same time. I can happily think and THEN talk but when I've interviewed with companies that have this interview culture (i.e. Google) they don't let you do this. They start telling you they want to hear what you're thinking. Also, most of the time thinking is disjointed and nonsensical and is way faster than what you can express so it's actually disrupting the problem solving. I really don't understand what's wrong with letting people think for a few minutes.

Additionally I am perfectly fluent in English and talk code everyday in English but it's not my mother tongue so having me chit-chat my thinking away while I think (potentially in another language) hinders me since I focus more on what I am saying than actually solving the problem.

>> "My typical work process in a technical challenge like this is to spend a minute or two thinking quietly about the problem and writing down notes, I’ll share those thoughts with you in a moment to get your input"

That's great, but that hasn't been my experience. Interviewers constantly tell you to talk and it's specially bad during a phone interview. I'd be fine if the interview was really setup as a collaboration between two people, but it's not, you're given a problem and a whiteboard.

1 comments

I'd talk more in code interviews if more interviewers behaved the way these essays say. I struggle to recall a time when the interviewer acted as a collaborator during the interview.

Usually, they'll pose the task, sit back, and stare at you. You ask a clarifying question, but you know you're stalling for time. The task is clear. You just need to remember the LeetCode solution. The interviewer looks at you impatiently.

You take a stab at describing the solution. You say, "I think this is a job for prefix trees," and look at the interviewer.

The interviewer says, "OK," and gives you a look of alarm and pity.

You solve the problem the way you've solved ten very similar problems on LeetCode. The interviewer says, "Are you sure this works the way you think it does?"

You panic. What did you do wrong?! The interviewer gives you another look of pity.

If you're writing live code, you run it with some test cases. The test cases pass. You think of some edge cases. They pass too. You look at the interviewer. The interviewer says, "OK." A moment elapses.

A few days later the recruiter calls you and extends you a verbal offer. Or they send you an email that says that you won't be getting an offer. The interviewer's expression of pity is the same in either case.

Yup. I've had that blank stare interview. I've decided that the next time it happens, I'm going to attempt to patiently explain to the interviewer why that isn't going to get them the information they want. Last time it happened I was hired anyway because this was only one interview of many. It turns out the bad interviewer was a nice chap and very clever, but with no understanding of how humans work. I've found that such people are often interested to know why their interactions are failing. They want to learn new rules that they can add to the personality simulator they run in their head :-)

Absolutely, that's what I meant with my last comment. It's framed as a collaboration to see how you think but that's not what really happens. It's all about jumping through hoops and doing the right dance.

My experience is in the games industry and interviews there are usually more about what you've done which eventually leads to implementation details from where you can easily gather if the person knows what they're talking about.