Interview tips
-
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 )
But you have other loves besides code....
Christian Graus wrote:
Metal Musings - Rex and my new metal blog
Thats the key point....
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
-
One sneaky practice that's getting popular in India is to steal employees from other companies in the region. Usually this is done by offering a huge joining bonus and a substantial increase in salary. Of course you still need to validate that the candidate is the right one - but you have a higher chance of getting quality candidates when your pool is already filtered (the other company would have done all the interviewing and choosing for you, or if they themselves have stolen the candidate, then the original company would have). It might sound unethical, but it's part of corporate IT hiring :-)
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com linkNishant Sivakumar wrote:
It might sound unethical, but it's part of corporate IT hiring
Nothing unethical about as long as you aren't stealing "secrets". Free markets aren't just for goods, labor should move freely as well.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
-
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"?
Contrary to popular belief - don't need to write code. Ask to talk about project they've done or would like to work on. Use 'Behavioral Interview' technique (http://www.google.com/search?q=behavioral+interview&rls=com.microsoft:en-us:IE-SearchBox&ie=UTF-8&oe=UTF-8&sourceid=ie7&rlz=1I7WZPA[^]) God bless, Ernest Laurentin
-
Ask them if they know something that you're pretty sure they don't, to see if they tell you the truth. Something that's outside of the stuff you advertised for and actually do, and obscure. As in 'as it happens, we're tending for a project writing software the help with breast screening, have you ever done any image processing with regard to detecting cancerous lumps ?'
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 )
woo i have! Bryce
--- To paraphrase Fred Dagg - the views expressed in this post are bloody good ones. --
Publitor, making Pubmed easy. http://www.sohocode.com/publitorOur kids books :The Snot Goblin, and Book 2 - the Snotgoblin and Fluff
-
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.
Today's WTF article is about absurd interview questions. http://worsethanfailure.com/Articles/Riddle-Me-An-Interview.aspx[^]
Farhan Noor Qureshi
Well.. I disagree with the writer. These are creative problem solving question. He just came up with his own stupid conclusion and find they are stupid, great! Good practical answer to these question sho good problem solving skill, as they say!
-
Trollslayer wrote:
What was the biggest problem they were unable to solve?
Hey! My suggestion was exactly the opposite. May be both questions make a good pair. Tsk tsk, poor interviewees!!!
Farhan Noor Qureshi
True, how someone handles success and failure tells you a lot about them. To quote Kipling: "If you can meet with Triumph and Disaster And treat those two impostors just the same"... Elaine (literary fluffy tigress)
-
Occasionally, I have to help hire a contractor so, some of the things I try to do are: Screen out as many people as you can with a take home project. Though try to keep it brief because time is money and I'd never interview with a company that wanted me too spend to much time cutting code for free. 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. Some simple pseudo coding of a reasonable problem tends to help. I've found that some people get way too nervous during an interview and they get some kind of programming block. Ask them about data structures and algorithms, this is often where people are lacking. And most of all, make sure you "like them". As you interview more people your will develop you intuition, trust it. -- modified at 18:32 Tuesday 15th May, 2007
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
Hmm... some of the people I work out can't be left outside if it starts to rain.
-
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"?
-
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"?
-
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"?
Lie :laugh:
Steve
-
Ask them if they know something that you're pretty sure they don't, to see if they tell you the truth. Something that's outside of the stuff you advertised for and actually do, and obscure. As in 'as it happens, we're tending for a project writing software the help with breast screening, have you ever done any image processing with regard to detecting cancerous lumps ?'
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 )
Christian Graus wrote:
ever done any image processing
You mean *manual* image processing? E.g. browsing websites inspecting breasts. Yep, and I always *say* I'm looking for cancerous lumps :->
-
Ask them to bring a project/program/util that they have written and ask them to wlak you through parts of the source code, from that you'll know if they can cut code or not.
.net is a box of never ending treasures, every day I get find another gem.
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
-
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