Earlier quoted context omitted.
Competency tests have helped me get in the door. That said, they seem to work best when they're part of an overall interview process. I think it's a mistake to look at only the highest scores and interview those people, they should only weed out the bottom scores and follow a more typical (do they fit? can they learn it?) process for the rest.
> Competency tests have helped me get in the door. How so? The door was already open if the company decided to give you a test. My impression is that coding tests either offer neutral or negative feedback during an interview. It's not like a candidate can manipulate linked lists in a way that shows particular brilliance.
Limitations and pitfalls of the job interview
81–90 of 185 posts
Re: Limitations and pitfalls of the job interview
#82If you want a really big competitive advantage, figure out how to hire great people who don't interview well.
I use a gig to hire process for this. It works very well. I've been meaning to write more about it but I also get income for helping with hiring around this model so im a bit conflicted. The whole answer is long and complex. Basically: give candidate a proper task on your project and evaluate them based on that work - the "interview" is less than an hour, the "work" is longer (many hours (and you pay for it)) - provi…
Re: Limitations and pitfalls of the job interview
#83> The key is to decide in advance on a list of questions, specifically designed to test job-specific skills, then ask them to all the candidates. In a structured interview, everyone gets the same questions with the same wording, and the interviewer doesn’t improvise.
This is good advice, if and only if you're interviewing an undifferentiated group of applicants, as in the cited examples (college entrance and army recruits). If you're hiring a QA III and you have three different applicants, it's terrible advice. You need to ask about the candidate's specific experience, and ask follow-ups.
More generally, I don't think the stated goal of an interview according to this essay (peering in to the candidate's soul to suss out traits like "responsibility" or "sociability") is possible or reasonable. My goal is more modest - I just want to figure out whether you were good at your last job or not. If you say you're responsible, I can't prove you right or wrong in a one hour conversation. But if you say you're a whiz at Selenium UI automation, and you're lying, I will figure it out pretty easily.
Re: Limitations and pitfalls of the job interview
#84Earlier quoted context omitted.
I use a gig to hire process for this. It works very well. I've been meaning to write more about it but I also get income for helping with hiring around this model so im a bit conflicted. The whole answer is long and complex. Basically: give candidate a proper task on your project and evaluate them based on that work - the "interview" is less than an hour, the "work" is longer (many hours (and you pay for it)) - provi…
That will work for some people but not everyone. At my current job I can't monetize work I do outside the company without approval. That means I can't go through you application process unless I quit first. Even if I was allowed to do this I don't think I'd want to. The time commitment of an extra project on top of my normal workload is not something I want.
Re: Limitations and pitfalls of the job interview
#85There's a growing rift in software between employers saying "there's a talent shortage" and a rapidly growing population of devs who feel like they're locked out due to the technical interview process. Many of the engineers not being hired are recent bootcamp grads but there are also tons of CS majors that can't seem to "crack" the interview process. Part of my job is helping companies "fix" their hiring and one of t…
Re: Limitations and pitfalls of the job interview
#86> What’s the best way to test if someone can do a particular job well? Get them to carry out tasks that are part of the job. See if they can do what they say they can do. It’s much harder for someone to lie and mislead an interviewer during actual work than during an interview. Using competency tests for a blinded interview process is also possible—interviewers could look at depersonalized test results to make unbias…
These are good points, and the tests I have given are specifically designed to avoid these issues.
Personally I do this:
* Come up with a simple but realistic 1 or 2 hour task, and write up the request in plain English (do not write a tech spec). It should be task you'd expect anyone to be able to easily do on day one without any assistance.
* Include a short narrative about the end user that clearly implies a specific requirement or two, but don't spell out it out as an explicit requirement.
* Omit a small but important detail that any reasonable person would ask.
* Instruct them to provide a solution to the users problem, and ask questions if something isn't clear.
These are pretty simple to evaluate too:
* Does the code run? (i.e. can the candidate write basic code?)
* Does it meet the user's explicit needs? (i.e. can the candidate follow basic instructions?)
* Does it meet the user's implicit needs? (i.e. does the candidate write code to spec, or do they think about the bigger picture?)
* Did the candidate ask a question about that obvious missing detail? (i.e. does the candidate speak up, or will they make assumptions?)
You would be surprised with how many people don't have the ability to apply their ability to write code to solve simple problems.
Re: Limitations and pitfalls of the job interview
#87There's a growing rift in software between employers saying "there's a talent shortage" and a rapidly growing population of devs who feel like they're locked out due to the technical interview process. Many of the engineers not being hired are recent bootcamp grads but there are also tons of CS majors that can't seem to "crack" the interview process. Part of my job is helping companies "fix" their hiring and one of t…
I’m not convinced all these articles about “hiring is broken” and “interviews are broken” actually help with this problem. They are pining for something that may not exist (and may not be possible), and failing to help candidates understand and excel within the current system’s imperfections.
I get the impression that many young devs have skewed expectations and aren’t practicing job interviews before attempting them, and believe that their coding skills are the only things that should matter. The article here reinforces those expectations by repeatedly talking about evaluating competency without acknowledging that competency in soft skills like writing and communication and attitude are often at least as important as competency in software engineering, for example.
That said, I would very much agree with your approach and that a technical apprentice is a nice way for both the candidate and the company to learn about each other. Internships naturally do this without necessarily having the expectation of hiring the intern - though I’ve seen a lot of interns hired because they prove themselves competent.
One problem with a technical apprentice role as an alternative to longer interviews is that you have to expect to not hire a large percentage of the apprentices (otherwise there’s no point). In that sense, the apprenticeship becomes a much more demanding interview, and the commitment and risks are much higher for both the candidate and the company. As someone who does a lot of interviewing and resume reading and hiring, I’m not sure I would change my interview process if I hired more apprentices (but I already spend a lot of time looking for potential over experience.)
Re: Limitations and pitfalls of the job interview
#88If you want a really big competitive advantage, figure out how to hire great people who don't interview well.
I use a gig to hire process for this. It works very well. I've been meaning to write more about it but I also get income for helping with hiring around this model so im a bit conflicted. The whole answer is long and complex. Basically: give candidate a proper task on your project and evaluate them based on that work - the "interview" is less than an hour, the "work" is longer (many hours (and you pay for it)) - provi…
Re: Limitations and pitfalls of the job interview
#89There's a growing rift in software between employers saying "there's a talent shortage" and a rapidly growing population of devs who feel like they're locked out due to the technical interview process. Many of the engineers not being hired are recent bootcamp grads but there are also tons of CS majors that can't seem to "crack" the interview process. Part of my job is helping companies "fix" their hiring and one of t…
Seems like a no-brainer to me. Most skilled professions provide some sort of apprenticeship track where you balance some mundane tasks with more complex tasks working with skilled professionals in the discipline to learn the trade better. You're not paid at industry high rates initially but provided a reasonable timeline for full competitive pay employment into the profession. New and young surgeons don't start out d…
There were students who really struggled getting jobs and it was not at all surprising. They struggled in their courses and were not proficient programmers. I never got the impression that they spent much time outside of class trying to work on these skills. No matter how hard I tried to motivate them it fell on deaf ears. I do not think an apprenticeship would have much value to these students other than possibly delaying the conclusion that this may not be the field for them.
I see the idea of apprenticeships discussed as a better alternative to the technical interview. My observation is that those that are proposing this have not worked in a "skilled profession" (not entirely sure how one defines that) that has a so-called apprenticeship. A common example I see on HN is that of doctors, where their residency serves as a sort of apprenticeship. The number and difficulty of tests doctors have to go through to practice as a doctor (at least in the US) is pretty incredible. Given the choice between going through that or studying months for the most difficult battery of technical interview questions, I would choose the technical interview route every time. This completely ignores the fact that doctors attend 4 years of post-graduate education (medical school) before even starting the residency. Imagine if companies required a PhD in CS before you could become an apprentice! And their boards are, without question, orders of magnitude more difficult than a PhD defense (I have a PhD in CS and my wife is a spine surgeon, so I am speaking from experience).
The counter argument I suppose is "well maybe not doctors, but what about accountants and actuaries?" I was a fully credentialed actuary in a prior life and can say those exams were way more stressful and difficult than preparing for technical interviews. Once you are through them it is very easy to move around and there are no technical interviews, but it also takes on average 7 years of intense studying and heartbreaking failures to get there.
I am not saying technical interviews are perfect. However, it seems the theme is that the grass is greener in other professions, and I don't think that is actually the case. What other profession can you studying your butt off for 6 months and land a job paying over $250k out of college?! Yes preparing for technical interviews is difficult, but boy is it worth it (at least in my opinion). I personally think they are a great opportunity to grow as a developer as well. Anyways, I suppose I have gone on enough.
Re: Limitations and pitfalls of the job interview
#90If you want a really big competitive advantage, figure out how to hire great people who don't interview well.
The opposite is a great interviewer. They will have an even better resume. Rarely are the best workers but can somehow stage what little they do into looking like a top performer. Will likely move on when the going gets tough.