

Why I don't do coding tests - mparramon
http://www.developingandstuff.com/2015/05/why-i-dont-do-coding-tests.html

======
nanolith
The point of these tests is not to see who remembers their CS. The point of
these tests is to have an opportunity to see how candidates go through the
process of solving problems by approaching a problem that is well-understood
by the interviewer. Good interviewers pair with the candidate and help to
coach him/her towards a solution. This is a carefully crafted simulation of
two people working together in which certain variables can be controlled. It's
also time-limited because most interviewers have to go through dozens of
candidates to find someone who is a good fit for a particular team and
culture. It's economically infeasible to hire a bunch of people on a per-trial
basis. It's also hurtful to bring someone in for a few days, and then tell
them that they aren't working out.

Normally, when I heard this whole "I don't do coding tests" attitude, it comes
from a candidate who thinks that he/she is so amazing that the rules don't
apply. If such candidates flounce out of my tech screening because I dared to
give them a problem, then my tech screening has worked. In my experience, most
good engineers have tempered their egos with a dose of humility. They have hit
the wall of their abilities, and they understand that they aren't nearly as
amazing as they thought they were when they were younger. They are more
careful, and they are open minded. I won't dismiss a candidate for lacking
humility if I believe that he or she can grow, but if given the choice between
a good candidate with humility and a stellar candidate who is too good for a
test, I'll pick the good candidate every day. I'll let that stellar candidate
be someone else's management nightmare.

~~~
yetihehe
> The point of these tests is not to see who remembers their CS.

The point of these tests is exactly to see who knows how to program. I've seen
too many candidates who couldn't program, which I understand as finding code
which solves a stated problem. FizzBuzz is only used as a first pass filter.
After they solve it and are deemed normal enough to work, they are hired for
limited time to really see if they are worth working with.

If candidates can't solve fizzbuzz with a language they're most comfortable
with (yep, we don't require you know any of our technology), they won't solve
other problems they will be given. All my current coworkers can solve those
kinds of tests in reasonable time without any help, even if it's in a language
they don't know, I've also solved tests prepared by them.

~~~
nanolith
Being able to reason about a problem and then work towards a solution in code
is a more general skill than just programming or CS. I'm assuming that here,
"FizzBuzz" is more of an allegorical example than a literal test question, as
it would be rather useless in a test. I'd be more likely to ask someone to
write and then optimize an algorithm or implement a simple data structure, and
then build on this example with additional constraints or requirements. That
has merit. A pure coding test is no better than a typing test. Without the
problem, it's a meaningless exercise.

~~~
yetihehe
You would be surprised how many people which call themselves programmers can't
even solve fizzbuzz. This is good test to weed out really bad candidates. As
I've said, it's good firstpass filter, not a good hiring test.

------
fsk
My rule is 15-30 mins max for a pre-interview coding test.

For an onsite interview, I'll also do some with the interview.

------
spacemanmatt
Seems like good stuff to me.

