16 ms·

Interviewing people is hard. Most people suck at it. I've interviewed over 100 people in my life, and I've been interviewed about ten times. I know I still suck

Interviewing people is hard. Most people suck at it. I've interviewed over 100 people in my life, and I've been interviewed about ten times. I know I still suck at it. The code test is one of the more annoying facets of interviews. On the hiring side, it's an efficient way to screen and vet candidates for basic skills. It's relatively low cost to the employer to have a recruiter issue the test. If you come up with your own in-house code test, it still requires time to evaluate and grade the submissions. There's also a fairly large cost to creating an in-house code test (I know from experience). You have to balance complexity so that it requires enough skill to pass, but isn't so onerous that it puts off too many candidates. Using something like LeetCode removes all the cost from the employer side. Someone else maintains it for you, and you get a canned score at the end. It also depersonalizes it, and provides an opportunity for people to game the system by memorization. The same applies to using canned whiteboard/algorithm questions. I think most of this is a colossal waste of time. It turns away people who don't want to spend hours (or days) on each interview. Imagine applying for even a handful of jobs where each one expects you to do a take-home test that can take a full day. Who has time for that? There's the "if they really want to work for us, they'll take the time to do it" argument, but let's face it, most people are not that passionate about where they work until they actually work there. As a candidate, I am loath to spend my time on these. As someone who's been doing this for 30 years, I'm also a bit insulted by having to do the monkey dance over and over again. At this point in my career, I don't bother applying to places like this. My resume speaks for itself. Of course it makes sense to vet the technical skills of candidates, but you can learn a lot more from 15 minutes of questions than you can from a code test. If you present a candidate with some abstract questions and a couple of targeted detailed technical questions, you can tell if they've got the right problem-solving mind and if they've had experience with the technology you're working with. It's also a much more personal experience.

ryandrake 7y ago
When you need a doctor or lawyer or pilot, because they are certified, you at least know that they all have at least a bare minimum amount of competence. You may not know if they are elite ninja skilled, but you know they know the basics. Literally anyone can say they know how to program, and there is nothing on the resume that can confirm or deny this. I’ve interviewed Senior Software Engineers with years of experience who couldn’t complete a FizzBuzz-like task. Software engineering unfortunately does not have its own “bar exam” or board certification, so it has to be “Monkey Dance” over and over no matter how much experience you have. It’s frustrating both as an interviewer and as an interviewee, but until there exists a verifiable signal of competence for one’s resume, basic skills need to be tested over and over and over.
- fizzbuzz123 7y ago
  I'm sorry but this is such BS. There are what, a dozen other engineering industries out there? EE, Civil, Mechanical, Aeronautical etc. and in not a single one of them do they do this monkey dance. It would be absurd to ask a Aeronautical Engineer to do something like derive the Navier-Stokes Equation on a whiteboard and its equally absurd to play the same game with SWE's, you all have just been bamboozled and strong-armed by employers into accepting it as a valid practice. I doubt you would be willing to say that those other industries are failures or hire low quality engineers because they don't torture their employees with essentially pointless trivia games. In fact one might say that the Aeronautics industry is in far better shape than the Software industry, a failure in one of their systems results in people dying but I can go to any major tech companies websites and experience a bug on any given day.
  - ThenAsNow 7y ago
    > It would be absurd to ask a Aeronautical Engineer to do something like derive the Navier-Stokes Equation on a whiteboard A thorough interview in physical engineering disciplines will often expect you to demonstrate/validate something about your technical skill in-person, unless you are being interviewed because people already have validated knowledge about your capabilities (e.g., hiring a known individual from a competitor that is well-respected among peers). To your point, a physical engineering interview might be more about "spot checks" than "assume the person is lying so ask them to complete a bevy of undergraduate final exam questions". In the software world, maybe that would be akin to starting with FizzBuzz and finding other ways to get solid proof the person can implement, not just talk. To me, if you have open source work that can be read by an interviewer, I would find it disrespectful for that interviewer to act as though the work doesn't exist and they should verify from scratch you can actually write working code. It's comparatively a lot harder to just have a conversation with a software person and be certain they have the technical competence they claim vs. other technical realms. I tend to think it is the nature of the subject, as well as the salaries drawing in more charlatans than in physical engineering realms. > In fact one might say that the Aeronautics industry is in far better shape than the Software industry, a failure in one of their systems results in people dying but I can go to any major tech companies websites and experience a bug on any given day. This probably has more to do with Aeronautics actually practicing engineering as compared to today's software development practices. Also software development as a field is far less mature than traditional engineering disciplines. That's not meant to be pejorative - it's just where humanity is.
