6 ms·

Interviewers ask puzzles and give you tricks because they want to see your problem solving process. Obviously, anyone who hires simply off a litmus test of such

Interviewers ask puzzles and give you tricks because they want to see your problem solving process. Obviously, anyone who hires simply off a litmus test of such questions is not doing their job, but that doesn't preclude the use of such brain teasers/problems at all. Asking a candidate a difficult brainteaser that may be even close to impossible can be extremely revealing. There isn't a canned response, you get to see them work under pressure, you experience live problem solving and you can understand how they move through their work better. All of these factors are just as important as competency when hiring. A great programmer doesn't "fizzle" in front of a difficult interview question. He/she may or may not get the correct answer, but as long as they have the requisite problem solving skills and communicate with their interviewer well they will come out fine. I'd say that showing how you fail can be quite beneficial when trying to get a job, especially if you happen to fail gracefully :) It seems like 37signals is just echoing platitudes to gain karma/publicity at the expense of cheapening the discussion.

herdcall 14y ago
All good, but the success of this method also depends on how well the interviewer interprets/evaluates the interview. Unfortunately, the danger here is that inexperienced/immature interviewers can easily discard good candidates this way. This is similar to the skill required to grade a written test for partially correct answers vs. right/wrong ones. Hence the criticism on wide-spread usage.
gizzlon 14y ago
People can be nervous on job interview and therefore "shut down" and fail simple tests. This does not reveal a persons real problem solving skills. I don't consider myself especially nervous in job interviews and when taking tests and exams. But I still had a much harder time solving simple programming tasks than I would "back at my desk" with no-one watching. YMMW. It would suck to want a job so bad you completely freeze up on simple interviewing tests :(
- pwny 14y ago
  On the other hand, if I'm hiring someone for a high pressure job I don't want them to fail when under pressure. I understand your point but I don't really buy it. I train lifeguards as a hobby/side-job (I'm in uni right now) and pressure is the number 1 reason they give us for failing their final pratical test. I can't give a kid a permit to work as a lifeguard if the pressure of an exam makes him screw up because the real life pressure of saving somebody's life is even greater. The exact same applies here for all jobs where you expect the engineer to work in stressful situations.
  - LockeWatts 14y ago
    "On the other hand, if I'm hiring someone for a high pressure job I don't want them to fail when under pressure." But those are in no way the same kinds of pressure. The pressure of being able to meet a release date, design incredibly safety sensitive algorithms, etc, are completely different from the social pressure of having someone evaluate work you normally do by yourself, in real time. This kind of interviewing would work well for the kind of stress a salesman gets, not the kind of stress a software engineer gets.
    - pwny 14y ago
      I completely agree and that's why that part of the interview shouldn't be the only one. As someone said earlier, it should be a negative filter of incredibly unsuitable candidates. In a perfect setting the interviewer wouldn't evaluate the candidate's ability to solve the problem, but his/her ability to approach it, explore it, ask questions and take steps in the appropriate direction.
  - deleted 14y ago
    [deleted]
  - Proleps 14y ago
    > On the other hand, if I'm hiring someone for a high pressure job I don't want them to fail when under pressure. Programming is not like in those hacker movies, we don't have to solve problems in 60 seconds while getting a blow job[1]. [1]https://www.youtube.com/watch?v=rUY8HysBzsE https://www.youtube.com/watch?v=rUY8HysBzsE
ironchef 14y ago
"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 modeling state, how are you deciding what is best, etc. This way most people will get something that works, you can see their thought processes (where are they optimizing first, why are they doing that), and maybe learn something new.
- LockeWatts 14y ago
  "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 who has never played the game before. Reapply the same paragraph to Go and Sudoku. You've created a filter for someone who plays games, not problem solving skills.
  - danielweber 14y ago
    That's why the interviewer should ask if they are familiar with those games first. Even Connect Four or tic-tac-toe can be a useful exercise to go over with someone.
  - ironchef 14y ago
    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.
