6 ms·

Don't use a white board or a pad of paper. A select few eccentric programmers have ever actually sat down and wrote out a program on paper. Every physicist can

Don't use a white board or a pad of paper. A select few eccentric programmers have ever actually sat down and wrote out a program on paper. Every physicist can solve first-year physics problems on the back of a napkin. Every mathematician can solve first-year math problems on the back of a napkin. Every machinist can sketch her approach to making a widget on the back of a napkin. Electrical engineers can sketch schematics. Chemical engineers can sketch reactions. Architects do nothing but sketch. Why? Because practice makes perfect: In most technical fields, thinking on paper is an important part of basic education. Why? Because even at the highest level so much of the most important creative work is done on whiteboards or notebooks or lunch-counter napkins, often in the middle of an impromptu jam session with the smartest peers you can find. My Ph.D. work was mostly involved with machines and materials, but the essential plans and conclusions were sketched out on a set of whiteboards in a series of evening discussions after eating pizza with some folks from my research group. This was completely typical. If you can't think about programming without electronic help, does that mean you can't think about programming while walking down the street, or showering, or shaving, or doing dishes? If you can't discuss software, even at the oh-so-basic level of an interview question, without a screen and keyboard in front of you, does that mean that you can't design software while eating at a nice restaurant with your collaborators? If you can't communicate technically in person in real time -- and we're talking really basic stuff, not formal proofs of Euclid's Algorithm or anything -- why should you be hired onto a team? The team can just outsource you.

