8 ms·

Absolutely untrue. Whiteboard problems absolutely do work. The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at

Absolutely untrue. Whiteboard problems absolutely do work. The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list. Worse is that these guys can be employed as developers (even 'senior' ones!) for years and years in 'serious' enterprises. How, you ask? By using copy-paste and cleverly navigating their enterprise processes and dodging responsibility. Maybe this is what you mean by 'being good at working with others', but it's definitely not what I want in a software developer. Source: I've interviewed a great deal of people for lots of positions over the years.

maehwasu 7y ago
+1. I’ve interviewed senior guys, with medium to high salaries, who couldn’t do fizzbuzz. What’s worse, a lot of them were fully confident in awful solutions, and didn’t even want to test them. Talented people frustrated at the process just don’t get how bad bad coders are. I would never have believed it myself until I experienced it.
- aetherson 7y ago
  I used to give a whiteboard coding interview (for a QA engineer position) that started with "swap the values of two integer variables. Yes, you can use a temporary variable," then went on to find the highest element in an array, then implement any kind of sort for an array, then implement depth-first-search. People who would ace the entire interview would look at me funny when I asked the first question, and I just said, "I mean, look: about 25% of the candidates fail this first question." Lots of others got partway through it. It is very true that you need to qualify someone's ability to write code at all. I think there's usually a lot less utility in some of the "clever" coding challenges that require you to remember some difficult-to-derive-from-first-principles data-structure or algorithm. But on the other hand, if we literally just give fizzbuzz to everyone, we'll eventually see people who have memorized fizzbuzz but can not create any other program. There's a real challenge to creating a coding problem that hits the sweet spot between "doesn't just test that you had a particular intuition," "does actually test real coding skills" and "isn't so common that people have memorized the solution."
  - cr0sh 7y ago
    The best coding challenge for a hiring process I ever had happened, of all places, when I applied for a PHP development position at Fender. At the time, their marketing department did all of their web development in-house. I don't recall all the specifics; there was a round table meeting between the manager of the unit, the team lead, and one of the senior developers. At the end of it, they sat me in the cubicle area with their other developers, gave me an MBP with MAMP on it, and a piece of paper outlining what they wanted me to code - a simple CRUD app. It didn't have to have any fancy styling, but it had to look ok, and it had to work. It was "open book" otherwise; use google or whatever other resource as you needed it. Also, all this happened while the other devs were in the area; it was basically a time slot from 2:30pm to closing time... I'm thinking - really? Something this basic... But given what you had to do - essentially from a blank slate, including the database, set up the tables, build the SQL, code the PHP, integrate the form to talk to the PHP "backend" and update things, refresh and show the updates, etc... ...well, isn't that basically what most software dev work is, at the core? And if you can't do any of that... Of course I got the position, and worked there for a couple of years; not the easiest environment I've ever been in, but certainly very interesting. During it, though, I got to experience, from the "other side" what I went through - and I was amazed and dismayed to see how many people were interviewed who couldn't do it. Who had what seemed like great resumes who couldn't even start. Who'd sit there for 2+ hours, and not type a thing. Who didn't even google up something, or ask a question, or... We had one guy sit for a while, then just got up and walked out without a word. As I read comments like yours, and others elsewhere, I can see that this is more common than not. You are right to believe that there will be those that will "memorize" fizzbuzz, which I why I think a challenge similar to what Fender asked for is a better test. I know that some developers would balk at it, but I think the time invested may be worth it, to show you are able to do the job, and can come up with your own solution to a problem, and not just some regurgitated answer. Interesting aside: A colleague of mine I had worked with prior, unknown to me, applied for the same position at Fender and was given the same laptop as I did. But they had forgotten to wipe it! He saw my code, and didn't know if he was supposed to expand on it or what; he told them "hey, this looks like my friend's code...?" - and they realized what they forgot. They thanked him for his honesty, wiped it, and continued on with the process. He also ended up getting the position as well.
  - 7y ago
- frigfog 7y ago
  What do you mean by Fizzbuzz? Normal fizzbuzz or the pointless overengineering fizzbuzz?
