Peter – Code for more

21 things to check before you submit your technical test

As a programmer and a recruiter, I tend to read my candidates’ take-home technical tests before submitting them. I’m pretty sure it’d be completely wrong to give anyone feedback on their completed tests before submitting them to my clients, so I’ve instead built-up non-specific pre-test advice over the years, which seems fair to send to candidates along with clients’ technical tests.

There’s a pretty limited amount that can be learned about a developer in an interview, and the interviewing developers generally don’t interview people for a living, so we want to try and avoid making one of their learning points that you’re sloppy or not especially conscientious.

If you follow through this checklist before submitting your technical test you’ll avoid at least some of the simply-fixed issues that I’ve seen arise over and over and over again in test submissions.

Packaging

1. Is your code packaged in the right format?

Double-check what you’ve been asked for. Is it a zip file? tgz? An upload to BitBucket? Is your code meant to be an installable library? If it’s a series of small tasks to complete, have you added a script that demonstrates they are completed?

2. Is your code sensibly named? Does it decompress sensibly?

Sensibly named is usually your-name-company-name-tech-test.tgz. Sensibly decompresses is generally (albeit language specific): “it unzips / untars into its own named directory” and not “it pollutes the current working directory with hundreds of files and directories”. If you’re submitting a repository, have you used a sensible branch name like master?

3. Have you removed random file detritus?

Is there anything you’ve included that a sensible .git-ignore would have stopped you committing? .DS_Store, ~myfile.js, myfile.c.swp? If you’re submitting a repository, are there random other branches that you shouldn’t be committing?

4. Have you removed any sample data that isn’t yours to include?

Incredibly, people do use their current company’s live database as a source for test data for technical tests at other companies. That’s bad, don’t do that. Make sure any sample data you include is either randomly generated or sensibly licensed, and don’t include other people’s personal information (including lists of email addresses)

4.1 Have you removed any code that wasn’t yours to include?

I don’t want to see your current workplace’s copyright notice in any code you’re submitting; it doesn’t matter if you claim you wrote most of it or “they’re just useful generic functions”. I’ve received far too many pieces of proprietary production from developer’s current workplaces when asking for sample code…

Contents / README.md

5. Have you documented what you completed and how?

Some tests will explicitly ask you for commentary on what you completed, what you didn’t complete, and thoughts on your implementation. If you’ve been asked for it, you should definitely include it. If you haven’t been asked for it, you should probably include it. What are the strengths and weaknesses of your approach? Are there other approaches you considered? What would you have done if you’d had more time?

6. Have you added installation / run instructions?

Don’t make the code reviewer think too hard. Add any instructions for installation and running the code that might be relevant, even if that starts with obvious things like `node install`. If it’s a web application + server, does it have a default bind port? What’s the local URL that the reviewer should go to to start? How can they run the tests? Do they need to initiate a test database? Is that easily done using copy-pasteable commands you’ve included?

7. Is your version history / commit log sensible?

If you’ve been asked to deliver your code by pushing it to a version control system, are you happy with the version control artifacts you’ve created? Will the contents of git log pass muster? How are your commit messages?

Tests

14. Did you write some tests?

There may be good reasons you haven’t included automated tests in your submitted code. “I didn’t have time” and “I couldn’t be bothered” are not good reasons

15. Do your tests pass? Do your tests pass without filling the screen with warnings?

Self-explanatory

16. Are your tests good examples of production code?

Testing code should be a first-class citizen. This means it should be documented, sensibly laid out, and easy to follow. Separating test data from the the test code that exercises it is usually a sensible starting strategy

17. Are you including tests you didn’t write, and if so, are they useful?

See point 8. A boiler-plate test that performs a useful function is fine. The example test script that your framework included (assert( true, "Hello world!")) is generally worthless

Implementation

18. Can you explain what every line of your code is doing?

Developers have a nasty habit of taking a cargo-cult approach to interacting with their tooling, especially given the all-encompassing knowledge available on StackOverflow.

If you’ve copied-and-pasted any part of your code from StackOverflow, or library documentation, or it was generated for you by your tooling, or your linter told you to do it a certain way, make sure you know what — and can explain what — it does.

19. Have you avoided “cutting edge approaches”?

Libraries and approaches the reviewer of your test hasn’t seen before are more likely to elicit a response of WTF? rather than admiration for your use of cutting-edge tooling. Unless you’re reasonably certain the company uses — or is likely familiar with — any exotic libraries or approaches, your technical test is not a great place to show off your familiarity with them. Using Cucumber for your test suite will usually be a rash choice unless you’re being asked to show off your BDD chops.

Your technical test is also not the place to demonstrate you know how to use arcane language techniques. It’s not the place to introduce a library that overhauls your language’s entire OO system that was released 2 weeks ago. Limit your tooling to tools you probably wouldn’t need to ask permission to introduce into production.

20. Is your code robust?

For example:

Is there user-provided input at some point? Is your code easily broken by bad input?
Does your code degrade nicely with edge-cases?
Can I pass untrusted inputs into your SQL?
Can the user create a security issue by passing you HTML or JavaScript where you expect something else?

Do you need to consider text encodings? Have you done so?

Strategy

21. Have you used the test to show off your best work, or did you rush through it?

Aim to do a portion of the test well, rather than desperately trying to complete the whole thing and running out of time. Well-presented, thought-out, commented and tested code that completes 3 of the 4 set tasks is often better received than the trappings of a new framework you’ve started building to solve all the problems they might ever encounter.

Most tests I’ve seen in the wild set an unrealistically short time-frame to complete all the tasks. I’m yet to see anyone penalized for spending more time than they were allocated to produce good work — I’ve seen it commented on a few times by reviewers, but never penalized.

The code you’ve submitted will be seen as a proxy for the code you’ll produce when you work there, so bring your A game. In almost all cases, quality is more important than quantity.

And so…

Did I miss anything? Have you been caught out by making stupid mistakes in your technical tests? Do you see the same issues over and over in code you have to review from interviewees? Drop me an email to [email protected], I’d love to hear from you.

Programmers: Just how relevant was your education?

Short answer today in response to a reader’s question:

How should I talk about my education on my resume?

