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

The Terrible Technical Interview

techcrunch.com

Post reply on HN
Print view View original

71–80 of 236 posts

Re: The Terrible Technical Interview

#71

Post by frostmatthew »

fsk wrote: post #40
geebee wrote: post #34

Earlier quoted context omitted.

Arg! I'm on my phone and I meant to upvote! Apologies, this was a very insightful comment. I had never thought of it this way before but this is an instance of Bayes's rule. If the false negative rate goes too high and the percentage of good programmers is small then yes, the process could actually increase the odds of a bad hire.

Actually, it happens as long as your "stricter hiring practices" increase your false negative percentage by a lot more than they decrease your false positive percentage. Try it out with some numbers. 10100 candidates, 100 are "good". Suppose you have 2% false positives and 1% false negatives. You hire 99 good candidates and 200 bad candidates. Suppose now you have 0.5% false positives and 90% false negatives. (You de…

> Try it out with some numbers. 10100 candidates, 100 are "good".

What you're attempting to do works well for hypothetical drug testing[1] or terrorists but not for hiring developers (or anyone else). With the numbers you used you're proposing that less than 1% of all candidates are "good" - nobody would reasonably set the "good" threshold to include only the top 1% of developers.

[1] https://en.wikipedia.org/wiki/Bayes%27_theorem#Drug_testing

Re: The Terrible Technical Interview

#72

Post by SnacksOnAPlane »

philbo wrote: post #12
StevePerkins wrote: post #6

I do almost all of the technical phone screens for my company. The process starts with a "where-do-you-see-yourself-in-5-years" personality screen, with an H.R. drone or outside recruiter. It moves on me, and then on to a brief "homework" coding exercise that we ask people to write and submit. If we like their code sample, then they come in for the panel of "whiteboard-exercise" people who conduct the face to face ro…

Although I believe everything you say, I'd like to provide a counterpoint. I think I'm a pretty good programmer and I've got a reasonable body of work on GitHub to back it up, but I've often failed technical interviews because I go to pieces under the pressure and my brain just stops working. I've been a dev for > 15 years but if anything I've got worse at interviewing over time. I only apply for positions that I gen…

I felt bad about my nervousness in interview situations too, so I started taking improv classes. Now interviews don't give me any performance anxiety at all; once you've performed in front of a large audience with no idea what you're going to say or do, it makes interviews a cakewalk.

And remember, even though the primary skill you're interviewing for is coding, they are also testing you for communications ability. Being able to clearly and concisely explain what you're doing is at least as important as being able to get things done.

Re: The Terrible Technical Interview

#73

Post by SnacksOnAPlane »

skwirl wrote: post #58
tptacek wrote: post #44

Earlier quoted context omitted.

Having performed a thousand interviews by now, I am awestruck by how poor the software development talent pool is. My experience: exactly the opposite .

Steve works for a relatively unknown company making products for businesses, mostly using Java/C#, whose technical staff seems to be based in Atlanta, which is not a super attractive city for tech workers. Your experience comes from matasano, a company where people get paid to be hack, a dream job for many techies, with offices in New York, Chicago, and Silicon Valley. Is it surprising that your experience is exactly…

Why is Atlanta not attractive to tech workers? Georgia Tech has a phenomenal CS program, and we've got a pretty large and diverse startup population.

I'm not sure if what you're saying isn't true, or if I'm just biased and not able to see Atlanta from an outsider's perspective.

Re: The Terrible Technical Interview

#74

Post by ams6110 »

cpprototypes wrote: post #46

I think this would be a fair and effective interview system: 1) College graduate: Keep the traditional algorithm programming tech interview. But allow the use of a laptop (no whiteboard) 2) 2 - 7 years engineer: Require a github side project or give a home coding test. Interview will focus on discussing the project implementation. Also ask them to add a simple feature. 3) 7 - 15 years engineer: Ask them to come to th…

Are you actually involved in screening candidates and making hiring decisions?

Re: The Terrible Technical Interview

#75

Post by tptacek »

waterlesscloud wrote: post #69
skwirl wrote: post #58

Earlier quoted context omitted.

Steve works for a relatively unknown company making products for businesses, mostly using Java/C#, whose technical staff seems to be based in Atlanta, which is not a super attractive city for tech workers. Your experience comes from matasano, a company where people get paid to be hack, a dream job for many techies, with offices in New York, Chicago, and Silicon Valley. Is it surprising that your experience is exactly…

There's another big factor at work. If you read Thomas's recent post on Matasano's hiring process [1], they were looking to funnel people in . Steve's process seems pretty clearly designed to filter people out . Compare the idea of sending would-be candidates books to study and the idea of an interview process that COMPLETELY EXPOSES candidates. One is trying to bring people in, the other is trying to drive them out.…

I like this summary and plan on stealing it from you.

Re: The Terrible Technical Interview

#76

Post by SnacksOnAPlane »

fsk wrote: post #59
lukeschlather wrote: post #45

Earlier quoted context omitted.

Finding out how someone reacts to being told they are wrong when they know that they are right is a totally valid interview technique. Furthermore, I think past basic fizzbuzz questions, complex interview questions are good, but someone failing to get an objectively correct solution to an objectively difficult problem is just one signal among many. The goal of asking the questions should be to gather lots of other si…

If someone was playing emotional tricks on me during an interview, such as telling me I'm wrong when I'm right, I'd lose interest in the opportunity. One interviewer tried yelling at me for no reason, just to see if I would react or flinch.

I had an interviewer tell me that I was wrong that DNS ran over UDP. Not sure if the interviewer was trying to run some psychological test or if he was just wrong.

Re: The Terrible Technical Interview

#77

Post by frostmatthew »

golergka wrote: post #10

I'm going to go against the popular opinion here: I don't believe that technical interviews are broken and need fixing. Of course, we know as engineers who deployed code filled with hacks and known bugs to production, everything is broken. The difference is only how broken it is. Let's fix our approach to quality and security, ability to estimate and other things that are much more broken first.

> I don't believe that technical interviews are broken and need fixing

I think one of the reasons so many developers feel the process is "broken" is because it's all they know (i.e. most developers didn't have a previous profession).

For most jobs it's not practical or possible to get any insight into how a person will do that job prior to hiring them. Whiteboarding isn't intended to perfectly mirror "real life coding" - it's intended to give some insight into one's ability to write software to solve a problem. It's not perfect (and it can certainly be done extremely poorly!), but it shouldn't be dismissed as broken or useless any more than one should suggest actors shouldn't have to audition for roles.

Re: The Terrible Technical Interview

#78

Post by swatow »

msoad wrote: post #23

I live in Silicon Valley so I have tons of Software Engineer friends. I also have a friend who's a heart surgery researcher at Stanford. When we talk about our hiring process he just laughs and thinks its impossible to do something remotely close what we do in Software in their field. It seems Software is the only field that people have to do some serious work for the interviews.

Maybe they should. Studies have found that ratings of a surgeon skill based on a video recordings of surgery, are predictive of patient outcomes[0]. The problem with associating prestige and respect with not stooping to being tested, is that testing can be useful and necessary.

http://psnet.ahrq.gov/resource.aspx?resourceID=26950

Re: The Terrible Technical Interview

#79

Post by tptacek »

StevePerkins wrote: post #48
mtviewdave wrote: post #33

Earlier quoted context omitted.

> "I see that you've spent X years using Subversion for source control. What are your opinions on trunk-first development vs. branch-first development?" Actually, this demonstrates a problem right here. It's not clear to me what you mean by these terms. A quick Google search ("trunk-first vs branch-first svn") suggests that you're not using common terminology. After thinking about it for a minute or two, what I _thin…

In an actual interview, I would only pull out that specific example for a candidate who's worked with CVS and Subversion almost exclusively. The actual question is also a bit more verbose: Have you worked for a company that strives to do as much development as possible in 'trunk', creating a release branch near deployment time for production bugfixes? Have you worked for a company that preferred to branch at the outs…

Exactly why is it that you would making a screening decision based on version control practices? Of the many things you'll need to ramp candidates up on, this seems like one of the very easiest. Not only that, but because most firms do release management a little differently from each other, there's some VC ramp-up effort you'll need even with people who have mastered your VC tool.

I feel like dev interviews are full of questions like this, things that require some expertise and experience to answer, but do virtually nothing to predict on-the-job performance.

When you ask an interview question, you are pricing candidates. That's obvious when you think about it: you're screening, and so your questions alter the supply of candidates that will hit the bottom of your screening processes. Fewer selectees -> poorer employer BATNA -> higher prices.

Do you really want to price candidates based on how they use version control tools? How much are you willing to pay extra for people who have a lot of experience with different VC methodologies? Are you sure the weight of your questions about VC match up with the (hopefully minimal) premium you're hoping to pay for VC expertise?

Re: The Terrible Technical Interview

#80

Post by StevePerkins »

tptacek wrote: post #63
StevePerkins wrote: post #62

Earlier quoted context omitted.

I seldom post lengthy comments on HN, and when doing so I tend to include qualifiers such as, " I know that the Bay Area is overrepresented among HN readers, and the preceding opinion is based on a perspective from elsewhere." ... "I know that 20-somethings are overrepresented among HN readers, and the preceding opinion is based on an older perspective." Etc. Invariably, one of the top replies boils down to, " Hey! I…

I'm neither a 20-something nor in the valley. I'm (I think) older than you are, and in Chicago, which is even less of a technical hub than Atlanta.

Sorry, my remark wasn't referring to you exclusively, just noting a frequent trend. Fair enough.
Post reply on HN