Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interviews Can Be a Terrible Way to Identify Good Programmers

thecodist.com

Post reply on HN
Print view View original

41–50 of 108 posts

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#41

Post by mkramlich »

SatvikBeri wrote: post #29
sanderjd wrote: post #13

Earlier quoted context omitted.

Do people actually use FizzBuzz itself ? I always thought it was just one example illustrative of the type of simple and quick-to-answer question that makes a good initial negative filter.

SQL equivalent: "Explain the difference between a left join and a full join." ...seriously, this filters out a depressing number of people who put SQL on their resume and are applying for a SQL job.

There are a lot of people who've used SQL, and therefore will think it's perfectly honest and accurate to list SQL experience on their resume, and who've written perfectly fine queries to get shit done, and yet they would not be able to answer that question, especially in an interview/interrogation situation.

Also, in real life, under normal working conditions, we live in the Age of Google (and books) -- if someone ever needed to know the definition, or recite a definition or comparison of those terms, he could just look it up. A better question would be: can they solve problems? And solve them in good ways? And have they in the past? Do they get shit done? Ship? Reliable? Work well with others (to the extend it would matter, because it varies)? Would it be a net win to them involved with your project/team/company? Those questions matter the most by far. And I don't think it's wise to assume they're going to be able to recite a definition of any particular term. Offhand. In a stressful and unnatural situation like an interview.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#42

Post by [deleted] »

notJim wrote: post #18

Good to see that we're making good efforts at meeting our "articles about hiring" quota on HN. I have this theory that hiring people is nowhere near as hard as this particular echo-chamber likes to think it is. Everyone thinks they need "rockstars" or "A Players" and is looking for the magical recipe for finding them, but I think for most positions, someone who is smart and technically competent and fits with your co…

[deleted]

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#43

Post by McGlockenshire »

fendale wrote: post #32
SatvikBeri wrote: post #29

Earlier quoted context omitted.

SQL equivalent: "Explain the difference between a left join and a full join." ...seriously, this filters out a depressing number of people who put SQL on their resume and are applying for a SQL job.

What is a full join? I've been working with Oracle for 10 years and I've never used that term. I know what a left join is and an outer join, but not a full join.

"Conceptually, a full outer join combines the effect of applying both left and right outer joins. Where records in the FULL OUTER JOINed tables do not match, the result set will have NULL values for every column of the table that lacks a matching row."

http://en.wikipedia.org/wiki/Join_(SQL)#Full_outer_join

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#44

Post by mattdeboard »

rfrey wrote: post #25
jemfinch wrote: post #15

Earlier quoted context omitted.

"That's not how the best coders code, we offload most things to google searches" If that's really what you think, you may want to reconsider who the "we" you're talking about are.

I think it's fair to say that if you're stretching yourself, or working on challenging problems, a reasonable amount of time is spent researching. If you don't know how to do something, you research it. Whether you find it in a textbook or on Stack Overflow, it's essentially the same thing. Unless you think "good" coders reinvent algorithms they don't know from first principles?

I'd wager there's a difference between what jemfinch is talking about and what you're talking about.

I used to unilaterally believe that coding exercises or algorithm quizzes on interviews were silly because if I had to solve some given problem I would just google it. And that's true, I would. However, as I've gotten a little more experienced I've realized that there is extreme value in expanding the domain of problems for which I don't need to google, because either A). I've happened to read about it on my own time or B). I've encountered a particular troublesome component before.

In other words, I think it is entirely reasonable for the hiring process to properly evaluate a programmer's toolset. Yes, I think researching via Google is or should be a piece of everyone's process, but it matters greatly what kind of things you have to Google.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#45

Post by ChristianMarks »

kabdib wrote: post #5

One of my favorite questions is: "What's the best bug you've ever found?" Usually I get a "Huh?" The really stellar folks will tell you about the bug that took two weeks to find and boiled down to a single missing comma in a vendor's library routine. Or /something/. But "Huh" is a bad sign. "Huh?" is not a fail, but it usually correlates with people who can't write a function to find the length of a string, and I see…

Several:

1. debugging an options calculation on a spark workstation for a Merrill Lynch trader who was incognito and on his honeymoon. A certain options valuation table he was using had expired and needed to be updated. Ad interim his position went haywire. I didn't have the exact source, so the debugger was off by one line, then two lines, then three lines. But I found where the table was used and was able to patch and recompile the code.

2. This dates me somewhat (recruiters consider me too old) but I was bitten by the 80286 POPF bug, which caused the interrupt disable mask to be ignored in an interrupt driver I had written for a Motorola 6852 (if I recall). I found the bug but the client announced it was going out of business (I wasn't responsible).

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#46

Post by mattdeboard »

davvid wrote: post #35

I'm happy where I work. I interviewed for google once; their recruiter found me through an open source project in which google has a stake. Anyways, I was tired when I did my phone interview, having just returned home from work. I bombed a couple of those interview puzzles. I felt pretty stupid because the answers are really obvious to me in hindsight. No biggie. So this week they interviewed a junior programmer I me…

Yeah I've done the code-in-a-google-doc thing as well. Wasn't a fan. I've also done the interview-right-after-work thing. Not a fan. I'm happy where I work too, but it doesn't hurt to always know what the market is like (as you're obviously aware). That being said I've found the "job market research" process tedious and tiring. Months-long processes only to end in frustration, lies about project scope/culture/etc., time-intensive programming exercises, and so on.

Not sure how else you'd handle it though, really. Busy people are busy.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#47

Post by typicalrunt »

sanderjd wrote: post #13
raverbashing wrote: post #11

It depends I've hired great people without having them write code. (Or at least, not in a whiteboard) Trust me, you can know a lot about a candidate without him or her writing a line of code (ok, maybe a line) My favorite question: "Tell me about a bug you once solved". That will tell you loads about the candidate Or ask him/her about the difference bewteen foldl and foldr But, really, I won't use FizzBuzz again "bla…

Do people actually use FizzBuzz itself ? I always thought it was just one example illustrative of the type of simple and quick-to-answer question that makes a good initial negative filter.

Yes. In fact I'm using it in the current round of applicants. However, I slightly modify FizzBuzz so that it weeds out anyone that has memorized it.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#48

Post by MattGrommes »

notJim wrote: post #21

I'm curious, is it really that hard to identify competent programmers? Surely asking a few technical questions that include some element of programming should be enough. I feel like there's about 5-10 articles on this subject every week, all of which say or or less the same thing. In very nearly every case that I've interviewed someone, I've been able to easily decide if they were a hire or a no hire about 20 minutes…

Part of the problem, and the reason we have posts about hiring constantly, is that there's no solution to the problem. Every team is composed of different types and amounts of people, every company is different, everybody has had success or failure with different techniques, every recruiter brings different types of people, etc. There are a lot of people you can flip the bozo bit on quickly but others who are just bad interviewers and you have to draw out a bit more. There's people who just rub me the wrong way so I'm harsher than others sitting in the same room at the same time. And once you get past "These 5 people are competent but which one would I like to spend my week with?" the complexity goes up tremendously. If you're hiring the person who will sit behind you 8 hours a day it's a different deal than getting the 50th programmer in your department.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#49

Post by rmATinnovafy »

But I don't think that a bad interview will mislead a programmer.

Thruth is lot of companies out there are mediocre. And this shows on how they recruit.

Everyone wants a "rockstar" for some average CRUD app, but they don't seem to understand that most programmers will do fine building them. Even people who interview badly.

I think that programmers should be the ones taking a detailed look at companies to see if they are a fit with the dev team instead of the other way around. After all, if you don't feel well whithin a team, how will you do your best?

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#50

Post by decadentcactus »

cpt1138 wrote: post #30
decadentcactus wrote: post #23

Earlier quoted context omitted.

It seems to me that regardless, you need to still have a CS degree and understand (and be able to implement) algorithms of increasing complexity, even if you're making a CRUD app. But I agree, these interview posts altogether don't seem to say anything consistent.

"you need to still have a CS degree and understand (and be able to implement) algorithms of increasing complexity, even if you're making a CRUD app." Why?

Sorry if it wasn't clear, I meant that's the impression I get from a lot of these interview posts.
Post reply on HN