Some job descriptions will make an explicit demand about your education:

BA/BS degree in a STEM field such as Computer Science, Mathematics or Statistics

Don’t let that put you off applying if you don’t have it — simply do not mention and part of your education. These requirements are very rarely real, and the further you can get through an interview process without it coming up then the more of a chance you’ve had of demonstrating that you’re an excellent candidate for role in-spite of not having the educational background. Experience is almost always a good substitute, but the HR Person or recruiter who’s the first person to look at your resume may not know this.

I started my career straight out of high-school and didn’t have any form of degree. Mentioning my high-school grades (A-Levels, IB grades, diploma, GED or whatever) would have simply drawn attention to this, doubly so as my high-school grades were nothing to be proud of. I applied for and got several roles that had strong suggestions that they were intended for recent graduates. But it only came up towards the end of the interview process by which time I’d had time to show evidence of my existing technical skills.

If you have a degree — undergraduate or post-grad — treat it just like you’d treat your work experience.

If it’s unrelated or tangentially related to the job you’re applying for, then subject, award, and dates are probably sufficient. Any degree that didn’t have a strong programming component in it probably falls in this category.

If it’s strongly related, treat the degree just like you would a specific job. Pull out skills that you used, projects that you worked on, and interesting challenges tackled. See: writing up a work history that matters.

Finally: people are easily impressed by impressive degrees. A few years I undertook a part-time MSc in Software Engineering at a well-known university, and it really opens doors. If you went to a highly competitive university, consider pushing the education section of your resume right up to close to the top. External recruiters and HR people are easily impressed by shiny things and take it seriously.

Your undergraduate degree in Forestry Management from Springfield A&M deserves a small note at the end of your resume (if you’re a programmer — if you’re applying for a forestry management role, go large) with dates and award. You MSc from Oxford in Software Engineering belongs right at the top, with an exposition on what you learned from it.

Remember: your resume is simply a tool to get you an interview, and talk about things in that interview. Omit anything that would be better explained in the interview (eg: you don’t have a degree), or which isn’t explicitly focused towards getting that interview.

How to write up open-source experience when you don’t have any

Around here we like to prove rather than just say that we have skills. One really easy was to do this is by showing off your open-source contributions. If I want to prove to someone I really am a Perl programmer, I have a CPAN repository that demonstrates a whole bunch of different areas I’ve touched, and a GitHub account that shows contributions to other people’s projects too.

Hooray for me, right? But this doesn’t help you at all if you’ve not got any open-source experience already.

First a caveat

I don’t want to be that guy, but it’s worth pointing out before we get to the sneaky tricks, that the best solution here for writing up your open-source experience is to go and get involved in open-source projects.

Submit some patches, bug reports, features suggestions, or whatever to the code you use every day. Got some functions hiding away for solving a problem, and that you always come back to? Pull them together into a coherent whole and release them.

Find out if there’s anything in your work’s code-base that they wouldn’t mind you putting together and releasing. You may find that the senior developers haven’t done it because they simply can’t be bothered — I do some work for a company where we have four or five good libraries that are ready to go, but most of the senior development team are already heavily involved in open-source and don’t have the time to take on new projects to maintain.

However, this would be a pretty pointless article if my solution to writing up non-existent open-source experience was to simply gain some, so with that in mind, let’s move on to other solutions…

Talk about anything you’ve done but haven’t released

Interviewers are looking at your open-source contributions as proof that you’ve got an inherent interest in tech and programming, are exposing yourself to ideas of those that you’ll see purely in the workplace, and genuinely have some of the skills you’re claiming.

You’ll still cover most of those bases if you talk about personal programming projects you’ve completed, and can talk coherently and fluently about challenges and motivations for them. Maybe you never released your iOS app that allows you to scan crossword puzzles from newspapers, but you can still talk on your resume and your interview about challenges you faced getting OpenCV to recognize the outline of the puzzle and extract text. You can still describe what you liked about using Swift (or ObjC) and how it compared to the technologies you use in your day job.

Many developers run their own co-located server, especially now it’s so cheap to get a VPS. What OS is it running? How do you keep it up to date with security patches? Did you turn off password logins with SSH to secure it? Configure virtual hosts with Apache? Mess around with Puppet in case you ever needed to rebuild the machine from scratch? Put WordPress in a container because it’s a security concern? Manually setup the firewall with iptables?

It’s all in scope, it’s all relevant, and you should talk about it! It can’t be independently verified like open-source contributions can, but if you can insert your opinions into the description, talk about the challenges you faced, it’ll look credible, and it can be discussed in interview.

I’d consider collating all of this under “Personal Software Projects” where an “Open-Source Contributions” section might go on your resume.

Talk about anything you’ve learned

Anything you’ve read that was particularly interesting, any online course you’ve taken, or any interesting talks you’ve attended also hit our criteria of:

Exposing yourself to new ideas
Showing an interest in technology
Supporting the skills you’re claiming (if you’ve applied them, anyway)

I’d look favourably on anyone who’d read Seven Languages in Seven Weeks. If it’s mentioned, followed by an idea you took from it and applied, even better! Maybe something like “I recently completed Seven Languages in Seven Weeks and was inspired by Haskell’s typing system to look at introducing strongly-typed JavaScript variants into our work codebase”.

Tech talks also work well for this! “I recently attended a talk on Vagrant at the London Hackspace and used a work Hack Day to build a development image for our main production application”.

The basic structure is: you took the time to seek out a new idea, you were inspired by that new idea, and this either benefited the company you work for or led to further investigation and learning for you. Coursera and friends are full of interesting ideas: “I’ve recently completed ‘An Introduction to Compilers’ on Coursera, and have applied the sections on state machines to building a business rules engine in my latest project”.

All together now

Once you understand why open-source contributions are looked upon so favourably on developer resumes, you can start to highlight related experience that may not actually be open-source contributions to fit the same aims. One more benefit of understanding the process.

Developer employee cheatsheet: WTF is Salary Benchmarking?

It’s time to do my team’s annual salary review.

I have been given a chunk of money I can distribute through the team and it’s up to me how much each person actually gets. I’ve got a spreadsheet to fill out. Against everybody I have the basics you’d expect:

