15 ms·

Why Senior Engineers Hate Coding Interviews

36 points by vvern 6y ago

java-man 6y ago
All excellent points, happily ignored by every large company. Every time I come for an interview, I ask: did you check out my github? Only once in a while somebody responds with a yes. I mean, it's not a big deal - I just have a bunch of weekend projects there, nothing really outstanding, but it might give more information than any 15 minute coding quiz can give you. And, always the whiteboard coding... madness!
- pjmlp 6y ago
  Thing is, going through the github repository requires time, the whiteboard exercise they can pick anyone that happens to be idle just 5 minutes before the candidate arrives, just in time to print out the cv and being dragged into the interview room.
  - java-man 6y ago
    That's it. They are not really interested in getting the best (or competent) talent, they just need to follow a ritual. I mean, it's all explained better in the article, but focusing on competence: if they don't measure the competence [of a senior software engineer] they will not hire a competent engineer. And I've seen plenty of senior engineers who can produce reams and reams of awful, unmaintaineable, and buggy code. And, I am sure, they all aced the whiteboarding.
Serious_Cheese 6y ago
Agree that the system is broken. Not to defend the current interview system, but what other scalable solution do we have other than LeetCode type of questions? How would we be able to show that someone knows how to write code without testing them on the fundamentals of CS? Genuinely curious.
- Demonsult 6y ago
  It's not just testing fundamentals, it's testing who spent the most time on interview prep. Companies increase the difficulty level as more people do prep. That's become a cycle that favors those who have the most spare time. Senior engineers often have houses, kids and aging parents to take care of.
  - Google234 6y ago
    That doesn’t excuse hem forgetting what a priority queue is and when it’s appropriate to use one. The good senior engineers I know have a strong grasp of the fundamentals
    - giantg2 6y ago
      So you're saying LeetCode is only for screening seniors? What about entry level?
      - Google234 6y ago
        Where did I say that? Senior should have both fundamental coding and also more broad system design interviews.
    - Demonsult 6y ago
      You're hiring the candidate who happened to use one somewhat recently. The same candidate has completely forgotten other concepts and would have looked like a fool if questioned.
      - Google234 6y ago
        That’s why people do more than 1 interview. My example was just an example, I probably should have qualified it.
      - theamk 6y ago
        Requiring to implement a priority queue is harsh and no one should do this at the interviews. Asking "what is a priority queue" is a totally fair question (if your job may reasonably require it), because knowledge that such things exist is a big part of being a senior person. You don't have to be able to know the class name, or exact notation, but you should be able to know what to Google for. A person who does now know what a priority queue is will happily write O(n^2) algorithm which repeatedly calls max() and completely kill your app performance. There would be no opportunity to Google anything, because only senior people get business requirements, not names of algorithms they need to use.
iamleppert 6y ago
Anyone who says coding interviews don't work has never made the mistake of hiring someone who can't code. I've done it before -- someone who looks great on paper, interviews well but can't code their way out of a paper bag. I have no clue how or why they are in this industry, but I will never again let someone off the hook without demonstrating that they can code. I don't want to hire people who think coding is beneath them or are so far removed from the actual tech that they can't code anymore.
- PZ81JUXJE7uJ 6y ago
  Sure, yet how most interviews are done is bonkers.
