3 ms·

I am confused by the opening paragraph: In a job interview, I once asked a very experienced embedded software developer to write a program that reverses a stri

I am confused by the opening paragraph: In a job interview, I once asked a very experienced embedded software developer to write a program that reverses a string and prints it on the screen. He struggled with this basic task. This man was awesome. Give him a bucket of spare parts, and he could build a robot and program it to navigate around the room. He had worked on satellites that are now in actual orbit. He could have coded circles around me. But the one thing that he had never, ever needed to do was: display something on the screen. Okay, he "could have coded circles around the interviewer" while simultaneously he had never, ever needed to display something on the screen. Does this mean he's an awesome developer and we should be wary of a false negative provided by applying a single, very narrow test? Or does it mean we should apply lots of tests because you never know when you're going to discover that the person you thought was awesome lacks some basic experience you deem fundamental?

arethuza 16y ago
Interviews are stressful and coding is not normally an exhibition sport. It is possible for people to freeze in interview situations - I didn't realize it was possible until it happened to me once in an interview for a CTO role for a fairly established company. I had aced giving the "how do you launch a new product" presentation but then the founder asked me some trivial coding questions (and I do mean trivial) and my brain was stuck in marketing mode and would not context switch. A few minutes later I did come up with an answer, but by that point the founder has obviously decided that I wasn't technical enough.... I can laugh about it now - was pretty gutted at the time.
- raganwald 16y ago
  I recall the wheels coming off my bus once when asked to write a Java program that printed the first 100 primes in an interview. This was after writing a Scheme implementation in Java, being the Threadalyzer team lead, and JProbe Development Manager. I also laugh about it now, but at the time I was bewildered.
colomon 16y ago
I read it as we should be wary of a false negative. I was going to write that your other possibility seemed like good advice too, but on consideration, it probably isn't, at least without caveats. In this particular example, it sounds like the problem was a lack of ready familiarity with printf. As weird as that function is, any decent programmer with a man page could work out how to do it in under an hour, I'd imagine. It would be insane not to hire someone you intended to do something like embedded development because of lack of printf experience. On the other hand, take me as an example. I've got long professional experience writing platform independent software. But that experience is in the guts of the program; I've barely ever touched GUI stuff on any of those platforms. If you assumed my long experience with Windows, OS X, and Linux meant that I could program user interfaces on all three with ease and hired me for that reason, you'd find yourself in a world of hurt.
agentultra 16y ago
False-negative for sure. For highly specialized people, it's easy to forget trivial problems. They've just spent the last five or more years of their life honing their skills on a particular set of increasingly difficult problems. I'd be impressed if they could still scratch down a non-recursive fibonacci function off the top of their head. Most human beings cannot do that. As an interviewer it's easy to forget that you're the only one who is interested in simple functions like reversing strings or shuffling cards. You do so at your own risk. The people walking through your door are expecting to talk about what they're good at. Unless the technology world has progressed at such breakneck speed because we've been mulling over how to best reverse strings for the past thirty years, then it's no surprise that such a narrow test is practically useless for all but junior first-time programmers.
edanm 16y ago
He meant the first - be wary of a false negative. He didn't explain, but the reasoning is that an embedded developer can work for years on projects that dont' have a screen, so there's nothing to print to. I once found myself in a similar situation. After 2 years of working on an embedded C project (without a screen), I needed to print something. I found out to my horror that I didn't know how to do it - I'd only had experience with C++ before getting this job, so I only knew cout/cin. And even after 2 years of work on pretty hard embedded code in C, not having screen meant that printing had never come up. Similarly, many embedded programmers who program in C++ have no experience with the Standard Library, Templates, and sometimes even the "new" keyword, since these are things you often don't use in embedded systems. You can get a false negative if you assume that anyone who doesn't know how to use the Standard Library after 6 years of C++ experience is obviously a bad programmer.

arethuza 16y ago

Interviews are stressful and coding is not normally an exhibition sport. It is possible for people to freeze in interview situations - I didn't realize it was possible until it happened to me once in an interview for a CTO role for a fairly established company. I had aced giving the "how do you launch a new product" presentation but then the founder asked me some trivial coding questions (and I do mean trivial) and my brain was stuck in marketing mode and would not context switch. A few minutes later I did come up with an answer, but by that point the founder has obviously decided that I wasn't technical enough.... I can laugh about it now - was pretty gutted at the time.

raganwald 16y ago
I recall the wheels coming off my bus once when asked to write a Java program that printed the first 100 primes in an interview. This was after writing a Scheme implementation in Java, being the Threadalyzer team lead, and JProbe Development Manager. I also laugh about it now, but at the time I was bewildered.

colomon 16y ago

I read it as we should be wary of a false negative. I was going to write that your other possibility seemed like good advice too, but on consideration, it probably isn't, at least without caveats. In this particular example, it sounds like the problem was a lack of ready familiarity with printf. As weird as that function is, any decent programmer with a man page could work out how to do it in under an hour, I'd imagine. It would be insane not to hire someone you intended to do something like embedded development because of lack of printf experience. On the other hand, take me as an example. I've got long professional experience writing platform independent software. But that experience is in the guts of the program; I've barely ever touched GUI stuff on any of those platforms. If you assumed my long experience with Windows, OS X, and Linux meant that I could program user interfaces on all three with ease and hired me for that reason, you'd find yourself in a world of hurt.

agentultra 16y ago

False-negative for sure. For highly specialized people, it's easy to forget trivial problems. They've just spent the last five or more years of their life honing their skills on a particular set of increasingly difficult problems. I'd be impressed if they could still scratch down a non-recursive fibonacci function off the top of their head. Most human beings cannot do that. As an interviewer it's easy to forget that you're the only one who is interested in simple functions like reversing strings or shuffling cards. You do so at your own risk. The people walking through your door are expecting to talk about what they're good at. Unless the technology world has progressed at such breakneck speed because we've been mulling over how to best reverse strings for the past thirty years, then it's no surprise that such a narrow test is practically useless for all but junior first-time programmers.

edanm 16y ago

He meant the first - be wary of a false negative. He didn't explain, but the reasoning is that an embedded developer can work for years on projects that dont' have a screen, so there's nothing to print to. I once found myself in a similar situation. After 2 years of working on an embedded C project (without a screen), I needed to print something. I found out to my horror that I didn't know how to do it - I'd only had experience with C++ before getting this job, so I only knew cout/cin. And even after 2 years of work on pretty hard embedded code in C, not having screen meant that printing had never come up. Similarly, many embedded programmers who program in C++ have no experience with the Standard Library, Templates, and sometimes even the "new" keyword, since these are things you often don't use in embedded systems. You can get a false negative if you assume that anyone who doesn't know how to use the Standard Library after 6 years of C++ experience is obviously a bad programmer.