5 ms·

My attitude towards code interviews is to politely decline them and encourage people best of luck hiring a junior developer; because that's obviously what they

My attitude towards code interviews is to politely decline them and encourage people best of luck hiring a junior developer; because that's obviously what they are looking for. I'm closing in on 50, so not that junior anymore. If anyone has any doubts about my coding abilities after reading my CV, browsing my Github repos, and talking to me, then it's not going to work and we can both save ourselves some time. I've stopped responding to recruiters as I rarely see any evidence of them even being capable of doing these simple things. I've hired and interviewed a lot of people over the years. Mostly without the help of recruiters. I like to think I'm pretty good at that, actually. I always look for people that are eager to learn. I care more about what they don't know than what they can regurgitate because they did lots of silly online prep. If people are young and fresh out of school, my assumption is they are going to have to learn a lot in a hurry. So I look for people that are curious, eager, and have an open mind. The best way to do that is to get them slightly out of their comfort zone and talking about how they would tackle things. The signs I look for here are enthusiasm, ability to surprise with good answers, etc. This generally does not involve code interviews; though I might ask some targeted questions about how they would deal with certain things in languages, frameworks, etc. they list as being proficient in. I've of course worked for some people that insisted on me organizing code interviews and it's a chore and IMHO you learn absolutely nothing that isn't obvious if you just casually talk to people for 30 minutes or so. I usually argue against such things and prefer just talking to people directly.

