Technical interview performance is kind of arbitrary • Hacker News Board

Re: Technical interview performance is kind of arbitrary

#91

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

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…

> 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.

Re: Technical interview performance is kind of arbitrary

#92

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

maxaf wrote: post #71

chrisper wrote: post #67

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. 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 t…

Would you have preferred to spend a whole day on an inconclusive onsite interview? Or perhaps a phone screen during which you're asked to implement a hashtable for the umpteenth time? As I said in another comment somewhere in this thread, one day people will learn to do this right. Hopefully this will happen before programmers as a profession have decided to never take code tests again.

At least an onsite interview typically includes expense reporting lunch, if not dinner, and maybe an opportunity to visit a city or a part of city you are less familiar with and possibly even sight-see a bit.

I don't think a phone screen is productive beyond a half-hour to an hour and anyone asking technical implementations over the phone is likely a worse interview than trying to whiteboard things (and that's still far and removed from actual programming).

Re: Technical interview performance is kind of arbitrary

#93

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

rm_-rf_slash wrote: post #86

JasonCEC wrote: post #82

As a potential candidate, all of the standard complaints ring true - but once you're on the other side of the equation, and need to hire people... your ability to create new interviews is not nearly as wide or as clear as it would seem from the outside. 1) Take home test: OK for performance metrics, bad for "getting to know" the candidate, and terrible for selling the candidate on your company 2) Daylong interview: E…

I've said elsewhere on this thread, but my absolute favorite technical interview method is to set up a contract to pay the candidate to create a feature or fix a bug on your codebase, and have it merge and work as expected. It lets the candidate feel (literally) valued by your company, and you get to learn how they do the job you are hiring them to do.

Agreed that this is a great approach, but the major downside is that you are limiting yourself to candidates who either:

a) have the time to do real work outside of their day job and aren't on a restrictive contract preventing them from moonlighting, or...

b) are currently unemployed

Re: Technical interview performance is kind of arbitrary

#94

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

superuser2 wrote: post #90

rm_-rf_slash wrote: post #73

Earlier quoted context omitted.

Startup A asked me to do a take-home programming challenge to prove my skills, as well as a general algorithm test to give them ideas how to run their core architecture. This took hours, I felt I was being asked to do their job for free (on the second test), and the results were pathetic. Startup B gave me an assignment to add a feature to their API and have my work merged with their active code base. I was compensat…

Option B is explicitly prohibited in your employment agreement for most salary workers. I would never consider working for a company that required me to violate a contract just for a chance to work there.

"Most"? Anecdotally and all that, but I never signed a contract that stated that, across ~5 jobs. One tried and I got it redlined out before I started.

Re: Technical interview performance is kind of arbitrary

#95

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

iolothebard wrote: post #44

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…

Ever thought about releasing this study guide that you've made? I would love to take a look at it/ send it to some friends!

Re: Technical interview performance is kind of arbitrary

#96

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

chrisper wrote: post #67

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

As someone currently preparing to interview with Google I'd take 4 hours implementing real code over a (recommended) 2 weeks of basic algorithms, data structures, math, etc. revision.

Re: Technical interview performance is kind of arbitrary

#97

Post by rm_-rf_slash » Wed, Feb 17, 2016, 8:57 PM UTC

hire_charts wrote: post #93

rm_-rf_slash wrote: post #86

Earlier quoted context omitted.

I've said elsewhere on this thread, but my absolute favorite technical interview method is to set up a contract to pay the candidate to create a feature or fix a bug on your codebase, and have it merge and work as expected. It lets the candidate feel (literally) valued by your company, and you get to learn how they do the job you are hiring them to do.

Agreed that this is a great approach, but the major downside is that you are limiting yourself to candidates who either: a) have the time to do real work outside of their day job and aren't on a restrictive contract preventing them from moonlighting, or... b) are currently unemployed

I was a college student at the time. I was long on money and short on cash. I was also far less experienced than I was so there were a lot of new things for me then, like those fascinating "callback" thingies I had to figure out.

Nowadays if I were given roughly the same assignment it would have taken me about 3-5 hours at best, which, given my graduated-and-employed hourly rate, is actually quite in line with what I was paid. So it paid as much as I would have charged for a Saturday hack.

Re: Technical interview performance is kind of arbitrary

#98

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

maxaf wrote: post #71

chrisper wrote: post #67

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. 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 t…

Would you have preferred to spend a whole day on an inconclusive onsite interview? Or perhaps a phone screen during which you're asked to implement a hashtable for the umpteenth time? As I said in another comment somewhere in this thread, one day people will learn to do this right. Hopefully this will happen before programmers as a profession have decided to never take code tests again.

Yes. The onsite means the company is investing just as much time and effort into the process as the candidate.

Re: Technical interview performance is kind of arbitrary

#99

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

eropple wrote: post #84

maxaf wrote: post #62

Earlier quoted context omitted.

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…

> Having them do code tests is pretty much the only way that doesn't involve talking to every single one. I get where you're coming from. But to me that's still a very, very selfish way of approaching this. You are asking for a blind burn of four hours of their time just to consider talking to them. Four hours is a lot of time. It's half a workday. You're asking for a hell of a lot just to not-a-culture-fit them out…

I wish there was a way to scale the "add feature to FOSS project we use" thing. Scale is a concern here because I see this exercise being doled out more than a few times, which means that every instance must involve someone deciding what features should be added. There's also a limit to how much can be added to the same handful of projects over time.

Can't ask all candidates to add the same feature over and over, or else this becomes throwaway code as well, which doesn't address any of the valid negatives you've raised.

> I know within an hour or so of talking to somebody if I want to work with them

Ha ha! I've had an HR department at a BigCorp tell me that there was a minimum duration to each interview (30 minutes for phone screen, at least 45 but preferably an hour for in-person), regardless of how they were doing. Their thinking was that more time spent by us would cause the candidate to consider us a more desirable employer. You can imagine my anguish at having to speak endlessly with people who would clearly never cut it on my team.

"But you can't just walk them out after an hour!"

Re: Technical interview performance is kind of arbitrary

#100

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

superuser2 wrote: post #90

rm_-rf_slash wrote: post #73

Earlier quoted context omitted.

Startup A asked me to do a take-home programming challenge to prove my skills, as well as a general algorithm test to give them ideas how to run their core architecture. This took hours, I felt I was being asked to do their job for free (on the second test), and the results were pathetic. Startup B gave me an assignment to add a feature to their API and have my work merged with their active code base. I was compensat…

Option B is explicitly prohibited in your employment agreement for most salary workers. I would never consider working for a company that required me to violate a contract just for a chance to work there.

In my experience this hasn't been the case. The closest I've come was an employment contract that required me to notify my employer of any work on the side. This has happened only once over more than a decade of work in this industry.