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

161–170 of 246 posts

Re: Technical interview performance is kind of arbitrary

#161

Post by nvarsj »

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…

> The single most effective way that I've found to interview for "interest" is to just get them talking about something they've done before and ask them to go deep into the details. You get everything you need from watching somebody talk, with a smile on their face, about how they solved some problem in a creative way that makes them show some pride.

Sorry, but you are being scammed. You are selecting for sales skills, not technical skills. Read what you've written. You're judging someone based on how they presents themselves - not anything about technical ability.

I have interviewed many people who are great at doing this impassioned sales speech, but are terrible at actual engineering. And in fact, many good engineers are not good at selling themselves in this way - they have spent most of their lives deep in code, not working on their social skills like normal people.

Why not actually test them similar to what they're going to be doing? If it's a sales or advocate role at your tech consultancy, well then sure, your approach works.

Re: Technical interview performance is kind of arbitrary

#162

Post by bicknergseng »

deangiberson wrote: post #131
bsder wrote: post #124

Earlier quoted context omitted.

> but you're not going to get the same caliber of work from someone who first saw python two weeks ago compared to someone whose been using the language for 5 years on real projects. Careful. You probably need to define your terms more clearly. A CS student who knows Java (4+ years of experience) is going to turn out very different programs from a 20 year veteran of Erlang who is just learning Java. Even with bad Jav…

"Even with bad Java idioms, the veteran is very likely to be turning out much better code because he is thinking about the underlying architectural issues (failure modes, recovery, concurrency) with far more experience." Careful with that assumption. While there may be instances where this is true, I've met many veterans that couldn't think outside the small specialty they had become locked into. Idioms are powerful…

This makes me think of that study[1] about doctors being away on conferences. I think it likely comes down to recognizing that experience rarely, if ever, trumps solid analytical thinking.

[1]http://archinte.jamanetwork.com/article.aspx?articleid=20389...

Re: Technical interview performance is kind of arbitrary

#163

Post by ffumarola »

leeny wrote: post #45
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.

In a recent job hunt, I found cases were used as an excuse for the company to invest 0 time in the process.

It was so bad that with one company (a unicorn, if it matters) I replied with a bunch of questions that I had to fill out the gaping holes in the case, and they instead opted for an in person to avoid investing the time in the replies! In two other cases, they requested 4-6 hours for a time commitment. I told them I was incredibly busy and was more than happy to put 1-2 hours into the case and return it as a work in progress. Both company's said to put as much time as I wanted into it, but then decided that the case wasn't complete enough to continue.

This last round taught me that I won't do cases as a first pass filter as a matter of principle. If you want me to do a case, invest time in me first so that I know we both have skin in the game.

These cases are really just optimizing for people with more time than others.

Re: Technical interview performance is kind of arbitrary

#164

Post by jccc »

nvarsj wrote: post #161
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…

> The single most effective way that I've found to interview for "interest" is to just get them talking about something they've done before and ask them to go deep into the details. You get everything you need from watching somebody talk, with a smile on their face, about how they solved some problem in a creative way that makes them show some pride. Sorry, but you are being scammed. You are selecting for sales skill…

> Sorry, but you are being scammed. You are selecting for sales skills, not technical skills. Read what you've written.

You're asking the parent commenter to set aside eight years of personal hiring experience, over which time "every person I've ever hired who has passed that part has ended up in my 'great hire' category" (assuming, that is, that you've read what he/she's written).

Can a candidate lacking the technical skills go deep into details the way the parent commenter describes?

Re: Technical interview performance is kind of arbitrary

#165

Post by tiglionabbit »

elliotec wrote: post #159
maxaf wrote: post #88

Earlier quoted context omitted.

It was worse than what you describe. It was literally a wholesale copy/paste of a related but not-quite-right solution. The code test involved designing a data model for chess, but the candidate took an implementation from elsewhere that didn't give us the opportunity to evaluate their modeling skills (i.e. "I will create these classes with these fields and connect them like so").

That sounds like an excessive test. What kind of code are you guys writing? Why is it not okay for him to use implementations from elsewhere? Should he really reinvent the wheel to try and impress you? Reminds me of the time I got asked to write a merge sort algorithm in Ruby. I wrote array.sort! on the board, the interviewer told me I have to rewrite it from scratch, and I was done with the interview. Because we cre…

Understanding how mergesort is implemented can be useful. I've had interviewers ask me to sort a data set that is too large for a single hard disk to contain. Mergesort is like map/reduce; it can be distributed.

Re: Technical interview performance is kind of arbitrary

#166

Post by angelbob »

jccc wrote: post #164
nvarsj wrote: post #161

Earlier quoted context omitted.

> The single most effective way that I've found to interview for "interest" is to just get them talking about something they've done before and ask them to go deep into the details. You get everything you need from watching somebody talk, with a smile on their face, about how they solved some problem in a creative way that makes them show some pride. Sorry, but you are being scammed. You are selecting for sales skill…

> Sorry, but you are being scammed. You are selecting for sales skills, not technical skills. Read what you've written. You're asking the parent commenter to set aside eight years of personal hiring experience, over which time "every person I've ever hired who has passed that part has ended up in my 'great hire' category" (assuming, that is, that you've read what he/she's written). Can a candidate lacking the technic…

> Can a candidate lacking the technical skills go deep into details the way the parent commenter describes?

More often than you'd think, alas. I'm going by about fifteen years of personal hiring experience, for whatever that's worth.

Re: Technical interview performance is kind of arbitrary

#167

Post by deciplex »

RogerL wrote: post #109
jkyle wrote: post #91

Earlier quoted context omitted.

> I expect a programmer to be able to pick up a new language or database within a couple of weeks (tops) in most cases. They may be able to hack around, write a for loop, track down a bug....but you're not going to get the same caliber of work from someone who first saw python two weeks ago compared to someone whose been using the language for 5 years on real projects.

So how exactly is anyone supposed to gain new experience? I don't mean to be combative, but so many job recs and interviews expect X years of Y. How do you get that time it? You learn it, right? I didn't used to know Python, but it was obviously useful for my job. So, I installed it and learned it. I was producing useful results for my company very rapidly. Sure, a few years later my skills are more well rounded and…

> So how exactly is anyone supposed to gain new experience?

By having commits on Github numbering in the middle five digits, of course! The only downside is eventually employers will move on to some other arbitrary bullshit metric, and you'll have to start over.

Re: Technical interview performance is kind of arbitrary

#168

Post by deciplex »

bsder wrote: post #124
jkyle wrote: post #91

Earlier quoted context omitted.

> I expect a programmer to be able to pick up a new language or database within a couple of weeks (tops) in most cases. They may be able to hack around, write a for loop, track down a bug....but you're not going to get the same caliber of work from someone who first saw python two weeks ago compared to someone whose been using the language for 5 years on real projects.

> but you're not going to get the same caliber of work from someone who first saw python two weeks ago compared to someone whose been using the language for 5 years on real projects. Careful. You probably need to define your terms more clearly. A CS student who knows Java (4+ years of experience) is going to turn out very different programs from a 20 year veteran of Erlang who is just learning Java. Even with bad Jav…

Why didn't you just write this:

> A CS student is going to turn out very different programs from a 20 year veteran.

Re: Technical interview performance is kind of arbitrary

#169

Post by innertracks »

Just finished 2nd phone interview (it was somewhat technical) yesterday with a company and an online timed tech test this afternoon. First interview was with an internal recruiter and was non-technical.

I've been impressed. They've been very straight forward regarding tech eval with no trick questions and respectful of time. Their interview process is selling me on the company.

Re: Technical interview performance is kind of arbitrary

#170

Post by splintercell »

muddyrivers wrote: post #155
splintercell wrote: post #136

Earlier quoted context omitted.

> 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. I have been reading a quora answer about why most of the developers fail FizzBuzz test and the author differentiates between Programming and Engineering and he says that programming is aim…

The current common interview practice is more like a programming contest. The candidate has to figure out a problem and finish it within ~30~35 minutes. Very competitive, but with little engineering involved. I like the "Software engineering fizz buzz" idea. For backend engineers, I usually ask the candidate to implement a commonly used API in a language she/he is most proficient at.

The way I envision "Software Engineering Test" as a 20 questions exercise.

The interviewer will give a simple user story to the user. "As a user I want to be able to add two numbers".

After the candidate implements that, "As a user I want to be able to subtract two numbers". At this point look how the candidate continues. If he implements a class Calc with two methods as Add and Subtract, then give him 5 points, if he just writes another method then zero points.

Then ask him to add multiplication functionality. If at this point he encapsulates the code as a class, good, if not then make him do that and let him choose the encapsulation(with no bonus points).

Now the point of this exercise is how good of a job does a developer do of figuring out what does the client want especially when client himself doesn't know what he wants.

Somehow once the Calculator class is implemented, the next user story is to "create an interest rate calculation method which offers different interest rate based on credit rating", the idea is the new user requirement is a client asking for to do something quite weird. You can't JUST add this method to the Calculator class. This is the point where the candidate shows how good he is in being an artist with the code.

Post reply on HN