Retric 16y ago
There is no such thing as first year programming problems. At best you provide a simple problem with minimal constrains, but they have nothing to do with professional programming. PS: What would you do if someone said write a function that will sort these three numbers? Hint: there is no safe answer.
- mechanical_fish 16y ago
  Problems without safe answers are great. They are infinite fodder for discussion. P.S. Let's assume, oh interviewer, that your answer to my question "what kind of numbers?" is "integers, for now". sort(a,b,c) { exchange(a,b) if a > b exchange(b,c) if b > c exchange(a,b) if a > b return (a,b,c) } I think that's probably the stupidest thing that could possibly work, not counting: <?php $sorted = sort($unsorted); Assuming it does work, of course. It may have a bug. Probably does, in fact. Now you could ask me to find the bug and I'd write out some test cases in the margin. Or you could ask me what happens if a string gets in there, or how I'd generalize this algorithm to N numbers, or what kind of language I'm using with this exchange primitive in it (answer: my own highly arbitrary mental pseudocode!) or how I'd implement the exchange primitive, or how fast this algorithm will run on N numbers (not very; it looks to be O(N!), and that's not counting the fact that my exchange primitive is probably wicked slow). Or, depending on the job, you might head in some other direction.
  - Retric 16y ago
    My point is there is no default correct answer to that type of problem. In physics there are default approaches based on ignoring wind resistance etc. However, in computing knowing which questions to ask is the real test and they don't teach you that in your first year. EX1: You wrote code before asking for more details you fail. EX2: Then again some people view asking questions as stalling. Perhaps they are thinking about sorting a vector and want you to use the the language library of your choice or write something. Or perhaps they want a few lines of ASM that include at most 2 swaps and: x = x xor y y = x xor y x = x xor y But if it's a high level ASM then you may have XCHG etc.
    - mechanical_fish 16y ago
      EX1: You wrote code before asking for more details you fail. EX2: Then again some people view asking questions as stalling. This is interviewing, not a mathematics competition or a judicial proceeding. It's not a test, it's a first date. If your interviewer applies either of these rules so strictly that you "fail", you probably don't want to work for them... ...unless you really are the type of person who wants a work environment where such rules apply strictly, and you happen to have the same ruleset as the person who is interviewing you. In which case the two of you may work together very well, and the interview will be a big success. The first rule of interviewing is: Although one of you is leading, and one of you is following, you are interviewing each other. It's a conversation. If I start out answering your question on a track that you don't want to follow -- integers and not vectors, Lisp but not ASM -- you need to lead me in the right direction, just as you would do if we were discussing a real problem. Your ability to guide the conversation, and my ability to follow, and our resultant ability to establish a rapport and keep the conversation moving, is what is under test here. The problem itself is far less important. P.S. I have seen that XOR trick before, once, but it still blows my mind. I can never understand it without spending half an hour in a corner muttering to myself. Is there a field where that trick is so idiomatic that it's a reasonable thing to expect a candidate to come up with it an interview?
      - sushantsharma 16y ago
- Leynos 16y ago
  I'm not sure I follow. I seem to remember being given various algorithmic and data structure related problems to solve in 1st year of University - both the implementation and appropriate application of algorithms - that I tend to find myself using as fundamental building blocks in my work. Granted, I haven't had to write a sort function since 1st year, but knowing when to use various approaches to representing and processing data and their limitations is pretty much fundamental stuff.
- mseebach 16y ago
  > Hint: there is no safe answer. I'd be interested in hearing what you're thinking of -- but if you're right that actually makes it a perfect interview question. The baseline implementation is simple, but you can keep pointing out deficiencies and observe how the candidate attacks the revised problem. The point of interview coding problems isn't to produces production-quality code with no preparation, it's to gain some insight in the way the candidate attacks a problem, particularly when approaching the edge of his abilities. At one of the interviews I went through for my current job, I completely tanked on a question that fished for a particular design pattern. But while I didn't figure out I needed to use that particular pattern, I was able to participate actively in the discussion on how and why the solution I chose wasn't optimal.
  - Retric 16y ago
    Simply put based the type job your applying for there is types of solutions they are going to want to see. Without knowing more about the job you may be thinking frameworks while they want ASM.
    - ori_b 16y ago
      Then ask for elaboration. It's a discussion, not a monologue.
      - Retric 16y ago
        Of course, but that's not a year one problem. If I say how much energy does a 10kg rock gain falling 50m in a 1G gravity field you can just solve it. However, when handed a simple programming problem the natural instinct is to ask for just a little more information. I find many programmers have issues quickly context switching between thinking about the problem, discovering what the constraints are, coding a solution, and then debugging that solution. Ask them to do it on a blackboard under a little pressure and they can't do it. The problem is the better programmers often do worse in these situations because they think about more things at each step so they need to keep purging more ideas.
- palish 16y ago
  r[0] = Min( a, Min( b, c ) ) r[2] = Max( a, Max( b, c ) ) r[1] = a + b + c - r[0] - r[2] I don't think that can suffer from integer overflow. But it might suffer from floating-point rounding problems. Of course you could always go with the boring solution: if a > b: swap( a, b ) if b > c: swap( b, c ) if a > b: swap( a, b )
agentultra 16y ago
I'm talking specifically about interviews here. (In short, yes one should be able to think about programming problems while away from the computer. However, one doesn't arrive at a solution away from the computer. Napkins don't compile.) Writing code in an interview will tell you one of two things: 1. This person has encountered the problem before and is simply regurgitating the solution they came to when they had four months to work on it and the assistance of a TA and other students. 2. This person has not encountered the problem before. While the latter case is considered ideal, it only works if you know how to ask the proper questions. I suggest avoiding it because there are more direct ways to get what you want to know. My suggestion? Code reviews. Have some pre-made examples or ask the candidate to bring their own code. No one has to be put on the spot. It's much easier to control the dialog.
kgo 16y ago
If you're talking pseudo-code, I'd agree. And I think all these various sketches you're talking about are comparable to psuedo-code. Those sketches aren't going to tell you exactly what PSI some escape valve needs to blow at, or what temperature a reaction is going to run at, etc. If you're expecting me to write out code that can be ocr'ed and compiled, which is basically what most whiteboard tests expect, I'd disagree. I failed one whiteboard test (C#) because: (a) I didn't know the formatting for Console.WriteLine off the top of my head, because who the hell uses that when writing an app anyway? (b) Because I didn't check the List<int> parameter too see if it was null, even though I did handle an empty list correctly. With the whole interview thing going on, I didn't even argue point (b), there was too much going on. On the way home I was thinking about it, and as a design decision I actually would've just let the function throw a NullPointerException. No specification was provided to the contrary. Should I have wrapped it in a FooAppException, java-style? Or just silently done nothing even though the inputs were invalid?
jules 16y ago
In my experience thinking is nigh impossible with your hands on the keyboard. Thinking happens in the shower, or with a pen in your hand and a sheet of paper in front of you, or in a conversation. Here's a homework question that I got last week: Two numbers x and y in 0..50 with x <= y get selected. Bob gets told x^2+y^2, Alice gets told x+y. Alice and Bob have the following conversation: - Bob: I don't know which numbers x and y are. - Alice: I don't know which numbers x and y are. - Bob: I don't know which numbers x and y are. - Alice: I don't know which numbers x and y are. - Bob: I don't know which numbers x and y are. - Alice: I don't know which numbers x and y are. - Bob: Now I know which numbers x and y are. Question: which numbers can x and y be? If you're able to solve this problem by firing up your editor and starting coding the 10 lines of code required to solve it I'd be very surprised. Hard problems require real thinking.
- phaedrus 16y ago
  Reminds me of the blue-eyed islanders puzzle. http://www.xkcd.com/blue_eyes.html http://www.xkcd.com/blue_eyes.html
  - jules 16y ago
    That's a similar puzzle. Maybe it's because I solved the homework puzzle first, but the blue eyes puzzle is much much easier. You might want to try to solve that first ;) The cool thing about the blue eyes puzzle is that you can solve it without a computer or pen and paper.
