Interview questions

Today I’ve seen a set of interview questions. What actually caught my eyes was the following question/task:

Write a yesterday function, based on the Calendar API.

I don’t really consider this question helpful. I mean it was helpful if you hired people for implementing some kind of scheduling engine (I can tell you, this was not the case. Of course there are situations when you have to touch things like that, but it usually happens like twice a year).

The problem with questions targeting APIs is that you cannot really draw conclusions based on the answers given to them. I am sure that there are several really great professionals I know, who could not write such a function on paper (and I was witness to that: somebody I consider good was only able to write the method with the help of Eclipse). I am also sure that we could find at least five terrible programmers who’d happen to be able to write that function. Does that mean that persons from the latter category are more valuable? Not by any means.

Why are we even giving people paper-based tests? Come on, this is the 21st century. Wouldn’t a pair programming session make more sense? So we could find out more about the person (interpersonal skills, openness, original ideas etc. I know, I know; we didn’t get into this industry to deal with people). Anyway, when was the last time had to write pieces of code full of API calls on paper? Yes, it happens that we scratch some idea on paper, but those are mainly pseudo-code based algorithms and not API calls (and let’s admit, these are rare occasions). I remember once I had to memorize the whole SAX – XML parsing mechanism (and by this I mean all the function calls) for an exam. That was one of the most pointless things I ever had to do; and of course I completely forgot the whole thing by the end of the week.

If I were to put a (paper-based) test together, here’s what I’d ask:

  1. Simple Java concepts: interfaces, abstract classes, inheritance, aggregation
  2. Common data structures (trees, maps, lists – not necessarily Collections Framework, but basics)
  3. Test related concepts: how could you test a specific method (no JUnit or NUnit API calls to be written)
  4. Given a spaghetti-method, refactor it
  5. Write a simple algorithm (like this one) – so we can see how good is their code
  6. Concepts regarding exception handling (checked vs unchecked, catching Throwables, finally blocks)
  7. Database concepts and simple SQL queries

Or even better, I’d organize the above-mentioned pair programming session. I’d pick a kata, and see how the “subject” performs. I wouldn’t need them to be perfect at refactoring, JUnit, JMock, just to see whether they get the point or not.

Who knows, maybe I can try it out one day 🙂

Author: tamasgyorfi

Senior software engineer, certified enterprise architect and certified Scrum master. Feel free to connect on Twitter: @tamasgyorfi

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s