NateDad 14y ago
I care about three things in a candidate: Code Quality Productivity Communication ... pretty much in that order. Brain teasers test none of those things (maybe a some communication) I've never met a coder that couldn't eventually figure out a way to hack the code to do what the PMs want. But I have met a lot of coders that take way too long and/or produce horrific code that is a buggy maintenance nightmare. Those people often do ok on brain teasers (or at least do well enough that the interviewer doesn't feel like he can give negative feedback). A more important point is that brain teasers are a waste of time compared to a million other things you could be doing with the candidate to determine their aptitude, like actually writing code to solve a problem.
bluekite2000 14y ago
I have heard of interviewers asking candidates to solve various levels on mobile brainteaser apps. Something like this game https://itunes.apple.com/us/app/smart-kick-pro/id590049769?mt=8 https://itunes.apple.com/us/app/smart-kick-pro/id590049769?m... could work well as it involves problem solving skills and is a great fun little ice breaker.
dhimes 14y ago
A great programmer doesn't "fizzle" in front of a difficult interview question How do you know this?
- nonamegiven 14y ago
  A great employee is more than a great programmer.
Terretta 14y ago
> Interviewers ask puzzles and give you tricks because they want to see your problem solving process. It depends on the "problem solving process" you are trying to get insight into. These procedural "how does the candidate get to the answer?" questions are great for procedural thinkers. Even if they don't know details that feed into reaching an answer, they can show you how they'd get there. Unfortunately, if your staff ends up entirely composed of procedural thinkers, you may find your company challenged at innovation. For that, you need candidates good at "Eureka" moments. Your Eureka candidates will often do quite badly in the procedural "what's your thought process?" questions in the one hour interview context. Measured over a 24 hour period, they may do notably better. "The problem solver initially has a low probability for success because they use inappropriate knowledge as they set unnecessary constraints on the problem. Once the person relaxes his or her constraints, they can bring previously unavailable knowledge into working memory to solve the problem." -- http://en.wikipedia.org/wiki/Eureka_effect#How_people_solve_insight_problems http://en.wikipedia.org/wiki/Eureka_effect#How_people_solve_... What you're looking for here is both broad and deep domain expertise, coupled with an ability to understand the question well then let the subconscious mind pull together the insights needed for a breakthrough solution. This process cannot be talked through out loud. The answer may take longer (hours, a day or two, probably reached in the proverbial shower), but will often be an answer that gives you a long term competitive edge over a blunt procedural approach. This said, it's not clear to me how to interview for this ability. I'd start by considering a way to understand the depth and breadth of a candidate's exposure to technology and domain knowledge. This is the opposite of interview processes using dives into the interviewer's area of expertise. I might consider a two part interview a few days apart, where the candidate gets the context in part one, and shares their thinking in part two. > Asking a candidate a difficult brainteaser that may be even close to impossible can be extremely revealing. There isn't a canned response, you get to see them work under pressure, you experience live problem solving and you can understand how they move through their work better. All of these factors are just as important as competency when hiring. Except that this situation is an artificial construct. You're covering their mouth and nose and saying, "Now show me how you breathe." You are favoring candidates whose problem solving is informed by the belief they can reach an emergency answer on their own through brute force, rather than those whose problem solving starts with the assumption that someone else has already solved or mostly solved the problem and who is great at finding the "shoulders of giants" to stand on, building an informed answer a priori. I'm reminded of getting my deep water scuba certification. You're not interviewed for a diving salvage job by repeatedly seeing how you handle having your breathing apparatus turned off. Yes, a diver should be able to "perform under pressure", but what you really want are divers who help ensure nobody on the team ends up under pressure.

herdcall 14y ago

All good, but the success of this method also depends on how well the interviewer interprets/evaluates the interview. Unfortunately, the danger here is that inexperienced/immature interviewers can easily discard good candidates this way. This is similar to the skill required to grade a written test for partially correct answers vs. right/wrong ones. Hence the criticism on wide-spread usage.

gizzlon 14y ago

People can be nervous on job interview and therefore "shut down" and fail simple tests. This does not reveal a persons real problem solving skills. I don't consider myself especially nervous in job interviews and when taking tests and exams. But I still had a much harder time solving simple programming tasks than I would "back at my desk" with no-one watching. YMMW. It would suck to want a job so bad you completely freeze up on simple interviewing tests :(

pwny 14y ago
On the other hand, if I'm hiring someone for a high pressure job I don't want them to fail when under pressure. I understand your point but I don't really buy it. I train lifeguards as a hobby/side-job (I'm in uni right now) and pressure is the number 1 reason they give us for failing their final pratical test. I can't give a kid a permit to work as a lifeguard if the pressure of an exam makes him screw up because the real life pressure of saving somebody's life is even greater. The exact same applies here for all jobs where you expect the engineer to work in stressful situations.
- LockeWatts 14y ago
  "On the other hand, if I'm hiring someone for a high pressure job I don't want them to fail when under pressure." But those are in no way the same kinds of pressure. The pressure of being able to meet a release date, design incredibly safety sensitive algorithms, etc, are completely different from the social pressure of having someone evaluate work you normally do by yourself, in real time. This kind of interviewing would work well for the kind of stress a salesman gets, not the kind of stress a software engineer gets.
  - pwny 14y ago
    I completely agree and that's why that part of the interview shouldn't be the only one. As someone said earlier, it should be a negative filter of incredibly unsuitable candidates. In a perfect setting the interviewer wouldn't evaluate the candidate's ability to solve the problem, but his/her ability to approach it, explore it, ask questions and take steps in the appropriate direction.
