Technical interview performance is kind of arbitrary • Hacker News Board

Re: Technical interview performance is kind of arbitrary

#41

Post by dudul » Wed, Feb 17, 2016, 8:11 PM UTC

dms105 wrote: post #36

dudul wrote: post #12

In the HN echo chamber, there isn't a day without some blog post/article describing how our interview process is BS, interview is broken, etc. I don't necessarily dispute this state of affaire, but does anyone know how it compares to other fiels/professions? How about interviewing a lawyer? Or a doctor? Or an account manager? Or a product marketer? Are developers the only one with a "broken" interview process?

You could argue that building software has a higher potential for complexity than work in any of those fields. So how do you measure someones ability to be good at that within a reasonable time frame using limited resources (interviewer time)? You're always going to have a "broken" process with those limitations, because you can't test for every possible scenario they may encounter. This leads to a small subset of qu…

More complex than practicing medicine? Or law?

Re: Technical interview performance is kind of arbitrary

#42

Post by pklausler » Wed, Feb 17, 2016, 8:12 PM UTC

rewqfdsa wrote: post #20

grillvogel wrote: post #17

Earlier quoted context omitted.

most other job interview processes don't involve solving a series of riddles

In most other jobs, candidates don't vary in skill by a factor of 10x or more

In most other jobs, it's harder to earn a PhD in the field while not being able to perform basic skills competently. But not computer science. It's damned depressing how low the proportion of new grads is that can write code for me to, say, sort a linked list. So the factor is way larger than 10x. We're not differentiating the great programmers from the merely competent; we're struggling to distinguish the capable from the inept.

Re: Technical interview performance is kind of arbitrary

#43

Post by maxaf » Wed, Feb 17, 2016, 8:14 PM UTC

tiglionabbit wrote: post #35

maxaf wrote: post #29

Take home tests FTW. The thinking goes as follows: 1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in the language of their choice, we can't be bothered to talk to them. 2. If the candidate does reasonably well by completing the code test somewhat on time (with a fat margin allowed for them, well, having a life) and within parameters of the task, they're invited…

You need to verify that the candidate actually did the take home test, and didn't hand it to their more talented friend.

That has always been a concern, but in practice I've never seen this happen. Even for common-ish problems (Dijkstra's algorithm, GCD, chess) I've seen many, many diverse solutions that were obviously hand-coded by the candidate. I recall once we've suspected plagiarism based on a Google search. If my memory serves me right, we rejected the candidate and moved on.

Re: Technical interview performance is kind of arbitrary

#44

Post by iolothebard » Wed, Feb 17, 2016, 8:14 PM UTC

dms105 wrote: post #18

The real weaknesses of technical interviews are: 1) They usually just measure the amount of effort a person has put into studying interview questions. Whether or not the ability to do this translates to being a better engineer is debatable. 2) An interviewer almost always exercise some form of personal bias, whether it be educational, personal, etc. This doesn't always show up in written feedback, but the interviewer…

I had a 800+ page study guide while living in SF for the ridiculous technical interviews they'd put you through. Then you'd see their code base and realize they've never actually done anything that would remotely resemble best practices.

The best part though was realizing if you didn't answer that one question exactly how the "brilliant" person interviewing you wanted it answered, you were done. So at that point I'd quiz them on all their shortcomings that were evident based on what they'd told me.

In my experience hiring it's not that difficult. Good attitude, good aptitude, genuine interest in the field (software engineering), ideally interest in the applied product (if not a software product), decent communicator and good hygiene. If they've done well in those areas, I've never had to let someone go.

Re: Technical interview performance is kind of arbitrary

#45

Post by leeny » Wed, Feb 17, 2016, 8:14 PM UTC

maxaf wrote: post #29

Take home tests FTW. The thinking goes as follows: 1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in the language of their choice, we can't be bothered to talk to them. 2. If the candidate does reasonably well by completing the code test somewhat on time (with a fat margin allowed for them, well, having a life) and within parameters of the task, they're invited…

These can be great. Provided that they're not used as a first-pass filter and provided they give some insight into the work the person will actually be doing. Because otherwise you're going to lose a lot of talented people who can't be bothered, especially in this market.

Re: Technical interview performance is kind of arbitrary

#46

Post by maxaf » Wed, Feb 17, 2016, 8:15 PM UTC

Peroni wrote: post #40

tiglionabbit wrote: post #35

Earlier quoted context omitted.

You need to verify that the candidate actually did the take home test, and didn't hand it to their more talented friend.

That's why you get them to talk you through their process during the face-to-face interview. It'll be immediately apparent if they didn't do the work themselves.

One of the best interviews I've had as a candidate (didn't get that job - it's the one that got away) involved me explaining design choices I made while implementing my solution to the take-home test. That was a great discussion, and didn't feel like the traditional interview-style questioning.

