Interview tips
-
Anybody got any? I'm actually the one interviewing a candidate to replace a programmer that I inherited. They were totally incompetent.They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking. However, they were nice enough to resign (a few months after I became their boss) before we had to fire them. Now we need a replacement and I'm want to make sure I can weed out the crap and the clueless. Anybody have any magic questions that can really reveal if they "get it"?
My personal fave is to print off a load of code with deliberate mistakes in, put it in front of them, and get them to point out the problems. Start with easy ones (variable assignments etc) to see if they've an eye for detail, then move on to some more esoteric ones in the area they'll be working in, to test domain specific knowledge...
"Knock me down, I'll get straight back up again, I'll come back stronger than a powered up pacman" (Lilly Allen / Kaiser Chiefs)
-
WesInSaratoga wrote:
Write a program that will print "X" for numbers divisible by 10, "Y" for numbers divisible by 4, and the number itself for all other numbers.
What should be printed for 20, 40, 60, 80, and 100?
:josh: My WPF Blog[^] FYI - Bob is a scarecrow who keeps Chuck Norris away from CodeProject.
*Beep* Sorry - you're wrong but thanks for playing....seriously it clearly says "X" for numbers divisible by 10, "Y" for numbers divisible by 4, and the number itself for all other numbers." It did NOT say print the numbers between 1 and 100 that are both divisible by 4 and 10. The output would be something like this - there would be 100 results: 1, 2, 3, Y, 5, 6, 7, 8, 9, X, 11, Y,13,14,15, Y,17,18,19,XY, ...ecetera...;)
-
*Beep* Sorry - you're wrong but thanks for playing....seriously it clearly says "X" for numbers divisible by 10, "Y" for numbers divisible by 4, and the number itself for all other numbers." It did NOT say print the numbers between 1 and 100 that are both divisible by 4 and 10. The output would be something like this - there would be 100 results: 1, 2, 3, Y, 5, 6, 7, 8, 9, X, 11, Y,13,14,15, Y,17,18,19,XY, ...ecetera...;)
pgorbas wrote:
*Beep* Sorry - you're wrong but thanks for playing
At least I would have scored points for my effort at attempting to clarify the requirements doc! ;)
:josh: My WPF Blog[^] FYI - Bob is a scarecrow who keeps Chuck Norris away from CodeProject.
-
pgorbas wrote:
*Beep* Sorry - you're wrong but thanks for playing
At least I would have scored points for my effort at attempting to clarify the requirements doc! ;)
:josh: My WPF Blog[^] FYI - Bob is a scarecrow who keeps Chuck Norris away from CodeProject.
It is true tha as stated some of the requirments were vague. A typical response to the question "How many numbers between 1 and 100 are divisible by 4?" would have the person counting up all the numbers which divide by 4 with 0 remainder, while others would reply "All of them." AFter all you can divide ANY number by ANY number...
-
Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that. Like the other guy said, have them bring something in to talk about ... or better yet, send them a short assignment they can complete in an hour or two, and have them bring that in and discuss how/why they did things a certain way.
Paul Brower wrote:
Most good programmers would struggle with that.
I'm having a difficult time comprehending how anyone who struggles with writing code could possibly be considered a good programmer.
Grim
(aka Toby)
MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL GO
(0 row(s) affected)
-
Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that. Like the other guy said, have them bring something in to talk about ... or better yet, send them a short assignment they can complete in an hour or two, and have them bring that in and discuss how/why they did things a certain way.
Paul Brower wrote:
Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that.
As a former hiring manager I'd have to agree that writing code is often wasted time. My favorite approach (and hiring is as individual a skill as programming!) is to ask them to solve a common problem, such as how did they get to the interview, how do they make breakfast, etc. The answers to these questions will tell you a LOT about the person as both a programmer and a problem solver. For example, one candidate who specialized in embedded systems made use of timers to kick off processes, another candidate who was very UI oriented took the most non-linear approach I've ever seen, and even amongst "standard issue" programmers the answers were NEVER the same. I wish I had kept all the flow charts and pseudo-code that resulted from these questions! If the candidate got through that phase of the interview I usually asked them to write part of the exercise in their favorite language. A deep understanding of one language usually meant that they could pick up whatever languages we were using. Over the last couple of years that I was involved in hiring programmers I discovered that more than half the candidates had code in some open source project. If that was the case I knew I didn't really need to look at it, but I usually did anyway! In my experience (your mileage may vary) the programmers who could create a reasonable flow chart or pseudo-code outline worked out well. Of course I'll never really know how well the ones that could not would have faired... Bill
-
Anybody got any? I'm actually the one interviewing a candidate to replace a programmer that I inherited. They were totally incompetent.They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking. However, they were nice enough to resign (a few months after I became their boss) before we had to fire them. Now we need a replacement and I'm want to make sure I can weed out the crap and the clueless. Anybody have any magic questions that can really reveal if they "get it"?
My two favorite questions: 1. How many quarters tall is the Empire State Building? I'm looking for problem solving skills. Do they ask stacked face to face, or end on end? If they just give up, I do not want them. 2. Which is funnier in movies, monkies or racoons? This is just to see if they have a bit of sense of humor. Sometimes they ask questions to find the 'right' answer. I don't want a yes person. I want someone who has opinions and is not afraid to speak up.
__________________ Bob is my homeboy.
-
Anybody got any? I'm actually the one interviewing a candidate to replace a programmer that I inherited. They were totally incompetent.They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking. However, they were nice enough to resign (a few months after I became their boss) before we had to fire them. Now we need a replacement and I'm want to make sure I can weed out the crap and the clueless. Anybody have any magic questions that can really reveal if they "get it"?
Send me your email... I gotta bunch of things. Dennis A. Drew 805.560.0404 Ext. 105 dennis@multiprobe.com Director of Software Engineering Multiprobe Corporation 819 Reddick Street Santa Barbara, CA 93103
-
Chris Austin wrote:
Make sure your candidates are balanced individuals, if their only hobbies are coding, programming, and software you may have problems getting them to work well with the users and customers.
Damn, I doubt you'd hire me, then...
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Anybody got any? I'm actually the one interviewing a candidate to replace a programmer that I inherited. They were totally incompetent.They were hired by a non-programmer and enjoyed a good couple of years of being able to BS their boss who didn't know a thing about what they were doing. The stuff they got away with is just shocking. However, they were nice enough to resign (a few months after I became their boss) before we had to fire them. Now we need a replacement and I'm want to make sure I can weed out the crap and the clueless. Anybody have any magic questions that can really reveal if they "get it"?
I start with a phone interview and ask a few short answer questions like "What is a dead lock?" and "how can you guarantee that they don't happen?". Questions that are typically not taught in school are best. A lot don't get past this stage and it saves a lot of time. In the interview I give puzzles and watch how they solve them. Ask them to draw a state map for a common household appliance, or explain how they would solve a simple problem like debouncing a switch in software. Something that takes little setup time and can be solved in 10 - 15 minutes. I tailor the questions to the job duties to give the candidate an idea of the work they would be doing.
-
Brainbench is an absolute waste of time. Anyone with a couple of books can answer every single one of those questions. It doesn't help assess the true program ability of a candidate. I've given many technical interviews and I've come up with 10 questions that touch on different areas. I have them take an online test with these questions, with me on the phone. I tell them to let me in on their thought process. By the last question, I get a great assessment of the candidate. Listing to a person's thought process on programming problems far outweighs any other technical interview. I don't think asking obscure questions like "how much does Mt Everest weigh?" don't help much at all.
-
I start with a phone interview and ask a few short answer questions like "What is a dead lock?" and "how can you guarantee that they don't happen?". Questions that are typically not taught in school are best. A lot don't get past this stage and it saves a lot of time. In the interview I give puzzles and watch how they solve them. Ask them to draw a state map for a common household appliance, or explain how they would solve a simple problem like debouncing a switch in software. Something that takes little setup time and can be solved in 10 - 15 minutes. I tailor the questions to the job duties to give the candidate an idea of the work they would be doing.
bitzblitz wrote:
a simple problem like debouncing a switch in software.
I guess I would fail your interview, then. I don't even know what that question means.
Grim
(aka Toby)
MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL GO
(0 row(s) affected)
-
My two favorite questions: 1. How many quarters tall is the Empire State Building? I'm looking for problem solving skills. Do they ask stacked face to face, or end on end? If they just give up, I do not want them. 2. Which is funnier in movies, monkies or racoons? This is just to see if they have a bit of sense of humor. Sometimes they ask questions to find the 'right' answer. I don't want a yes person. I want someone who has opinions and is not afraid to speak up.
__________________ Bob is my homeboy.
leckey wrote:
2. Which is funnier in movies, monkies or racoons? This is just to see if they have a bit of sense of humor. Sometimes they ask questions to find the 'right' answer. I don't want a yes person. I want someone who has opinions and is not afraid to speak up.
Monkeys are always funnier, no question. Chimps are the funniest but, of course, they are not technically monkeys. -- modified at 10:12 Wednesday 16th May, 2007 Argh, the replying is all messed up again :doh:
-
Same here. This used to be my hobby, until it became my profession.
Grim
(aka Toby)
MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL GO
(0 row(s) affected)
Ever since I turned my hobby/passion into my profession, I have had less enthusiasm about it.:suss: I used to spend ALL of my free time working on my computer and writing fun little apps. Now, it's just like taking work home! EEEWWWWwwwww! X| Something about your bills REQUIRING you to work on your hobby and someone else telling you HOW you will do that same hobby just take the fun out of it! I can tell you, I'll NEVER turn a hobby into a profession again!
JamminJimE Microsoft Certified Application Developer
-
bitzblitz wrote:
a simple problem like debouncing a switch in software.
I guess I would fail your interview, then. I don't even know what that question means.
Grim
(aka Toby)
MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL GO
(0 row(s) affected)
I wouldn't ask such a question to someone I was hiring to do database or Web development (for example). For the DB developer, I might ask "how do you find duplicate records in a database?", For the Web developer I might ask "How do you find the server address in JavaScript?".
-
*Beep* Sorry - you're wrong but thanks for playing....seriously it clearly says "X" for numbers divisible by 10, "Y" for numbers divisible by 4, and the number itself for all other numbers." It did NOT say print the numbers between 1 and 100 that are both divisible by 4 and 10. The output would be something like this - there would be 100 results: 1, 2, 3, Y, 5, 6, 7, 8, 9, X, 11, Y,13,14,15, Y,17,18,19,XY, ...ecetera...;)
pgorbas wrote:
The output would be something like this - there would be 100 results: 1, 2, 3, Y, 5, 6, 7, 8, 9, X,
Gee. I thought 8 was divisible by 4. :-D;);P
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
-
pgorbas wrote:
The output would be something like this - there would be 100 results: 1, 2, 3, Y, 5, 6, 7, 8, 9, X,
Gee. I thought 8 was divisible by 4. :-D;);P
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
-
That works if they can. I've worked a number of jobs that were secure locations. No code leaves, in fact no storage media leaves, the facility. If that's the case, a simple progamming task works wonders. For people who can't "take the test" and freak out ... they'll have to go elsewhere. Software development requires some non-code skills like talking with customers / users (not just requirements, sometimes for feedback or even "thank you"), documentation, and the that applies to lots of non-tech careers too, working under some pressure. The best and simple skill test I saw, on the web, went something like this: Write a program that will print "X" for numbers divisible by 10, "Y" for numbers divisible by 4, and the number itself for all other numbers. Do this for numbers (integers) between 1 and 100. Amazing how half the posts to that complaint - that 90% of programmers can't think the problme through - also didn't get it correct. I'd suggest something like that - give them a computer to actually do it on, real-time, and a few others like it. Deeper code problems like APIs / object libraries (Java and .NET come to mind) and design patterns and such are best done orally or "at the white board." What to look for there, and this is crucial: understanding, not knowledge. It was a preacher - minister - that once talked about that and gave the clearest explanation, which went well above, shall we say, spiritial scenarios. It applies to programming just fine. - Knowlege is the accumulation of facts, as in "memorization"; most public school tests only deal with this, except for essays - Understanding, which is the ability to re-organize the facts without losing the meaning. Jesus' talking in parables - using a story to explain something, was the minister's example. In programming, the person has to be able to "explain it" in plain terms, not just buzzwords. Even if she starts out with something as silly as "these 2 objects go into a bar, and the that implements Ifoobar says ..." - you're looking for understanding, not memorization. Why? When? Where? Gotchas? Under what conditions does this no longer apply? - Wisdom goes well beyond knowledge, and is harder to describe. Simply put it deals with "application" but requires a level well beyond the obvious. Anyone claiming to be a guru or master thinker should have wisdom. For non-programming stuff, it would be the "master" in something like a Karate Kid movie who does things not at all obvious to the apprentice
-
Paul Brower wrote:
Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that.
That's right. And a surprising number of interviews ask you to write code at the interview.:(
Kevin
Kevin McFarlane wrote:
Paul Brower wrote: Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that. That's right. And a surprising number of interviews ask you to write code at the interview.
I disagree. I think that having a candidate write code can be a good thing. What you have to understand is that it's just as important to see how they approach the problem as it is whether or not they get the right answer. Encouraging them to think out loud as they solve the problem helps. One of my standard questions is the task of writing an Insert function that adds a new node into a sorted singly linked list in the correct position. The problem requires some level of comfort dealing with pointers but should be solvable by anyone with a CS degree or even just a course in data structures. After they've written the function I then ask them how they would go about testing it and what test cases they would use. What I'm looking for here is a set of tests that at a minimum test for adding to a null list, adding the the beginning of a list, adding to the middle of a list and adding to the end of the list. I then have the candidate step through his/her code for each of these cases. I don't expect a candidate to always write perfect code but I do expect them to be able to understand their own code and to be able to see and address the problems they find. A failure on this test was a canidate who advocated test driven development. When ask to come up with a set of test cases for the problem he said he'd test it by writing some test code to throw random numbers at the list and then write some more code to validate that the list was still well formed. Of course he'd also visually inspect the first dozen or so passes to make sure his test code was correct. No amount of prompting could get him to manually set up the test cases so I did that for him. Walking his code through each of the test cases showed that 3 of the 4 cases failed. The process gave me the impression that this candidate hacked at code rather than designed code so despite a great resume he was a 'no hire' for my team. scoy
-
Don't have them write code in the interview. That is simply a waste of time. Most good programmers would struggle with that. Like the other guy said, have them bring something in to talk about ... or better yet, send them a short assignment they can complete in an hour or two, and have them bring that in and discuss how/why they did things a certain way.
I disagree. Having them write code before your eyes gives you a sense of how they think as they work through the problem. What has to be tempered is your expectation of the code they produce. You have to bear in mind that they are under a nervous pressure which means you won't see the best they can do, but you can get a good idea. I interviewed for a large corp that had me write code under a NetMeeting session. I was nervous as hell, but it was a good experience. You just do what you can, and talk it out, think aloud, and let them take part in that process. Its kinda like Pair Programming at this point. And if you can't handle anyone watching you code, then you might have other issues. But keep the problems within reason. One was: "Describe a design for a logging system, and define the initial interfaces. Not the implementation, just the interface." Another one was: "Write a program which calculates the angle between the hour and minute hand." I got the offer but had to decline do to my wife entering surgery, but the experience in itself was worthy. This was also for C++ which my skills had gotten rusty from all the C#. So it was an eye opener too. Let me know where I was at. I also agree with the comments regarding understanding verses knowledge. I don't care if you've memorized any api, but if you're not too proud to tell me you'd use MSDN or Google, or just F1 in response to a question, then you've earned a couple of points. I think the ability to research has to be accounted for as well.
This statement was never false.