Computer Science questions during interview?

Question

What do you think about purely CS knowledge questions during the interview? What I mean is:

• Data structures (stacks, queues, lists, trees)
• Algorithms (sorting, search, shortest path, data compression)
• Recursion, etc.

Unless you have some specific need (search engine implementation, low level no-framework programming), I am struggling to see the value of questions like that. I feel like "fresh" college grads would answer questions like that easier than some experienced software engineer, who's last time implementing any type of array sort was 10 years ago in college.

Answer 1

I have learned that no matter what the line of questioning, the only real way to know if someone knows something is to have them write code. Since we started adding a coding exercise to the interview process, we have seen multiple times where someone might be able to give a textbook answer, but fail to implement it correctly or at all.

Definitely ask questions to determine how a person thinks on their feet and that they "speak the language" (pun intended). There is no harm in asking theory questions, or even basic course-type questions - just do not put all your eggs in one basket.

Answer 2

Data structures and recursion, yes; obscure algorithms, no.

Better yet, give them some of your buggy code to debug!

Answer 3

Lets divide this into 2 questions

1. Sorting questions
2. Everything else

I don't know of anyone who asks "Write sort X" during an interview. If I were ever asked it during an interview I would really re-consider why I was applying for a specific job. if you want a good sort algorithm, look it up (really though, just use a builtin framework one).

I do occassionally ask for trade offs on various sorting techniques. But it's a sub-question and I don't really care if people know the various algorithmn names.

Now for the rest of the questions. CS, educational and professional, is all about data structures and algorithmns. If you made it through college without knowing what a binary tree, stack or queue was, I likely don't want you working with me.

While I don't ask data structure questions directly, I find it valuable to ask indirect questions. Instead of asking "build a binary tree", I would ask "given a binary tree do X". I want to see how an interviewee can apply their pure CS knowledge to real problems.

Answer 4

I have had many years of successful hiring of developers by not focusing so much on the CS knowledge, but I do tend to ask how a candidate would go about solving a specific problem where a commonly known data structure, pattern or algorithm would easily be used to solve the problem. If the candidate knows enough to call a specific list a stack, or describes the workings of a trie or binary tree as part of their answer then they score higher. Part of being a member of the team includes the ability to describe what the programmer is doing or about to do, in addition to the ability to solve problems.

Answer 5

Steve Yegge and Joel Spolsky have made some great blog posts about programming interview questions you might want to read through when you have time. They both seem to be heavy into the computer science questions and harder interviews.

Steve Yegge on phone screening questions

http://steve.yegge.googlepages.com/five-essential-phone-screen-questions

Joel Spolsky on interviewing

http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html

Answer 6

I just read Joel's book about hiring developers, Smart and Gets Things Done. In it, among many other thoughtful ideas, Joel talks about asking the hard technical questions.

One thing that caught my eye, and I do think this is related to your question, is that Joel says he likes to ask people about pointers to see if they have the ability to think abstractly.

He admits that many developers no longer need to work with pointers... Ever. But Joel thinks there are some people who will never get that lightbulb moment on this subject, and those people are not the top developers that he wants to hire. And as you may know, he advocates only going after the very best.

So for me, that's the type of data I'm after. Unless you're writing a search engine or something, I would try to get at that data without grilling people too hard on pathfinding. :)

If you intend to do some dev hiring, I highly recommend that you check out that book. It's a quick read and it definitely made me re-think some things.

Answer 7

I'm currently finishing a PhD in Software engineering, I have two master degrees (one in CS, one in SE), and a prior BS in CS, and it still infuriates me that when I am interviewing for non-entry-level engineering jobs I still get the same questions that I teach my students in CS courses, and that I was sked 10 years ago when I was interviewing for my first jobs. By now, by the way, everyone knows all these questions and there are sites like AceTheInterview that give candidates most things that you could ask.

If the job really has to do with algorithms and optimization, go ahead and focus on them, but be aware that you may be weeding out very good designers. It's one of the reasons we have so much efficient but broken code.

