This is a repost of my original 2017 blog post. It maybe a little outdated.
I recently got my first developer job as a Quality Assurance Engineer at a company called Modern Message and I want to share a few tips on things I did to help me eventually land this job.
I’m a student at Bloc which is a remote, self-paced developer bootcamp. I managed to pick their longest track called the Software Engineering Track.
It’s a Numbers Game
When I was searching for a job, I assumed 5% of my applications would result in a job. That’s a conservative number I think, I don’t even remember where I got that from, but it gave me a goal. So let’s assume, that stat is correct.
If 5% of your applications result in a job, lets say 20% actually call you after applying. This is great news. That’s 20 out of 100 applications. That’s 20 opportunities. If your working hard, just 1 of those opportunities is enough.
While I’m sure that the actual stats are much different based on a very large number of factors, that stat still is some number though, which means each application you send out, gets you one step closer to the employer that’ll make you an offer. Keep this at the forfront of your mind, cause finding your first gig can be real up hill struggle. Just remember, each place you apply, increases your chances of getting an offer. It may seem basic, but it kept me going after sending out my 120th application.
The Industry
There’s a few things that I felt like companies were really looking for when it came to finding candidates to work for them:
- Industry Fit
- Culture Fit
- Technical Fit
Industry Fit
A business wants to know you’re passionate about what you’re doing. That you’re keeping up with issues/news about the software industry. There’s plenty of places to get this info like HackerNews or Reddit. You can easily see trends and see the focus of people in the industry to gauge better what you should be learning about and what you can talk about in interviews.
ES6 was a new thing when I was hunting, so being able to at least discuss it, even at just a high level, benefitted me in a couple interviews.
Culture Fit
This is huge. Most software companies understand that programming isn’t a science where you hold all the knowledge in your heard about everything. Very few fields are that way. What’s important is that you show that you’re always willing to learn and accept feedback. This is especially true for junior level developers. Showing that you take initiative to grow in your field, and you can take criticism well will help take you a long way with potential employers.
Technical Fit
This is the most obvious, but should definitely still be stated. Learn to code. You don’t have to know everything, but understand the fundamentals really well. If you’re studying Ruby like I did, make it a point to study up on topics like OOP, inheritence, and even going deep-ish on a framework. All these things will just make you a better programmer, but they’ll also give you things to speak to in interviews.
It’s important that you just build things also. This gives you practice in integrating technologies, thinking about planning, architecture and system design. Just build something from scratch. If you’re not sure what to build, build a clone of a popular website. I think building a Pinterest clone was the first project I ever did. This will also give you stories to talk about in interviews.
Getting Started
I started my job search about a month into Bloc. I didn’t know much and had only built very small applications by following tutorials and stuff, but my mentor encouraged me to just start applying. I initiated my first iteration of a blog, got my LinkedIn all nice and up to date and started the long process.
The easiest thing to do when starting is to just sit down and clean up your LinkedIn.
- I made sure everything was up to date.
- I made sure my skills reflected what I was studying (Rails, Javascript, Ruby, SQLite etc…).
- I updated my profile picture to something that I looked relatively professional in but not “suit and tie” professional."
Mostly just basic stuff.
I then focused a lot of time and effort on my resume. I had it reviewed by peers, mentors, and anyone I spoke to that had seen it basically. I used Creddle for my first iteration before moving to something custom. Here’s a few things to make sure of:
- Only ONE page for my resume.
- I made sure I explained actual accomplishments under my previous employment descriptions.
- I put my skill list at the very top. (A lot of recruiters for companies aren’t that technical, so they are using template matching. I made sure the first thing htey saw on my resume were the words that would match the template they got from the engineering department).
- I put references on there as well as links to my Github and website.
- I listed “potential weak points” at the bottom of the resume, decreasing the chances it would get focused on.
A resume MUST be clear and concise, only focusing on whats important, not useless details about the Chess Club you were in in highschool.
This is the big point.
Network
Network, Network, Network. I can’t say it enough. I’m not the most out going person in the world, I can even be socially awkward in odd situations. But I had to really work at that. Mostly by just practicing what I would say, or listing out the questions I would ask before the interaction. A whole blog could be devoted to this I think.
Go to Meet Ups
At Meet Ups you can engage with people you already have a common interest in, making initiating conversation a tad bit easier. I recommend coming up with 3-4 questions you’ll ask upon meeting people, like:
- Where do you work?
- How long have you been programming with x technology?
- How’d you learn?
- What challenges are you encountering at work?
I did this to almost every person I met at Meet Ups.
Coffee
I asked about 8 developers for coffee in my job search. Through that I was able to get to know them, pick their brains and learn. Another engineer, Haseeb Qureshi has a great blog on this whole topic, especially networking. If you’re still reading this and not his blog (which is totally the wrong move by the way) here’s what I did.
I went to a Meet Up and asked one of the obvious experienced engineers out for coffee. He was very kind and obliged. I paid, and got to sit down with him for almost 2 hours just picking his brain. At the end I asked, “I’m really trying to get a job as a developer using x technology, mostly right now I’m just trying to get to know people and learn from them. Do you have someone else you can reccommend I talk to?”
I’ve heard of these leading to job offers and such, but I ended up just meeting 8 good solid, very nice engineers. It turns out engineers are just people who like to talk about what they do, like most people do. This not only brought a level of comfort meeting new people, but also helped me to learn about the industry in my area.
Practice
There’s a couple of things to practice when looking for developer job.
- Whiteboarding
- Answering Questions
Whiteboarding
This is some what of a controversial subject. It’s good to go into it with the mentaility of solving problems instead of actually coding. I did several whiteboarding interviews that involved dealing with collisions in hashes, implementing a method on a string like .reverse, and taking an algorithm and making it faster. All these are skills that can be practiced easily, but there’s a method which will give you great results.
- Find the problem
- CodeWars
- Cracking the Coding Interview
- Exercism.io
- Speak out loud as you try to solve the problem.
- Ask yourself questions about the data. ALWAYS.
- Ask yourself about output.
- Explain your thought process and theory before writing one line of code.
- Code and explain the solution
Using these steps will give you good practice for what whiteboarding is like. Most of the hiring managers I’ve spoken too, don’t emphasize the right answer as much as being able to solve the problem and communicate the idea behind the solution.
Answering Questions
It’s definitely in your best interest to practice answering questions about your coding skills. One of the questions I frequently rehearsed was “what’s a big challenge that you’ve experienced and how did you tackle that?” I came up with both a “soft-skills” answer and a “technical-skills” answer to that question. I rehearsed the answer over and over so I didn’t have to think about it much. I made it clear and concise, with enough detail to make sense, but not enough that I bored the interviewer to death. I’m sure a Google search can turn up hundreds of answers for questions that’ll be asked in an interview. Google it and come up with your answers before hand.
Cue the Offer
I was hell bent on meeting every Ruby engineer in the DFW area. I would frequently skip the local “hacknights” as I was intimidated by potentially letting a senior engineer peak at my super lame code. Thankfully, one night when I was supposed to stay home, I randomly decided to go to the hacknight. I went and met the CTO of the company I’d later get an offer from.
I think just personality wise we got a long really well and hit it off. I’m sure that building this level of rapport was a BIG part of how I landed the job. After talking about random things like (Minecraft), I asked his (and the other devs there that would later become collegues) advice on finding a Jr Developer rails job in Dallas. This lead to a great conversation about the open positions at Modern Message and I got an offer 2 1/2 weeks later.
I ultimately think that it was because I “practicing” building rapport with those other engineers that I was able to build rapport with Daniel and the other developers which ended up increasing my chances of getting the job.
It’s a Grind
It’s definitely a grind. My thoughts go back to my days of playing World of Warcraft… Anyway. I have a pending post I’m working on about my actual job search and how I organized it using a Trello board. This post is already too long.
Good luck on your job search and remember, network.