- deleted 14y ago
  [deleted]
- Proleps 14y ago
  > On the other hand, if I'm hiring someone for a high pressure job I don't want them to fail when under pressure. Programming is not like in those hacker movies, we don't have to solve problems in 60 seconds while getting a blow job[1]. [1]https://www.youtube.com/watch?v=rUY8HysBzsE https://www.youtube.com/watch?v=rUY8HysBzsE

ironchef 14y ago

"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 modeling state, how are you deciding what is best, etc. This way most people will get something that works, you can see their thought processes (where are they optimizing first, why are they doing that), and maybe learn something new.

LockeWatts 14y ago
"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 who has never played the game before. Reapply the same paragraph to Go and Sudoku. You've created a filter for someone who plays games, not problem solving skills.
- danielweber 14y ago
  That's why the interviewer should ask if they are familiar with those games first. Even Connect Four or tic-tac-toe can be a useful exercise to go over with someone.
- ironchef 14y ago
  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.

NateDad 14y ago

I care about three things in a candidate: Code Quality Productivity Communication ... pretty much in that order. Brain teasers test none of those things (maybe a some communication) I've never met a coder that couldn't eventually figure out a way to hack the code to do what the PMs want. But I have met a lot of coders that take way too long and/or produce horrific code that is a buggy maintenance nightmare. Those people often do ok on brain teasers (or at least do well enough that the interviewer doesn't feel like he can give negative feedback). A more important point is that brain teasers are a waste of time compared to a million other things you could be doing with the candidate to determine their aptitude, like actually writing code to solve a problem.

bluekite2000 14y ago

I have heard of interviewers asking candidates to solve various levels on mobile brainteaser apps. Something like this game https://itunes.apple.com/us/app/smart-kick-pro/id590049769?mt=8 https://itunes.apple.com/us/app/smart-kick-pro/id590049769?m... could work well as it involves problem solving skills and is a great fun little ice breaker.

dhimes 14y ago

A great programmer doesn't "fizzle" in front of a difficult interview question How do you know this?

nonamegiven 14y ago
A great employee is more than a great programmer.

Terretta 14y ago

> Interviewers ask puzzles and give you tricks because they want to see your problem solving process. It depends on the "problem solving process" you are trying to get insight into. These procedural "how does the candidate get to the answer?" questions are great for procedural thinkers. Even if they don't know details that feed into reaching an answer, they can show you how they'd get there. Unfortunately, if your staff ends up entirely composed of procedural thinkers, you may find your company challenged at innovation. For that, you need candidates good at "Eureka" moments. Your Eureka candidates will often do quite badly in the procedural "what's your thought process?" questions in the one hour interview context. Measured over a 24 hour period, they may do notably better. "The problem solver initially has a low probability for success because they use inappropriate knowledge as they set unnecessary constraints on the problem. Once the person relaxes his or her constraints, they can bring previously unavailable knowledge into working memory to solve the problem." -- http://en.wikipedia.org/wiki/Eureka_effect#How_people_solve_insight_problems http://en.wikipedia.org/wiki/Eureka_effect#How_people_solve_... What you're looking for here is both broad and deep domain expertise, coupled with an ability to understand the question well then let the subconscious mind pull together the insights needed for a breakthrough solution. This process cannot be talked through out loud. The answer may take longer (hours, a day or two, probably reached in the proverbial shower), but will often be an answer that gives you a long term competitive edge over a blunt procedural approach. This said, it's not clear to me how to interview for this ability. I'd start by considering a way to understand the depth and breadth of a candidate's exposure to technology and domain knowledge. This is the opposite of interview processes using dives into the interviewer's area of expertise. I might consider a two part interview a few days apart, where the candidate gets the context in part one, and shares their thinking in part two. > Asking a candidate a difficult brainteaser that may be even close to impossible can be extremely revealing. There isn't a canned response, you get to see them work under pressure, you experience live problem solving and you can understand how they move through their work better. All of these factors are just as important as competency when hiring. Except that this situation is an artificial construct. You're covering their mouth and nose and saying, "Now show me how you breathe." You are favoring candidates whose problem solving is informed by the belief they can reach an emergency answer on their own through brute force, rather than those whose problem solving starts with the assumption that someone else has already solved or mostly solved the problem and who is great at finding the "shoulders of giants" to stand on, building an informed answer a priori. I'm reminded of getting my deep water scuba certification. You're not interviewed for a diving salvage job by repeatedly seeing how you handle having your breathing apparatus turned off. Yes, a diver should be able to "perform under pressure", but what you really want are divers who help ensure nobody on the team ends up under pressure.