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

71–80 of 246 posts

Re: Technical interview performance is kind of arbitrary

#71

Post by maxaf »

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…

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.

Re: Technical interview performance is kind of arbitrary

#72

Post by maxaf »

Retric wrote: post #56
maxaf wrote: post #49

Earlier quoted context omitted.

This kind of depends on where the candidate is coming from. Those who're applying directly are obviously already expressing some desire to work with us. Recruiters should be instructed to give a consistent narrative, too. Good recruiters will also pitch the code test as a sign that we're a serious employer and take people seriously. I don't like phone conversations that serve as the first line of candidate triage. Ma…

A 4h test when your still rejecting 90+% of people is ridiculous. You are basically rejecting anyone that is talented ahead of time. I personally know two programmers that did not create a resume for 20 years and still got jobs offers. Remember anything more complex than a phone screen is going to start turning people away.

The 90%+ rejection rate was at a BigCorp that refused to give people code tests ahead of a technical phone screening and onsite interview.

Re: Technical interview performance is kind of arbitrary

#73

Post by rm_-rf_slash »

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 compensated $300 for my time. The feature worked, although I don't know if they still use my code from 3 years ago.

In the end, I worked for neither. But if I were forced to choose between them, I know my answer in a heartbeat.

Will name companies if requested.

Re: Technical interview performance is kind of arbitrary

#74

Post by alive2007 »

Minor question; is it just me or is the "Results of Interview Simulations by Mean Score" a bit difficult to parse? I understand that observing the behavior of any singular cohort involves looking at the endpoints of the cohort's curve at the horizontal line 'x=n', where n is number of simulations you wish to observe (the right point of the curve at x=n is P(fail) of the worst performer in the cohort at n simulations, the left point of the curve at x=n is the P(fail) of the best performer); which is why the gap between endpoints within a singular cohort decreases as n increases. But it seems kind of counterintuitive to observe any other kind of trend -- shouldn't the information be graphed as P(fail) being a function of # of simulations, as opposed to the other way around, seeing as the latter is the independent variable?

Re: Technical interview performance is kind of arbitrary

#75

Post by mentatseb »

The conclusion is misleading due to 2 wrong assumptions:

1. The population is heterogeneous: interviews test different skills. All interviews don't test the same set of skills, which is mandatory to compare interview scores because scores are aggregates of these skill tests. Different job opportunities means different skills to test, so it seems reasonable to assume that people evaluation vary for different job opportunities, and thus their scores vary for different interviews.

2. The observations are not statistically independent: past interviews may influence future interviews. People may get better at passing interviews or conducting interviews over time. This would impact their score. It would be good to study the evolution of individual scores over time.

While (1) should strongly limit the conclusions of the study, the complete analysis may simply be irrelevant because of (2) if the statistical independence of observations is not demonstrated. Sorry guys but this is Statistics 101 introductory course.

Re: Technical interview performance is kind of arbitrary

#76

Post by pklausler »

dragonwriter wrote: post #50
pklausler wrote: post #42

Earlier quoted context omitted.

In most other jobs, it's harder to earn a PhD in the field while not being able to perform basic skills competently. But not computer science. It's damned depressing how low the proportion of new grads is that can write code for me to, say, sort a linked list. So the factor is way larger than 10x. We're not differentiating the great programmers from the merely competent; we're struggling to distinguish the capable fr…

> In most other jobs, it's harder to earn a PhD in the field while not being able to perform basic skills competently. But not computer science. I think that you are confusing "computer science" with "software development". It may be easy to get a Ph.D. in computer science and be poorly suited for work in the software development industry, but that's no more surprising than the fact that people can get Ph.D.'s in eco…

All that I'm saying is that it's possible to get a degree in CS from some schools without being able to demonstrate a mastery of concepts like pointers or recursion.

Re: Technical interview performance is kind of arbitrary

#77

Post by adregan »

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 have been interviewing quite a bit lately, and I have found that my favorite interviews are take home tests that are representative of the kind of work I would be doing at said company. I am more comfortable with that style and I perform better.

More than that though: it gives me an idea about what it will be like to work at the company. If my only experience is studying algorithms and coding on a white board, I have a hard time knowing whether or not I will enjoy working at this company for years of my life.

A promise that you can work on "interesting problems" is hardly enough. I'm curious why more companies don't take the opportunity to sell themselves.

Anyhow, I've hung a whiteboard in my room and try to practice for interviews as much as possible. It's incredibly draining and produces a feeling completely opposite to how much fun I have building things. This feels like getting started on the wrong foot.

Re: Technical interview performance is kind of arbitrary

#78

Post by Ocerge »

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.

Re: Technical interview performance is kind of arbitrary

#79

Post by cmccomas »

muddyrivers wrote: post #61
jessedhillon wrote: post #25

Earlier quoted context omitted.

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

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

Do you do that on the spot or is it a "take home" assignment? I've known many solid programmers (myself included) that could code anything you want, but if you put them in a room, sit there and watch them do it, they'd freeze up. On the other hand, if you give them a project, give them a timeframe to develop it, then have them walk you through what/why they did, they would absolutely excel. It's sitting there in front of someone(s) and the expectation, that would just cause them to freeze up.

Re: Technical interview performance is kind of arbitrary

#80

Post by t0mbstone »

maxaf wrote: post #43
tiglionabbit wrote: post #35

Earlier quoted context omitted.

You need to verify that the candidate actually did the take home test, and didn't hand it to their more talented friend.

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.

Post reply on HN