I started my career as an embedded engineer after graduating from Georgia Tech with a Computer Engineering degree. I learned a lot from working on the firmware layer of ARM-based mobile chip processors. I had the opportunity to work on software projects with millions of lines of C and Assembly code as part of a large team of very smart people.
But there was a lot about the work that I didn’t like. Working on special hardware in the lab started becoming less fun. I had to deal with long compile times, sometimes hours. And many of those times, I’d find out that I need to recompile for some unrelated reasons. Logs had to be extracted from memory and were very limited. Worst of all, breakpoints were not reliable, making it hard to know what code paths were being executed. So disappointing!
It was a relief to be able to develop software with just my laptop. No need for big bulky FPGA boards or other special hardware.
Sounds silly, now that I’m many years into my software engineering career. I can’t imagine operating in a flaky development environment. And I definitely appreciate the safety of typed code 🙂.
I put together my resume and applied to multiple small startups working on web-based products. Most of the job descriptions included jargon that I didn’t understand at the time — Ruby on Rails, Backbone.js, Socket.IO. I had no idea what any of that was. But the job title said “Software Engineer”. I figured that perhaps the fundamentals are the same, so I should just apply.
I didn’t get many responses. Except for one company. I got on a phone screen with an engineer, where he asked me what a REST API was. I had no idea at the time. And I failed the phone screen!
After talking to a few friends at web-based startups, I realized that I’d have to give employers more confidence that I can translate my embedded engineering skills into the kind of engineer that they need.
So I decided to improve my candidacy to stand a better chance at getting the role — which I later learned was called, a full-stack engineering role. I picked up Node.JS again. But this time I took it a few steps further. I went through dozens of exercises to create simple programs. I worked my way up to create the infamous To Do app in jQuery and Node, which persisted Todos in MongoDB using Mongoose.JS. My first full-stack, simple web app. I finally learned what a REST API was. I got so into it.
I decided to take my skills a step further and solve a real problem for even just a few users. I worked with a healthcare consulting company to create a web application that helped them coordinate tasks with their clients. This was one of my favorite learning experiences. I worked on small-scale yet core problems on a single page application such as user authentication, front-end and database performance, refactoring spaghetti code, etc. I was able to help people with their day jobs!
I began to re-apply for jobs. But this time, I put my side project on the very top of my resume. While my embedded engineering experience was valuable, my side project made my resume more relevant to the job.
My response rate from employers was exponentially higher. In addition, the side project prepared me for the technical interview. I even got positive feedback about my experience creating a web application that real users actually used. After a few rounds of interviews, I accepted a position as a full-stack engineer at a startup in NYC.
While online courses, interview prep books, and bootcamps are great ways to learn how to become a full-stack developer, working on side projects helped me line up almost every job I took in my career.
You don’t need to create a side project that gains adoption by users. And a side project might not be for everyone. But there are many ways to learn on your own time and prepare yourself to get the job that you want. Even if it’s completely different than what you currently do.
Rohit is a co-founder of Easy Resume, an online resume builder and career advice blog.