Technical interview performance is kind of arbitrary • Hacker News Board

Re: Technical interview performance is kind of arbitrary

#81

Post by chrisper » Wed, Feb 17, 2016, 8:41 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.

You are right with that a whole day onsite interview is more time consuming.But personally, I think I can do better in a face-to-face evaluation than on a coding challenge where I have to guess the test cases from some vague description. In fact, face-to-face can show the interviewer how I think and what kind of questions I ask to figure out the way to solve an issue.

Maybe it is my lack of interview experience, since I only had like 3 or 4 so far, but I only 1 out of them left me with a good experience after the coding challenge (even if I did not get an offer yet).

Re: Technical interview performance is kind of arbitrary

#82

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

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: Expensive, requires interrupting our team, needs a fully planned and well executed itinerary - but is perfect for getting to know someone, getting the feel for their personality and interests, and is the best way to sell someone on the opportunity.

3) Work sample: we usually do this for interns[1] and pair it with a ~1 hour conversation (either before or after, doesn't really matter to us) on what the company is like and what they would be working on. Obviously, work samples suffer from the same deficiencies as a take home test for cultural fit and the like, but it's the best we can do for interns!

[1] https://gastrograph.com/blogs/gastronexus/interviewing-data-...

Re: Technical interview performance is kind of arbitrary

#83

Post by WorldMaker » Wed, Feb 17, 2016, 8:45 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…

I honestly feel like take home tests are "busy work" and just as volatile as any other sort of technical interview for showing actual skills versus a real world environment.

2-4 hours is a lot of time to ask of somebody, regardless of their circumstances. Would you pay a contractor's salary rate for that work? Are these take home tests results worth $100/hour? $40? Every take home test I've encountered I've wished someone would pay me for that time, based on the opportunity costs of what I could have been doing, but maybe I'm cynical and pessimistic.

Re: Technical interview performance is kind of arbitrary

#84

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

maxaf wrote: post #62

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…

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 afterwards. And from a practical perspective, somebody who's good and employed is unlikely to expend the effort unless you're a very special company, too, which complicates the search.

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

See...this I don't get. I know within an hour or so of talking to somebody if I want to work with them, and past that literally everything else, aside from compensation, is belaboring the point. And I mean "an hour"; if I'm not enjoying the process at that point, I'll usually suggest we end the interview. But on the flip side, because I am a good community member and I network heavily, I might in those situations go "hey, I think this isn't a good fit, but I want to introduce you to my friend who I think might be a better fit." I've done this before, and I can't do that (and wouldn't be inclined to do it) after you've burned half a workday on a monkey-work project.

I think there are reasonable ways to get a demonstration of work, but they involve investment and give-a-shit that I think most companies are way too happy to be bad cultural citizens to consider. Like, here's a coding test I'd be happy to do: "add this feature to this open-source project you probably use every day", well, that'd be different. I'd be getting something for my time, too, both in terms of feature and in terms of public recognition for open-source contribution. But one-way, dance-monkey-dance, throw-it-away-after stuff? That's very selfish, and I think we should be better than that.

Re: Technical interview performance is kind of arbitrary

#85

Post by hire_charts » Wed, Feb 17, 2016, 8:49 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.

Presumably you (the employer) have less time to do on-site interviews than to assign take-home projects, so landing a real interview is a much better indicator that my (the job-seeker) time will be well-spent. (Hiring is a two way street.)

Re: Technical interview performance is kind of arbitrary

#86

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

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.

Re: Technical interview performance is kind of arbitrary

#87

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

Technical interviews are a form of hazing. Engineers often suffer from imposter syndrome, especially during an interview. Those who have already been hazed and accepted to the club will turn around and put potential candidates through the same humiliating process. And what's worse is that demonstrating you have superior capabilities in one area or another can be seen as a threat to the interviewer and they may give you a thumbs down based purely on their own insecurities. What ends up happening is that, just like in college fraternities, is that everyone ends up being similar, both culturally and in terms of abilities.

If I had it my way I would do away with the interview process altogether and do something more akin to an internship. Potential employees could start their engagement with a company by working (for pay, mind you) on a very limited basis to solve actual problems that need solving (i.e. "write an algorithm that's 10% more efficient", "create a tooltip that's aware of the viewport in React", etc). Based on their output their engagement could be ramped up until they are brought on as a full time employee. That way it ends up being completely merit based. You can either solve these problems or you can't. And whether or not they ultimately end up becoming an employee doesn't end up mattering because both parties are compensated along the way.

This would obviously put the burden on the company to boil its problems down into smaller, isolated efforts but that's something all companies should be trying to do anyways. In the end, they just want some code written that will end up solving some problem for their customer.

Re: Technical interview performance is kind of arbitrary

#88

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

t0mbstone wrote: post #80

maxaf wrote: post #43

Earlier quoted context omitted.

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.

"plagiarism based on a Google search" Uh... If the solution is readily available on Google, and they can solve the problem effectively with that solution, then they didn't plagiarize. They operated exactly the way they should work in a real world scenario. The worst kind of employees are the ones who insist on re-inventing the wheel every chance they get, instead of using industry standard libraries.

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

Re: Technical interview performance is kind of arbitrary

#89

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

Ocerge wrote: post #78

pklausler wrote: post #31

I have learned that an (in)ability to program "in the small" correlates very well with an (in)ability to program in the large, and now ask mostly simply questions whose answers are things like one-line Boolean predicates to test for well-defined conditions. It is paradoxically easier for an inept candidate to fake his way through an algorithm design question than it is to fake the coding of a simple test for "determi…

I've moved to doing something extremely simple: just give me pseudo-code for indexOf given a string and a character. If you can't write the 4-5 liner for linearly searching a string for a character, then there's not much point in moving further. It is shocking how many people get tripped up by it.

I'm similarly shocked, but it's just how things are now. I'm not sure how I could set the bars any lower.

Re: Technical interview performance is kind of arbitrary

#90

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

rm_-rf_slash wrote: post #73

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…

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.