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

71–80 of 108 posts

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

#71

Post by vorg »

captobvious wrote: post #62

There is a lot of focus on team work. I'm still not sure if programming is suited for team work. There's clearly some activities of creative problem solving which are better suited for individuals working mostly alone, but belonging to a community of peers. For example: * math * research * art * visual design * writing * music * programming? People have been trying to apply Taylorism to programming making it approach…

> and/or a portfolio (github for example)

This can be cheated. They could get someone else to create the Gibhub portfolio for them, perhaps a friend who's an unemployed "real programmer", just like they could get someone else to sit an aptitude test for them if only HR people are at the test and no photos are taken.

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

#72

Post by captobvious »

vorg wrote: post #71
captobvious wrote: post #62

There is a lot of focus on team work. I'm still not sure if programming is suited for team work. There's clearly some activities of creative problem solving which are better suited for individuals working mostly alone, but belonging to a community of peers. For example: * math * research * art * visual design * writing * music * programming? People have been trying to apply Taylorism to programming making it approach…

> and/or a portfolio (github for example) This can be cheated. They could get someone else to create the Gibhub portfolio for them, perhaps a friend who's an unemployed "real programmer", just like they could get someone else to sit an aptitude test for them if only HR people are at the test and no photos are taken.

Yeah of course you'd bring them in for an interview to talk about those projects if they show a promising portfolio.

I just can't imagine hearing someone say "Yeah this guy is a great visual designer, look as his gorgeous portfolio, and look at all this great stuff he did at smashing magazine (or whatever good place for design, I don't know..) But he's not a team player, he is sceptical about doing 'pair-designing' for 8 hours a day with other randomly chosen incompetent designers. No hire."

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

#73

Post by wccrawford »

amcintyre wrote: post #61
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…

One of my favorite questions is: "What's the best bug you've ever found?" One of the problems I always have with questions like that is this: I don't keep mental lists of events or other things ordered by potential "interestingness" to myself or other people. I just don't think that way for some reason. I might fumble to come up with an answer to that question, and then an hour after the interview is over, I'll remem…

That was my first thought, too. I've had some bugs that actually make good stories, if told right... But I had a lot of other stories that are better. The only halfway interesting bug I can think of right now is actually pretty lame, and the rest of the story that goes with it is halfway interesting.

There's always a danger when picking out certain criteria and claiming they mean something. In this case, 'ability to remember an interesting bug' does not actually select for good programmers. It just happens to overlap somewhat.

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

#74

Post by wccrawford »

glogla wrote: post #60
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…

Oh boy. I seem to remember the (member 1 '(1 2 3)) -> t (equal '(1 2) '(1 2)) -> t (member '(1 2) '('(1 2) '(3 4))) -> nil bug. It took me just three hours, but boy was it annoying. In the end, it was just me not knowing the language of course.

I can read just enough of that that it confuses me why it doesn't work. Care to explain?

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

#75

Post by glogla »

wccrawford wrote: post #74
glogla wrote: post #60

Earlier quoted context omitted.

Oh boy. I seem to remember the (member 1 '(1 2 3)) -> t (equal '(1 2) '(1 2)) -> t (member '(1 2) '('(1 2) '(3 4))) -> nil bug. It took me just three hours, but boy was it annoying. In the end, it was just me not knowing the language of course.

I can read just enough of that that it confuses me why it doesn't work. Care to explain?

The problem is, that

  (equal 1 1) -> t
  (equal '(1 2) '(1 2)) -> t

  (eq 1 1) -> t
  (eq '(1 2) '(1 2)) -> nil
because eq tests for the same symbol, while equal test for the same list. Member uses eq, not equal.

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

#76

Post by SatvikBeri »

mkramlich wrote: post #41
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.

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 e…

You know, that's a fair point. I think our company may be making that same mistake where instead of trying to find the good candidates, we're trying to filter out the bad ones. I'll see if I can change that.

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

#77

Post by disgruntledphd2 »

tveita wrote: post #37
kevinpet wrote: post #7

Earlier quoted context omitted.

This a good point. It seems somewhat unavoidable, since no one will ever be in a position to evaluate the effectiveness of both those who did well on their metric and those who did poorly (since they will only hire those who do well). Perhaps there are companies out there with a large enough sample size that are recording metrics on a "programming concepts verbal interview", "analytical thinking verbal interview", "p…

If you wanted to go about it scientifically, you could hire some fraction of the people that wouldn't have passed based on the current practices. That's a pretty scary thing to do, but it could be worth it for a large company which needs to improve its hiring. Think exploration/exploitation.

Speaking as someone who's thought a lot about this (mostly during my psychology studies), here's what I would do, if someone let me.

1) Establish the competencies of your employees. Think small programming exercises, IQ tests, personality tests etc. Use this to establish a minimum score for hiring. 2) Apply these same tests to all prospective employees. 3) Of all the candidates that meet the minimum criteria, hire a random set of them. 4) Follow up the progress of all these employees over 1-2 years.

