Tech Transition — pairing tests and good rejections.

How not getting the job was invaluable in starting a new career path.

In the last year I decided to abandon my career in project management to move into the tech industry, with the hope of becoming a Software Developer. Coming from a non-technical background, this hasn’t been the easiest of tasks, but I’ve been employed as a Software Engineer since September 2019. I’m learning how to navigate a brand new career path, being the only non-male on the engineering team, and not necessarily having a clue what I’m doing at least some of the time. Career changes are challenging and exhausting, but don’t let that stop you.
Read how I started here.

Photo by John Schnobrich on Unsplash

It’s more than a little daunting at the age of 29 to start applying for jobs you have no prior experience in. I was used to being the person with the expertise, the one running the projects, hiring and training the team. To start looking for something where you know you’ll be right back at the beginning is pretty terrifying. Factor in that I knew I would have to relocate from the town I’d lived in since I was 18, it became a big life changing task.

I applied for everything. Everywhere. Manchester was my starting point, but soon I was applying for jobs in Leeds, Glasgow, Edinburgh, Bristol. I knew I didn’t want to move back to the south, but aside from that I was open to everything. I honestly couldn’t tell you now how many applications I submitted. I was applying for Junior roles, Graduate roles (a bit of a stretch 8 years after graduating…) — essentially anywhere that I thought would take me as a work in progress and allow me room to learn on the job.

I had a lot of rejections and a lot of no-responses. But I did also have a lot of experience of getting beyond the initial application. Many companies have multistage application processes. There are pages and pages in one of my notebooks full of scribbled problem-solving test notes. I had to record a video interview answering questions to no one but my laptop camera (a truly bizarre experience). Then there was a Skype interview with a woman in Ohio, interviewing me for a role in Glasgow, who had little idea about the role or my experience. And at some point I completed a strange “morality” test asking things like whether I would report a colleague who was late for work three days in a row. I think I may have been too honest on that one — they didn’t get back to me (but if they were expecting me to say I would then I don’t think I would have wanted to work there anyway…).

But all of these different assessments and interviews also gave me an idea of the sort of place I wanted to work too. Some of the companies bragged about their strong corporate ethos and formal dress code. Coming from a workplace where choosing to not wear trainers was considered dressing smartly, I wasn’t sure that was for me.

I was compulsively applying for everything that came up, beginning to wonder if I was being too ambitious. And then, following a phone interview, I got invited to an actual face-to-face interview with a well-known company in Manchester. This was also when I first found out about pairing tests.

Up until this point, I had been diligently working through Python courses, and starting to feel like it was my thing. My upcoming day long assessment involved a group task with the other candidates, a values based interview, a technical discussion (where I needed to come prepared having reviewed their app and thought of improvements or suggestions) and a pairing test. In JavaScript. After being involved in hiring people for a few years, the thought of the interview didn’t phase me, and team tasks were nothing new. Reviewing the app would take some time and work, but I was comfortable with that. But a pairing test in a language that was not my current focus… that posed a challenge.

I should say upfront — I did not get the job. The feedback was fantastic and I thoroughly enjoyed the experience and would have totally loved to have worked there, but ultimately it came down to the pairing test and that was highlighted as my weakness on the day.

If you’ve never encountered a pairing test before, essentially it involves being faced with a problem and given a set time to provide a solution. In my case, it was something along the lines of ordering a list of words alphabetically and only keeping words that involved a certain string of letters. You’re paired with another developer and you work with them to write a solution. There’s also usually a second developer there observing.

I am by no means qualified to give good advice on how to tackle a pairing test, but that being said, there are a few things I would definitely do in future.

1. Write pseudo code if you’re not sure where to start. Generally speaking, you’re not being grilled on your syntax, more how you approach and tackle a problem. I was a JS noob and the added pressure of being assessed meant I was spending more time worrying about whether I was writing Python or JS than actually thinking of how to solve the problem. Get your ideas down first, then write the code.
2. Ask if you can Google things. Everyone I work with does this on a daily basis, from new starters to senior devs. You’re not expected to know every function and library out there — if you ask if you’re allowed to use Google then you’re showing that you are willing to search for an answer, not give up because you don’t already know. If you’re told you’re not allowed to, then maybe consider what they’re trying to test and if the role is one that you’d want…
3. Communicate. One of the biggest aspects of pairing (both in tests and in work) is to communicate with the other developer and work through a problem together. Be clear about what you’re thinking and don’t be afraid to ask questions either. You could sit in silence for the duration of the assessment and produce a perfect solution, but it doesn’t show much about your ability to collaborate.
4. Don’t be afraid to admit to not knowing something. At the most basic level, the machine I was given to use was a Macbook, and I’d hardly used one before. I didn’t even know that you use a different key instead of ctrl. This did nothing for my confidence, but I was honest about it from the start. So at least there’s that…
5. Do some practice tests beforehand. This is probably the best thing you can do in terms of prep, so that you at least know what it’s like to be faced with an unknown problem.
6. Don’t forget to test your code as you go along. Testing is key in all aspects of development, so don’t forget about it when you’re facing an assessment. It allows you to work towards a solution, making changes as you go along and fixing any errors.
7. One of the biggest issues for me was not having enough sleep beforehand. I’d stayed overnight in a hotel, got nervous disturbed sleep all night and then unfortunately was picked to do the pairing test first. I still feel like I may have done better if I’d had the interview first and had time to get rid of those initial nerves, but lack of sleep was definitely not helping me. I don’t have a solution to that one, but I guess I got unlucky on this occasion.

Any kind of assessment is daunting, particularly where it impacts on whether you get offered a job or not, and even though it didn’t work out for me on this occasion, overall the day was really great. It helped me get an idea of the sort of place I’d like to work and what to expect from a full-on interview process. So even though I didn’t get this particular job, it was an invaluable experience. I came away feeling validated — there were things I needed to work on, but I was seen as employable in a field that was brand new to me. Personal growth and experience aside, I was still gutted to not be able to work there. But the next two companies I interviewed with both offered me positions and I now had a better idea about the sort of company I really wanted to work for.