I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
Yeah, coding challenges as part of the interview process are a huge red flag IMO. They show that either:
HR has more influence over the hiring process than the department that the interviewee will be working in and doesn't understand what the department actually needs.
or:
The management of the department itself doesn't actually understand how real-world development works.
Both are generally signs of endemic issues with how the company is managed that will cause other problems down the road.
Now, there is a realistic way you can do a coding-based interview. You give the interviewee a (properly isolated) real development system as they would be using, give them their choice of editor, let them use the internet and the documentation, give them an actual problem to solve instead of something that's better designed to test their understanding of their native language than their coding skills, and then (and this is the important part) watch them while the work through it.
The process is more important than the result in cases like this. I don't care if you can regurgitate a dozen variants of fizzbuzz in any of half a dozen languages. I care that you understand how to effectively utilize documentation and online resources to figure out the correct way to solve a problem.
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Could not agree more! This is the best way to see how they go about their work. The only problem is that this sometimes causes stress they are not used to and therefore do not show an accurate representation of their actual behavior.
fizzbuzz
And yes, what's up with that? I see that a lot recently. What happened to good 'ol foobar?
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
And yes, what's up with that? I see that a lot recently. What happened to good 'ol fooba
Fizzbuzz is a general class of coding challenges that's pretty popular because it's a) easy to understand, b) trivial to verify without even needing to run the code, and c) actually shows some basic understanding of the language in question (namely control flow and IO) while still managing to be completely useless otherwise.
The general form of the problem statement is:
Write a program that iterates over a sequence of numbers (possibly a fixed sequence, but usually taken as input) and:
If the number is a multiple of X print 'fizz'
If the number is a multiple of Y print 'buzz'
If the number is a multiple of both X and Y print 'fizzbuzz'
I actually remember when that trend started. It precipitated off an article that made the rounds on LinkedIn many years ago, about hirees who could not actually code, but could fake their way through the interview.
The author made the point that you should at minimum verify the applicant's claimed skills with something that would be trivial to write during any interview, such as a fizz-buzz.
Unfortunately, as with Ben Franklin and Daylight Savings Time, the idea was taken too literally! Hiring managers took the suggestion and ran with it, implementing literal fizz-buzz challenges in interviews, contrary to the author's actual point.
So, disaster #1: Non-coders learned how to fizz-buzz, so as to fool interviewers.
Many other hiring managers did get the point, and came up with unique, simple challenges that could fit within the interview. Unfortunately, this part of the disaster was on the would-be applicants. Modern code golfing was born, obstensibly to help programmers prep for interviews, but...
**Disaster #2: Code golfing sites inadvertently nullified the point of the coding challenges.
Unaware that their weeding technique was now pointless, companies started formalizing code golfing challenges and offloading them to the front of the process, to save time during interviews. The same sites that allowed anyone to practice these challenges saw an opportunity to cash in at the expense of companies.
Disaster #3: The process devolved from something useful to an exercise in futility that screened nothing, and ultimately helped no one (except the fakers).
The trend was now firmly established, and no one seemed to remember the original point. Fizz-buzzing and code golfing became a normal part of the fake programmer's acting repertoire.
Separate from my other response in this thread, I want to add something...
Yeah, coding challenges as part of the interview process are a huge red flag IMO.
I think code golfing challenges specifically are the red flag. I find it helpful if a company has some coding "challenge" task, either before or during the interview, which is (a) unique to them, and (b) reflects the work you'll actually be doing.
As an applicant, this helped me twice to realize I didn't have the experience for the job I was applying for! The coding challenges in both cases used the technology the job required, in a manner similar to how I'd be using it on the job. I was able to save myself and the hiring manager a few hours of effort, through those challenges alone.
A good coding challenge can be a real asset (as I comment separately). A bad one, including ALL code golfing challenges, is useless at best.
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
Agreed. I was definitely being a bit over-generic in my statement there. If done right, a coding challenge can be a good part of the screening process. The problem is that most places don't do them right.
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Interesting. What do you think about having the candidate look into the used codebase and explain the process of understanding what is going on?
I assume it depends on various factors if that is suitable, but I had the chance of trying that out and found it had an excellent side effect: you basically get a code review from an external view. This can be a win as the existing team tends to create a "bubble" and inconsistencies, missing docblocks etc become more apparent. At the same time, you gain a pretty solid understanding of the candidates ability to "pick up work"
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
If it's a case where you can do that without needing multiple layers of NDA's just for the interview, then yes, I think that's a good option as well. It's kind of dependent though on how close to BCP for whatever language/platform you're using you are, as being too far just makes it too difficult for the candidate to pick up anything.
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Sure, and there's probably an even longer list of cases where it's also not appropriate neither of us are thinking about. That is what I implied when I said it probably isn't a possibility in many cases.
It certainly makes sense for a team around an open source project to relate screening challenges to the existing code base! That can be an amazing technique...as y'all said, if done right.
There is a fundamental difference between reading/explaining code and writing code, though, and that should be accounted for. I've met plenty of people who could do one, but not the other.
And then you have the companies whose code base is already a horrific pile of spaghetti, and showing any of their code in an interview would reasonably send candidates screaming into the night. ;) Or do you ask then: how do we make this function better?
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Yeah, coding challenges as part of the interview process are a huge red flag IMO. They show that either:
or:
Both are generally signs of endemic issues with how the company is managed that will cause other problems down the road.
Now, there is a realistic way you can do a coding-based interview. You give the interviewee a (properly isolated) real development system as they would be using, give them their choice of editor, let them use the internet and the documentation, give them an actual problem to solve instead of something that's better designed to test their understanding of their native language than their coding skills, and then (and this is the important part) watch them while the work through it.
The process is more important than the result in cases like this. I don't care if you can regurgitate a dozen variants of fizzbuzz in any of half a dozen languages. I care that you understand how to effectively utilize documentation and online resources to figure out the correct way to solve a problem.
Could not agree more! This is the best way to see how they go about their work. The only problem is that this sometimes causes stress they are not used to and therefore do not show an accurate representation of their actual behavior.
And yes, what's up with that? I see that a lot recently. What happened to good 'ol foobar?
Fizzbuzz is a general class of coding challenges that's pretty popular because it's a) easy to understand, b) trivial to verify without even needing to run the code, and c) actually shows some basic understanding of the language in question (namely control flow and IO) while still managing to be completely useless otherwise.
The general form of the problem statement is:
Write a program that iterates over a sequence of numbers (possibly a fixed sequence, but usually taken as input) and:
I actually remember when that trend started. It precipitated off an article that made the rounds on LinkedIn many years ago, about hirees who could not actually code, but could fake their way through the interview.
The author made the point that you should at minimum verify the applicant's claimed skills with something that would be trivial to write during any interview, such as a fizz-buzz.
Unfortunately, as with Ben Franklin and Daylight Savings Time, the idea was taken too literally! Hiring managers took the suggestion and ran with it, implementing literal fizz-buzz challenges in interviews, contrary to the author's actual point.
So, disaster #1: Non-coders learned how to fizz-buzz, so as to fool interviewers.
Many other hiring managers did get the point, and came up with unique, simple challenges that could fit within the interview. Unfortunately, this part of the disaster was on the would-be applicants. Modern code golfing was born, obstensibly to help programmers prep for interviews, but...
**Disaster #2: Code golfing sites inadvertently nullified the point of the coding challenges.
Unaware that their weeding technique was now pointless, companies started formalizing code golfing challenges and offloading them to the front of the process, to save time during interviews. The same sites that allowed anyone to practice these challenges saw an opportunity to cash in at the expense of companies.
Disaster #3: The process devolved from something useful to an exercise in futility that screened nothing, and ultimately helped no one (except the fakers).
The trend was now firmly established, and no one seemed to remember the original point. Fizz-buzzing and code golfing became a normal part of the fake programmer's acting repertoire.
Separate from my other response in this thread, I want to add something...
I think code golfing challenges specifically are the red flag. I find it helpful if a company has some coding "challenge" task, either before or during the interview, which is (a) unique to them, and (b) reflects the work you'll actually be doing.
As an applicant, this helped me twice to realize I didn't have the experience for the job I was applying for! The coding challenges in both cases used the technology the job required, in a manner similar to how I'd be using it on the job. I was able to save myself and the hiring manager a few hours of effort, through those challenges alone.
A good coding challenge can be a real asset (as I comment separately). A bad one, including ALL code golfing challenges, is useless at best.
Agreed. I was definitely being a bit over-generic in my statement there. If done right, a coding challenge can be a good part of the screening process. The problem is that most places don't do them right.
Interesting. What do you think about having the candidate look into the used codebase and explain the process of understanding what is going on?
I assume it depends on various factors if that is suitable, but I had the chance of trying that out and found it had an excellent side effect: you basically get a code review from an external view. This can be a win as the existing team tends to create a "bubble" and inconsistencies, missing docblocks etc become more apparent. At the same time, you gain a pretty solid understanding of the candidates ability to "pick up work"
If it's a case where you can do that without needing multiple layers of NDA's just for the interview, then yes, I think that's a good option as well. It's kind of dependent though on how close to BCP for whatever language/platform you're using you are, as being too far just makes it too difficult for the candidate to pick up anything.
Sure, and there's probably an even longer list of cases where it's also not appropriate neither of us are thinking about. That is what I implied when I said it probably isn't a possibility in many cases.
It certainly makes sense for a team around an open source project to relate screening challenges to the existing code base! That can be an amazing technique...as y'all said, if done right.
There is a fundamental difference between reading/explaining code and writing code, though, and that should be accounted for. I've met plenty of people who could do one, but not the other.
And then you have the companies whose code base is already a horrific pile of spaghetti, and showing any of their code in an interview would reasonably send candidates screaming into the night. ;) Or do you ask then: how do we make this function better?
Lol. Yes, but my point is: then that company needs such feedback.
True. So I guess you want to see both capabilities.