âźµback

Applying to my first dev job

A few weeks before COVID-19 really struck Europe, I applied for a job.

It was a 12-month, well-compensated programme offered by one of Berlin's biggest tech success stories, in which emerging software developers would learn as they worked. It sounded like an amazing opportunity, and they said they were specifically looking for candidates from demographics underrepresented in tech. I tick two of those boxes, so of course I was going to go for it.

Having never applied for such a job, though, I was really anxious. Would they just laugh at my application? I decided to take it step by step.

Make a brag doc

Shortly before hearing about this opportunity, I attended the wonderful You Got This! conference. One of the speakers, Gargi Sharma, talked about making a "brag doc" (term coined by Julia Evans). As someone all too wary of the dangers of neglecting the documentation of just about everything, I'd fortunately already made one before the end of the 2019, when I knew the review was looming. In German, it's called a Selbsteinschätzung. Start making your brag doc now because you never know when you're going to need it. No achievement or evidence of taking the initiative is too small.

Once you've written one application, that's half the job done

Even before this one showed up, I put off applying to certain jobs for ages, simply because I was stuck in a certain mindset. The mindset, I eventually realised, was this: I hate writing about myself when I'm not 100% sure I deserve the thing I'm asking for. In fact, I probably wasn't even 75% convinced.

This isn't something new that's come with my career change. I have a graveyard of Google Docs and Sheets filled with missed opportunities; clients I wanted to pitch my services to when I was still freelancing, literary journals I wanted to submit my work to, etc. Sometimes I managed a couple of lines, but then I'd procrastinate, thinking I sounded either pompous or pathetic. So either way, I couldn't win.

Even the day before the application to this job was due, I was freezing up. Finally, I submitted it at the last minute.

The prospect of applying for my first job as a developer was scary, because I felt not nearly qualified enough. I felt I had to reach a magic point where it was okay to even consider doing it, even though the whole idea of this position was to help people who'd not had a "traditional route" into tech.

You don't need to have your projects live and on their best behaviour

More fuel for the fire that is chronic perfectionism: of course I wanted to talk about the programming experience I'd had so far, but my biggest project wasn't live! It was fine on localhost, but deploying it was an ongoing nightmare that cost me most of my evenings and weekends.

This lead to so much frustration and beating myself up. I'd found a job I really wanted, yet I spent a full week driving myself crazy trying to fix my biggest project in a rush when I should have been writing a cover letter. Life is too short!

I'm not saying it's an ideal solution, but in cases like these, merely showing that you've been doing stuff on GitHub proves you're motivated. I handled it by making a note in the repository description that the site was currently down, but that I had the code, even if the finished product wasn't available. Like, seriously, it is better than nothing. There was nothing wrong with my code; it was entirely a hosting problem. Plus, it's not to be taken for granted that beginner developers even know about servers and self-hosting. So the fact I'd dipped my toes into that, I felt, worked in my favour.

Getting through to the next round

And clearly, my approach worked, because I was overjoyed and terrified to see that the company's recruiting department hadn't laughed at my application and moved onto the next one. They'd invited me to do a coding test! It was my first ever one, so I didn't really have any idea what to expect.

After putting it off for a couple of days — I was worried that once I opened it, I would have to finish it there and then — I finally looked at the test, which consisted of one "easy" task and one "difficult" task that "shouldn't take more than two hours to complete". I broke down the problem bit by bit, hashed out a few lines of code on my own code editor, tested it, and it worked, but didn't actually solve the problem described.

A catalogue of difficulties unfurled that weekend, not all of them directly related to the test: I tried to go to a fun Python event only to arrive and see it was full, I injured my shoulder (probably from hauling my laptop-laden rucksack too vigorously), and worst of all, the internet at home stopped working. My girlfriend created a hotspot from her phone data but it was no use: my morale was already at rock bottom. I woke up the morning after the evening the internet disappeared and cried about how shit I was that I was even having trouble with the "easy" question. Since it was fairly nice out for a February, we ended up taking the kitties on their first trip out in the rucksacks. That cheered me up.

Then I took a nap and didn't think about the test for the rest of the day, because I couldn't get online anyway.

It's easy to think that humans just fear failure, but a lot has been written about the fear of success that underpins many of our endeavours. I believe this is what was subconsciously holding me back, leaving me to not only send my application at the last minute, but also to mentally freeze up when it came to doing the test. I was preoccupied by what would follow if I somehow passed the test. Even harder, in-person tests? Realising the full extent of what I didn't know?

What I've taken away from the experience

All this has shown me that my CV is already strong enough to get noticed. That's no small feat when it comes to applying for jobs.

Also, you read about technical tests or technical interviews and might think they're a monolith. However, the best thing to do when applying is THINK ABOUT THE PRODUCT YOU'RE GOING TO BE WORKING ON and therefore what kind of stuff they might ask of you.
In this case it was actually rather opaque, because it was a fixed-length placement that didn't actually ask for any particular technical requirements from employees in the job posting. But if I'm honest, I was also so dazzled by this huge, cool company that I didn't put much thought to the actual things I'd be doing. On the other hand, the questions in the test didn't directly relate to it at all, which I would say also threw me off. I've heard a lot that technical tests should include tasks that would come up in a regular workday.

Most of all — and I've seen this a lot when reading up about technical tests — it was a time-suck. It didn't matter how long the company says it should take to complete it; tests like these creep into time you should be using to relax. It's just a fact. I used up a great deal of emotional energy thinking about the scariness of the test, which distracted me from harnessing my mental energy to acquire tangible skills that would lay the foundations that would enable me to complete such a test in the future. I saved the test (not to publish anywhere, of course) so that when I'm at a point where I am learning that, I can use it as a marker for how far I've come.

I also realised that leading up to the test, I'd been viewing everything through a web development lens and so had been expecting the test to reflect that. In fact, the test was pretty data science-y, which might have caused me to panic at least subconsciously. You see, I'd decided early on that I "wasn't a STEM person", scraped a pass at GCSE Maths, and I just have a lot of issues wrapped up in it all. When I finished high school, I swore I was never going to need it again... until I decided to change career.

So maybe, even though I am loath to admit it, doing this test — and preferably succeeding at it — was also about proving a point. Grappling with your own ego is a topic in and of itself, but it's true: the only person you should compare yourself to is the person you were a week ago (a month ago, half a year ago, etc.)!

Coming back to the ol' "fear of success" thing, since the test, I've noticed a recurring theme in my dev work; sometimes I write code and am scared of running it in case it works. Am I alone in this? In certain situations, getting an error message is comforting because more often than not, it shows you what you want to hear. It tells you the problem, and you can continue to surf the net, StackOverflow and Reddit, trying to find kindred spirits who've been there and can tell you what to do. In short, someone else is doing the heavy lifting for you.

Okay, that's not an entirely fair assessment, because programming in and of itself is heavy lifting. What's more, as Danny Thompson wisely says, being able to put your problem into searchable terms is key.

Conclusion

It's 2020, and things are sad and scary right now, but if a good opportunity comes your way, grab it with both hands!