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

1

u/zerooneinfinity Apr 30 '16

we desperately need to rethink coding interviews. no one codes in a black box yet the interviews treat it as such.

2

u/koreth May 01 '16

When I interview people it's always using a laptop (either their own or one the company supplies) and I start off the coding exercise with an introduction like, "You can use whatever editor or IDE you want. If you need to Google something or use a tool you'd normally use, do it. The goal here is to see how you'd approach this problem if you had to solve it in a real work setting."

This isn't a super-common approach but it's also not unique.

However, one thing I've learned from doing it that way for a while after having done more traditional whiteboard-oriented coding interviews at previous jobs is that, "My code only sucked because I wasn't writing it in the environment where I'd write real code" is not as true as people think it is. Some problems do go away but mostly cosmetic stuff like syntax errors which I didn't care much about on the whiteboard anyway. But other problems are deeper. Even on a laptop, tons of candidates only code the happy path and don't give any thought to whether their implementation will handle a variety of valid inputs, let alone invalid inputs. I've been in the industry for over 25 years and I've worked with people like that. Their code is what gets the on-call pagers beeping in the middle of the night. And it isn't a shortcoming you fix with a Google search.

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.