by Marilyn Magnusen

Crossing The Bridge: How to Transition into a Career in Software Development

3EHodgieEa9qowG7OIDgV8UiHxsG045J7n48
Photo by Mark Basarab on Unsplash

I’ve been learning how to code for some time, mostly as a hobby in the evenings and weekends. It went from a couple of hours a month to replacing my Sudoku addiction.

One Saturday, I was sitting in our office (I used to go in and make use of the comfy sofas, unlimited tea, and stable wifi). I had one of those moments when you look at yourself from the outside and realized that instead of doing normal things on a hot summer afternoon, I was alone, inside an office, glued to my computer.

It was then that I decided to make the leap to become a full-time Developer. I’d never had something I enjoyed and could market as a skill in the workplace.

After a few months of juggling learning and work, I left my job at a software start-up to focus on learning full-time. People around me said how brave I was for pursuing my dream, but the looks on their faces plainly said I was crazy to give everything up for an unknown. I’d be lying if I said I wasn’t **very** scared.

The plus side is that taking away your parachute suddenly focuses you. It’s not a case of “this might work,” it’s a case of “this has to work.” There was no plan B.

It’s taken just over three months to accept my first role as a Software Developer.

These are some of the things I wish I’d known before, and will hopefully help anyone looking to embark on a similar journey.

Know your why

Why do you want this? This has to be the most important question. Sure, everyone knows about unicorns, IPOs, unlimited beer and an array of perks. This isn’t enough to keep you going when you’ve been staring at the same error for the last 15 minutes or hit a road-block and have to find another solution.

What’s the ultimate end-game? Do you eventually want to run your own company? Or freelance? Or head-up a Development team? Do you want to get more cats online? (Which is totally fine). Or do you want to change the world? Whatever your motivation, make sure you really understand it and hold onto it for dear life.

Do the work

The great thing about software is that it’s mostly meritocratic. It matters less and less what your academic qualifications are, (sensible) employers only care if you have the right skills or the ability to learn those skills on the job. Use this to your advantage.

7l5EWinZp1j3oLQuT6DdMuULfH2oltthwhtC
Image from UKBlackTech

Regardless of whether you choose front-end or back-end, take the time to really understand the core concepts. Focus on learning the vanilla language instead of relying on frameworks. A solid understanding of something like JavaScript will equip you to learn any JavaScript framework, but the reverse isn’t true. You’ll be caught with your pants down when it’s time to debug and you don’t know if it’s the framework or your code causing the issue.

Show your work

You must have work to show. If you come from a computer science background, you have a qualification to show what you’ve done. If you don’t have any formal qualifications, this is even more important. Just turning up to ask for a job isn’t going to cut it. You need to be able to show the code you have written, (ideally something more substantial than a tutorial on a blog).

Show how you’ve tackled real problems and the path you took to get to your end solution. You don’t need to have dozens of projects — quality is more important than quantity. The first interview I landed was based purely on what they’d seen from two projects on my GIT. It was a steaming pile, but I could explain every line, what it did, and why I took certain decisions.

Don’t be afraid of interviews

1ni90KzjpzhjBtgFzCypya4jZkcwHvdxkRLu
Image from UKBlackTech
The only way to get better at interviews is to do interviews.

This is a piece of advice I got from a Developer friend of mine at the beginning. It sounds like a chicken-and-egg situation, but you can make a start by practicing at every opportunity.

There are services like interviewing.io which will help you practice. Talk to people you know and look up common interview questions for Junior Developers online. There are even YouTube videos which will help.

You won’t be expected to do a white-board test as a junior, but you will be asked to explain concepts or address different scenarios in your own words. They aren’t trying to catch you out, they’re giving you the opportunity to shine and show what you do know. If they ask you about something you don’t know, make a note. (Yes, I actually kept a notepad/my laptop with me during interviews to jot things down).

At the end of the interview, ask them about some of the things you weren’t quite sure of. This will show you’re keen to address gaps in your knowledge and help your own understanding. The best interviews I’ve come away from have always left me knowing more than I went in with.

It’s a two-way street

You should be assessing them as they are assessing you. If you were to work there, would you be happy and successful? How clearly written is the job spec? Are your emails replied to in a timely manner? Are they happy to answer questions, or are they defensive on certain topics? Do the people in the office seem happy to be there, or do they have one eye on the clock?

The aim is not simply to get a job, it’s to get a job which you’ll love, which will allow you to grow and get better at writing software. I ended up declining an offer to move onto the second stage of one interview process because I didn’t think they could support me as a junior. Three years + and it probably would have been fine, but I didn’t get the impression they’d have the time or resources to support my learning as a new Developer. These are the type of things you should take into consideration.

Ask for feedback

Ask for feedback at every opportunity. You’re unlikely to get feedback just for submitting an application, but you should be aiming to get feedback on every interview. This will help plug your weaknesses. Write an email asking about them if they don’t offer any up. When you finally land your first role, you’ll need constant feedback to improve, so this is a good habit to get into at the start.

We seem to be genetically programmed to be adverse to any type of social interaction involving potential awkwardness/negativity. This type of thinking will kill your career and your growth. You wouldn’t expect to merge without a code review, so how can you expect yourself to come out the other end without going through a similar review and feedback process?

