8 ms·

I've interviewed hundreds of programmers, and really, you cannot trust pretty much anyone. There's so many people that think they can code, or just say they do

by juancn 5y ago

I've interviewed hundreds of programmers, and really, you cannot trust pretty much anyone. There's so many people that think they can code, or just say they do that really don't, that some sort of basic coding test is necessary if the job requires it. Our hiring rate for some roles is 200:1, but we pay handsomely for those. Think it the other way around, interviews are a two way process, you're also interviewing the company, and the way they conduct the interviews, in many ways also tells you what they value. What they're like. Take it as an opportunity to get to know each other. Bring this up in a constructive manner. It may make all the difference and provide a stronger signal to both of you, you learn how do they react to feedback and at the same time you show that you're capable of critical thinking and care enough about your craft to call bullshit when you see it.

maybenotafart 5y ago
yeah I just dont get why we have to make the coding exercises algorithmic. I care more about like, do I have to hold your hand or not? no I dont. Okay we are cool.
- hocuspocus 5y ago
  I'm not a fan of leetcode questions on a whiteboard, and I personally don't ask those. However for an online automated assessment, provided the question is reasonably time-boxed and not too crazy, I think that's fine, on both side of the interviews.
  - xtracto 5y ago
    The questions available at CodeWars page seem the best for me: They are no "gotcha," algorithmic questions (except the higher level ones) and they allow for a good amount of problem solving. The ones at LeerCode are asinine... oh, you dont remember Dynamic programming? Tough luck. Even if you really wont use it at all.
- juancn 5y ago
  It has to be simple, not too hard. That first test is basically a screening. Will I invest an engineer's hour to try to figure you out? Then, if you get to a whiteboard challenge, in those the end result is not usually what matters, but the process of problem solving is what you typically look for. Can we communicate effectively? Will you thrive here?