- giantg2 6y ago
  I don't mind simple fizz-bang coding interviews. But some of the ones I've been to, for internal positions no less, have been absurd ambushes. I once had an interview for a front-end midlevel position. I had some prior front-end experience in another framework, but mostly worked on midteir and vendor products. I was notified the morning of my interview that it wasn't just a regular interview but a code screen and I could use any language/tools/etc that I wanted. I got there and found out that was not the case - he was not following HR's procedures. So he hands me a Mac (which I'm not familiar with), tells me to use Angular (which I've never used), in Webstorm (I played around with it once), and tells me to build a page to upload a CSV file and display the contents in a table on the page. I have 30 minutes to do it, and then I'll get 30 minutes to dress it up in CSS. Needless to say, I bombed it. I was sort of impressed with myself that I had it almost functional, but yet ashamed at my abysmal evaluation. He said I didn't do well and that he was looking for an expert. Shouldn't you open a senior posting if you want an expert? I asked him why he gave me an interview if my resume listed none of the technologies, with my cover letter stating that I was looking for a change and wanted to learn new technologies. His answer was that maybe I knew the tech from personal projects. I had Android personal projects listed on my resume, so why would I have left off other ones more pertainate to the position? My guess is he was too lazy to read and understand the resume and cover letter, not to mention ignoring HR's instructions. What a waste of both our time (moreso mine since he was on his laptop most of the time).
deleted 6y ago
[deleted]
makecheck 6y ago
The ones I truly hated were presented in some weird online not-a-real-text-editor format (unrealistic environment), and were also TIMED (unforgivable). I mean, I’m not sure what you’re assessing if you throw 4 different problems at me to complete in an hour using an editor I’ve never seen before (that may have bugs of its own). “Homework assignments” seem OK to me though; feel free to give me a few days in my environment of choice to produce quality work. Anything less is not a good benchmark.
- giantg2 6y ago
  I general agree that timed coding is not good. I had a similar experience. I don't know that take-home stuff is good either. It can allow some individuals to cheat.
  - giantg2 6y ago
    Why is this downvoted?
  - olnluis 6y ago
    I would say take homes are good, but not by themselves. Instead of spending an hour in front of the applicant trying to solve a problem, let them take the challenge home, and spend 15 minutes afterwards letting them explain their solutions. You'll fish out cheaters by questioning their work.
- AnimalMuppet 6y ago
  If your job is not either my only hope or my dream job, no, I'm not doing homework assignments that take a few days. I'm probably chasing several different places. 3 days homework times 10 places equals something that I do not have time in my life for. Nor am I going to make time for it to try to get into your company. You aren't that much better than anywhere else, so don't make it harder for me to get a job at your place.
hpoe 6y ago
I'll just throw out there that one reason I think coding interviews have some sort of value is because there are very few metrics to distinguish good engineers vs bad engineers when it comes to software engineering apart from working with them. For example someone was the lead Senior Engineer for 10 years at their previous company. Their biggest project was a rewrite and migration of the invoice handling system to optimize for data analysis leading the millions more in revenue. Based on this description I have no idea if this person a) Went to hundreds of meetings around priority, resources and timelines while other engineers did the actual work. While he went to the big wig meetings as the technical resources because he was trying to make optimal "architecture decisions" not because of talent but because his role as lead was built on having been with the company 10 years he knew how to navigate the internal politics as well as being an SME in the companies specific systems. or B) He was making major architectural decisions, leading the engineering team, mentoring other engineers, helping ensure best practices and trying to find time to squeeze coding in while trying to prevent the PMs and Execs from making the wrong decisions and getting the wrong ideas. The problem is these pieces of information can be hard to distinguish between based on the information that most people have access to during the hiring process. Now the looking at the github can be useful but if you are applying at a large organization a lot of the rules and processes are controlled not by the hiring manager but by HR who is trying to avoid anything that could lead to a lawsuit, so hiring managers have to try and navigate this field in a sub-optimal way.
Demonsult 6y ago
I wrote a "find the bugs" test that did a great job of selecting good senior engineers. No coding, just point out the mistakes in a series of short code snippets. Some bugs were simple and some were obscure corner cases.
- lsaferite 6y ago
  Seems like a much better test style to me. You could come prepared with cases from multiple languages and frameworks even.
- neverartful 6y ago
  I think these types of tests are pretty good, especially if there's a healthy mix of objective bugs and subjective warts. Not only does it easily allow the candidate to show what they know, it also opens the door for some discussion on the subjective parts.
