267
all 41 comments
sorted by: hot top controversial new old
[-] frezik 34 points 4 weeks ago

Our industry has no idea how to hire people. Our interview processes are almost designed to filter out obviously bad candidates while accepting that some good candidates will fail, too. Getting a specifically good candidate is almost luck.

Remember this if you're bummed about a string of rejections.

[-] FizzyOrange@programming.dev 4 points 4 weeks ago

You don't know how good you've got it. The hiring process in other industries is much worse.

[-] bitcrafter@programming.dev 2 points 4 weeks ago
[-] FizzyOrange@programming.dev 1 points 4 weeks ago

I don't have a particular story. A lot of industries use "competency based questions", you know "tell us about a time when...".

They're awful. If you don't know what I'm talking about count yourself lucky.

Which would you rather, "write some code to filter off numbers from a list", or "tell us about a time when you worked with someone difficult. How did you win them over and subsequently become best friends?".

[-] bitcrafter@programming.dev 1 points 3 weeks ago

It is true that the last time I answered that question with, "I put something in their drink every morning to make them more chill," I did not end up landing that job...

[-] staircase@programming.dev 1 points 4 weeks ago

for those who this affects, this lands badly

[-] resipsaloquitur@lemmy.world 23 points 4 weeks ago

I disagree. I give live coding tests. I very much don’t want the candidate to be stressed. I provide a written and verbal description of the (simple) problem, and provide unit tests. And I talk them through it if they run into problems, but try to give them space to work it out.

I’m not sadistic. I want to see if they can write code.

The few times I skipped the live test because of practical reasons or they were “too senior” I absolutely regretted it.

[-] cole@lemdro.id 13 points 4 weeks ago

fully agree. we're actually reintroducing live coding interviews into our process because so many candidates made it onsite who then showed that they didn't really know how to code

[-] staircase@programming.dev 7 points 4 weeks ago* (last edited 4 weeks ago)

The article isn't saying don't check, it's saying that live coding interviews are a bad measure.

[-] VoterFrog@lemmy.world 2 points 4 weeks ago

I'm not sure that offline or alone coding tests are any better. A good coding interview should be about a lot more than just seeing if they produce well structured and optimal code. It's about seeing what kinds of questions they'll ask, what kind of alternatives and trade offs they'll consider, probing some of the decisions they make. All the stuff that goes into being a good SWE, which you can demonstrate even if you're having trouble coming up with the optimal solution to this particular problem.

[-] NotMyOldRedditName@lemmy.world 2 points 4 weeks ago* (last edited 4 weeks ago)

... that's why you do a follow up interview and review their code, and maybe leave some things a little ambiguous to see if they ask you questions (telling them it's okay to email questions and mostly expected)

Why did you decide to do ABC this way? What do you think about having done it XYZ way instead?

I know you didn't have time to write a full test suite, but what areas of what you wrote would be best to focus on tests and why?

You can ask them so many things about what they wrote.

That's like... how it works in the real world. They ask questions to product as they come up, they get questioned on their work in code reviews

Unless you work somewhere where you pair code 100% of the time anyway...

If you just look at it as a pass or fail and are not doing a detailed review with them after, you're doing it wrong.

[-] cole@lemdro.id 2 points 4 weeks ago

hey, I love this idea, but we tried it and we kept getting candidates who managed to BS their way onsite and then waste our time ultimately.

it just didn't work. I really want it to work because I hated live coding too but it just didn't.

you can make live coding interviews that aren't actually difficult questions and are more about showing that you can think and write the most basic of code. that's what we do now.

[-] VoterFrog@lemmy.world 1 points 3 weeks ago

