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

Ask HN: Measuring the long-term benefit of interview code tests?

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 76 posts

Re: Ask HN: Measuring the long-term benefit of interview code tests?

#61

Post by alain94040 »

kasey_junk wrote: post #55
errcorrectcode wrote: post #51

Earlier quoted context omitted.

I think we should use interviews for basic screening purposes only and skip determining "who is awesome from just signals". Instead, shift to a flexible hours paid trial period where potential colleagues get a better assessment. Measure by doing and interacting around doing, not by guessing, hazing, trivia, interrogating, or whiteboard hand-waving.

The issue with paid trials are 2 fold: If you are talking about short term trials many devs are bound by anti-moonlighting employment agreements that either outright bar working for someone else or require notification. For long term trials you severely limit your hiring pool because that is effect temp-to-hire which many devs simply will not do.

The first issue could be fixed legally. Just like California makes non-compete in-enforceable, it could pass a law that says short-term moonlighting can’t be in employment agreements. This way, you could take a week off from your current job, and actually work for a week for an employer that you are interested in. Fully paid.

Re: Ask HN: Measuring the long-term benefit of interview code tests?

#62

Post by kasey_junk »

alain94040 wrote: post #61
kasey_junk wrote: post #55

Earlier quoted context omitted.

The issue with paid trials are 2 fold: If you are talking about short term trials many devs are bound by anti-moonlighting employment agreements that either outright bar working for someone else or require notification. For long term trials you severely limit your hiring pool because that is effect temp-to-hire which many devs simply will not do.

The first issue could be fixed legally. Just like California makes non-compete in-enforceable, it could pass a law that says short-term moonlighting can’t be in employment agreements. This way, you could take a week off from your current job, and actually work for a week for an employer that you are interested in. Fully paid.

I’m not a legal expert in this but am fairly certain it already is illegal in California.

I was not working in an environment that could only hire California developers. If I were I might more seriously consider the option.

That said, I’m guessing you’d still get people who would balk at moonlighting even if it was allowed.

Re: Ask HN: Measuring the long-term benefit of interview code tests?

#63

Post by nameisname »

alain94040 wrote: post #61
kasey_junk wrote: post #55

Earlier quoted context omitted.

The issue with paid trials are 2 fold: If you are talking about short term trials many devs are bound by anti-moonlighting employment agreements that either outright bar working for someone else or require notification. For long term trials you severely limit your hiring pool because that is effect temp-to-hire which many devs simply will not do.

The first issue could be fixed legally. Just like California makes non-compete in-enforceable, it could pass a law that says short-term moonlighting can’t be in employment agreements. This way, you could take a week off from your current job, and actually work for a week for an employer that you are interested in. Fully paid.

This would mean you would have to work a ton of extra, waste significantly more time than a day with the current interviews approaches, or be "interview hopping" with no steady job for an extended period if nobody hired you. Which could have gaps between "moonlight" sessions. Which could mean you end up broke.

Re: Ask HN: Measuring the long-term benefit of interview code tests?

#64

Post by nameisname »

handrous wrote: post #35
nefitty wrote: post #33

Earlier quoted context omitted.

The clear requirements of take home tests make them my favorite. They allow me to express how I work: get a list of reqs, walk away and think about them, make some decisions on directions, then let the code lead me. I strike the style required. I capitalize on opportunities to make decisions I can discuss. "I used tape instead of jest because this example product will be distributed to many developers. The reduced AP…

Trouble is, unless more of the industry starts doing them so they're unavoidable, I'm going to skip companies that put these anywhere other than at the tail end of their process. I'm not putting in half a day of work for zero pay to help you with your first-pass weed-out phase before we bother to make sure we align otherwise and this looks like a good fit. Thanks, bye, next (employer) candidate.

I agree and generally say I'm willing to an alternate, live coding approach instead. I'm not putting in hours and hours in some random take home that may or may not be discussed down the line. Been there and done that so many times. Most of the time it didn't even align with the job.

Re: Ask HN: Measuring the long-term benefit of interview code tests?

#67

Post by kovac »

kspacewalk2 wrote: post #5
daviddever23box wrote: post #4

Earlier quoted context omitted.

I'd be careful to call that out as a negative; if the culture fit wasn't right, and the candidate would have been a net negative to the team, it shouldn't matter where they end up next, unless (of course) the candidate that was actually hired ends up being an even worse fit (ergo the need to fix your hiring process).

On the other hand, "they would not have been a good fit" sounds suspiciously like a blanket, non-falsifiable denial of failure. I other words, bullshit.

"Culture fit" has become like the currency of recruitment. Supposedly what you may have to pay with for a potentially great engineer (technically) about whom the hiring team didn't feel comfortable with. I think the original question is a great one. Do we actually put these intuitions to the test?

Re: Ask HN: Measuring the long-term benefit of interview code tests?

#68

Post by kovac »

leeoniya wrote: post #32
kasey_junk wrote: post #8

I don't know if my current company does, but when I first implemented them for a company I worked for ~15 years ago we definitely did. At that company (which was a ~200 engineer, privately held, software company) we found a few things: - in person tests were less predictive than take home tests. - tests that did not provide automated test cases as examples were less predictive than those that did. - there was virtual…

> there was virtually no predictive power to 'secret test cases' that we ran without providing to the candidate. this brings back some unpleasant memories of a take-home i got from a FAANG. basically i was given a loose spec to implement, with no real data or test cases (and was told that none would be provided when i asked). after submitting my work i received a terse rejection with 0 constructive feedback for my 6h…

In one interview, I was given a timed hacker rank problem with a screen share with 2 interviewers. The sample tests passed and the real tests passed except for 2 (from what I remember) that timed out on large data sets. Before the tests were run, I already highlighted the part of the code that's the bottleneck and asked if I could copy the code to Visual Studio (the test was in C#) because the standard lib has a data structure for this use case that I hadn't used in a long time but I couldn't get the code to compile on hacker rank. I wasn't allowed to use the IDE and I was also denied access to the standard lib documentation (in front of then through the screen share). I couldn't implement the data structure within the time limit. I failed the interview. I still wonder what the point of that test was.

Re: Ask HN: Measuring the long-term benefit of interview code tests?

#69

Post by Aeolun »

yupper32 wrote: post #42
Aeolun wrote: post #36

We don’t do coding tests at all. We do one 30-60m interview that covers some general tech questions and motivation. So far we’ve hired 7 decent and 3 great people. No truly bad people have made it through that pipeline yet. I can’t say anything about why, and I’d be prejudiced in any case.

What is motivation in this case?

Things like why you want to change positions, what motivates you, what tech do you like and why.

Re: Ask HN: Measuring the long-term benefit of interview code tests?

#70

Post by maxgfaraday »

The main thing that matters is training managers properly. Training management to be clearer about how they communicate goals and how transparent they are. The fault is not with candidates. Making sure a candidate can communicate clearly and effectively and has some passion for the position is all that you can really do at the interview level. The rest is quite frankly having better management and a culture of being helpful. Metrics on your org should be about how clear are the processes and planning toward goals and how well do they get communicated and executed. I worked for a MAAAN company and this one didn’t get it right. I figured they just made the decision that it is better to crank through people than actually grow them - since they were never short of candidates. This was pretty clear from their promotion culture and assessments that rewarded selfishness. Bottom line... train managers. Build the scaffolding to grow competent, empathetic, managers. Communication and clarity and empathy wins over everything else. F** programming test hazing. Commit to the people in the organization. Done.
Post reply on HN