willvarfar 2y ago
FWIW I always ask some really super simple coding questions in interviews, even for really senior people with apparently stellar CVs. Let them pick their language or use psuedocode or whatever. It's surprising how many 'senior' engineers are actually BSers who will slow you down or derail you completely rather than speed you up and you need to spot them because they will excel at getting through the non-technical interview filtering! Also, I'm interested in how you explore things and explain things. I'm not actually interested in acquiring an implementation of FizzBuzz or whatever. I just want you to show me that you 'get' it and then we can get on to the interesting stuff like 'tell me about your last project' etc. So don't be too hasty to think the people doing technical interviews are idiots thinking devs are interchangeable cogs etc.
- OJFord 2y ago
  > Also, I'm interested in how you explore things and explain things. I'm not actually interested in acquiring an implementation of FizzBuzz or whatever. I just want you to show me that you 'get' it and then we can get on to the interesting stuff like 'tell me about your last project' etc. Sounds like you'd more valuably/realistically get that from the discussion of a previous project though? How it works, or something interesting they had to figure out, etc.? > don't be too hasty to think the people doing technical interviews are idiots I don't think anyone has a problem with technical interviews? At least I agree that's not reasonable. That doesn't have to mean 'coding' though, you can ask about how they'd approach a particular problem, quiz on some fundamental knowledge in a fizzbuzz sort of way, etc. You can more easily tune it to the kind of candidate you're looking for then too, for example I've asked how they'd tackle improving the performance of a particular SQL query that's been identified as too slow. There's a tonne of possible answers to that ranging from naïve/they don't really know, through pragmatic good fit responses, to way overkill I hope they understand we don't need them doing that here/not operating at that scale etc. - and it's fairly open-ended in what you can discuss driven by what they volunteer and know about. (Which is another good thing IMO, I don't like being on either side of interviewer quizzing and candidate umming and ahhing not really knowing! Both more comfortable and more beneficial to have a discussion about whatever is known IMO; to quickly move along the perimeter if you hit the edge of that.)
  - pavel_lishin 2y ago
    > Sounds like you'd more valuably/realistically get that from the discussion of a previous project though? How it works, or something interesting they had to figure out, etc.? You may be underestimating people's ability to bullshit their way through this sort of discussion. It's harder to bullshit your way past a blank file in a code editor. I'd wager that something like FizzBuzz will eliminate 90% of the chaff. Yes, it's laughably simple. No, it's not so simple that it won't stump a significant number of folks who've coasted for years.
    - around_here 2y ago
      FizzBuzz is an incredible filter for devs. Any kind of async JavaScript that needs to do something with the data after it fetches it has also been a winner. Lately the biggest weeding tool has been asking candidates to fetch some JSON from a bucket, then visualize that data. I'd say that maybe half the people manage to fetch the data in 30 minutes, and of that, maybe 10% get the data fetched within 10. The other 20 minutes is trying to help them recognize that their data is initially being rendered with "undefined" and they have to update the viz.
M4v3R 2y ago
I totally understand your point of view, but looking at it from the other side it’s not as simple. We had candidates with 10+ years of experience in their resume, talking to them it seemed they know what they’re doing, they showed some of the code they’ve supposedly written. Then they got hired and it turned out they can’t code - their PRs are below junior level, constant bugs, communication is abysmal, they overshoot their estimations by 3-4x, etc. Thus happened to us twice, and after we introduced a simple live coding session to our interviews where you have to implement a simple real world web component (for a frontend position) suddenly the problem of bad hires disappeared almost entirely (you can’t judge someone’s character during a short interview but that’s another issue).
- mrweasel 2y ago
  We recently interviewed a candidate, with 7 years of experience at a FAANG company, fail a really basic coding interview and we don't even make you write code. I have no idea what these people expect. We ask coding questions, we have basic programming skills as a requirement, what do they think will happen if they get the job? Do they expect to just magically learn the required skills or hope that nobody will notice that they're not able to close their tasks?
  - vntok 2y ago
    > Do they expect to just magically learn the required skills or hope that nobody will notice that they're not able to close their tasks? It obviously worked for the candidate you mention, didn't it? Spent 7 years at FAANG, didn't know how to code.
    - mrweasel 2y ago
      That is true, but how?
      - azornathogron 2y ago
        There are lots of roles at big companies that don't involve actually writing code. The bigger the company, the more communication and organizational overhead there is, and the more not-actually-coding work there is. Even within roles that have a "software engineering" title. Hell, I barely touch any code in my current company. The only reason I can still code is because I love it, started programming at about 11 years old, and still do it in my spare time. If it was "just a job" for me, then no doubt the skill would atrophy.
lr4444lr 2y ago
I think you're completely ignoring the reality of frauds. Jeff Atwood was writing about this over a decade ago with "FizzBuzz". There are many people who spend more effort creating the illusion of competence on paper and on the job, getting harder to detect the higher they go. We as a profession (software engineers) have continually resisted broad unified certification like other engineers which could be a replacement for code interviews to assess competence, but would have other drawbacks. So we are stuck with code interviews to ferret out BSers. And even then it sometimes fails. But it appears to be the best tool we have, because there is nowhere to hide. Don't take ot so personally.
- andai 2y ago
  >even then it sometimes fails How can a code interview fail? Hidden earpiece?
  - lr4444lr 2y ago
    People spending inordinate amounts of time memorizing solutions to common problems. This is admittedly partly the fault of HR not ensuring that interviewers have a good pool of problems to choose from and twists to put on things, but it's a constant cat and mouse game with various websites aggregating interview questions from companies.
    - tsukikage 2y ago
      It's pretty easy to spot when the candidate goes from canned answer to actually having to think. "Thank you, that looks good; now I need it to also do this extra thing" - keep tweaking the question until they have to think.
  - com 2y ago
    I’ve had reports of Zoom interview where an earpiece has fallen out and my interviewers heard advice on how to answer the question audibly present. Kind of dumb, how hard is mixing the audio?
  - jnwatson 2y ago
gigel82 2y ago
There are very few options outside of coding interviews, and getting fewer by the day. It's almost like everyone big and small is standardizing on this model. Feels like one of those mandatory courses you took in college: the teacher and all the students knew it was bullshit yet you needed to perform the parroting at some adequate level to pass. I have 21 years of varied experience in software engineering, yet a recent "technical" phone interview was a kid asking me to "balance a B-tree"; I can tell his expectation was for me to start reciting some CS algorithm BS, probably that's what everyone else is doing. I politely declined and that was the end of the interviewing process with that company.
LargeWu 2y ago
Hard disagree. On my teams, we're going to give you a problem with some slight ambiguities to see how you handle that. We're going to see what kinds of questions you ask and how you respond to feedback. We want to hear you walk through your thought process. The more senior the position, the more important all of this becomes. Getting the "correct" solution is, at best, 50% of the goal with the interview.
- zamalek 2y ago
  This is not the approach that the majority of coding interviews take. In my experience, it has been disinterested interviewers who are blatantly pretending to understand what they are asking. Any attempt to engage in the type of discussion you aim for is met with dead ends, because that's not what the Googled answer contains. Your approach is a major outlier. You probably have many good candidates turning away, and for good reason, they have no idea that you are different to everyone else. Find a different way to do this, there are several other approaches.

willvarfar 2y ago

FWIW I always ask some really super simple coding questions in interviews, even for really senior people with apparently stellar CVs. Let them pick their language or use psuedocode or whatever. It's surprising how many 'senior' engineers are actually BSers who will slow you down or derail you completely rather than speed you up and you need to spot them because they will excel at getting through the non-technical interview filtering! Also, I'm interested in how you explore things and explain things. I'm not actually interested in acquiring an implementation of FizzBuzz or whatever. I just want you to show me that you 'get' it and then we can get on to the interesting stuff like 'tell me about your last project' etc. So don't be too hasty to think the people doing technical interviews are idiots thinking devs are interchangeable cogs etc.

OJFord 2y ago
> Also, I'm interested in how you explore things and explain things. I'm not actually interested in acquiring an implementation of FizzBuzz or whatever. I just want you to show me that you 'get' it and then we can get on to the interesting stuff like 'tell me about your last project' etc. Sounds like you'd more valuably/realistically get that from the discussion of a previous project though? How it works, or something interesting they had to figure out, etc.? > don't be too hasty to think the people doing technical interviews are idiots I don't think anyone has a problem with technical interviews? At least I agree that's not reasonable. That doesn't have to mean 'coding' though, you can ask about how they'd approach a particular problem, quiz on some fundamental knowledge in a fizzbuzz sort of way, etc. You can more easily tune it to the kind of candidate you're looking for then too, for example I've asked how they'd tackle improving the performance of a particular SQL query that's been identified as too slow. There's a tonne of possible answers to that ranging from naïve/they don't really know, through pragmatic good fit responses, to way overkill I hope they understand we don't need them doing that here/not operating at that scale etc. - and it's fairly open-ended in what you can discuss driven by what they volunteer and know about. (Which is another good thing IMO, I don't like being on either side of interviewer quizzing and candidate umming and ahhing not really knowing! Both more comfortable and more beneficial to have a discussion about whatever is known IMO; to quickly move along the perimeter if you hit the edge of that.)
- pavel_lishin 2y ago
  > Sounds like you'd more valuably/realistically get that from the discussion of a previous project though? How it works, or something interesting they had to figure out, etc.? You may be underestimating people's ability to bullshit their way through this sort of discussion. It's harder to bullshit your way past a blank file in a code editor. I'd wager that something like FizzBuzz will eliminate 90% of the chaff. Yes, it's laughably simple. No, it's not so simple that it won't stump a significant number of folks who've coasted for years.
  - around_here 2y ago
    FizzBuzz is an incredible filter for devs. Any kind of async JavaScript that needs to do something with the data after it fetches it has also been a winner. Lately the biggest weeding tool has been asking candidates to fetch some JSON from a bucket, then visualize that data. I'd say that maybe half the people manage to fetch the data in 30 minutes, and of that, maybe 10% get the data fetched within 10. The other 20 minutes is trying to help them recognize that their data is initially being rendered with "undefined" and they have to update the viz.

M4v3R 2y ago

I totally understand your point of view, but looking at it from the other side it’s not as simple. We had candidates with 10+ years of experience in their resume, talking to them it seemed they know what they’re doing, they showed some of the code they’ve supposedly written. Then they got hired and it turned out they can’t code - their PRs are below junior level, constant bugs, communication is abysmal, they overshoot their estimations by 3-4x, etc. Thus happened to us twice, and after we introduced a simple live coding session to our interviews where you have to implement a simple real world web component (for a frontend position) suddenly the problem of bad hires disappeared almost entirely (you can’t judge someone’s character during a short interview but that’s another issue).

mrweasel 2y ago
We recently interviewed a candidate, with 7 years of experience at a FAANG company, fail a really basic coding interview and we don't even make you write code. I have no idea what these people expect. We ask coding questions, we have basic programming skills as a requirement, what do they think will happen if they get the job? Do they expect to just magically learn the required skills or hope that nobody will notice that they're not able to close their tasks?
- vntok 2y ago
  > Do they expect to just magically learn the required skills or hope that nobody will notice that they're not able to close their tasks? It obviously worked for the candidate you mention, didn't it? Spent 7 years at FAANG, didn't know how to code.
  - mrweasel 2y ago
    That is true, but how?
    - azornathogron 2y ago
      There are lots of roles at big companies that don't involve actually writing code. The bigger the company, the more communication and organizational overhead there is, and the more not-actually-coding work there is. Even within roles that have a "software engineering" title. Hell, I barely touch any code in my current company. The only reason I can still code is because I love it, started programming at about 11 years old, and still do it in my spare time. If it was "just a job" for me, then no doubt the skill would atrophy.

lr4444lr 2y ago

I think you're completely ignoring the reality of frauds. Jeff Atwood was writing about this over a decade ago with "FizzBuzz". There are many people who spend more effort creating the illusion of competence on paper and on the job, getting harder to detect the higher they go. We as a profession (software engineers) have continually resisted broad unified certification like other engineers which could be a replacement for code interviews to assess competence, but would have other drawbacks. So we are stuck with code interviews to ferret out BSers. And even then it sometimes fails. But it appears to be the best tool we have, because there is nowhere to hide. Don't take ot so personally.

andai 2y ago
>even then it sometimes fails How can a code interview fail? Hidden earpiece?
- lr4444lr 2y ago
  People spending inordinate amounts of time memorizing solutions to common problems. This is admittedly partly the fault of HR not ensuring that interviewers have a good pool of problems to choose from and twists to put on things, but it's a constant cat and mouse game with various websites aggregating interview questions from companies.
  - tsukikage 2y ago
    It's pretty easy to spot when the candidate goes from canned answer to actually having to think. "Thank you, that looks good; now I need it to also do this extra thing" - keep tweaking the question until they have to think.
- com 2y ago
  I’ve had reports of Zoom interview where an earpiece has fallen out and my interviewers heard advice on how to answer the question audibly present. Kind of dumb, how hard is mixing the audio?
- jnwatson 2y ago

gigel82 2y ago

There are very few options outside of coding interviews, and getting fewer by the day. It's almost like everyone big and small is standardizing on this model. Feels like one of those mandatory courses you took in college: the teacher and all the students knew it was bullshit yet you needed to perform the parroting at some adequate level to pass. I have 21 years of varied experience in software engineering, yet a recent "technical" phone interview was a kid asking me to "balance a B-tree"; I can tell his expectation was for me to start reciting some CS algorithm BS, probably that's what everyone else is doing. I politely declined and that was the end of the interviewing process with that company.

LargeWu 2y ago

Hard disagree. On my teams, we're going to give you a problem with some slight ambiguities to see how you handle that. We're going to see what kinds of questions you ask and how you respond to feedback. We want to hear you walk through your thought process. The more senior the position, the more important all of this becomes. Getting the "correct" solution is, at best, 50% of the goal with the interview.

zamalek 2y ago
This is not the approach that the majority of coding interviews take. In my experience, it has been disinterested interviewers who are blatantly pretending to understand what they are asking. Any attempt to engage in the type of discussion you aim for is met with dead ends, because that's not what the Googled answer contains. Your approach is a major outlier. You probably have many good candidates turning away, and for good reason, they have no idea that you are different to everyone else. Find a different way to do this, there are several other approaches.