- chillacy 6y ago
  This is a great exercise because code reviews are such a important part of the job.
eithed 6y ago
Recently I've been interviewing a bunch of programmers and most of them exhibited one pattern - while their code was good, when it came to edit it, in a f2f interview, they simply couldn't do it. They had access to googling the answer, they could ask questions and I tried to give hints to the answer. It's as if they didn't write it - it was most bizarre. So, no, will stick to the interviews as well.
- MeinBlutIstBlau 6y ago
  Wow that's crazy. I wouldn't mind being given interview like that. It's the hard math quiz whiteboards I'm petrified of. Not being able to access my notes is like telling me run shell commands on a cli program you've never used and you can't use --help or -man
  - eithed 6y ago
    Yeah, that's unrealistic - in the real world you have access to the internet, to your notes, to other people. As long as you can apply that knowledge, as long as you can show that "ok, here I want to use XYZ because of ABC", I think that's what matters.
- justinclift 6y ago
  Perhaps you've hit a run of people submitting dodgy or bogus work? One of the other commenters mentioned people doing phone screens who were clearly not the people in a f2f interview. So maybe it's something along those lines? eg: people who've not really written the code, then being asked to edit it... and boom, they're screwed. If you're having a run of people doing that though, it sounds like something about the way you're finding candidates needs adjusting. Maybe try through a different avenue?
zcw100 6y ago
Everyone wants to talk about the bad hire that can’t “program their way out of a paper bag but I want to talk about another kind of animal. The one who seems to know what their doing on all the coding tests. You hire him thinking he’s great. Gets right to work , cranks out a ton of code, is working weekends etc. Then you look at the code and it’s a crap ton of idiomatic garbage, seemingly clever hacks, etc. The rest of the teams productivity goes to shit because no one can understand Glen’s weird code. I worked with a guy who spent weeks writing a CSV parser. Firstly there are a ton of libraries to choose from. Secondly while CSV is simple it can be surprisingly difficult to handle all possible options. When we got a look at his code it was filled with really odd usage of reflections and dynamic code generation. This was supposed to process huge files so performance was supposed to be a priority. Or the other guy who complained daily about maven then one day he comes in on Monday right before a major deadline with a big shit eating grin on his face and when someone finally asked what he was grinning about he said he spent the weekend replacing maven with ant. I’ll take someone who can’t program their way out of a paper bag over one of these guys any day. At least when they’re in the paper bag they can’t destroy anything.
- dilyevsky 6y ago
  Do you not have coding style guidelines and code reviews? Unlike incompetence this behavior can be corrected easily.
- theamk 6y ago
  We've had a case like that in one of previous jobs. It was not very bad. The key is correct procedure. We've had required code reviews for every bit of code written. Those are always harder for the new people, but exactly how hard depends on the person. I have seen PR reviews which require major things like "let's refactor those changes into separate class with proper interfaces". And the good old "this code is too hard to understand, let's simplify" As for CSV story -- if you new people can go off for weeks and work on new project without talking to anyone, there is something wrong with your org. You want to have status meetings periodically (weekly? every sprint?) where everyone talks what they are working on, and what difficulties are they facing. Those are really great -- they let the team feel together, they let people whom to ask for help, and they may help discover hidden talents. And we did have people who would spend time doing integration with their favorite IDE's build system. It is not quite "maven vs ant" -- but if this helps them be more productive, why not! Of course this would be still optional, so other people would not have to use this, and it is up to them to maintain the integration.
BXLE_1-1-BitIs1 6y ago
Software engineers should be entitled to keep a copy of their code. This code can be presented to interviewers for subsequent positions. Interviewers can be allowed to review a hardcopy during the course of the interview, but can't keep it. If the hiring company wants to use the code, a license must be obtained from the employer who has copyright.
- neverartful 6y ago
  The tricky part of this approach is that many companies treat all of their software as a trade secret. These types of companies would likely object on these grounds. For code that isn't part of a trade secret, it's not a bad idea.