raiflip 7y ago
Sounds interesting, could you expand some of the abstract and targeted technical questions that you find effective?
balls187 7y ago
> The code test is one of the more annoying facets of interviews. On the hiring side, it's an efficient way to screen and vet candidates for basic skills. It's relatively low cost to the employer to have a recruiter issue the test. I agree with you in principle for a programming job, but from the post, this was a dev ops job, and the candidate was asked a dynamic programming question. There was no link to the JD, but I suspect it had little by the way requiring a CS degree.
tomp 7y ago
Everything you say sounds extremely reasonable... but still, there are plenty of stories (mostly online, so they might not actually be true) of people hiring a person that aces (mostly non-technical) interviews only to show absolutely 0 actual technical skills on the job.
- malvosenior 7y ago
  In my experience (also interviewing hundreds of people) this is totally an urban (internet) legend. Not once has someone been able to talk intelligently and at length about a project they built and the underlying technology choices and then been unable to deliver. Once you gain experience building things yourself, it's pretty easy to suss out whether someone is any good just by talking to them. No coding tests needed.
  - panopticon 7y ago
    At one of my previous gigs, we managed to hire someone who couldn't write more than basic control structures. I have absolutely no clue how it happened as I wasn't involved with the interviewing process at the time. The people who were involved blamed the recruiting firm for not doing adequate technical screening, but that doesn't explain how this person passed the on-site interview they performed... At any rate, we let them go after 3 days. I have no way to prove to veracity of my story, so feel free to add it to the "urban myth" pile. But it was extremely bizarre to experience.
  - jjav 7y ago
    Agreed. The best way to interview is to simply have a joint discussion about their past projects (from resume). There is no value in whiteboard puzzles. It is easy to gauge who is competent and who didn't do or didn't understand the work they claim on the resume. In over 25 years of interviewing candidates, this approach has never failed me. I've never asked for whiteboard coding. Whiteboarding architectural concepts, sure. The only caveat is the interviewer needs to have substantial experience in the same field to spot the wheat from the chaff in a casual conversation. If the interviewer is very junior, I can see how this might not work. Solution: don't have your most junior people run the interviews.
jasonpeacock 7y ago
I've had interviews start very positively with such an approach of questions, but then "just to be thorough" I have them code something simple on the whiteboard and they completely fail. Some of them couldn't even get nested for loops to work correctly. If you're hiring someone to write code for you, you need to have them write code in the interview. There's no substitute for it. Obviously, you can improve the experience - let them bring their own laptop and code on it, no problem.
- ConcernedCoder 7y ago
  This disproportionally filters for those who can think/code and perfom while under pressure/observation... i.e. the "porn stars" of software development, if you will. Similar to how not everyone is able to perform well while having sex-on-demand in front of a camera -- these same people are more than likely able to have sex when not under pressure and observation, and probably are quite adequate while doing it. My personal experience in software development spans decades, I'm quite competent and I have definitely "choked" at the whiteboard, just like you're describing -- for the same reasons I don't do well speaking in public, I'm not comfortable doing it, and I'm just not cut-out for it... I don't think it's a good measure of actual problem solving and/or software development competency.
  - rightbyte 7y ago
    An analogy that every male acctually can relate to is peeing under pressure from the que behind you.
  - gowld 7y ago
    > "porn stars" That's.... a much more accurate term than the "rock star" that gets tossed around.
  - IshKebab 7y ago
    By the same logic you might say that we shouldn't interview at all because it selects for people that are good at being interviewed. Obviously this is true but I think it would be pretty crazy to not interview people. Frankly I think most people suck at being interviewed initially, but you can definitely improve with practice. The same as public speaking and interviewing candidates.