Name
Job title
Current salary

If you’ve done this kind of thing before, or you’re thinking ahead, perhaps you’ve also guessed I have:

Last year’s salary increase
Number of years they’ve been employed

But I’ve also got some columns you might not have expected:

“Normalized” job title. My “Head of Backend Applications” has become “Senior Software Developer” and my “Client-Side Developer” has become “Front-End Developer”
Years of experience
Market Salary‽
A suggested pay rise based on how much under or over the Market Salary each person is

For each person in my team, someone has tried to work out what they should be getting paid based on our location, an approximated job title, and their years of experience!

Welcome to the world of salary benchmarking…

Salary is difficult

Companies have a dilemma.

If they offer too little money to current and future staff, those staff won’t accept the jobs, or will take jobs elsewhere. That’s pretty straight forward.

But if they offer too much money, it’s very difficult to reduce someone’s salary if they turn out not to be worth the premium price tag. What’s more, for every four developers they’re paying 25% more than the market rate, they’re not able to hire a fifth potential developer.

If they’re in a competitive market, then their competition can get more done at the same price. If they’re a company with shareholders, they open themselves up to challenge from those shareholders on why they’re paying their developers more than the market rate.

Companies may have a lot of reasons they decide they’re going to under or over pay. Perhaps they think working at the company or the perks they offer make up for a smaller salary, or perhaps their systems take a long time to learn and once someone’s on board they don’t want them tempted away with a larger paycheck elsewhere. But in either case, unless they know what the market rate for their people is, they can’t effectively do either.

A salary benchmark allows them to compare their staff to the market rate, and guide decisions about who should be getting paid more, or less.

Where the data comes from

There are a number of places companies can get this data. On the smallest scale, a company trying to fill a job may just ask their friendly local recruiter what kind of salary range they should be offering. Recruiters are incentivized to push that number upwards because they’ll get a bigger commission and the job will be easier to fill — there’s no downside to them if the company overpays!

Larger companies will buy the data from companies like Payscale, who allow them to specify all sorts of factors — educational attainment, skills, office location, auxilliary benefits like pension and healthcare — to find out how their staff rate against the market.

Very large companies may even have dedicated staff to do this, especially for more senior staff — a remuneration committee, or dedicated people in HR whose job it is to come up with benefits packages and salary bandings for different roles.

What you can do

Besides this process being simply interesting in its own right (to me, anyway), there’s an actionable point here as well for the developer who wants to get paid more.

The basic principle is: you want the salary benchmarking process to make it look like you’re currently underpaid, to encourage the levels of management above you to try and fix that, so you don’t get poached by another company.

The person creating the salary benchmarks probably doesn’t know you, and will be simply guessing on what job you’re actually doing based on your job title. Or maybe they do know you, and they’re searching a long list of job-titles they’ve never seen before from the salary benchmarking data. They have to take a guess on what exactly the “Widget Team Manager” or “Data Extraction Lead” maps to in the data they have.

So it’s worth making sure your job title adequately reflects your current seniority. Programmers often think that quibbling about titles is below them, but if you’re mostly doing architecture work, or you’re leading a team, or you’re one of the senior members of a team, having a job title that reflects that will make the magic Market Salary number higher.

Smaller companies will often be pretty flexible with job titles – as long as it’s not something ridiculously senior (most companies will only allow for one CTO, for example), adequately describes the work you do, and won’t cause too much resentment with your team mates, then it’s pretty reasonable for you to ask for a review of it.

Larger companies will have their own internal hierarchies or what constitutes a “Senior” or “Junior” developer. Are you familiar with what it’d take for you to get the next job title up? Not all managers are on the ball with career development, but if you start bringing this up at your one on one with your manager, you should at least get the ball rolling by eliciting what you’d need to do to move up.

Even larger companies may well have official internal levels: “Software Engineer Grade 3” and so on, and these will generally come with pay brackets attached. It’s reasonable and well within your rights for you to express to your manager that you’d like to move up to the next level, and for concrete steps you’d need to take to do so.

Job titles are more important than you think

The exact characters that comprise your job title can cause all sorts of unexpected effects on your salary range. Many developers consider them unimportant, or as I mentioned earlier think that thinking about them or discussing them too much is beneath them.

Most, however, are interested in being paid more for their existing work. Once you understand the processes involved it becomes easier to see which levers are available for you to pull to start getting paid more.

Don’t bore me: how to write a technical work history that matters

When I was a kid, I used to work at Pizza Hut in the high-school holidays. I loved doing that — when you were in the kitchen you could get away with eating anything you’d made by mistake, and we made a lot of mistakes.

You end up putting up with a lot of Corporate Bullshit in service industry roles — when at about 16 I switched to doing programming jobs in my free time for my beer and clothes budget I was pleasantly surprised at how much better tech companies treat their staff.

Anyway, as a result, I tend to look pretty favorably on graduates or high-school leavers with service industry experience on their resume. It takes a certain inner resilience to not go crazy working in a kitchen or with customers. But reading your resume: if you’ve already got ten years’ experience programming, I stop caring about the jobs you did years ago, especially the ones without direct relevance to the job you’re currently applying for.

Let’s cover what and how to put together the work history section of your resume.

Which jobs to cover

Your resume is a necessary evil that nobody really wants to be reading. Recruiters will just skim it, the Hiring Manager has much better things to be doing and is trying to get to a decision on whether to bring you in for interview as soon as possible, and the interviewing developers are just scanning it for anything interesting to talk to you about.

My belief is that three pages is about ideal for the resume of a Senior Developer with a long work history. A page of summaries and skills to begin, and up to two pages of work history, if it’s interesting and relevant.

Your most recent roles are generally where you’ll have learned about modern technologies, techniques and tooling, and the experience you’ll have gained at those roles are what will be at the forefront of your mind.

While it’s pretty cool that I worked at the BBC in 2006, and also that I was working on one of the first internet TV technologies, the state of the art back then was CVS and Server-Side Includes. Did I learn anything interesting and still relevant today? Sure: I saw one of the first proper roll-outs of Scrum at a huge company, and learned the hard way that 100% test coverage in a codebase is pretty worthless. But at the end of the day we were still deploying code by emailing tarballs to an ops team.

