Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical interview performance is kind of arbitrary

blog.interviewing.io

Post reply on HN
Print view View original

61–70 of 246 posts

Re: Technical interview performance is kind of arbitrary

#61

Post by muddyrivers »

jessedhillon wrote: post #25
brightball wrote: post #22

With programmers, the single easiest way to identify good candidates (in my experience) is sheer interest in what they do / desire to learn. This is a learn everyday field and if you're interested in what you're doing, you're going to do a lot better at it. It's hard to apply yourself mentally to something that you don't have a good level of interest in. Given that it's a learn everyday field, people with that level…

Interest is not enough, unfortunately. There are plenty of engineers who are attracted to the challenge and excitement of building new things, but have no appreciation for The Right Way to build things. Great engineers think beyond "how" and ask the "should" questions as well. Mediocre engineers glue things together in a haphazard way with little thought about what's the best way to write things. Caring about maintai…

I apply almost the same approach as OP. You can get a relatively good picture at a candidate's engineering skills and thinking ability via "go[ing] deep into the details", compared to asking algorithm questions.

I also ask candidates to code on a realistic problem. It doesn't involve any "fancy" algorithms or "tricks". What I want to see are the coding style, attention to details, and of course, if the candidate is comfortable at coding.

This approach has been working well for senior candidates. It is much harder to interview new graduates.

Re: Technical interview performance is kind of arbitrary

#62

Post by maxaf »

eropple wrote: post #48
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 fas…

I have one major disagreement with you:

> I have a Github profile with more than enough stuff on it

Based on my experience only, you're in the minority here. Most candidates I've interviewed have barely anything on GitHub. Some UI/UX-ish people will have a portfolio, which involves a lot of "view source" and isn't too rewarding. Lots of perfectly good working programmers have no active open source participation, not even a "dump of code" type of GH profile, making it difficult to tell wheat from chaff. Having them do code tests is pretty much the only way that doesn't involve talking to every single one.

Look at the other side, too: I've gone through hiring processes in the past as a candidate that started with a 30-45 minute conversation with the hiring manager, and proceeded to the onsite interview stage. This inevitably ended up being the classic 6-hour beatdown, with both sides muddling through without truly understanding what either is doing. These are usually so inconclusive (especially at bigger companies) that no one can make a decision, so they end up saying "no". Now both sides are 6+ hours in the hole. This could have been a simple 2-4 hour asynchronous code test, which would have provided hard information to the hiring team instead of the usual inconclusive bullshit.

Re: Technical interview performance is kind of arbitrary

#63

Post by CryoLogic »

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 was bummed out recently when I did a take home test for a local start-up, which asked me to build a full web app. I spent 4-6 hours on it making sure it was perfect - just to turn it and and get told I did a great job but they decided they didn't really want to hire any non-senior engineers and where just testing the waters.

This is happening a lot in Seattle recently - the job market is here is terrible for anyone except senior devs (which it is great for!).

Re: Technical interview performance is kind of arbitrary

#64

Post by dannyr »

darryl42 wrote: post #53
eropple wrote: post #48

Earlier quoted context omitted.

> 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 fas…

How do you feel about the all day interview process some large companies are currently using? Keep in mind you probably had 1-3 phone + computer interviews before the in person interview. A take home test seems like a less time intensive process as you at least don't need to take time off from your normal job to do it.

In addition, Take-home test is better because it is more flexible than an in-person or even phone interview.

Re: Technical interview performance is kind of arbitrary

#65

Post by NDizzle »

jchendy wrote: post #51
brightball wrote: post #22

With programmers, the single easiest way to identify good candidates (in my experience) is sheer interest in what they do / desire to learn. This is a learn everyday field and if you're interested in what you're doing, you're going to do a lot better at it. It's hard to apply yourself mentally to something that you don't have a good level of interest in. Given that it's a learn everyday field, people with that level…

As somebody who's terrible at monologuing, this scares me.

It shouldn't be a monologue - it should be a discussion.

Re: Technical interview performance is kind of arbitrary

#66

Post by [deleted] »

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…

[deleted]

Re: Technical interview performance is kind of arbitrary

#67

Post by chrisper »

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.

A good reason not to work at your company. Why would I want to invest 4(!) unpaid hours into something where I am not even considered seriously yet?

I recently had a coding challenge, which was not only vague, but also took up two hours of my time. The end result was... nothing. Not even a "thank you, but we chose someone else." Since every then, I chose to not bother with long coding challenges anymore.

Re: Technical interview performance is kind of arbitrary

#68

Post by kbd »

kybernetikos wrote: post #47
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.

> There are candidates with amazing resumes that can't do much...

That's certainly true. I understand not taking resumes at face value; I've interviewed developers (and DBAs) and I'd always pour over their resumes to look for both padding and meat to ask about. It can be insightful to ask about a big accomplishment someone claims as their own only to find out that they only actually affected a small part of it. However, In this case I'm honestly not sure whether my interviewer even read my resume.

Re: Technical interview performance is kind of arbitrary

#69

Post by maxaf »

CryoLogic wrote: post #63
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 was bummed out recently when I did a take home test for a local start-up, which asked me to build a full web app. I spent 4-6 hours on it making sure it was perfect - just to turn it and and get told I did a great job but they decided they didn't really want to hire any non-senior engineers and where just testing the waters. This is happening a lot in Seattle recently - the job market is here is terrible for anyone…

Poor execution doesn't invalidate the idea. Happened to me too, although on a smaller scale. 4-6 hours is a bit much for a take-home evaluation project. If it can't be reasonably done by a distracted person in 4 hours, it's too hard/too long for a take-home test.

Hopefully people will learn to do this right over time. Or, someone might solidify a common platform for doing this, a-la HackerRank or any of the other similar services.

Re: Technical interview performance is kind of arbitrary

#70

Post by jchendy »

dudul wrote: post #41
dms105 wrote: post #36

Earlier quoted context omitted.

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?

I'm not a doctor, but from the outside, it seems that practicing medicine is mostly about memorizing a whole bunch of things and then doing them correctly over and over again.

Law actually seems quite similar to programming. You can think of the jury as your users and facts/precedent/laws as the statements available in your programming language. Then your job is to assemble the statements into a program that compiles and that your users want to buy.

Post reply on HN