SubuSS 7y ago
The coding is to get a sense of how they write code, how rusty they are, how many good habits they've picked up relative to their experience, how do they think about validation/testing of it, how the go about building it (ad-hoc vs top down), their problem solving skills when faced with an unknown problem and so on. There will always be unknown unknowns. We are just trying to cover the known variations and if he has any unknown knowns[1]. 1 -https://academic.oup.com/jxb/article/60/3/712/453685 https://academic.oup.com/jxb/article/60/3/712/453685
fdjlasdfjl 7y ago
We draft a test tailored to each position. I couldn't even imagine using some canned crappy algo test. People claim more skill on their resume than they typically have, so having a test on the tools they'll actually use is a great way to determine fit for intermediate and senior roles. We also run the test for junior roles but there is a loooooot of latitude on the test, we're mostly interested in how they respond to interview questions. Also I feel that a paper test (without google) is important because I see "failures" who get the concepts right but fuck up the syntax or easily google-able things.
pault 7y ago
> My resume speaks for itself. At the time of this writing, I am working with someone who has 10+ years of experience, including former positions as a lead developer. I was involved in the interview process and made the recommendation to hire, as they were able to answer a lot of domain-specific questions very well and had a good knowledge of the ecosystem. Fast-forward three months, and I am spending hours per day sending changes back on code reviews for features that would have taken me 30 minutes to implement. Every review has at least one conditional that always evaluates to true. Yesterday I found a try/catch block that always throws inside of the try block. The crown jewel was the following for-loop (psuedocode): for i=0; i<=3; i++: try: doSomething(); catch: if i<3: continue; else if i==3: break; And the best part is because of political reasons and difficulty hiring a replacement, we can't fire this person. I now include coding exercises in my interviews. I typically focus on reviewing code with bugs and refactoring bad code instead of forcing them to whiteboard.
- jimcsharp 7y ago
  At least you have a constant source of code for interviewees to fix.
  - pault 7y ago
    You jest, but the for loop example is now in our pre-screening questions!
- HorizonXP 7y ago
  Would a better interview test be to ask the candidate to review code rather than write it themselves? That is, give them a code sample, describe what it aims to do, and ask: 1) Does this code accomplish the goal? 2) How would you improve this code to make it more readable? More efficient? Personally, I think I'd rather work with people that know how to review code and provide feedback/commentary, since that usually means they can write good code themselves. It should lead to a better team dynamic.
  - granshaw 7y ago