Re: Technical interview performance is kind of arbitrary

#47

Post by kybernetikos » Wed, Feb 17, 2016, 8:17 PM UTC

kbd wrote: post #24

I had a really bizarre interview recently where, after the initial recruiter phone screen, I was rejected based on an in-person half-hour very simplistic paired coding exercise, only met with one person, and wasn't asked about my (imo very strong) resume once. I must have said something foolish at some point, which is on me, but the point is: interviews can be hit or miss. Fortunately you only need one hit.

It does sound like a bad interview experience, but I will say that I have very little interest in what a candidate writes on their resume. There are candidates with amazing resumes that can't do much and people without much that they can talk about publicly that are amazing. If the interview is low signal, the resume is even worse.

Re: Technical interview performance is kind of arbitrary

#48

Post by eropple » Wed, Feb 17, 2016, 8:17 PM UTC

maxaf wrote: post #29

Take home tests FTW. The thinking goes as follows: 1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in the language of their choice, we can't be bothered to talk to them. 2. If the candidate does reasonably well by completing the code test somewhat on time (with a fat margin allowed for them, well, having a life) and within parameters of the task, they're invited…

> 1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in the language of their choice, we can't be bothered to talk to them.

The approach you describe strikes me as shortsighted as well as to no small degree selfish. I don't do take-home tests, as a rule, for one overriding reason: my time is too valuable, and I have so much less of it to expend in discretionary fashion than any potential client or employer, to spend it on a one-way interaction such as a coding test. I have a Github profile with more than enough stuff on it to demonstrate proficiency in some areas and mastery in others, and I learn nothing about your company by completing your test that will help me better understand if I want to work for you. If I really want the gig, maybe then I'll do a little additional work to demonstrate, in good faith and after you have likewise established that you are acting in good faith and aren't just cattle-calling me, that yes, I'm interested. But before? No way. Your company is just not special.

Conversing with a potential client or employer, on the other hand, is a two-way street. I learn things useful to me both in terms of deciding on a gig and things that are more generally useful, like the war stories that inevitably get swapped during those conversations. It helps me decide whether your company is worth it to me and, right now and in this market (for clued-in people), that's the biggest question: not "do we want this person to work for me?", but "do I want to work for this company?". Not operating with that in mind seems like a very, very poor idea to me.

Re: Technical interview performance is kind of arbitrary

#49

Post by maxaf » Wed, Feb 17, 2016, 8:19 PM UTC

kanwisher wrote: post #39

maxaf wrote: post #29

Take home tests FTW. The thinking goes as follows: 1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in the language of their choice, we can't be bothered to talk to them. 2. If the candidate does reasonably well by completing the code test somewhat on time (with a fat margin allowed for them, well, having a life) and within parameters of the task, they're invited…

I assume the take home test is after you have talked to them? I wouldn't spend multiple hours unless it was already clear there was some desire to move further

This kind of depends on where the candidate is coming from. Those who're applying directly are obviously already expressing some desire to work with us. Recruiters should be instructed to give a consistent narrative, too. Good recruiters will also pitch the code test as a sign that we're a serious employer and take people seriously.

I don't like phone conversations that serve as the first line of candidate triage. Many big-company HR departments will have engineers phone screen anyone who sounds marginally suitable. This is soul-crushing, pointless busy work. My personal rejection rate of such candidates is somewhere in the 90-95% range. These are cold leads, not candidates. They should be taking the code test before talking to anyone in engineering.

Re: Technical interview performance is kind of arbitrary

#50

Post by dragonwriter » Wed, Feb 17, 2016, 8:19 PM UTC

pklausler wrote: post #42

rewqfdsa wrote: post #20

Earlier quoted context omitted.

In most other jobs, candidates don't vary in skill by a factor of 10x or more

In most other jobs, it's harder to earn a PhD in the field while not being able to perform basic skills competently. But not computer science. It's damned depressing how low the proportion of new grads is that can write code for me to, say, sort a linked list. So the factor is way larger than 10x. We're not differentiating the great programmers from the merely competent; we're struggling to distinguish the capable fr…

> In most other jobs, it's harder to earn a PhD in the field while not being able to perform basic skills competently. But not computer science.

I think that you are confusing "computer science" with "software development". It may be easy to get a Ph.D. in computer science and be poorly suited for work in the software development industry, but that's no more surprising than the fact that people can get Ph.D.'s in economics and be poorly suited for work in the finance industry.

Computer science is, obviously, related to software development, and in many cases its possible to take a CS degree that is focused on software development, but CS in general is not software development, and CS degrees in general are not vocational degrees in software development.

The best software developers may need to have extensive knowledge of CS, but merely having extensive knowledge of CS doesn't make you even a competent software developer.