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

221–230 of 236 posts

Re: The Terrible Technical Interview

#221

Post by bshimmin »

rwallace wrote: post #180
bshimmin wrote: post #175

Earlier quoted context omitted.

I'm surprised you would say that there "hundreds of different definitions" of polymorphism. Here's one of the top-ranked results for the term: http://stackoverflow.com/questions/1031273/what-is-polymorph... If you look at the answers, aside from a few that are really poorly phrased, they all fundamentally say the same thing. If I were interviewing someone and asking them about polymorphism, I would expect a definitio…

> (I'd probably give them bonus points for mentioning what the Greek words mean, but only because someone who knows that is likely to be someone I'd enjoy working with.) I know what the Greek words mean, but it would never in a million years occur to me to mention it in an interview; I would have no way of knowing without being told that you would assign positive value to such.

I'm certain the vast majority of interviewers wouldn't care in the slightest if you demonstrated that knowledge; I just happen to have a degree in classics and thus a bias towards such things! (Not that knowing the meaning of two fairly common Greek roots really demonstrates much knowledge of classical languages, but there we are.)

Re: The Terrible Technical Interview

#222

Post by sytelus »

itsdrewmiller wrote: post #213
sytelus wrote: post #152

Earlier quoted context omitted.

No. Many companies have hiring rate of 10% [1] which means hiring 1 candidate may cost you 10 person-days assuming full day interviews for each candidate [2]. You can probably double that to cover the cost of phone screens, so let's say 20-person day of work per good hire. Assume you had 4 false negatives just because you are so aggressive and so a good hire ended up costing you 100 person days instead. This cost is…

You didn't actually respond to his comment. Assuming, for example, you have: * 99% of applicants are bad * 50% false negative (You look over about one good developer for every good developer you hire) * 1% false positive (one out of a hundred bad devs can snooker you into hiring) In that scenario, you're twice as likely to hire a bad dev as a good one. And if you halve your false positive rate by increasing your fals…

The following comment by @fsk which I think what you are describing is inaccurate:

if you decrease your false negative rate by more than you decrease your false positive rate, you're actually hiring MORE bad candidates

First false negatives (FN) and false positives (FP) are independent of each other. FP estimates how many bad developers you would end up having regardless of your FN. The FN determines how many good developers you would turn away regardless of your FP. If you are confused about this, well, these numbers are part of appropriately called "Confusion Matrix". I would highly recommand reading up on Wikipedia (http://en.wikipedia.org/wiki/Confusion_matrix) or any textbooks before you jump on commenting and through bayesian equation around because you are certainly not using right terminology. Also both of these are again independent of actual % of bad developers out there (i.e. whether market has 99% bad or 1% doesn't matter, FP solely determines what many bad developers you would end up with).

Next, it might be actually easier for you to think in terms of precision and recall instead of FP/FN. Interviewing process is nothing but classification problem and P/R is standard way to measure its performance. Again Wikipedia is your friend to brush up on that.

A classic situation in classifier performance is referred to as precision recall tradeoff. You can plot that on curve called RoC and choose your operating point. The way you typically do that is by quantifying how much you would get hurt due to loss in precision (~ more FP) compared to increase in recall (~ less FN). You plug the costs in equation and decide your operating point. For companies that can rapidly deal with FP, increasing recall may make sense and other way around. However in most cases there are too many other reasons that I'd listed should typically prevent you from lowering your precision too much.

Re: The Terrible Technical Interview

#223

Post by sytelus »

fsk wrote: post #219
itsdrewmiller wrote: post #213

Earlier quoted context omitted.

You didn't actually respond to his comment. Assuming, for example, you have: * 99% of applicants are bad * 50% false negative (You look over about one good developer for every good developer you hire) * 1% false positive (one out of a hundred bad devs can snooker you into hiring) In that scenario, you're twice as likely to hire a bad dev as a good one. And if you halve your false positive rate by increasing your fals…

I see what you're saying. I was pointing out the dangers of false negatives, but he responded that he hires 10% of the people he invites for an onsite interview. Even if you hire 10% of the candidates you on-site interview, that says nothing about your actual false positive or false negative rate. For all I know, he could be weeding out all the top candidates at the pre-interivew stage, and then hiring the best of a…

No, I did not say I hire 10% of candidates I interview :). What I said was that's a fair estimate in industry.

I feel you are truly confused about FP and FN. Whether there are 99% bad developers out there or if you hire 10% of candidates you interview - these both quantities are independent of FN and FP. FN says that you are turning away X good people and it's again independent of FP which ultimately decides how many bad developers you would eventually end up hiring regardless of other 3 quantities I mentioned. See here: http://en.wikipedia.org/wiki/Confusion_matrix

It's not easy to measure FN, FP, TN or TP. Even good people fail due to different reasons like bad manager and bad people may succeed despite of mediocre skills. Looking at who you had to fire or who got promoted doesn't give accurate measurements at all although they may serve as weak proxy. The scenario I described was hypothetical to point out that cost of FP is far more higher than additional cost in hiring due to FN.

Re: The Terrible Technical Interview

#224

Post by T_Rex »

SnacksOnAPlane wrote: post #73
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…

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.

I'm not entirely convinced that the CS program is phenomenal at tech. I wish it was, since it's my alma mater (ECE/PHYS 08). I've tried to hire people out of there for ebaynyc and now shopspring.com, but they don't seem nearly as prepared as the northeast college graduates. Tech seems way too old school. They only teach java (I'm pretty sure they don't even offer a functional programming class!), and all of the candidates that I talked to had no experience even building a simple web app.

Re: The Terrible Technical Interview

#225

Post by socrates2016 »

An issue with technical interviews is the shortness of the measurement. Real-life programming occurs over days, weeks, and months. You think about a problem and come up with progressively better solutions while thinking through and understanding tradeoffs. Its more a marathon than a sprint. Technical interviews are like sprints. So its as if you hire runners based on how well they can sprint but then race them in marathons.

Re: The Terrible Technical Interview

#226

Post by amarjeet »

I follow this process for most of tech/product/analyst type roles. Specifically, in the case of tech, to me, it really depends upon the level of coding exposure a candidate has. If he/she is a fresher then I would prefer some real-time exercise (white-board/phone/skype exercises) - it helps me get the idea of a person's thought process. I don't look for right answers in that exercise. If the candidate has some code exposure, I prefer to dive deep into his previous work and figure out how he executed the projects. In both the cases I am trying to asses a candidate's approach to execute something. I also try to figure out the candidate's ability to pickup new things and start executing them quickly. This is measure of a candidate's potential. I assign similar weightage to 'Potential' as to 'Past Work History'.

Re: The Terrible Technical Interview

#227

Post by geebee »

SilasX wrote: post #35
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 bas…

(I'm very late to this discussion, so I may try this question another time).

But I've been thinking about the marginal value of each additional technical question. In other words, how much additional relevant information do you get about a candidate increase with each increasing level of difficulty?

For instance, suppose you ask fizzbuzz and the candidate has an easy time of it. Then you ask about building/searching a binary tree, which the developer manages, but only after fumbling round a bit. Then you get into finding cycles in linked lists or graphs, and the developer takes a crack at it, but would need to look it up. Or maybe the developer gets it, and the interviewer ask about finding all permutations of a string...

How much more do you learn by going from fizzbuzz to binary trees. How much more do you get by asking about cycles in linked lists? And so on…

Just for the record, I can't stand technical interviews, and I dislike them so much that I'm considerably less inclined to apply for and interview for new jobs because I feel that I've studied for my data structures and algorithms midterm one time too many. I just don't want to re-load merge sort into short term memory again.

However, in spite of all this, I'm still somewhat sympathetic to interviewers[1]. The truth is, if you really don't have a lot of direct evidence about a developer, you truly are at risk of hiring someone who can't code.

[1] My problem with silicon valley hiring practices isn't that they have a process that leads to a high false negative rate. They should do what they feel is best for their company. My problem is that they do this while complaining about a critical shortage of developers so severe that it endangers the entire tech economy.

Re: The Terrible Technical Interview

#228

Post by fsk »

sytelus wrote: post #223
fsk wrote: post #219

Earlier quoted context omitted.

I see what you're saying. I was pointing out the dangers of false negatives, but he responded that he hires 10% of the people he invites for an onsite interview. Even if you hire 10% of the candidates you on-site interview, that says nothing about your actual false positive or false negative rate. For all I know, he could be weeding out all the top candidates at the pre-interivew stage, and then hiring the best of a…

No, I did not say I hire 10% of candidates I interview :). What I said was that's a fair estimate in industry. I feel you are truly confused about FP and FN. Whether there are 99% bad developers out there or if you hire 10% of candidates you interview - these both quantities are independent of FN and FP. FN says that you are turning away X good people and it's again independent of FP which ultimately decides how many…

If you increase FN and FP stays the same, you are more likely to make a bad hire. Do you understand this?

Re: The Terrible Technical Interview

#229

Post by jghn »

jimbobimbo wrote: post #215
jghn wrote: post #195

Earlier quoted context omitted.

"As an interviewer, I simply don't have an hour or two to evaluate someone's project." These are people with whom you'll be working together with for years. If you can't spare a few hours to make sure you are finding the right person, what does that say to a candidate?

The interview is a tool to quickly evaluate the candidate. Not every candidate reaches the point where they could be even considered being a person I'll "be working together with for years". There're more than one candidate at any given time and I still have my day job to do. I don't know what does this say to a candidate, but I surely hope they're mature enough to understand that there's nothing personal about it. T…

The thing is that they're also interviewing you. If I expect a candidate to spend time prepping and then taking time off of work to come in and talk to us, the least I can do is take the time to properly prep for them.

I know that when I'm on the candidate side of the fence it makes a big difference to me if a company/interviewers seem like they've actually taken the time to get to know who I am instead of just walking in a room and that being the first time they've checked out my resume. I realize it's not personal and I don't expect it but if a company/interviewer puts in the extra effort it's a definite positive.

Re: The Terrible Technical Interview

#230

Post by dba7dba »

rifung wrote: post #162
dba7dba wrote: post #104

Why not require programmers to submit samples of work (most likely personal, side projects due to legal issues) done over a period of time, like graphic artists do when they apply for positions? I would think that would be a much more correct assessment of the programmer. Interviews should really be limited to check personality, and not much more imo.

This seems like what the article suggested. The issue then just becomes that not everyone has the time to do side projects and some of us are lucky enough that we really enjoy what we do for our job, so even when we have spare time we still work on the company project.

While I agree with you, I've learned no company will stay as loyal to you as you are to them. You always need to plan ahead to fend for yourself. And having SOME kind of side project (no matter how small) is always advised, imho, for future employment.
Post reply on HN