6 ms·

For me, this applies equally to programming competitions and white boarding algorithms in interviews.

by abetusk 10y ago

barrkel 10y ago
I've seen a correlation in working mode between pairing on a competition-style programming problem (to evaluate a job candidate) and pairing in real work. I'm not looking for leaps of insight though (I explain the insight required), and we're both in front of the IDE and can search the web to clarify simple questions. It's more communicating a problem and the outline of a solution, and seeing if someone is able to understand what you say and is fluent in turning ideas into code in their chosen language. I personally despise gotcha questions that rely on you either having seen the problem before, or getting lucky enough to spot the insight in a pressure situation.
gautamdivgi 10y ago
I think some folks overdo the white boarding. But I believe it is needed - may be one or two problems on the whiteboard with the rest of the interview focusing on design & software engineering (metrics, resiliency, etc.). I've seen folks who have a lot of coding skill on their resume fumble simple white board problems. I have fumbled simple white board problems when I have also interviewed (It was for a s/w engg position but I had spent the past several years in architecture and away from any real code - so it was expected). The point is white boarding is ok if you have a well defined problem solvable in 45 mins and if it is just geared to assess your familiarity with code. I don't think its a reasonable expectation to come up with new approximation algorithms for NP-complete problems and solve+prove them on a white board in 45 mins.
- onion2k 10y ago
  I've seen folks who have a lot of coding skill on their resume fumble simple white board problems. Solving a coding problem on a whiteboard tests your ability to solve coding problems on a whiteboard. That's a bias. It makes people who get nervous standing up and being the centre of attention less likely to pass the test. If coding on a whiteboard is a part of the job then fair enough, but if it isn't then you're introducing something to the interview that filters people out based on something other than their ability to do the job - and that means you're not necessarily recruiting the best person. I believe that's a good reason not to use whiteboard tests very often.
  - skybrian 10y ago
    Finding a whiteboard and brainstorming about how to solve a problem is absolutely part of the job. Unfortunately it's hard to find problems that can be explained to anyone with a reasonable programming background and solved in 30 minutes. So anything you do under those constraints is going to be artificial.
    - JoeAltmaier 10y ago
      And if you overthink it (how can you not? no idea what they're looking for) you appear to clutch or ask too many questions. No shared context means a very artificial exchange.
    - varjag 10y ago
      > Finding a whiteboard and brainstorming about how to solve a problem is absolutely part of the job. But let's face it, this skill is trivial to an otherwise intelligent person, and it's not the reason whiteboard coding is done at the interviews. It is to assess one's problem solving or even specific coding skills. Unfortunately, in a nearly QM way, observation here affects the outcome. I did partake in CS competitions at regional level and to me they are less stressful than whiteboard tests. There you just have a console or a sheet of paper and a few hours to hash it over. No 3 pairs of eyes staring at your back. Guess it's the same for many others: the thing that turns reading a figurative newspaper chess column into chessboxing tournament. One might be good at chess and OK in boxing, but not necessarily at the same time. (and no, unfortunately I don't see a good way to fix this)
  - nordsieck 10y ago
    While that is in some ways fair, interviews inherently involve being the center of attention; people who do poorly at them because of nervousness will always have problems regardless of the format. While it's true[0] that work samples are substantially better at evaluating candidates than informal interviews, they have their own downsides. For example, I have heard many people balk at multi-hour homework assignments as part of the interview process as too much of a time commitment to one company. In the end, any screening technique will be flawed. That doesn't mean that we shouldn't use them. [0] http://bobsutton.typepad.com/my_weblog/2009/10/selecting-talent-the-upshot-from-85-years-of-research.html http://bobsutton.typepad.com/my_weblog/2009/10/selecting-tal...
kamaal 10y ago
This explains why: From the article: From Terence Tao: professional mathematics is may be quite different from the reality. In elementary school I had the vague idea that professional mathematicians spent their time computing digits of pi, for instance, or perhaps devising and then solving Math Olympiad style problems. In real life its the same. You don't cook up interview coding problems and solve them whole day. You have real world work to do and often that requires a degree of productivity, not knowledge. This is even more so true given how cheap and easy access to knowledge has become because of the web. From GH Hardy: it is useless to ask a youth of twenty-two to perform original research under examination conditions, the examination necessarily degenerates into a kind of game, and instruction for it into initiation into a series of stunts and tricks. Notice how closely this matches with interviews which mandate people to demonstrate expertise in trivia. Or quickly state the Big-Oh complexity of some sorting algorithm. From Andrew Wiles: Real mathematical theorems will require the same stamina whether you measure the effort in months or in years [...] Almost any real measurement of algorithm expertise is in seeing how good a person in coming up with a new algorithm for a novel problems. What exactly is your knowledge of 100 sorting algorithms worth, when it can be searched for in a google search which takes a few milliseconds. Interview Algorithm guru's to me are no better than those smart elecs who used to show up in school having memorized multiplication tables and then demonstrate that as some kind of mathematical ability.
rafaquintanilha 10y ago
For such things like coding an optimal algorithm from scratch this might be true. But there are interview questions which have a more practical appealing, and this definitely does not apply to math Olympiads.
kafkaesq 10y ago
Love / hatred of the whiteboard process being of course a perennial topic here, there is one major distinction between Math/CS olympiads and the typical industry whiteboarding session: with the Math/CS olympiads, you can count on a reasonable degree of professionalism (in terms of forethought and judgement, and overall solidness of execution) -- not to mention basic common sense -- behind both the curation of the actual problem sets, and in the design of the test environments. These people know what they're doing, and their process is mature and generally well accepted. And the actual problem solving environment is designed for maximum efficiency and fairness. In the tech industry, however -- here and there you'll find companies that know what they're doing: they actually put a lot of though into picking reasonable problems to solve, and present the candidates with reasonable conditions for doing so. They're clear in stating both the problem and what they expect; and the interviewers are reasonably personable, and have great communication skills. But quite often, it's a total shit show: problems are often poorly stated (and sometimes ridiculously complex); combined, importantly, with a poor or completely absent statement of what is really expected from the candidate (As in -- do they want a perfect working solution, on running code? Or does it suffice to just outline the general idea, perhaps with pseudocode? Quite often this is never stated up front); along with gratuitously taxing and sometimes downright annoying conditions in which to tackle this allegedly crucially important problem you're asked to solve (among my favorites being: whiteboards with barely usable markers / erasers; or their electronic equivalent -- Google Docs, or other ridiculously unusable coding "platforms"; voice-only sessions of nearly any kind, but especially those where the interviewer clearly has limited communication skills for one reason or another; and then of course sessions where the interviewer doesn't know the language you're coding in very well, and you have to constantly pause to explain the basic facets of said language, along with the solution itself).

For me, this applies equally to programming competitions and white boarding algorithms in interviews.

by abetusk 10y ago

For me, this applies equally to programming competitions and white boarding algorithms in interviews.

I've seen a correlation in working mode between pairing on a competition-style programming problem (to evaluate a job candidate) and pairing in real work. I'm not looking for leaps of insight though (I explain the insight required), and we're both in front of the IDE and can search the web to clarify simple questions. It's more communicating a problem and the outline of a solution, and seeing if someone is able to understand what you say and is fluent in turning ideas into code in their chosen language. I personally despise gotcha questions that rely on you either having seen the problem before, or getting lucky enough to spot the insight in a pressure situation.

gautamdivgi 10y ago

I think some folks overdo the white boarding. But I believe it is needed - may be one or two problems on the whiteboard with the rest of the interview focusing on design & software engineering (metrics, resiliency, etc.). I've seen folks who have a lot of coding skill on their resume fumble simple white board problems. I have fumbled simple white board problems when I have also interviewed (It was for a s/w engg position but I had spent the past several years in architecture and away from any real code - so it was expected). The point is white boarding is ok if you have a well defined problem solvable in 45 mins and if it is just geared to assess your familiarity with code. I don't think its a reasonable expectation to come up with new approximation algorithms for NP-complete problems and solve+prove them on a white board in 45 mins.

onion2k 10y ago
I've seen folks who have a lot of coding skill on their resume fumble simple white board problems. Solving a coding problem on a whiteboard tests your ability to solve coding problems on a whiteboard. That's a bias. It makes people who get nervous standing up and being the centre of attention less likely to pass the test. If coding on a whiteboard is a part of the job then fair enough, but if it isn't then you're introducing something to the interview that filters people out based on something other than their ability to do the job - and that means you're not necessarily recruiting the best person. I believe that's a good reason not to use whiteboard tests very often.
- skybrian 10y ago
  Finding a whiteboard and brainstorming about how to solve a problem is absolutely part of the job. Unfortunately it's hard to find problems that can be explained to anyone with a reasonable programming background and solved in 30 minutes. So anything you do under those constraints is going to be artificial.
  - JoeAltmaier 10y ago
    And if you overthink it (how can you not? no idea what they're looking for) you appear to clutch or ask too many questions. No shared context means a very artificial exchange.
  - varjag 10y ago
    > Finding a whiteboard and brainstorming about how to solve a problem is absolutely part of the job. But let's face it, this skill is trivial to an otherwise intelligent person, and it's not the reason whiteboard coding is done at the interviews. It is to assess one's problem solving or even specific coding skills. Unfortunately, in a nearly QM way, observation here affects the outcome. I did partake in CS competitions at regional level and to me they are less stressful than whiteboard tests. There you just have a console or a sheet of paper and a few hours to hash it over. No 3 pairs of eyes staring at your back. Guess it's the same for many others: the thing that turns reading a figurative newspaper chess column into chessboxing tournament. One might be good at chess and OK in boxing, but not necessarily at the same time. (and no, unfortunately I don't see a good way to fix this)
- nordsieck 10y ago
  While that is in some ways fair, interviews inherently involve being the center of attention; people who do poorly at them because of nervousness will always have problems regardless of the format. While it's true[0] that work samples are substantially better at evaluating candidates than informal interviews, they have their own downsides. For example, I have heard many people balk at multi-hour homework assignments as part of the interview process as too much of a time commitment to one company. In the end, any screening technique will be flawed. That doesn't mean that we shouldn't use them. [0] http://bobsutton.typepad.com/my_weblog/2009/10/selecting-talent-the-upshot-from-85-years-of-research.html http://bobsutton.typepad.com/my_weblog/2009/10/selecting-tal...

kamaal 10y ago

This explains why: From the article: From Terence Tao: professional mathematics is may be quite different from the reality. In elementary school I had the vague idea that professional mathematicians spent their time computing digits of pi, for instance, or perhaps devising and then solving Math Olympiad style problems. In real life its the same. You don't cook up interview coding problems and solve them whole day. You have real world work to do and often that requires a degree of productivity, not knowledge. This is even more so true given how cheap and easy access to knowledge has become because of the web. From GH Hardy: it is useless to ask a youth of twenty-two to perform original research under examination conditions, the examination necessarily degenerates into a kind of game, and instruction for it into initiation into a series of stunts and tricks. Notice how closely this matches with interviews which mandate people to demonstrate expertise in trivia. Or quickly state the Big-Oh complexity of some sorting algorithm. From Andrew Wiles: Real mathematical theorems will require the same stamina whether you measure the effort in months or in years [...] Almost any real measurement of algorithm expertise is in seeing how good a person in coming up with a new algorithm for a novel problems. What exactly is your knowledge of 100 sorting algorithms worth, when it can be searched for in a google search which takes a few milliseconds. Interview Algorithm guru's to me are no better than those smart elecs who used to show up in school having memorized multiplication tables and then demonstrate that as some kind of mathematical ability.

rafaquintanilha 10y ago

For such things like coding an optimal algorithm from scratch this might be true. But there are interview questions which have a more practical appealing, and this definitely does not apply to math Olympiads.

kafkaesq 10y ago

Love / hatred of the whiteboard process being of course a perennial topic here, there is one major distinction between Math/CS olympiads and the typical industry whiteboarding session: with the Math/CS olympiads, you can count on a reasonable degree of professionalism (in terms of forethought and judgement, and overall solidness of execution) -- not to mention basic common sense -- behind both the curation of the actual problem sets, and in the design of the test environments. These people know what they're doing, and their process is mature and generally well accepted. And the actual problem solving environment is designed for maximum efficiency and fairness. In the tech industry, however -- here and there you'll find companies that know what they're doing: they actually put a lot of though into picking reasonable problems to solve, and present the candidates with reasonable conditions for doing so. They're clear in stating both the problem and what they expect; and the interviewers are reasonably personable, and have great communication skills. But quite often, it's a total shit show: problems are often poorly stated (and sometimes ridiculously complex); combined, importantly, with a poor or completely absent statement of what is really expected from the candidate (As in -- do they want a perfect working solution, on running code? Or does it suffice to just outline the general idea, perhaps with pseudocode? Quite often this is never stated up front); along with gratuitously taxing and sometimes downright annoying conditions in which to tackle this allegedly crucially important problem you're asked to solve (among my favorites being: whiteboards with barely usable markers / erasers; or their electronic equivalent -- Google Docs, or other ridiculously unusable coding "platforms"; voice-only sessions of nearly any kind, but especially those where the interviewer clearly has limited communication skills for one reason or another; and then of course sessions where the interviewer doesn't know the language you're coding in very well, and you have to constantly pause to explain the basic facets of said language, along with the solution itself).