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

Why we don't hire programmers based on puzzles and tricks

37signals.com

Post reply on HN
Print view View original

151–160 of 460 posts

Re: Why we don't hire programmers based on puzzles and tricks

#151

Post by bramcohen »

Over time I've made interview challenge problems progressively easier, as I've found that the trickier ones don't give any more information than the easier ones. My challenge now basically amounts to 'read this doubly nested for loop and tell me what it does', equivalent in difficulty to fizzbuzz.

If you can't solve that, even in the pressure of an interview, then I'm sorry, but you have no business working as a programmer, and I'm offended that you even applied.

And yes, people flunk it all the time.

Re: Why we don't hire programmers based on puzzles and tricks

#152

Post by mds »

dmbaggett wrote: post #5

At ITA Software, we found in-person quizzing to be a lot less useful an indicator than looking at puzzle (or other) code someone had written "offline". We also found puzzles to be a useful talent magnet. If you're Google (or perhaps 37Signals) you don't need a talent magnet. If you're a small company nobody's heard of, one can be quite helpful.

Not that it matters anymore since this was pre-Google, but I swear to god, someone actually asked me the manhole cover question when I interviewed at ITA in 2010. This was for a DevOps type role, so maybe they were less well organized on that side of the house.

At first I laughed because I thought he was joking until he I saw he was serious. He followed that up with something about stacking weights on a seesaw.

Re: Why we don't hire programmers based on puzzles and tricks

#153

Post by andrewaylett »

NateDad wrote: post #92
southphillyman wrote: post #48

Earlier quoted context omitted.

Yea this is where I'm at with it. If I walk into an interview and the first question is what is the difference between an abstract class and an interface my interest in the interview is probably going to decrease exponentially. How about asking me about my design approach to a specific problem, what frameworks have I try when presented with a specific problem and my thoughts on it, or what I'm currently learning. I g…

You assume people working at programming jobs for years on end have a clue... that's not always true. I've worked with people who couldn't do fizzbuzz, or describe the difference between an interface and an abstract class, or any other basic programming stuff. If they throw you an easy pitch, knock it out of the park and they'll ask you something more difficult afterward.

This is precisely right: I ask people questions like the difference between an interface and an abstract class as a gauge, because I've had so many people answer them really badly.

The question wouldn't normally come out of the blue, though, but as a follow-up from part of a design exercise where they would have just used one or the other in their design, and as part of finding out whether they could justify their choice.

Re: Why we don't hire programmers based on puzzles and tricks

#154

Post by ianstallings »

Well the good news is this problem should be solved soon since we spend so much time focused on it.

I don't care for puzzles. Just conversations. I skim resumes looking for glimpses into personality more than looking for skill sets. I have a guy that went to Yale on my team. I didn't even know that until he mentioned it the other day, yet it was on his resume. I missed it because I don't care where you went. I don't care how fast you can solve a puzzle. It's put up or shut up and show me what you've built when you come here. If you can do that in an interview there's a great chance I'll hire you. The last two hires whipped out apps they'd built and then we went over how they accomplished it. To me that's more valuable than any other process, having a portfolio or sample ready when you show up.

Re: Why we don't hire programmers based on puzzles and tricks

#155

Post by boomzilla »

jdmichal wrote: post #85
blparker wrote: post #47

I consider myself a proficient developer, however, in situations where I'm required to solve an obscure puzzle while someone is staring at me, generally makes me uncomfortable...no matter how easy the question. I interviewed for an internship position at Microsoft, where I was required to write some bizarre code on graph paper while the interviewer literally stood over my shoulder. Horribly uncomfortable, I barely ma…

I have a similar story with Microsoft when I interviewed with them my senior year also. I feel like I nailed everything except for the puzzles, and also got denied. My favorite one I "failed" on was: Given a node of a linked list, delete that node. The expected answer: Copy the next node's contents into the given node. Then delete the next node. Just simply never occurred to me to use a memory copy in a linked list.…

but that is not a puzzle, it's real code if you don't access to a collection library

Re: Why we don't hire programmers based on puzzles and tricks

#156

Post by rdtsc »

jwwest wrote: post #150

The best interview I ever had, I was given a problem to solve with a system, a whiteboard and 20 minutes. I sketched out a quick ERD, and explained the high level architecture of the system. No code was written -- it was assumed that I could implement said system if I could design it. The worst job interview grilled me on low level algorithms (I'm not a CS grad) and wanted me to sketch out a quick sort. Of course, I…

Exactly. Same here.

Now I give interviews, and I do the former not the later. Make sure you do the same if you get to interview others.

This puzzle and brainteaser shit needs to stop.

Re: Why we don't hire programmers based on puzzles and tricks

#157

Post by ianstallings »

andrewvc wrote: post #37
csmatt wrote: post #13

I remember when I was prepping for my Microsoft interview. There was so much lore online as to the types of questions they'd ask and how to prepare. I even found 'How Would You Move Mount Fuji?' in the library and started reading through it. It was an absolute waste of time as I, fortunately, learned weeks before the interview. As an example, one of the questions I was asked was 'how would you write the C function st…

I generally agree, most logic questions are useless, but Big-O notation I use every day. Programmers who don't understand the performance difference between Array#include? and Set#include? in ruby are dangerous!

All one really needs to know about Big-O is that nested data lists can be exponentially harder to process. If you understand that then you understand the need for it and when the time arises for you to create these type of structures you'll calculate the time needed to process them accordingly using said method. In turn helping you predict future performance and avoiding bottlenecks.

Re: Why we don't hire programmers based on puzzles and tricks

#158

Post by ironchef »

LockeWatts wrote: post #77
ironchef wrote: post #61

Earlier quoted context omitted.

"Asking a candidate a difficult brainteaser that may be even close to impossible can be extremely revealing." I prefer problems that are ridiculously simple on the outside; however, allow for lots of optimization. Choose the next best move in chess or go for example (or design a simple sudoku solver). A completely simplistic solver just chooses a valid move. It becomes more interesting as one looks at how are you mod…

"Choose the next best move in chess or go for example (or design a simple sudoku solver). " You make the assumption that your candidate knows anything about those games. If you placed me in front of a chess board, said "these are what the pieces do" and then asked me to tell you the next best move, that move will either be A) blindingly obvious to anyone who has played chess for years, or B) too difficult to someone…