- kingkilr 16y ago
  Maybe my thinking is a bit slow here, but can't you even only begin to hope to answer this question if you assume Alice and Bob are cooperating in some fashion?
  - seabee 16y ago
    It's a very awkwardly phrased recursion problem. The point is to find a unique x, y where x <= y. The algorithm starts with the set of all possible (x, y) pairs, and switches between the Bob and Alice stages. In Bob's stage, eliminate pairs that give a unique value for x^2 + y^2. If such a unique value matches the value Bob was given, then obviously you know x, y for sure. Otherwise, switch to Alice's stage, which operates on the remaining pairs from Bob's stage, and eliminates all pairs that give a unique value for x + y. The weirdness in the question is both Alice and Bob are performing the exact same algorithm, but (to use CSP parlance) there is a channel from Bob to Alice in Bob's stage, and vice versa, due to the different information given to both parties. Alice must wait for Bob to declare if the algorithm has terminated or not.
jasonkester 16y ago
While you're absolutely correct, it's worth noting that for most of the disciplines you mention, the actual work takes place on paper too. A mathematician, physicist or engineer will spend most of his working life scribbling on paper, so it makes a lot of sense to interview that way. There are plenty of other fields that don't work quite that way. You wouldn't interview a baseball player by asking him to describe hitting a curve ball on paper, or a nurse by asking him to draw stiches on a piece of paper. Every field has its own medium of expression. For many fields, that's paper. For programming, it's a text editor.
ubernostrum 16y ago
If I ask a physicist to sketch out a solution to a problem, I'll be willing to accept that they may need to look up some constants or formulas along the way, because knowing how to attack the problem and memorizing a bunch of numbers are two very different things; the latter is useful from time to time, but it's the former that I care about if I'm interviewing you. Why, then, do so many interview processes assume that the ability to, essentially, vomit rote-memorized bits of syntax, argument orders, etc. onto a whiteboard is so important that any "real programmer" should be able to do it on command?
- mfukar 16y ago
  Perfect analogy right there. See Tim Bray doesn't know operator precedence rules. It's perfectly possible to live and work and thrive without memorizing everything. This is what being an engineer is all about. Yet the FUD that goes into interview & recruitment processes (as well as other aspects of a programmer's work, but that's a longer story) is astonishing.