Sure you can move some parts of the conversation to a review session, though I think the answers will be heavily influenced by hindsight at that point. For example, hearing about dead end paths they considered can be very informative in a way that I think candidates assume is negative. Nobody expects you to get it right the first time and telling the interviewer about your binary tree solution (that actually doesn't work) can be a good thing.

But the biggest problem I think with not being in the room as an interviewer is that you lose the opportunity to hint and direct the candidate away from unproductive solutions or use of time. There are people who won't ask questions about things that are ambiguous or they'll misinterpret the program and that shouldn't be a deal breaker.

Usually it only takes a very subtle nudge to get things back on track, otherwise you wind up getting a solution that's not at all what you're looking for (and more importantly, doesn't demonstrate the knowledge you're looking for). Or maybe you wind up with barely a solution because the candidate spent most of their time spinning their wheels. A good portion of the questions I ask during an interview serve this purpose of keeping the focus of the candidate on the right things.

[-] FizzyOrange@programming.dev 2 points 3 weeks ago

I don't think anyone disputes that, it's just that nobody has come up with anything better.

Take home exercises were a potentially better option (though they definitely have other big downsides) but they aren't a sensible choice in the age of AI.

Just taking people's word for it is clearly worse.

Asking to see people's open source code is unfair to people who don't have any.

The only other option I've heard - which I quite like the sound of but haven't had a chance to try - is to get candidates to do "live debugging" on a real world bug. But I expect that would draw exactly the same criticisms as live coding interviews do.

What would you do?

[-] staircase@programming.dev 1 points 3 weeks ago

You mention lots of options. Given people are varied, and you want that in a company, how about letting the candidate decide how to prove themselves? It's pretty established that it's not "fair" to stick to a single style, so why hang on to that?

[-] staircase@programming.dev 12 points 4 weeks ago* (last edited 4 weeks ago)

You seem to be disagreeing with something that isn't the main point of the article.

That you take those steps doesn't mean candidates aren't stressed, despite your intentions.

[-] resipsaloquitur@lemmy.world 3 points 4 weeks ago

Sorry an interview is stressful to candidates?

[-] toynbee@lemmy.world 8 points 4 weeks ago

Fuck yes, and that's just a regular one.

[-] StupidBrotherInLaw@lemmy.world 7 points 3 weeks ago

Is this a serious question? What interview, a meeting specifically to scrutinize someone and compare them to their peers, isn't stressful for candidates?

[-] BrianTheeBiscuiteer@lemmy.world 7 points 4 weeks ago

Interesting. What do you think happened with those you didn't test? You think they were making stuff up or senior at their job is a far cry from senior at your job?

[-] resipsaloquitur@lemmy.world 7 points 4 weeks ago* (last edited 4 weeks ago)

Not sure. One seemed either incredibly timid or just way in above his head on simple tasks. I assigned him a bug and had already narrowed it down to a particular return code, in a particular call tree. He could have set 20 breakpoints and found the bug in five minutes. Or put unique error codes and found the bug in ten minutes.

But weeks later he was still asking questions and eventually just moved on without solving the bug or even finding the cause.

Maaaybe he would have aced the live coding test, but I doubt it. He just never seemed to "get it" and I think the live test would have reflected it.

But by "senior" i mean decades of experience. No quibbling about job titles.

[-] herseycokguzelolacak@lemmy.ml 22 points 4 weeks ago

I think asking one simple coding question during a live interview is a great way to eliminate candidates that have obviously lied on their CVs. Nothing fancy, just a simple problem that everyone should know. But asking leet-code medium or hard problems make no sense.

[-] silasmariner@programming.dev 3 points 4 weeks ago

Depends on what your requirements are. Some times it's the best way to let a candidate shine, which is usually the goal -- give people as much of an opportunity to impress as you can

[-] JackbyDev@programming.dev 1 points 3 weeks ago

If a requirement is that a developer writes code then I want to see them write code.

[-] Kurious84@lemmings.world 22 points 4 weeks ago* (last edited 4 weeks ago)

If you give live coding tests you're a moron. Here's why. Not all but many of us coders are autistic or highly functional autistic and our brain shuts down in high stress social situations with someone watching over you. Plus whiteboarding when I never fucking whiteboard anything. But get us alone in a room with a task and we'll whip your ass.

My last boss pulled this on me. I almost didn't get the job. Then I told him to assign me any project as homework. Overnight I produced a program that blew them all away. Got hired.

[-] Cratermaker@discuss.tchncs.de 19 points 4 weeks ago* (last edited 4 weeks ago)

I can see how this could be unfair, but working as a dev sometimes does require you to be on top of things in a high stress atmosphere. For example, what if you're proposing an excellent technical solution in a meeting but some jaded older engineer is hard to convince? If you can't outline your thinking in that scenario, your solution could be discarded just because someone was louder than you. As someone who used to have performance anxiety, I believe it's generally something you can and should practice for. On the other hand, if there really isn't a need for this type of skill, it totally makes sense to avoid creating interview environments where you are filtering candidates based on it.

[-] martinb@lemmy.sdf.org 5 points 4 weeks ago

I did stress test interviews for DevOps positions. I explicitly told them that and gave them a task and a time limit. I would watch what they did and there was nothing out of bounds as long as they were solving problems. For example, I would give them an account in cloud provider and then task them with spinning up a k8s cluster with a few basic services and make it scalable, then watch and heckle as they googled around and brought up services. The objective wasn't to complete the task though, it was too see how they approached problem solving. Good times.

[-] mxskl@programming.dev 1 points 4 weeks ago

Great example. We do the same but to spin up a single ec2 via terraform. Checking the real familiarity with tools. This immediately filter those who lied about their experience.

[-] silasmariner@programming.dev 4 points 4 weeks ago

Good enough example, although I would've picked dealing with a live incident

[-] Cratermaker@discuss.tchncs.de 3 points 4 weeks ago* (last edited 4 weeks ago)

Yeah, that too! When you have some non technical manager breathing down your neck, you might have a hard time not fumbling around even if you normally could resolve the issue in no time.

[-] BrianTheeBiscuiteer@lemmy.world 2 points 4 weeks ago

That sounds fair. I hate "tests" that involve things you'd never do on the job.

[-] FizzyOrange@programming.dev 14 points 4 weeks ago

IMO this is not a helpful way to put it. They measure skill under stress. Stress may have a large effect on skill level for some people but highly unlikely that it's so large that performance is completely random.

[-] tyler@programming.dev 4 points 4 weeks ago

Nah, they measure memorization under stress. Can you recall that tidbit of information to solve the problem the interviewer has given you? If you never have needed to solve a problem like that then you’re shit out of luck, even though solving that problem for the first time (by whomever) definitely didn’t do it under stress in a job interview.

[-] FizzyOrange@programming.dev 5 points 4 weeks ago

Some bad interview questions are like that, sure. But they're supposed to be things you are very unlikely to have done before and can reasonably figure out. It's not too hard to come up with simple questions like that. (Though I will grant many people don't seem to bother.)

[-] JackbyDev@programming.dev 7 points 3 weeks ago

I'm sorry, but as an interviewer I'll never not have some form of live coding. Some people just don't know how to code. I don't mean that in some elitist, gate keepy way. I mean some people lie on resumes. If I used Excel every day (like I was an accountant) I would not take someone's word that they know how to use Excel, I'd want to see them do it.

I am fully aware that problems are harder under stress. I advocate for genuinely easy problems in coding challenges. I don't like brain teasers. I don't really even care if you finish the problem. So long as I can tell that you know how to make a computer do things you tell it in code, know how to ask questions about a problem, and make progress towards solving it -- I'm happy.

At an old job I made the mistake of not conducting a coding session of some form and we hired someone who I genuinely believe didn't know how to program. They'd ask for help on tasks very often and I'd try to guide them in the right way, but once we paired up, they just wouldn't ever type anything. After me becoming more and more clued into something being wrong and seeing no progress I finally mentioned it to my manager. I don't think he ever got fired, just shuffled around.

[-] oshu@lemmy.world 4 points 4 weeks ago

my current company does live code design challenges instead of straigt codong exercises. seems to work well

[-] Venat0r@lemmy.world 4 points 4 weeks ago

is the point of a question like that not to measure how you perform under stress? the guy who posted it in the screenshot doesn't seem to realise that either though...

[-] tiredofsametab@fedia.io 2 points 4 weeks ago

I give live coding tests generally based on the level they claim to be at in the language. It doesn't have to be perfect as I'm more concerned with why they're doing a thing. I usually pick something fairly basic with some edge cases just to see if they mention it.

As opposed to homework, it also proves that you can at least basically work in the language in question (I've had a couple of people who got to my round but seemed to know almost nothing about a language they claimed a lot of experience in (like declaring variables and struct members wrong... seriously). We also caught someone that didn't seem to have done the homework themselves.

If the candidate makes mistakes or gives an imperfect solution, I try to gently guide them to where we need to be. I ask them to explain why they made decisions they did, any edge cases, and how to improve performance or scale it. I expect them to ask questions when something is vague (and usually something in my problem can be interpreted one or two ways for this reason) because these are things they will encounter working with stakeholders and other engineers. If they can't do that live and on-the-fly, they're probably not for us. I fully expect nerves to be a factor and account for that; we're all nervous in interviews.

[-] sobchak@programming.dev 5 points 4 weeks ago

People have different levels of "nerves" as others, and it kind of sounds like you may filtering out applicants on an arbitrary metric (how nervous a person may be in an interview). Don't have enough information about your process to say for sure (obviously), but it may be something to think about. Interviews can be very high-stakes for some people (such as "I may become homeless"), and not for others ("my parents are rich"). After hired, it's not necessarily as high-staked, and toy problems aren't what SEs work on day-to-day.

[-] tiredofsametab@fedia.io 3 points 3 weeks ago

I'm mostly making sure they didn't completely lie about being able to work in the language and can explain what and they would do, why, and how they respond to feedback. I expect people to be varying levels of nervous and that's fine. I work with people to get them focused and take the edge off as much as possible.

What I ask for usually is related to what we need to implement, but a more basic chunk of it to, for example, show that the candidate understands concurrency and can use basics in the language to do something with that (which we do frequently).

For many positions, we do not have homework and this is the only coding we get (kinda depends on role and project).

As a newer company and still technically a start-up, the boss paying the bills can decide we need to chase something else and he isn't being talked out of it. This can lead to very fast collaborative design and coding of PoCs which can be more intense than the interview. I don't like it but it is what it is. Not everything we do is nice, stable, and long-term.

I can relate to needing that job; I've been homeless, so I definitely kno the hat that pressure feels like and why nerves alone are never a deciding factor for me.

this post was submitted on 02 Aug 2025
267 points (100.0% liked)

Programming

22415 readers
86 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS