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

91–100 of 236 posts

Re: The Terrible Technical Interview

#91

Post by skybrian »

monksy wrote: post #82

> This is why personal references and recommendations remain everyone’s favorite hiring technique… > …which in turn is a major reason why the tech industry’s diversity numbers are so disastrous. I'm not buying that argument. I would however agree that recommendations and references create a lack of diverse ideas/approaches. Lack of racial/gender diversity: That would indicate that the people in the minority just aren…

You make it sound so easy. Perhaps they've tried, but it's harder for them to connect? Without actual data, I think I'll go with that; it fits better with what people are saying.

Re: The Terrible Technical Interview

#92

Post by BurningFrog »

This article seems to be written inside a different bubble than mine. Then author lives where all technical interviews are conducted in a similar way, and thinks that is the universal truth everywhere.

In my bubble things aren't perfect, but they're quite different.

Re: The Terrible Technical Interview

#93

Post by fsk »

skybrian wrote: post #86
fsk wrote: post #40

Earlier quoted context omitted.

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…

This is reasoning from something that's harder to estimate (how good is the hiring pool and your interview process) to something you know more about (how good are the company's employees). It seems like you should be working backwards instead? For example, if you assume that 90% of your employees are "good" and 1% are "toxic", what does that tell you about the candidate pool and/or your interview process?

It's my crude estimate based on the places I've worked over the years, and the people I've seen come in when my employers were interviewing.

If I was the boss and had a "toxic" employee, I'd just dump them rather than waiting. I've been forced to work with toxic people because I'm not the boss, and I've noticed that toxic people are really good at pretending to be brilliant.

Over the years, I've also worked with a couple of people who singlehandedly wrote all of the employer's key software. I also worked with several people who wrote a garbage system but conned everyone else into thinking it was brilliant.

If 90% of candidates are "good", then why waste time with a detailed technical screening at all? Just interview a couple and pick the ones you like the best.

Re: The Terrible Technical Interview

#94

Post by tptacek »

StevePerkins wrote: post #87
tptacek wrote: post #79

Earlier quoted context omitted.

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…

I'm not sure that you fully read the parent comment. I could care less about their Subversion expertise. My company doesn't even use Subversion anywhere. However, if you list " 10 years experience with " on your resume, then you should absolutely be prepared to discuss your experience with at a high level. Not anal minutia or contrived trick questions, but certainly you should be able to respond to an open-ended ques…

There is no less productive form of interview than the "resume validation interview". Resumes are practically useless in the best case. Here, you seem to propose paying a premium for candidates who can properly estimate their facility with VCS systems and then cogently discuss that estimation in an interview. That can't possibly be a skill relevant to building software on your team!

Re: The Terrible Technical Interview

#95

Post by mingmecca »

I lose about 20 points of IQ in a technical interview. It's nerve racking (I wear black shirts to hide the sweat) and it cost me a job working for a well known VR company. I passed the 'practical', which was a 2 hour coding test to generate a working game application, but the tech interview probably did me in. I've been programming games for almost 20 years, and as far as I know I'm one of the few who has done lead/senior level work on games that were both #1 and #2 simultaneous chart-topppers, but I still couldn't get the job. Their loss I guess, but it still sucks, as I was really enthused about what they were doing and could contribute significantly. I was about 10 years older than their typical engineer however, so maybe ageism played a part. I'll never know. I just wish companies would look at my past body of work, see that I'm friendly and un-abrasive, and bring me aboard.

Re: The Terrible Technical Interview

#96

Post by joncrocks »

tptacek wrote: post #79
StevePerkins wrote: post #48

Earlier quoted context omitted.

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…

That's not what I think is going on here. He's not asking "Tell me the commands that I have to type to do X, Y and Z in GIT, SVN and Mercurial", he's asking a higher level question about how one can utilise VCS (and DCVS) tools to work in different ways.

Depending on the experience of the candidates he's trying to acquire/interview, this may be appropriate to indicate that they have either experienced different ways of developing at different companies, or have an interest in software development practices wider than just "The way I've done it is the way I was told."

I'd consider it an 'indicator' question, indicating that the candidate has either experience or interest in software delivery and the way that different organisations work/operate. It's probably not a make-or-break question, but if a candidate had a good number of years under his belt and hasn't at least heard of some kinds of different practices then they might be the "do what I'm told but no more" coder that that organisation wants to avoid.

Re: The Terrible Technical Interview

#97

Post by rsuelzer »

I remember with horror one technical interview I had. I was asked to complete a fairly basic problem, which I had actually just practiced a few hours before (the fact you can practice for these interviews indicates how questionable they are). As soon as the question was asked, I proceeded to start typing the answer and explaining what I was doing when suddenly my mind went blank, I struggled for nearly ten minutes to regain my confidence but by that point it was too late. The interviewer quickly ended the interview and told me to apply again after I had more programming experience, since apparently he was able to conclude the extent of my knowledge based upon my answer to a single question made during stressful circumstances.

Re: The Terrible Technical Interview

#98

Post by FireBeyond »

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…

Try Toastmasters. Definitely something out of most people's comfort/familiarity, but works wonders for improving speaking talents.

Re: The Terrible Technical Interview

#99

Post by sanderjd »

guelo wrote: post #30
philbo wrote: post #12

Earlier quoted context omitted.

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…

You should spend time improving your live performance skills. It comes in handy for more than just job interviews.

I think you're correct, but I also think it's a real shame that live performance skills are important to excel at a career that has nothing to do with live performance.

I wonder if there are any careers where you only have to get good at the thing you're doing rather than a bunch of meta-things.

Re: The Terrible Technical Interview

#100

Post by monksy »

skybrian wrote: post #91
monksy wrote: post #82

> This is why personal references and recommendations remain everyone’s favorite hiring technique… > …which in turn is a major reason why the tech industry’s diversity numbers are so disastrous. I'm not buying that argument. I would however agree that recommendations and references create a lack of diverse ideas/approaches. Lack of racial/gender diversity: That would indicate that the people in the minority just aren…

You make it sound so easy. Perhaps they've tried, but it's harder for them to connect? Without actual data, I think I'll go with that; it fits better with what people are saying.

IMO: Its more of people being shy and/or drop the expectation that they'll accepted by the community in the first go.

They should come out to the non-discriminatory user groups. (I.e. groups that don't ask for a particular gender i.e. xNUG/xJUG etc)

I've found, in others and myself before, is that I've held myself back from going to meetups because I didn't feel immediately welcome the first go, or that I didn't think I'd know people. However, you can't expect for everyone to welcome you with open arms in the first go. It's easier to blame the issue on racism/sexism, than to admit that you may just be shy. (That being said, I attempt to introduce new people in my meetups to the group and others)

Post reply on HN