sliverstorm 16y ago
I would expect any programmer would be able to write a program on paper. I wouldn't expect it to be perfect or even compilable, just the same as a widget or schematic. Physicists and mathematicians have an advantage in producing 'perfect' things on paper, because they 'solve' where the other examples you gave 'develop'. They work in the other direction; the mathematical pursuits analyze systems whereas you have asked the other pursuits to create systems, which is much more difficult on a piece of paper. Now, if you had the designers working forwards- analyzing code or schematics or widgets- then I would expect an accurate answer (with a little fuzz for basic mistakes, same as I'd give a mathematician slack for accidentally dropping a minus sign)

Retric 16y ago

There is no such thing as first year programming problems. At best you provide a simple problem with minimal constrains, but they have nothing to do with professional programming. PS: What would you do if someone said write a function that will sort these three numbers? Hint: there is no safe answer.

mechanical_fish 16y ago
Problems without safe answers are great. They are infinite fodder for discussion. P.S. Let's assume, oh interviewer, that your answer to my question "what kind of numbers?" is "integers, for now". sort(a,b,c) { exchange(a,b) if a > b exchange(b,c) if b > c exchange(a,b) if a > b return (a,b,c) } I think that's probably the stupidest thing that could possibly work, not counting: <?php $sorted = sort($unsorted); Assuming it does work, of course. It may have a bug. Probably does, in fact. Now you could ask me to find the bug and I'd write out some test cases in the margin. Or you could ask me what happens if a string gets in there, or how I'd generalize this algorithm to N numbers, or what kind of language I'm using with this exchange primitive in it (answer: my own highly arbitrary mental pseudocode!) or how I'd implement the exchange primitive, or how fast this algorithm will run on N numbers (not very; it looks to be O(N!), and that's not counting the fact that my exchange primitive is probably wicked slow). Or, depending on the job, you might head in some other direction.
- Retric 16y ago
  My point is there is no default correct answer to that type of problem. In physics there are default approaches based on ignoring wind resistance etc. However, in computing knowing which questions to ask is the real test and they don't teach you that in your first year. EX1: You wrote code before asking for more details you fail. EX2: Then again some people view asking questions as stalling. Perhaps they are thinking about sorting a vector and want you to use the the language library of your choice or write something. Or perhaps they want a few lines of ASM that include at most 2 swaps and: x = x xor y y = x xor y x = x xor y But if it's a high level ASM then you may have XCHG etc.
  - mechanical_fish 16y ago
    EX1: You wrote code before asking for more details you fail. EX2: Then again some people view asking questions as stalling. This is interviewing, not a mathematics competition or a judicial proceeding. It's not a test, it's a first date. If your interviewer applies either of these rules so strictly that you "fail", you probably don't want to work for them... ...unless you really are the type of person who wants a work environment where such rules apply strictly, and you happen to have the same ruleset as the person who is interviewing you. In which case the two of you may work together very well, and the interview will be a big success. The first rule of interviewing is: Although one of you is leading, and one of you is following, you are interviewing each other. It's a conversation. If I start out answering your question on a track that you don't want to follow -- integers and not vectors, Lisp but not ASM -- you need to lead me in the right direction, just as you would do if we were discussing a real problem. Your ability to guide the conversation, and my ability to follow, and our resultant ability to establish a rapport and keep the conversation moving, is what is under test here. The problem itself is far less important. P.S. I have seen that XOR trick before, once, but it still blows my mind. I can never understand it without spending half an hour in a corner muttering to myself. Is there a field where that trick is so idiomatic that it's a reasonable thing to expect a candidate to come up with it an interview?
    - sushantsharma 16y ago
Leynos 16y ago
I'm not sure I follow. I seem to remember being given various algorithmic and data structure related problems to solve in 1st year of University - both the implementation and appropriate application of algorithms - that I tend to find myself using as fundamental building blocks in my work. Granted, I haven't had to write a sort function since 1st year, but knowing when to use various approaches to representing and processing data and their limitations is pretty much fundamental stuff.
mseebach 16y ago
> Hint: there is no safe answer. I'd be interested in hearing what you're thinking of -- but if you're right that actually makes it a perfect interview question. The baseline implementation is simple, but you can keep pointing out deficiencies and observe how the candidate attacks the revised problem. The point of interview coding problems isn't to produces production-quality code with no preparation, it's to gain some insight in the way the candidate attacks a problem, particularly when approaching the edge of his abilities. At one of the interviews I went through for my current job, I completely tanked on a question that fished for a particular design pattern. But while I didn't figure out I needed to use that particular pattern, I was able to participate actively in the discussion on how and why the solution I chose wasn't optimal.
- Retric 16y ago
  Simply put based the type job your applying for there is types of solutions they are going to want to see. Without knowing more about the job you may be thinking frameworks while they want ASM.
  - ori_b 16y ago
    Then ask for elaboration. It's a discussion, not a monologue.
    - Retric 16y ago
      Of course, but that's not a year one problem. If I say how much energy does a 10kg rock gain falling 50m in a 1G gravity field you can just solve it. However, when handed a simple programming problem the natural instinct is to ask for just a little more information. I find many programmers have issues quickly context switching between thinking about the problem, discovering what the constraints are, coding a solution, and then debugging that solution. Ask them to do it on a blackboard under a little pressure and they can't do it. The problem is the better programmers often do worse in these situations because they think about more things at each step so they need to keep purging more ideas.
palish 16y ago
r[0] = Min( a, Min( b, c ) ) r[2] = Max( a, Max( b, c ) ) r[1] = a + b + c - r[0] - r[2] I don't think that can suffer from integer overflow. But it might suffer from floating-point rounding problems. Of course you could always go with the boring solution: if a > b: swap( a, b ) if b > c: swap( b, c ) if a > b: swap( a, b )

agentultra 16y ago

I'm talking specifically about interviews here. (In short, yes one should be able to think about programming problems while away from the computer. However, one doesn't arrive at a solution away from the computer. Napkins don't compile.) Writing code in an interview will tell you one of two things: 1. This person has encountered the problem before and is simply regurgitating the solution they came to when they had four months to work on it and the assistance of a TA and other students. 2. This person has not encountered the problem before. While the latter case is considered ideal, it only works if you know how to ask the proper questions. I suggest avoiding it because there are more direct ways to get what you want to know. My suggestion? Code reviews. Have some pre-made examples or ask the candidate to bring their own code. No one has to be put on the spot. It's much easier to control the dialog.

kgo 16y ago

If you're talking pseudo-code, I'd agree. And I think all these various sketches you're talking about are comparable to psuedo-code. Those sketches aren't going to tell you exactly what PSI some escape valve needs to blow at, or what temperature a reaction is going to run at, etc. If you're expecting me to write out code that can be ocr'ed and compiled, which is basically what most whiteboard tests expect, I'd disagree. I failed one whiteboard test (C#) because: (a) I didn't know the formatting for Console.WriteLine off the top of my head, because who the hell uses that when writing an app anyway? (b) Because I didn't check the List<int> parameter too see if it was null, even though I did handle an empty list correctly. With the whole interview thing going on, I didn't even argue point (b), there was too much going on. On the way home I was thinking about it, and as a design decision I actually would've just let the function throw a NullPointerException. No specification was provided to the contrary. Should I have wrapped it in a FooAppException, java-style? Or just silently done nothing even though the inputs were invalid?

jules 16y ago

In my experience thinking is nigh impossible with your hands on the keyboard. Thinking happens in the shower, or with a pen in your hand and a sheet of paper in front of you, or in a conversation. Here's a homework question that I got last week: Two numbers x and y in 0..50 with x <= y get selected. Bob gets told x^2+y^2, Alice gets told x+y. Alice and Bob have the following conversation: - Bob: I don't know which numbers x and y are. - Alice: I don't know which numbers x and y are. - Bob: I don't know which numbers x and y are. - Alice: I don't know which numbers x and y are. - Bob: I don't know which numbers x and y are. - Alice: I don't know which numbers x and y are. - Bob: Now I know which numbers x and y are. Question: which numbers can x and y be? If you're able to solve this problem by firing up your editor and starting coding the 10 lines of code required to solve it I'd be very surprised. Hard problems require real thinking.

phaedrus 16y ago
Reminds me of the blue-eyed islanders puzzle. http://www.xkcd.com/blue_eyes.html http://www.xkcd.com/blue_eyes.html
- jules 16y ago
  That's a similar puzzle. Maybe it's because I solved the homework puzzle first, but the blue eyes puzzle is much much easier. You might want to try to solve that first ;) The cool thing about the blue eyes puzzle is that you can solve it without a computer or pen and paper.