I cannot tell you how many students I have taught who were brilliant in classic CS but had zero instincts when it came to designing, encapsulating, etc. As employees, they'll do amazing jobs optimizing specific functions, but you'll be paying for it by having a lot of unmaintainable code.

If what you really need is a good designer or developer who'll be using standard libraries for most things, focus on those things. Especially if you want said person to be doing OOP work for your company. Find out if they understand inheritance, interfaces and dynamic binding, for example. You can ask a few classic CS questions to make sure they got that part covered.

Answer 8

I tend to ask questions that relate to the projects that I expect that people will be working on. Generally, I'm interested, not in knowing if they can write a complete code sample off the top of their head, but if they are able to understand what I am asking, ask good questions to get more information, and understand the concepts. What I would ask would also depend on the level of the person I'm hiring. A more senior person would be expected to understand things like reflection, be familiar with design patterns and architecture, understand database design and normalization, and be able to explain different development methods and the differences between them. A more junior level person would be expected to know the difference between Map and List data structures and know when to use each, be able to explain cross-site scripting and SQL injection attacks and how to avoid them, and be able to read and explain some code and perhaps talk about its complexity. Since it is very important to how we work, I'd also ask them about testing, perhaps explain how they unit test their code.

Mostly what I am interested in is how well the person will fit with our organization. Are they technically curious and willing to learn. Have they demonstrated this in the past? If they run up against something in the interview are they willing to ask questions or do they try to bluff their way through it (note: I always emphasize when giving a "code" problem, that if they have questions they should ask. I don't expect people to know or remember everything, esp. things that you can always look up). I also tell them that I'm not particularly concerned with framework details or exact syntax and to not worry about that.

The other thing that is critical is how well do they communicate. Can they understand what I am saying? Are they able to articulate their solution so I can understand it?

I am concerned about the fundamentals that people have from a CS point of view, but I've found that it is usually more apparent from how they handle real problems whether they have been able to translate theoretical knowledge to practical abilities. Pretty much anything they have learned (or should have learned) in school can be looked up for details. The question is whether they have internalized it and can put it to use in a real setting.

Answer 9

Depending on how good the company is (i mean there are companies that just "hire")

A big one is questions about design patterns, for instance MVC, singleton, etc. Which ones would you use and why, etc etc..

of if its for a SE position they would probably ask methods for doing your product, the strategies, etc.

Stacks, queues, don't think would matter much. Knowing design patterns really well is sufficient. Honestly they are harder to know than simple data structs.

Answer 10

The only interview approach I've seen consistently get good results is to sit down and do some real work with the person for a day at least. Sadly a lot of people aren't available for a couple days worth of trial contracting.

I've seen mixed results with CS questions in interviews. I think asking specific rote knowledge CS questions is a poor approach in most cases. I don't care if you know how to implement radix sort since on the job you'll be able to look that up in reference.

What I do care about is how good you are at understanding and solving problems, and intro to CS style questions may be effective at showing this. I stress the may. I saw someone crash and burn pretty hard in an interview discussion about searching through quad-trees... however I've seen and heard about his work through friends in the years since and know that he would have been a solid developer for that job.

Personally I like questions similar to Ruby Quiz, Perl Quiz of the week, etc. They may be toy problems, but they at least let you see someone work through a problem and communicate with you about it. Having the candidate do a code review can be good too.

Finally, I think it's important to remember there's no sure bets when it comes to interview techniques. The worst is when the evaluator is totally unfamiliar with the subject area (ie HR drone) and uses artificial questions that the candidate may not happen to be familiar with. But even when it's a peer interview people get nervous or otherwise don't show their best ability. Likewise the evaluator may not be that experienced in interviewing and reaches for silly questions to just find any way to differentiate the candidates.

It pays for everyone sitting at the interview table to remember how stressful a situation it can be and patiently give people some support to show their best. It may feel satisfying to have a tough or demanding attitude, but I doubt it actually gets you great co-workers.