commandlinefan 5y ago
If those tests actually filtered out incompetent programmers, I'd say they were great, but my experience is that they all test very shallow knowledge that doesn't relate to ability to produce software that performs under load. If you could come up with such a test, it ought to just be used as a standard for everybody to take. And yes, as unpopular an opinion as it is around here, I'd love to see a "bar exam"/licensing board for software developers.
- juancn 5y ago
  I mean, you don't need a really hard test to weed out most hacks. In any case, if the test is hard, companies that know their shit in hiring, care more about how you approach it than what the end result is. In the end, the interview tries to figure out how it's like to work with you. Do we get along? Can we communicate effectively? Will you be happy and thrive here?
  - nouveaux 5y ago
    You sound like a great hiring manager/interviewer. However, I have read stories of people who got rejected only because they did not finish the coding challenge in time. The engineer reported that the candidate communicated well, but did not finish. Hiring manager rejects the candidate.
    - juancn 5y ago
      Yeah, there are bad employers and bad interviewers. Sometimes the importance of it is underplayed. I always drill others that interview duty is the most important thing you can do at a company (even though it sometimes feels like a chore). The people you help choose, influences culture and long term viability of the company. Take it seriously and be fair with candidates. Having said that, figuring out a fair and effective interview process is HARD. It requires constant tweaking and monitoring. Also, you have to start from a decent set of values at the company. For example, we do shadow interviews. When we certify interviewers, we have them come to watch and listen to an interview (we explain to the candidate beforehand what's going on), and then after the interview ends, we meet with the shadow interviewer and discuss what they picked up, and explain why I went such and such way, what I was looking for, why such and such mistake is not a big deal, and so on. After a couple of these, we have them interview, but with a certified interviewer shadowing them. Just observing (we have them practice on us their interview exercises if any before the interview). And the we give feedback, you rushed a bit here, give them more time to be at ease with you, did you notice such and such, whatever... If everything goes well, we certify them, and they can fly solo. We try to have a varied pool of interviewers to avoid biases. The downside is that you need to do more interviews as a candidate, to get a fair assessment (i.e. no single person can derail you). In the end, we've all been in a crappy interviews and try our best to not inflict that on other people.
starlust2 5y ago
I've recently had multiple candidates recently with inflated resumes. Not mere embellishments, but claiming advanced degrees in computer science when they can't solve a simple algorithmic problem (something that can be coded in <10 mins). I dislike most take home problems, especially longer ones. But there's few exceptions where I could move forward with a candidate who refuses a technical interview. In almost all cases it's egotistical and a glaring red flag.
- jstx1 5y ago
  > Not mere embellishments, but claiming advanced degrees in computer science when they can't solve a simple algorithmic problem (something that can be coded in <10 mins). I thought the second part of the sentence would be about how they don't actually have those degrees. If you say that you have the degree you have, that's not embellishing at all, and it doesn't mean that you'll be able to solve a coding problem. They're two separate things and you've kind of mixed them up. There's two questions - is the candidate outright providing false information (where they've worked or studied, how much experience they have and with what tools etc) - does the true information give you the wrong impression about the candidate i.e. you think someone with this degree or with that many years of experience should be capable of more than they are
  - starlust2 5y ago
    Ok I agree with your point that "embellishment" may not be the correct term and I really meant the latter. I 100% expect that someone with an advanced computer science degree can demonstrate they have problem solving ability. I don't really think that is an unreasonable assumption. I mean we're talking undergraduate level skills that are the bare minimum for an entry level position at my org. If it really is the case that an advanced computer science degree does not convey computer science knowledge then it reinforces the need for screening questions.
    - porker 5y ago
      > Ok I agree with your point that "embellishment" may not be the correct term and I really meant the latter. There's no 'may' involved. It is not the correct term. Here in the UK, embellishing your CV can be classed as 'fraud by false representation', which carries a maximum 10-year jail sentence.
grumple 5y ago
Stats from the experts show that even great engineers fail technical interviews [1]. Anecdotally: I've bombed interviews myself! Sometimes due to anxiety (a real problem for some of us), sometimes because the problem was difficult. So false negatives are very common. Especially if you are interviewing 200 people - you are wasting SO MUCH TIME. I simply can't believe that you're actually getting that 1 in 200 dev. Why? Because devs also pass interviews they have no business passing. You get a technical question that you already know the answer to and so you get through it easily (this has happened to me as well). I'd consider this a false positive. And today, I suspect this is just as likely as a false negative - we have many books on coding interview prep, probably hundreds of sites with coding problems to practice. Are you getting a good dev or are you getting someone that practiced 20 questions on the same subject last week so they happen to know exactly how to solve your interview problem? And the worst types of false positives are not ineptitude, in my opinion. I can make a mediocre dev (or a dev who is bad at algorithms) into an excellent dev. But there are a lot of devs who are very smart, but very lazy or toxic. And those people will sometimes impress you the most in interviews... because they have to do it a lot because they don't last. If anything, if the industry insists on technical coding challenges, we should stop the random bullshit and commit to a standardized exam and license. That's how other professions do it (and it works quite well with rare exceptions), and it would save software engineers a lot of time and headache, and make the hiring process smoother for everyone. Experience should count the most. How recently have they been coding. Look for signals like: they got promoted. Listen to them talk about things they worked on and find out how much detail they can give on those things. 1. https://medium.com/free-code-camp/you-will-randomly-bomb-technical-interviews-everyone-does-heres-the-data-44475806e32 https://medium.com/free-code-camp/you-will-randomly-bomb-tec...
- seba_dos1 5y ago
  > Listen to them talk about things they worked on and find out how much detail they can give on those things. This always stresses me out, not just in interviews (which are actually a bit easier since you try to prepare beforehand there, although I guess the anxiety and stress can cancel this out anyway) but also in everyday chit-chat with other devs. I strongly suspect that I may have ADHD and I'm just unable to randomly talk about things I've been doing even as recently as last week without preparation. I can recall a lot if I actually sit down and calmly trace back some stuff I've been doing years ago, but if I got surprised with a question like "you said in your CV that you used X at job A, what was the thing you liked the most about it?" it could take me the whole interview to just get into the mental state necessary to even recall my experiences with X, let alone put them into proper words. I'll eventually find a perfect answer, but chances are high that it will happen at evening under shower accompanied with a huge regret titled "I should have said that back then" :P
conductr 5y ago
> you cannot trust pretty much anyone. This. I hire financial analysts regularly and it's similar in that it requires a high degree of proficiency in Microsoft Excel. People consistently over many years of hiring absolutely do lie about their level of proficiency. Sometimes it's over confidence, ignorance, but often just a straight lie. So, we do Excel modeling similar to this. It's truly the only way to get a good gauge of where the individual is in their proficiency and how they approach modeling problems. I don't see a way of eliminating them, but to OP's point, I do try to make the tests generic (no industry/business knowledge required), open ended (allowing them to solve the problem however they want) and generally "good". We always tell folks taking the test, "it's not meant to be trick questions, if the instruction is confusing ask us for clarification" and afterwards we discuss "how do you think you performed?", "what did you think?" those kinds of things to try to iterate on any of the poorly constructed aspects we may be blind to.
- kragen 5y ago
  Is there a video demonstrating the kind of modeling you're talking about? The only thing I've seen that sounds similar was a Martin Shkreli video which is of course removed from YouTube now, and I don't know whether Shkreli was a beginner or an expert, just that he navigated Excel 20 times faster than I do.
  - conductr 5y ago
    There's some videos of high level skills if you search "excel modeling championship". Shkreli was a hedge fund/wall street guy if I remember correctly and probably has more of a banking background. That area of finance tends to be hyper competitive on Excel skills. I've heard stories of them banning mice from the office to force people to use keyboard shortcuts and what not. It's locker room braggadocious badge of honor in that world. But it's the type of application navigation that it sounds like you're describing. I on the other hand am in realm of corporate finance. Think CFOs, Controllers, and their teams. It's a bit more relaxed here but you still need enough skill to get the job done effectively. We don't really care how you get the job done (use a mouse, keyboard, google, it's all game) but you need a nice output and your approach in an interview context should convince me that you'd be capable of solving similar problems in the future. For that reason, I typically provide crappy raw data (oddly and inconsistently formatted) and ask them to build or analyze it. Given some fictional general ledger data; can they build a 3 statement model? Can they summarize some payroll data in a logical way? Build a budget scenario based on the following actual financial data... also, here are 5 basic features the model should incorporate. I don't typically watch them so I don't know how they navigate the application (I don't find it important) but we give a time limit and stop them at time and review work attempted. The highest skilled folks tend to finish within time. It's counter-intuitive but the worst thing for an analyst is to work at a company that has a great ERP/BI tools with reliable data, etc. It's only about 10% of companies that have their shit together in that regard and those analyst just run reports from XYZ GUI and never have to work with data. So they have low level of Excel skills but think they are great analysts. I've never actually experienced that world, but I know their analysts wouldn't cut it in the real world of crappy data and ad-hoc work. I've seen them crash and burn too many times and it's painful for the entire team. Back to your original point, as you might expect, most folks that are great at Excel just use it a lot to build complex things. They may have learned the keyboard shortcuts along the way; or not. It just takes practice and muscle memory will kick in but also requires regular practice to keep sharp at it. There's also some pretty decent tooling to help you step your game up if you wish. I personally like https://macabacus.com/ https://macabacus.com/
