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

121–130 of 236 posts

Re: The Terrible Technical Interview

#121

Post by meejah »

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!

Do you ask to see the resumes of candidates?

Re: The Terrible Technical Interview

#122

Post by marktangotango »

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 sometimes ask candidates what the letters "MVC" stand for. The successful response rate is around 50/50. I ask candidates to briefly explain the advantages of the Model View Controller pattern,

It's good you don't ask for a definition. Even the inventor of MVC thinks it's rarely been applied as intended [1] (see forward by Trygve Reenskaug).

[1] http://downloads.nakedobjects.net/resources/Pawson%20thesis....

Re: The Terrible Technical Interview

#123

Post by moey »

I think the best approach would be options for different people to choose.

Think you can pass a hardcore whiteboard interview? Go for it.

Would you rather spend a day and solve a real problem we have? Lets see what you got.

Think you have the attitude, just not the knowledge to match our exceptions yet? Do you have time for an internship? Ok cool. Lets play.

One size fits all is a bad idea for interviews. Just as how teachers test their students.

Re: The Terrible Technical Interview

#124

Post by jes5199 »

tptacek wrote: post #106
santoriv wrote: post #102

Earlier quoted context omitted.

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?

personally, I think the SVN question is a pretty good example of "can you talk intelligently about any aspect of any complex system you've ever worked with?". If a candidate can explain one, I'll recommend to hire them. The resume provides a good list of possible subjects to discuss, otherwise I just cast about randomly, try to chase threads in the conversation until I find something with some depth.

Re: The Terrible Technical Interview

#125

Post by bhayden »

leadgenguy wrote: post #50

I am a self taught PHP programmer. Been working in tech as a freelancer since early 2000s. Built real applications. I thought I was pretty good so a few years ago I moved to Silicon Valley to get a startup job. Boy was I wrong. Even though I had created real applications and knew MVC, etc. etc. I was basically told I was worthless because I didn't know algorithms, unit testing, etc. etc. So I moved back home (Tel Avi…

I really like seeing this. I also write PHP for my projects, and I know it's terrible. I have no delusions about this. I use mysql_query despite knowing it's deprecated and possibly insecure, and if I'm building something that doesn't store any sensitive data and the worst case scenario of someone finding an exploit is that I have to restore from a snapshot, I really just don't care. I focus on building the product quickly and efficiently. Let the programmers of the world thumb their noses at me, at least I'm building something of value for me instead of some company.

Re: The Terrible Technical Interview

#126

Post by army »

rsuelzer wrote: post #97

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…

Um, you can practice for anything that involves communication or demonstrating your skills. Its just arrogant to think that you can go into an interview cold and rely on the interviewer to tease out your positive qualities. If they're a good interviewer they'll do their best to do that but its also on the interviewee to convince the interviewer that they're a good fit for the job.

I wouldn't present on a technical topic without preparation, because I'm not going to do a good job of explaining it or communicating the ideas - I'd be wasting the audiences time. Same with interviews - you need to be prepared to explain your work and put your experience in as favorable a light as possible.

Re: The Terrible Technical Interview

#127

Post by army »

buchweizen2 wrote: post #88
tptacek wrote: post #52

Requiring a side project from candidates would have cost us most of our best hires.

I was a bit surprised that the article first talks about how bad it is to pass on good candidates that don't interview well on whiteboards and then suggests to pass on candidates that don't have side projects. Are all candidates without side projects not good?

My bias is better than your bias ;)

Re: The Terrible Technical Interview

#128

Post by tonyarkles »

simoncion wrote: post #68
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…

> Actually, this demonstrates a problem right here. It's not clear to me what you mean by these terms. I'm not trying to get in an ego stroking contest here, I'm just providing anecdata. I worked with SVN for ~4 years and git for ~4 more. What StevePerkins was asking was perfectly clear to me after about three seconds of thinking. Of course, in an interview, I would be sure to parrot back my understanding of the ques…

I feel the same way, with approximately the same number of years of experience with each. And I definitely have strong opinions on the answer to the question :)

Re: The Terrible Technical Interview

#129

Post by Darmani »

bsder wrote: post #111

Look, if you want to talk about code, the easiest and best way to sidestep this issue is to have people bring code (somewhere between 200-1000 lines) to the interview. While they may not have a github presence, they've probably written something on a computer outside of business at some point. I really don't understand why more people don't do this. It doesn't even matter if it is their own code. The fact that they w…

I tried this with the first few people I interviewed. None of them had any code from outside work to bring. (This includes a brilliant and hardworking coworker that I practice-interviewed -- he just hadn't coded outside work in a very long time.)

We wound up switching to giving code challenges instead.

Re: The Terrible Technical Interview

#130

Post by tonyarkles »

parennoob wrote: post #15
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…

As a self-taught person beginning to write software who is not in SF, your description of someone who cannot explain the advantages of the MVC pattern makes me incredibly nervous. I don't really know the MVC pattern in detail, or what its advantages are. I do know about Big O complexity, data structures, loops, registers, as well as logic gates, and the basic structure of computer processors. I can code small program…

As a total curiosity, what's the biggest from-scratch codebase you've ever made? In my experience so far, things like MVC don't always make a whole lot of sense until:

1) You've got a code base large enough that they matter; 2) You wrote it initially without using something like MVC; 3) And then it grew into a ridiculous monstrosity, which you then cleaned up by breaking it into models, views, and controllers.

At that point, if it turns out well, you start to "know it in your heart" instead of just being a nebulous concept that you read in a blog/textbook/whatever somewhere.

Post reply on HN