The amount of time and space I want to use describing that role is much less than a modern gig I’ve done using AWS EC2 containers and Kanban. A new role I’m applying for will (most likely) be using a different technology stack and different techniques from what I was doing ten years ago, so describing that is where I want to be spending most of my time.

In general, I’d:

Go into detail only about the last 2-3 roles you held
Summarize earlier roles as a relevant job title and dates only, perhaps pulling out a couple of skills if you’re trying to show a certain amount of experience with that skill or are going for One Trick Pony
Lump up non-technical jobs as a line item (“A variety of non-technical roles”) unless you’ve got virtually no relevant experience — if this covers many years, you could consider adding “Full work history available on request” instead

How to cover those jobs

We’ve identified which jobs to talk about, but we’ve not yet looked at how we’re going to talk about them. We’re going to take a three bullet point approach to this, trying to appeal to each of the interview gatekeepers.

As a very quick reminder of who they are, and what they want:

The HR Person or external recruiter is a non-technical person who’ll be Ctrl-F’ing through your resume looking for keywords that were on the job description.
The Hiring Manager is usually a senior technical person who wants is looking for experience that’s similar to the job you’re applying for.
The interviewing developers are a random collection of non-professional interviewers who were dragged together at the last minute, and are desperately scanning your resume for interesting things to talk about.

With a cynicism so pure it’s admirable, we’re just going to literally give each person exactly what they’re after, in order, rather than trying to be poetic or particularly accurate.

Facts and figures

Job title and dates are one of the few objective facts on your resume. You need to get them right and be accurate. However we can supplement accuracy with some artistic license. Use two job titles instead of one if the role’s title wasn’t exactly what you wanted (see that linked article, there are legitimate and illegitimate ways to do that).

There’s also occasional mileage in dropping the months from employment dates: Dec 15 – Jan 16 is 2 months, where 2015 – 2016 looks a lot like a year. While you had excellent reasons for leaving after two months, those are generally much better explained in person rather than simply stated by your resume.

So we kick off with job-title, dates, and employer:

Senior Perl Developer / Warehouse Systems Programmer
NET-A-PORTER; 2009 – 2012 (Contract)

Keyword smackdown

I’m not a fan of lists of keywords but we’ll start with that to keep the HR Person or external recruiter happy. The more these match and mention the ones in the job description, the better, and if you’re matching your resume to a specific job you’re applying for, I’d consider trimming ones that aren’t relevant: nobody cares that you’ve used FTP and SMTP as a Python developer.

Did you know? HR software, resume databases and job boards often have embedded resume parsers that will attempt to summarize how many years experience you have with each skill. And recruiters are lazy, so will trust the time-saving software they use. It pays to be explicit: I know that if your skills include AngularJS and React then you also know JavaScript, and that if you’re using Docker then you probably have Linux experience, but a recruiter or piece of software might not.

I like to prefix the work history bullet points with a meta-description, so for example:

Skills used: Perl, JavaScript, Test::More, testing, Agile, Scrum, git, Postgres, MySQL, Catalyst, Modern Perl

Try and find a comfortable balance between spartan terseness:

Skills used: Perl.

… and going overboard with SEO-style keywords:

Skills used: Perl, JavaScript, Test::More, testing, Agile, Scrum, git, Postgres, MySQL, Catalyst, Modern Perl, FTP, Linux, bash, T-SQL, CGI, Test::More::Extended, software testing, Cucumber, Behaviour Driven Development, meetings, Microsoft Office, typing, keyboard, mouse, monitor, programming, programmer, development, developing, INTERCAL, IP over Avian Carriers, Perl 5, Perl 5.14, Perl 5.16, Perl 5.18, Perl 5.20

What did you actually do?

In the majority of programming roles, your job in practice was “X Programmer”. And that’s good, but we should put just a tiny bit more meat on those bones. Mention a major project or two that you were involved in, mention what the company did, and mention parts of that project that you took the lead on or that you were good at. It can’t hurt at all to make your last role sound somewhat like the role you’re applying for.

We’re trying here to speak to the Hiring Manager. When HR asked the Hiring Manager to put together a job description, she secretly just thought she could write “Senior X Programmer” and the right people would apply. The aim with this bullet point is to say that that’s what you are, and provide a small amount of proof or evidence that backs that up.

I call this a Role Overview:

Role overview: Senior Perl Developer helping to design and architect an automated warehousing system for a major e-commerce brand. Employed to help build out their automated unit and internal testing libraries to maximize reuse. Role evolved to general architecture as I worked with a variety of external suppliers, internal stakeholders and other teams.

… and in this one I’ve hit an overview of what kind of job it was (“Senior Perl Developer”), the general context of the role (“design and architect an automated warehousing system for a major e-commerce brand”), and started to embed evidence of skills by highlighting opinions of what it took to do the job well (“maximize reuse”).

What was interesting about it?

So far we’ve put together relevant pieces for recruiters and the hiring manager, but … it’s a bit dull. During the interview you’ll need to show off your technical skills by having interesting technical things to discuss. We can prime for that by pulling out interesting challenges and experiences you had in the role. This is also a good time to show off your knowledge of modern tooling and techniques that perhaps don’t collapse easily down into one-word skills.

Simple man that I am, I like to label this section as exactly what it is: Interesting Challenges:

Interesting challenges:

The system involved interacting with large, caged robots moving around a physical warehouse at high-speed. I developed a queue-based architecture based on AMQ to deal with the natural latencies involved with sending 4 tons of steel to a different location at 60mph

Maintaining 100% up-time during development was business-critical so we used a several-stage roll-out during the migration from manual to automatic warehouse processes; I made heavy use of automated monitoring of events using Riemann to detect developing problems before they had a business impact

The initial automated test system took two hours to run to completion, based on a live database dump. I made aggressive use of fixtures, profiling, and removing duplicated testing paths to bring the run time down to under 5 minutes

It’s interesting to note that when I did the things mentioned in the points above, it was very much part of a team effort. It’s reasonable to take credit for things you did in a role, although I’d be very careful taking credit for things in which you had almost no hand: claiming to have been person developing test fixtures is fine unless you can’t talk at length about it during the interview.