pxeger1 5y ago
> 200:1 Do you mean you hire 200 out of every 201 people? Or you hire 1 out of every 201 people?
- juancn 5y ago
  Source 200, hire 1. Many don't even get to basic screening,
geebee 5y ago
We've talked about this so many times on HN, and I've weighed in on this so many times. But it's an important enough topic that we should have the discussion again. You left undefined what you mean by "some sort of basic coding test". I have been screened out of jobs based on questions like "find all matching subtrees in a binary tree", or "find all sub matrices with positive determinants in an NXM matrix" (at the whiteboard, in 45 minutes). I don't think this is as much about critical thinking as you do. What limited feedback I got (from a recruiter, never the person who did the test) was "analysed the problem and sketched the solution well, but didn't make enough coding progress." Again, this was 45 minutes at the whiteboard in a day of getting shuttled from room to room for 5 hours of this. At least you didn't mention "programmers who can't write fizz buzz." I have never heard of anyone getting screened out because of fizz buzz. You may have seen it. But based on my experience, the coding problems are way, way harder than fizz buzz. Maybe you're doing things differently. If so, that's great, but I don't believe it's he norm at all. I'm also totally ok with you giving a difficult technical test that will weed out many competent programmers, as long as you don't pretend it isn't. I'll finish the way I always do - the alleged "shortage" or software developers in Silicon Valley is a product of rational market behavior among educated people who are free to choose a career according to market signals and their own personal interests. Re-taking your second year undergraduate data structures and algorithms exam is about as appetizing as retaking organic chemistry for the rest of your life for a physician, or retaking your partial differential equations exam is for an actuary. If free citizens don't want an employer's job in the numbers the employer thinks they should, even though the employer has decided it pays well, that's the market's answer. I see no need for the government to ask again on the employer's behalf.
- dennis_jeeves1 5y ago
  >You left undefined what you mean by "some sort of basic coding test". Yes, they never define it, because it's really hard work to clearly define what the bar is in terms of a know coding problem (like fizz-biz).
  - geebee 5y ago
    A precise definition in the abstract would be difficult. However, examples are still very useful. Typically, there's an initial easier screening followed by a much harder coding test. Rather than discuss them in the abstract, why not provide clear examples of each? For example, consider the difference between the three statements: You'd be amazed with how many candidates can't actually program. Like at all. vs. You'd be amazed with how many supposedly 'senior' programmers can't pass a very simple programming test. And even those who do can't handle relatively elementary data structures and algorithms once they get to the second round. vs. You'd be amazed how many supposedly 'senior' programmers can't code up fizz buzz or sum odd numbers from 1 to 100 in a loop. And even the ones who do can't search a binary of integers to see if it contains a particular value at a whiteboard in 45 minutes. The last one doesn't define what an easy and hard problem is in the abstract universal case, but it gives me a very good sense of who is and isn't failing these tests. Without that, the claim is relatively meaningless. Unfortunately, I actually think that many of these claims are deliberately left ambiguous. Many people who are claiming a shortage really don't want to be clear about why.