36 points by vvern 6y ago

All excellent points, happily ignored by every large company. Every time I come for an interview, I ask: did you check out my github? Only once in a while somebody responds with a yes. I mean, it's not a big deal - I just have a bunch of weekend projects there, nothing really outstanding, but it might give more information than any 15 minute coding quiz can give you. And, always the whiteboard coding... madness!

pjmlp 6y ago
Thing is, going through the github repository requires time, the whiteboard exercise they can pick anyone that happens to be idle just 5 minutes before the candidate arrives, just in time to print out the cv and being dragged into the interview room.
- java-man 6y ago
  That's it. They are not really interested in getting the best (or competent) talent, they just need to follow a ritual. I mean, it's all explained better in the article, but focusing on competence: if they don't measure the competence [of a senior software engineer] they will not hire a competent engineer. And I've seen plenty of senior engineers who can produce reams and reams of awful, unmaintaineable, and buggy code. And, I am sure, they all aced the whiteboarding.

Serious_Cheese 6y ago

Agree that the system is broken. Not to defend the current interview system, but what other scalable solution do we have other than LeetCode type of questions? How would we be able to show that someone knows how to write code without testing them on the fundamentals of CS? Genuinely curious.

Demonsult 6y ago
It's not just testing fundamentals, it's testing who spent the most time on interview prep. Companies increase the difficulty level as more people do prep. That's become a cycle that favors those who have the most spare time. Senior engineers often have houses, kids and aging parents to take care of.
- Google234 6y ago
  That doesn’t excuse hem forgetting what a priority queue is and when it’s appropriate to use one. The good senior engineers I know have a strong grasp of the fundamentals
  - giantg2 6y ago
    So you're saying LeetCode is only for screening seniors? What about entry level?
    - Google234 6y ago
      Where did I say that? Senior should have both fundamental coding and also more broad system design interviews.
  - Demonsult 6y ago
    You're hiring the candidate who happened to use one somewhat recently. The same candidate has completely forgotten other concepts and would have looked like a fool if questioned.
    - Google234 6y ago
      That’s why people do more than 1 interview. My example was just an example, I probably should have qualified it.
    - theamk 6y ago
      Requiring to implement a priority queue is harsh and no one should do this at the interviews. Asking "what is a priority queue" is a totally fair question (if your job may reasonably require it), because knowledge that such things exist is a big part of being a senior person. You don't have to be able to know the class name, or exact notation, but you should be able to know what to Google for. A person who does now know what a priority queue is will happily write O(n^2) algorithm which repeatedly calls max() and completely kill your app performance. There would be no opportunity to Google anything, because only senior people get business requirements, not names of algorithms they need to use.

iamleppert 6y ago

Anyone who says coding interviews don't work has never made the mistake of hiring someone who can't code. I've done it before -- someone who looks great on paper, interviews well but can't code their way out of a paper bag. I have no clue how or why they are in this industry, but I will never again let someone off the hook without demonstrating that they can code. I don't want to hire people who think coding is beneath them or are so far removed from the actual tech that they can't code anymore.

PZ81JUXJE7uJ 6y ago
Sure, yet how most interviews are done is bonkers.
giantg2 6y ago
I don't mind simple fizz-bang coding interviews. But some of the ones I've been to, for internal positions no less, have been absurd ambushes. I once had an interview for a front-end midlevel position. I had some prior front-end experience in another framework, but mostly worked on midteir and vendor products. I was notified the morning of my interview that it wasn't just a regular interview but a code screen and I could use any language/tools/etc that I wanted. I got there and found out that was not the case - he was not following HR's procedures. So he hands me a Mac (which I'm not familiar with), tells me to use Angular (which I've never used), in Webstorm (I played around with it once), and tells me to build a page to upload a CSV file and display the contents in a table on the page. I have 30 minutes to do it, and then I'll get 30 minutes to dress it up in CSS. Needless to say, I bombed it. I was sort of impressed with myself that I had it almost functional, but yet ashamed at my abysmal evaluation. He said I didn't do well and that he was looking for an expert. Shouldn't you open a senior posting if you want an expert? I asked him why he gave me an interview if my resume listed none of the technologies, with my cover letter stating that I was looking for a change and wanted to learn new technologies. His answer was that maybe I knew the tech from personal projects. I had Android personal projects listed on my resume, so why would I have left off other ones more pertainate to the position? My guess is he was too lazy to read and understand the resume and cover letter, not to mention ignoring HR's instructions. What a waste of both our time (moreso mine since he was on his laptop most of the time).