- theWheez 7y ago
  This is incredible to me. How can one get to senior or middle software engineering positions without the ability to write such trivial code?
  - maehwasu 7y ago
    It was incredible to me too. But it’s reality. As another poster said above, best guess is some version of copypasta and navigation of bureaucracy.
  - 0x8BADF00D 7y ago
    TechLead said it best IMO. If a developer cannot understand basic concepts like recursion, then they are in the wrong industry.
  - cr0sh 7y ago
    It does seem incredible, but it happens. One place I worked at, the company hired a developer who claimed to have a CompSci masters. He was completely unable to code anything. I thought it strange. I started to ask him some basic questions that any actual CompSci degree holder should be able to answer (and I don't have a degree in CompSci at all - everything I know I've learned on my own, from other sources, for the most part); I didn't make it like a grilling session, just polite conversation about a shared interest - but he either had difficulty, or couldn't answer at all. He only stuck around a couple of weeks. I've often joked that an interview question should be asked akin to "What basic logic function is needed to implement a computer? Show it's truth table, then design one in 2-dimensions on a whiteboard as a virtual 'rope-and-pulley' system." Couple that with a random-style fizzbuzz-like challenge, and maybe a more difficult open-ended programming challenge (ie "build a simple CRUD app") - that would give you a good idea on their real skills. Note: That first question I wouldn't expect many to be able to pass the last part; even the first two parts many perfectly capable developers would have difficulty with. But I would be disappointed if they claimed to have a CS degree and weren't able to at least tell me what it was and the truth table for it.
    - falsedan 7y ago
      shit, I'd have to look up NAND gates. also: that's EE, not CS.
- erik_seaberg 7y ago
  Are there a lot of senior people who don't interview? Fortunately most of my candidates have been at least marginal, but the first couple of useless ones years ago were all it took to convince me that we can't ever skip coding questions.
MentallyRetired 7y ago
My frustration is that this is the only industry I know of that makes you perform a pre-hiring test. Can you imagine if a construction worker had 1 hour to assemble a dog house as proof that he can build?
suzzer99 7y ago
The problem is there are a lot of people who are still good coders who suck at white-boarding for one reason or another. I became one of them due a combination of age, rustiness and an escalation of nervousness after failing a couple whiteboards out of the gate. Of course once I did land a job it took about a week to shake off the rustiness, and the company that hired me is thrilled. The point is that companies like Google and Facebook can afford to miss out on those devs. But smaller companies should be looking for diamonds in the rough, not trying to mimic the FAANGs and getting their leftovers.
- dantheman 7y ago
  You can offer a coding test - give them a computer, a piece of paper, etc. Let them sit a room by themselves, give them up to an hour to do a 15 minute problem. There are lots of ways to destress the coding interview, but the ability to code has to be tested.
  - beat 7y ago
    What if the job doesn't really involve coding? That's true of rather a lot of senior/lead level software engineering jobs. Security analysts, devops engineers, architects, and others may never write code at all as part of their jobs. As a senior devops engineer, I write a lot of trivial Groovy code for Jenkins pipelines. But the interesting part isn't the code, which for the most part a monkey could do. It's redesigning the release process. The rest is just implementation details. Thinking coding is important is a failure mode.
    - joshuamorton 7y ago
      FWIW, I'd refuse to work for a lead or architect who wasn't tested on their ability to write code (and in my current position, my manager, their manager, their manager, and their manager all have significant work as SWEs that I can see, or passed coding interviews). The thing that I find when conducting interviews is that people who have trouble writing a concrete solution to a problem often have trouble formalizing any solution. They can handwave stuff that maybe makes sense, and given enough good faith is "correct", or at least not obviously incorrect, but at the same time it depends on a whole suite of libraries that don't exist, or a domain specific language that someone would need to come up with, or something. And if you need to invent a DSL to parse a string, I'm worried about how complicated your actual solution would be when redesigning the release process. Because sure, any monkey can write some groovy code that does something. But I'm more worried about if that code will be well designed. Note, not the system, but the code itself. Because in reality the code defines the system, and a beautiful architecture implemented terribly is still terrible to work with. To see the second thing, I need to see concrete code.
Tade0 7y ago
There exist automated processes[0] that efficiently reject such candidates - no need to bother staff with doing the same manually. [0] https://www.codility.com/ https://www.codility.com/
- danesparza 7y ago
  Soo ... not sure if you read the article, but that's exactly what it was discussing.
  - StavrosK 7y ago
    The article is down.
- wuliwong 7y ago
  It's funny, the worst engineer I ever hired did great on our Codility tests. Maybe he just cheated, he actually scored higher than myself. Just a little anecdote but we no longer use Codility at my company. :)