gdfgjhs 5y ago
I agree there are some very good fake programmers. And I haven't interviewed as many programmers, more like tens of them but I had good luck discussing the issues I was having at work. For example, I might tell them about a bug I am working on or even show code on my laptop. Good programmers actually wanted to solve the issue. Many solved or made useful suggestions. Fake programmers usually had pretty hard time, even had troubles verbalizing questions to ask. And sometime I turn tables and ask them what they are stuck at work and I try to help them. With good programmers, we had good discussion and sometimes actually solved their issues. Bad programmers never had any issues.

by juancn 5y ago

maybenotafart 5y ago

yeah I just dont get why we have to make the coding exercises algorithmic. I care more about like, do I have to hold your hand or not? no I dont. Okay we are cool.

hocuspocus 5y ago
I'm not a fan of leetcode questions on a whiteboard, and I personally don't ask those. However for an online automated assessment, provided the question is reasonably time-boxed and not too crazy, I think that's fine, on both side of the interviews.
- xtracto 5y ago
  The questions available at CodeWars page seem the best for me: They are no "gotcha," algorithmic questions (except the higher level ones) and they allow for a good amount of problem solving. The ones at LeerCode are asinine... oh, you dont remember Dynamic programming? Tough luck. Even if you really wont use it at all.
juancn 5y ago
It has to be simple, not too hard. That first test is basically a screening. Will I invest an engineer's hour to try to figure you out? Then, if you get to a whiteboard challenge, in those the end result is not usually what matters, but the process of problem solving is what you typically look for. Can we communicate effectively? Will you thrive here?

commandlinefan 5y ago

If those tests actually filtered out incompetent programmers, I'd say they were great, but my experience is that they all test very shallow knowledge that doesn't relate to ability to produce software that performs under load. If you could come up with such a test, it ought to just be used as a standard for everybody to take. And yes, as unpopular an opinion as it is around here, I'd love to see a "bar exam"/licensing board for software developers.

