Category: Interviews

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?

Meta

8. Have you removed pointless boilerplate?

Documentation is great! Place-holder documentation created by a module / framework starter script is worthless if you haven’t added anything to it. Tests are great! Tests that your testing library add as a “HOW TO” are worthless. Code is important! Stubs that aren’t used that the computer wrote are not very interesting, and usually have no place in your test submission

9. Have you run a code tidier over the code?

Some people consider code style to be a deeply personal choice. Some people think it’s best handled by a computer and a shared style configuration. Everybody (almost) agrees that internal consistency is important. While you can go wrong by mixing tabs and spaces as indentation, you’ll almost certainly never go wrong by running a popular code tidier over your code in the default settings

10. Have you linted your code?

Linters find “areas worthy of review” in your code via static analysis. They help Perl developers remember to `use strict` and `use warnings`, they help JavaScript developers to find a sensible semi-colon strategy, and they incessantly nag Haskell developers to lose redundant parentheses. You don’t have to accept all of your language’s linter’s suggestions, but you should make sure you review all of the suggestions to catch any dumb mistakes

11. Does your documentation render properly?

Push any Markdown files to a private GitHub repo and check they render correctly. If your programming language has an embedded documentation format like POD, or uses method annotations for documentation, try viewing that documentation and check you haven’t botched it by a mistype character that throws the parser off

12. Have you triple-checked your code dependencies?

Code reviewing code that has incorrectly-specified dependencies is irritating. If you’ve installed libraries globally, it can be easy to miss that you’ve forgotten to specify them in your code as well. Consider spinning up a virgin AWS instance and checking you can install and run your code on to check

13. Have you removed any extraneous dependencies?

In the process of developing anything, I generally use libraries that I don’t end up using by the time I’m finished. If your code reviewer is like me and starts by looking at the dependencies to get a feel for how your code might fit together, you’ll confuse and frustrate them if you’ve left in a bunch of dependencies you no longer make use of, and you’ll look sloppy

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.

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!

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.

When I was in grade-school math class, the teachers would always implore us to show our working. When answering a question, you wouldn’t always get to the right answer, but if you could show you’d approach the problem in the right way then there were still marks to be awarded.

You should take exactly the same approach answering programming problems in interviews.

Interviews are limited opportunities to learn about someone

As we covered in Can you pretend to be normal for up to two hours?, there’s not really that much that can be found out about someone in a technical interview.

The list basically comes down to:

• Can they answer questions about the skills they claim to have experience with?
• Can they present some evidence of their experience with those same skills?
• Are they capable of maintaining a façade of normality for at least a few hours?
• Can they – when motivated to – have a technical discussion where they respectfully listen to the other person’s opinion?
• Do you like them, basically?

Nowhere in the list is “have a dictionary knowledge of algorithms and perfectly solve all technical challenges”. Heck, three of our five bullet points deal entirely with just your inter-personal skills while answering technical questions. The other two deal with showing evidence that you know how to approach certain technologies.

The answer to any given technical question you ask is usually not that important. Getting to a right answer the wrong way — rote repetition of something you’ve memorized or just guessing around — is usually the wrong answer. Getting annoyed that you’ve being asked questions that you don’t think are appropriate is almost always the absolute worst answer.

Doing anything other than demonstrating how you think a programmer should approach unfamiliar technical challenges is the wrong answer. That’s what you’re really being tested on.

How to reverse a binary tree

Short interlude for one of my favourite tweets of 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

Let’s say that unlike the author of that tweet, you actually want to get a job. And let’s say you’re asked in an interview, “How would you reverse a binary tree?”

I’ve got an MSc in Software Engineering from Oxford and reversing a binary tree is not something I’ve ever had to think about it before. So … let’s instead show off how a programmer approaches an unfamiliar technical problem (other than StackOverflow).

What don’t you know, and what are you assuming?

Start by laying out what you know, what you don’t know, and what you’re assuming.

Let’s take a guess at what a binary tree is. Binary means a pair, and a tree is a data structure where objects link to other objects above or below them… So a binary tree is a tree where every object has two child objects?

Say this out loud and ask for clarification: “Is that what you had in mind?” Your interviewer probably wants you to succeed, and is likely to help you, so show your working.

