Code over the phone

Two weeks of waiting for it have built it up pretty much. When the phone finally rang, for some reason it felt surprising. No more waiting? Interview begins?

“I would like you to dictate me some code” said the engineer. He was describing tasks and asking me to write code that solves them. They were not daunting; could be easily decomposed into basic operations. Recruiters surely understand that people get nervous when being interviewed. The fact that one is being interviewed, not “just” asked to write some code, makes them make stupid mistakes all the time. Interviewers try to give simple tasks to people. It’s also interesting that the questions were not strictly theoretical, but more like “how would you…” followed by something to find out or to calculate.

The questions were pretty simple, but somehow not easy to answer and easy to answer wrong. It’s all about stupid mistakes, of course. Have you ever made any clever mistake, anyway?

The questions concentrated on the technologies that I declared to have experience with. In this case, they were SQL, Python and shell. The SQL part went well. The Python part didn’t go so well; you would be surprised how many things of your “first language” you need to check before you code. Was it, say, foo.baz(bar) or bar.baz(foo)? It’s so easy to check this kind of thing, that you wouldn’t bother trying to remember. Yet the engineer asks for it and… it feels embarrassing to tell “I’m sorry, I don’t remember.” Add to it two rookie off-by-one errors. The interviewer was kind enough to point out the places, giving me a chance to correct them.

The shell part contained something that I’ve never used. Fortunately, the other question, probably even trickier, was manageable to figure out.

Asking questions about technical details of some technology is like measuring something by taking samples. You can’t go through all of it, there’s no time. It’s possible to fit 10 small questions or perhaps 5 bigger ones, taking into account how awkward it can be to dictate code over the phone. If the sample isn’t big; neither is the certainty. “Is it the right candidate?”

If a recruiter asked about basic features, it would be easy answer. To test if you are proficient in a technology, they ask about its more obscure corners to see if you’ve ever been there. Chances are you haven’t, while still being proficient, so the test could be a “false negative”. The signal from phone screening isn’t very strong, but failing to answer simple questions will always be offputting. At the end of the day, recruiters need to translate the interview results into a binary answer: hire or no hire. Joel Spolsky writes:

(…) it is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people’s time fixing all their bugs.

Three quarters of mumbling code into the phone, off-by-one errors and forgotten foobar functions. What is the lesson learned? As for the technical details asked, Wikipedia can tell all about them, so will do “man bash”. All programmers do that all the time, so the lesson won’t be “read more Wikipedia” or more “man bash”. It would boil down to “have more knowledge”. Perhaps it’s more important to use the existing knowledge as efficiently as possible.

Take the code for instance. Programmers write code and read it, always on the screen. Sometimes on paper. They never (in practice) learn the code by listening or dictate it. Someone hearing “for left parenthesis eye equals zero semicolon eye less than five semicolon eye plus plus right parenthesis left brace slash star body of the loop star slash right brace” won’t tell how many times will loop execute. Maybe five, maybe six… was it less than five or less equals five? Compare it to the the same code on the screen. It’s so much clearer!

for (i = 0; i < 5; i++) {
    /* Body of the loop */
}

The telephone itself is an “unnatural” media for code transfer. It also sounds bad if you think when you dictate; thinking makes you mumble, stop, start over again, all sort of things. Perhaps it’s because of the way speaking is bound to thinking. It’s better to make the interviewer wait a little, write you code snippet in a copybook in front of you and once it’s ready, perform the brainless task of reading the code aloud.

It also applies to non-code questions. Making a quick sketch of the answer and reading it will probably make it more clear on the other end of the wire. It also makes the answer slower, but interviewers will have no objections to wait first and hear a clear answer afterwards. The advantage of hearing immediately is outweighed by finding it hard to make sense of the answer.

The interview has come and gone. It’s enough now to sit and wait for the result, but the result isn’t the most important thing. What’s the most important is what we learn.

Author: automatthias

You won't believe what a skeptic I am.

3 thoughts on “Code over the phone”

  1. ok, how about they interview via an online chat? I thought about that yesterday and rejected it, as it’s quite important to hear the voice.

    However, in your case, that would be perfect. Or you could have a simultaneous phone conversation/IM chat. That way, if s/he asks a question, you can respond in typing.

    PS: it’s not ‘putting off’, but ‘offputting’:

    incorrect: “The signal from phone screening isn’t very strong, but failing to answer simple questions will always be putting off.”

    correct: “The signal from phone screening isn’t very strong, but failing to answer simple questions will always be offputting.”

  2. Lenina, thanks for the correction.
    Using a text chat for this is a good idea except for one thing: the interviewees are not allowed to use any computer or calculator during the interview. If there was any computer around it would be sometimes possible to find out answers to tricky techical questions in, say, half a minute.

Comments are closed.