As much as anything this section is about signalling the things you do want to talk about in an interview so that you don’t get asked inane technical brainteasers that the interviewer has just thought up instead.

Final thoughts

If you remember who your resume is aimed at and try to speak to each of those people directly, your resume will be 90% better than most of the ones I receive. Your experience 15 years ago fixing computers at Best Buy is of limited utility when applying for a Software Architect role, and including details of it is a signal that you don’t know what’s important and not. Don’t bore the people who have to read your resume — speak to them directly instead.

Different types of technical interview, and how to handle them

There’s a limit to how much a company can actually find out about a job seeker in an interview, and in my opinion that’s pretty much limited to:

Can the job seeker appear kind of normal for a few hours?
Are they able to provide some evidence about the skills they claim to have?
While on their absolute best behaviour, can they have a technical conversation without throwing a chair at anyone?

Most interviews will use some form of technical test as the basis for answering those questions. I’ve already covered the importance of being interesting rather than simply right and showing your working when answering general technical questions, but there are specific strategies you can use when you’re actually being tested.

Make sure you do you minimum viable interview research and find out what kind of test — if any — you’re expecting! Below are the kinds I’ve seen as a job seeker or administered as a hiring manager.

Code review some existing work

One of my favourite tests to give — especially for senior developers — is asking them to code review some code I’m already familiar with. Developers spend a lot of time reading other people’s code, so it gives experienced developers a chance to show how they’ll start working out what code does. Additionally their feedback on the code shows what they think is important, and leads to good technical discussions.

First of all, be careful with your criticisms of the code! When I used to run these, I’d make sure I was showing job seekers code I’d written many years before, and wasn’t particularly proud of, but you never know when someone’s presenting their masterpiece. Much as if you were code-reviewing a colleagues code, be sensitive — mix in praise liberally with things you think could be improved.

Chances are though that your interviewer knows there are things wrong with the code, or at least aspects that invite discussion. Are there methods or constructs you’ve previously seen issues with? The code I used to use for this used goto, which was always an interesting way to get the conversation going.

What are the failure modes in the code? Does it live and die gracefully? What assumptions does it makes about its environment? Are there situations in which those might not hold? How does it handle unexpected inputs? Is it performant? Is it making obvious trade-offs between readability, memory use, CPU use, or something else? Are tests included? Integration tests, unit tests, something else? Does the documentation clarify, confuse, or simply not exist?

Generally I’d steer clear of purely stylistic concerns — an interview is probably not the time to criticize indentation style. That said, if the code is inconsistently formatted then a discussion of linting tools can often lead to interesting places.

Remember that you’re being evaluated not just on your ability to identify strengths and weaknesses of the code under review, but also your ability to interact with other developers. Suggest things rather than being dogmatic, and while you should stand behind your opinions, avoid being too inflexible.

Implement an algorithm, solve a problem

One of the most popular tests with interviewers, and least popular with interviewees, is white-boarding algorithmic questions.

You’re (usually) not expected to simply know the answer, but rather to be able to tackle and reason about something unfamiliar. If you don’t know the answer straight away, be upfront with it. Ask for help on bits you don’t understand, and talk about what you’re thinking rather than expecting the interviewer to be psychic.

Generally the interviewer is trying to work out how you think, and how good you are with coming up with questions about the task at hand; what tools do you have in your toolbox, and how do you apply them?

Some companies have a real reputation for asking these kinds of questions. If you have time to prepare, making sure you have a good grasp of Big O Notation and doing some practice runs at home is probably a good idea.

Above all: show your working. That link just there was a whole article about specifically how to do it, and you’d be well served by familiarizing yourself with it.

Under no circumstances get defensive. However smart or capable you are, a developer who starts to attack the question and questioners is not demonstrating their ability to be normal for a few hours!

I pick on this particular tweet all time:

Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.

— Max Howell (@mxcl) June 10, 2015

Spoiler: he didn’t get the job he wanted, and on seeing that tweet, I suspect the interviewers didn’t feel they’d made the wrong choice.

Take-home technical test

My favourite test as an interviewee is the take-home technical test. You’re given a programming challenge or set of instructions, and you’re meant to complete it on your own machine, in your own time, at home.

Many companies use these as a prelude to an in-person interview, and you shouldn’t be surprised to see your code printed out at the interview ready for discussion.

Generally there’s a suggested time constraint, although I’ve never seen a developer penalized for spending longer on the problem to bring it up to what they consider their best effort. That said, some tests aren’t meant to be finished all the way — the questions get more and more time consuming. Try and bite off only what you think you’ll be able to complete to the best of your ability.

If you’re working with a programming language that has linting or static analysis tools, make use of them: you’ll catch silly mistakes, and it’ll probably guide you towards best practices.

Important: make sure you can explain every line of code you’ve included. [Calvin and Hobbes comic] It’s tempting to copy and paste code snippets from the documentation of framework from StackOverflow, but it’s also obvious that you’ve done so if you can’t explain how or why something work. If you start your JavaScript files with `”use strict”` I’ll expect you to know exactly what it’s doing and why it’s good practice.

Make sure you understand how the technologies you rely on work

Idiotic programming trivia

Every so often you come across a developer running an interview who’s learned something new recently and wants to show off their knowledge. Questions about Monads in any language other than Haskell, exotic data structures, and so on. I had someone ask me in an interview — in all seriousness — to explain what this does:

sub { return
 ((1 x shift) !~ /^1?$|^(11+?)\1+$/)
 }

(it’s a regex that finds prime numbers)

The wrong answer is: “Could you explain what this has to do with the job?” That you have a smart-ass developer interviewing you is probably not indicative of some deeper truth about the company, or even about your future colleagues — someone is having some (inappropriate) fun.

Unless you already hate the company at this point in the interview, it’s probably not a good idea to launch in to a heated take-down of their interview, parentage, etc. Instead, grin and bear it, and look impressed when they come to the big reveal and tell you what’s going on.

Parting thoughts

When it comes to running interviews, nobody knows what they’re doing, and all the processes are a bit broken.

However odd the process seems to you, remember what’s in your control:

Appearing normal and likeable for a few hours
Providing some basic evidence of your ability to work with the technology
Not getting unduly upset about questions you don’t like

And, for the final time, show your working and be technically interesting.

Get a programming interview with three bullet points

To get a job, you’re going to need an interview. To get an interview, and then a job, you need to get past the three interview gatekeepers.

Developers are generally in high demand, and recruiters want to move quickly, so your resume is going to get read very quickly.

In my opinion it’s entirely possible for most (qualified) developers to put enough good information in three bullet points at the beginning of their resumes that the person reading it will make a snap Yes decision and just skim the rest of it.

If you don’t put anything outlandish on the rest of your resume, it’s possible to get a programming interview with three bullet points.

Don’t be boring

Summary sections at the beginning of a resume can be a real mixed bag. The problem is that people tend to try and describe themselves in positive terms without saying anything of value. For example:

I am a self-starter and also a quick learner. I am highly motivated, with ambitions to work for a company whose high standards match my own. I am conscientious and experienced in all aspects of software development, including JAVASCRIPT, CGI, and HTML programming languages.

Cool story. But nobody cares, see?

Recruiters and HR people think programmers are weird already. They know that you just mashed together some positive adjectives, and that it signifies precisely nothing.

Actual photo from “Search and Placement! A Handbook for Success” by Nobles and Finkel

Assume the Hiring Manager will be deeply cynical. You’ve claimed a lot of skills they may or may not care about while providing evidence for none of them.

Your future coworkers will just think you’re an idiot for taking the time to write all that self-promoting stuff down.

But with a little work — and by that I mean specifically removing all of the above and replacing it with something else — we can make all three groups happy. We’re going to give each group a bullet point that speaks exactly to them.

Help the recruiter know they’re in the right place

Recruiters and HR people get a lot of speculative resumes from people who aren’t even a little bit qualified for the roles. Network Engineers and Waitresses apply for Node.js roles. Sysadmins who wrote a little bit of PHP once apply for full-stack developer roles. College grads apply for architect roles that need 15 years’ experience. This effect is exacerbated by job sites that allow one-click application to roles for job seekers.

Let’s put that to rest straight away. I want you to repeat the job title they said they were looking for back to them, and throw in one or two skill keywords to show you actually read the job ad. Help them to understand that they are, in fact, looking at a resume for a “Senior Python Developer” by literally writing it down:

I am a Senior Python Developer with 15 years experience, including exposure to Puppet and Chef and JavaScript, CSS and AJAX

The hiring manager wanted a Senior Python Developer, you’ve said you’re a Senior Python Developer in the first sentence. They’re not going to look too stupid if they forward your resume on to the Hiring Manager, given that you have assured them from the offset that you are Senior Python Developer — you’ve saved them from having to do some archaeology on all of the arcane words they don’t understand in your work history.

The Hiring Manager

The Hiring Manager is a little more canny. She doesn’t need to be spoon-fed the fact you’re an approximate match, she can just glance at the skills section and work history for a few seconds.

But those skills aren’t really that trustworthy. It’s easy to claim technical skills on a resume. You can just write them in, 4-7 keystrokes each. The person reading it has no idea if they’re accurate or if the experience you’re claiming really happened.

However you can also provide inline evidence of your skills by showing opinions you’ve formed as a result of having used them. You could write:

8 years of Perl, testing, DBIx::Class, Plack, Catalyst, CGI, Test::More

… and force the Hiring Manager to then go digging around in your work history to find out corroboration. OR you could put a bullet point in your summary section where you provide just a tiny bit of description about each skill to act as a shibboleth to people familiar with those skills:

I’m an active proponent of Modern Perl – I love the power of composing resultsets in DBIx::Class, using Plack to hide web-server implementation details, and the way that Test::Builder-based testing tools all interact well with each other

There are a bunch of great ways to prove your skills on your resume; I wrote a whole article about proving not saying which I’d encourage you to read.

Future Coworkers

The developers who interview you don’t interview people for a living. They have your resume, and they have an hour of time to fill. They will be searching for interesting things to talk about based on your resume. Generally developers also enjoy working with people who have an intrinsic enjoyment of technology.

You can provide interesting things to talk about in the interview as well as showing your love of technology by mentioning interesting side projects you’re involved in:

My personal development projects include an automated cat treadmill using Arduino with a digital signal processing component written in Perl using the Event module

… or …

In my free time, I’m currently working on an app that converts photographs of crossword puzzles in to playable games using OpenCV

… or …

I teach an after-work class to my colleagues in using AngularJS

You don’t have to be building a rocket ship in your garage to have an interesting technical project on the go. The more interesting things you have to talk about, the more passion you’ll show about programming, and the more you’ll end up talking about your technical strengths, rather than solving inane technical brain teasers the interviewers found online.

Summary of the summary

Most people hate reading resumes, and don’t want to go on an fishing expedition through your 7 page resume to find where you mention skills. Put the important things first, and speak to the interview gatekeepers.

Having been a recruiter, a Hiring Manager, and an interviewing developer, a resume that starts with:

Summary

I am a Senior Perl Developer with 15 years experience, including exposure to Puppet, Chef, JavaScript, CSS and AJAX.

I’m an active proponent of Modern Perl – I love the power of composing resultsets in DBIx::Class, using Plack to hide web-server implementation details, and the way that Test::Builder-based testing tools all interact well with each other

My personal development projects include an automated cat treadmill using Arduino with a digital signal processing component written in Perl using the Event module

… saves me a whole bunch of time. The recruiter knows they’re in the right place, the Hiring Manager gets a bit of proof you’ve not completely made up all the words on your resume, and the developers get something interesting to talk to you about in the interview.

Just don’t screw up the rest of the resume.

Knowledge is power: Why are they hiring a new developer?

One of the core concepts on this site is the idea that the more you understand a process, the better equipped you’ll be to work with it. The more you understand the recruitment process, the more you’ll have a good idea of what questions to ask a potential employer and what to do with that knowledge.

In addition to the Minimum Viable Interview Research, one of the most important — but also most overlooked — questions to ask is:

“Why are you hiring a new developer?”

The Options

