Shaking off some job interview rustiness

Introduction - looking for a new challenge is a full time occupation
Having a long term secure job is great, but in general the longer that you are away from the process of looking for a new role, the less well prepared you will be for interviewing for the next one.  Please don't take that as an indication that you should hand in your notice for the sake of it, but read on to learn from some of my experiences.

I find the whole process of looking for a new job to be quite a strange situation.  Most people that I have worked with somehow find ways of arranging interviews and accepting an offer while they are still actively employed.

I don't like the awkwardness of sneaking around and being economical with the truth - not lying, but not giving a full explanation. So whenever I have come to the decision that it is time for me to change jobs I have resigned, served my notice period including all the appropriate knowledge transfer, and then gone to look for an appropriate company to work for next.

Fortunately in London there are many companies that have a technology team that needs someone with my skills and experience, so I have been able to afford to not ace every interview first time.  What follows is a bit of self-analysis of my most recent experiences of being back on the job hunt in 2019.

First interview - brain fade
I did my early interview preparaton no favours by taking a relaxing holiday for six weeks or so without touching a single line of code.  Don't get me wrong, it was great to unwind and take some deep breaths and be away from thinking about the ins and outs of the product that I had been working on for the last year and a half.  I just didn't appreciate that even twenty years of commercial experience isn't enough to be ready to churn out code at the drop of a hat.

You come to realise just how much you rely on the code completion features of an IDE when you try to jot down a technical solution on a piece of paper.  String.charAt has been around forever, but it just escaped my memory when I needed it most.  So I found myself going back to first principles and introducing an unnecessary array copy of the underlying characters.  🤦

Second interview - time management
For the second company that I interviewed at I made sure that I had dabbled with some code to solve some common types of low level exercises, then proceeded to make an entirely different type of mistake when it came to the interview.  I didn't think enough about the time limit when I came to introduce myself, so ended up giving a five minute speech about my background when a thirty second high level description would have been perfectly sufficient.

Sure enough my technical solution became a little rushed, so instead of reaching for the modern obvious implementation approach of applying streams and lambdas I went back to first principles and applied a simple for loop - making it seem as though I wasn't familiar enough with some of the most widely used Java 8 functionality - despite having used that for over five years.

When it came to a whiteboarding session I was fine for describing how the solution that I had fully designed and implemented worked, but didn't pick up on the different nature of the company that I was interviewing at and the types of challenges that they have had to overcome.  My main takeaway from this shortcoming was to look outside of the industry that I have been working in.  Check out the various videos available on Youtube where vendors and other businesses describe their approach and the solutions that they produce.

During the third hour of the interview process I faced another group of people, this time probing my personality, attitude, and experiences of different cultures and situations.  In the process of producing this blog post I have thought of an answer to one of their more peculiar questions - something that I have learnt from people I work alongside that came as an "aha" moment that I might not have considered before: Colleagues in the US generally get their medical cover through their employer, so it would be a major risk for them to leave their job without having another one lined up to go to.

For some of the more general, "Can you think of a time when..." situational questions I didn't have much of a response.  Sometimes I feel fortunate that I haven't felt like I have worked in particularly stressful projects, but unfortunately this line of interview questioning doesn't seem to believe that's possible.

Third interview - getting better technically, just not enough emphasis on end users
I really appreciated having a thorough interview feedback call from the company's in house recruiter recently.  The fact that most of it was positive and constructive is making me feel more confident that I am getting better at preparing for interviews and being able to present my thoughts to strangers.  Even though I found myself apologising for being flustered and repeating the same introductory wording (so self conscious about repetition...) the tech interviewers expressed that they were pleased that I had managed to come around to a suitable workable solution to the hypothetical scenario that they had raised.

This particular interview had a slightly unorthodox format of including a product focus stage where other companies have a more general behavioural / soft skills stage.  Here I didn't strike the right balance between refering to more recent projects versus projects that involved developing functionality for end users.  Having spent the better part of a year largely self-managing migrating an internal framework and its associated libraries doesn't offer much to talk about when it comes to requirements and compromises and team dynamics.

Onwards and upwards
I was tempted to consider an offer to go to work at the third company that I interviewed at, but the lower pay rate range that they were suggesting would have been too much of a step down from what I know I am worth.  I also had a couple of reservations about the approach that they have taken with their microservices, so I will leave those challenges for others to face.

In the next week or so I expect to be attending interviews at a few more companies that I have applied to.  My confidence in my technical and social abilities remains high, and my preparedness for the interview processes has grown considerably.

Interview preparation

I had a mental blank while attempting to jot down some code for solving a problem on paper during a recent job interview.  Less than a minute after leaving the interview I remembered the name of a method that I should have been using instead of my clunky array manipulation.  I put the experience down to a combination of being so reliant on IDE code completion, and not having written much code for a couple of months while I have been unwinding on holiday.

Alas, even my depth of knowledge on changes to HashMap’s implementation (List gets replaced by tree when 8 elements fall under the same bucket since Java 8) did not balance out for that particular glitch.

Oh well, it was always going to be unlikely to ace the first interview after a four year break.

Preparing for interviews versus skating to where the puck is going to be

"I skate to where the puck is going to be, not to where it has been." - Wayne Gretsky

I'm in the process of seeking out a new challenge in my career (no need to whisper - I've left my previous job on good terms and taken a nice long holiday - so I'm not sneaking around to speak to recruiters during work time).

While updating my CV I have been quite aware that once again I find myself without professional experience of the latest popular technology in my sector - Kubernetes ... and maybe Kafka.

It's very tempting to go away and complete a full-on course to fill in the gaps, but I've been in the industry for long enough to appreciate that there's still a reasonable chance that my next role might not include those technologies anyway.

So, for now I'll just have to find the right balance of revising what I already know, and reading about and watching videos about enough to be able to carry my end of a conversation.