wutbrodo 7y ago
I think it's a holdover from hiring more junior candidates: after a few years interviewing and sitting on HCs at Google, I hired for a tiny startup that had tons of trouble sourcing candidates. My interviews at the latter place eventually devolved into basic IQ tests. Simple coding problems are pretty ideal for this, since they also lightly test necessary domain skills. The problem is that this doesn't scale with talent and/or experience: I certainly wouldn't be better at coding interviews than I was out of college. People who aren't great at hiring take an approach that's valid at the low level and extrapolate it well beyond the bounds where it makes sense. On the other hand, this only works if the pedigree is recognizable and reliable. I can be pretty confident that I don't need to test basic coding literacy of someone who was an engineer at Google for four years, but I've interviewed people with ten years experience and great references who were clearly dumb as a brick during the interview. In one case, we hired the guy over my objection and spent the next year fighting the fires he'd set whenever he touched anything (the founder eventually found some relatively unimportant, isolated niche for him to keep busy in). It's a really hard problem, and most complaints I've come across are generalizing from their skewed view of what the candidate pool is like (usually assuming that most candidates are roughly as talented as they are, when the reality is that many candidate pools consist of some of the dumbest people you're likely to ever encounter) [1] ie, practically everyone
- dcolkitt 7y ago
  > My interviews at the latter place eventually devolved into basic IQ tests... The problem is that this doesn't scale with talent and/or experience. Industrial psychology has consistently found that IQ is a better predictor of job performance than experience. The reason being is that intelligence is defined as the ability to acquire knowledge and skills. Intelligent people literally learn faster than others. The skill acquired by a low IQ in five years is often surpassed by a high IQ person with a few months of experience. [1]https://www.jstor.org/stable/20182140?seq=1#page_scan_tab_contents https://www.jstor.org/stable/20182140?seq=1#page_scan_tab_co...
  - winter_blue 7y ago
    > Industrial psychology has consistently found that IQ is a better predictor of job performance than experience. If hiring managers are aware of this, then it might be a good idea to apply to Mensa. If you're able to get in, maybe putting "Mensa" down on your resume isn't that bad of a thing. (I've always felt it would make one come off as a douche, but maybe that's not so true.)
mangatmodi 7y ago
> most people are not that passionate about where they work until they actually work there I do like coding a lot, but these home tests can never excite me. I have a family. I can't do it after office. In office I want to work honestly on my job. So frustrating!!
deleted 7y ago
[deleted]
tptacek 7y ago
The problem is, your resume doesn't speak for itself, or, more accurately, resumes in general don't speak for themselves. It's not because people lie on their resumes, but because there's a pattern in this industry of people failing laterally and upwards. It takes much longer than people assume to get a dysfunctional team member off the payroll. In most shops, new hires spend months in a (reasonable!) reduced-expectation state of on-boarding and ramping up, during which their performance can't readily be measured. It then takes several engineering cycles to figure out that they're not working out on a particular project, after which the normal response is often to try moving them to another project. You can be more than 6 months in with an employee before there's a confident assessment in engineering management that someone isn't working out. In many shops, at that point the next step is to begin the process of "managing them out" (often with multiple stages of PIPs), which includes a fig-leaf premise that performance can be fixed and the team member retained. And that's if things are carefully managed. Lots of teams, even good teams, aren't carefully managed, and it can take more than a year to detect and propagate the signal that someone isn't working out. The net result is that people can accumulate impressive-looking resumes without ever effectively delivering for any team, and because resumes get more impressive over time, the roles people get offered improve as well, compounding the effect. I'm an evangelist for evidence-based hiring techniques and a fierce critic of standard interviewing practices, which I agree are dehumanizing and unreliable. But we started our hiring practice[1] not because we wanted to include more people, though that was a happy result of it, but rather because we'd been burned repeatedly by good resumes and strong interviewing skills. At this point in my career, for a technical/IC role (really, any role), I'd be alarmed if I wasn't given practical tests to verify I can actually back up my talk. Their absence would make me suspicious (though perhaps not dispositively so) about the technical ability of the team I was considering joining. [1]: https://sockpuppet.org/blog/2015/03/06/the-hiring-post/ https://sockpuppet.org/blog/2015/03/06/the-hiring-post/
- wyclif 7y ago
  For a technical/IC role (really, any role), I'd be alarmed if I wasn't given practical tests to verify I can actually back up my talk Agreed, and let me offer an anecdotal, real-world example. Before I was in this racket, I used to be a land surveyor. Because it's both technical and licensed (and btw, I'm not going to make an argument for licensure, just mentioning it as a qualifier), you had to take a written test and pass a rigorous interview before you were accepted as an apprentice land surveyor. The test involved trigonometry, plane geometry, algebra, property law, and basic statistics. The sit down involved attempts to surface red flags all the way down to testing if the candidate was afraid of dogs. And after passing that, then you were hired on as an apprentice which meant that all your work had to be reviewed and signed off on by a licensed PLS while you learned on the job and could eventually take the PLS exam yourself. Too often in software engineering, a candidate can jump through the hoops and get hired but even if their role is junior, they're essentially on their own except for code reviews. There's very little mentoring, because senior people are neck deep in work and nobody's got time for that. The company has to be committed to mentoring and carve out space and money for it in order for it to happen.
scarface74 7y ago
Resumes lie. You can’t imagine the number of times I’ve interviewed someone with $years of experience who were actually no more than “expert beginners”. Older developers come in two forms. Those who aggressive learn, have matured beyond “just developers” and those who are set in their ways. I’m 45.

ryandrake 7y ago

When you need a doctor or lawyer or pilot, because they are certified, you at least know that they all have at least a bare minimum amount of competence. You may not know if they are elite ninja skilled, but you know they know the basics. Literally anyone can say they know how to program, and there is nothing on the resume that can confirm or deny this. I’ve interviewed Senior Software Engineers with years of experience who couldn’t complete a FizzBuzz-like task. Software engineering unfortunately does not have its own “bar exam” or board certification, so it has to be “Monkey Dance” over and over no matter how much experience you have. It’s frustrating both as an interviewer and as an interviewee, but until there exists a verifiable signal of competence for one’s resume, basic skills need to be tested over and over and over.

