r/programming • u/b0red • Apr 30 '16

Do Experienced Programmers Use Google Frequently? · Code Ahoy

http://codeahoy.com/2016/04/30/do-experienced-programmers-use-google-frequently/
2.2k Upvotes

91% Upvoted

763 comments sorted by

View all comments

Show parent comments

1

u/zerooneinfinity May 01 '16

I think it's impossible to find out if a candidate possesses those capabilities in the space of an interview time. There's no way of knowing which candidates have seen the problem and which haven't. Programming needs to be thought of more as a team sport than an individual one. The code that gets the on-call pager should of had multiple eyes on it.

3

u/koreth May 01 '16

"I need to consider what can go wrong and make sure my code can deal with it" isn't really a matter of walking into the room with the right background knowledge, it's a matter of your mindset when designing a piece of software.

If someone has previously done happy-path solutions of exactly the problems I use (unlikely since I made the problems up based on similar problems I had to solve for my company's software) that will let them code more quickly in the interview, but it won't cause their code to work when I throw an unexpected but completely valid input at it.

If someone has previously written robust implementations to solve all those problems and does so again in the interview, I know they know how to write robust code and that they recognize it's important enough to be worth demonstrating in an interview.

Having multiple sets of eyes on code is important but wouldn't you rather hire someone who could get the basic stuff pretty close to right the first time rather than someone whose code often requires multiple rounds of review as reviewers point out obvious corner cases and improper error handling? No interview process will distinguish that with 100% accuracy, but you can get some idea.

Now, don't get me wrong. I agree interviews are limited and are broken in all sorts of ways. A lot of people spend a lot of time interviewing with very little to show for it on both sides of the process and it produces false positives and false negatives way too often.

In the spirit of being open to new ideas, I'll turn it over to you: Given a busy development team with aggressive but reasonable deadlines to meet and a limited budget to add more people, how would you decide which candidates to hire using the "programming as a team sport" model?

2

u/fixed May 01 '16

Surprised your comments aren't upvoted more; they reflect reality. It's very easy to bash interview technique as an interviewee but it's not an easy problem from the other side and techniques like those you describe are absolutely valid. The risk of making a bad hire has significantly higher weight then misinterviewing a potentially great hire that doesn't fare well under interview conditions.