What are the constraints?

What are the success criteria to think about here? Most technical problems can be solved in several ways, and the correct way to solve it depends on the constraints and practical applications of the question.

Start asking about those constraints: “Are we optimizing for anything in particular here? Memory usage or speed?” They may give you a constraint you hadn’t even thought of at this point, and that’s a useful hint.

Test your thinking with examples

Do you have a whiteboard? Great! Start sketching out an example binary tree. What does reversing it even mean? Try a three layer tree and draw out what you’re starting from and where you’re trying to go to. If you’re on the wrong path, you’ll give the interviewer a chance to make a subtle course correction for you at this point.

White-boarding is often a great way of solving technical problems in the real world, and is going to help your brain start to narrow down solutions. We’re trying to show off we know how to solve problems, remember?

What would you need to look up?

You’re not being employed as a walking encyclopedia, so if there are specific things you don’t know or can’t remember, highlight what those are rather than hiding the rest of your knowledge behind small ignorances.

Do you think your method will take an amount of time that’ll grow linearly with the number of elements but don’t remember the technical name for that relationship? That’s fine! Explain it in English.

Does your solution use recursion, and you know there’s a way that some languages optimize recursive operations, but you can’t remember what it’s called? Not a problem! Show your thinking, say what you’re thinking. It’s natural to forget things, but you’re not going to lose many points for having forgotten the term for “tail recursion” if you know it exists.

Say exactly where you’re getting stuck

Does your solution create circular references in a garbage-collected language? Admit it, and be honest that you don’t see the solution, rather than hoping they don’t notice. Is there a feature in that language that would help and you don’t remember what it’s called and how it works? Mention all of that. Your interviewer almost certainly wants you to succeed and will probably give you hints and help you get unstuck, but they’re not psychic. A problem shared is a problem halved.

What are the failure modes

What should you do if there’s a node “missing” in the binary tree? What should you do if you’re given a tree with a single node? Think about what unusual or erroneous input and starting conditions would look like, and reason through what you think reasonable solutions would be. Some interviewers won’t care what behaviour you choose but will be glad you’re thinking about it, and some will want it solved in a certain way.

Thinking about edge-cases is also a trait of an experienced developer, and you’re using this whole process to show that you’re an experienced developer!

Please show your working

Showing your willingness and ability to think is far more important generally than solving a specific problem you’ve been shown.

I will hire the person who had interesting insights in to the problem but got stuck on something because they were nervous, but a person who just sits, assumes, and writes code without discussing the problems they’re trying to solve is a red flag as a future colleague, and that’s assuming they produce a right answer the first time!

The more you understand the process of an upcoming technical interview, the more you’ll be setting yourself up for success. The more you know what to expect, the more confident you’re likely to be in the interview itself.

What’s below is a list of things I’d recommend trying to find out before the interview. Some of it you might be told proactively, and some of it you may need to ask for. You may not be able to get answers for all of it, but it can’t hurt to try.

You should ask these questions to whomever is setting up the interview for you. That might be an external recruiter / headhunter, that might be an HR person at the company, or that might even be a technical employee at the company (see: Interview Gatekeepers).

Who Will You Be Meeting?

Find out who you’ll be talking to. Are they technical? Is it your future boss? Will you be meeting an HR person for soft-skills?

Try and find them on LinkedIn, either via job-title or name. Do you have any shared connections you could talk about with them? Have you worked at the same companies before? Maybe you went to the same University.

Are they on GitHub? Maybe they’re the only other INTERCAL developer in your city. Maybe it’s useful to know they’re a core-contributor to Magento before starting your customary rant about how PHP developers should be hunted down like dogs.

But … don’t contact them. It’s legitimate to try and find out a bit more about the people to whom you’ll be talking in an interview, but you should keep your actual communication with them inside of the interview context.

Technical Test?

Will there be a technical test at some point in the process? What form does it take? Is it a take-home, white-board, will they give you a computer and ask you to produce something? Is there anything they can do to prepare?

Some companies are happy to be upfront about which areas of your knowledge they’ll be poking into. You probably don’t have time to ingest an algorithms book, but making sure you’re not too rusty on any skills mentioned in the job-ads “REQUIRED SKILLS” section would be a good idea.

Structural Overview

Is this the first interview of several? Is it going to be a phone-screen followed by two days in-office? You might not want to talk salary in a first interview, but if the first interview is also your only interview, you probably don’t want to skip the conversation all together.

Knowing how the interview fits together can help you gauge how well you’re progressing through it too — if you appear to have skipped two interview stages, perhaps ask for more money? If you seem to have stalled after a phone-screen and nobody’s talking about a follow-up then perhaps it’s time to see what else is on the market.

Prior Preparation and Planning

If you’re working with an external recruiter, they should really have all this information at their finger-tips, although not every recruiter is diligent as we might prefer. It’s entirely within your rights to ask these questions, although bear in mind that they may not know exactly who you’re meeting — I’ve worked at no shortage of companies where this isn’t decided until 15 minutes before the meeting based on who’s free!

Every company sucks at interviewing. Plenty of companies (and individuals at companies) think they’re really really good at interviewing, but mostly they’ve just gotten lucky.

You’re never going to learn in a 2 to 12 hour interview programme what it’ll be like to sit next to someone day to day, share large bodies of work with someone, or rely on someone in a professional context.

In fact, there’s very little you can learn about during an interview.

What you can learn about a candidate during an interview

Can they:

• Maintain a façade of normality for at least a few hours?
• Have a technical discussion – while on their absolute best behaviour – where they respectfully listen to the other person’s opinion?
• Answer questions about the skills they claim to have experience with?
• Present some evidence of their experience with those same skills?

and … do you like them, basically?

THAT’S IT.

And therefore, as a candidate, you have some very very simple and straightforward goals while being interviewed:

• Provide evidence of having used those tools you claim experience with
• Try and not be too weird for a few hours
• Don’t shout at the interviewer
• Make yourself appear likeable

Much of the content on this site is about providing evidence of your technical skills, and acing the technical part of an interview, so let’s quickly go over how to not appear to weird for a few hours.

Bad weird, good weird

I’ve been programming since I was 6, took time off from high school to speak at technical conferences, and have been commercially employed as a programmer since I was 18. Being a bit weird as a programmer goes with the territory, and everyone involved in the hiring process knows this. Weird is OK.

But there’s also bad weird, which is less OK. Bad weird is you cause messes that line management and HR need to clear up, and cause other people to do more work, less enjoyably, as a result of your being employed.

Wearing Vibram Toe Shoes and having a sub-dermal magnet are par-for-the-course weird, and may well endear you to future employers and coworkers. Turning up 40m late for the interview in shorts and a t-shirt and starting the interview with a small lecture about how you’re not going to accept payment in “unconstitutional fiat so-called money” is bad weird.

Signs that you might be bad weird

Unwillingness to put up with small amounts of corporate bullshit

The nature of companies includes small amounts of corporate bullshit. Sometimes large amounts of corporate bullshit, but generally small amounts. Examples of corporate bullshit at my last real job:

• Marketing insisted on a photo of all employees on the website
• HR insisted on using a terrible system for booking holidays
• Finance insisted on a weekly timesheet for developers breaking down how many days were spent on each project

Some small companies do manage to do away with corporate bullshit entirely, and some larger companies try really hard to pretend they do (and then it leaks out in the form of structure-less management or unlimited holiday days that aren’t), but you’re going to face some degree of it almost everywhere.

And some employees will spend a lot of time and energy complaining to their immediate line manager — who’s usually empowered to do precisely nothing about it — about it. It’ll come up at every weekly review, it’ll come up in response to mandatory security training, it’ll come up at every team meeting. And it’s a huge waste of everyone’s time.

Side note: some things are absolutely worth shouting about over and over again to anyone who’ll listen: discrimination in the workplace, genuine health-and-safety issues, abusive relationships in the workplace / bullying. Notably not on that list is “the holiday booking system is cumbersome”

However technically gifted you are, it’s entirely possible to be a net negative to a team through constantly complaining and arguing about virtually everything. These people exist, and your interviewer does not want to hire them.

Employers won’t explicitly ask you if you recognize that there are rules in a workplace, and if you accept that you’ll have to put up with a small amount of corporate bullshit, but they will:

• Make a note of if you’ve shown up to their interview looking like you’re going to a business meeting, rather than with baggy shorts and a ripped t-shirt
• Be concerned if you’re late to the interview
• Look unfavorably on your spending an hour complaining about how your last employer wouldn’t let you run a Tor relay in the data center
  

  Inability to avoid (technical) arguments even while on your best behaviour

  An interview is your opportunity to sell yourself to a potential employer. You’re expected to know this, and act accordingly. *Your behaviour in the interview is expected to be your best behaviour*. If you can’t last two hours without getting into a petty and pointless technical argument, being condescending to your interviewers or throwing your toys out the pram because you were asked an algorithms questions, that’s a bad sign that you’re going to be a real pain to work with and manage.

  I suspect the people who passed on this guy:

  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

  … probably don’t regret it, having read the tweet.

  I’ve been asked some truly shockingly poor quality questions in interviews by some truly bizarre interviewers, but it’s a mistake to try and read too much into a company simply because one of the people the hiring manager picked to interview you has a favourite algorithms question he likes to ask to make himself feel intelligent.

  I was an interviewer once where a co-interviewer asked our candidate — in all seriousness — which the better band of The Beatles and The Rolling Stones was, and was expecting a serious answer. No deeply meaningful information about the company, work environment, or role, was passed on in that moment. It was a misguided rephrase of a (more interesting) product management question.

  Looking a little confused and asking follow-up questions makes you look like you at least know what being a compassionate, understanding, and thoughtful coworker looks like, and can pretend to be one when you need to be. Getting defensive and asking aggressively what relevance that question has to the job — while you’re meant to be on your best behaviour — just makes you look like an ass.

  A skillful technical interviewer will ask your questions that are a matter of opinion, and then challenge you politely on your opinion. The correct answer is explaining how you came to your answer, and to show an ability to understand that other opinions can exist, and that most technical decisions have trade-offs.

  You will almost certainly also meet bad interviewers with poor quality questions, but you’ll still be judged on your ability to keep your cool, make the best of the situation, and not berate your interviewer for wasting your time…

  Deep-seated and poorly hidden anger about previous coworkers and employers

  I’ve worked places I didn’t enjoy, and I’ve worked with people I hope I’ll never see again. I’ve interviewed places because I was desperate to get out of the toxic environment I was working in.

  And you’ll often get asked about these in interviews:

  “Why are you moving on from your current employer?”

  “Describe a difficult situation with a coworker, and how you recovered from it”

  These are a great opportunity to show how you’re like Rocky, and how you’re on a journey that included overcoming adversity with an open heart, rather than how you’re like the guy from Silence of the Lambs, and will carry your employment trauma with you forever to the detriment of those around you.

  This bit’s really important, so it’s in bold: under no circumstances make disparaging comments about your current company, as the interviewer has no way to know that you’re not the problem you are describing. Plus, if you can’t show you have the social skills not to trash the last company you worked for, that’s a big red flag, and you’ll look like an HR liability.

  Safer answers are specific things that you’d like to see in a new role, couched with an understanding for why things were how they were in the old role, eg:

  Is the codebase of your last company literally a festering sore that’s burned into your retinas? How about:

  “Much of my last employer’s codebase was built to try and satisfy customers and get the product to market as quickly as possible, and obviously corners had to be cut in order to achieve that. However, for me the trade-off was a little too far, and I’d like to work somewhere that considered code quality to be an important attribute in its own right”

  Was your last boss a control-freak who’d check your commits out of source-control if he didn’t like the indenting? How about:

  “In my last role there was a very strong technical hierarchy, and there wasn’t always an opportunity to engage in technical discussions about the right way to solve problems. I appreciate that you can’t always do everything the way you want to, but I believe I’d enjoy a workplace where I had more freedom to bring my skills to bear”

  …

  Your goals, in summary

  Interviews are not a good way to find out how good a coworker will be, but they can give you a pretty good read on some of the soft-skills. You are trying to not eliminate yourself by showing you at least understand those soft-skills exist, even if you’re not a master of them.

  In particular:

  • Try and not be too weird for a few hours
  • Don’t shout at the interviewer
  • Make yourself appear likeable

  Good luck with not being bad weird…