kingkilr 16y ago
Maybe my thinking is a bit slow here, but can't you even only begin to hope to answer this question if you assume Alice and Bob are cooperating in some fashion?
- seabee 16y ago
  It's a very awkwardly phrased recursion problem. The point is to find a unique x, y where x <= y. The algorithm starts with the set of all possible (x, y) pairs, and switches between the Bob and Alice stages. In Bob's stage, eliminate pairs that give a unique value for x^2 + y^2. If such a unique value matches the value Bob was given, then obviously you know x, y for sure. Otherwise, switch to Alice's stage, which operates on the remaining pairs from Bob's stage, and eliminates all pairs that give a unique value for x + y. The weirdness in the question is both Alice and Bob are performing the exact same algorithm, but (to use CSP parlance) there is a channel from Bob to Alice in Bob's stage, and vice versa, due to the different information given to both parties. Alice must wait for Bob to declare if the algorithm has terminated or not.

jasonkester 16y ago

While you're absolutely correct, it's worth noting that for most of the disciplines you mention, the actual work takes place on paper too. A mathematician, physicist or engineer will spend most of his working life scribbling on paper, so it makes a lot of sense to interview that way. There are plenty of other fields that don't work quite that way. You wouldn't interview a baseball player by asking him to describe hitting a curve ball on paper, or a nurse by asking him to draw stiches on a piece of paper. Every field has its own medium of expression. For many fields, that's paper. For programming, it's a text editor.