There are three common answers to why a company is hiring, and each opens up different opportunities to the developer interviewing for the job. Essentially:

Replacing an existing person who’s vacating the role
Staffing a new project or team
Incremental growth / expansion of their team

Replacement

People leave jobs to go to different companies, or different roles within a company. What opportunities does this present to the person interviewing for the replacement role?

For one thing, the technical people interviewing you (meet the interview gatekeepers) will probably have opinions on the strengths and weaknesses of the person being replaced. You can ask about these in the interview itself to find out what skills they’re most interested in:

“Are you looking to exactly match the skill-set of the person who used to have the role?”
“Is there anything new that you’re looking for the replacement to bring to the table?”
“Are there specific skills you’re worried about leaving when they move on?”

The answers to these will give you a good idea of how to pitch yourself in the interview, and what skills you have to talk about. You probably don’t want an exchange where you simply parrot back to the interviewers all the things they said they’re looking for — it’ll look like you’re trying to over fit yourself to the role. But these are great for jumping off points for “proving, not saying” and “being technically interesting”.

It’s possible that an external recruiter you’re talking to about the role will also have a strong idea about the answers to these questions — we often get a lot of “liner notes” to go along the job description when we take on a job search. If so, you can use some of the ideas under “More Advanced” in How a Recruiter Speed-Reads Your Resume.

Startups or small businesses that became successful often have the “tech lady” or “tech guy” who did all the originally development — the one who wrote the horrible legacy code and runs SQL “fixes” against the live DB. The business generally has a love/hate relationship with this person or people — maybe they got the business a certain distance, but they lack the willingness to follow business and technical processes that make their work stable and predictable. If that’s the case, make sure you talk about professionalism and experience of “more appropriate methods for a more mature business” in the interview!

In general, if they’re doing a like-for-like replacement of someone, a company’s unlikely to want to massively change the seniority of the role or pay a dramatically different amount to the new hire than they did to the last person. They’re probably looking to re-use the same job title, and so there’s probably the least amount of negotiating flexibility about the remuneration and benefits package. But they’ve also probably got the clearest idea about what they need, and that can work to your advantage.

A Whole New World!

One of the most exciting times for a developer can be building something from scratch. And sometimes companies are hiring for a new project or a new team, and you’re interviewing to get in right at creation time. Awesome! Someone in the business got funding signed off to do something, and now they need to build the team to do it.

There’s probably a specific pot of money that’d been allocated and a rough guess on how much head count is needed. This means there’s probably the most associated flexibility in hiring — how that money is divided between different developers as salary, how that team will be structured, the mix of experience needed in the team. There’s potential to make one or two expensive hires, and who doesn’t want at least one superstar on their team?

Try and sound out the possibilities:

“Are there other related roles you’re looking to fill for the team?”

Maybe you’re a developer with some DevOps experience that you’d like to build on, and they’re looking for someone to fill that role and you’d be a good match. Maybe they’re also looking to hire an Architect or Team Lead, and you could suggest you’d like to be considered for that role too?

Internal or external recruiters certainly won’t mind if you end up with a slgihtly different role at the same company — they’ll get paid whichever role you take. And companies are often looking for people who want to develop and grow inside the company. There’s benefit in showing some ambition and initiative beyond simply finding out if there are more interesting or appropriate roles you’d like to do inside the team.

Incremental Growth

Somewhere between the like-for-like replacement and the building of a whole new team, we find incremental growth or expansion of a team. That’s a great sign! It usually means the business values the work that team’s doing sufficiently to invest more in it.

If they’re hiring quite a few new people, you have some of the advantages of a whole new team — there’s probably a head count and an amount of money assigned to it, so they can take a chance on you if you’re more junior, or pay a bit extra for your expertise if you’re senior.

You can also find out specifically which skills the team is looking to build upon with the questions from the like-for-like replacement. At worst, you’ll look like you’re genuinely interested in their company, and at best you’ll be able to sell your strengths directly against the things in which they’re most interested.

Knowledge is Power

Programmers are by and large intelligent people who like to solve problems and work with constraints, but for some reason many are reluctant to apply those skills to the more meta problems and constraints attached to interviewing for new roles. You wouldn’t try and design a new technical system without trying to find out what problem it’s meant to be solving. Likewise, the more you can find out what problem the company who’s hiring is trying to solve by hiring, the more you can pitch yourself as the appropriate solution to that problem!

Developers: When being a one-trick pony is of the utmost value

There are some organizations that are interested in generalist programmers or tech people. There are roles where your technical skills are less interesting than your ability to solve business problems by using some programming magic.

But most programming jobs aren’t like that. Most programming jobs are looking for developers already experienced with the employer’s technology stack to solve the employer’s problems primarily using that technology stack.

Most jobs aren’t looking for Senior Programmers, they’re looking for Senior Python Programmers, Senior Ruby on Rails Programmers, Senior C# Developers or Senior Node.js Developers, or whatever the job-spec happens to say.

And when that’s the case, the recruiter will be speed reading your resume looking for proof that that’s what you can do, and you’ll be really helping yourself by making it clear you fit the bill.

Talk About the Important Things First and at Length

If you’re applying for a Node.js role, and your experience using Visual Basic takes up as much room on your resume as your Express.js experience, you’re doing it wrong.

Heck, if you’re applying for a Node.js role, and your experience using Visual Basic takes up as much ink as the fact that you read (and mostly understood) the Promises documentation once, you’re still doing it wrong.

This kind of thing is common and terrible:

Skills:

JavaScript (7 years)
Java (2 years)
Linux (5.5 years)
SMTP (2 years)
FTP (12 years)
T-SQL (1 year)

If you’re thinking: “Do Node.js developers really list SMTP and FTP as skills?”, the answer is yes. Tragically so.

Only the non-technical recruiter or HR person cares (meet the interview gatekeepers) about a long-list of auxiliary skills, they’ve seen 5,000 resumes like this, and they don’t even know what FTP is.

We’re aiming to prove our skills, not just mention them. And if you’re applying for a Node.js role, the main skill you’re trying to prove you have is Node.js

If you’re applying for a Node.js role, then Node.js should be the first heading on your Skills section, it should be the largest part of your Skills section, and it should be full of proof that you know Node.js.