Learn how to work with an existing codebase.

This one is particularly painful to talk about, but I do so in the spirit of helping others.

One of my interviews was with an amazing agency who was doing work for brands I could only dream of. They mentioned that they work a lot with SASS so I spent hours reading up and practicing.

When I got to the interview, the code challenge was fairly simple: create a feature within an existing codebase. This may sound crazy, but editing code others have created requires a different skill-set to editing your own code. It’s like opening a book that’s half-written and trying to finish the story yourself.

I realized that the first time I had ever worked with code someone else had written was there and then at the interview, and it caught me off-guard to switch gears. It’s like that nightmare you have when you have to take an English exam and realize you’ve studied the wrong book and wake up in a sweat. But instead of waking up, you have an hour where you have to type something. Anything. There’s literally no way out, not even a fire-escape or a poorly constructed window.

5dmvZEVbhJdcyIKyNJXkVvHLfvr0IxYU982r

Try and practice working with existing code as much as possible. Do hackathons, take part in open-source projects, or even get together with any other programmers you know and find something small to work on. The irony is that after I’d gotten back and dried my eyes it was fairly easy to create from scratch, I just couldn’t get my head around something that had already been started.

It’s ok to not know

Do not be afraid of what you don’t know. One interviewer asked me to rate myself on a scale of 1 to 10 on my front-end knowledge. I was honest and said that at the start of the process, I probably would have said about 4. But after all the work I’d been doing, I’d probably put it at 1.

This wasn’t to self-deprecate, it was because every document or article I read introduced me to about 10 new concepts. So the more I learned, the more I realized how much more there was to learn. As a Developer, you must make your peace with the idea you will never know everything. There are new languages, frameworks, and technology being born every day. You could read 24/7 and still not scratch the surface.

Have the right attitude

In the end, the feedback I got from the job I accepted was that I was the least qualified of all the candidates (too true, seeing as I had exactly 0 years of experience). But I more than made up for it in enthusiasm and I seemed like the type of person they’d actually want to work with.

There’s little you can do about your experience or qualifications in the beginning, but what you can do is give yourself the best possible chance of putting your best foot forward. Talk about things you’ve done and show your passion for the role. This can include articles you’ve written, events you’ve been to, books you’ve read, or even podcasts you love that are related to the field.

Forget the perks, buy your own doughnuts

A lot of software roles will be offering numerous perks to entice Developers. I’m not going to pretend they’re irrelevant. But at this stage in your career, they should be. The most important thing should be the actual team you’ll be working with and the opportunities for training and development. Do they do code pairing? Peer reviews? Is there time set aside for personal development?

3uHBNbdQaibke2f17lYoENB1NmANraLQ9MCb

In years to come, when it’s time to make your next move, you’ll need to be able to demonstrate what you know, now that you’re a Developer with X years of experience. They won’t give a rag what you were paid in your previous role or how many free perks you devoured. But they will be impressed if you can show all the new technologies you’ve learned, how you worked to solve different problems, and what you’ve done to aid your learning in your first role.

By focusing on perks when it’s time to accept an offer, you’re selling yourself short and may as well work for magic beans.

Make your network.

UzfnbvW-uy7E25VE3dhHYr4rjAIrxxeV0Onh
Image from UKBlackTech

I was lucky to come from a software start-up and to live and work around the software hub of London. It’s brimming with meetups and groups. Codebar is probably the best thing I’ve been part of. They not only pair you with Developers to learn, but it’s free, they have awesome talks, you get access to industry insiders, and it’s a completely non-judgmental environment where you can ask anything.

If you live somewhere similar, please take full advantage and get out there and meet people. Yes for the networking, but more importantly because what you soak up in those surroundings will pay dividends several times over. Hiring managers also love being involved in the community, and your next employer may well be presenting at the next meetup you attend.

We need you as much as you want this

The imposter syndrome is well documented and certainly something I suffered from in those moments of self-doubt. There are thousands of people graduating from CS degrees and bootcamps — was I unrealistic to even attempt this a career only knowing what I’d taught myself?

The truth is that there aren’t nearly enough Developers to meet the demand of open jobs. As long as you have the core skills, the right attitude, and a willingness to learn, you’ve got a shot. Employers can’t afford to hire based on qualifications alone.

This next part is a little touchy — the diversity issue. Anyone who doesn’t live under a rock knows that tech has a huge diversity issue. When I started applying, I couldn’t help but notice that every team lead I looked up on LinkedIn was male.

The truth is that not once did I ever feel like I wasn’t welcome or wouldn’t be respected as an equal member of the team. Every interaction I had, I felt as if each of these teams were holding out a hand wanting me to be successful. I now truly believe most companies want to increase the diversity in their teams and are active in doing so.

If you don’t fit the stereotypical mould of what a Developer should look like — so what? Technology wants and needs you. It’s a big table, and there’s enough room for everyone.

If you’ve enjoyed this post, please clap to show your appreciation.

You’re also welcome to leave a comment below.

Find me on twitter: Marilyn Magnusen