Re: interview question on primes

Tim Little <tim@xxxxxxxxxxxxxxxxxxxxxxxxxx> writes:

If it were just a general test of some minimum ability to solve toy
problems, maybe.

It probably was, *even* for hiring a software engineer. Hopefully, it
was asked over the phone (to be answered via email or in spoken
pseudocode) rather than in-person, but better late than never.

It's wise to ask these kinds of problems for software hires at all
levels. More than one self-proclaimed "systems architect" with 20
years of experience on a picture-perfect resume has been weeded out by
the infamous FizzBuzz problem.

Depending on the level, the question might be prefaced with "I can see
you're very experienced, but it's policy around here to ask all job
candidates to solve a little toy problem using actual code, so..." If
a candidate refuses to solve a toy problem on the grounds that it's
beneath him or her, that's probably a bad sign. (If nothing else,
what organization needs another pompous jackass around, qualified or
not?)

Also, you'd hardly let a candidate finish writing all the code or even
care very much if it was correct, in my opinion. Overanalyzing the
answer is a bad idea: you'll just weed out potentially qualified
people.

For example, I think if you were hiring for a junior position and the
candidate wrote:

int isPrime(int p)
{
for (q = 1; q <= p; ++q) {
if (p mod q)
return 1;

within 30 seconds or so, you should probably stop them with a "pass".
Sure, it's full of mistakes. (If it's supposed to be C, there are
already two reasons it won't compile. There are at least three or
four logic errors, depending on how you count. Not even the most
basic optimizations have been performed, like stopping at sqrt(p).)

But, that's not particularly relevant. The candidate has already
demonstrated he or she knows at least one language well enough to
write cogent (if not correct) code and that he or she can analyze a
problem and start developing a sensible and general software solution
that shows some promise, and so they've passed the toy problem test.

Contrast this with a candidate who struggles for five minutes to come
up with:

def isPrime:
div2 = false
if p == 2:
div2 = true
div3 = false
if p = 6:
div2 = true
if div4:
div2 = true
div3 = false

Notice the immense gulf between the broken but promising first answer
and the completely hopeless second answer.

But as part of hiring a *software engineer*, employing someone who
demonstrates that they will not even ask a simple question before
designing their solution seems like a good way to guarantee project
failure in the future. Clarifying specifications with minimum fuss is
an absolutely necessary skill for that type of position!

That's fine, so far as that goes, but unfortunately expecting
candidates to read your mind can lead to early disqualification of
promising people. Many candidates (some of whom have hired more
programmers than anyone else in the room) will have different
expectations about the purpose of such a problem. If they see it as a
toy problem for quick screening, they may just jump right in, seeing
further questions as a waste of everyone's time.

If you want to see whether or not a potential hire has the ability to
ask questions about design requirements in a real-world situation,
don't infer it from the answers to toy programming questions. Ask
something more appropriate: "Suppose you were tasking with developing
a system to solve INSERT REAL WORLD PROBLEM HERE. How would you get
started?"

--
Kevin Buhr <buhr+un@xxxxxxxxxxx>
.

Loading