Interview tips
-
What was the biggest problem they were unable to solve?
Trollslayer wrote:
What was the biggest problem they were unable to solve?
Women.
Michael Martin Australia "I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash 24/04/2004
-
What about the chest? If they have spectacular growths on their chest, is there a polite way to gaze, without getting called out?
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
-
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"?
Wjousts wrote:
Anybody have any magic questions that can really reveal if they "get it"?
well brain bench is also a good option... just take his test at brain bench as you requrie.
Muhammad Minhaj Mehmood Application Developer E-mail: minhaj.kk@gmail.com Cell: +92 (333) 2715467
-
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:
That is simply a waste of time. Most good programmers would struggle with that.
I'm curious. Why do you think that? (Obviously, my experience is the other way, but it isn't that much)
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist -
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"?
Just my 2 cents, I would set a small test - I've found testing the most basic knowledge can instantly rule out some candidates. Prepare a short 15-30 min test for some of the most common technologies that appear on the c.v's you recieve i.e. SQL skills, XML, coding then give the candidate a test comprising of items listed on their c.v. This gives you chance to find out if the candidate has been over ambitious in stating what they are experienced in. I've found that my idea of experienced often differs from the candidates. It is crucial to remember the candidates listed experience, don't expect a fresh graduate to be at the same level as someone with a few years commercial experience. If dealing with someone straight out of college/university I would always be looking more for them to demonstrate good problem solving skills and a sound foundation and eagerness to learn rather than being able to answer every question 100% accurately. In short, 1:- cover the c.v and make sure everything in it is the truth 2:- short technical test (but I dont look for complete correctness, psuedocode or even a description of what the candidate would do can sometimes suffice) 3:- Other experience, discuss this. Even non IT related can matter. I worked within a customer service call centre and local shops while at uni - gave me lots of experience of dealing with customers which can be very important. 4:- Discuss other interests. Might not seem that important but it is essential to get someone that will fit right into the team as well as do the job. 5:- trust your instinct. Sometimes one candidate will stand out above all the rest, this is usually a sign. Finally - if you don't have much experience interviewing candidates practice with one or two of your collegues, family, friends. You want to be able to keep the interview moving along at a nice steady pace. This not only helps the candidate relax (admit it we all get a bit nervous at interviews) but allows you more time to assess and record the interviews progress. As a sidenote - after I got my first job coding I spoke to one of the guys that interviewed me one evening and he told me that I was chosen over the other candidates, not because I had better qualifications,experience, answers than the others. One of the questions I was asked I didn't have a clue and managed to get him to tell me the answer without him realising he had. For him this demonstrated the ability to find the answer to a problem, which is something we face every day.
-
The thing that most interviewers do that makes me laugh is, they do all the talking! It's like they finally have a captive audience to drone on about their boring company and boring job. So, my advice to you is, minimize the amount of talking that you do, and let the candidate do most of the talking. For example, if they ask about company benefits, don't drone on about the company benefits, ask them what they are looking for. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithCheck This link. This helps me a lot http://www.joelonsoftware.com/articles/fog0000000073.html[^]
Ravi
-
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 consider myself a pretty good Software Engineer. I have been programming for over 20 years now which brings with it experience that can not be measured by on-the-spot syntactical prowness. One of my interviews had several programming questions. Some were of the variety "What is this block of code doing?" while others were "Write a routine to compute the moving average of a stock over time. Consider recursion." Well, I can look at any code and tell you what it is doing. Unfortunately, I didn't even know what a 'moving average' was. Needless to say, the interviewer was dissapointed that I didn't get it. When I got home, I figured out what a moving average was and, within 30 minutes, wrote up two ways of computing it and yes, one was recursive. I fired that off to my interviewer with a question, "Are you looking for a Software Engineer who can solve problems, or a stock broker that can program?" Impressed, he invited me back but I declined, mostly out of spite, but I also felt that his attitude betrayed the way he ran his shop and I wanted no part of it. Programming is a small part of Software Engineering. The programmer who can whip up a routine to compute a moving average using recursion, on-the-spot, is cream of the crop. If you can find him/her, hire them. I'll be the first to admit I'm not at that level and probably never will be. My brain simply isn't wired that way. When I interview people, I am looking for 2 things: Problem solving skills and programming skills. In the end, I like the "What is this block of code doing?" approach. It reveals the interviewees understanding of the language and 'potential' programming skills. But I also like the "Write a routine to ..." type of questions (they identify problem solving skills). They just need to be realistic. Here is an interesting article: FizzBuzz
-
Trollslayer wrote:
What was the biggest problem they were unable to solve?
Women.
Michael Martin Australia "I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash 24/04/2004
Funny, I was thinking men ;P
-
Wjousts wrote:
Anybody have any magic questions that can really reveal if they "get it"?
well brain bench is also a good option... just take his test at brain bench as you requrie.
Muhammad Minhaj Mehmood Application Developer E-mail: minhaj.kk@gmail.com Cell: +92 (333) 2715467
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.
-
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
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.
-
What about the chest? If they have spectacular growths on their chest, is there a polite way to gaze, without getting called out?
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
Jim Crafton wrote:
is there a polite way to gaze, without getting called out?
Wear sunglasses. :suss:
:josh: My WPF Blog[^] FYI - Bob is a scarecrow who keeps Chuck Norris away from CodeProject.
-
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"?
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
-
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.
-
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 )