deleted 7y ago
[deleted]
thorwasdfasdf 7y ago
> And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list. Seriously, Where are you finding these candidates? seriously. I've worked at a number of mid-sized companies, and interviewed dozens of candidates, and I have never, ever, ever come across a candidate that couldn't write code on this level: "write a function that adds two numbers or counts the number of elements in a list".
- pathseeker 7y ago
  It happens if you don't do phone screens. People lie on their resumes.
  - erik_seaberg 7y ago
    This. I can't trust your résumé at all, but it does tell me what you think should be reasonable to ask.
- rootusrootus 7y ago
  Crappy head hunters. I have some outside firms who have sent me good people very reliably, and then once in a while HR will make me try another company who probably gave us a cheap quote, and I'll get a series of terrible candidates from them. I've even been given outright frauds -- people who paid someone else to phone screen for them.
  - vidarh 7y ago
    Cut and paste answers to initial screening questions was my favorite. How I knew they were cut and pasted? I got paranoid after some suspicious answers and started doing searches for random lines from the answers. The included such brilliant things as cut and pasting an answer from a forum that was followed by a dozen comments of people explaining how wrong that answer was, and someone who answered what should have needed a short sentence with two pages from an Oracle manual giving an answer that did not apply to the question. . It's not that we expected everyone to be honest about not using Google - it didn't matter, it was an initial screening question. But we did expect them to at least bother to restate the answer in their own words if they looked it up. And get it right..
JohnFen 7y ago
> The vast majority of applicants cannot code at all. I've been interviewing devs for years, and this is not my experience at all. The vast majority of applicants that I've interviewed can code, although they tend to be minimally competent at it.
pathseeker 7y ago
You're probably using a different definition of "whiteboard problem" than is common for what is used a places like Google/Facebook/etc. I agree with you 100% if "whiteboard problem" means, sit with them while they type up a function in an IDE that does something common (e.g. validates a string, implements some error handling, do a failure backoff, etc). I disagree if it means, ask them to implement an algorithm on a whiteboard to steer a robot through a maze in a time with optimal algorithmic complexity. This is completely useless and the people that can do this have little overlap with people that can implement easy to read/debug code worthy of production and maintenance.
- cr0sh 7y ago
  > I disagree if it means, ask them to implement an algorithm on a whiteboard to steer a robot through a maze in a time with optimal algorithmic complexity. This is completely useless and the people that can do this have little overlap with people that can implement easy to read/debug code worthy of production and maintenance. From an interviewing perspective, asking someone to "solve" this kind of problem on a whiteboard would be interesting to see. One thing I'd tell them is to not worry about the code; that is, if they just want to write the process in pseudocode or something like that - as long as the logic can be followed, that would be ok. In other words, give them the leeway to not worry about proper coding, knowledge of functions, etc - but instead let them concentrate on the problem. I wouldn't expect anyone to solve such a question - but it would give a good insight into how they go about solving a problem. Do they ask questions? What happens when they get stuck? Can they explain their reasoning? And so forth. Let them do what they can, give them 30 minutes or so; if they look lost, ask them some questions, see how they respond, etc. I think such a question could be very valuable - if presented in the right way.
