The Implementation of Hash Maps and Interview Madness

I recently had a telephone interview for a Java position which was going well until they asked the first technical question – “How do you implement a hash map?”

My first thought was that it was a very mean question to ask a Java applicant as you never need to implement your own hash map, rather using Java’s implementation of a HashMap.  My second thought was “Whooopeee – I’ve done this stuff in a C++ module at Uni a few years back”.  I then launched into a rambling explanation of hash functions and ways to deal with collisions.  I wasn’t prepared for that question and the fact I was trying to dredge up memories from a few years ago left me less coherent than I would like.  The voices at the other end of the telephone seemed a little confused and after a couple more questions about my answer, I finally gave up and asked them what they were looking for.  Their answer: a collection of key value pairs.

Well, yup – that’s what a hash map is and if they had asked for a definition, that is what I would have provided.  While they thought they were sliding into the interview the easy way, I had jumped into the technical deep end and splashed around until ultimately drowning on the easiest of questions…

Which leads me straight into one of my pet hates – technical vocabulary!  The amount of technical jargon that is thrown around in interviews is astounding, yet so often the terms are really general whilst the person using it is thinking of something specific.  One example that springs to mind is “Agile” – a term used to describe a group of different software methodologies, yet you can be sure the person using it is thinking purely of the methodology they use.  Half the time people aren’t even using the terms correctly anyway.

I once went for an interview and was immediately given a 22 page technical quiz to complete.  One page consisted purely of acronyms that I had to expand (Oh wow, I know what JMS stands for, I must be a real good programmer).  The rest of the questions consisted mainly of definitions and other “book knowledge” questions.  I was really disappointed not to find a single question where you had to think about a problem and solve it (even in pseudocode).  To make things even better, I could hear the interviewer & friend talking about me just outside the paper thin walls of the interview room.  I was ready to walk out of there right then but for the sake of politeness (and pride – I didn’t want them to think their quiz had got the better of me), I completed the interview.

This last interview has helped me realise I am sabotaging myself.  I am so nervous during the interview that I am always looking for the trick or diving into the technical deep end without covering the Oh-Duh! stuff, which just might happen to be what they are looking for.  I can clearly imagine the discussion on my last interview “Oh my word! She didn’t even know what a HashMap was! …And she calls herself a developer! *tut.tut* …the candidates these days!”

[Via http://geekrambles.wordpress.com]