deleted 6y ago

[deleted]

makecheck 6y ago

The ones I truly hated were presented in some weird online not-a-real-text-editor format (unrealistic environment), and were also TIMED (unforgivable). I mean, I’m not sure what you’re assessing if you throw 4 different problems at me to complete in an hour using an editor I’ve never seen before (that may have bugs of its own). “Homework assignments” seem OK to me though; feel free to give me a few days in my environment of choice to produce quality work. Anything less is not a good benchmark.

giantg2 6y ago
I general agree that timed coding is not good. I had a similar experience. I don't know that take-home stuff is good either. It can allow some individuals to cheat.
- giantg2 6y ago
  Why is this downvoted?
- olnluis 6y ago
  I would say take homes are good, but not by themselves. Instead of spending an hour in front of the applicant trying to solve a problem, let them take the challenge home, and spend 15 minutes afterwards letting them explain their solutions. You'll fish out cheaters by questioning their work.
AnimalMuppet 6y ago
If your job is not either my only hope or my dream job, no, I'm not doing homework assignments that take a few days. I'm probably chasing several different places. 3 days homework times 10 places equals something that I do not have time in my life for. Nor am I going to make time for it to try to get into your company. You aren't that much better than anywhere else, so don't make it harder for me to get a job at your place.

hpoe 6y ago

I'll just throw out there that one reason I think coding interviews have some sort of value is because there are very few metrics to distinguish good engineers vs bad engineers when it comes to software engineering apart from working with them. For example someone was the lead Senior Engineer for 10 years at their previous company. Their biggest project was a rewrite and migration of the invoice handling system to optimize for data analysis leading the millions more in revenue. Based on this description I have no idea if this person a) Went to hundreds of meetings around priority, resources and timelines while other engineers did the actual work. While he went to the big wig meetings as the technical resources because he was trying to make optimal "architecture decisions" not because of talent but because his role as lead was built on having been with the company 10 years he knew how to navigate the internal politics as well as being an SME in the companies specific systems. or B) He was making major architectural decisions, leading the engineering team, mentoring other engineers, helping ensure best practices and trying to find time to squeeze coding in while trying to prevent the PMs and Execs from making the wrong decisions and getting the wrong ideas. The problem is these pieces of information can be hard to distinguish between based on the information that most people have access to during the hiring process. Now the looking at the github can be useful but if you are applying at a large organization a lot of the rules and processes are controlled not by the hiring manager but by HR who is trying to avoid anything that could lead to a lawsuit, so hiring managers have to try and navigate this field in a sub-optimal way.

Demonsult 6y ago

I wrote a "find the bugs" test that did a great job of selecting good senior engineers. No coding, just point out the mistakes in a series of short code snippets. Some bugs were simple and some were obscure corner cases.

lsaferite 6y ago
Seems like a much better test style to me. You could come prepared with cases from multiple languages and frameworks even.
neverartful 6y ago
I think these types of tests are pretty good, especially if there's a healthy mix of objective bugs and subjective warts. Not only does it easily allow the candidate to show what they know, it also opens the door for some discussion on the subjective parts.
chillacy 6y ago
This is a great exercise because code reviews are such a important part of the job.