ApolloFortyNine 7y ago
The number of people I've had fail simple questions (not binary node problems, I mean problems where the optimal solution is basically a for loop with an if statement) is absolutely insane. I would say at least 50% of applicants fail to solve the coding question, and this is interviewing for a 100k+ US job in medium sized city (so low cost of living, and good salary for the area). We have 'hard' questions in our pool we can ask (where optimization actually comes into play) but I've found that the easy questions weed out so many candidates it's not worth it. There's no room for debate if someone tries to write 15+ if statements rather than creating a loop and one if statement.
b_t_s 7y ago
"The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list." I'm genuinely curious how you manage to find all these folks. I've been on the interview team at my company for a several years now(mostly in house, some first pass phone screens) and I've never encountered a single person who was literally unable to code a trivial problem. The last time I met a "programmer" who couldn't code was first semester university, and I thought most of them quickly flunked out/changed majors. I wonder if there is something about your company/recruiting process that is particularly attractive to them, or if our prescreen(which I'm admittedly no expert on) is just particularly good at filtering them out, or if there's some other explanation.
- jamiepenney 7y ago
  I've performed close to 400 screening interviews now for a range of companies. There's a good chunk of people that struggle to write a solution that correctly compiled to an "aggregate this data" style problem. People with the "correct" CV that have made it through the HR filter. It's a real problem.
- HelloNurse 7y ago
  There are people who overestimate their ability. For example, I've worked with a very junior programmer (too junior for a good whiteboarding performance) who took extensive notes about everything, appeared to learn quickly, was probably convinced that he was learning, but performed poorly because he failed to think enough. I saw him do SQL joins on the wrong column, cause accidents in source control, lose changes because he wasn't looking at the file and folder names on screen, and so on. Hard to realize for him, and hard to guess in an interview.
- drspacemonkey 7y ago
  I've also been doing interviews for a few years at three different companies, and I've encountered it. It depends heavily on the quality of the recruiter. Good recruiters will attempt to filter out complete duds, bad recruiters will pack a clown car full of "rockstar candidates" that just wasted my time. There was one particularly bad instance where a guy with 10 years of experience and a masters degree got stuck for an hour trying to write a for loop. With unfettered access to Google.
__jal 7y ago
Sounds like you don't phone screen. I've screened people like you describe, but the only time I've interviewed them face-to-face was when they didn't have a technical phone screen for whatever reason. FWIW, one of the ways I screen companies when I'm looking is whiteboard problems. I refuse them and move on. In my experience, only HugeCos and places with problems use them. I'm sure that's not true, but I have a necessarily small sample-size, and skipping over firms that do it has worked well for me so far, and there are plenty of fish in the sea. (I do in fact suck at writing on whiteboards, I just don't consider it a skill worth developing to pursue jobs I probably don't want.)
algoreithm 7y ago
FTFY: Absolutely untrue in my experience, I can't speak for other people. To imply that this is absolutely untrue in the global space would require that I have interviewed everyone. Whiteboard problems absolutely do work in my interviews. Again, use of the word absolute indicates that I've never interviewed without a whiteboard. Given the high number of candidates I've interviewed, this might indicate a flaw in the interview process. The vast majority of applicants I select for interviews cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list. I should consider the possibility that I'm selecting the wrong people for interviews. Worse is that these guys can be employed as developers (even 'senior' ones!) for years and years in 'serious' enterprises. Clearly other companies are making the same mistakes I am making in their candidate selection process. How, you ask? By using copy-paste and cleverly navigating their enterprise processes and dodging responsibility. Maybe this is what you mean by 'being good at working with others', but it's definitely not what I want in a software developer. Source: I've interviewed a great deal of poorly selected people for lots of positions over the years.
justfor1comment 7y ago
May be the company you hire for has a mediocre reputation. So that people with average programming skills don't mind applying. People are generally good at self sorting. At some level they must be thinking they can get this job and end up being surprised that all the rounds are not behavioral rounds.
wuliwong 7y ago
>Whiteboard problems absolutely do work. >The vast majority of applicants cannot code at all. You kinda set up a strawman here. If the purpose of the whiteboard problem was just to establish some very low baseline of coding ability then I doubt many people would argue about their effectiveness. But companies don't use whiteboard problems for that purpose. In my experience (on both sides of the table) they are given with increasing levels of difficulty to see how far the candidate can go. They do not simply ask a few basic questions like "how would you write a function that returned the sum of two numbers" or "count the number of elements in a given array." I'm not saying there is a really good answer to this. The best I've seen is that some people just seem to be good at hiring and others are not. I am one who is not. I am also a terrible interviewee. The whole process whigs me out.
drugme 7y ago
The vast majority of applicants cannot code at all. And I mean that literally. No, you mean that hyperbolically. Not only does it simply not happen that "the vast majority of applications cannot code at all" -- this literally has never happened at all, in my experience. What does happen is that you get a range of people on a spectrum. And yeah, a fair number of them can't code very well. They're slow, they don't see smart solutions, whatever - or are just plain sloppy. But that's quite different from "not being able to code at all." As to those people who (supposedly) can't "write a function that adds two numbers or counts the number of elements in a list" -- most likely they're simply freezing up from the anxiety of being whiteboarded by a perfect stranger for the first time in a great while - or perhaps ever. (In fact that's exactly what happened to me, on my very first on-site interview after college). Or that is to say: they haven't internalized -- and produced defenses for -- the (intentionally) awkward and humiliating ritual of the modern tech interview process. And again, you should only be actually seeing these people once in a blue moon. Unless the people running your incoming "pipeline" are utterly incompetent, and are constantly feeding you a stream of unqualified candidates. In which case your companies much bigger problem a lack of engineers who are able to "ace" HackerRank problems in 59 minutes or less.[1] [1] Which, lest be honest now -- basically can only happen after extensive time spent on practicing these problems in advance. Or that is, by blatantly gaming your hiring "filter". And one more thing: How, you ask? By ... dodging responsibility. No - their jobs just have different metrics for "responsibility" than yours. That's just the way many businesses are run, whether you like it or not.

maehwasu 7y ago

+1. I’ve interviewed senior guys, with medium to high salaries, who couldn’t do fizzbuzz. What’s worse, a lot of them were fully confident in awful solutions, and didn’t even want to test them. Talented people frustrated at the process just don’t get how bad bad coders are. I would never have believed it myself until I experienced it.

aetherson 7y ago
I used to give a whiteboard coding interview (for a QA engineer position) that started with "swap the values of two integer variables. Yes, you can use a temporary variable," then went on to find the highest element in an array, then implement any kind of sort for an array, then implement depth-first-search. People who would ace the entire interview would look at me funny when I asked the first question, and I just said, "I mean, look: about 25% of the candidates fail this first question." Lots of others got partway through it. It is very true that you need to qualify someone's ability to write code at all. I think there's usually a lot less utility in some of the "clever" coding challenges that require you to remember some difficult-to-derive-from-first-principles data-structure or algorithm. But on the other hand, if we literally just give fizzbuzz to everyone, we'll eventually see people who have memorized fizzbuzz but can not create any other program. There's a real challenge to creating a coding problem that hits the sweet spot between "doesn't just test that you had a particular intuition," "does actually test real coding skills" and "isn't so common that people have memorized the solution."
- cr0sh 7y ago
  The best coding challenge for a hiring process I ever had happened, of all places, when I applied for a PHP development position at Fender. At the time, their marketing department did all of their web development in-house. I don't recall all the specifics; there was a round table meeting between the manager of the unit, the team lead, and one of the senior developers. At the end of it, they sat me in the cubicle area with their other developers, gave me an MBP with MAMP on it, and a piece of paper outlining what they wanted me to code - a simple CRUD app. It didn't have to have any fancy styling, but it had to look ok, and it had to work. It was "open book" otherwise; use google or whatever other resource as you needed it. Also, all this happened while the other devs were in the area; it was basically a time slot from 2:30pm to closing time... I'm thinking - really? Something this basic... But given what you had to do - essentially from a blank slate, including the database, set up the tables, build the SQL, code the PHP, integrate the form to talk to the PHP "backend" and update things, refresh and show the updates, etc... ...well, isn't that basically what most software dev work is, at the core? And if you can't do any of that... Of course I got the position, and worked there for a couple of years; not the easiest environment I've ever been in, but certainly very interesting. During it, though, I got to experience, from the "other side" what I went through - and I was amazed and dismayed to see how many people were interviewed who couldn't do it. Who had what seemed like great resumes who couldn't even start. Who'd sit there for 2+ hours, and not type a thing. Who didn't even google up something, or ask a question, or... We had one guy sit for a while, then just got up and walked out without a word. As I read comments like yours, and others elsewhere, I can see that this is more common than not. You are right to believe that there will be those that will "memorize" fizzbuzz, which I why I think a challenge similar to what Fender asked for is a better test. I know that some developers would balk at it, but I think the time invested may be worth it, to show you are able to do the job, and can come up with your own solution to a problem, and not just some regurgitated answer. Interesting aside: A colleague of mine I had worked with prior, unknown to me, applied for the same position at Fender and was given the same laptop as I did. But they had forgotten to wipe it! He saw my code, and didn't know if he was supposed to expand on it or what; he told them "hey, this looks like my friend's code...?" - and they realized what they forgot. They thanked him for his honesty, wiped it, and continued on with the process. He also ended up getting the position as well.
- 7y ago
frigfog 7y ago
What do you mean by Fizzbuzz? Normal fizzbuzz or the pointless overengineering fizzbuzz?
theWheez 7y ago
This is incredible to me. How can one get to senior or middle software engineering positions without the ability to write such trivial code?
- maehwasu 7y ago
  It was incredible to me too. But it’s reality. As another poster said above, best guess is some version of copypasta and navigation of bureaucracy.
- 0x8BADF00D 7y ago
  TechLead said it best IMO. If a developer cannot understand basic concepts like recursion, then they are in the wrong industry.
- cr0sh 7y ago
  It does seem incredible, but it happens. One place I worked at, the company hired a developer who claimed to have a CompSci masters. He was completely unable to code anything. I thought it strange. I started to ask him some basic questions that any actual CompSci degree holder should be able to answer (and I don't have a degree in CompSci at all - everything I know I've learned on my own, from other sources, for the most part); I didn't make it like a grilling session, just polite conversation about a shared interest - but he either had difficulty, or couldn't answer at all. He only stuck around a couple of weeks. I've often joked that an interview question should be asked akin to "What basic logic function is needed to implement a computer? Show it's truth table, then design one in 2-dimensions on a whiteboard as a virtual 'rope-and-pulley' system." Couple that with a random-style fizzbuzz-like challenge, and maybe a more difficult open-ended programming challenge (ie "build a simple CRUD app") - that would give you a good idea on their real skills. Note: That first question I wouldn't expect many to be able to pass the last part; even the first two parts many perfectly capable developers would have difficulty with. But I would be disappointed if they claimed to have a CS degree and weren't able to at least tell me what it was and the truth table for it.
  - falsedan 7y ago
    shit, I'd have to look up NAND gates. also: that's EE, not CS.
erik_seaberg 7y ago
Are there a lot of senior people who don't interview? Fortunately most of my candidates have been at least marginal, but the first couple of useless ones years ago were all it took to convince me that we can't ever skip coding questions.

MentallyRetired 7y ago

My frustration is that this is the only industry I know of that makes you perform a pre-hiring test. Can you imagine if a construction worker had 1 hour to assemble a dog house as proof that he can build?

suzzer99 7y ago

The problem is there are a lot of people who are still good coders who suck at white-boarding for one reason or another. I became one of them due a combination of age, rustiness and an escalation of nervousness after failing a couple whiteboards out of the gate. Of course once I did land a job it took about a week to shake off the rustiness, and the company that hired me is thrilled. The point is that companies like Google and Facebook can afford to miss out on those devs. But smaller companies should be looking for diamonds in the rough, not trying to mimic the FAANGs and getting their leftovers.

dantheman 7y ago
You can offer a coding test - give them a computer, a piece of paper, etc. Let them sit a room by themselves, give them up to an hour to do a 15 minute problem. There are lots of ways to destress the coding interview, but the ability to code has to be tested.
- beat 7y ago
  What if the job doesn't really involve coding? That's true of rather a lot of senior/lead level software engineering jobs. Security analysts, devops engineers, architects, and others may never write code at all as part of their jobs. As a senior devops engineer, I write a lot of trivial Groovy code for Jenkins pipelines. But the interesting part isn't the code, which for the most part a monkey could do. It's redesigning the release process. The rest is just implementation details. Thinking coding is important is a failure mode.
  - joshuamorton 7y ago
    FWIW, I'd refuse to work for a lead or architect who wasn't tested on their ability to write code (and in my current position, my manager, their manager, their manager, and their manager all have significant work as SWEs that I can see, or passed coding interviews). The thing that I find when conducting interviews is that people who have trouble writing a concrete solution to a problem often have trouble formalizing any solution. They can handwave stuff that maybe makes sense, and given enough good faith is "correct", or at least not obviously incorrect, but at the same time it depends on a whole suite of libraries that don't exist, or a domain specific language that someone would need to come up with, or something. And if you need to invent a DSL to parse a string, I'm worried about how complicated your actual solution would be when redesigning the release process. Because sure, any monkey can write some groovy code that does something. But I'm more worried about if that code will be well designed. Note, not the system, but the code itself. Because in reality the code defines the system, and a beautiful architecture implemented terribly is still terrible to work with. To see the second thing, I need to see concrete code.

Tade0 7y ago

There exist automated processes[0] that efficiently reject such candidates - no need to bother staff with doing the same manually. [0] https://www.codility.com/ https://www.codility.com/

danesparza 7y ago
Soo ... not sure if you read the article, but that's exactly what it was discussing.
- StavrosK 7y ago
  The article is down.
wuliwong 7y ago
It's funny, the worst engineer I ever hired did great on our Codility tests. Maybe he just cheated, he actually scored higher than myself. Just a little anecdote but we no longer use Codility at my company. :)

deleted 7y ago

[deleted]

thorwasdfasdf 7y ago

> And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list. Seriously, Where are you finding these candidates? seriously. I've worked at a number of mid-sized companies, and interviewed dozens of candidates, and I have never, ever, ever come across a candidate that couldn't write code on this level: "write a function that adds two numbers or counts the number of elements in a list".

pathseeker 7y ago
It happens if you don't do phone screens. People lie on their resumes.
- erik_seaberg 7y ago
  This. I can't trust your résumé at all, but it does tell me what you think should be reasonable to ask.
rootusrootus 7y ago
Crappy head hunters. I have some outside firms who have sent me good people very reliably, and then once in a while HR will make me try another company who probably gave us a cheap quote, and I'll get a series of terrible candidates from them. I've even been given outright frauds -- people who paid someone else to phone screen for them.
- vidarh 7y ago
  Cut and paste answers to initial screening questions was my favorite. How I knew they were cut and pasted? I got paranoid after some suspicious answers and started doing searches for random lines from the answers. The included such brilliant things as cut and pasting an answer from a forum that was followed by a dozen comments of people explaining how wrong that answer was, and someone who answered what should have needed a short sentence with two pages from an Oracle manual giving an answer that did not apply to the question. . It's not that we expected everyone to be honest about not using Google - it didn't matter, it was an initial screening question. But we did expect them to at least bother to restate the answer in their own words if they looked it up. And get it right..

JohnFen 7y ago

> The vast majority of applicants cannot code at all. I've been interviewing devs for years, and this is not my experience at all. The vast majority of applicants that I've interviewed can code, although they tend to be minimally competent at it.

pathseeker 7y ago

You're probably using a different definition of "whiteboard problem" than is common for what is used a places like Google/Facebook/etc. I agree with you 100% if "whiteboard problem" means, sit with them while they type up a function in an IDE that does something common (e.g. validates a string, implements some error handling, do a failure backoff, etc). I disagree if it means, ask them to implement an algorithm on a whiteboard to steer a robot through a maze in a time with optimal algorithmic complexity. This is completely useless and the people that can do this have little overlap with people that can implement easy to read/debug code worthy of production and maintenance.

cr0sh 7y ago
> I disagree if it means, ask them to implement an algorithm on a whiteboard to steer a robot through a maze in a time with optimal algorithmic complexity. This is completely useless and the people that can do this have little overlap with people that can implement easy to read/debug code worthy of production and maintenance. From an interviewing perspective, asking someone to "solve" this kind of problem on a whiteboard would be interesting to see. One thing I'd tell them is to not worry about the code; that is, if they just want to write the process in pseudocode or something like that - as long as the logic can be followed, that would be ok. In other words, give them the leeway to not worry about proper coding, knowledge of functions, etc - but instead let them concentrate on the problem. I wouldn't expect anyone to solve such a question - but it would give a good insight into how they go about solving a problem. Do they ask questions? What happens when they get stuck? Can they explain their reasoning? And so forth. Let them do what they can, give them 30 minutes or so; if they look lost, ask them some questions, see how they respond, etc. I think such a question could be very valuable - if presented in the right way.

ApolloFortyNine 7y ago

The number of people I've had fail simple questions (not binary node problems, I mean problems where the optimal solution is basically a for loop with an if statement) is absolutely insane. I would say at least 50% of applicants fail to solve the coding question, and this is interviewing for a 100k+ US job in medium sized city (so low cost of living, and good salary for the area). We have 'hard' questions in our pool we can ask (where optimization actually comes into play) but I've found that the easy questions weed out so many candidates it's not worth it. There's no room for debate if someone tries to write 15+ if statements rather than creating a loop and one if statement.

b_t_s 7y ago

"The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list." I'm genuinely curious how you manage to find all these folks. I've been on the interview team at my company for a several years now(mostly in house, some first pass phone screens) and I've never encountered a single person who was literally unable to code a trivial problem. The last time I met a "programmer" who couldn't code was first semester university, and I thought most of them quickly flunked out/changed majors. I wonder if there is something about your company/recruiting process that is particularly attractive to them, or if our prescreen(which I'm admittedly no expert on) is just particularly good at filtering them out, or if there's some other explanation.

jamiepenney 7y ago
I've performed close to 400 screening interviews now for a range of companies. There's a good chunk of people that struggle to write a solution that correctly compiled to an "aggregate this data" style problem. People with the "correct" CV that have made it through the HR filter. It's a real problem.
HelloNurse 7y ago
There are people who overestimate their ability. For example, I've worked with a very junior programmer (too junior for a good whiteboarding performance) who took extensive notes about everything, appeared to learn quickly, was probably convinced that he was learning, but performed poorly because he failed to think enough. I saw him do SQL joins on the wrong column, cause accidents in source control, lose changes because he wasn't looking at the file and folder names on screen, and so on. Hard to realize for him, and hard to guess in an interview.
drspacemonkey 7y ago
I've also been doing interviews for a few years at three different companies, and I've encountered it. It depends heavily on the quality of the recruiter. Good recruiters will attempt to filter out complete duds, bad recruiters will pack a clown car full of "rockstar candidates" that just wasted my time. There was one particularly bad instance where a guy with 10 years of experience and a masters degree got stuck for an hour trying to write a for loop. With unfettered access to Google.

__jal 7y ago

Sounds like you don't phone screen. I've screened people like you describe, but the only time I've interviewed them face-to-face was when they didn't have a technical phone screen for whatever reason. FWIW, one of the ways I screen companies when I'm looking is whiteboard problems. I refuse them and move on. In my experience, only HugeCos and places with problems use them. I'm sure that's not true, but I have a necessarily small sample-size, and skipping over firms that do it has worked well for me so far, and there are plenty of fish in the sea. (I do in fact suck at writing on whiteboards, I just don't consider it a skill worth developing to pursue jobs I probably don't want.)

algoreithm 7y ago

FTFY: Absolutely untrue in my experience, I can't speak for other people. To imply that this is absolutely untrue in the global space would require that I have interviewed everyone. Whiteboard problems absolutely do work in my interviews. Again, use of the word absolute indicates that I've never interviewed without a whiteboard. Given the high number of candidates I've interviewed, this might indicate a flaw in the interview process. The vast majority of applicants I select for interviews cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list. I should consider the possibility that I'm selecting the wrong people for interviews. Worse is that these guys can be employed as developers (even 'senior' ones!) for years and years in 'serious' enterprises. Clearly other companies are making the same mistakes I am making in their candidate selection process. How, you ask? By using copy-paste and cleverly navigating their enterprise processes and dodging responsibility. Maybe this is what you mean by 'being good at working with others', but it's definitely not what I want in a software developer. Source: I've interviewed a great deal of poorly selected people for lots of positions over the years.

justfor1comment 7y ago

May be the company you hire for has a mediocre reputation. So that people with average programming skills don't mind applying. People are generally good at self sorting. At some level they must be thinking they can get this job and end up being surprised that all the rounds are not behavioral rounds.

wuliwong 7y ago

>Whiteboard problems absolutely do work. >The vast majority of applicants cannot code at all. You kinda set up a strawman here. If the purpose of the whiteboard problem was just to establish some very low baseline of coding ability then I doubt many people would argue about their effectiveness. But companies don't use whiteboard problems for that purpose. In my experience (on both sides of the table) they are given with increasing levels of difficulty to see how far the candidate can go. They do not simply ask a few basic questions like "how would you write a function that returned the sum of two numbers" or "count the number of elements in a given array." I'm not saying there is a really good answer to this. The best I've seen is that some people just seem to be good at hiring and others are not. I am one who is not. I am also a terrible interviewee. The whole process whigs me out.

drugme 7y ago

The vast majority of applicants cannot code at all. And I mean that literally. No, you mean that hyperbolically. Not only does it simply not happen that "the vast majority of applications cannot code at all" -- this literally has never happened at all, in my experience. What does happen is that you get a range of people on a spectrum. And yeah, a fair number of them can't code very well. They're slow, they don't see smart solutions, whatever - or are just plain sloppy. But that's quite different from "not being able to code at all." As to those people who (supposedly) can't "write a function that adds two numbers or counts the number of elements in a list" -- most likely they're simply freezing up from the anxiety of being whiteboarded by a perfect stranger for the first time in a great while - or perhaps ever. (In fact that's exactly what happened to me, on my very first on-site interview after college). Or that is to say: they haven't internalized -- and produced defenses for -- the (intentionally) awkward and humiliating ritual of the modern tech interview process. And again, you should only be actually seeing these people once in a blue moon. Unless the people running your incoming "pipeline" are utterly incompetent, and are constantly feeding you a stream of unqualified candidates. In which case your companies much bigger problem a lack of engineers who are able to "ace" HackerRank problems in 59 minutes or less.[1] [1] Which, lest be honest now -- basically can only happen after extensive time spent on practicing these problems in advance. Or that is, by blatantly gaming your hiring "filter". And one more thing: How, you ask? By ... dodging responsibility. No - their jobs just have different metrics for "responsibility" than yours. That's just the way many businesses are run, whether you like it or not.