
Will the real programmers please stand up? - coffeemug
http://www.rethinkdb.com/blog/2010/06/will-the-real-programmers-please-stand-up/
======
jwr
One thing to consider is that there are many people (myself included) who are
_really_ bad at solving problems under stress, especially next to a
whiteboard.

Note that this does not necessarily imply these people are useless in real-
life tasks. It just means they are bad at passing exams.

This is why I would never get through Google's interviewing process. Some
companies (like Google) just accept the fact they will throw away some
possibly good candidates because of the nature of the selection process — and
that's fine, as long as you realize that.

Note that I'm talking about solving problems involving abstract thinking next
to a whiteboard here. The part about people not knowing the difference between
cooperative and preemptive multitasking is something I fully agree with —
people who do not know that should not seek a job at a company that deals with
anything low-level.

~~~
coffeemug
We fully recognize that we have a high false negative rate. We work every day
to get it lower, but unfortunately there is only so much we can do without
compromising the integrity of the process.

~~~
Andys
I have a question for you. I'm comfortable answering those coding questions,
but not on a whiteboard.

Would you be OK if instead of writing on the white board, I whipped out my
laptop and coded the answer there in front of you? If the answer is no, I
would happily walk out of the interview knowing I would not be a good fit for
the company.

~~~
heresy
I have a similar problem with transcribing my thought processes into little
diagrams that other people can follow, yet it's the easiest thing in the world
to explore the ideas with code.

Not sure why that is.

Are you also self-taught, by any chance?

~~~
Andys
Yes!

------
jeb
I can reverse a linked list, but here's what happened on reading this article.

After seeing the problem, I fired up textmate and started writing C pseudo-
code to do it. I started off with

    
    
        first_item = l.first();
        next_item = first_item.next();
    

Then I started writing the loop, and somewhere in there, I got confused. And
then a wave of panic came over me - shit, maybe you can't do this. I shook off
the thought, deleted my code, and restarted. At some point, I realised that I
was always pointing at the first element. My stomach sank and I had this
dreadful feeling - okay, you kind of suck as a programmer. Then my mind went
blank, and I wanted to switch over and see if the answer was there.

And that's with NO PRESSURE AT ALL. With someone watching me, I'd probably not
even have been able to get the loop right.

I have never written such a loop, but it's basic stuff, I can do this anytime.
But just a little bit of pressure made me royally fuck up.

Programming is thinking - you need to juggle shit in your head - if at the
same time you are paying attention to what a HIRER is doing or saying, it will
totally smash this ability to do shit in your head.

Your programming exercise probably selects for calm people, not for good
programmers.

~~~
grogers
Staying calm while thinking through a solution is a pretty useful trait to be
hiring for - not just for programmers either. What happens when the shit hits
the fan and everything is core dumping left and right - do you really want
someone whose head is going to explode? Or do you want someone who can stay
calm and diagnose the problem and/or get to a workaround quickly.

~~~
prodigal_erik
This. Every so often something blows up at 2 am and we have to troubleshoot an
unknown problem while our employer loses $3k/hour and everyone in charge wants
to know WTF. Thankfully it's rare, but I don't want us to have to support your
code if you aren't up to offering useful help at that moment.

------
noelwelsh
In my mind condition variables are stored under "crap I don't need to know
because we have better abstractions". I can understand why RethinkDB will be
messing around with semaphores (or monitors aka condition variables) but for
most programs there are far better ways to organise concurrency. Java
recognises this -- experience showed the synchronized (monitor) approach to
concurrency to be too unwieldy and it was superseded fairly quickly by
java.util.concurrent and friends. Way back in 2000 we were using Doug Lea's
concurrency library, which formed the basis for java.util.concurrent. I
certainly _could_ use semaphores but it would certainly take me some time to
adjust my thinking to that primitive model.

~~~
JoeAltmaier
That's an applications-programmer answer. But who did you think wrote
java.util.concurrent? The article is by someone who needs systems programmers,
who do algorithmic work, not applications programmers, who put together large
state-diagram code.

~~~
GFischer
Hah, I suspected as much from the article's title.

