Google, Facebook, Amazon use it for a reason. And they are top engineering companies. Period.
If their process for hiring was so spectacular, you'd think they'd have been a little more reluctant to do mass layoffs.
The problems with live coding interviews
21–30 of 226 posts
Re: The problems with live coding interviews
#22This presents as a bit of an unintentional strawman against demonstrating any kind of coding during an interview process. Live coding, if earnestly used only as a filter, does not inherently need to focus on speed or performance. It doesn't have to be a hard "galaxy-brain" problem. It doesn't have to have any tricks to it. It can literally be a simple task that one would expect any working software developer to be ab…
> It can literally be a simple task that one would expect any working software developer to be able to complete without too much fuss.
I agree, although this is why I feel a small project and participation in code review is a more realistic and useful gauge for real world ability.
Can the person understand the code base well enough to propose a sensible change, and how collaborative are they in the code review process? Do they document/comment their code, add tests, do they answer questions and take criticisms patiently, is the solution simple, does it work?
You'll learn about zero of these things watching them write a fizzbuzz in a shared editor window.
Re: The problems with live coding interviews
#23A perspective from the other side of the desk (playing devil's advocate here): There's a fundamental skill that a good programmer has to have, and that is to be able to take a novel problem that they haven't seen before and break it down to solve it in a sensible way. There are plenty of programmers who fake their way through a career without having that skill. They just copy stuff and never really understand it. The…
> “take a novel problem that they haven't seen before and break it down” But who does that professionally as a stand-up performance, clock ticking, a judge breathing down your neck who has been equipped with a script that tells him things like “if candidate doesn’t do X within the first ten minutes it’s very bad”? Doing well in that situation depends more on social performance skills than problem-solving skills. You’…
As for the time limit, it's relative. All things equal, if you can complete the problem in 10 minutes and the company can hire somebody that can complete it in 9, then objectively the other candidate is the stronger one.
As for nervousness for being forced to partaking in a stand-up performance, I'd argue that "social performance skills" can work against you, since the more "antisocial" you are, the more you can ignore (or are oblivious to) what other people think about you and you can focus on your task. It's only people who actually have the minimum requisite "social skills" that would be conscious of other people intensely watching them "perform".
But even if you're right -- interviewing is inherently a "social performance" activity. If you're not coding you're doing some other stand up performance to present yourself anyway.
Re: The problems with live coding interviews
#24I’ve never tried this exactly, but I wonder how “live coding” interviews might go if the interviewer was the one doing the typing/coding and the candidate’s role was to verbalize what the interviewer was doing (and why) - and also guide them to some degree.
It’d be more akin to pair-programming, which some of the interviews I’ve conducted have evolved into, depending on the strength of the candidates.
Would that capture enough to get a sense whether this person gets the gist of the code being written such that they could replicate the same output in a less contrived scenario?
Re: The problems with live coding interviews
#25There are problems with not doing any live coding too. I've interviewed people for programming jobs who can bullshit their way through a phone screen but literally can't write a for loop or a simple fiz buzz program.
Re: The problems with live coding interviews
#26Everyone complains about the state of SWE interviews yet nobody seems to be able to come up with a legit better alternative. Even the author recognises this in the article.
This format is popular because it's the best time/effort trade-off for both the company and the candidate. It's massively flawed, but everything else attempted so far turned out to be even worse.
Re: The problems with live coding interviews
#27I’ve never tried this exactly, but I wonder how “live coding” interviews might go if the interviewer was the one doing the typing/coding and the candidate’s role was to verbalize what the interviewer was doing (and why) - and also guide them to some degree. It’d be more akin to pair-programming, which some of the interviews I’ve conducted have evolved into, depending on the strength of the candidates. Would that capt…
I actually was interviewed this way once. It worked pretty well.
Re: The problems with live coding interviews
#28Live coding interviews are the future. The risk of false impersonation was low enough for a while to rely solely on virtual screens, but widespread access to and awareness of large language models has made any virtual exercise unsustainably corrupted. Sure, you can often tell the folks who know nothing when asking them to explain the code, but it's increasingly difficult to tell a great engineer apart from a mediocre…
One of the author's points is that the live coding questions are often the types of problems which, in the workplace, might best be done with GPT.
"So at that point, do they want to see you muddle through it, or would they rather see that you know to have ChatGPT run through the initial pass and then refactor?"
"If a company is evaluating engineers with questions that can be easily answered by AI in seconds, what are they really evaluating for? Perhaps they’d be better off hiring a chat bot."
Re: The problems with live coding interviews
#29Your experience sounds horrible, and unfortunately those sort of "tests" are just a horrible thing. Generally, do NOT do take-home exercises. That's your time, which has value; the company doing the hiring contributes nothing. At least, in a live-coding exercise both you and they have some skin in the game. As with all tests, good or bad, part of the test is actually doing the test. Often it's less what you know, or…
The author did write "better yet, let applicants do a take-home, and pay them for their time. ... think of it as another chance to be selling them on joining your team over some other team."
Re: The problems with live coding interviews
#30Everyone complains about the state of SWE interviews yet nobody seems to be able to come up with a legit better alternative. Even the author recognises this in the article. This format is popular because it's the best time/effort trade-off for both the company and the candidate. It's massively flawed, but everything else attempted so far turned out to be even worse.
How do other industries do this?
Is programming weird because you can just ask someone to prove they know how to use a hammer? And so other industries just have to hire based on work history and/or bias "culture fit" during the interview? And they suffer terribly from people who can talk the talk but not walk the walk?
Or is programming weird because there's so much propensity for people to be able to talk but not walk? We rely on nerdspeak and jargon so much that just being able to prattle on in a dilbert-esque way would otherwise convince someone to hire you?