Fog Creek Software
Discussion Board




technical interviewing styles

there is a pattern of interview I came across, where you were asked technical questions, as well as problems in all areas of software and cs, that is
OOP,algorithms, design patterns, OS,parallel programming,database,programming languages(Perl,LISP,Java,C++,C), automata theory
around 5 questions from each group amounting to around say 30 or so questions, as well as small problems.
Would this be an effective interview technique for software dev. positions? that is get a reasonable clue on the person's tech knowledge?

B.Jones
Thursday, April 10, 2003

The problem you'll run into is you'll either end up asking basic questions that a reasonably astute person will be able to guess at or have read somewhere on /. or you'll ask too in depth questions and stump even a good programmer in some areas and come away with a bad opinion.

I suggest looking at the requirements for your position and asking real world questions as they extend from his/her background and move towards your position.

"John, I see you have 97 years of Java experience - we're moving all our legacy COBOL systems to the new OO-COBOL - what tools will you use and what development methodologies would you take advantage of to help us in with this?

Truly specific questions never get you anywhere (often) and general questions are a laugh - I was asked if you can have a Many to Many join in a database (DUH No, everyone who's seen a database or sat through an intro class knows that).  That doesn't show my knowledge of DBs in any way and affords little follow up and offers me little chance to expound.

Propose a problem and ask for thoughts/solutions.  I think you'll be pleased.

Lou
Thursday, April 10, 2003

That "interviewing style" is just undergrad exams 101.


Thursday, April 10, 2003

I think you should aim to ask a question that is a "real" problem you solve on a daily basis, or at least modelled on it.

THen, and this is the key, if they know the answer, discard that question from your evaluation.

Anyone can already know an answer. That's not realistic for what most developers do on the job though. If you want answers, you can buy a book.

You need to evaluate a persons ability to solve problems they dont already know the answer to. Thus, ask enough questions such that they actually have to work through a few and judge them on that.

And the horse you rode in on
Thursday, April 10, 2003

Lou - to me that's the "standard question" for db interviews. So much so I tend to cut off the interviewer:
"How would you implement a man..."
"Three tables"  (with a smile)

[and if the interviewer takes offense at being cut off like that, I won't fit in there anyway]

Philo

Philo
Thursday, April 10, 2003

I think there's another problem with this interviewing style--you'll annoy some pretty good people with the inanity.

In my last job search, one company I interviewed at asked me these two questions (among others):

What's the difference between a hashmap and a hashtable?
What does a % in an email address mean?  (This was for a job that had no connection to email reading, writing, or parsing).

Frankly, it made me not want the job.  At the same time, I interviewed at a company that asked me to write a couple of methods in C++ that did things related to their work, and explain the decisions I had made, and the tradeoffs involved.  And that made me feel like I wanted to work there--they obviously took their job candidates seriously, and (within the limits of an interview) tried to judge how well they could do the work required of them.

Gav
Thursday, April 10, 2003

Lou wrote, "you'll...end up asking basic questions that a reasonably astute person will be able to guess at or have read somewhere on /."

Isn't the ability to determine if the person is reasonably astute or not a *good* thing?

I can see the advantages of this interviewing style, as a way of assessing roughly what a person knows.  I would find it tiring, but I think it has its place.

Brent P. Newhall
Thursday, April 10, 2003

We have a small written test (choices as answers, not prose) of around 20 questions. We mark the answers and anyone who gets above 5 is called for an interview (ok, the test's not very easy) - we then sort of "drill in" into some of the questions on the test, which gives a good indication of the understanding/communication skills and the ability to learn. Sometimes we proceed with puzzles, like lateral thinking stuff, or some of the tech interview questions at techinterview.org. It's not perfect, but what I look for most is the ability to learn and how well we're able to communicate with each other.

What I don't usually buy is "I don't know this because my last job(s) did not require me to know them" - that answer to more than N questions (where N is subjective) usually indicates lack of interest and/or passion to me.

Deepak Shenoy
Thursday, April 10, 2003

I questioned my own choice of words at the time.  By "reasonably astute" I meant to imply that anyone who has made it past a preliminary phone screening (you do that, right) would probably be able to answer some of those questions not because of any knowledge in the specific area but just because of passing by the answer somewhere. 

While its great that they picked it up it doesn't show any real knowledge in the area so you haven't learned anything new. 

Boy, Tom is smart, he knew why concatenating strings in C is rough when you use '+'. 

Okay, but does he know an alternative method - could he implement his own?  Ask him to describe the knowledge not answer a question.

Poor interviewers ask "What didn't you like about your last job?".  Good interviewers ask "If you were suddenly the manager at your last job what would you have done differently to make the programmers lives better?" 

The former is shallow and conveys no useful information - "The fridge smelled like fish and I really hate fish".  The latter offers real insight - "I find it very useful to not have any interruptions before noon -  so I would have made all meetings take place in the afternoon.  Also I prefer coding early in the morning - starting at 6 am if possible - so I would have arranged for programmers to have greater freedom in their work hours during non-critical times."

Now that's useful information to an interviewer.

Lou
Thursday, April 10, 2003

Actually, Lou, I'm afraid I disagree.  If I ask someone in a job interview what they disliked about their last job and they complain that the refrigerator smelled like fish, that tells me a lot about them right there.

In my opinion, an interview should focus on gauging the applicant's skills and personality.  Any question can improve the interviewer's knowledge about the applicant, and each interviewer should have his or her own way of doing that.  I don't think we can find an optimal set of questions, or a question that wouldn't be applicable in any interview.

Brent P. Newhall
Thursday, April 10, 2003

"Actually, Lou, I'm afraid I disagree.  If I ask someone in a job interview what they disliked about their last job and they complain that the refrigerator smelled like fish, that tells me a lot about them right there."

That they don't like the smell of fish?

choppy
Thursday, April 10, 2003

"What questions would you ask in an interview?" is getting to sound an awful lot like "What is the one true editor?"  -- it's a matter of style and context, both of which thankfully resist easy categorization.

Chris Winters
Thursday, April 10, 2003

choppy:  Heh.  Seriously, it tells me that the applicant's not interested in answering the question I asked; obviously, I don't care if their last employer's refrigerator stank.  But the applicant apparently doesn't care about my interests.

That impression is based on no other information about the applicant.  It could be that the applicant can't find anything bad to say and mentions the stinking refrigerator as a joke.  It sure doesn't sound like it.

The point is, as Chris wrote, interviewing is a matter of style and context.

Brent P. Newhall
Thursday, April 10, 2003

At one interview at a company that considers itself highly, the sprat doing the interview came to his Big Questions: "Now, tell me," he says, "what does the button at the left of ... do?"

I was stumped. "It's the wizard, of course," he said, and I could see he was pretty impressed with himself.

I thought we were going to start bagging wizards and joined in. Good joke. I started laughing.

It wasn't a joke. Boy genius used the wizard to do all his C++ code. I didn't get the job.

.
Thursday, April 10, 2003

>"If you were suddenly the manager at your last job what would you have done differently to make the programmers lives better?" 

"I find it very useful to not have any interruptions before noon -  so I would have made all meetings take place in the afternoon.  Also I prefer coding early in the morning - starting at 6 am if possible - so I would have arranged for programmers to have greater freedom in their work hours during non-critical times."<

So, you would hire this person? Personally I wouldn't. For one thing he qould quickly lose the trust of his developers if, simply because he doesn't like something (e.g. having interruptions before noon) he makes all meetings take place in the afternoon. Particularly if the developers have been working since 6am. (You know that the easiest way to get a decision through is to hold a meeting on Friday afternoon, right?)


Friday, April 11, 2003

A fixed, general question set has two dangers:
1) Can't be tuned to a given position and set of claimed skills on the resume
2) If you are cool enough, keys will circulate.

Technical interviews are easy.  Pick something off of their resume that they claim to know and you know and get down to brass tacks, especially if it is a buzzword technology like .NET or Java or C++.

flamebait sr.
Friday, April 11, 2003

*  Recent Topics

*  Fog Creek Home