Category Archives: Interview advice and preparation

Top 5 Things To Get Ready For Your Job Search: NUMBER ONE, Work Out What You Want To Do

Whether you’ve got a job right now and you’re looking to take your next career move, or whether you’re beginning your search from a standing start, here are my top 5 things that are going to help you get ready to begin your search.

Getting ready

This is aimed at software engineers looking for a permanent position (PAYE), most of the things I’m talking about will be applicable to day-rate contractors, but not 100%:

NUMBER ONE: Work Out What You Want To Do

As anyone who’s recently finished looking for a new job will tell you, it doesn’t take many conversations to work out that you actually need to have a really good understanding of what you want to do next before you start to talking to anyone.

The key point here is that for the hiring managers the interview process is all about risk. Working out which candidates are going to be worth interviewing from their CVs is an obvious example (which candidates looks like they’re least likely to be a waste of time interviewing). But for the hiring manager it isn’t just the time spent on the initial search for the right candidate, what’s also at stake is the huge amount of time that stands to be wasted if the candidate they hire never really wanted the job in the first place. If the successful candidate goes on to leave after the first couple of months, then that’s potentially hundreds of hours of time wasted, involving training, mentoring, showing them around the company, including them in future plans, wasting the hiring manager’s time, their colleague’s time, their team’s time, their boss’s time…, reputational damage, their judgement and competency questioned, a huge amount of budget potentially wasted, IP at risk, etc, etc, etc.

Which means that during an interview when you’re asked “what kind of job are you looking for” or “what are the main things you want to get from your next job”, you’re going to want to have worked this out already. Because the man who walks into an orange fruit shop and starts talking about other fruit they’ve had in the past that they liked, and “that they really don’t mind what kind of fruit they buy because they’re just hungry”, or even that “actually their most favourite kind of fruit they ever had was an apple, but as they’re here now they’re happy to consider oranges”, isn’t going to go down as well as the man who confidently tells the shop keeper “I’m an orange-kind of guy. I like oranges and I’m here to buy oranges.”

So, going into the job market armed with nothing more than a bunch of vague ideas about what you kind of job you’d like to have is not going to help you.

Operational Hypothesis vs Re-iterating

Have a good think about it, talk it over with someone else, and then be comfortable with the idea that you’re probably going to refine your idea of what you’re looking for after you’ve started your search, but time spent working it out before you begin will be time well spent.

Some Food For Thought:

To help get the brain juices flowing, here are some ideas. You could say a Software Engineer can go in 1 of 3 general directions with their career:

  1. Team Management
  2. Sales and Product
  3. Architecture / Technical SME.

Here is a simple list of the main factors that Software Engineers’ tell me they’re looking for:

  • How much time you want to spend hands-on coding? Do you just want to code, or do you want to be paid for other things as well (design, architecture, requirements gathering, scrum mastering, stakeholder facing, client facing, deployment, support, testing, code reviews, people management, project management, etc)?
  • What size of company do you want to work for? A big corporate? A mid-tier company? A start-up? A small company?
  • Would you discount a company that had lots of problems, or would you see that as an appealing factor?
  • Does it matter if the team is all located in the same office or is spread around the world?
  • Are you looking for technical authority?
  • Is formal training and investment important to you?
  • Is any the “package” element of the job important to you (pension contributions, medical insurance, nice office, flexible working hours, working from home, lots of colleagues etc)
  • What kind of office locations you want to commute to / are you prepared to get to?
  • Is a new (“greenfield”) application important to you?
  • Is working with the latest and greatest tools and technologies important to you?
  • Do you have some kind of preference for the people you work with (senior to you so you can learn from them, same age as you so can easily get along, etc)?
  • What kind of industry/industries do you want to work in? Does it matter to you?
  • Is it important that the application you work on is something you find exciting or high profile?
  • Do you want to work for a well-known company?
Advertisement

Why are Algorithms such a popular test for a developer’s skills?

In my experience, although there are lots of different ways of assessing a developer’s technical ability (from verbal technical interviews, to logical and numerical tests to the dreaded “paper and pen” exercises) most technical interviews fall into broadly one of two schools of thought: either ask them to complete an exercise which requires solving a real-life business problem, or ask them to solve written-for-purpose puzzles by writing algorithms.

 