ubernostrum 16y ago

If I ask a physicist to sketch out a solution to a problem, I'll be willing to accept that they may need to look up some constants or formulas along the way, because knowing how to attack the problem and memorizing a bunch of numbers are two very different things; the latter is useful from time to time, but it's the former that I care about if I'm interviewing you. Why, then, do so many interview processes assume that the ability to, essentially, vomit rote-memorized bits of syntax, argument orders, etc. onto a whiteboard is so important that any "real programmer" should be able to do it on command?

mfukar 16y ago
Perfect analogy right there. See Tim Bray doesn't know operator precedence rules. It's perfectly possible to live and work and thrive without memorizing everything. This is what being an engineer is all about. Yet the FUD that goes into interview & recruitment processes (as well as other aspects of a programmer's work, but that's a longer story) is astonishing.

sliverstorm 16y ago

I would expect any programmer would be able to write a program on paper. I wouldn't expect it to be perfect or even compilable, just the same as a widget or schematic. Physicists and mathematicians have an advantage in producing 'perfect' things on paper, because they 'solve' where the other examples you gave 'develop'. They work in the other direction; the mathematical pursuits analyze systems whereas you have asked the other pursuits to create systems, which is much more difficult on a piece of paper. Now, if you had the designers working forwards- analyzing code or schematics or widgets- then I would expect an accurate answer (with a little fuzz for basic mistakes, same as I'd give a mathematician slack for accidentally dropping a minus sign)