fizzbuzz123 7y ago
I'm sorry but this is such BS. There are what, a dozen other engineering industries out there? EE, Civil, Mechanical, Aeronautical etc. and in not a single one of them do they do this monkey dance. It would be absurd to ask a Aeronautical Engineer to do something like derive the Navier-Stokes Equation on a whiteboard and its equally absurd to play the same game with SWE's, you all have just been bamboozled and strong-armed by employers into accepting it as a valid practice. I doubt you would be willing to say that those other industries are failures or hire low quality engineers because they don't torture their employees with essentially pointless trivia games. In fact one might say that the Aeronautics industry is in far better shape than the Software industry, a failure in one of their systems results in people dying but I can go to any major tech companies websites and experience a bug on any given day.
- ThenAsNow 7y ago
  > It would be absurd to ask a Aeronautical Engineer to do something like derive the Navier-Stokes Equation on a whiteboard A thorough interview in physical engineering disciplines will often expect you to demonstrate/validate something about your technical skill in-person, unless you are being interviewed because people already have validated knowledge about your capabilities (e.g., hiring a known individual from a competitor that is well-respected among peers). To your point, a physical engineering interview might be more about "spot checks" than "assume the person is lying so ask them to complete a bevy of undergraduate final exam questions". In the software world, maybe that would be akin to starting with FizzBuzz and finding other ways to get solid proof the person can implement, not just talk. To me, if you have open source work that can be read by an interviewer, I would find it disrespectful for that interviewer to act as though the work doesn't exist and they should verify from scratch you can actually write working code. It's comparatively a lot harder to just have a conversation with a software person and be certain they have the technical competence they claim vs. other technical realms. I tend to think it is the nature of the subject, as well as the salaries drawing in more charlatans than in physical engineering realms. > In fact one might say that the Aeronautics industry is in far better shape than the Software industry, a failure in one of their systems results in people dying but I can go to any major tech companies websites and experience a bug on any given day. This probably has more to do with Aeronautics actually practicing engineering as compared to today's software development practices. Also software development as a field is far less mature than traditional engineering disciplines. That's not meant to be pejorative - it's just where humanity is.

raiflip 7y ago

Sounds interesting, could you expand some of the abstract and targeted technical questions that you find effective?

balls187 7y ago

> The code test is one of the more annoying facets of interviews. On the hiring side, it's an efficient way to screen and vet candidates for basic skills. It's relatively low cost to the employer to have a recruiter issue the test. I agree with you in principle for a programming job, but from the post, this was a dev ops job, and the candidate was asked a dynamic programming question. There was no link to the JD, but I suspect it had little by the way requiring a CS degree.

tomp 7y ago

Everything you say sounds extremely reasonable... but still, there are plenty of stories (mostly online, so they might not actually be true) of people hiring a person that aces (mostly non-technical) interviews only to show absolutely 0 actual technical skills on the job.

malvosenior 7y ago
In my experience (also interviewing hundreds of people) this is totally an urban (internet) legend. Not once has someone been able to talk intelligently and at length about a project they built and the underlying technology choices and then been unable to deliver. Once you gain experience building things yourself, it's pretty easy to suss out whether someone is any good just by talking to them. No coding tests needed.
- panopticon 7y ago
  At one of my previous gigs, we managed to hire someone who couldn't write more than basic control structures. I have absolutely no clue how it happened as I wasn't involved with the interviewing process at the time. The people who were involved blamed the recruiting firm for not doing adequate technical screening, but that doesn't explain how this person passed the on-site interview they performed... At any rate, we let them go after 3 days. I have no way to prove to veracity of my story, so feel free to add it to the "urban myth" pile. But it was extremely bizarre to experience.
- jjav 7y ago
  Agreed. The best way to interview is to simply have a joint discussion about their past projects (from resume). There is no value in whiteboard puzzles. It is easy to gauge who is competent and who didn't do or didn't understand the work they claim on the resume. In over 25 years of interviewing candidates, this approach has never failed me. I've never asked for whiteboard coding. Whiteboarding architectural concepts, sure. The only caveat is the interviewer needs to have substantial experience in the same field to spot the wheat from the chaff in a casual conversation. If the interviewer is very junior, I can see how this might not work. Solution: don't have your most junior people run the interviews.

jasonpeacock 7y ago

I've had interviews start very positively with such an approach of questions, but then "just to be thorough" I have them code something simple on the whiteboard and they completely fail. Some of them couldn't even get nested for loops to work correctly. If you're hiring someone to write code for you, you need to have them write code in the interview. There's no substitute for it. Obviously, you can improve the experience - let them bring their own laptop and code on it, no problem.

