Many years ago, I was working as a support technician at a university. I had a long commute to go through every day for a job I thoroughly hated, and there was no end in sight. Even with a technical degree in software development, I was faced with the harsh truth that I had specialized in something I was fairly good at, and moving to engineering would mean going through a career change, as if I had no experience. One day, I decided I had enough and I would do everything in my power to get a software job. It took 7 months, 210 applications, dozens of hours of work time lost to interviewing (and salary, thankfully, my boss at the time was very understanding), but I finally got some offers. Out of those 210 applications, I got 4 interviews, 1 rejection, and 2 offers. I decided to take the job that paid 30% less than my technical role (barely working above minimum wage) but no commute – and I never looked back.

I now find myself helping a good friend do the same and, with this first topic of the Writeathon being about my first job as a developer, I decided to share my story here as well. Let me know if this story helped you in your own job search in the comments, I'll be happy to provide more tips if I can.

Getting hired as a "web integrator"

The role that I ended up accepting was for a so-called "web developer/integrator" position. What is a web developer/integrator? In short, it is someone whose main job is to take designs and implement them pixel-perfect in HTML, maybe with some PHP sprinkled in. The web developer part meant writing a bit more PHP, SQL, and JQuery (I wouldn't dare call what we did at the time "JavaScript") to get the features integrated in those HTML pages. I would never recommend this title to anyone (it hurt my resume a lot), but I loved it. I was finally coding. I ended up proving myself in that role and gaining a lot more responsibilities, but that's a story for another day.

The interview process at that place was "fairly simple": I sent my resume, got called back for a 15 minute phone chat with the manager. I was given a 2 hour take-home assignment, and met with the entire team (4 people) in a 30 minute chat to go over the assignment. I ended up getting an offer on the spot, and we discussed the exact details throughout the week.

It was clear to me even at the time that my success was based mostly on luck. They needed someone now and I ended up filling enough boxes that they gave me a chance. I later learned that they were pretty picky on many things, the team lead had their own vision of programming and failed anyone who didn't fit. I just happened to say the right things. Still, I managed to wow them on multiple occasions regardless of my junior-ness. At only 210 resume sent, I clearly had an easier time than most, but I was also able to get just enough things going for me to take advantage of that luck. Here is what I did.

Acing the take-home

I had a degree in Java, but I was a Java dev in name only, I was mostly writing PHP at the time. The take-home assignment was a Meteor.js project (JavaScript) with some blaze for the frontend. I had to start from scratch and build a data visualization website with some basic CSS in 2 hours. Time was short, so I focused on reading just enough documentation and tutorials to finish on time. The biggest recommendation I can give for those tests is to trust google and focus on getting the information you need, nothing more. I could have dug into how to cache data on Meteor.js or using a real MongoDB database over the development version, but that wasn't in the requirements. Always focus on the requirements and get only the knowledge you need to get it done 100%, the polish can come after. If they hire you, they’ll train you in using the tools properly.

I did not do amazing. I missed some requirements and I didn’t realize that they wanted a responsive version. The biggest recommendation I can give for situations where you feel like you failed is: always be honest. I learned later when interviewing candidates myself that, especially for juniors, learning the tech used in the assignment is half the score. I assumed I would be turned back when I told them I had to learn everything from 0 and couldn't do everything. Instead, they were impressed. They thought I knew the tech and gave me a harder assignment. If you can't submit the perfect assignment, aim for a perfect second impression. Tell them what you learned, show interest, ask questions, and don't throw down the towel before you're able to share your results.

Finally, always take all the time you're given. If you feel the test was very easy and you ended up finishing an hour early, take that time to polish the results. You may notice the solution you came up with was not what the recruiter wanted (I once submitted an assignment on golang concurrency without any concurrency at Sourcegraph, that was embarrassing. "It was so easy!" I thought.) and that extra time is perfect to revise your solution. It's also a good time to go above and beyond, add tests, make the CSS pretty, add comments, write a readme. If they asked for a PR, make that PR as detailed as you can. All these things will give you more points and make your submission stand out.

Have open-ended projects on GitHub

One thing I see a lot these days are candidates applying with their GitHub full of tutorial projects. The code looks great and they show some of the signals I am looking for, but it's hard for me to know where the tutorial ends and where their code starts. I vividly remember the team lead during the last interview in this story asking me about a failed PHP framework I had on my GitHub. "It's really cool to see you doing something from scratch" they said, we then proceeded to geek out about it for 10 minutes. I only had three projects back then: a GUI application for modding my favorite game at the time, a fork of a clone of that GUI app in React, and that PHP framework I had built for fun.

Having open-ended projects that you contribute to on a semi-regular basis is extremely valuable for your portfolio. When we hire developers, we want to be able to see what makes them tick, what kind of code they write, what they are passionate about. Cloning Airbnb is impressive, but it doesn't tell me anything about you as a developer. That PHP framework said a lot about me: I was proficient in PHP, I knew the basic of web frameworks and MVC, and I was weirdly passionate about modularity and aspect-oriented programming.

To make your GitHub shine, find a project you're passionate about that you can start from scratch and execute on it. Talk about it in your cover letters (always write a cover letter, in PDF format if possible, with links), chat about it when people ask for a project you're proud of, pin it on your GitHub. The more you talk about it, the more you will understand it and the tech it's powered by. You want to have one thing you're an expert in, make it that project.

This may look like a lot of work, and that's because it is. One commit to this project may take you as much time as three great looking tutorial projects. But here is the big cheat that there projects provide: you don't need to complete them! If you keep working on them on a regular basis, it shows you're still interested and you'll have something fresh to talk about. No one expects you to finish an entire web framework by yourself.

Bonus: Hate the whiteboard, but don't dread it

Small bonus from that one place that rejected me. I ended up being rejected due to a totally flopped whiteboard interview. They asked me how I would build a load balancer and I immediately started designing a Node.js implementation because I heard it scaled well. I had never used Node.js before, but the stress got to me and I copied a blog post I had recently read. Needless to say, I couldn't say why it was a good solution and they saw right through me.

Whiteboard/leetcode interviews are broken, but sometimes you hit these design interviews that do have hiring value and can give good hiring signals.The ones where you're asked to pair on something or design a system, these are the ones you can and want to, do something about. The biggest tip I can give is to ask questions, lots of them, you're not giving a presentation, you're going through an interview. The interviewers are there to act as the "customers", but they can also be your rubber ducks. Ask questions, keep explaining what you're thinking, and let them interrupt. You're having a discussion, they want to hire you and you're there to prove them they made the right choice. It's very likely the job you'd be doing will be with a team, you won't be doing these designs alone on the job, why should you do them alone in interviews?

Conclusion

I wish everyone who is out there looking for a job the best of luck in their search and career change (if you're going through that). Getting hired is tough, it can be devastating to see all your efforts put into applying be met by silence (all too common) or rejection. I hope these small tips will help put luck on your side. Feel free to drop a question into the comments if you need more detail.