[lucisferre]

This 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 able to complete without too much fuss.

Whether this is actually the case comes down to the hiring manager.

If the hiring manager decides to optimize for performance in the coding interview then yes everything said here is true. They will typically hire people who can perform well and fast at simple coding test type problems above other any other desirable attributes.

If however, they simply evaluate the ability to work through (at any reasonable pace) a fairly trivial coding task, but make the hiring decision on bulk of the rest of the interview, then it shouldn't be a problem.

The problem is most hiring managers have not been selected for their ability, or even trained, in interviewing. A coding test is easy to set up (or copy from somewhere), administer and evaluate. It is often literally the least they could do.

What this post describes is simply hiring managers who lack interviewing skills. Personally, I would probably want to avoid reporting to such a person.

[polalavik]

I still feel like interviews are entirely weird for everyone involved. It's not a real reflection of somebody's performance. Perhaps some people cannot work well with someone watching them think. I'm one of those people. I get a lot done at my job, but I need time to mull things over and sit with things in order to come to something that makes sense. Interviews only reward 1 of 2 things: people that are fast, efficient thinkers (this is good) and people that have very good social skills and can convince you of something they are not.

People who cannot perform socially or technically on the spot in a completely unnatural setup are sort of left in the dust. I'm not sure i have a solution other than throwing out technical interviews and actually trusting peoples prior work. I have work in the public (published academic papers, patents) but none of that seems to mean anything in an interview lol. Its only about can you perform right here right now for 1-4 hours.

I've said it on other threads. (1) trust peoples past employment, use background checks or something to make sure they actually worked where they said they have worked (2) look at their body of public work if they have any (3) just hire the people that look good off those two metrics and youll probably end up with a good employe 90% of the time and save countless hours and dollars. I'm almost convinced random choice + team vetting of resumes + a little background check would be just as effective as endless technical interviews.

[RandallBrown]

> It can literally be a simple task that one would expect any working software developer to be able to complete without too much fuss.

Unfortunately this varies dramatically from person to person during a high pressure interview.

I interviewed a very senior developer once that actually used to be my current manager's boss. The coding question was pretty simple and most people didn't struggle too much with it. He BOMBED it. Like, you could have taken someone with 30 minutes of coding experience and they would have gotten as far as he did.

It was also very obvious he was just incredibly nervous so I put him through to the next round anyway. We hired him and he was great.

[uuddlrlrbaba]

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

[eesmith]

> unintentional strawman against demonstrating any kind of coding during an interview process

I don't think that's a fair statement. One of the alternatives, take-home coding exercises (with possible live call afterward), is a kind of "coding during the interview process", yes?

The essay more specifically concerns a certain specific type of coding evaluation, with live evaluator who is unknown to you, in a setup which inhibits many normal problem-solving techniques (pacing, drawing notes, thinking silently for 10 minutes, etc.)

> 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 think the two of you are in agreement even for that point. That is, the author seems to agree, writing "They likely do a great job filtering out people who are incapable of programming".

[commandlinefan]

The point that's often overlooked by people who complain about any sort of interviewing process (this one being an example) is: somebody _does_ pass the interview, eventually, or they change the process. The poster here seems to be suggesting that live coding is an impossible hurdle that nobody can overcome, but that's obviously not true - people overcome it and get hired all the time. I've auditioned as a musician in the past and it's tempting, when rejected, to say, "well, their standards were just too high" - but I have to find the humility to recognize that they just went with somebody better, because they did end up going with somebody.

[goostavos]

>hey just went with somebody better

Yeaaaaah, that's not how any of this works. I've done 100+ interviews for MegaCorp. Who ultimately gets hired is ultimately a dice roll no matter how "data driven" we call it. Did you get a good loop? Was one of your interviewers in a bad mood? Did you end up with a hiring manager who "used to code" and now measures everyone against whether or not they use out dated OOP techniques everywhere? Ah crap, did you get Gary? That guy sucks so much. He asks "hard" questions to make himself feel good.

The sausage is what you'd expect if you remember one key thing: it's humans on the other side of the desk. They're finicky and arbitrary ceatures.

[AbsoluteCabbage]

Flashbacks to losing out on a dream job because the husband and wife interviewers had a nasty argument after a long plane flight right before the interview. Sigh.

[commandlinefan]

> Who ultimately gets hired is ultimately a dice roll

Well, I'm not sure I believe that's universally true (or even particularly common) but even if you're right, what difference does it make? You still have to be good enough not to bomb the interview but then just "hit the tables" often enough to get a lucky roll. That would be the case for any sort of interview process, whether it was live coding, an informal discussion, or tests of strength.

[pugworthy]

Sometimes someone is passed by the interviewer, which is not the same thing as passing the interview. That is, they just pick someone, who may or may not be the best candidate.