Interviewing candidates • Hacker News Board

Re: Interviewing candidates

#81

Post by RogerL » Wed, Jun 10, 2015, 12:20 AM UTC

ericlippert wrote: post #30

RogerL wrote: post #10

"Red flags often surface at this point. I’ve had candidates with PhDs in computer science, for instance, who did not know that on a 64 bit architecture, pointers are 64 bits wide." Because learning 64-bit architecture is impossible for somebody that have proven that they can learn a field, perform research, and successfully write and defend a dissertation? '32 < 64' is beyond them?

No, because we are actually building telescopes here , and astronomy PhDs apply, and when they are not actually clear on the difference between a reflector and refractor telescope you realize, hey, this person is going to need to learn so much about the very basics of the field that they're applying for that it's not going to be a good fit. I've had candidates with PhDs in computer science who thought that pointers o…

On your latter point (pointers) I've heard that argument before. I work with somebody that turned out not to know about hash tables. I could spin a tale about how this meant they were so wide eyed they'd just be incapable of doing anything valuable (an argument made so many times on here). Instead, I took 15 minutes and taught them about hash tables and how to do them in C++. A few pointed questions about run time and the constants implied by the promise of O(1) (i.e a good question), and from then on every time a hash should have been used sure enough, they used one. Even showed initiative and added a memcache type interface to some of our code that was performing very slowly due to poor access patterns.

I guess it is lucky for us that when they interviewed they didn't have an interview question that involved hash tables, because they would have been bounced for not hitting the ground running.

I bet I know a lot about a field that you don't. I wouldn't bet that you couldn't walk in and pretty quickly become useful, given that you've learned other things, and at one time I didn't know this field either yet somehow, somehow, learned it. I think you would do just fine; and I think somebody that can get a PhD in CS can handle the math that 2^16 < 2^64, even if they haven't thought about the implications re allocations.

Re: Interviewing candidates

#82

Post by dbenhur » Wed, Jun 10, 2015, 5:46 AM UTC

> if we make a bad hire, that can drag down the productivity of a team for years

This is the essential cowardice of employers. Interviews are insufficient contexts to judge if someone can help move your business forward. Screen the incompetent, but just hire people and don't be afraid to let them move on if they don't work out after 2/=4/6 months.

Re: Interviewing candidates

#83

Post by kruczek » Wed, Jun 10, 2015, 8:06 AM UTC

EliRivers wrote: post #9

doragcoder wrote: post #7

I feel like I follow this template as well. Except, I like to add a small self assessment at the beginning of the interview. Like: Q: On a scale from 1 to 10 (1 being low) how do you rate yourself on "Programming Language Du Jour"? Then I can see if their self assessment is inline with mine. Which can help in reviewing the resume. I also like to ask for them to choose a project in the past to talk about, because then…

I was asked by a hip, happening, popular web-app related startup to rate myself in C++. I pointed out that Bjarne Stroustrup rated himself 7 out of 10 once. I wasn't as good as him, and I wasn't nearly as good as him, which left me the field of 5 and below. I can guarantee that some ham-fisted chancer who'd flicked through the "Teach Yourself C++" chapter summaries put himself down as an 8, though.

> I can guarantee that some ham-fisted chancer who'd flicked through the "Teach Yourself C++" chapter summaries put himself down as an 8, though.

It's very easy to filter out these guys though. I had one such come to my interview - on a scale 1-10 (10=best) the guy put 8s, 9s and 10s for several programming languages (C++, C#, Java, a few others); and that guy was fresh out of college.

Then during the interview it turned out the guy knows exactly nothing, even when I tried to talk with him about the most basic concepts of OOP (like, what is a class or an object), he couldn't provide any meaningful answer to lead the conversation further.

I have no idea how he hoped to pass an interview, perhaps he thought there wouldn't be anything beyond the online form to fill.

Re: Interviewing candidates

#84

Post by dvt » Wed, Jun 10, 2015, 6:57 PM UTC

smikhanov wrote: post #72

dvt wrote: post #17

I don't really get it. This is sounds like a very pretty typical software engineer interview process. The fact that these kinds of interviews suck, don't produce good hires, and yield a ridiculous amount of false negatives has been beaten to death. Unless you're Google (or Facebook), you are not getting thousands of applications a day. You don't need to emulate their hiring process. They do it for a reason (practical…

Oh wow: now this is a solid example of HN fandom. Google, Apple, Facebook, Microsoft, Dropbox, Evernote, Amazon, Airbnb, Uber, Square, PayPal and countless others are hiring their engineers using some variation of whiteboard coding. Engineers in those companies built literally 99% of the technology the author of the comment above uses every bloody day. From the browser he used to leave his comment, to operating syste…

Your point is logically inconsistent.

There's some evidence that the iPhone in your pocket, for example, may have been built via forced manual/child labor in Taiwan/Vietnam/China etc. The fact that the iPhone is a revolutionary (and generally game-changing) product doesn't somehow add to the virtuousness of how it was built.

Re: Interviewing candidates

#85

Post by georgemcbay » Wed, Jun 10, 2015, 11:29 PM UTC

boothead wrote: post #70

georgemcbay wrote: post #66

Earlier quoted context omitted.

I started my career being pretty terrible with interviews for reasons pretty well encapsulated in Thomas' article -- general nervousness, social anxiety, lack of confidence (in retrospect, I believe this was primarily an impostor syndrome issue). I've gotten better at it with age, but the improvement in my interviewing skill is completely unrelated to my improvement in programming skill, though I believe both continu…

I recently totally bombed a programming interview, and I always feel like I've done terribly, even if feedback afterwards is quite good. I'd be interested in hearing how you improved your performance in interviews, if you wouldn't mind sharing?

Partly it was just experience. Interviews (as done poorly in the tech industry) tend to follow certain patterns, the more you do the more you see the patterns and the more you can adjust for them.

Perhaps most importantly (and this is something that is often mentioned by people give interview advice but easy to ignore if you're a "meritocracy"-minded techie) I've gotten really good at just sort of taking control of the interview and leading it where I want it to go (while still being sure to display how I would be valuable to the company) rather than being a passive question-answer-er, but getting good at this is also pretty much just down to experience.