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

101–110 of 236 posts

Re: The Terrible Technical Interview

#101

Post by tptacek »

joncrocks wrote: post #96
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…

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…

There is a subtle but crucial difference between "candidates with experience working on teams delivering enterprise software" and "candidates with aptitude for working on teams delivering enterprise software". Worse, many in the former set aren't in the latter.

You might want to build an interview process that selects candidates who belong to the latter set. I'm a little baffled why you'd want to select from the former set in preference to the latter.

Re: The Terrible Technical Interview

#102

Post by santoriv »

tptacek wrote: post #94
StevePerkins wrote: post #87

Earlier quoted context omitted.

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!

Personally I think it's an excellent question. He's probing into a candidate's understanding of why you use version control systems and why different approaches might be used.

If you have a significant amount of experience then hopefully you have seen enough different situations to be aware of the advantages and disadvantages of each approach.

It's really a question to figure out whether or not you can reason about high level concepts.

Re: The Terrible Technical Interview

#103

Post by tptacek »

fsk wrote: post #90
waterlesscloud wrote: post #69

Earlier quoted context omitted.

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'm still not sure how giving employees a book to read and then testing them on it is a good process. If I'm going to spend a couple months of free time learning something, I'd pick something like Python or Android development or HTML5 app development, rather than learning a skill that will only be useful for 1-3 employers. How can I know if an employer is worth 1-3 months of my free time until I meet my potential fu…

I did not have a problem with passing on candidates who weren't not sold on learning our subspecialty.

I do have a problem with passing on candidates who were sold on our subspecialty, had an aptitude for it, but could not pass an interview on it "cold".

Re: The Terrible Technical Interview

#104

Post by dba7dba »

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.

Re: The Terrible Technical Interview

#105

Post by logn »

I think people overstate how much interviews are the problem. Managers/HR are the problem. In most companies the team manager has little to do with finding and initially screening candidates and they (or HR) are too afraid of firing people. I think managers alone should be handling this.

I also don't think hiring by committee decision makes much sense. It reduces the one-on-one evaluation time by the hiring manager. If you have 6 people doing 30-minute interviews of a candidate, everyone gets a few good questions in then the decision comes down to a consensus of gut feelings. Plus the manager can deflect blame for bad hires.

But changing this require re-organizing people and job duties in a company and they'd rather just look for the next hot interviewing trend. (Edit) But as far a trends go, looking at real work is at least better than contrived exercises.

Re: The Terrible Technical Interview

#106

Post by tptacek »

santoriv wrote: post #102
tptacek wrote: post #94

Earlier quoted context omitted.

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!

Personally I think it's an excellent question. He's probing into a candidate's understanding of why you use version control systems and why different approaches might be used. If you have a significant amount of experience then hopefully you have seen enough different situations to be aware of the advantages and disadvantages of each approach. It's really a question to figure out whether or not you can reason about h…

Stipulate that it is. Why is that a good idea for an interview?

Re: The Terrible Technical Interview

#107

Post by doug1001 »

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 like the style/approach of your questions--a nice optimum that minimizes false positives and false negatives.

and i agree with you that threshold competence in the general applicant pool is so low that some form of technical screening is absolutely essential. My problem is how best to do it. For one thing, it has taken me far too long to recognize that the pool of interview questions and plausible answers are widely available and apparently studied by many applicants prior to technical onsite interviews. Their answers are quickly given and so polished that we bring them on, then fairly soon find that answers to those interview questions is pretty much all they know.

Re: The Terrible Technical Interview

#108

Post by jimbobimbo »

I've been on both sides of the process and in both cases I prefer the whiteboard.

As an interviewer, I simply don't have an hour or two to evaluate someone's project. I want to see a strong resume and ask a few questions to understand whether the resume is real or not. A simple whiteboard question or two is great for that. You can always see whether the person is capable of writing code and it always brings up questions around the choices they made.

As an interviewee, I rather not be engaged in a live coding session: the whiteboard is a very efficient tool to get an idea across, without sweating on syntax errors, searching for API documentation and whatnot. Test projects - I have a job, thank you very much.

Re: The Terrible Technical Interview

#109

Post by bsder »

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…

> 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.

Fail. You just killed the quality of your pool.

You've just negatively screened against people with a life (experienced, 30+ years old, generally with a family) and screened for people with no life (aka single, male 20-somethings).

For an example, if John Carmack hadn't been able to release his employers source code (like many people), your process would screen him out (no github or side project presence).

Re: The Terrible Technical Interview

#110

Post by jlees »

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

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. B…

I've been doing improv for 10+ years and had never realised this, but it may well be a large part of the reason why I don't get nervous in interviews. Thanks for helping me make the connection!

Plus, as one other commenter points out elsewhere in this thread, once you've been on the other side of the table for a while, you get a much better idea of where your own strengths lie (and what you're up against, which can instil a lot more confidence than you might think!).

Post reply on HN