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?
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.
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.
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.
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.
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.
Some good points in interviewing, but I think that's more useful to me for when I'm the interviewee... Seems like that info could be used to improve your resume and lead an interview from the interviewee's seat... Make them ask the questions you want to answer, etc, if they aren't already.
As for the lying on the resume, though... I disagree. Assuming everything on the resume is a lie and not being surprised about the lies is wrong. Anyone who will lie on their resume will lie afterwards, too. Anytime they tell you they can do a task, you can't trust them for it. You have to micromanage them forever after.
That's not to say you should assume it's the truth... You should investigate and make sure. But if there are lies, it should horrify you.
I wanted to echo the last part of this one. I've interviewed a lot of people and I see people "exaggerating" or outright lying about their skill levels and abilities more often than I would expect. It seems, anecdotally, to be increasing as well. If you find someone doing this - no hire. Instantly. If you're the one with the CV - please don't. For your own sake. It's poisonous, and it won't help you long term.
Yeah, it's not like, if you get the job, you can fake out the machine too. Either you got the skills or you don't.
I interviewed someone recently who listed C++ as his top skill. What that actually meant was a) he phyically sat near the C++ programmers at his current job and b) he ran the programs they wrote on his PC.
People list all the programs they've used. Microsoft Word, Microsoft Powerpoint, Firefox, Internet Explorer, [no, not a web programmer] Windows, Linux, Mac OSX, emacs, Visual Studio, gcc, g++, ssh, Putty, xterm, armed robbery, and emacs. (Typical start to an interview: "You listed emacs twice." "Really? Oops, sorry." "That's... not the reply I was fishing for, but 'oops' is acceptable.")
Frankly, I don't blame them. I looked through a stack of a dozen resumes on my boss's desk and noticed that every single resume listed Scrum. Somebody in HR is screening out candidates that don't list Scrum on their resume. I pointed it out to my boss and he just laughed and said he didn't think he could do anything about it. (I didn't look for other patterns, but I bet it's just as bad with particular software technologies.)
So listing every single piece of software you've ever noticed installed on your computer is a good policy unless you're personally handing your resume to the hiring manager. It makes a bad impression on technical folks, but that's better than getting your resume round-filed before anybody technical sees it.
(Note to self: next time job hunting, prepare different HR-friendly and techie-friendly versions of each resume.)
There must be some jub hunters advice book where they tell people to do this, or maybe schools careers advisers do.
We had a case where we had a stream of candidates giving the same - and wrong - answers to various questions, all had come via the same recruiter, who was debriefing them after and coaching the next one.
From the resume writer's perspective, the problem is that you have no idea what standard the interviewer uses, so you pretty much have to use the standards of your peers.
For example, I have programmed a little in many, many languages, and consider myself reasonably good in Python and C++. I know plenty of people who are less experienced than me who would write that they are "experts" in C++/Python, and would list those languages I wouldn't think to list 'cause I only know them a little.
So what should I write on my resume? I'm trying to compete with these people, after all.
My resume includes separate lists for technologies/languages I am "advanced" or "proficient" in and technologies/languages I have done some work with. To give an example, I can slowly and painfully write PL/SQL when it's necessary, but I would not feel comfortable deploying it without asking a PL/SQL guru to review it, so I don't describe myself as "proficient." I described my Java skills as "advanced" after doing a couple of years of professional Java development, but I downgraded my Java to "proficient" after spending several years away from it. I describe myself as "advanced" if I'm ready to do professional-quality work from day one.
If you go by the standards in the marketplace, well, there aren't any. We interviewed a candidate for a highly technical position only to find out that most of the technology experience listed on her resume was indirect exposure doing administrative and liaison work for technical teams. She was more technical than the typical corporate product manager or account manager position, but she wasn't remotely close to being qualified for the position we advertised. Strange thing was, she seemed to understand the position and clearly wanted it... not sure what that was about, but it proves you can't assume anything.
I interviewed a finance major for a job parsing a COMSTOCK feed from a satellite. Asked him "Can you program in C++?" "Yes" he lied.
We decided to hire him. After he accepted the offer, he asked if he could come in over the weekend to get started. Wow! What enthusiasm!
He spent the weekend learning to program in C++. He was great, his knowledge of finance was invaluable, a stellar performer all around. Eventually wrote a webpage test kit on his own and sold it to Adobe.
So was it a lie? He WAS able to program in C++ on Monday.
That's really funny. It reminds me of my old Quiz Bowl days, where I would raise my hand while still working out the answer. I trusted my brain would finish the problem before the "well, what's your answer?" pause ran out.
I suspect this individual was extremely bright, and would have succeeded regardless of job specifics.
I lied on my resume (basic C++ knowledge) when applying for my very first job. It got me past the phone interview, and I've spent the next 48 hours on caffeine struggling with examples from C++ tutorial. (I did knew some C and basic OO concepts at that point though.)
Never came to regret it.
Yes, lying is bad, and perhaps I would agree with your well-spirited reply if I weren't already at the other side. I hope it didn't reflect on my personal qualities long-term :)
Oh the other hand clueless people often don't realize that they're clueless. For instance when I was in high school I took a C++ class and never touched it again until much later, but I still had it on my resume for a long time because I didn't realize how little I had learned or how much I had forgotten until I was extremely embarrassed at a job interview.
The question must be precisely worded. "Write a function to shuffle a deck of cards" is woefully ambiguous. Provide the function header and avoid misunderstandings, which are all too common.
Nah... you need to know if the candidate can spot underspecified problems and ask for clarification.
I'd argue that ability is more important than if he can come up with a good card-shuffling or string-reversing algorithm on the spot. Algorithms can be looked up easily if you're having a mental blocj. The ability to know that you need more information is a bit more elusive.
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?