Slashdot Mirror
Programming Interview Questions Are Too Hard and Too Short (triplebyte.com)
Programming interview questions can feel unnecessarily difficult. Sometimes they actually are, a new study has found. And this isn't just because they make interviews excessively stressful. The study shows that harder programming questions actually do a worse job of predicting final outcomes than easier ones. From the study: Programming under time pressure is difficult. This is especially true during interviews. A coding exercise that would seem simple under normal circumstances somehow becomes a formidable challenge under the bright lights of an interview room. Stress hormones cloud your thinking during interviews (even though, sadly, neither fight nor flight is an effective response to a menacing programming problem). And it can almost feel like the questions are designed to be perversely difficult. I actually think this is more than just a feeling.
Interview questions are designed to be hard. Because the cost of hiring a bad engineer is so much higher than the cost of rejecting a good engineer, companies are incentivized to set a high bar. And for most companies that means asking hard questions. Intuitively this makes sense because harder questions seem like they should result in a more rigorous screening process. But intuition turns out to be a poor guide here. Our data shows that harder questions are actually less predictive than relatively easy ones. Further reading: Programmers Are Confessing Their Coding Sins To Protest a Broken Job Interview Process.
Interview questions are designed to be hard. Because the cost of hiring a bad engineer is so much higher than the cost of rejecting a good engineer, companies are incentivized to set a high bar. And for most companies that means asking hard questions. Intuitively this makes sense because harder questions seem like they should result in a more rigorous screening process. But intuition turns out to be a poor guide here. Our data shows that harder questions are actually less predictive than relatively easy ones. Further reading: Programmers Are Confessing Their Coding Sins To Protest a Broken Job Interview Process.
Answers are never that important to me as an interviewer unless I am verifying they possess a certain skill. I am much more interested in how conscientious a candidate is in looking for the right answer. It is predictive of how they will solve real problems when they are unsupervised later after being hired.
Small hint: sometimes the answer is not what they are looking for...stress handling, bullshit-o-meter, implementation ideas, probable likability, etc...
Only once I had an interview where I didn't get the job (as a software dev - back when I was a junior, was totally not prepared). The key is to be prepared and actually tell them you don't know and/or you don't want to bullshit them if you don't know the answer.
Why do people go to college to study information systems; analysis, design, project management, requirements, QA, etc. only to be stuck in a corner to code bits and pieces of a system they really have no control over?
What that makes you is pretty much the dude on the auto assembly line screwing on brake drums. You may be very good at it. You can probably put brake drums on any car ever made. You can do it blind folded and you can tell by feel if the drum is unbalanced.
But you are still just screwing on brake drums.
But hey, we need brake drums on every car, eh?
None of us were told there was a programming exercise
Do you really need to be told this? Were you expecting to be hired as a programmer without demonstrating that you can program?
I was a lot happier when I bid contracts for work and stopped interviewing for jobs.
Being an employee sucks. The tax system is set up to screw over the working schlob. If you're smart enough to program well, you're smart enough to hack the tax system too. Programming is the only profession that has anything like trivial tests in interviews. The flip side of this is without professional credentials, that's where things go.
Otherwise.. stand up and do tricks.
Unionize already. Doctors are unionized. Lawyers are unionized. They call it something else, but that's what it is..
..don't panic
Maybe you could talk to them, instead of trying to deceive them?
Indeed. I find that within a few minutes of talking to a candidate, I usually have them nailed down pretty well.
A good developer simply talks differently than a bad one. They talk about what matters rather than whatever rote thing they learned in school, they are excited to talk about cool projects they did, enjoy getting into the mud answering deeper questions, have opinions about things they've been using for a long time, and don't bullshit claiming they know things they don't.
The ones I do give a longer coding exercise to are juniors -- these guys don't usually know how to chat just yet, and don't have any interesting projects under their belt. Enthusiasm can only go so far, so I like to send them home with something to spend an hour on, letting them send it back the next morning.
None of us were told there was a programming exercise
Do you really need to be told this? Were you expecting to be hired as a programmer without demonstrating that you can program?
I imagine it wasn't so much the test, but the bulk 'we don't want to waste our time, but are happy to waste yours' nature of the interview process. It can be a lot more effort for a candidate to come to an interview (time off current job, dry cleaning, transport costs) then for the company to allocate a few staff to the interview room for an hour, and it is a pretty good indicator that the company is happy to mess you about if they expect you to put the effort in to turn up, but won't even give you a one on one interview.
I would always expect a one on one interview unless they told me before hand as a matter of courtesy.
The problem with the approach is that there is a non-trivial percentage of people who can talk the talk, but can't actually do the job. They're good at understanding the successes of their peers in enough depth to be able to successfully claim them as their own, and even fool a competent interviewer in spite of not being able to do the work themselves.
No. The problem with this approach is that it requires an interviewer that has been in the trenches long enough to have worked with enough of the moochers. Once you've worked with a few, they're easy enough to spot. Unfortunately, competence in interviewers closely tracks competence in the general population.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
I'm not surprised HR raised holy hell over that they were 100% right to do so. Only people in fairly narrow niches have time to do take finye coding tests. It skews heavily towards the young and especially those without dependents. Older candidates tend to have more in their lives outside work which preclude doing such tests.
And older, more experienced candidates know you don't do work for free.
They don't know you or your company. You're spending zero effort to ask them for a lot. They have no indication you'll put anything like a commensurate amount of effort into evaluating their work. We've all seen jobs where the winner was selected even before the advertisement. Who on earth but the naive or desperate wants to risk their work on that.
There's no guarantee that you'll get a fair shake if you have an on site, but you know that the company is spending about as much time as you are, so there's a good chance they're not simply wasting it.
SJW n. One who posts facts.
This is another problem with the modern interview process - you only get to see half the results. Your success rate among hires is 87.5%. But you have nothing to compare that against because you don't know what the success rate would've been for the people you didn't hire. Who knows, maybe 90% of the people your interview process filtered out would've made good employees too, and your interview process is actually picking worse candidates than random chance?
The only method I've been able to think of to test this is for management to hire "perfect applicants" to apply for job listings at their company. People with a made-up history, skill set, and knowledge which makes them perfect for a job. See how far they get through the HR filtering and interview process. If HR or an interviewer rejects them, then that indicates a problem with HR or the interviewer.