ConcernedCoder 7y ago
This disproportionally filters for those who can think/code and perfom while under pressure/observation... i.e. the "porn stars" of software development, if you will. Similar to how not everyone is able to perform well while having sex-on-demand in front of a camera -- these same people are more than likely able to have sex when not under pressure and observation, and probably are quite adequate while doing it. My personal experience in software development spans decades, I'm quite competent and I have definitely "choked" at the whiteboard, just like you're describing -- for the same reasons I don't do well speaking in public, I'm not comfortable doing it, and I'm just not cut-out for it... I don't think it's a good measure of actual problem solving and/or software development competency.
- rightbyte 7y ago
  An analogy that every male acctually can relate to is peeing under pressure from the que behind you.
- gowld 7y ago
  > "porn stars" That's.... a much more accurate term than the "rock star" that gets tossed around.
- IshKebab 7y ago
  By the same logic you might say that we shouldn't interview at all because it selects for people that are good at being interviewed. Obviously this is true but I think it would be pretty crazy to not interview people. Frankly I think most people suck at being interviewed initially, but you can definitely improve with practice. The same as public speaking and interviewing candidates.

SubuSS 7y ago

The coding is to get a sense of how they write code, how rusty they are, how many good habits they've picked up relative to their experience, how do they think about validation/testing of it, how the go about building it (ad-hoc vs top down), their problem solving skills when faced with an unknown problem and so on. There will always be unknown unknowns. We are just trying to cover the known variations and if he has any unknown knowns[1]. 1 -https://academic.oup.com/jxb/article/60/3/712/453685 https://academic.oup.com/jxb/article/60/3/712/453685

fdjlasdfjl 7y ago

We draft a test tailored to each position. I couldn't even imagine using some canned crappy algo test. People claim more skill on their resume than they typically have, so having a test on the tools they'll actually use is a great way to determine fit for intermediate and senior roles. We also run the test for junior roles but there is a loooooot of latitude on the test, we're mostly interested in how they respond to interview questions. Also I feel that a paper test (without google) is important because I see "failures" who get the concepts right but fuck up the syntax or easily google-able things.

pault 7y ago

> My resume speaks for itself. At the time of this writing, I am working with someone who has 10+ years of experience, including former positions as a lead developer. I was involved in the interview process and made the recommendation to hire, as they were able to answer a lot of domain-specific questions very well and had a good knowledge of the ecosystem. Fast-forward three months, and I am spending hours per day sending changes back on code reviews for features that would have taken me 30 minutes to implement. Every review has at least one conditional that always evaluates to true. Yesterday I found a try/catch block that always throws inside of the try block. The crown jewel was the following for-loop (psuedocode): for i=0; i<=3; i++: try: doSomething(); catch: if i<3: continue; else if i==3: break; And the best part is because of political reasons and difficulty hiring a replacement, we can't fire this person. I now include coding exercises in my interviews. I typically focus on reviewing code with bugs and refactoring bad code instead of forcing them to whiteboard.

jimcsharp 7y ago
At least you have a constant source of code for interviewees to fix.
- pault 7y ago
  You jest, but the for loop example is now in our pre-screening questions!
HorizonXP 7y ago
Would a better interview test be to ask the candidate to review code rather than write it themselves? That is, give them a code sample, describe what it aims to do, and ask: 1) Does this code accomplish the goal? 2) How would you improve this code to make it more readable? More efficient? Personally, I think I'd rather work with people that know how to review code and provide feedback/commentary, since that usually means they can write good code themselves. It should lead to a better team dynamic.
- granshaw 7y ago

wutbrodo 7y ago