THE EXERCISE-BASED CAMP

The exercise-based camp always made sense to me, apart from the common trap that the hiring manager who writes the exercise basically writing a test that says “can you guess how I think” and then marking the result on how close they got to their own solution, it’s a clear indicator of what a programmer’s development skills might be on the job. Does it solve the challenge? Did they complete their solution? Does they solution make sense? Is it elegantly written in the development language of choice? Is it extendable / documented / follows TDD / etc etc? Naturally coding in the time sensitive, pressured environment of an interview doesn’t suit everyone, but it is unarguably a rock solid example of what the candidate can actually do.

 

THE ALGORITHM-BASED CAMP

And for years the algorithm test camp has puzzled me. Algorithms are often written in the main language that the job requires skills in (write your algorithm in Java if it’s a Java developer role), but sometimes answers can be written in pseudo-code and that’s just as acceptable – which seems counter-intuitive. Often when my candidates fail the algorithm writing part of the interview and are “no’ed”, they tell me that they were asked to write a kind of sorting algorithm that they hadn’t looked at since their university days (typical example is a Bubble Sort) and their mind goes blank. Which seems unfair.

bubble sort

A better gauge of your coding skills than anything you write in an IDE.

 

And I can’t help but wonder how easy it is to game algorithm-based technical tests. Many developers who are actively looking for a new position know they’ll come up against algorithmic challenges to complete during the interview process and I wonder to what extent you can simply train yourself to become “good” at solving the most commonly ask kinds of question. I know for a fact that I’ve seen some very good developers dismissed for developer jobs they were good fits for, completely out of hand after failing a algorithm test. And I’ve then seen the same developer go on to successfully complete algorithm based challenges and get job offers after having practised solving challenges at home. I personally recommend codility.com as a great preparation tool to the developers I work with.

 

It’s also very rare that writing algorithms from scratch will be a part of s developer position’s day job, so my candidates are being tested on a skills they don’t need to have to be able to do the job they’re going for.

 

So with so many pitfalls, I began to ask my candidates and hiring managers why algorithms are so highly valued as an interview tool.

 

ALGORITHMS ARE A RELIABLE TEST

The first thing I learnt is that it the ability to write an algorithm is considered one of the few reliable tests of how good a developer is (despite concerns about “gaming”). The field of study to be a competent Java developer (or C# developer or [insert chosen language here] developer etc) is so deep its hard to actually come up with a reliable, catch-all test that doesn’t take hours and hours, in the absence of a better model, algorithms are a tried, tested and trusted way of assessing how good someone’s core development skills are. When asked about “gaming” algorithm writing tests, I’m told that most tests these days can be gamed, and that its up to the hiring manager to keep the exercises fresh. Which doesn’t sound like an unreasonable requirement!

merge_sort.png

Ahhh, the old “merge-sort two step”

ALGORITHMS ARE TIMELESS

New algorithmic challenges can be written, but the principles by which they are solved still rely on the same set of fundamental skills, its just the style of implementation that changes (hence the willingness of some hiring managers to accept answers written in pseudo-code). On the basis that development languages change over time, and dexterity with the latest tool or framework will probably soon be made redundant, a test of someone’s ability to solve an algorithmic-based challenge is kind of timeless.

 

EACH ALGORITHM IS A MINI-PROGRAM

Each algorithm-based challenge is good all round mini-test requiring the candidate to demonstrate the core concepts of software development:

  • Problem solving
  • Structuring the solution
  • Refactoring it
  • Testing it
  • Proving it
  • Optimising it if necessary

They’re all key skills required to be able to “code”.

 

AN ALGORITHM CAN BE WRITTEN COMPARATIVELY QUICKLY

Its common for developers to be set 1 algorithmic puzzle per 15 minutes, with taking up to 30 minutes to complete not being considered an automatic rejection.

 

So there you have it, for as long as a more reliable, less time-intensive form of testing a candidate’s development skills is unforthcoming, the algorithm-based technical test will continue to form a common stage of a developer’s interview.

 

Video: My HR Interview Advice

HR interviews can be a sticky wicket, but they’re easy to pass as long as you bear in mind a couple of simple facts and do a little preparation before hand. Here’s my explanation of the key points:

Martin Jee’s HR interview advice