juancn 5y ago
I mean, you don't need a really hard test to weed out most hacks. In any case, if the test is hard, companies that know their shit in hiring, care more about how you approach it than what the end result is. In the end, the interview tries to figure out how it's like to work with you. Do we get along? Can we communicate effectively? Will you be happy and thrive here?
- nouveaux 5y ago
  You sound like a great hiring manager/interviewer. However, I have read stories of people who got rejected only because they did not finish the coding challenge in time. The engineer reported that the candidate communicated well, but did not finish. Hiring manager rejects the candidate.
  - juancn 5y ago
    Yeah, there are bad employers and bad interviewers. Sometimes the importance of it is underplayed. I always drill others that interview duty is the most important thing you can do at a company (even though it sometimes feels like a chore). The people you help choose, influences culture and long term viability of the company. Take it seriously and be fair with candidates. Having said that, figuring out a fair and effective interview process is HARD. It requires constant tweaking and monitoring. Also, you have to start from a decent set of values at the company. For example, we do shadow interviews. When we certify interviewers, we have them come to watch and listen to an interview (we explain to the candidate beforehand what's going on), and then after the interview ends, we meet with the shadow interviewer and discuss what they picked up, and explain why I went such and such way, what I was looking for, why such and such mistake is not a big deal, and so on. After a couple of these, we have them interview, but with a certified interviewer shadowing them. Just observing (we have them practice on us their interview exercises if any before the interview). And the we give feedback, you rushed a bit here, give them more time to be at ease with you, did you notice such and such, whatever... If everything goes well, we certify them, and they can fly solo. We try to have a varied pool of interviewers to avoid biases. The downside is that you need to do more interviews as a candidate, to get a fair assessment (i.e. no single person can derail you). In the end, we've all been in a crappy interviews and try our best to not inflict that on other people.

starlust2 5y ago

I've recently had multiple candidates recently with inflated resumes. Not mere embellishments, but claiming advanced degrees in computer science when they can't solve a simple algorithmic problem (something that can be coded in <10 mins). I dislike most take home problems, especially longer ones. But there's few exceptions where I could move forward with a candidate who refuses a technical interview. In almost all cases it's egotistical and a glaring red flag.

jstx1 5y ago
> Not mere embellishments, but claiming advanced degrees in computer science when they can't solve a simple algorithmic problem (something that can be coded in <10 mins). I thought the second part of the sentence would be about how they don't actually have those degrees. If you say that you have the degree you have, that's not embellishing at all, and it doesn't mean that you'll be able to solve a coding problem. They're two separate things and you've kind of mixed them up. There's two questions - is the candidate outright providing false information (where they've worked or studied, how much experience they have and with what tools etc) - does the true information give you the wrong impression about the candidate i.e. you think someone with this degree or with that many years of experience should be capable of more than they are
- starlust2 5y ago
  Ok I agree with your point that "embellishment" may not be the correct term and I really meant the latter. I 100% expect that someone with an advanced computer science degree can demonstrate they have problem solving ability. I don't really think that is an unreasonable assumption. I mean we're talking undergraduate level skills that are the bare minimum for an entry level position at my org. If it really is the case that an advanced computer science degree does not convey computer science knowledge then it reinforces the need for screening questions.
  - porker 5y ago
    > Ok I agree with your point that "embellishment" may not be the correct term and I really meant the latter. There's no 'may' involved. It is not the correct term. Here in the UK, embellishing your CV can be classed as 'fraud by false representation', which carries a maximum 10-year jail sentence.

grumple 5y ago

Stats from the experts show that even great engineers fail technical interviews [1]. Anecdotally: I've bombed interviews myself! Sometimes due to anxiety (a real problem for some of us), sometimes because the problem was difficult. So false negatives are very common. Especially if you are interviewing 200 people - you are wasting SO MUCH TIME. I simply can't believe that you're actually getting that 1 in 200 dev. Why? Because devs also pass interviews they have no business passing. You get a technical question that you already know the answer to and so you get through it easily (this has happened to me as well). I'd consider this a false positive. And today, I suspect this is just as likely as a false negative - we have many books on coding interview prep, probably hundreds of sites with coding problems to practice. Are you getting a good dev or are you getting someone that practiced 20 questions on the same subject last week so they happen to know exactly how to solve your interview problem? And the worst types of false positives are not ineptitude, in my opinion. I can make a mediocre dev (or a dev who is bad at algorithms) into an excellent dev. But there are a lot of devs who are very smart, but very lazy or toxic. And those people will sometimes impress you the most in interviews... because they have to do it a lot because they don't last. If anything, if the industry insists on technical coding challenges, we should stop the random bullshit and commit to a standardized exam and license. That's how other professions do it (and it works quite well with rare exceptions), and it would save software engineers a lot of time and headache, and make the hiring process smoother for everyone. Experience should count the most. How recently have they been coding. Look for signals like: they got promoted. Listen to them talk about things they worked on and find out how much detail they can give on those things. 1. https://medium.com/free-code-camp/you-will-randomly-bomb-technical-interviews-everyone-does-heres-the-data-44475806e32 https://medium.com/free-code-camp/you-will-randomly-bomb-tec...

seba_dos1 5y ago
> Listen to them talk about things they worked on and find out how much detail they can give on those things. This always stresses me out, not just in interviews (which are actually a bit easier since you try to prepare beforehand there, although I guess the anxiety and stress can cancel this out anyway) but also in everyday chit-chat with other devs. I strongly suspect that I may have ADHD and I'm just unable to randomly talk about things I've been doing even as recently as last week without preparation. I can recall a lot if I actually sit down and calmly trace back some stuff I've been doing years ago, but if I got surprised with a question like "you said in your CV that you used X at job A, what was the thing you liked the most about it?" it could take me the whole interview to just get into the mental state necessary to even recall my experiences with X, let alone put them into proper words. I'll eventually find a perfect answer, but chances are high that it will happen at evening under shower accompanied with a huge regret titled "I should have said that back then" :P

conductr 5y ago

> you cannot trust pretty much anyone. This. I hire financial analysts regularly and it's similar in that it requires a high degree of proficiency in Microsoft Excel. People consistently over many years of hiring absolutely do lie about their level of proficiency. Sometimes it's over confidence, ignorance, but often just a straight lie. So, we do Excel modeling similar to this. It's truly the only way to get a good gauge of where the individual is in their proficiency and how they approach modeling problems. I don't see a way of eliminating them, but to OP's point, I do try to make the tests generic (no industry/business knowledge required), open ended (allowing them to solve the problem however they want) and generally "good". We always tell folks taking the test, "it's not meant to be trick questions, if the instruction is confusing ask us for clarification" and afterwards we discuss "how do you think you performed?", "what did you think?" those kinds of things to try to iterate on any of the poorly constructed aspects we may be blind to.

kragen 5y ago
Is there a video demonstrating the kind of modeling you're talking about? The only thing I've seen that sounds similar was a Martin Shkreli video which is of course removed from YouTube now, and I don't know whether Shkreli was a beginner or an expert, just that he navigated Excel 20 times faster than I do.
- conductr 5y ago
  There's some videos of high level skills if you search "excel modeling championship". Shkreli was a hedge fund/wall street guy if I remember correctly and probably has more of a banking background. That area of finance tends to be hyper competitive on Excel skills. I've heard stories of them banning mice from the office to force people to use keyboard shortcuts and what not. It's locker room braggadocious badge of honor in that world. But it's the type of application navigation that it sounds like you're describing. I on the other hand am in realm of corporate finance. Think CFOs, Controllers, and their teams. It's a bit more relaxed here but you still need enough skill to get the job done effectively. We don't really care how you get the job done (use a mouse, keyboard, google, it's all game) but you need a nice output and your approach in an interview context should convince me that you'd be capable of solving similar problems in the future. For that reason, I typically provide crappy raw data (oddly and inconsistently formatted) and ask them to build or analyze it. Given some fictional general ledger data; can they build a 3 statement model? Can they summarize some payroll data in a logical way? Build a budget scenario based on the following actual financial data... also, here are 5 basic features the model should incorporate. I don't typically watch them so I don't know how they navigate the application (I don't find it important) but we give a time limit and stop them at time and review work attempted. The highest skilled folks tend to finish within time. It's counter-intuitive but the worst thing for an analyst is to work at a company that has a great ERP/BI tools with reliable data, etc. It's only about 10% of companies that have their shit together in that regard and those analyst just run reports from XYZ GUI and never have to work with data. So they have low level of Excel skills but think they are great analysts. I've never actually experienced that world, but I know their analysts wouldn't cut it in the real world of crappy data and ad-hoc work. I've seen them crash and burn too many times and it's painful for the entire team. Back to your original point, as you might expect, most folks that are great at Excel just use it a lot to build complex things. They may have learned the keyboard shortcuts along the way; or not. It just takes practice and muscle memory will kick in but also requires regular practice to keep sharp at it. There's also some pretty decent tooling to help you step your game up if you wish. I personally like https://macabacus.com/ https://macabacus.com/

pxeger1 5y ago

> 200:1 Do you mean you hire 200 out of every 201 people? Or you hire 1 out of every 201 people?

juancn 5y ago
Source 200, hire 1. Many don't even get to basic screening,

geebee 5y ago

We've talked about this so many times on HN, and I've weighed in on this so many times. But it's an important enough topic that we should have the discussion again. You left undefined what you mean by "some sort of basic coding test". I have been screened out of jobs based on questions like "find all matching subtrees in a binary tree", or "find all sub matrices with positive determinants in an NXM matrix" (at the whiteboard, in 45 minutes). I don't think this is as much about critical thinking as you do. What limited feedback I got (from a recruiter, never the person who did the test) was "analysed the problem and sketched the solution well, but didn't make enough coding progress." Again, this was 45 minutes at the whiteboard in a day of getting shuttled from room to room for 5 hours of this. At least you didn't mention "programmers who can't write fizz buzz." I have never heard of anyone getting screened out because of fizz buzz. You may have seen it. But based on my experience, the coding problems are way, way harder than fizz buzz. Maybe you're doing things differently. If so, that's great, but I don't believe it's he norm at all. I'm also totally ok with you giving a difficult technical test that will weed out many competent programmers, as long as you don't pretend it isn't. I'll finish the way I always do - the alleged "shortage" or software developers in Silicon Valley is a product of rational market behavior among educated people who are free to choose a career according to market signals and their own personal interests. Re-taking your second year undergraduate data structures and algorithms exam is about as appetizing as retaking organic chemistry for the rest of your life for a physician, or retaking your partial differential equations exam is for an actuary. If free citizens don't want an employer's job in the numbers the employer thinks they should, even though the employer has decided it pays well, that's the market's answer. I see no need for the government to ask again on the employer's behalf.

