This always gets me. When the interviewer asks a question, the correct answer is literally never, “let me think about it quietly for a moment”. This is one of the disconnects between interview programming and real programming people get frustrated over.
Also this: "It’s funny how many people can’t edit text on any machine but their own." - I bought a notebook without properly checking the keyboard and even now after 3 years it still bugs me everytime I type. Nobody can understand how these things can really limit focus. If I got a different computer with different keyboard, different operating system, different text editor (not even an IDE) and was asked to write a program, my focus would be totally ruined, compared to my actual daily work.
But I prefer to let applicants pick whatever language (within limits) and editor/ide they want for our current hiring process.
It's much more about how they solve a problem and navigate their tools (because that's an indicator too) than how they can use my stack.
After they gave me the keyboard, I told them that I can only type with one hand for physical reasons.
Not saying interviewing isn't broken in a myriad of ways, but asking a candidate to talk through their process to illuminate it isn't unreasonable.
yes, you do, but many interviewers don't and that's the problem
The information flow goes both ways.
I mean, you don't want to say: "I'm going to trial & error this shit while the fucking compiler builds and the stupid tests say it works" which is how must programming is done anyway.
But hopefully you have some ideas on what you want to try (and what your experience says you shouldn't, equally important) and talking about that thought process is exactly the kind of data I would want.
It doesn't even take an interview, we've quit pair sessions because it's sometimes fucking impossible to focus on deep stuff with another person competing for your attention.
Shut up, go away, let me focus and solve this is a perfectly good approach in real work.
Well if you solve it, then you've proved that you can solve it, right? So let people solve it the way they solve it when they're working for real. If that means sitting quietly and focusing on their screen, so be it.
Alternatively, the point of an interview is for the applicant to pretend they're bright and solving it on the spot while broadcasting how smart they are: https://news.ycombinator.com/item?id=17106291
Which gives you more data on how someone works and thinks?
1. Person silently sits for 15 minutes and then codes up a solution that meets the test criteria in another 15 minutes, typing quickly.
2. Person talks about the issues, tradeoffs and experiences while coding. They ask questions and engage in some discussion around the problem set. They end up with a partial solution after 30 minutes.
Of course those are hypothetical extremes, but it is clear to me which scenario gives the interviewer more information.
That's different from when the candidate is asked a question and they literally just become silent, with a "deer in the headlights" expression.
Of course, there's not really a way to tell in advance if you get an interviewer like me, or a jerk that insists you know everything off the top of your head.
If I, as an interviewer, ever did that I would:
a) expect the candidate to walk out, and
b) get told off by pretty much everyone in the company. Deservedly.
I really cannot think of a ruder way to express "you do not matter" sentiment than completely ignoring the candidate and flip through random stuff on my phone - while conducting an interview.
Google-fu is just as important a skill as knowing how to exit vi.