Interview tips
-
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.
-
That's the only thing where they can't BS you, and I've seen it show huge differences between candidates that are resume-wise hard to tell apart. You need a few problems ready that you deeply understand and can be solved in 10..20 lines (he might race through a problem he already knows by heart, so you need at least a second one to throw at him). Does he: Make a plan? Rely on unconfirmed assumtions? communicate with you? Write solid code? Check for errors? Encourage him to talk about his thoughts, help him when he's stumped or makes a stupid mistake, be relaxed about abbreviations, typos and general "looks", but be tough about things that matter. Play devils advocate: think of all things that can go wrong (overflows, strange inputs, ...) and question/nudge him to see how many he finds. What would he do if he can't use CString class? The second most important thing is: set a minimum standard. Don't hire the best you can get just because you need one desparately. For a 1h interview, I'd say roughly 20 minutes warm up, asking the usual resume questions, poking for passion, discussing previous projects (can he explain the task of the software in terms you understand?), getting over the initial nervousness. 20 minutes "write code & discuss", and 20 minutes about the project he is to work on: what you require, what he expects, where are his deficiencies and how to catch up. If you have more time (I found that short of 90 minutes feels necessary), expand the first and the last part.
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! | sighistWhen we were interviewing C++ candidates, I'd use this function below and just ask them to explain it to me. Amazing the range of responses.
void foo(char *p, char *q)
{
while(*p++ = *q++);
}This statement was never false.
-
Nishant 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
Exactly. And too bad that's often the only way to get a raise. Lateral movement. It seems that companies have a hard time rewarding existing employees, but no problem paying more for a new person, even though they have to train them etc. Oh well, such is life.
This statement was never false.
-
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.
Give them a laptop with your IDE loaded, am sure most good programmers would not struggle with that.
- sajith m
-
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.
-
This thread is interesting, but this quote had me laughing out loud!
Tom Delany wrote:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
agi20dla
I wish I could take credit for that, but actually, my 16 year-old son came up with that from somewhere, and I thought it was funny.
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
-
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.
norm .net wrote:
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.
And after doing that you might want to ask them if they actually have the right to show a prospective employer the materials that they presented. In the US actual employees will not have that right to company materials unless it is specifically given by the employer. And many contractors will not have that right either.
-
norm .net wrote:
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.
And after doing that you might want to ask them if they actually have the right to show a prospective employer the materials that they presented. In the US actual employees will not have that right to company materials unless it is specifically given by the employer. And many contractors will not have that right either.
jschell wrote:
And after doing that you might want to ask them if they actually have the right to show a prospective employer the materials that they presented.
You said employers, I've written a networking desktop application that is and looks professional enough to be sold by Microsoft. This has been written in my own time and not connection with my current employers. And anyway you are showing code not giving it away.
.net is a box of never ending treasures, every day I get find another gem.
-
jschell wrote:
And after doing that you might want to ask them if they actually have the right to show a prospective employer the materials that they presented.
You said employers, I've written a networking desktop application that is and looks professional enough to be sold by Microsoft. This has been written in my own time and not connection with my current employers. And anyway you are showing code not giving it away.
.net is a box of never ending treasures, every day I get find another gem.
norm .net wrote:
You said employers, I've written a networking desktop application that is and looks professional enough to be sold by Microsoft. This has been written in my own time and not connection with my current employers.
If it is your own code, you have no limiting contractual agreements with your employer (some employers require such contracts), and it does not reflect what your employer does then you can show it. Contractual agreements might include any of the following or more - Rights to anything you produce, regardless of industry - Rights of first refusal on anything you produce - Rights of no-compete within the same industry If you signed something then it is your responsibility to know what you signed.
norm .net wrote:
And anyway you are showing code not giving it away.
Wrong. It is intellectual property. You have absolutely no rights to it. Including just "showing" 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"?
I think you should find one or two guru/consultants to sit in on the application process with you. They can help you weed out the wannabees. Just make sure they aren't looking themselves, or they will pull the best applicant away from you. Another thing you can do is employ a company like brainbench to have a small test prepared for applicants to take, they can provide you with a report of the skill level of your applicants. I've had to do this a few times for some jobs I've taken. Good Luck!
-
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.
Personally, I've never worked in an environment where any code has been allowed to leave the premisis, but on another note,check out these tips from Joel Spolsky: http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html[^] NB: See those in Edinburgh at the Radisson for a pint or two tonight.:-D
-
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"?
Get through it without using the word "challenge", in any of its forms. It turns me off no end when people describe a job I'm offering as "challenging" -- if I need someone who can't do a perfectly do-able job without struggling, I'll scout universities, not advertise in the pro press.