Fog Creek Software
Discussion Board

Interview Questions

I was wondering what types of interview questions (specifically coding questions) people use for Visual Basic programmers or even Java programmers?

For example, on this site Joel has mentioned using strrev or atoi as an interview question for a C++ programming.  Since VB and Java don't have pointers, these don't really have any context to them.  So what type of programming question would I ask a VB programmer?

I'm thinking - insert a node into a link list (beginning, end, and middle), bubble sort an array, etc.  Those can be done with references.

Any other suggestions?

Hopefully I'm not coming off as a language bigot :-)  For a future product we don't need C++, but I don't want to hire people that don't "pass" a coding test.


Justin Rudd
Monday, November 26, 2001

I think that with VB programmers its good to explore knowledge of OO features, ask them to work with collections and classes etc. I usually ask somebody to describe populating a collection with data from a database and using it to perform some task. Its interesting to note the structures that people come up with, how they initialise an object etc. Its usually fairly obvious the depth and experience they have had with the OO stuff. Most people who have been working with it for a while tend to have fairly structured recognizable ways of doing things. There are, of course, lots of different questions to ask but I always include something along the above lines.

Tony McConnell
Tuesday, November 27, 2001

We usually give them a machine, a small spec and tell them to get on it with it.
The typical problem we give is to read in a text file, perform some manipulation then print it out.
Typically the text file is a simple file something like this:
H 110001 ACC01
I 110001 001000 PRODA 1 1.99
I 110001 002000 PRODB 3 1.99
H 110005 ACC02
I 110005 001000 PRODA 1 1.99
I 110005 002000 PRODC 3 2.99
Representing some order headers and some order items. I suppose ideally you'd expect some to implement this as a collection of order classes each with a collection of order items, plus some methods and properties.
It's not a bad test and typically we'd give folks around an hour or two for this.
Good ones usually get around to doing some data validation at the same time and the truly good cope with out of order text files (Or put out an error message at that point).

When I did embedded systems I used to use:

"Hand compile the following C code to assembler, DO NOT ATTEMPT TO OPTIMISE THIS, assume the C Compiler is very stupid"

void test_func(int a)

{ int b;
  printf ("%d squared is %d\n",a,b);

For embedded systems this is quite a good test as it shows if the person has ever debugged C code at the assembler level, since it requires knowledge of what a stack frame is and what order C parameters go on the stack. (Actually the sample code was a little more complicated to try and force folks to use a stack frame)

Peter Ibbotson
Tuesday, November 27, 2001

Another thing that was done to me once was that I was given a piece of code to review (complete with bugs easy and hard) and asked to defend my review. The person interviewing then disagreed with some of my review issues and put some pressure on me to defend my position. This takes a bit of pressure off the interviewee, I think, giving them something to work with rather than having to create something themselves in an interview situation. Its fairly easy to tell from a persons review where they are "at".

Tony McConnell
Wednesday, November 28, 2001

a good question to ask might be:

"imagine you had to interview someone for an engineering position - what questions would you ask them?"


callum prentice
Tuesday, December 4, 2001

I've interviewed quite a few people for an Application Architect position at an NYC-based eBusiness company I was consulting for. The project was J2EE (no EJBs), with several 3rd party frameworks (commercial as well as proprietary). Here are some of my favorite questions: "What is polymorphism?", "What is a layered architecture and why would you use it?", "What is double dispatching?".

Dragos Manolescu
Wednesday, December 5, 2001

Just discovered this guy. He's the sort of MS man-with-the-answers I have tought time enduring. Let me get that out of the way.

Can think of few things more pointless than interviewing programmers about syntax and functions. Sank myself once by hiring two guys who handled even really obscure questions well, but who then mucked around for weeks putting a GUI together. BTW, how the hell would writing code in an interview have helped me detect THIS problem?

Seems to me that J's article about a programmer forgetting everything on vacation also applies to interviews. If a really good programmer takes a really good vacation, he's going to give a REALLY BAD interview, especially if he knows  20 languages (like me) instead of one. Think about it for a minute--the two principles are self contradictory. It's  easier to generate profound-sounding opinions than it is to reconcile them.

He gives himself an out by claiming that it's better not to hire a good programmer than to hire a bad one. Well, yeah, but not by much. The real trick, and the only point, is to hire the good one. Bad ones? Just ditch 'em.

The real solution to protecting yourself from bad code is good management of programmers and good code reviews. Programming ain't that hard, guys. It's the supervision and direction of talent that's demanding. Good programmers are defeated by bad management every time. But good management bouys up mediocre programmers and makes them good ones.

If you can't smell a real resume a mile away, you should get out of the business of hiring programmers. Start a training company and teach people syntax. It will keep you from bothering people who do this for a living.

Thursday, December 13, 2001


Saturday, December 14, 2002

  What questions should i ask if i have to interview a person for J2EE.


Thursday, February 6, 2003

*  Recent Topics

*  Fog Creek Home