I think it's a holdover from hiring more junior candidates: after a few years interviewing and sitting on HCs at Google, I hired for a tiny startup that had tons of trouble sourcing candidates. My interviews at the latter place eventually devolved into basic IQ tests. Simple coding problems are pretty ideal for this, since they also lightly test necessary domain skills. The problem is that this doesn't scale with talent and/or experience: I certainly wouldn't be better at coding interviews than I was out of college. People who aren't great at hiring take an approach that's valid at the low level and extrapolate it well beyond the bounds where it makes sense. On the other hand, this only works if the pedigree is recognizable and reliable. I can be pretty confident that I don't need to test basic coding literacy of someone who was an engineer at Google for four years, but I've interviewed people with ten years experience and great references who were clearly dumb as a brick during the interview. In one case, we hired the guy over my objection and spent the next year fighting the fires he'd set whenever he touched anything (the founder eventually found some relatively unimportant, isolated niche for him to keep busy in). It's a really hard problem, and most complaints I've come across are generalizing from their skewed view of what the candidate pool is like (usually assuming that most candidates are roughly as talented as they are, when the reality is that many candidate pools consist of some of the dumbest people you're likely to ever encounter) [1] ie, practically everyone

dcolkitt 7y ago
> My interviews at the latter place eventually devolved into basic IQ tests... The problem is that this doesn't scale with talent and/or experience. Industrial psychology has consistently found that IQ is a better predictor of job performance than experience. The reason being is that intelligence is defined as the ability to acquire knowledge and skills. Intelligent people literally learn faster than others. The skill acquired by a low IQ in five years is often surpassed by a high IQ person with a few months of experience. [1]https://www.jstor.org/stable/20182140?seq=1#page_scan_tab_contents https://www.jstor.org/stable/20182140?seq=1#page_scan_tab_co...
- winter_blue 7y ago
  > Industrial psychology has consistently found that IQ is a better predictor of job performance than experience. If hiring managers are aware of this, then it might be a good idea to apply to Mensa. If you're able to get in, maybe putting "Mensa" down on your resume isn't that bad of a thing. (I've always felt it would make one come off as a douche, but maybe that's not so true.)

mangatmodi 7y ago

> most people are not that passionate about where they work until they actually work there I do like coding a lot, but these home tests can never excite me. I have a family. I can't do it after office. In office I want to work honestly on my job. So frustrating!!

deleted 7y ago

[deleted]

tptacek 7y ago

The problem is, your resume doesn't speak for itself, or, more accurately, resumes in general don't speak for themselves. It's not because people lie on their resumes, but because there's a pattern in this industry of people failing laterally and upwards. It takes much longer than people assume to get a dysfunctional team member off the payroll. In most shops, new hires spend months in a (reasonable!) reduced-expectation state of on-boarding and ramping up, during which their performance can't readily be measured. It then takes several engineering cycles to figure out that they're not working out on a particular project, after which the normal response is often to try moving them to another project. You can be more than 6 months in with an employee before there's a confident assessment in engineering management that someone isn't working out. In many shops, at that point the next step is to begin the process of "managing them out" (often with multiple stages of PIPs), which includes a fig-leaf premise that performance can be fixed and the team member retained. And that's if things are carefully managed. Lots of teams, even good teams, aren't carefully managed, and it can take more than a year to detect and propagate the signal that someone isn't working out. The net result is that people can accumulate impressive-looking resumes without ever effectively delivering for any team, and because resumes get more impressive over time, the roles people get offered improve as well, compounding the effect. I'm an evangelist for evidence-based hiring techniques and a fierce critic of standard interviewing practices, which I agree are dehumanizing and unreliable. But we started our hiring practice[1] not because we wanted to include more people, though that was a happy result of it, but rather because we'd been burned repeatedly by good resumes and strong interviewing skills. At this point in my career, for a technical/IC role (really, any role), I'd be alarmed if I wasn't given practical tests to verify I can actually back up my talk. Their absence would make me suspicious (though perhaps not dispositively so) about the technical ability of the team I was considering joining. [1]: https://sockpuppet.org/blog/2015/03/06/the-hiring-post/ https://sockpuppet.org/blog/2015/03/06/the-hiring-post/

wyclif 7y ago
For a technical/IC role (really, any role), I'd be alarmed if I wasn't given practical tests to verify I can actually back up my talk Agreed, and let me offer an anecdotal, real-world example. Before I was in this racket, I used to be a land surveyor. Because it's both technical and licensed (and btw, I'm not going to make an argument for licensure, just mentioning it as a qualifier), you had to take a written test and pass a rigorous interview before you were accepted as an apprentice land surveyor. The test involved trigonometry, plane geometry, algebra, property law, and basic statistics. The sit down involved attempts to surface red flags all the way down to testing if the candidate was afraid of dogs. And after passing that, then you were hired on as an apprentice which meant that all your work had to be reviewed and signed off on by a licensed PLS while you learned on the job and could eventually take the PLS exam yourself. Too often in software engineering, a candidate can jump through the hoops and get hired but even if their role is junior, they're essentially on their own except for code reviews. There's very little mentoring, because senior people are neck deep in work and nobody's got time for that. The company has to be committed to mentoring and carve out space and money for it in order for it to happen.

scarface74 7y ago

Resumes lie. You can’t imagine the number of times I’ve interviewed someone with $years of experience who were actually no more than “expert beginners”. Older developers come in two forms. Those who aggressive learn, have matured beyond “just developers” and those who are set in their ways. I’m 45.