Systems Programmers = "real" programmers (for the article's writers)

Application Programmers (or even worse, Information Systems guys like myself)
are not "real" programmers to them - and to be honest, I don't believe myself
a "real" programmer sometimes as well.

------
PieSquared
Huh, I think it's time to learn something.

I can write C code to reverse a linked list, or discuss the asymptotic
efficiency of a bunch of data structures in my sleep... but I clearly don't
have enough experience with threading if I had to google what a "condition
variable" was, or had to make sure my intuitive notions about cooperative and
preemptive multitasking were right.

Always nice to be reminded that you don't actually know anything.

~~~
pohl
I have a tangential question: is there a name for the kind of diagram one sees
on this wikipedia page involving rooms & doors? I've never seen it before.

<http://en.wikipedia.org/wiki/Condition_variable>

~~~
ygd
It seems they're all some type of "monitor".

------
adbge
> the interview process is something we won’t compromise on.

Sounds like you're caught up in a big circlejerk, to be honest. Your interview
process is terrible and that's why you aren't finding any employees. You won't
compromise on your process? What? You should be less worried about your
process and more worried about finding quality employees (hint: your process
isn't working).

Asking people to write a program over the phone isn't going to work. Have you
ever written a program while on the phone? I haven't and I'm not going to.
It's so far out of my comfort level that I'd probably end up looking like a
moron.

Your test sounds like it's too much about what a person knows and not enough
about how a person performs. You'd be much better off looking at a persons
resume and, if you're satisfied with that, just talking to the person instead
of worrying about whether or not they can reverse a linked list in C off the
top of their head. If you want them to write you some sample code, let them do
it at their leisure instead of with you breathing down their neck over the
phone.

Frankly, reading about your interview approach just kind of pisses me off.
What's more likely: all the candidates suck or your interview process sucks?

~~~
starkfist
In the OP's defense, this is how Google interviews, and they've done ok.

~~~
chc
Google can afford to be ridiculous. Practically everybody would like to work
for Google, so they can afford to have a high false negative rate — even if
they reject 99% of good candidates, they can probably still fill their
staffing needs. RandomCompanySoft, on the other hand, might only get five good
candidates for a given position — so if _they_ only recognize one out of every
10 good programmers, they can't find anybody with any skill.

~~~
sghael
If you are a startup, you can't afford to be NOT be "ridiculous"

Possibly nothing is worse for a new tech venture than a bad hire. I've lived
through a few at various startups. It's horrible. It's the worst kind of death
because its often slow and painful and you're bleeding capital.

Also realize that a bad/incompetent programmer is a NET NEGATIVE.... not just
net 0!

(obviously being 'ridiculous' is subjective, and highly dependent on the roles
and responsibilities of the job).

Google on the other hand actually could afford to be less ridiculous.. they
just choose not to.

~~~
chc
This isn't about rejecting bad programmers — it's about rejecting good ones.
If you can't afford a bad hire, that means you should spend more time and care
trying to determine accurately whether somebody is good rather than relying on
a rough heuristic with a strong negative bias — especially if you find that
your heuristic is rejecting everybody.

~~~
sghael
you make a valid point, and i completely agree. It's about more efficiently
honing in on the best candidates. And the trick is to do that early in the
process, especially when the hiring process is typically front-loaded with
mostly crap candidates.

I've thought A LOT about this problem... so much so that my web-startup is
attempting to solve one aspect of this problem (see my HN profile for the
link).

------
dkarl
Similar experience here. A shocking number of people simply can't code. I
started giving people a "simple" whiteboard programming question: write code,
in any real language (i.e., not pseudocode,) to print out the permutations of
a string, and give me running commentary on what they were doing. The idea
was, by watching them complete a simple coding task that would require a
couple of iterations of design and a little bit of "debugging" at the end, I
could get a feel for how they attack problems.

In about a dozen interviews, nobody did it. The problem was way too hard. By
the end of the cycle of interviews I had started giving _lots_ of guidance to
the candidates: asking them about permutations that their solutions would
miss, asking them how many permutations their solution would print, asking how
many permutations a string of length 2, 3, or 4 might have, and when they got
stuck, telling them what they had right and when they went wrong. Nothing
really helped, though.

Perhaps it's not really so shocking. Maybe's it's just too hard in a one-hour
interview. I thought it would be easy, but then again, I've never had to write
code in an interview. What _is_ shocking is how poorly people floundered. I'm
pretty sure most of them couldn't have even reversed a singly linked list. In
the end, I gave the best marks to the candidates who:

1\. Asked whether it was okay for duplicates to appear in the output.

2\. Wrote up a roughly correct (syntax errors and off-by-one errors aside)
implementation of their first idea for solving the problem and explained how
it worked.

3\. Understood when I pointed out permutations that their solutions would
miss.

4\. Were a good sport about being asked to solve the problem. (Actually,
nobody who failed this criteria did remotely well at the others, so it's
somewhat redundant. I mention it because I was surprised that people would get
crabby about being asked to write code in an interview.)

Three or four of the candidates, out of about a dozen, managed to meet all
four criteria. These were people who passed a phone screen! Even worse, some
of the candidates who failed one or more of the four criteria above apparently
shined in their other interviews, claiming to have been in charge of designing
and implementing significant systems.

~~~
lincolnq
Solving this problem (permutations) in Haskell helped me understand the list
monad, which in turn helped me think about nested-loop algorithms in general
and how they should be structured in code. So thanks. It was a fun exercise
and I learned something.

I am pretty sure I nailed it. But I have been asked questions like this at
interviews and screwed them up (e.g., at Facebook, which asked me something
very similar and I failed to get it right). The notable thing was that at
home, sitting at my desk, I wasn't afraid of sitting silently and figuring it
out. It took me about 3 minutes of silence for my brain to organize itself
enough to solve the problem. I'm not willing to spend 3 minutes in silence at
an interview, and yet if I just jumped in I would go down a lot of wrong
alleys, become confused, and screw it up.

Is there room at an interview for someone to silently figure something out,
without someone waiting on you, asking to "show me your thought process"?

~~~
mechanical_fish
_Is there room at an interview for someone to silently figure something
out...?_

Frankly? No.

Not for three minutes, anyway.

That's why either (a) the permutations question is too hard, or (b) the
interviewer cannot necessarily expect anyone to get the right answer, but
should instead judge incidental aspects of the process. (This is what dkarl
seems to be doing, and that's fine.)

If you are _asked_ a hard question, I think it's better to steer on the side
of "going down a lot of wrong alleys, out loud". Just be honest about it. If
you find yourself lost, go ahead and say "oops, thinking out loud during
interviews is not my strong suit and now I'm pretty sure I'm lost". Find your
own bugs and laugh at them. Backtrack. Start over. Restate the problem. Sketch
a unit test that describes the answer that you can't quite derive yet. Define
a simpler problem that you _can_ solve out loud, and solve that first. And, of
course, always do the stupidest thing that could possibly work.

It occurs to me that the average student spends all kinds of time in school
studying how to solve problems quietly and completely at one's desk, and very
little time practicing the art of sketching half-baked solutions out loud
while waving one's hands. But you _can_ practice that.

~~~
aristus
"the art of sketching half-baked solutions out loud while waving one's hands"

You mean, teaching?

~~~
mechanical_fish
Precisely.

------
pmjordan
Over the last 2-3 years, I think RethinkDB has literally been the only company
that has made me think "wow, I think I'd really enjoy working there". (I'm
self-employed) I find it baffling they can't find enough people. Are the cool
kids really only doing web apps these days? What about all the army of
Objective-C programmers that Apple has been assembling?

~~~
yummyfajitas
A good chunk of the cool kids probably want to make more than $125k/year.

<http://rethinkdb.com/jobs/>

~~~
Alex63
I haven't worked as a "programmer" or "software engineer" for a few years, but
looking at GlassDoor.com for evidence, $125K seems like a pretty good salary.
Is that an unrealistic salary for a programmer today? Are you referring to the
greater rewards of being an entrepeneur/founder?

~~~
yummyfajitas
I'm referring to wages, not rewards of being a founder. As for glassdoor.com,
I don't think it's very accurate. I'm guessing "database engineer" == DBA.

$125k/year is what you would give to a decent coder with 3 years of
experience. At Rethink, it looks like they want to pay him $80k/year. Some
people will take the job just because the company and problem domain looks
fun, but not everyone will.

~~~
mynameishere
_$125k/year is what you would give to a decent coder with 3 years of
experience._

You're living in a dream world.

~~~
yummyfajitas
I'm just working for a company trying to hire. Competent people are hard to
find (as rethinkdb noted, 95% of applicants == fail), and when you find them,
you pay for them. They are worth it.

------
orp
When I interview programmers I start off with this question:

Write a function in C (on the whiteboard) that takes an array of integers and
returns its sum.

I explicitly explain to candidates that this is a warm-up question to start
the interview, and that I'm looking for the textbook solution, no tricks.

The advantages are: 1\. It takes a reasonable candidate 3 minutes to write
down the answer. 2\. Answering a question correctly gives them confidence,
always important in an interview. 3\. It provides a good basis for a little
advanced discussion (overflow, speed, error handling, supporting infinitely
large numbers, etc).

Amazingly enough, some candidates have actually failed this...

~~~
ivenkys
This is the right approach.

If an interview is like dating/flirting then you don't start by asking the
prospective partner about their life philosophy you start by talking about the
weather.

"Amazingly enough, some candidates have actually failed this..." - that is
just sad.

------
starkfist
Nobody in America has to do this kind of work anymore. Some do it by choice
but usually work on something they are really into, like Pro-Tools or iPhone
software, or something where you make a lot more money, like Wall Street (or
iPhone software). I have not had to do anything remotely resembling reversing
a linked list in C since 1994. Since then, the further I've gotten away from C
and algorithms, the more I've gotten paid...

Your best bet is to recruit in Russia/Eastern Europe/India/China.

Edit: before I get downvoted into oblivion, I didn't mean this disparagingly,
I am just being matter of fact. It will be easier to hire people from those
countries. Most Americans who do this work already have a job. Most Americans
looking for a job, don't want to do this, or don't know how. I have worked
with guys from Croatia who helped write some database driver code for me and
were excellent.

~~~
amalcon
Here's the thing: you're not being asked to reverse a linked list because they
expect you to implement one. 99% of the time, you'll just use a library (the
other 1%, you're writing the library). You're being asked to reverse a linked
list because it's bloody easy if you understand the fundamentals (what a
linked-list is, how a loop works).

~~~
starkfist
I realize that but wishing that people applying for jobs actually knew what
they are doing unfortunately is not going to help much. You can make a whole
career without understanding linked lists. If you need people to work on
database internals you either have to hire from the areas I mentioned or
figure out how to poach people already doing this kind of work. The pool of
applicants who just send in their resume generally does not contain the
programmers you actually want to hire.

~~~
amalcon
To someone who does know about this stuff, though, it seems completely
fundamental. It's a total mystery (to me at least) how a half-decent
programmer could avoid getting curious enough to figure out what a linked list
is.

There's at least one other place you can get competent people who know about
the fundamentals: academia. This is why Google tries so hard to lure people
from academia.

~~~
starkfist
I wouldn't bet on that. It really depends on what they are doing in academia.
You can get through some programs without doing much programming at all. They
even mention in the post that a PhD failed the phone screen.

------
ydant
C and C++ seem to be the languages of choice lately for the interview
complaints. I wonder if that's indicative of the language itself or of the
number of people who actually program in those languages.

Of the questions / problems expressed in the article, I think I have a decent
grasp of most of them, and I don't program in C or language with similar
ideas. I did learn with C (and then expand that knowledge to C++), but that's
been a long time ago. To not be able to traverse a linked-list, though, that
baffles me. Simply shouldn't be appling for a job programming in C or C++ and
not understand linked lists.

~~~
habitue
If you have to traverse a linked list at any time to reverse it, you're doing
it wrong.

~~~
roel_v
How would you reverse a singly linked list without traversing it? (and without
knowing implementation details too I guess - doing pointer arithmetic and
storing the size somewhere else doesn't count).

~~~
mjw
I think he means: if you have to traverse it without building up a result (or
doing some in-place modification) as you go - then you're doing it wrong.

Obviously you gotta traverse the thing at least once.

~~~
ydant
If that's what he meant, his comment was pretty much useless.

Anyway, I misread "traverse" for "reverse", hence my incredulous comment.

Perhaps traverse means different things to the two of us.

------
timwiseman
When I have done interviews, I too was truly surprised by how many
"programmers" could not program even simple things.

But I do think you should realize what type of programmer you are looking for.
Most of their questions mentioned assume a knowledge of C. I have not used C
since high school, even in college it was optional for CS majors, and a lot of
programmers majored in things other than CS (I started in math, I know another
truly good programmer that started in nuclear physics).

This is great if you are looking for C programmers, but I would not consider
them basic things any developer should know.

------
jimbokun
These are the kind of questions where I might draw a blank if asked out of the
blue, but I make sure to bone up on before going into any kind of technical
interview.

------
hernan7
Making the candidates reverse a linked list over the phone? Either the job
market is worse than I thought or somebody is power-tripping something awful.

~~~
coffeemug
<http://typewith.me/>

~~~
tkahn6
When you ask someone to reverse a linked list, do you mean 'in place'?

~~~
weaksauce
The in place way is O(N) whereas I cannot think of a way to do it for less
than O(N^2) building up the list the other way.

~~~
chc
They're both O(N). Pseudocode for the other way:

    
    
        1. copy head of list consed with nil
        2. copy next item consed with previous
        3. goto 2 while next item is not nil
    

That's N*(cost of a copy and a cons). Granted, it's not as fast in absolute
terms, but the slowdown is a constant factor. You're certainly not doing N
operations on each item.

------
Tycho
Maybe you're doing things the wrong way round? Is there no way you can have
potential candidates complete a programming task/test and THEN, if they're
successful, send you their CVs? Whether using Codility or something you devise
yourselves.

It bugs me that no matter how much I practice programming and know my stuff,
my application might get glossed over in favour of some non-programming douche
with an immaculate CV.

~~~
cellularmitosis
It seems it would be great to have the inverse of codility, where job seekers
take a bunch of coding tests, and then employers start sending them job offers
based on their scores.

it was only after completing their warm-up problem that I realized that wasn't
the case, and that in order to have access to any of the other programming
problems (ie, in order to get to the fun stuff), I'd first have to set about
finding an employer who has signed up with their service :(

------
alttab
This actually made me feel better about what I _do_ know.

But then again, my course work included a course in operating systems where
the main project was to write the multi-threading architecture, system call
infrastructure, virtual memory, and file system for a bootable x86 OS. I went
to Virginia Tech but the course's origins is Stanford.

Best class I ever took.

~~~
scott_s
You may be curious to know that's not a required course anymore. It's now a
senior level elective. The required junior level course is now Computer
Systems (<http://courses.cs.vt.edu/~cs3214/>), taught by the same professor. I
was a TA for it last spring and I'll probably TA it again in the fall.

Although now that I look over the listed courses, I don't see a senior level
OS class.

~~~
alttab
Interesting. I remember the course being very difficult. I wonder if it was
"too hard" so they made it optional. A mistake if you ask me, that class made
me a better programmer than any other undergraduate course.

Although, the only ones that would take it now would want to.

~~~
scott_s
I had a similar reaction when I first heard about it, but after TAing Computer
Systems, I think the replacement is still difficult. It's also perhaps more
relevant to more people. Very few people will ever work inside an OS kernel.
Many more people will have to code _against_ an OS kernel. Further, I find
that it codifies many concepts and techniques that I had to learn and develop
on my own in grad school.

Computer Systems still introduces many of the concepts that OS does, it's just
done from the perspective of user-land, not kernel-land.

------
alanh
EDIT: Has anyone else had OK experiences with on-the-spot programming as they
were interviewed? </edit>

I don’t get all the people saying that most people can’t code under the
pressure of an interview. What’s the big deal? It’s one function. I have
certainly been asked technical questions in interviews, including to write
code on a whiteboard, and it’s no big deal — I have missed a bracket or two,
or been slightly off, but if it’s 95% right that’s good enough for the
interviewer.

I’m not Mr. Cool, either. Finals, deadlines, and papers all really stressed me
out in school (mere months ago). I can just code alright and I understand the
tech.

I just don’t get it.

I also don’t understand what the alternative is: just take people at their
word they are great programmers?

~~~
cantastoria
_I also don’t understand what the alternative is: just take people at their
word they are great programmers?_

We've had great success giving candidates a week to design and implement a
small application from end to end. It really let's you see everything all at
once. Can they design? Good comments? Good data structure selection?

It's the best of all worlds. The candidate has time to really show off their
ability, you'll get a much more holistic view of their skills and it puts them
equal footing with the interviewer because they've had a lot time to think
about the problem. We found that whiteboard coding questions tend to favor
"geek jocks" that are really just good test takers.

~~~
alanh
Doesn’t a little app seem like a lot of unpaid work to ask of prospective
employees?

I’m not so sure about "geek jock" but I do happen to be a good test-taker. (I
assumed most nerds were, though.)

~~~
cantastoria
Actually we've tried giving them a choice. Most chose to do the assignment
rather have to go through a high pressure interview answering whiteboard
questions. We're not asking them to solve problems that could possibly be used
in any of our products so they don't feel taken advantage of and it's usually
something fairly simple (e.g. design a parking lot management system). All in
all they probably spend as much time writing the small sample app as they
would in the typical all-day interview loop.

------
logic
Interesting (to me) observation: I found I spent significantly more time on
the scaffolding for this problem to prove my answer correct, than on the
answer itself. (I'm one of those folks addicted to "FizzBuzz"-esque toy
problems.)

I probably spent five minutes at most working out a reasonable way to do this
in-place with a single pass, but spent 20-30 minutes reassuring myself that I
had it right for all cases.

These kinds of problems are always interesting to me: they have simple and
obvious (after some thinking) answers, but probably aren't something you've
touched in a significant amount of time, because nobody reinvents the wheel
like this day-to-day. They're very satisfying in a "back to basics" kind of
way.

------
pkrumins
Don't ask the candidates for silly resumes. Ask for their github repos and
blogs. I mean who cares what your education, background, and previous job
experience is? All of that is irrelevant. What matters is the code they have
written. I want to see the code. The best developers will have thriving github
repos and they'll be enthusiastic to write about what they are coding on their
blogs. The perfect job application form has to have just two fields `Github
URL: [.........]` and `Blog URL: [.........]`. Everything else is irrelevant.
That's how I am going to hire.

~~~
sghael
I generally agree that it matters more what you've actually done or created,
not what you say on a resume.

But specifically when it comes to asking for the Github url (or the like):
that assumes that the code they have worked on is open source. There are
plenty of good hires out there that may not have participated in open source
but still have plenty of code they've created. I think asking for a public
repo is too heavily weighted towards open-source wonks.

I'm content asking the candidate to point me to something they've created. I
work on webapps so presumably for the candidate that would be a public facing
website. And then i study it. And then I grill them hard on the details of
their implementation.

~~~
substack
This is a good point but at the same point not many employers have this
strategy so I suspect there is plenty of underemployment among people writing
open source given the level of skill. The hiring strategy that pkrumins
advocates seems pretty sensible for a business that is already deeply familiar
with the open source world.

------
16s
If I was asked this question and I could express the answer in C++, then I
would say list::reverse.

It seems (to me) that more important than this question is knowing when to use
one data structure over another (pros and cons) is more important than being
able to manipulate one specific data structure during an interview process.

------
angelbob
I used the linked-list question for years as well. I think our phone screen
was harder -- it probably only filtered out about 60%-75% of our applicants
rather than 95%.

It's a good one. I have an awesome follow-up to it that it sounds like your
interviewees would never get to anyway :-)

------
heatdeath

      void reverse_list(head) {
        struct node* current = head;
        struct node* last = NULL;
        struct node* next;
    
        while(current != NULL) {
          next = current->next;
          current->next = last;
          last = current;
          current = next;
        }
      }

------
adn37
That was funny to go pen & paper to do the reversal of the linked list, C
style, like in the old days.

(aka, Java coding is tasteless)

~~~
brown9-2
What does this mean? The article also states they ask other questions in which
the candidate can respond in any language of their choice.

The language isn't important here, it's knowing the algorithm and being able
to put your ideas into code.

You could ask the same exact question in Java and you should be able to get
the same answer from people.

~~~
substack
The language is absolutely important, since in haskell I could just:

    
    
        > reverse [1,2,3,4]
    

or if I couldn't use the Prelude (yikes!)

    
    
        reverse [x] = [x]
    
        reverse (x:xs) = reverse xs ++ [x]
    
        > reverse [1,2,3,4]
    

The problem is that linked list traversal is a solved problem. Why not throw a
novel and interesting problem at candidates? That way you could gain some
insight into how they go about solving problems instead of how good the
candidate is at memorizing other people's solutions that they could just as
easily look up in a search engine in a few minutes.

------
wangwei
Hello, RethinkDB. You get what you pay for. You don't expect to buy a diamond
for 10 bucks , do you?

------
amarc
yes, but only if you pay enough...

------
juicebox
You need to give a programmer a task, then let him get back to you in a day or
two. Give him something that you can't find a solution to on Google, but isn't
so hard that it couldn't be done in an hour or two.

Sitting there putting pressure on the programmer working is just a prick move.
If you gave the same test to a carpenter and asked him to build a bird house
and the outcome would decide whether he could pay rent this month, he would
cut his damn hand off. Guaranteed.

