Interview Questions

[11jmb]

I'm curious what members of this forum would ask during an interview.

You have a very short amount of time to figure out if a potential hire is a good match for your program (in terms of aptitude and technical interests). What would you ask?

Full Disclosure: Be honest about how senior you are on your program. I don't want to exclude newbies from this thread . I'm interested in responses from people who may have a recent interview experience fresh in their minds, and of course I want to hear from people who regularly conduct interviews. I'd like to make an easy distinction between these two groups.

Also, quickly explain your problem space, as this might drastically affect the content of your questions.

[Barrucadu]

Two questions I was asked in my interviews for a Google internship (which I alas didn't get) were "I type www.google.com in my browser and press enter. What happens?" and "Write a function to convert Roman numerals into normal numbers, and vice versa."

In my university interview I was asked to swap two integer values without using a third temporary one, although that's quite easy.

[CptPicard]

I'm trying to get more into doing interviewing at where I work, and so far it seems like my superiors have liked what they've seen when I handle the technical side of the interview. The firm is a software house that mostly sells project work to clients, and the applications are mostly web-based. The scope of the projects ranges between simple Rails db apps to big J2EE business/IT infrastructure systems.

I'm not too keen on using batteries of questions like Roman numeral parsing or detail-oriented questions about APIs or languages... the fact of the matter is that a person can acceptably fail a lot of those, and in many cases I'm cool with the idea that you just look up stuff you don't know yet. For example, at our firm we often need to know Hibernate, and thus I'd mostly hope they've read "Java Persistence with Hibernate" and know which chapter to look into for the details.

However, technology questions are a good way to use to weed out people who simply don't have a clue. In this case the question will have to be pretty obvious for anyone with any experience, but failing it or multiple of the sort will almost surely mean the person is not the right guy for the job. The questions can be surprisingly trivial... "what does Java's static do? What is a .war file? If I give you the Javascript function foo() { x = 5; }, what is the scope of x?"

Next, I try to probe the person's background and in particular his level of enthusiasm for and internalization of programming. Here it helps to just be very open-ended. I let him talk about things he's done, what he finds interesting and why. Here the point is to let him give me something to latch on to so that I can probe that a bit further to see if this is just all superficial or if there's something deeper there. I might actually ask some technology-related question that he should know, based on whath he says he's done. Or maybe I'll ask him how he feels of the implementation choices of some framework or something. There is no right answer necessarily, I want the person to just demonstrate there's some thinking going on regarding this.

IMO after sitting down for some 30 minutes with a person I just get the impression if the person has the right attitude and background and is able to learn as he goes. If there's too much "umm I dunno" going on, then I'm not very impressed. If he's just blabbering nonsense, that's easy to catch as well, I'm able to give them enough rope to hang themselves with.

[11jmb]

I've been with the same job for ~5 years now, with 2 years at a prior job and an internship before that. I conduct interviews regularly, and get to weigh my opinion, but I don't make any final decisions on hiring.

I try not to ask too many direct technical questions, because I only have 30 mins to an hour, so anything that can be solved in that time frame would have to be trivial. I'm certainly not fond of asking anything that can be looked up in a matter of minutes

In my (admittedly short) experience, the best way to figure out if somebody is a good fit is simply to discuss prior projects. You benefit from this in many ways. First, you can ask technical questions as they arise. Second, you may not be able to see it happen right in front of you, but you can get a good idea of how the candidate solves hard problems. Finally, you can get hints to the candidate's passion in the area. People who are truly interested will become noticeably excited: sitting upright, talking faster, etc.

A job interview is a two-way screening process, and I don't waste time actively making a sales pitch. Ideally, the candidate would have already asked me some technical questions about what I do and perhaps some of the problems I work on, but I never hold it against a candidate for being shy or nervous. If I must, I will ask (towards the end of the interview) if the candidate has any questions for me, and I'm not expecting "Where did you find that tie?"

[CptPicard]

Looks like we've got a similar approach.

My own interviews when I was applying for my current job were interesting; I was to begin with perhaps a bit too academic with my algorithmics degree (I've seen a couple of people get politely shown the door at the end of trial period that had the same education, they just can't code). In addition my work history in the field was a bit questionable, although I certainly had been pushing millions of euros a year of other people's money through a betting system built my me.

Anyway, I guess I was so enthusiastic about my former project that the business side guys liked me... besides our lead architect is a Lisp hacker so we definitely connected there. It helped that I could recount details of Java frameworks that I had been dabbling in since the late 90s. I would personally admit to being partial to Lispers and connoisseurs of more esoteric programming paradigms -- as long as I can trust they also already have sufficient practical skills. Generalists are quicker learners of new things, I would assume, as they can associate the new stuff to the things they already know.

[11jmb]

I see nothing wrong with being academic as long as you stay grounded in reality I've worked with a couple PhD's who not only had a huge wealth of theoretical knowledge, but were also able to apply it to the problem at hand. I've also encountered a few PhD's who were completely worthless in industry and belonged in a university (I don't mean offense; some people are cut out for academia while others are cut out for industry). The best hackers I've met are good computer scientists, great software engineers, AND they understand when to apply which mindset.

I wouldn't say that I'm particularly fond of people who enjoy esoteric languages/paradigms for the sake of esotericism, but many of these paradigms have indirect practical applications. For example, I'm a believer to some extent in the "people who understand lisp write lisp in every language" idea. Anybody who understands how Haskell/Lua/PetLanguageX can help me write better C or Python (just about the only 2 languages I use these days) is alright in my book.

[ofnuts]

I tend to agree with this guy (warning: strong language).

[Bachstelze]

I tend to agree with this guy (warning: strong language).

I plan to avoid industry like the plague so it's not really relevant to me, but I mostly agree too.

[the042011]

Hi,
I feel like I might need to brush up on my planning knowledge just in case someone actually calls for an interview!

I found some references on this subject, please refer to everyone here: Dell interview questions

Best regards.