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

31–40 of 236 posts

Re: The Terrible Technical Interview

#31

Post by napoleond »

ditonal wrote: post #4

In my experience, a lot of companies are combining _all_ these things. So you're expected to do a phone interview, a test project/coding test, a whiteboard test, and the management brown-nosing at the end of it where you get to pitch that you've studied a hard technical skill your whole career just because you're so passionate about getting woken up at 3AM on PagerDuty to build _their_ vision, and definitely not beca…

> I'm convinced one huge reason all this happens is to discourage job-hopping, because in this market, liquidity would probably help salaries move up faster.

Walk yourself through that for a second. You're saying a company that's hiring would intentionally make the process difficult for applicants in order to help their competitors retain their employees? That doesn't make sense. Even if they conspired with said competitors for this purpose, they would simply be ceding the hiring advantage to anyone who wasn't conspiring with them.

Occam's razor suggests a simpler answer: it turns out that identifying good software workers is a hard problem.

Re: The Terrible Technical Interview

#32

Post by kelukelugames »

foz wrote: post #17

In my organization, we start by looking at what the candidate has actually done. We ask for a github profile, and any side projects they might have worked on. If the CV and body of work look interesting, we go on to a phone screen - general questions, clarifying points on the CV, explaining the job, answering questions. For the on-site interview, we ask candidates to bring their laptop. We advise them to use a typica…

Wow, this is my worst nightmare. I freeze anytime a co worker is near my desk because I worry they will judge how I type and get around the IDE. Of course that just makes the vicious cycle worse.

Re: The Terrible Technical Interview

#33

Post by mtviewdave »

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…

> "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 _think_ you're asking is "should all development happen on a common branch, or should developers create separate branches for individual features/fixes, merging back into the mainline when finished". And, indeed, I'd be happy to have a conversation with you about this.

But if it takes me a couple of minutes to figure this out while just sitting here at home, in the pressure of an interview, I'm probably going to fumble, or say "I don't understand what you mean", which will make me wonder if I've blown the entire interview. This despite the fact that I've been programming for 20 years and have used a number of version control systems (CVS, ClearCase, P4, Subversion, and most recently Git).

Re: The Terrible Technical Interview

#34

Post by geebee »

fsk wrote: post #5

False negatives are a lot worse than most interviewers think. (False negative = you pass on a good candidate, false positive = you hire someone who turned out to be unqualified) If a "good" candidate is a 1-in-100 find, then each false negative means you have to look at another 100 candidates. Also, if you decrease your false negative rate by more than you decrease your false positive rate, you're actually hiring MOR…

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.

Re: The Terrible Technical Interview

#35

Post by SilasX »

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…

With respect, I think you might just be making (what we should now call) the "Fizzbuzz fallacy": "99% of applicants can't answer basic questions, therefore the talent pool is poor".

Really, it's more like "99% of the people still searching, who don't have a documented contribution history, and don't have a network that lets them find good jobs in a heartbeat, who must resort to this to find a job[1], can't answer basic questions."

Most of the talent pool is working and has to be pried away; they won't show up through HR channels.

[1] Not a diss, by the way; I count myself in that set, though am still not "on the market", and still don't fail at fizzbuzz style questions.

Re: The Terrible Technical Interview

#37

Post by TACIXAT »

I get to interview candidate team members for the malware research team I'm on. We write a lot of code, but we're not really software engineers. Accordingly, I only ask people very basic things in an interview to see if they can use the tools they list on their resume. Often times it's something that can be handled with a single list comprehension (though no one every does that). It is astounding how few people can do what their resumes say.

I'm sure it's stressful if you don't know what you say you do. Then again, if you list 6 programming languages on your resume and can't xor decode a string in the one I let you choose from that list, you deserve to sweat a little.

Re: The Terrible Technical Interview

#38

Post by ditonal »

napoleond wrote: post #31
ditonal wrote: post #4

In my experience, a lot of companies are combining _all_ these things. So you're expected to do a phone interview, a test project/coding test, a whiteboard test, and the management brown-nosing at the end of it where you get to pitch that you've studied a hard technical skill your whole career just because you're so passionate about getting woken up at 3AM on PagerDuty to build _their_ vision, and definitely not beca…

> I'm convinced one huge reason all this happens is to discourage job-hopping, because in this market, liquidity would probably help salaries move up faster. Walk yourself through that for a second. You're saying a company that's hiring would intentionally make the process difficult for applicants in order to help their competitors retain their employees ? That doesn't make sense. Even if they conspired with said com…

Do you realize that there was a class-action lawsuit where the "competitors" Google, Apple, Adobe etc were working together to not poach each other's employees? You're acting like I'm a conspiracy nutjob when there were emails from Eric Schmidt and Steve Jobs where they admitted they were illegally colluding.

Do you realize that many "competing" startups have the same VC firms investing in them who don't want bidding wars between their engineers?

They want new talent but they don't want their current talent bouncing around for more money.

Re: The Terrible Technical Interview

#39

Post by cubano »

maigret wrote: post #8
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…

Interesting report! Did you weight in this - the bad developers are most likely to interview many times, so they appear often to you? Talents either get advised into a new job or stay where they are, because many shops know they are valuable, I'd think.

> Did you weight in this - the bad developers are most likely to interview many times..

Which implies, almost by definition, that they will become much better at the process over time and eventually become very good at gaming it, therefore making it even less reliable.

Re: The Terrible Technical Interview

#40

Post by fsk »

geebee wrote: post #34
fsk wrote: post #5

False negatives are a lot worse than most interviewers think. (False negative = you pass on a good candidate, false positive = you hire someone who turned out to be unqualified) If a "good" candidate is a 1-in-100 find, then each false negative means you have to look at another 100 candidates. Also, if you decrease your false negative rate by more than you decrease your false positive rate, you're actually hiring MOR…

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 decreased your false positive rate by 4x but increased your false negative rate by 90x. This is typical for employers who look for every little excuse to reject someone.)

You hire 10 good candidates and 50 bad candidates. Your "good hire" percentage went down, and you're churning through a lot more candidates to meet your hiring quota!

So, "it is better to pass on a good candidate than hire a bad candidate" is FALSE if you wind up being too picky on passing on good candidates.

Assuming you can identify losers and fire them after a year or two (with decent severance to be fair), you're actually better off hiring more leniently.

It's also even worse when you realize that the candidate pool is more like:

10200 candidates, 100 are "good", 100 are "toxic", and the toxic people excel at pretending to be "good".

Also, the rules for hiring are different for a famous employer and a no-name employer. Google and Facebook are going to have everyone competent applying. If you're a no-name startup, you'll be lucky to have 1 or 2 highly skilled candidates in your hiring pool.

Post reply on HN