eithed 6y ago

Recently I've been interviewing a bunch of programmers and most of them exhibited one pattern - while their code was good, when it came to edit it, in a f2f interview, they simply couldn't do it. They had access to googling the answer, they could ask questions and I tried to give hints to the answer. It's as if they didn't write it - it was most bizarre. So, no, will stick to the interviews as well.

MeinBlutIstBlau 6y ago
Wow that's crazy. I wouldn't mind being given interview like that. It's the hard math quiz whiteboards I'm petrified of. Not being able to access my notes is like telling me run shell commands on a cli program you've never used and you can't use --help or -man
- eithed 6y ago
  Yeah, that's unrealistic - in the real world you have access to the internet, to your notes, to other people. As long as you can apply that knowledge, as long as you can show that "ok, here I want to use XYZ because of ABC", I think that's what matters.
justinclift 6y ago
Perhaps you've hit a run of people submitting dodgy or bogus work? One of the other commenters mentioned people doing phone screens who were clearly not the people in a f2f interview. So maybe it's something along those lines? eg: people who've not really written the code, then being asked to edit it... and boom, they're screwed. If you're having a run of people doing that though, it sounds like something about the way you're finding candidates needs adjusting. Maybe try through a different avenue?

zcw100 6y ago

Everyone wants to talk about the bad hire that can’t “program their way out of a paper bag but I want to talk about another kind of animal. The one who seems to know what their doing on all the coding tests. You hire him thinking he’s great. Gets right to work , cranks out a ton of code, is working weekends etc. Then you look at the code and it’s a crap ton of idiomatic garbage, seemingly clever hacks, etc. The rest of the teams productivity goes to shit because no one can understand Glen’s weird code. I worked with a guy who spent weeks writing a CSV parser. Firstly there are a ton of libraries to choose from. Secondly while CSV is simple it can be surprisingly difficult to handle all possible options. When we got a look at his code it was filled with really odd usage of reflections and dynamic code generation. This was supposed to process huge files so performance was supposed to be a priority. Or the other guy who complained daily about maven then one day he comes in on Monday right before a major deadline with a big shit eating grin on his face and when someone finally asked what he was grinning about he said he spent the weekend replacing maven with ant. I’ll take someone who can’t program their way out of a paper bag over one of these guys any day. At least when they’re in the paper bag they can’t destroy anything.

dilyevsky 6y ago
Do you not have coding style guidelines and code reviews? Unlike incompetence this behavior can be corrected easily.
theamk 6y ago
We've had a case like that in one of previous jobs. It was not very bad. The key is correct procedure. We've had required code reviews for every bit of code written. Those are always harder for the new people, but exactly how hard depends on the person. I have seen PR reviews which require major things like "let's refactor those changes into separate class with proper interfaces". And the good old "this code is too hard to understand, let's simplify" As for CSV story -- if you new people can go off for weeks and work on new project without talking to anyone, there is something wrong with your org. You want to have status meetings periodically (weekly? every sprint?) where everyone talks what they are working on, and what difficulties are they facing. Those are really great -- they let the team feel together, they let people whom to ask for help, and they may help discover hidden talents. And we did have people who would spend time doing integration with their favorite IDE's build system. It is not quite "maven vs ant" -- but if this helps them be more productive, why not! Of course this would be still optional, so other people would not have to use this, and it is up to them to maintain the integration.

BXLE_1-1-BitIs1 6y ago

Software engineers should be entitled to keep a copy of their code. This code can be presented to interviewers for subsequent positions. Interviewers can be allowed to review a hardcopy during the course of the interview, but can't keep it. If the hiring company wants to use the code, a license must be obtained from the employer who has copyright.

neverartful 6y ago
The tricky part of this approach is that many companies treat all of their software as a trade secret. These types of companies would likely object on these grounds. For code that isn't part of a trade secret, it's not a bad idea.