dennis_jeeves1 5y ago
>You left undefined what you mean by "some sort of basic coding test". Yes, they never define it, because it's really hard work to clearly define what the bar is in terms of a know coding problem (like fizz-biz).
- geebee 5y ago
  A precise definition in the abstract would be difficult. However, examples are still very useful. Typically, there's an initial easier screening followed by a much harder coding test. Rather than discuss them in the abstract, why not provide clear examples of each? For example, consider the difference between the three statements: You'd be amazed with how many candidates can't actually program. Like at all. vs. You'd be amazed with how many supposedly 'senior' programmers can't pass a very simple programming test. And even those who do can't handle relatively elementary data structures and algorithms once they get to the second round. vs. You'd be amazed how many supposedly 'senior' programmers can't code up fizz buzz or sum odd numbers from 1 to 100 in a loop. And even the ones who do can't search a binary of integers to see if it contains a particular value at a whiteboard in 45 minutes. The last one doesn't define what an easy and hard problem is in the abstract universal case, but it gives me a very good sense of who is and isn't failing these tests. Without that, the claim is relatively meaningless. Unfortunately, I actually think that many of these claims are deliberately left ambiguous. Many people who are claiming a shortage really don't want to be clear about why.

gdfgjhs 5y ago

I agree there are some very good fake programmers. And I haven't interviewed as many programmers, more like tens of them but I had good luck discussing the issues I was having at work. For example, I might tell them about a bug I am working on or even show code on my laptop. Good programmers actually wanted to solve the issue. Many solved or made useful suggestions. Fake programmers usually had pretty hard time, even had troubles verbalizing questions to ask. And sometime I turn tables and ask them what they are stuck at work and I try to help them. With good programmers, we had good discussion and sometimes actually solved their issues. Bad programmers never had any issues.