No...I don't make the assumption they know anything about those games. I start off talking to them about some of the above games.. One could just as simply walk through other games (checkers, tick-tack-toe, hangman, etc.). Or...if they've never played games, then you could walk through other somewhat classic problems (how should one load an airplane, the back of a car when travelling).

My point was largely that there are a variety of problems out there which have "no right answer" yet are fairly intuitive to get started on...and figuring out modeling of the problem space in combination with decision logic is an excellent example of problem solving which may help one see how a candidate attacks problems, optimizes, etc.

Re: Why we don't hire programmers based on puzzles and tricks

#159

Post by jnbiche »

kamaal wrote: post #103

This is something to think about. The interview process is so badly gamed that these days its kind of a ceremony. In a recent interview, I gave a candidate a practical problem. He was allowed to use the sed man page, and then I gave him a file and search/replace problem. Nothing much! The candidate fails! Instead he asks me if there is going to be a algorithm/data structure interview. I told him, I don't know but as…

May I ask where you work? I'd love to interview at a company like yours.

I'm in the process of changing careers to programming in my late 30s. I dabbled in coding on and off for most of my life, but two years ago I started taking it seriously, read K&R, etc, and completely fell in love with programming. And so I start thinking about working full-time as a developer, and schedule an interview for a programming position for a company in the industry where I've worked for the past decade. I've always been a confident interviewer, but I totally froze in this phone interview. They started the interview off with a tough algorithm problem that I probably could have solved on my own in 30-40 minutes, but couldn't possibly solve on the spot in a conference call, with several people listening in and quizzing me. From there, things went downhill quickly, and I struggled to answer questions that I could have easily answered on my own at my desk. Since then, I've been burned on two freelance programming assignments (that I should have known better than to take given the level of desperation involved), which was quite a blow after spending a decade freelancing for dozens of clients without incident in another industry.

I love programming, and so I continue to code whenever I get the chance (and have two rather large projects underway), but these experiences have shaken my confidence. If most programming jobs involve similar interview processes, I'm not sure this would be the best move for me.

However, this comment has given me hope. If there are companies out there like this, then I stand a fighting chance -- I would excel at an interview where I'm given a problem, a time limit, vim, and then told to go solve it with no whiteboard or group of people watching. Let it be a hard problem, but make it realistic -- not some obscure puzzle or algorithm -- and let me use my own tools. I wish there were some job board where companies with this type of interview process posted jobs.

Re: Why we don't hire programmers based on puzzles and tricks

#160

Post by ricardoz17 »

danielweber wrote: post #128
grey-area wrote: post #91

Earlier quoted context omitted.

I think the point of the article is this: Trivial puzzlers like:write a fizzbuzz program, swap two variable contents without using a temp variable, how do you count the stars in the universe Just encourage people to game the system. It's impossible to get real insight from them, because you can't differentiate between those who worked it out, and those who have read about it. If you're in an interview by now and some…

As much as people say "well, everyone knows about Fizzbuzz by now," lots of people still can't do it. "Swapping two variables without a temp" is a bad question, because it depends on knowing the trick. "Find the 2nd-highest element of this list" is a basic question, and I can change it up it a zillion ways such that anyone trying to just learn all possible permutations will end up doing way more work than someone who…

I think the swapping two variables has a bit more going for it if they do not know the trick. Explain the concept of invertible functions. Hopefully they would be able to come up with plus and minus - even if you have to walk them through the a=f(a,b) b=g(a,b) a=g(a,b)

From there you can say that works fine with pen and paper but why might it go wrong in a program? So how do you avoid integer overflow? If the signs are the same then use subtract first else use addition first. After we have done that. After this step assume I have returned to the main flow. How do I check if I should use addition or subtraction? If a is bigger than b I must have added so use subtraction. Writing the algorithm this way is trickier than xor. The problems to be solved are to do with understanding concepts

Next you have the xor solution but more important than getting the answer to that might be to see if they can see that the two functions are like encrypt and decrypt where a is the message and b is a key and a + b is the ciphertext c - so that f(m,k) is encrypt and g(c,k) gives the message and g(c,m) gives the key. If they have had any exposure to cryptography then xor should present itself.

If they give xor straight off then you can work backwards.

Post reply on HN