Live data from Hacker News

Ask HN: Whiteboard interviews don't work, what's your ideal technical interview?

news.ycombinator.com

11–20 of 21 posts

Re: Ask HN: Whiteboard interviews don't work, what's your ideal technical interview?

#11

I've hired maybe 30 to 40 people over the past 15-20 years and interviewed atleast an order of magnitude more. I don't claim to have things figured out but I can create a list of things that owrk and things that don't work. Things that work: - white board interviews, they let you get a dialog going with the candidate, - take home work, they let the candidate work at their own pace - showing work samples, whether that…

Can't you tell if someone is taking someone else's work as their own? It seems like they wouldn't be as familiar with the code and wouldn't be able to explain why things are done certain ways. I feel like I'd be able to tell.

Re: Ask HN: Whiteboard interviews don't work, what's your ideal technical interview?

#12

I've hired maybe 30 to 40 people over the past 15-20 years and interviewed atleast an order of magnitude more. I don't claim to have things figured out but I can create a list of things that owrk and things that don't work. Things that work: - white board interviews, they let you get a dialog going with the candidate, - take home work, they let the candidate work at their own pace - showing work samples, whether that…

What about discussing past experience, previous projects? Are you unable to detect if the candidate is lying/faking?

Additionally, if unsure after this discussion, what about proposing small, relevant to the job paid project? Can't you afford this?

Re: Ask HN: Whiteboard interviews don't work, what's your ideal technical interview?

#13
I believe pg wrote in one of his essays that a hacker can immediately recognize another hacker, but it is impossible for a non-hacker to do so. Therefore the best method would be to let your best developers handle interviewing as they would be the best at recognizing skill.

Re: Ask HN: Whiteboard interviews don't work, what's your ideal technical interview?

#14
post #13

I believe pg wrote in one of his essays that a hacker can immediately recognize another hacker, but it is impossible for a non-hacker to do so. Therefore the best method would be to let your best developers handle interviewing as they would be the best at recognizing skill.

In that same essay I think he also mentioned you can't know fully how good a hacker is until you've worked with them. I still agree that the best developers will be able to see talent.

Re: Ask HN: Whiteboard interviews don't work, what's your ideal technical interview?

#15
Personally, I like the hackerrank or leetcode automated challenge as an initial first filter. It can be gamed by cheaters of course but that requires some work on the cheaters part. It allows me to start the test at a convenient time and in a standard format. Hopefully, it allows the company to be less stringent about skill sets and other resume keywords and simply test more people. Hopefully it makes job searches harder for resume spammers, cheats, and fakes. I suspect even a few really easy problems from these sites would be a useful filter.

Then perhaps a phone interview so that the company can confirm I'm likely not cheating.

Finally an onsite white board interview or written test or at the computer programming test. Yes I get nervous doing white board interviews but if the difficulty level of the problem is not too great it is a useful filter.

I dislike long take home work because it requires too much of a time sink and it could be abused by employers fishing for ideas, competitor information, or just wanting free work for one of their problem areas. Algorithm tests on hackerrank or leetcode or wherever are still useful practice but take home tests can be too job specific and therefore prematurely requires candidates to commit to learning a particular companies needs without the company committing anything in return.

Questioning candidates about their experience in an informal manner by conversation may be of some benefit, but is likely just testing how well the candidate has prepared various stories about their past employment and past projects. Unfortunately, abandoned projects that taught a candidate a lot and served their intended purpose may not make as good a portfolio or story as completed projects that were just cookie-cutter implementations of projects found in books or tutorials or elsewhere.

The important thing for all of these filters though is that they be carefully calibrated in difficulty to the companies needs and job sourcing pool. If your large top-N company carefully optimizes it's customer funnel with a/b testing but has no real employee hiring sanity checks, then that is not good. Randomly have one employee at the company white board interview another employee at the company from a different department. Secretly test your interview process with known good programmers from outside the company.

Re: Ask HN: Whiteboard interviews don't work, what's your ideal technical interview?

#16
post #3

Earlier quoted context omitted.

So in the case of trial jobs how do you narrow down the candidate pool to the point that you have few enough candidates that you can bring them in office and let them work for a day without the office just becoming an unmanageable Fiesta?

Trial jobs happen at the point that you would be ready to hire that candidate. This is after you have evaluated if they are excitable if they fit well in the current culture of your company or would bring a good change to your company culture, and if they have some level of technical expertise (they went to college, worked at another development position, or have side projects).

Trial jobs would be ok for some candidates, but I would be furious if, after spending a lot of time in the interview process, a company tells me only at the end that the job is a contract to hire job. Trial jobs should be advertised up front at the start of the process.

Re: Ask HN: Whiteboard interviews don't work, what's your ideal technical interview?

#17
post #10

From Laszlo Bock, former SVP of People Ops @ Google. > [1] The best predictor of how someone will perform in a job is a work sample test (29 percent). This entails giving candidates a sample piece of work, similar to that which they would do in the job, and assessing their performance at it. Based on the statistics he provided, it seems like a combination of work sample and behavioral questions will typically produce…

From this paper: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2853669

> On the basis of meta-analytic findings, this paper presents the validity of 31 procedures for predicting job performance and the validity of paired combinations of general mental ability (GMA) and the 29 other selection procedures. Similar analyses are presented for 16 predictors of performance in job training programs. Overall, the two combinations with the highest multivariate validity and utility for predicting job performance were GMA plus an integrity test (mean validity of .78) and GMA plus a structured interview (mean validity of .76).

Re: Ask HN: Whiteboard interviews don't work, what's your ideal technical interview?

#18
Whiteboard interviews DO work - if done right. Don't ask computer science questions. Instead give the interviewee real world problems to solve. And find out how he/she attacks the problem. What he/she would look at to solve the problem. What tools he/she would use and why. The key thing is to learn how the interviewee thinks through a problem. And how well the interviewee explains his/her thinking. I have interviewed and hired people for 10+ years and can testify that this approach work.

Re: Ask HN: Whiteboard interviews don't work, what's your ideal technical interview?

#19
Ask hard questions. It is important to understand the boundaries of a candidates knowledge. I don't trust company that lets me off easy, it feels like they aren't actually looking for a good fit.

Asking for a prepared presentation is a nice alternative to take home coding (If applicable to your work culture).

Phone call trumps videochat every time. Our communication isn't strengthened by a video chat unless there are prepared visual aids, don't solve problems that don't exist.

Let me know who I will be meeting during 'in person' interview. What teams are they on.

Live coding with a current employee is a good practice. Keep problems small, and loosely specified.

Re: Ask HN: Whiteboard interviews don't work, what's your ideal technical interview?

#20

I've hired maybe 30 to 40 people over the past 15-20 years and interviewed atleast an order of magnitude more. I don't claim to have things figured out but I can create a list of things that owrk and things that don't work. Things that work: - white board interviews, they let you get a dialog going with the candidate, - take home work, they let the candidate work at their own pace - showing work samples, whether that…

Can't you tell if someone is taking someone else's work as their own? It seems like they wouldn't be as familiar with the code and wouldn't be able to explain why things are done certain ways. I feel like I'd be able to tell.

If they show you a mid-sized project it would be very hard to look at it and have a better understanding than someone who intentionally ripped it off and read up on it themselves. That being said, I'm sure if you really grilled them on specifics you might be able to catch them off guard. The problem though is that is showing that you don't trust them from the start as opposed to showing them that you are interested to see what kind of coder they are. I would leave an interview if the interviewer seemed to only be asking questions to throw me off intentionally (I've done it once before).
Post reply on HN