I don’t think I’ve ever been asked a “which is the brake pedal” level question in an onsite interview. Usually it’s more like I’m a mechanic being asked “how do you replace the water pump on a 1999 Saturn Ion, from memory, please.”
That's a benefit of the coding interview, actually. We don't ask you about that particular feature of some library from 10 years ago, which is basically a luck question: you either happen to know or you don't.
We ask you to code a simple task that you should be able to do in your favorite programming language.
Not entirely sure how the discussion of coding interviews veered towards obscure knowledge interviews - the former was expressly designed to supersede and eliminate the latter as one of its core goals!
That’s just it: replacing a water pump on a common used car is a task any competent mechanic should be able to do. But, possibly not without the repair manual. And, I certainly wouldn’t think they’d be able to describe step by step how to do it without the car or manual in front of them!
Likewise, many interview programming tasks can be are ones a competent programmer should be able to do with the tools of the trade accessible (namely Google and time to think).
Some simply are not. I was once expected to write, debug, and modify a concurrent chat server in an hour long interview. I do think that’s a reasonable programming task, but not one to be completed in an hour, under scrutiny. It’s the equivalent of being asked to rebuild a motor in an interview : definitely doable under real world conditions, but not a realistic test to determine whether to hire someone.
Sounds awful. I'd be interested to know what startup it was. But it's no secret that some of the well-known names do tend to drop the ball on hiring and various other aspects of operations.
We ask people to implement a relatively simple algorithm, that’s particularly practical, in the language of their choice. Then we change the parameters and ask them to make it more efficient.
It’s centered around solving a reasonably common place problem, and doesn’t require anything fancy to solve. It’s more of a test in how they programmatically solve problems over anything else. If somebody struggles with it, then they haven’t been bamboozled by some acedemic algorithm problem, they’ve just shown that they’re not going to be able to write clean code unsupervised.
Exactly. I don't think they are accounting for how some people react to interviews. I've had candidates who have been explicitly nervous and stuttering, and we've consciously had to decide not to hold that against them. They turned out to be a great hire.
I think I can do okay in coding interviews, but only if I prep for that style of work first. It's definitely different. I'm perfectly (or at least acceptably) competent in my day to day.
If we’d ever had somebody crippled by interview stage freight, I make be able to take that seriously. The coding skills you need to pass our test is writing a for loop that mutates a dict. We’ve never had anybody forget how to do that in our interview, but we have had people come up with remarkably inefficient solutions to the problem.
I don’t think it’s reasonable to say that people’s problem solving skills (which is what we’re actually testing) become exponentially less efficient during an interview. But even if it was, the test is still doing it’s job, because what would we expect to happen when we give a person like that a deadline, or ask them to review a PR?
Don't need to be "crippled." Simply a shot of adrenaline is enough to shut down most higher-level thinking. At that point the candidate is just pulling things from memory at random hoping they fit.
> remarkably inefficient solutions
The first one usually is. As the problem gets clearer, better solutions become obvious. That takes relaxation and calm thought however, e.g. Archimedes in the bathtub.
> I don’t think…exponentially less efficient
Doesn't need to be a large difference. With multiple candidates, even 10% is decisive.
There's also the psychological factor of knowing something makes the "knower" think it's easy while the others believe it's hard.
I do lots of interviews as a contractor, and must say they have little to no bearing on my ability. In the real world I've solved every problem encountered, given some time. Interviews almost none, the few successes depend on whether I wrote the same algorithm in the last two weeks by chance.
A random throw of the dice at the craps table would be just as accurate and less stressful for all involved.
