How I would enter the software engineering field, if I had to do it over again
How I would enter the software engineering field, if I had to do it over again
Ten step approach that I would apply if I were to join the tech industry again.
Welcome to the Captain’s Codebook newsletter. I'm Ilija Eftimov, an engineering manager at Stripe. Each week (or so) I write a newsletter article on tech industry careers, practical leadership advice and management how-tos.
Managers or employers want to be sure that when they hire someone, it'll all work out just fine. Great managers or employers won't optimize costs on candidates (e.g., trying to save a few bucks) - they will prioritize hiring the right personality and skills.
As someone trying to break into the industry, I would ask myself: before I apply to jobs, what steps can I take to derisk my potential employment? In other words, how can I make it so apparent that I will be a good fit for the manager/company that they won't even feel like they're making a bet?
My answer: proof of work. As a newcomer to the industry, the most efficient way to derisk my work application is to show evidence of competency. But it's also the most challenging way.
In continuation, I will talk about how to build a proof of competency. While I am sure there are other ways to approach breaking into the industry, I am confident this is the best way, even though it's demanding. If you have a different approach - tell me about it in the comments; I would love to learn.
My assumed profile
To frame my write-up well, let's create a persona. It'll be helpful to have one, as it will frame my advice better.
In no particular order:
I am not a fresh grad out of college. Let's assume I am in my early thirties (as I am at the time of writing this).
I worked in an unrelated field for a few years before switching careers. I've never worked in any tech company before.
I have invested a few months to learn fundamental web technologies. For example, I completed a boot camp.
My goal is to enter the tech industry as soon as possible. I want to earn a salary, but I am okay with delaying that – an unpaid internship is also acceptable for a short bit.
Without further ado, embracing this persona, here’s how I would break into tech.
Step 1: Flexible mindset
Limiting myself to only the area I started my learning in would be a mistake. In other words, spending time on a front-end boot camp doesn't mean I should avoid learning about other areas. A limited mindset gives me a striking similarity to the sunk cost fallacy - just because I invested time and money in one area doesn't mean I shouldn't be flexible and expand my horizons.
A short personal story: I found front-end work interesting early in my career and had ambitions to be a front-end engineer. But, as luck would have it, I had more opportunities to work on backend. So, I took them. At the start, I was afraid I lacked the skills to be a backend developer; e.g., I was never good at solving algorithmic challenges. Over time, despite being somewhat frightened of the prospect, I ended up as a backend engineer. I learned to love and appreciate the field. And to suppress my impostor syndrome.
Back to our hypothetical scenario: I don't get to choose as someone trying to break into the industry. If I'm serious about entering the industry, I'll take any opportunity. You name it, whether that's front-end, backend, support engineer, or infrastructure engineer.
I call this "engineering my luck". The more flexible I am, the more opportunities I will get, so I will have a bigger chance of finding a job or an internship faster than not.
Step 2: Know the job market
After agreeing that any job/internship is better than none, I would change my focus to learn the job market. By "learn," I mean figuring out what jobs are hot or not, what roles are in demand, what profiles, schools, boot camps, etc. Practically speaking, I hop on LinkedIn, look for local and remote jobs, and jot down my observations in a notebook.
I don't browse for jobs to apply to them. My goal is to get data about what's in demand. If front-end is not in demand, or people want to avoid juniors, I must broaden my search. Or get creative by considering ways to fit my expertise within another adjacent role.
For example, with the knowledge gained from my front-end boot camp, I could think about adjacent roles: design or full stack development. Suppose the market does show demand for full-stack developers. In that case, I will start thinking about expanding my knowledge. In other words, I would (potentially!) embark on the journey of learning full stack, building on top of the knowledge I already have.
The bottom line is that I follow the market. If the market is leaning towards full-stack engineers, I build a plan to bridge the gap between where I am and what an employer expects of entry-level full-stack engineers.
After identifying one or two adjacent and in-demand roles, I think long and hard about what path to choose. Once I decide, I will be ready to start closing the knowledge gap. Note that this doesn't stop me from applying to front-end roles - it just adds another supplemental role that I can eventually apply for.
Step 3: Identify the gaps
Let's build on the example from step 2: my LinkedIn research shows that full-stack developers are in demand.
I ask myself: What minimum skills do I need to be seriously considered for an entry-level full-stack position? Finding the answer can be nerve-wracking. But there's a trick to it: I will ask someone who is already a full-stack engineer what skills I lack. I don't assume or jump to conclusions. Ask the people who do the job—the professionals.
It's mind-blowing how people think it's wrong or rude to ask. It's not. I have feared rejection in the past, but I know I've got only something to gain. The worst case is I get no reply, or I get ghosted. And usually, there's a good reason for it. After a decade in the industry, I have yet to find someone who genuinely wouldn't want to help newcomers—especially the hardworking and humble ones.
Do you want to try this for yourself? Just ensure you're logged in on LinkedIn and click on this link. Once you see some folks with the "Full stack" title on their profile - message them. That's it, there's no magic to it. If you're searching for experts in different roles, update the search keyword for a more suitable one.
When reaching out to folks, I take my time when composing the message. I want to save their time, so I go straight to the point: share my goal to become a full-stack developer, explain my skills so far, and ask for advice on what to learn next. I would also ask if they have resources (books, websites, courses, etc.) that they have experience with that I should get. Getting vetted resources is very useful - it'll provide me with a free quality check (so I don't get stuck in useless content). Also, it will help me with step 4.
Next: X (ex-Twitter). Same exercise. Make sure you're logged in on your browser and click here. Look at the people that show up in the search results. I'd do a quick up-to-30-second scan for each of them and see if they engage with others. If so - ping them and ask them the same questions as you did on Linkedin.
I do not doubt that after reaching out to 100 people across Linkedin and Twitter/X, I will get a dozen replies. As a result, I will identify a set of skills or technologies that I need to learn to bridge the gap and become a serious full-stack candidate. Plus, I'll have some links to courses or names of books that I can work on next.
Step 4: Close the gaps
After identifying my knowledge gaps, it's time to close them. In simple terms, it's time to learn the skills I lack. Given that I've already been through a boot camp, I know there's no better way to learn than rolling up my sleeves and getting my hands dirty. So, it's time to dive into the courses and the books I got in step 3.
I wouldn't use the shotgun approach. Trying everything is rarely good. Instead, I would find the most adjacent new skill to the one I already have. For example, I wouldn't learn React if I only knew DOM manipulations using JavaScript. First, I would learn to understand the building blocks: APIs, asynchronous requests (fetch), and JSON. I will move to higher-order abstractions once I know how data flows from an API to the browser (and back).
Given my goal to learn full-stack, I would also look for adjacent technologies. For example, I would learn a well-established technology like Node.js - it's JavaScript on the server side and a mature technology. In some communities online, Node might be perceived as "uncool" or "outdated", but that's just noise. As a newcomer, getting productive as fast as possible is essential.
When building an API - I would begin with a straightforward JSON API instead of using the more advanced GraphQL or self-describing REST APIs. It's enough to be able to return JSON from my APIs. I can learn the other aspects and ways of building JSON APIs later. All that matters is that I can do damage as soon as possible.
Same with data storage: instead of using a database right out of the gate, I'd start with learning how to use a document storage platform (e.g., Firebase or Supabase). Once I can create simple CRUD applications using Firebase, I can explore how to use an actual RDBMS. My approach would be similar there - use one of the most popular choices, like MySQL or Postgres. Some online communities might state that MySQL has limitations, but that's irrelevant at my level. My goal is to become productive as fast as possible to build applications and my portfolio.
Some folks say that object-relational mappers (ORMs) are lousy practice. I would ignore this advice, too. ORMs are great for being productive fast and learning to store, read, and modify data in a database. Yes, one should absolutely know the lower-level language powering the database (e.g., SQL), but I can learn those later.
Step 5: Proof of work
Assuming I spend the time to bridge the gaps and learn the basics of the skills I lack, I need to show the world my skills. Building in public is the highest leverage I can do: I build something in public to show the world my skills, and by building, I further develop my skills.
I would build multiple apps that would showcase my knowledge. Starting simple is critical. I'd begin with building a personal website. It would be backed by a database with a landing page, an 'About me' page, and a blog archive. Then, something more advanced: a tiny clone of a favorite website. Again, simplicity is vital. If I tried to clone Reddit as a whole, I'd quickly get overwhelmed and fail. So, selecting a few core features and starting with them is crucial. Once I feel more confident in my abilities, I will go for the other, more niche features.
If I need inspiration, I would look at some indie products over at Indie Hackers and build clones. Cloning is not plagiarizing. Plagiarism can be illegal, but cloning is not. Especially when done for educational purposes. Not sure how a particular feature is built? Ping the maker via the Indie Hackers website (or Linkedin or Twitter) and ask them. Just give them context that you're trying to learn, not steal their customers.
Another idea is to look for public datasets or public APIs. Use the data to build a website around it. For example, here's a repository with a bunch that is free to use: GitHub - public-apis/public-apis: A collective list of free APIs. Use the free data and build an application around it.
Very important: proof of work is no proof if it can't be seen in others. So, any apps I would build must be online and accessible. I would deploy my app and tell the world about it. I'd put the code up on GitHub. Write a solid README. Do good commit messages and make them tidy. If I am unsure what a well-organized repo looks like, I will look at popular open-source projects on GitHub. The GitHub Explore feature is handy to discover new and popular repositories.
Remember the folks I spoke with on Linkedin and Twitter? I would send them the link to my new app, including the Github repository, thanking them for their input and celebrating the achievement of launching an app. I would also politely solicit their feedback. One never knows - they might check the code and give me tips or a review.
If I manage to build a few apps accessible online, with open-sourced code on Github that is well documented, I have my proof of work. My competency is online, free to be seen by any potential employer.
Step 6: Find my people
It's good to have a support network in difficult times. In my case, I would lean on my friends and family for support and a shoulder to cry on. But also, it's good to find my community. Find the people who are having struggles similar to mine.
Having a network of folks who have embarked on a journey like mine benefits my ego. I will know I am not the only one struggling. It will be a good reminder that many thousands like myself are out there, day in and day out, trying to break into the tech industry.
Nowadays, there are plenty of communities online. I would look for Discords where folks hang out. Here are some examples I've found in the wild - you can just click on the links to join the community:
DEV's Dungenon - ±10K members at the time of writing
Devcord - ±35K members at the time of writing
Code Support - ±33K members
The Coding Den - ±155K members!
Reddit is another way to take part in a community. Some useful Subreddits for newcomers:
/r/FreeCodeCamp - subreddit to learn to code for free
/r/cscareerquestions - subreddit for questions regarding careers in Computer Science
/r/webdev - subreddit for web developers
/r/learn$LANGUAGE - there are many "learn" subreddits, such as /r/learnajvascript or /r/learnpython
Beware: joining these communities is not enough - I must engage. Engaging can mean more than just helping others. Helping others can feel daunting for newcomers - it's common for folks to self-censor due to feeling insecure about their knowledge or experience. In the beginning, I would engage by asking questions whenever I got stuck while building apps, but only for questions that Google, Perplexity, or ChatGPT could not give me a straight answer for. (Asking questions that are easy to find online is poor etiquette and a sign of laziness.)
In general, I would keep my vibes in check. Positive energy and a collaborative spirit go a long way. If I employ a helpful attitude in these communities, I know that in no time, I will have a small network of like-minded people going through a similar journey like myself whom I can connect and lean on in my career.
Step 7: Find my mentor
Until now, I've been working on learning the skills / closing the gap, and building a support network around me. An essential component of the support network is to find a mentor. As you can tell, there's a theme here already: people. Learning technical skills is no joke. Yet learning how to connect with people and nurture relationships is as difficult. Finding a mentor can also be nerve-wracking. But it doesn't have to be.
The mentor's profile
Before looking for a mentor, I need to decide on my mentor's profile. It's common to want to be mentored by an experienced person working at a fancy company, but it's unnecessary. It can be an impediment. Folks working at the fancy, MANGA(-like) companies are often unavailable as their jobs are demanding. More prominent companies attract more experienced folks, so these folks might also have families. Their free time is generally limited, and they might want to prioritize it differently.
But I know I don't need that experienced mentor. I would instead identify someone with just enough experience. Someone just a few steps ahead of me - someone five years ahead of me.
To maximize my chance of getting a 'yes', I want to also look for engineers that engage with their community. Look for people who write blogs, have a bunch of points on Stack Overflow, Reddit karma, or people who talk at/organize meetups. I look for folks who engage with their community beyond their day-to-day work. By targeting them, I'll have a better chance of finding a mentor, as these people already like to engage with and empower others.
Finding The One
I would start with LinkedIn. Like before, when I looked for advice to close the skill gaps. I would look for engineers with a more significant following who often publish posts or comment on people's posts. Recently, LinkedIn started a crowd-sourced platform for writing articles called "Collaborative Articles". By contributing to these collaborative articles, authors can get the "Community Top Voice" status - an award for their contributions. Folks having this badge can be a good candidate for a mentor. Message them!
Alternatively, if someone rejected me, I would pitch them to boost my message to their followers. These "Community Top Voices" typically amass a following as part of their special status. I would write a short and punchy post on Linkedin about my background, my journey, and that I am looking for a mentor. Then, I would ask the person to re-share my post with their network, significantly increasing the likelihood of finding a fitting mentor.
Next, I would use websites like The Mentoring Club, where people volunteer as mentors. Interested mentees can review mentor profiles, including work experience, expertise, passions, etc. Mentees can schedule a call with a mentor - they send a request, and, assuming the mentor accepts, they're well on the way to having a first session with a mentor.
Next, local meetups. I would use Meetup.com to see what's happening around me and attend some meetups. Once there, I would approach other folks and create relationships. I would refrain from jumping directly into asking people to be my mentors. I would get to know people, ask them to share their stories with me, and ask how I can help them. That's it. Once we've established a meaningful relationship, I might ask them to mentor me.
Keep in mind that mentorship must be a win-win situation. While the mentee might get more out of the relationship, mentors should still get something. If mentors don't get anything out of the mentorship, they won't be incentivized to do it. As a mentee, I would bring my best self whenever I meet my potential mentor.
Meeting mentors
To have a practical mentorship session, I have a clear goal in mind: I want to break into the industry. That's all that I am going to be talking about with my mentor. Nothing else. Having focus in my conversations shows them that I have my eyes on the prize. A personal connection with my mentor is valuable. But after getting to know them, I would spend every ounce of my mentor's energy and every second of their time focusing on the problem.
Showing focus and commitment is simple. I like to be on time. I come prepared with questions and topics to go over. I do my homework (if any). To listen attentively, I leave my phone out of sight. Or out of the room. I jot down notes. I do everything in my power to maximize my learning and my retention.
I would try my best to never run out of topics to discuss. I would build a topic bank from which I can always pull ideas. If you need inspiration for your mentorship sessions, here are a few ideas to start with:
Feedback on my current project(s)
"I've been working on $PROJECT_NAME. Could you review my code and suggest areas for improvement?"
"What design patterns would be most effective for this project?"
"Here's a challenge I faced during this project. How would you have approached it?"
Asking for guidance on my learning path
"What key technologies should I focus on learning next, based on my current skill set?"
"Can you recommend any courses or resources that helped you when you were at my stage?"
"What skills will be most valuable in the industry over the next few years?"
Asking for general career advice
"Which career paths in coding do you see as most promising for someone with my background?"
"What skills are currently in high demand in the coding industry?"
"How can I align my learning path to meet the industry needs?"
Step 8: Interviewing
Next up: learning how to interview. Yes, "interviewing" is a skill of its own. If you don't believe me, ask any engineer who has switched jobs or works at a more prominent company. Or hop on YouTube and see how many tutorials on solving LeetCode questions there are. (Hint: countless!)
I wouldn't invest in LeetCode-like exercises for interviewing sake. Such coding challenges are more common in huge companies. But instead, I would learn all the unwritten rules and customs of interviewing in the industry. For example, how to structure my CV, answer interview questions, prepare for interviews, and so on.
Make my CV tight.
I've seen folks over-index on being prepared on the technical aspects but have yet to land an interview. Yes, solving a bunch of coding questions or experimenting with the language's standard library is very useful. Yet, I've witnessed these same folks, who are technically sound, send their CVs to job openings to no avail. They laminate that the market is terrible or that juniors are not in demand.
But I think that's wrong - no company will pass on a great junior candidate. At the very least, the recruiter will send a note back. Not receiving any feedback when sending my CV says nothing about the market. But it says about my CV. Picture this: I send my CV, and the recruiter receives it. They download the CV from the email. They open the CV. And the clock starts ticking. My CV has 30 seconds at most to convince the reader that I should get a chance at an interview with them. After those 30 seconds - it's decision time. If my CV does a good job - I'll get the interview. If not - I won't. It's as simple as that.
What happens behind the scenes eludes newcomers. They think it's their skills or their experience. Nope. It's the CV itself. Having a great CV is like wearing a tailored suit; both are customized to fit perfectly, making an excellent first impression and highlighting I am the best fit for the open role.
Practicing
Some of the free or open-source communities and websites for practicing software engineering interviews include:
Leetcode: Offers over 1050 software engineer interview questions and solutions and is one of the most well-known platforms for practicing coding skills.
HackerRank: Provides code challenges and interview preparation for developers and offers a substantial library of challenges for free.
Coderbyte: Offers full-stack coding challenges, interview preparation courses, and mock interviews, with over 500 challenges, articles, and videos across different domains.
Interviewing.io: A platform where software engineers can participate in mock and actual technical interviews, watch a library of video interviews, and take mock interviews with engineering hiring managers.
Pramp: Allows users to practice coding interviews through peer-to-peer mock interviews, helping them prepare for actual technical interviews for hiring companies.
These platforms offer a variety of resources, including coding challenges, mock interviews, and actual technical interview practice, to help software engineers prepare for interviews and improve their skills. I would lean into these, spending time to hone my interviewing skills with my mentor, where I would talk more about the "soft" sides of interviewing.
Sourcing jobs on Linkedin
I would look for jobs in companies where people are already working in the same positions I am learning about. For example, I wouldn't apply for a company job ad for a "full stack engineer" if there were no other full-stack engineers. In such a situation, it might mean that the company has no experience growing full-stack engineers.
Also, I wouldn't use only the LinkedIn Jobs functionality. While it's excellent, this functionality is not tailored to juniors. I would use the search functionality and look for posts from recruiters mentioning junior or entry-level positions.
Next, I wouldn't apply directly via Linkedin. Once I see a job ad on Linkedin, I would contact the recruiter or the hiring manager of the company that posted the ad. Even better, I'd contact a potential colleague there. I would explain my situation, give them the context, show my proof of work, and ask for a referral. I'll likely get the referral with the right vibe and the evidence of work.
The same approach works for other social networks. The right approach is connecting with the people behind these companies and avoiding the paved path.
Step 9: Document my journey
I would start to document my journey. I would write about my experiences, challenges, and successes. Writing is a powerful tool. It's not just about keeping a record; it's about reflecting on what I'm learning. This process helps solidify my new skills. I think of it as talking to a friend about my day. I would start with a blog or a journal. I would write about what I learned today, a problem I solved, or a new idea that I got. This doesn't have to be a daily task. Even a weekly update is a great start.
When writing, I imagine explaining my day to someone who doesn't know much about the topic. This helps me break down complex ideas into simpler parts. It's a skill that will not only make my writing better but also improve my ability to communicate. Deconstructing and explaining technical topics to non-technical folks is an essential skill.
I wouldn't worry about making everything perfect. The goal is to share my journey, not write a textbook. I would share my successes, but especially my mistakes. Mistakes are valuable because they often teach the most important lessons. Over time, you'll see how far you've come, and others will.
I wouldn't write on other platforms, like Medium. I would do it on a personal blog, where I can own my content. Writing connects me with others who are learning and have been in the field for a while. It'll build me a network, get feedback from others, and learn from them.
Remember, everyone started somewhere, and many will appreciate the honesty and effort in my writing. It is critical to keep it consistent, genuine, and reflective of my personal journey. This way, my blog or newsletter becomes more than just a diary - it becomes a tool for learning, networking, and personal growth.
Step 10: Learn to unblock yourself
Being resourceful when working is crucial. There will be many times when I won't have someone to unblock me, so learning to struggle through the problem and finding a solution by myself is very important. Luckily, the tools nowadays are much better than what they used to be a decade ago. There are two types of tools to master: search engines and AI-powered chat-like tools.
Looking things up online, a.k.a. Googling
When I am stuck on a coding problem and turn to online search for help, the key is to be as specific as I can in my search. I would start by describing my issue with precise terms. For instance, I mention 'Python' along with the specific error message if I am dealing with a Python error. The more details I provide, the better my chances are of finding a relevant solution. It's also a good idea to include any specific tools, languages, or technologies I use. Yet, too many keywords can create diminishing returns, so it's important not to overdo it.
Another clever tactic is to combine different keywords in a way that targets my problem accurately. I'd think about pairing general concepts with specific issues. For instance, searching 'Python for loop syntax error' is more effective than a broad search like 'loop problem'. If standard terms lead me astray, I try adding version numbers or using technical jargon related to the issue.
I use the minus sign (-) for unrelated results to exclude terms from my search. This helps filter out the noise and zoom in on the information that matters. Continuously tweaking the search terms and experimenting with different combinations is the way.
ML-Powered tooling
AI tools like ChatGPT and Perplexity.ai are the secret weapon for getting up to speed. These tools are fantastic for breaking down complex tech jargon into simple, understandable language. For example, to understand a tricky programming concept, I can pop a question to these apps, and they'll explain it in a way that makes sense. They're like having a patient mentor at one's fingertips, ready to clarify things without judgment.
These tools also come in handy when I'm stuck on coding problems. While they won't fix bugs for me, they're great at suggesting what could be going wrong and how to approach fixing it. They're also super helpful for quick answers to straightforward questions, like how to use a specific function in my code. This saves me time sifting through search results or documentation. Integrating these AI tools into the learning process can be a game-changer for beginners in tech, making the journey into tech smoother and more enjoyable.
Lastly, it's important to remember that while these tools are powerful, their knowledge is based on the information available up to a certain point. They might not have the latest data or be aware of recent developments. Also, unquestioningly trusting ChatGPT or similar tools is a mistake. It's essential to verify their results and supplement their suggestions with self-research.
And that’s it for this week! If you liked this, consider doing any of these:
1) ❤️ Share it — Captain’s Codebook lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
2) ✉️ Subscribe — if you aren’t already, consider becoming a subscriber. Seeing folks read the newsletter energizes me and gives me ideas to write.
3) 🧠 Let’s chat — I am always on the lookout for questions to answer, to help out with challenges, or topic ideas to cover. Hit me up on LinkedIn, Twitter or send me an email to blog@ieftimov.com.
Until next time,
Ilija