Now, this would never fly in many legal senses, and I doubt that anyone will ever let me do it, but it would provide useful data to improve hiring processes. I suspect that this would need to be done for each individual company at least 100+ times before you would start to be able to derive useful patterns.

Some hypotheses: 1) non linear relationship between IQ and performance 2) Increasing performance and longetivity of employment based on the similarity between personality of candidate and personality of team.

Just my 0.02c.

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

#78

Post by meric »

mattdeboard wrote: post #44
rfrey wrote: post #25

Earlier quoted context omitted.

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 proble…

Do programmers encounter all sorts of algorithms when engineering software? In my experience, the only things I really need to keep in mind what are the consequences of certain data structures and algorithm types rather than their specific implementation, because often the implementations are built-in to the language, but the choice of which implementation of data structure and algorithm to use are more important. I use sorting algorithms very frequently. Usually it is just a call like "list.sort()".

Yet in interviews, the questions I get asked are more like "Implement in 20 minutes, no googling.

I mean, really?

The other day I was in an interview where I had to implement a queue in 30 minutes. The unit tests were already written and the IDE was eclipse.

I wrote the "correct" implementation for the queue in about 10 minutes but there was a bug I couldn't find; I've never used eclipse before and took a lot of time figuring out everything. In the last minute I finally tracked down my bug. I forgot to increment a variable. I fixed it and all the tests as well as the performance test passed. I didn't get the job because I took too long. (It was a graduate position and the last time I used Java was 2 years ago)

I was distracted with all the buttons on eclipse... Otherwise I'd never have missed the variable increment! I swear. Anyway the point is, if a programmer is ever implementing their own simple Java queue in production software it is not a good sign anyway. Why are you testing for that?

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

#79

Post by wccrawford »

glogla wrote: post #75
wccrawford wrote: post #74

Earlier quoted context omitted.

I can read just enough of that that it confuses me why it doesn't work. Care to explain?

The problem is, that (equal 1 1) -> t (equal '(1 2) '(1 2)) -> t (eq 1 1) -> t (eq '(1 2) '(1 2)) -> nil because eq tests for the same symbol, while equal test for the same list. Member uses eq, not equal.

Ah, I see. Thanks.

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

#80

Post by JoeAltmaier »

parbo wrote: post #64
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…

Compiler bugs are always satisfying to find. "It's never the compiler", but sometimes it is: http://llvm.org/bugs/show_bug.cgi?id=12419 But I think my best one was when I found a bug in a third party communication library, that only manifested itself on ARM architecture. Our CPU was PPC, and our simulator was x86. On both of those, unaligned memory reads work fine. But the actual unit we'd talk to had an ARM CPU. On…

Funny - I remember when one of our new Engineers needed a memory-copy method for our ARM embedded solution - he went to Linux source and got some library routine.

It faulted when I used it the 1st time. Fixed the bug (alignment of source), ran again and it faulted again.

So I spent 10 minutes writing a test - move 0-128 bytes from source buffer offset 0-128 to destination buffer offset 0-128. Simple, overkill right?

11 bugs later the damned memory copy thing worked. 11.

The next thing to ask is, What did I learn from that bug? What I learned is, accept NO CODE as bug-free, no matter the source, no matter what authoritative base it came from.

Other learning: why oh why don't CPU designers put a damned memory-copy instruction into the machine? We all need it, all the time, for every project and we all hack something together that works until it doesn't. Sigh.

Post reply on HN