Stop Complaining, Show Me the Examples

How do we achieve this? Let’s take an example, and then break-down what’s going on:

Skills

NodeJS and JavaScript

Web Development

I have extensive experience of using Express.js, and appreciate its light-weight and unopinionated approach. I’ve found Middleware to be invaluable for inserting debugging code deep into requests, and for composing distinct pieces of functionality into one coherent whole. I have commercial experience using Meteor with React, and find that the publish-subscribe pattern allows for simple-to-reason-about consistency of data throughout the whole application. I have some exposure to AngularJS.

Testing

I have a deep and broad experience with various JavaScript testing tools. Most general testing I have approached with Selenium, but I’ve also worked in teams with an aggressive focus on unit testing with Mocha. Mocha’s flexibility is excellent, although I’ve found the sheer number of ways a test-suite using Mocha can be setup can be a barrier to getting started with a new team. I have some experience building Behaviour Driven Development user stories using CucumberJS, which I like because it forces technical and non-technical members of a team to agree in writing to sets of behaviour.

Quite a mouthful! What’s going on here, and why?

Let’s start with:

I have extensive experience of using Express.js, and appreciate its light-weight and unopinionated approach

One way to present your experiences as proof that you’ve actually used the tooling you’ve mentioned is to form and present opinions on them. It shows the hiring manager that your experience probably really happened, and it also gives the interviewers jumping-off points to talk about with you. If you choose to opine about a subject, make sure you have something interesting to say about it in the interview!

Mocha’s flexibility is excellent, although I’ve found the sheer number of ways a test-suite using Mocha can be setup can be a barrier to getting started with a new team.

It’s always worth showing off your battle scars — what are the insights you’ve gained from your experience? The more interesting problems you’ve encountered and solved, the more useful experience you’re bringing to your new team.

This also starts to get into “contentious opinions” territory — something that will allow you to explore how you have technical debates about the pros and cons of technology with your interviewers, without being too weird. We can double-down on that:

I have some experience building Behaviour Driven Development user stories using CucumberJS, which I like because it forces technical and non-technical members of a team to agree in writing to sets of behaviour.

Many developers have heard of, or dabbled with tools like CucumberJS. Some will have formed strong opinions about it. Interviewers will want to talk about things like these, so if you’ve prepared interesting things to say about it, you can keep the interview on topics which are interesting.

One more quick aside: played with a technology but don’t want to commit to being an expert on it? I like:

I have some exposure to AngularJS

It’ll get you past cursory keyword searches against your resume, while giving you an out if you get a question or two that’s out of your depth.

Finally, you might notice I’ve emboldened key technologies. It looks a bit naff, but it helps someone skimming your resume to pick out the things that are interesting to them.

Two bonus pieces of advice

This is neither the first nor last piece of content about describing your skills on your resume, but I’d like to throw in two other simple tips if you’re applying for an “x Programmer” role.

First: Make sure your previous job-titles align with the job-title you’re applying for as far as possible. If that’s not possible (maybe you’re “Software Engineer II” at your current role), take a look at When two job titles are better than one.

Second: start your resume with a clear, unambiguous mention that the person reading it is in the right place. Applying for a Senior Python Developer role? Have the first line of your resume be:

I’m a Senior Python Developer with seven year’s experience.

You’ll stop non-technical people missing the forest for the trees as they read through your experience.

Technical Interviews: Interesting is normally more important than right

We’ve already covered that technical interviews are often primarily about not being too weird and that you should really try and show your working when solving programming questions in interviews.

But you should also try to make answers about technical subjects interesting.

When you’re being asked technical questions, the point is not seeing whether or not you know the right answer — the point is to get you to show off your technical skills. There’s overlap there, but those are not the same thing.

So you like databases?

Let’s find ourselves in an interview, where the interviewer has just said “Ah, I see you’ve got Postgres and MySQL on your resume”.

Here’s a plausible answer:

“I’ve used MySQL for three years, I’ve used PostgreSQL, and I have used SQLite for testing”

An answer that’s short and to the point. But it’s also entirely the wrong answer. Seriously, who cares? You said that on your resume already.

If you’ve read around this blog, you’ll know we prefer to prove, rather than simply saying, our experience. So dig up your experiences, show off your battle scars, and share your opinions!

Talk about that Unicode issue you had with MySQL where you lost three weeks because you’d chosen to use codepoints from an astral plane and MySQL didn’t support 4 byte UTF-8. Talk about how you eventually debugged that, which tools you used, and heck, why not segue into some interesting things you learned about Unicode along the way.

How about that time you thought you were being super clever by using SQLite databases to provide reusable fixtures and temporary databases for testing, even though the production DB was Postgres? It went terribly wrong, and you can explain why, and the trade-offs you made and lessons you learned.

Don’t forget the really clever solution you came up with for choosing distribution keys on Redshift, and two different ways you decided to benchmark it.

Interesting trumps right

It’s tempting to think that you should be narrowly trying to answer any question you’re asked. And if you’ve been given a specific technical challenge, that’s probably true. But most technical questions in an interview are simply exploratory, and exist solely to get you to try to show off your technical experience.

And when you’re talking about technical problems you’ve solved in the past, or talking directly from your experience, you’re showing off your technical experience. What’s more, you’re on pretty safe ground.

When you stop talking, you’ll get asked another question designed to show off your technical experience, and perhaps it’ll be on a topic you’re not so comfortable on. If your monologuing about your experiences is boring them, or there’s something specific they want to talk about, they’ll cut you off and talk about it, but otherwise, keep segueing into other things you think they’d like to hear about, and that you’re good at talking about.

Personally, I’ve got all sorts of interesting things to say about testing. So if I get asked any question that I can segue from in to a testing strategy answer, I will do that, and without shame. You want to spend as much time as you can talking about the things you really know well.

It’s not an exam

At the end of the day, remember that an interview isn’t an exam. Your resume is not a PhD thesis that you’re trying to defend. You’re trying to not appear too weird while you show off your technical knowledge. Don’t make your interviewer work too hard to dig out your technical knowledge — flaunt it by proving what you know.