Interview Techniques

Interview Techniques… you are probably wondering what that has to do with technology.  This is partly to do with technology, partly a way for me to remember these, and partly, well, a ramble as usual.  I have been exposed to some simple interview techniques for “software engineering” positions and they are worth remembering.  These have come in a variety of difficulties, so I will attempt to organize them as such.

First, technology!  See Mike Code, is cool.  It is a way an interviewer can ask simple questions over the phone and see the person write the code.  That gets a darn cool in my book.  Perhaps it is as modern as VHS is these days, but who says a technology needs to be on the order of Star Trek to warrant recognition?

Also, I recently found this:  It is excellent for automatically formatting HTML/XML and code for posting in a blog.

Beyond the technology is the questions I have either been asked or found in my own prowling around.  These are thing ones I find to be the most interesting.

Practical Questions:

  • fizz-buzz, written in any language — basically, for some multiplier of a loop print “fizz”, for a different multiplier write “buzz”.  For a multiplier equal to one divisible by A and B, write “fizzbuzz”.
  • given two lists (e.g., friends lists), and assuming list-2 represents changes affected upon list-1, who was added, who was removed, who is the same.  Written in any language.
  • Extend a standard Java class (e.g., HashMap) such that it meets new constraints such as, and using HashMap as an example:
    • limit the number of values that can be stored popping off the oldest when a newer one is inserted
    • disallow overwriting an existing key; key/value must be removed first
    • lock the list if three unsuccessful attempts are made to retrieve a value
    • lock the list if three unsuccessful attempts are make to insert a value (e.g., inserting an existing key)
  • web application to retrieve basic statistics from somewhere like flickr, using web app technology of choice

Conceptual Questions:

  • What information should a bug tracking system have?  How should it be stored?
  • What project did you make the most difference on?  What did you learn?  What would you do differently?
  • Create an interface from a legacy system to a newer UI.  Assume an API or web service exists.  Describe the architecture you would use; describe high-level design considerations; define milestones.
  • A database has been demonstrating progressively degrading performance (either via an application or reports).  What diagnostic steps would you take?

Mean Questions:

  • I file lists like this as mean because they contain a lot of questions that either a person knows from practical use, or can look up.  To put someone on-the-spot to answer deep details like this in an interview is merely a test in making the interviewee squirm.  To me, these questions are a lot like asking a mechanic about metallurgy — while they use metal in their daily work, but they don’t need to know the minute details about the metals they use to get their job done or do their job well.

About John

I write about technology interests, cooking, and my own writing (sci-fi and fantasy... sometimes both). I try to keep things light, but sometimes I get side-tracked on an issue that I feel strongly about. No offense is meant, I'm just like any other person who feels strongly about something when I write. View all posts by John

Comments are disabled.

%d bloggers like this: