Do Not Ask Me About How Interviewing Works

It is very easy to get information about career progression in the software engineering world, but very hard to get good information about it. To understand how the various problems collude to stop us learning about our own career paths, let us start at the beginning.

I could tell you about my own experiences as a junior engineer (and as a candidate applying for those roles), but it is so long ago now that everything has changed. The technologies (to some extent, though in fact the popular languages of today are all the popular languages of back then) have changed. That first job I had as a sysadmin, which gave me the space I needed to learn about programming technologies and some problems to which to apply what I learned, I got by gaining access (physical or remote shell) to various computers by vendors who have long gone out of business and working out how to make them talk to one another.

But that is not all that has changed. The corporate cultures, and expectations, have changed too. I failed a Software Engineer in Test interview in Google back in my junior days because I did not have a Computer Science degree and they asked me a question which was a reification of the Traveling Salesman problem. They did not want me to try and whiteboard my way to a solution, like most interviewers would, they wanted me to already know that there was not a solution. I understand that Google have changed their expectations over the intervening decades.

The first company I was actually a software engineer for used a waterfall project management lifecycle, with projects across multiple teams organised into massive programs that were planned to take 100 people two years to complete (and invariably took at least 3.5). I may have been paid for my Objective-C skills but I made my money by learning to exchange header files and UML diagrams with people called “systems engineers”, whose exact responsibilities I was not certain of. Despite not understanding the system I could still survive within it.

And of course, I have changed a lot too. My recollections and reminiscences about those early days on the job are told through the rear view mirror of my later experiences, shaped by the person I became and my journey from there to here. The things I think are important now, I will tell you were important then, whether or not they were. For example, that first job where I got all the obsolete computers to talk to each other? I borrowed those computers from the guy who held the post before me, so I was learning to network in two different but both important ways.

Finally, we must realise that nobody on either end of the hiring process has much of a clue about what works. This is particularly true of hiring junior engineers, but hold that thought while we take a little look at why.

There are a few different examples of evidence you can gain about a candidate when you are reviewing their CV and interviewing them. There is credential evidence: what training do they have? Who gave that training? Is it up to date? What did it cover?

There is experiential evidence, which is quite broad. It overlaps a bit with credential evidence (if you rate Microsoft as a software company and this candidate has a couple of years of experience at Microsoft, that is effectively a certificate of Microsoft-worthiness). It also covers what they say they did, and what you can discover about what they actually did.

Then there is practical evidence, which a lot of software interviews focus on: how do you solve this problem? This can be done well (two interviews for different organisations that I took involved diagnosing actual customer support problems) or badly (reverse a linked list on a whiteboard).

And finally, the two more problematic ones: hypothetical evidence (“if you were asked to do a customer demo and the software crashed on launch, what would you do?”) and personal evidence (there is a person sitting in front of you answering all your weird questions, what do you think of them?).

The problem you have interviewing a junior is that they likely have little in the way of experiential evidence: “have you ever X” is likely to be answered either with a straight no, or with a possibly-relevant story from some non-engineering part of their life (which does of course tell you something about how they handle abstractions).

The few people at the junior level who do have plenty of experiential evidence are the privileged ones who got access to the trammels of software engineering – computers, quiet time, documentation, permission – and could make it their hobby. Making use of this evidence is both entirely natural and a source of demographic bias in your hiring practices.

And the credential evidence they can supply is likely to be similar to all of their peer candidates: they have each just graduated or completed a coding academy, leaving nothing to pick them apart.

Interviewing, and thus hiring, at this level is a difficult and highly variable proposition. Therefore anything you learn about recruiting or being recruited as a junior engineer is heavily tainted by survivor bias: I got the job, I did this, ergo doing this lands you the job. Well, maybe. It has long been the case that there is both a healthy demand for, and supply of, junior candidates, so it is no surprise that the interviewing system for juniors is deeply flawed. Weed out the dangerous candidates in interview, hire the questionable ones—then turn them into the employees you want or manage them out.

Does the situation get better as you go up the scale? Well, let us ask the other question: is there a scale to go up?

We have already looked at the management track, in our previous issue. It has significant flaws. But what about the technical track? Again, it is flawed, and again, the reason is survivor bias. Did you get that senior (Latin for “old”, as in senile and senescence) role because you were fulfilling the junior role’s expectations at a greater rate than other juniors? Or because you were doing bigger things than the other juniors? Or because there is an expectation of title inflation after a few years at your company, like a long service medal?

I will tell you how I got my first promotion. I was a software engineer at a company with around 100 Windows folks, and a Mac team of three people. I was the one with any experience of a Mac–both user and developer experience. Not very much developer experience, and I was not a very good developer, but still I was naturally the one person who could answer questions like “how do you do X” or “how much work is it to Y”. De facto that made me the technical lead over the senior engineer with five years on the MS-DOS product and the new graduate: that coveted “senior” title was mine.

There are other ways to get it. If the company you work for is small enough you can be the CTO or President of Engineering just because they need their one coder to be the CTO whenever they go to a conference. But typically in larger organisations there is some length-of-service requirement: it is illegal to ask about years of experience (as a proxy for age discrimination, the one kind of discrimination that white men can find themselves on the receiving end of and thus the one that is taken seriously) so instead we make up a title progression and then ask what your job title is. We cannot distinguish ten years of experience from one year of experience, ten times over, but we are not trying to.

You may well be angry at this point. I have told you that my career path is contingent on my privilege, being the right sort of person, who knew the right other sort of people, in the right place, at the right time. And I have told you that there is nobody behind the curtain, no objective system that I have somehow gained: it is all privilege, network, and dumb luck.

Well, it is. You might hope that there is some technical component, like if you learn the correct programming language or cloud platform it will open up new opportunities. It will! It will open them up by getting you to user group meetings where you encounter people who want to hire in those technologies. Or by answering questions on the forums until someone asks you to come in on a contract. Not by providing you with technical skills that get objectively weighed up in an interview, that is complete fiction.

This tells you a little bit about how to view your career trajectory: as a social game in which you make your own luck until occasionally that luck pays off. But, more importantly, it tells interviewers and hiring managers what they can do to fix the broken software engineering job market.

For a start, ask whether you really need to hire more engineers. If you are hiring because your team cannot keep up with the defect rate, change your process before hiring more defect introducers. If you are hiring because your team cannot keep up with the feature request rate, fix your product managers before giving them permission to bump velocity to meet the “new capacity”. If you are not hiring for any of those reasons, check whether your VP Engineering is mistakenly using headcount as a proxy metric for their own importance.

So you have decided you do want to hire an engineer. You can begin by hiring outside your network. You have already, by definition, got employees like that, you do not need any more (unless your company is a sweatshop/feature factory and you just need another interchangeable code typist).

Secondly, recognise that your hiring process is likely deeply flawed. Offer fair mutual flexibility, accept that any candidate’s best position (for them and for you) may be outside the company, and support their growth whether that is through your career track or off into the wider world. If they leave with a positive experience of working with you, you have just grown your professional network, increased your attractiveness to other recruits, and helped someone along in their careers.

Photo by Hello I’m Nik on Unsplash.

Continue reading Chad Fowler or go back to Issue 034: Job Market. Did you like this article? Consider subscribing to our newsletter or contributing to the sustainability of this magazine. Thanks!