So to help others out, I want to share my story. I know many people are out there looking for work and trying to transition into tech, just like I did.

When I was job searching, I found comfort in hearing how others made their way into tech, and I enjoyed their stories. So, I’m writing in the hope of helping others who are going through what I went through. If you’re one of those people, hopefully these tips will work for you as well and help you on your journey.

Original Article: エンジニアへ転身するための完全ガイド: 在宅フリーランスと育児から開発者の道へ. Written and Translated by: Saki Basken.

My Non-Traditional Background

I think it’ll help to share a bit about my background and how I came to work as a developer. I don’t have a conventional background in computer science. I studied Anthropology and Sociology in college, subjects I truly loved, but they didn’t offer the best job prospects.

After graduating, I had different office jobs, including working as an Executive Assistant and a Warehouse/Import Coordinator. Since I grew up in Japan and am bilingual, I also started translating as part of those jobs while working at Japanese companies in Chicago.

After my husband and I had our first child in 2013, my company only offered 6 weeks of maternity leave, which was standard in Illinois at the time. I’m not sure if things have improved over the last 10 years, though I truly hope they have. I remember I was shocked that only 6 weeks were offered for maternity leave.

So, I decided to leave my full-time position, which wasn’t particularly high-paying anyway, to focus on raising kids. Freelancing as a translator gave me the flexibility I needed during that time. As you can see, both my educational and professional backgrounds up to this point were far removed from programming and had nothing to do with computers.

I did study Sustainable Development to earn a postgraduate certificate (which just means I was a few modules short of a master’s degree) and took environmental science and other science-related classes because climate issues are where my passion lies. But that didn’t really give me a chance to explore programming, and I always thought I wasn’t a “computer person.”

Raising Kids and Freelancing: The Unseen Career Gap

While I was happily raising two amazing girls and freelancing as a translator, once they were both in elementary school, I felt I was ready to take on more work. I also missed working in the office as well. But I didn’t want to work full time as a translator. I did that to meet family demands, but it wasn’t my true interest.

I’ve been passionate about sustainability and climate change since college, so I was eager to work in that field. I spent a few months searching for opportunities, but I couldn’t get past the phone interviews.

During those quick calls, I was often asked about my experience from over 10 years ago, when I worked in an office. It was brutal, especially during the first interview — I didn’t expect them to focus so much on my past experience. I thought they’d be more interested in what I do now and what I can offer today.

It also made me feel sad, as if I was being told that everything I’d done over the last 10 years didn’t really matter. Raising kids, freelancing, and studying are all incredibly hard work: you have to manage time, work, stress, customers, and billing all on your own.

Yet society and companies often overlook the immense contributions that stay-at-home parents and freelancers make. It’s disheartening, especially when these roles require such dedication and resilience, but are undervalued far more than they should be.

Besides, who can answer in detail about what they did 10+ years ago for those crazy behavioral questions? Seriously.

The Turning Point: How I Discovered My Interest in Coding

During that time, I also started to realize that I didn’t have the skillsets those climate tech companies were looking for (since they typically aren’t in need of translators), and my experience from over 10 years ago just wasn’t enough.

At that time, I noticed many climate tech companies were looking for software engineers, and that’s when my husband suggested I learn coding. Plus, we live in Seattle, where it seems like half the people we meet are software engineers. When in Rome…right?

Starting Small: Gaining Initial Experience as a Technical Translator

My husband has a startup, and we reached out to the person who did the software development for the company — who also happens to be one of the cofounders and our friend — to get her insights on where I should start. She said the best way to learn how to code is by actually doing the work and not just studying. She also offered to help me learn by contributing to the startup.

With my background in translation and newfound interest in tech, I started doing technical localization for their mobile app. I didn’t have any background in computer science, but that’s how I landed my first position as a Software Developer. Although I wasn’t getting paid (since it was more of a family business), it was an incredible opportunity to learn not just coding but also Git flow and to get hands-on experience with software development.

So I’d suggest trying to get this sort of experience if you can. It can be anything. See if your family or friends’ business needs an update on their website or complete makeover. Anything can be experience if you put work into it and build something that you can learn from and show that you have.

After I started at the startup, I felt the urge to learn more, so I signed up for Codecademy during their Thanksgiving sale in 2022 and completed pretty much every lesson I could find. (They run sales around almost every holiday — I got 50% off — so never pay full price! Better yet – and I didn’t know it at the time – freeCodeCamp.org offers free programming tutorials and video courses, as well as an entire curriculum at no cost!)

I really enjoyed working with the startup cofounder, doing technical translation, and learning along the way. She was, and still is, an amazing mentor. At that point, I knew I wanted to pursue this as my career, and I was eager to learn more.

I tend to dive deep when I’m interested in something. Before coding, it was Korean dramas, and before that, the stock market. I usually binge-watch or binge-study for 3–4 months until I lose interest.

But with coding, I haven’t lost interest because programming offers an endless supply of challenges for better or worse, along with learning opportunities. This makes it the perfect field for someone like me who loves to learn.

One day, my husband was visiting our old neighbor’s house, and the neighbor casually mentioned that his wife had completed a coding bootcamp at Flatiron and she loved it. She, like me, was a career changer and had been working successfully as a developer ever since she graduated from the program. My husband shared the story with me, and I remember applying for the upcoming cohort the very next day.

Making the Big Move: Joining a Coding Bootcamp

Coding bootcamp was awesome. It was super intense, as the name suggests, but it definitely accelerated my learning by a lot. I mean, you probably wouldn’t spend 60+ hours a week learning on your own, and that’s likely why it worked so well.

When we started, the cohort had over 30 students, but after the first week, it dropped to 25. By the next week, it was down to 20, and when we graduated, only 12 of us remained. We trauma-bonded through the hard, intensive, and sometimes overwhelming program, and the classmates who made it through with me will always hold a special place in my heart.

It was a 15-week program with 5 phases, each lasting 3 weeks. We had coding challenges and group projects in every phase, and it all culminated in a solo capstone project at the end.

Post-Bootcamp Support: Career Coaching and Job Search Strategies

At Flatiron, they offer 180 days of career services after graduation, which was amazing. The career-related workshops actually started while we were still in the program, giving us a head start.

After graduation, we were each assigned a career coach. I met with mine weekly for the first month, then every two weeks after that. They helped by reviewing my LinkedIn profile, résumé, conducting mock interviews if needed, and offering suggestions on how to refine my job search efforts.

Flatiron also had a subgroup called the 'Global Community,' and I actively participated in their virtual meetings both during and after the program.

Since the group was small, it created a space where I could learn about career-related matters alongside people from other countries and those who grew up in multicultural environments. We shared our concerns and challenges, and we heard stories from others who had already transitioned into tech. It was an incredibly valuable learning experience.

When I started the program in January 2023, they estimated that it would take most graduates 3–6 months to land a job. But due to the mass layoffs happening at the time by big tech, by the time I graduated, the average was closer to 6 months.

It ended up taking me 7 months to secure a job, and I attended countless networking events during that time. But having my career coaches was crucial — they provided much-needed guidance and support, and it was invaluable to have someone I could ask questions and get advice from.

Breakthrough: How I Landed My First Full Time Job

After graduating, I jumped into the job hunt right away. I volunteered, contributed to open-source projects, attended networking events, kept learning, and passed the AWS Cloud Practitioner exam—I stayed very busy. I’ve also been active on LinkedIn, posting every milestone and anything relevant to programming and sustainability.

At Flatiron’s career workshops, I learned that 80% of jobs are never posted publicly and most people find roles through connections or past collaborations. I was skeptical, but that’s exactly how I landed my first job.

A mentor I worked with at the startup noticed the full-stack web application I had built with React after I shared it on LinkedIn. When her other company that she owns needed a React developer, she reached out to me with a job offer.

Throughout this experience, I picked up some insights that made a huge difference, and I’d like to share a few tips that helped me along the way.

Networking: Overcoming Awkwardness and Building Connections

Is networking necessary? I say yes. While you might not land a job directly from networking events, they’re great for preparing you for future interviews and building your confidence.

During my coding program, I tried hard to attend local events I found on meetup.com and other social platforms, but I rarely had the time. It was always either the night before a coding challenge or I needed to focus on a project. But I still made sure to book events for after graduation because I wanted to start job hunting right away.

Since I never needed to network before, I mistakenly thought these events were like “hiring events.” The first networking event I attended was incredibly awkward — I didn’t know anyone, and I felt like I had to “speed date” everyone to find a job. I even had to take a break in the bathroom just to regroup.

Most organizations have monthly meetups or events, and I ended up attending about 10 different groups every month. Since I was interested in climate tech, I went to climate tech events, as well as more general developer meetups.

Lessons from Networking: Turning Conversations into Opportunities

First and foremost, networking events are not hiring events! You don’t need to meet 30+ people and collect dozens of new LinkedIn connections. It’s far more meaningful to meet a few people you genuinely connect with and you can actually remember them.

Some people are naturals at these type of events, hopping in and out of conversations like social butterflies. But for me, it was more comfortable to focus on deeper conversations with fewer people. Everyone is different, so find what works best for you.

As you attend more events hosted by the same organizations or groups, you’ll start seeing familiar faces, which makes things easier each time. These events may not directly lead to jobs, but I found them invaluable for practicing interview skills.

You meet many new people who often ask questions like, “What do you do?” or “What brought you here today?” — the same kind of questions that interviewers ask. It reminded me that interviewers, like people at networking events, just want to get to know you.

By talking to others with similar interests, you can also discover resources you might not have come across otherwise. For example:

• I learned that the AWS Skills Center in Seattle offers free in-person and online classes, accessible from anywhere in the world.

• From senior developers in climate tech, I found out that climate tech companies tend to be small or medium-sized and they often prefer to hire experienced professionals because they lack the resources to train new hires. (Based on this, I changed my strategies from focusing on climate tech to finding more general dev work.)

• I also discovered programs specifically designed for bootcamp grads or those without conventional degrees, offered by large tech companies like the Microsoft Leap program. If you have a career coach, you can strategize with them on how to apply for these programs as well.

The list goes on!

You don’t have to attend formal meetups to network. You can talk to other parents when you pick up your kids from school or share your journey with friends and neighbors when they ask, “How are you doing?” or “What’s new?” Let people know you’re learning to code or looking for work.

People love to help if they can. That’s why they write blogs, contribute to open-source projects, and share resources. It might not happen immediately, but if an opportunity comes up or they hear about something, they’ll let you know.

For example, a friend approached me about a backend engineer position after I had already accepted an offer. I had to turn it down, but it shows how putting yourself out there can create opportunities.

Navigating Job Applications and Reaching Out to Companies

Getting interviews in last year’s market was tough, especially for someone like me with 10+ years of experience in one field, but who’s starting over in a completely new one.

In tech, even entry-level jobs often require 2, or sometimes even 4 years of experience. And even if you meet those requirements, they still want to interview you five times just to be sure — clearly, the tech industry has trust issues.

A key strategy when applying for jobs was always, always messaging the hiring manager or someone at the company after submitting an application. Companies want to hire people who show they care. Sending a thoughtful message that demonstrates your interest, why you’re a good fit, and how your skills align with the role can really catch their attention.

If you know someone who works at the company, don’t apply through the usual channels — reach out to them first and see if they can give you a referral.

For about 90% of the interviews I landed over the course of 7 months, they came from those follow-up messages. Plus, you get a glimpse of the company culture when you reach out. Some responses felt like auto-reply or they just ignore you, while others are warm and helpful.

In this job market, it’s hard to be picky but I wanted to make sure I found a company with great culture and values. Reaching out gave me a sense of what it might be like to work there.

Ace the Interview: Turning Conversations into Job Offers

Once you get the chance to interview — which is the hardest part — you’ll do just fine if you’ve been networking. For example, I applied for 100+ positions at Amazon alone, including around 25 referrals, and only got one opportunity to interview for a single position. In the end, although I had to decline due to relocation issues, I received the offer for that position so my success rate after landing the first interview was 100% 😎.

In my experience, interviews are more about how you think than what you can actually do. There were multiple rounds for different positions, but the questions were always centered around your thought process and how you handled situations in the past.

After months of attending networking events, I felt comfortable having conversations with interviewers, and it all felt much more natural. I remember interviews before Flatiron — they felt more like interrogations than conversations.

One of the things I learned in career workshops was to remember that they’re interviewing to find out who they want to work with, so make it a conversation. If it’s a Monday, ask them how their weekend was. If they ask, “How are you?” don’t just say, “I’m good, thanks, how about you?” Share something personal — talk about your weekend, your pets, your kids, or even how you’ve been sick. Build a human connection, and you’ll leave a lasting impression.

Learning from the Best: How Mentorship Accelerated My Tech Journey

I mentioned having one mentor earlier, but I actually had a couple. Mentors are incredible, and I’m not sure if it’s a tech culture thing or a West Coast thing, but there are so many people willing to help out there.

One of my mentors, who I mentioned earlier, was the person who got me started on my tech journey. She owns a software company and is the one who ultimately helped me land my current job.

Another mentor was someone I met while volunteering for PNW Climate Week last year after graduating from the coding bootcamp program. After the event ended, we started meeting online every other week until I began working.

She’d go over my job hunt with me and offer advice. I remember one time I had a take-home assignment, which was the 3rd round of interview, for a company I really wanted to work for, but unfortunately, I was turned down. I was upset and couldn’t figure out why. When I showed her my assignment, she gave me the clarity I needed and helped me understand where I went wrong. I learned a lot from those conversations.

My third mentor actually reached out to me on LinkedIn. I was active on the platform, and he found me, offering to mentor me because he enjoys mentoring. I accepted, and whenever I had questions like “What should I learn next?” or needed guidance, he provided valuable insights that I applied to my job search.

The tech industry is full of people who are willing to help, so don’t be afraid to ask for help and support and be open to offers. I am forever grateful to my amazing, wonderful mentors, and I hope to one day do the same for others. ♥️

The Power of Open Source: Building Experience and Credibility

Last but not least, if you haven’t started yet and don’t have much experience, begin contributing to open-source projects! In one of the career workshops during my bootcamp, we were told that open source is especially valuable for those without industry experience. By the time you graduate, you could already have 2+ months of hands-on experience.

I started contributing to open-source projects in March last year while still at Flatiron, and one of the first was for freeCodeCamp.org. What was amazing about freeCodeCamp.org was that once I started working on articles, they created a profile page for me, which I could immediately add to my résumé and portfolio.

Contributing to the React project also helped me keep my GitHub status “green.” After graduating from bootcamp, I met the founder of the Climate Tech Handbook at a climate tech event, and I started working on that project as if it were a part-time job. I got to collaborate with web designers, work with Figma designs, and engage with different teams, which was a fantastic learning opportunity and for a great cause.

Not only can you add these experiences to your portfolio and résumé, but you can also use them in interviews. For most of the behavioral questions I encountered, I drew from these experiences to provide relevant examples.

Even though I was fairly new to the tech industry, these projects gave me a lot to talk about that was highly relevant. And, of course, having that extra experience on my resume helped me stand out among others with the same career level in tech.

I am forever grateful to freeCodeCamp, the Climate Tech Handbook, and other open-source communities for giving me incredible opportunities to enrich my portfolio far more than I could have done on my own.

Reflecting on My Tech Journey: Embracing the Unconventional Path to Success in Tech

Key Takeaways

1. Being proactive definitely helped me build a stronger resume and portfolio. Volunteering and contributing to open-source projects are great ways to stand out among candidates with similar experience levels and they provide valuable talking points during interviews.

2. Meet as many people as you can to discover resources, gain advice, and improve your interview skills. This can also ease imposter syndrome, especially when you’re new to the industry.

3. Keep learning but at a sustainable pace. One mentor said that learning has its seasons. If you are someone like me who feels guilty when you are not learning constantly, it’s ok to take breaks. Processing what you learn takes time, and rest is an essential part of the process.

4. It may not feel that way but transitioning to tech from another field is an advantage. Your unique background offers insights that others might not have, and you can tap into niche markets to get started just as I did with technical localization, leveraging my translation skills.

I’ve now been with the same company for nine months, and time has truly flown by. Every day, I learn something new and genuinely enjoy what I do. I’m so glad that I challenged myself by entering this new field a couple of years ago.

While not finding a job right away was tough, and at times soul-crushing (as some of you may know), I am grateful for how things turned out. It all led me to where I am today and I’m excited to see what the future holds for me.

And if you're a developer, you may be in a good position to get into technical writing if it's something that interests you.

Developers have a lot of knowledge about topics like Git, Markdown, programming languages, and IDEs that they can use to teach others. And since they have worked with these tools and technologies themselves, they can often write documentation with a user-centric approach.

It's also fairly lucrative to be a technical writer, with the average salary in the US being $76,432 per year. This makes it a viable career to support yourself and your family.

Luckily, I had technical writing samples to exhibit my writing skills when I decided to give it a chance. My love for writing offered me a ready-made technical writing portfolio and made my career change easier.

But this is not the case for everyone and people regularly ask me tips to start technical writing and earn through it. So I'm compiling all the things that helped me transition into technical writing in this article.

What is Technical Writing?

Technical writing typically involves breaking down complex technical knowledge into simple words, making it easier for a non-technical audience to grasp technical concepts. The aim of technical writing is to ensure that users can effectively use a technology, which ultimately improves user satisfaction.

As a technical writer, you can write about a wide range of topics and write for different purposes and audiences. Some of the types of writing you may do will include:

• User manuals
• Documentation
• Detailed guides
• Blog posts
• White papers
• SOPs

and so on.

Accuracy, consistency, clarity, and conciseness are some of the crucial aspects of technical writing.

What are the Responsibilities of a Technical Writer?

Technical writing requires extensive research, which can make the writing process longer. Technical writers stay in a loop with Subject Matter Experts (SMEs) to understand the technical details of client products/ services.

After gathering loads of information through expert interviews and research, technical writers compile relevant information into their writing.

After gaining some experience, technical writers might also have to edit and proofread others' writing. Proofreading and editing require patience, attention to detail, and empathy.

How to Become a Technical Writer

Share Your Knowledge

Start writing tutorials, how-to guides, and share your experience with technology on an open publishing platform like Medium, Hashnode, or HackerNoon. These blog sites are easy to handle for beginners because they're free and some of their publications have a huge audience base.

If you're unsure about how to write technical articles, start reading a lot of them. This will start to give you the sense of how technical writers share their information in an approachable way, how they structure their articles, what topics they focus on, and so on.

Below are some beginner-friendly blog post ideas:

• How to do X in/ using Y (Example: How to build a portfolio website in WordPress)
• X ways to do Y (Example: 3 ways to avoid overfitting in machine learning models)
• What I learned in 10 days of working with X (Example: What I learned in 10 days of working in VSCode)
• A guide to X: Everything you need to know (Example: A guide to AI Website builders: Everything you need to know)

You can also read various publications' technical writing guides. These contain a lot of helpful hints and information about how to write good technical tutorials. Digital Ocean has a pretty well-known one, and freeCodeCamp has their own as well.

Build a Portfolio

Once you've got a few writing samples, you can help build your credibility by creating an online portfolio that contains all your writing samples. This is something you can share with potential employers or project maintainers.

You can share it on social media platforms, display it on LinkedIn featured section, and send to potential clients.

You can also try writing for publications. Well-known publications often have a huge following and they share contributor content on their social media platforms. This can help build your personal brand as a technical writer, grow your network, and motivate you to write more good stuff.

Some publications that accept contributions from new writers are:

• freeCodeCamp: freeCodeCamp expects you to have at least three writing samples when you submit a contributor application. The application process is a bit more rigorous than some, and they don't accept every application for various reasons. But if you don't hear from them and aren't accepted the first time, don't give up. You can keep improving your writing, and try again later – or try other publications. You can find the fCC contributor guidelines here.
• Towards Data Science: Towards Data Science accepts articles revolving around data science and machine learning. They expect you to submit well-structured, comprehensive, and up-to-date articles. Read the TDS contributor guidelines here.
• Level Up Coding: Level Up Coding is an online publication focused on sharing technical knowledge to help software engineers learn and grow. They have an audience of developers, designers, and data scientists so they expect content that's useful to them. Here are the contributing guidelines for Level Up Coding.

Though all publications have contributing guidelines in place to help contributors write relevant samples, a few tips to make your pitch a success are:

1. Get familiar: Read at least 3-5 top-performing articles in the publication you want to contribute to. Pay attention to the tone of voice and the level of detail shared to understand their preferences.
2. Create an outline: An outline is a structure for your content that keeps you on track while writing. You can create a good outline using top-performing content, AI tools, and your expertise.
3. Drafting: Create a draft based on your outline and let it sit for at least two days. This gap helps you spot mistakes in your draft that you might overlook during or immediately after writing.
4. Submit your draft: Finally, send your draft for review to the publication. They might edit your draft or ask you to make some changes before they publish it. Some publications also use AI content detectors, so if your publication does, make sure to verify your content using the same AI detector.

Share Your Work

While you're building your portfolio of technical articles, you can share them on LinkedIn (and other social media sites like Twitter) to let the world know about your new skills – and that you're writing about interesting technical topics.

You can also include a link to your LinkedIn profile in the articles you write, if the publication allows it, to help people find you. You'll be amazed to see how many people admire your work, and this will keep you going. You might also receive paid projects and job opportunities in your DMs.

Upskill to Documentation Writing

One great way to practice your technical writing (and help others along the way) is to contribute to documentation issues on GitHub open-source projects. This will expand your skillset and give you experience writing documentation and help you become more familiar with contributor guidelines.

Documentation writing is more focused on the product and, unlike blog posts, is usually concise. It follows a predefined structure, and the content format across pages is consistent. Accessibility, consistency, and clarity are the general best practices of writing documentation.

Pay attention to the editor's suggestions to develop a better understanding. There are usually two types of editor suggestions: objective and subjective. Objective suggestions are about general writing guidelines such as transition and clarity, whereas subjective suggestions are focused on company tone and preference.

Objective suggestions help you improve your writing skills and subjective suggestions guide you to align with company voice.

Find Paid Projects

Once you're comfortable writing technical content and doing content research, start searching for paid work. Apply to entry level jobs or look for freelance projects on job boards and in your circle. Doing the real work will really help advance your technical writing journey.

Though freelance platforms have become competitive, you can still find paid projects there. Personal branding works wonders in landing paid opportunities. Keep your GitHub and LinkedIn profiles updated, and share your achievements there to attract potential clients and stand out from the crowd.

How to Learn the Skills for Technical Writing

You can find a lot of quality writing courses, but finding the right course can be a struggle. I've taken quite a few writing courses and I'd love to help you out by sharing the tips and courses that are worth your time:

1. The Secret Sauce of Great Writing by Shani Raja is a perfect course for beginners. It covers the core aspects of good writing with practice exercises and lots of examples.
2. DevRel Uni is an online cohort-based program for people seeking to switch to developer relations. They've got a separate class on documentation writing where experts share the secrets of good documentation.
3. Whenever you secure your first external project, pay attention to editor suggestions. If it's a contributor article and they don't offer a one-to-one editing process, compare your submitted copy with the published article. Take notes of the changes they made. Editor suggestions are precious to make your writing better and if you take them seriously, you'll witness improvements in your writing soon.

Conclusion

Though career change can be exciting, transitioning from development to technical writing isn't too daunting. You just need to manage your career change anxiety, build a portfolio, and start cultivating your personal brand for a successful transition.

Still got questions? Feel free to reach out to me on LinkedIn.

We just posted a course on the freeCodeCamp.org YouTube channel that is a guide for those making a career change into tech. This course will equip you with the knowledge, strategies, and insights needed to navigate the complex landscape of learning to code, ensuring a smooth transition into software development.

Zubin Pratap, the creator of this course, brings a wealth of experience and a unique perspective to the table. With a history of securing positions at prestigious companies, including Google, within just eight months of applying a systematic approach to learning, Pratap's methodology is both tested and effective. The course is the culmination of years of trial and error, refined into three hours of focused, impactful learning designed to save you months, if not years, of wandering in the vast expanse of coding resources.

Course Overview

The course is structured to address the most common pitfalls and questions that beginners face: Where to start? How to choose the right resources? Am I too old to learn to code? What should I avoid doing? Through Pratap's guidance, you'll discover the answers to these questions and more, enabling you to avoid the mistakes that many before you have made.

Key highlights of the course include:

• Starting Right: Understanding the fundamental questions of who, what, when, where, why, and how to approach learning to code.
• De-Mythify: Dispelling common myths about coding, such as the necessity of a CS degree, the role of math, and misconceptions about the difficulty and excitement levels of coding.
• Fundamental Decisions: Guidance on choosing the right programming languages, frameworks, and tools that align with your career goals.
• Open Secrets: Unveiling the lesser-known tips and strategies for effective learning and progress in coding.
• Setbacks: Transforming obstacles like confusion, self-doubt, and slow progress from demotivators to stepping stones towards success.

What Sets This Course Apart?

Pratap's course stands out for its clarity, conciseness, and focus on the critical, often overlooked aspects of learning to code. It's not just about teaching coding; it's about teaching how to learn coding effectively. The course answers the philosophical question posed by Seneca two millennia ago, emphasizing the importance of having a clear goal and direction in your learning journey.

Conclusion

By the end of this course, you're not just saving hundreds of hours of aimless learning but also setting yourself up for success in the tech industry. It's more than a coding course; it's a blueprint for success in the tech industry, designed by someone who's navigated the path and emerged victorious on the other side.

Watch the full course on the freeCodeCamp.org YouTube channel (3-hour watch).

It's almost been two years since I got into coding and a year since I became a full-time dev.

I started writing this article merely as a self-reflection exercise. But I thought maybe someone who's in a similar position as I am or is just starting to code right now might find some of my experiences useful or interesting.

I plan on talking about a lot of things here. I'll go over everything from my background and how I switched careers at almost thirty to how I learned to code and chose my tech stack.

I'll also discuss what I plan on learning in the future and why, along with some general advice and my overall feelings and thoughts about this first year of professional work.

The way I'm going to structure this is that first I'm going to tell you the story of how I became a developer. Then I'm going to list the main thoughts and concepts that have helped me get to where I am now.

This article is going to be a bit different from what I usually write, in the sense that it won't be too technical and it might get too self-referential at some points. But the idea is to take you through my experience and thought process so you can get an idea of how things could be if you walked the same path.

Although always remember my opinions and experiences don't necessarily extend to everyone else. And I don't claim that my choices and preferences are necessarily the best. So you know... if you read through it all, just take whatever is useful to you and ignore the rest. :)

Enough cháchara, let's go!

Table of Contents

• My background

• How I learned to code

• My first job as a developer

• Present tense and future

• Tips and thoughts

  • Learn how to learn

  • Try to find a path

  • Do you need a college degree to work in technology?

  • What kind of developer do you want to become?

  • How to pick a tech stack

  • Don't jump around too much

  • Don't be too comfortable or get ahead of yourself

  • How to know when you're job ready

  • Sometimes not coding is the best way to learn about code

  • Diversify your learning sources

  • Keep in mind that nobody knows everything

  • There're good and bad things too

• Wrapping up

My Background

I'm a 29 year old guy from Buenos Aires, Argentina.

I grew up here, and once I finished high school I had no idea what to do with my life. I knew I had to go to college because that's what everybody else was doing. And according to "general knowledge", that was what was going to give me the best chances at life. So I started investigating around different career paths...

I was a shy and introverted adolescent in high school, so in this new chapter of my life I decided to change that and get more in contact with people and society in general.

I was attracted to social sciences studies such as philosophy, psychology and history. But It worried me that these professions weren't very in demand in the labor market. So I ended up choosing a major in human resources, as I thought it was a good match between social sciences and business.

I made this decision completely by myself, as I was part of the first generation of college students in my family. I didn't really know anyone who could guide me in this situation. I just made the best guess I could with the information I had.

Fast-forward a couple of years and I was starting to heavily regret my choice. I wasn't interested at all in what I was studying. The rigid structure and bureaucracy of college bored me to death and I had the feeling that I was wasting all my youth hearing people I didn't respect giving me meaningless lectures.

I started analyzing again what other career paths could I take, but nothing seemed to convince me enough. I even consulted with a group of vocational orientation professionals who charged me a ton of money for telling me that I was going to be a great HR manager in the future and that I should "just keep going".

This together with the fact that I had already put two years into this college thing convinced me to "just keep going".

Fast-forward another couple of years and I still felt the same way, but at least I was close to graduation and I was also working. So I was still bored to death but at least I was making money out of it.

I finally graduated and exited college with the feeling of having learned almost nothing, just happy that I was finally going to have more free time.

Regarding work, I started climbing the corporate ladder. Switching jobs every once in a while, making a tiny bit more money, and working for big and well known companies.

At this point I somehow got convinced that I liked this life, and even though I never enjoyed my job or being in the office environment, this was part of the deal.

In 2017 I was working for a very big industrial company and was offered the chance to move almost a thousand miles away from Buenos Aires, in exchange for a salary raise and the promise of future professional growth. I thought about it and accepted, as at the moment it seemed like too much of a great opportunity to pass by.

The work environment in this new position was terrible. I had to deal with crappy tasks, crappy leaders, and crappy people in general. I was learning nothing and the promises of future professional growth ended up being BS.

Things kept going the same direction for a few years, and when the pandemic arrived I was working harder than ever, often putting in nights and weekends, but somehow my leaders weren't happy with my effort.

I was feeling stuck and bitter. I left my family back in Buenos Aires in order to grow my career, and even though I was working as hard as I could, I wasn't collecting any profits and I was disliking my job more than ever.

At this point I finally opened my eyes and realized I couldn't be there anymore. I didn't know what to do next but I definitely knew I had to get out of there.

Then I saw an ad somewhere about a programming course and started investigating coding. I was always interested in technology, and at the moment it just felt right to occupy my mind with something new.

I didn't think about it as a way to get a new job, but as a hobby, a way to get my brain to think about something else.

How I Learned to Code

So after seeing this add and getting interested in coding, I did what most people do when looking for information: I Googled things, opened a ton of browser tabs, and watched a million YouTube videos.

I remember at the time I often couldn't understand a single thing about those videos. So many strange terms where used and people related each of those terms to other topics I had no idea about.

I didn't really know how computers worked, much less how the internet worked. I didn't know what a programming language was, why there were so many of them, what was the difference between front and back-end, what a function was, what a variable was, what on earth was SQL ... So many concepts and all of them completely new.

I just didn't know where to start. Learning to code felt like staring at the wall of Game of thrones.

I was feeling like the recruiter here...

Here's where I got back to freeCodeCamp (I had done a bit of a basic HTML and CSS course a few years ago) and also downloaded an app called Mimo (which helps you learn to code in a Duolingo kind of way).

These structured courses helped me organize my learning and grasp the basics of things before moving onto more complex topics. I dedicated a few hours every day to these two resources, and after a few months I was able to build a very very simple HTML and CSS page.

After that I felt I needed to interact with other people who were in the same learning path I was. I wanted to share knowledge with others, hear from other people's experiences, and check if what I was doing and learning made sense compared to what everyone else was doing.

The way I got to this was by signing up for a few online bootcamp courses. I liked that classes were live with a professor and a bunch of other students. This meant that I had the chance to ask questions, hear other people's questions too, and compare myself to others.

Four months went by and at that point I was completely into coding. I'd become comfortable with HTML and CSS, and also learned basic programming concepts with JavaScript. I was dedicating absolutely all my free time to this and even though slowly, I felt like I was making progress each day.

By this time luckily I was able to switch jobs (still within the human resources field) and get back to Buenos Aires. I was working in a much nicer environment and I was happy with my job and the team I had. But I still kept coding and learning about it every day. I just liked it a lot and felt I could be good at it some day.

A few more months went by, I completed more bootcamp courses, and got comfortable with React as well. I was able to build some more interesting and "complex" projects on my own and with the passing of time I got more and more curious about how could it feel to do this for a living.

I could somehow picture myself as a developer, and after doubting a lot I decided to give it a try and started applying for jobs.

I got rejected A LOT and struggled BIG TIME with the few interviews I was able to get (you can read more about that in the article I wrote about tech interview tips).

Some of those interviews were like a reality check for me in the sense that they made me realize there was still an immense amount of things I knew nothing about and I'd need to keep improving if I was ever to have the chance of working as a dev.

These experiences kind of hurt my self esteem and made me doubt if I could do this. I gave up coding for a few weeks for the first time in almost a year, but eventually got back to it. I just liked it a lot and felt like I had to prove the people who rejected me wrong.

By this time I started to expand the resources I was using to learn. Live classes weren't that interesting for me anymore since I felt I didn't need constant feedback from others like I did when I was starting.

Now that I had a wide array of knowledge, terms, and concepts at least superficially present in my mind, I could easily take advantage of asynchronous resources like videos, articles, and documentation.

And more importantly, I knew what path I needed to go through in order to learn what I needed to learn to get to the jobs I wanted.

So I reduced the number of live classes I was taking, and started getting more into videos, articles, and documentation of good trusted sources I found.

Also, I started writing about each of the things I was learning, which made a huge difference for me as it helped me internalize knowledge, go into detail on each of the topics I learned, and gain confidence in a way I hadn't experienced before.

In parallel I was still going through different interview processes and feeling better and more confident in these situations. And in one of these processes I ended up getting hired. 🙃

After a year of learning, burning my brain, and dedicating absolutely all my free time to code, I finally reached my goal.

I remember I felt as happy as I'd ever felt when I got the news. It felt like ending a marathon. I'd never before put so much consistent effort into something, and the feeling of going from knowing nothing about technology to being able to call myself a "programmer" was amazing.

It was really a great moment, but to tell the truth, I was also scared to the bone... When I looked into the mirror I didn't see a programmer. I saw a guy who still didn't know much. And now I was going to switch careers and put my financial (and emotional) stability at risk. Crap... 😳

My First Job as a Developer

Luckily, all the fears I had going into my first developer job were unfounded. I landed on an amazing company, and got to work on an amazing team with an amazing leader.

There were TONS of new things to learn, and at moments I couldn't understand a single thing. But my team made it clear to me that this was what it was supposed to feel like and that I should be patient and stick to the process of learning.

I did, and I took it step by step. With the help of my leader and teammates I was able to become pretty much proficient in a matter of months.

My team had a great culture and our leader encouraged us to share knowledge all the time. If someone found a bug, created a new feature, or wrote some documentation, that had to be shared with the rest of the group.

The same went for when someone made a mistake. Mistakes were not treated as opportunities to blame someone, but as chances for everyone to learn.

We had weekly meetings in which we shared this kind of information with each other. Through this continuous exchange I made a huge "click" in my mind. I understood no one knows everything.

Before I got this job, one of my biggest fears was that I wasn't prepared enough. There were many things I knew nothing about and I felt I "was supposed" to know them. But after getting to know developers with 5, 8, or more years of experience, I understood even with that amount of study and preparation, they still don't know everything. And that's ok, because no one can.

The size of the technological world humans have created and the constant evolution of it just makes it impossible for a single person to understand and know every single detail.

What I think is truly important is to deeply understand the given set of tools you work with in your environment, and to have a superficial understanding of the general system you work within.

But even then, you'll still never understand everything. Learning new things all the time and figuring things out is a core part of the job. In fact, what most companies pay engineers for is to figure things out. You just face problems you don't know how to solve at first, and slowly figure them out until you arrive to a solution.

This single idea was very powerful to me, and allowed me to get over the impostor syndrome I felt.

Overall I was feeling awesome at my new job. I was working remotely all the time (which I love and allows me to spend more time with my family and pets). I was working with people I felt related to in the sense that everyone was interested in sharing knowledge and constantly learning. And I felt my job was stimulating and interesting.

I was using my brain everyday, having to think in order to solve stuff, and that made me feel alive and useful instead of the zombie-like feelings I had in past jobs.

The feeling I had (and still have) is that my job and my hobby are the same thing. I'm not longer living for the weekend (great song by the way). I enjoy my job and I still dedicate most of my free time to learning and doing code-related things because I like it.

Present Tense and Future

After 9 months at my first job as a developer, I got the chance to switch jobs again. It was hard to leave such a great team and leader, but in my current position I'm able to work with cool technologies on a big and interesting project. Also, changing companies and projects has allowed me to understand a little bit better the process of software development and how different companies manage it.

It's also very interesting to get to know other fellow developers and learn from them. I feel there're things to learn from every single person working in this industry, so getting to know and work with new people every once in a while is something I'd like to keep practicing.

Besides focusing on my job, I also got back into college to study computer engineering. I made this decision because I felt most of the courses and classes I took focused heavily on learning to use tools (such as React or Node for example), but I lacked the basic knowledge those things were built upon.

I wanted to have deep knowledge about computer science topics too, and even though there're many ways in which you can get this knowledge, college made sense for me.

I find it funny that I'm having a completely different experience now compared to my first time at university. I'm attending classes with curiosity and learning at least a few useful things every time. Being truly interested in what you're learning and understanding the purpose of the information really makes a huge difference.

And besides those two things, I'm also working as a part-time assistant teacher in a coding bootcamp and trying to periodically write articles.

Sharing knowledge with others is something I really like and appreciate about the coding world, and without a doubt is one of the things that has allowed me to learn the most. Lots of people have benefited from this practice and I'm not an exception.

Regarding the future, I want to train myself as a well rounded software engineer. And by this I mean I'm aiming to gain knowledge about the whole ecosystem of things that lays around the creation of web-based software: front-end and back-end development, testing, infrastructure, cloud technologies, CI/CD, systems design and so on.

I feel that having at least a superficial knowledge of the core concepts in each of these fields is important and valuable, even though if end up specializing in a certain field later on. So this is what I'm directing my attention towards at the moment... and the rest is just to keep going.

Reflecting on the steps I took in the last few years, from the position I'm in now, I kind of appreciate how the experiences I had led me to where I am now.

Working in the social sciences environment for several years allowed me to gain the social skills I lacked when I was an adolescent. Also, working in toxic environments forged my character and gave me the ability to appreciate good teams and leaders.

It's likely that if I had never gone through those unpleasant experiences I would've never gotten into coding.

Life is really weird... I don't like to pretend I know how it works. I don't think anyone does. But in these past years I learned for myself that I can do whatever I set my mind to if I put enough time and effort into it.

I also learned that I should never settle for a situation I'm not comfortable in. What I like to do for a living is learning, thinking, and using my brain to solve problems.

Tips and Thoughts

So now that we're done with the telenovela, I'm going to present you with the main concepts and thoughts that have helped me get to where I am now.

Again, keep in mind this is not direct advice. Some of these things might not apply to you, but the idea is to share them so you can analyze and make decisions for yourself.

Learn How to Learn

If you'd like to become a developer, become comfortable learning things constantly. As I mentioned, I think this is a core part of the job for most of us.

Get used to the struggle of not understanding things at first, asking questions, doing research, making little or no progress at all, giving it another try, googling, watching videos, reading articles... and slowly but surely getting to what you want.

If you struggle and at times feel you're just not capable of understanding anything, that's ok! We all feel that way. The important thing is to be consistent, don't give up, be curious and keep going. You'll eventually wrap your head around things – just don't expect it to be easy or quick.

I think the best way to learn how to learn is just to keep trying. It's like a muscle: if you push it it will get stronger.

The cool thing is that things get easier as you advance. The more concepts and ideas you understand, the more connection points you'll have for the next topic you get into, which will accelerate your learning curve and help you move faster.

Try to Find a Path

The best thing about learning how to code is that there's so much information out there. The worst thing about it is also that there's so much information out there.

At the beginning everything sounds foreign and hard, so I think getting some kind of structure is of great help.

There're many sources for you to choose from. Free and with a cost, live or asynchronous, to learn alone or in a group... It's up to you and what you find works for you.

I'd say it's a good idea to start with something free to test if you like it. Then try different sources and work with the one or two you're more comfortable with.

Also, during the first steps, I feel like having the companionship of a tutor or a community is key to continue your learning path.

So much info can be overwhelming and it can be hard to know what to do next. A community and people to ask questions from can help diminish this level of uncertainty at the beginning.

Live classes solved this problem for me, but there are tons of ways to get in touch with people who are learning to code, so find one that suits yourself.

Also, after a while and once you have a clear understanding of your environment and what do you want to do, live classes can start to get less efficient and asynchronous learning becomes the best thing to do.

So getting to know useful and trustworthy sources of knowledge is key. And I don't have a recipe for this – for me it was just a matter of countless hours of exploring blogs, YouTube channels, and websites. And of course still all the time I'm finding great resources...

And about that, here I've put together some of the coolest resources I've found recently. Maybe it could be a good starting point for somebody. I'd also like to receive recommendations if you have any. 😉

Do You Need a College Degree to Work in Technology?

Absolutely not. I was able to get a good developer job without a related college degree.

Also, if you're just looking to switch jobs and get into tech, I'd recommend going to a bootcamp or completing some free online courses. It will probably be much quicker and cheaper for you than learning through college.

What I do think is that if you can afford going to college (both money and time wise), a degree won't hurt at all. And through college you can learn a series of general foundational concepts not often available in a bootcamp or programming courses (though this information is also available in other media and for free as well).

In my country, college education is relatively cheap and there are quality free options as well. So college was a reasonable choice for me. But this may vary from country to country and from person to person.

What Kind of Developer Do You Want to Become?

Once you start to comprehend the technology world, you'll see that the software engineer profession has many different paths and nuances. To name a few:

• Front end developers: Build the visual side of websites

• Mobile developers: Build mobile apps

• Back end developers: Work with all the software that is not directly exposed to the end user, like databases, authentication, and so on.

• Testing / QA: These people write programs to test that the software developed works as expected.

And many other paths like infrastructure, data analytics, robotics, and so on.

At first you won't be able to tell the difference between the one and the other, and that's ok. A good idea is to do a little research to understand all the possibilities that exist within the software engineering world, and see what you like most.

Also keep in mind there're different environments you can work in. From huge worldwide corporations to tiny startups, to freelance work, to starting your own company... Anything is possible.

Different fields and different environments make different experiences, and some might be better suited for what you like and what you're interested in. And also they'll require you to learn different things to get to work in those places.

How to Pick a Tech Stack

This is closely related to the kind of job and the environment you'd like to get. Though all knowledge is useful, some technologies are more related to one field and one type of environment in particular. So choosing carefully what to learn will help you use your time more efficiently and get to your goal quicker.

If I had to give a general path that applies to most people, I'd say get to know basic HTML, CSS and core programming concepts with JavaScript (variables, functions, loops, conditionals, data structures, and so on).

There're are lots of online resources where you can get this knowledge, and having these concepts under your belt will help you to some degree no matter what path you choose later.

I also feel that it's the easiest way to get into software since you start from a visual perspective that will allow you to build at least a very simple website in a few weeks.

Once you're there, I'd recommend that you analyze the different possible career paths and decide what you like the most or find the most interesting.

Watch videos, read articles, talk to people... Get a feeling of what each kind of job is about and what technologies are used in each of them. Then based on that, keep learning.

I find it's also important to choose based on what's available for you. For me, the bootcamp I was learning in had React and Node courses available, so that kind of laid the path for me. Maybe if they had Angular and Python courses I would've learned those technologies instead.

I don't really think it makes that much of a difference as long as the technologies serve your purposes. In the long run, technologies are only tools. And you can use many different tools to arrive to the same results.

Also keep in mind no choice is definitive. I mean, if you get into something and find that you don't like it, you can always get back and learn something else. It's useful to have some kind of plan and learning path, but it's not something rigid that can't be changed ever again.

Just to give you a superficial idea, the path I followed (and I'm still following) looks like this:

• HTML

• CSS

• Git and GitHub

• Basic terminal usage

• JavaScript

• React

• Node, Express, MongoDB and PostgreSQL

• Algorithms and data structures

• Testing: Jest, react testing library and Cypress

• TypeScript

• Intermediate terminal usage and scripting (Bash)

• React Native

• Firebase / AWS

• GraphQL

• Python

• Docker

Don't Jump Around Too Much

The idea of having a learning path is to provide structure and meaning to knowledge you'll acquire, so you can get to your goals quicker.

As I mentioned before, there's a huge amount of information out there and that's awesome if you know what you're looking for. But if you're not certain about what you need to learn, you might get lost between all the different possibilities and end up knowing just a tiny bit of a lot of things – and that's not really useful.

At least at the beginning, I'd recommend that you dedicate at least a few weeks to each new tool or concept you're learning. Make sure the knowledge sinks in and build a project or two with the tool you're learning, and then hop on to the next thing.

If possible, with each new thing you learn, try to add it to the same project or build a new one with all the tools you know up to that point.

For example, if you learned React before and now you're learning about back-end with Node, a good idea would be to build a front-end for that back-end too. Practice and repetition will make you better.

I also wouldn't recommend learning more than one thing at the same time. For example, let's say you're building your first React project and you're using TypeScript for the first time as well. That could be problematic, because when you get an error you might not be able to distinguish if it's a React or a TypeScript thing. You could also confuse concepts that belong to one technology with the other.

Don't Be Too Comfortable or Get Ahead of Yourself

Following the previous thought, I think it's important to push yourself and try to learn new things all the time. But it's also important to know where you are and control your rhythm. By this I mean, know when you need to move to the next thing and know when you need to stick to what you're learning at the moment.

This is a hard thing to know, and there's no way to be absolutely sure. I'd say you don't need to become an absolute expert, but at least build two decent projects with each technology you learn.

Make sure you understand the basic concepts behind it, understand the most common errors and problems you can face using it, compare your code to other people's code, and so on. If you feel you understand and can relate to most concepts regarding to that particular technology, then you're probably ready to learn something else.

Regarding what to learn next, that depends on your learning path and the things you've learned previously. I'd say a good sign is when you're able to connect some of the previous knowledge you have to the new things you're learning.

For example, if you learned HTML and now you're getting into CSS, you'll be able to understand how CSS helps you configure how HTML elements look and behave. If you learned JavaScript before, you'll be able to understand how TypeScript helps you control types and so on.

On the other hand, if you're trying to learn React without having a clue about JavaScript, you're very likely to mix concepts and confuse what technology is responsible for each thing (for example, I've seen many people think map, filter and reduce functions are a React thing, while they're all ES6 JavaScript features).

Consuming the right amount of information is important. Too little and you won't make progress, too much and you'll get confused and not make progress either.

How to Know When You're Job Ready

Short answer is you'll never know. You'll need to try yourself and (probably) fail to see what you still need to get better at.

There's not an exact recipe to get a job. Companies require different skills and have different levels of demand for their candidates.

I'd say a good place to start would be to go through job postings and see what kind of knowledge is required for the types of jobs you like. Once you're more or less comfortable with most of the things they require, I'd say start applying.

Waiting too long to apply for jobs can also hurt you. Even though doing badly at an interview sucks (I know, trust me...), it will really help you realize what knowledge you lack, and in that way accelerate your learning process.

You can read through this interviewing guide I wrote to help you prepare as much as you're able.

Sometimes Not Coding is the Best Way to Learn About Code

I feel that when you start out, building things is the best way to learn about programming. It gives you practical knowledge and the feeling of progress (which is key to get over the frustration any learning process involves).

But once you get comfortable with the practical side of things, I think it's also important to get a theoretical foundation. Learning how tools work, how the internet works, how computers work, the history of computer science, algorithms and data structures, and so on. I don't mean becoming an expert, but at least superficial knowledge of these topics is useful.

Regarding how to get this, you can go with videos, articles, books, courses... Again, there're countless resources to pick from.

But something I found really useful is to actually create content. Writing stuff, sharing knowledge, helping others – it all makes you think about code and programming from a different angle and have a deeper understanding of topics.

This is one of the main reasons why I like writing articles. And what I find the most interesting about it is that when I get back to actually coding, I feel that I'm a better programmer than I was before. I guess sometimes not coding is the best way to get good at it.

Diversify Your Learning Sources

I think a good way to wrap your head around complex topics is hearing different "voices" explain the same thing. Different people will use different analogies, vocabulary and approaches to explain. And eventually you'll find one that works for you.

Same goes to different formats like videos, articles, courses, and so on. Each time you're learning a new thing, try to combine different learning sources together so you can get a good general idea of it.

Keep in Mind that Nobody Knows Everything

Looking from the outside, it may seem that people working in the industry know so much more than you. But they don't know everything.

Senior developers normally have deep knowledge in some particular stack, but they don't know everything about everything, so much less should you if you're just starting out your learning path.

For me, being curious, eager to learn, and consistent in your learning efforts is the most important.

There're Good and Bad Things Too

For me, technology is the best possible environment to work in right now. Jobs are interesting and well paid, and the job market demand for developers is high (and it will probably keep growing in the future).

It's also one of the few sectors in which you can have a good job without a college degree.

I love it, and getting into technology has made a very positive change in my life. But I also think It's important to reflect about some of the negative things around it. For example:

Working remotely has challenges

Working remotely is great in many senses. For me, it has given me much more control over my time. It has allowed me to save tons of commuting hours and invest those hours into studying, spending more time with my pets and family, or just sleeping more. On the other hand, I recognize it has also separated me a lot from people and society in general which sometimes leads me to feelings of isolation, monotony, and social anxiety.

Working in tech can be stressful

Working in a project-based environment (which is the most common thing in technology) is awesome. You get to do different things every once in a while, facing different challenges, learning new things and getting the feeling of progress and accomplishment. But on the other hand, the pressure of dealing with deadlines and needing to solve technical problems so things can get done can be hard to deal with, especially at the beginning and on occasions where you don't have help from others.

While most people are nice...some really aren't

Though most people I've met in tech are nice, curious, and really eager to learn and share knowledge, there're also some egotistic, arrogant, and selfish people too. There're good and bad people in all paths of life.

Technology has a huge impact on our lives

To a bigger or lesser degree, by working in technology we're designing and making decisions that shape an important part of the world's reality and people's lives.

Think about it – technology is everyday becoming more and more intrinsically connected to everything we do as humans. From deciding what or where to eat, to traveling, to meeting new people and building relationships, to buying things, studying, managing money, looking for jobs or something so basic and central like getting to know the world around us. Googling has become the most primary action for most of us when we want to get information about anything.

Technology is absolutely everywhere around us. And as developers, this is great for us because it gives us a huge platform to impact people's lives in a positive way.

But that platform can also impact people's lives in a negative way too. As humans we've become so dependable on technology that decisions made by tech companies and engineers can have the same or more impact on society than those made by politicians.

We're all more addicted to our cellphones than we'd like to admit. Social networks have been used by companies to have a very detailed understanding of our expectations, preferences, fears and emotions. And from that knowledge, get us to buy things we don't need to impress people we don't like (yeah), or even worse, manipulate people's political opinions.

Technology is a very powerful tool, and that tool can be used both for good and for bad. The purpose and impact of it is up to us to decide, both as users and as developers.

Wrapping up

Well, I've talked about a lot of things here. I hope some of these concepts helped you picture how it may be to work in the technology industry yourself. Or at least cause you just to think and reflect about a thing or two.

If you read through all of this, I'd love to hear about your feedback or your own story in tech. You can hit me up on LinkedIn or Twitter if you'd like. 😉

Here's a little goodbye song for you (I'm making this a thing now 🤷‍♂️). See you in the next one.✌️

But the good news is you don't necessarily have to be a developer to be in the world of tech.

This article is a guide for people struggling with the transition to tech. It will explain various careers in tech that you can consider. We'll also discuss how to know whether a particular path suits you or your personality.

This is based on my views and experience, but I hope my insights will prove helpful.

Table of Contents

• UI/UX Design Path

• Frontend Path

• Backend Path

• Data Analysis & Data Science Path

• Cyber security Path

• Graphic Design Path

• Program Management Path

• Human Resources Path

• Growth Management Path

• Business Development Path

• Community Management Path

• Developer Relations Path

• Technical Writer Path

• Quality Assurance Path

• Motion Designing Path

• Digital Marketing Path

• Mobile Development Path

• Developer Operations Path

• Game Development Path

Possible Careers in Tech

UI/UX Design

UI/UX Illustration

If you love aesthetics and enjoy styling things, then UI/UX design might be your career.

What is UI/UX Design?

UI stands for User Interface and refers to the screens, pages, and visual icons that users interact with on a webpage or in an app (buttons, icons, and so on). A well-designed UI helps non-techies and all end-users interact with a product or a service online.

UX stands for User Experience and involves helping a product or service improve its customer's service. A good UX can also help grow followers for the brand.

As a UI/UX developer, your job is to design and build out a user's experience for a brand or company.

A UI/UX developer must know and understand how to use the following:

• Wireframing: A wireframe is a webpage layout stripped of visual design. You use it to prioritize page elements based on user needs.

• Prototyping: A prototype is a sample or simulation of a final product used to test and gather feedback. Low-fidelity prototypes might be sketched on paper and don't allow user interaction. High-fidelity prototypes are typically computer-based and allow for mouse and keyboard interaction.

• Mockup: A mockup allows designers to get an idea of a realistic visual model of a final webpage or application.

• User flow: A user flow is a way to map out each user's steps when using a product or service. This helps improve the user experience.

What tools do I need to become a UI/UX Developer?

If you're working as a UI/UX developer, you'll likely use tools like:

• Adobe XD

• Figma

• Photoshop

• Sketch

There are lots of tools, but these are the most popular.

A UI/UX developer designs websites and web apps and helps improve user experience with the need-to-knows mentioned above. You can get inspiration from Behance or dribble if you wish to go down this path.

Here are some resources to help you get started as a UI/UX designer:

• Figma Tutorial for UI Design - Course for Beginners

• UI / UX Design Tutorial – Wireframe, Mockup & Design in Figma

• UX Design Tutorial for Beginners

Frontend Development

Frontend Tools Illustration

If you love creating websites, you should consider frontend development.

A frontend developer ensures that a visitor can easily interact with a webpage. They use design tools, various frameworks and libraries, and coding to build websites.

Frontend devs are also client-side developers because they directly build the elements on websites and applications with which users and clients interact.

The leading web technologies used by frontend developers are:

• HTML (HyperText Markup Language):

HTML lets you build the skeleton of webpages and websites. The markup language defines the web. You can think about it as the structure of a house because it holds all the text and defines every header 0n a website.

• CSS (Cascading Style Sheets):

CSS is responsible for making the website beautiful. You can think of it like the decor of a house. You use it to give your pages color, animations, and more after the HTML has displayed the text.

• JavaScript:

JavaScript handles the responsiveness of the website. It gives life to a website, helps make it look fabulous on every device, and makes it more interactive.

You will need basic knowledge of these languages to build a unique and interactive website successfully. Knowing only one of the mentioned tech skills won't be enough to build production-quality applications because you will just be able to create a half-useful website.

Sometimes, frontend developers work hand-in-hand with UI/UX developers.

What tools do I need to know to become a Frontend Developer?

A code editor or an IDE (Integrated Development Environment)

A code editor/IDE is where you'll write your code, debug it, and preview written code.

There are many editors/IDE to choose from, but the most popular ones are Visual Studio Code, Atom, and Sublime text editor.

Chrome Developer Tools

You use Chrome DevTools to debug real-time applications on Chrome. It gives you an understanding of and access to important internal information of a web application. DevTools also helps you understand how to optimize the loading flow and what the browser is doing now.

Git and GitHub for version control

I know what you are thinking – what is a version control system? It is a system that helps you review your code in stages and keep track of your (and others') revisions. Git is a version control system, and GitHub is an online hosting service for Git repositories.

Say you are working on a landing page, and you messed up the footer, and in the codebase, it seems hard to debug. You can quickly go back to previously committed code on your repository and see your last change(s). Although, you can only see your previous commit when you commit to your repo.

GitHub helps team members work together more efficiently, and you can use it to contribute to open source projects.

Here are some resources to help you get started in Frontend Development:

• Frontend Developer Guide for 2022

• Frontend Development with HTML, CSS, JavaScript

• Responsive Web Design Course

Backend Development

Backend Tools Illustration

If you love working with and building things that depend on you, you should be a backend developer.

A backend developer builds and maintains technologies or software necessary to power client-side development components. They are also called server-side developers.

Their work includes:

• Building/maintaining databases

• Working with data and application integration

• Working with APIs

• Building out the core application logic

What tools do I need to become a Backend developer?

Backend devs use almost the same tools as Frontend developers. Here's what you'll find helpful:

• Code editor/IDE: This is used for writing code, debugging, and previewing codebases.

• Chrome developer tools: This helps you debug your code.

• Git and GitHub: This helps you review your code in stages and makes team-building, collaboration, and open source contributing easier. Any developer can contribute to your project if the repository is public.

• SQL or NoSQL server: SQL stands for Structured Query Language. This helps you query databases and interact with them while building an application.

• Knowledge of a database

Here are some resources to help you get started in Backend Development:

• Backend Development and APIs certification

• Backend Roadmap

• Back-end Development and APIs - FreeCodeCamp Tutorial

Data Analysis and Data Science

Data Science/Analysis Skills Illustration

Consider a data analyst career if you love calculating, mathematics, or statistics.

Data analysis involves examining, transforming, and arranging a given data set in specific ways to study its parts and extract useful information. It deals with interpreting, analyzing, and visualizing data.

In layperson's terms, data analysis involves gathering insights from data to aid business decisions.

Data science handles data using machine learning, algorithms, and statistics. It is the statistical part of the data field. Data scientists collect, clean, and interpret data sets for surveys. So data science involves statistically analyzing data.

It's always better to start as a data analyst and then transition to data science because data analysis is the foundation of data science. Although they may be on the same path, there is a fine line between data science and data analysis.

Data is present in every industry, so data scientists and analysts are needed everywhere.

Essential technical skills to have for Data Science:

• MySQL

• Python programming language

• Mathematics

• Statistics

• R programming language

What tools you would use in this field:

• Microsoft Excel

• Google Spreadsheets

• Tableau

• SQL Server

• PowerBI

Here are some resources to help you get started in Data Analysis and Data Science:

• Discover Data Analysis

• Data Science For Beginners

• Data Analysis certification

Product Management

Product Management Skills Illustration

This is for you if you are great at organizing products and teams.

A product manager manages and coordinates product development projects. The product manager is the voice of the customer on the team.

They ensure that the product being built contains the features and requirements needed to satisfy the customer. They're also in charge of drafting out a roadmap for that product, from imagination, all the way to launch. And they are the ones who decide what feature to include in v1 or V2.

Their responsibilities include:

• Understanding user needs,

• Drafting out roadmaps for the product being built.

• Defining a vision for the products

• Developing competitive analyses

• Prioritizing product features

And lots more.

Common tools product managers use:

• There are many tools for user tracking and analysis such as Pendo or Amplitude. These apps give insight into users' activity on the software or website.

• Product Plan is a road mapping software to draft out and manage the product plan. They can also handle version-control issues that can slow your product's progress.

• Survey Tools such as Typeform are very handy. PMs use them to carry out customer or user surveys to help improve the product to users' needs. A product manager can easily track and analyze the results using these tools.

• Feature flagging tools such as Split.io help teams quickly turn specific features when users have flagged them. This is useful during a notable feature or product launch or testing process.

• Flowcharting tools such as Visio help create product development workflow and help the product manager structure the user journey on the product.

Here are some resources to get started in Product Management:

• Product Management Fundamentals

• Introduction to Product Management

• Product Management Tutorial for Beginners

Cybersecurity

Cyber Security Skills Illustration

If you are passionate about security, consider a career in cybersecurity.

Cybersecurity involves everything from encryption to finding and protecting against malware or viruses to hacking to find security vulnerabilities in a system so they can be fixed.

A cybersecurity specialist protects digital information for individuals, companies, firms, and the government.

Their tasks include:

• Testing, analyzing, and implementing security system developments

• Managing system vulnerabilities

• Responding to security threats and attacks

• Developing threat prevention strategies

• Reporting directly to administrators and executives

Tools cyber security analysts use:

• Network security monitoring tools such as Splunk or Argus. These tools keep track of network threats and analyze network data.

• Encryption tools such as VeraCrypt and TrueCrypt. These tools are used for encryption by scrambling plain text to code that is not accessible to unauthorized users.

• Vulnerability scanners such as Nikto and Burp Suite. These tools scan software to identify security vulnerabilities using SQL Injection and cross-site scripting.

Here are some resources to get started in Cyber Security:

• Complete Ethical Hacking Course - Network Penetration Testing for Beginners

• Cyber Security Full Course for Beginner

• Cyber Security Training Course

Graphic Design

Graphic Design Skills Illustration

If you love designing flyers, logos, and other graphic elements, consider a career in graphic design. Many people will argue that graphic design is not a technical career, but it is because it helps bring ideas to life, like UI/UX designing.

A graphic designer is in charge of digitally beautifying a company's brand, assembling images that tell consumers about the brand, and creating motion graphics for a brand.

Graphic design as a tech career involves:

• Creating layouts

• Digital editing

• Typesetting

• Presenting design products

Some Graphic Designer tools you should know:

• Adobe Illustrator

• Procreate

• Adobe Photoshop

• Affinity

• Canva

These tools will help you get the most out of your designs, and they're used by designers all over the world.

Here are some resources to get started in Graphic Design:

• Graphic Design Tutorial For Beginners

• Photoshop for Beginners

• Graphic Design Crash Course

Program Management

Program Management Skills Illustration

If you love creating and managing structures, consider being a program manager.

A program manager oversees the fulfillment of company goals. They manage the practical programs and coordinate activities between multiple projects without executing them. They also focus on implementing programs, program strategies, and delegating tasks.

They are involved in:

• Sales process

• Employee training

• Creating marketing plans

• Opening new facilities

• Product launches

Tools used in Program Management:

• Agile tools such as Trello and Jira.

Here are some resources to get started as a Project Manager:

• Program Management Standard Summary & Introduction to PgMP

• Everything About PgMP (Program Management Professional)

• Overview of Program Manager

Human Resources

Human Resources Skills Illustration

If you are good with people and enjoy helping them resolve conflicts and issues, you might consider becoming an HR specialist. HR stands for Human Resources.

Human resources management is recruiting talents and developing a solid company's workforce. The HR department identifies skills or human resources in a company, evaluates potential candidates, and hires talent. They are also in charge of advertising a position for a company.

An HR specialist screens, recruits, interviews, and places new employees.

Other HR responsibilities include:

• Handling employee relations

• Handling payroll

• Managing benefits and training for employees

• Consulting with executives on strategic planning

Tools and techniques used by HR Personnel:

• Programmatic Job Advertising Tools

• Pre-employment Assessment Tools

• Talent Management Solutions

• Expert Judgement

• Networking - they use a platform like LinkedIn to reach out to talents.

Here are some resources to get started with Human Resources:

• HR Basics

• Complete HR Generalist Tutorial for Beginners

• Principles of Human Resources

Growth Manager

Growth Skills Illustration

If you are passionate about making things better or bigger, a career as a growth manager might be for you.

A growth manager handles the execution of growth strategy for a business's product to direct consumers. Also, they coordinate initiatives with key financial partners.

Growth managers handle the company's financial growth from sales and marketing to networking and business stakeholder management to people management and work with almost every department. They set goals for workers of every department.

Tools used in Growth Management:

• Expand

• Zapier

• GrowthBar

• Colibri

• Airtable

These tools are all used to track the activity growth in a company or a product.

How to get started as a Growth Manager:

• Growth Manager course

• Growth Hacking for Beginners

• Growth Management courses

Business Development

Business Developer Skills Illustration

This career is for you if you are great at building relationships and are 100% business-oriented.

A business developer or business development analyst is in charge of helping organizations gain better brand recognition and financial growth.

They bring up ideas, initiatives, and activities that help improve a business, including increasing revenues, growth terms of business expansion, and profitability by building strategic partnerships and making decisions for business strategy.

Other business development job responsibilities include:

• Coordinating events with company executives

• Reviewing current market trends

• Proposing new business ideas to improve revenue

• Building relationships with potential partners

At a large tech company, a business developer works with the non-technical teams and the CEO or board to help grow the business.

Tools used for business development:

• Social Management Tools

• Email Lists

• Customer Relationship Software (CRM)

• Project Management Tools such as Jira or Accelo

• SEO (Search Engine Optimization) Tools

Here are some resources to get started with Business Development:

• Business Analyst Full Course In 2 Hours

• Business Development Course

• Business Analytics Course

Community Manager

Community Manager Skills Illustration

If you are good with people, can drive conversations in a group, and are good at motivating people, this is for you. Every tech community needs a community manager, and if you are great at communicating with people, this is definitely for you!

A community manager handles communication and serves as the face of the company. They act as the voice, face, and tone of the community. Also, they are responsible for the digital engagement to build the community's presence and trust online and in person. They are the liaison between the community and its users.

Community managers are involved in:

• Communication

• PR (Public Relations)

• Social media management

• Events

• Content creation

Tools used in Community Management:

• Notion

• Trello

• AhoyConnect

• Orbit

Here are some resources to get started with Community Management:

• Community Management Masterclass

• Community Management course for an engaging an audience

• Meta Community Manager Online Courses

Developer Relations (DevRel)

Devrel Illustration

If you love marketing, DevRel is a career path for you.

Developer Relations has job responsibilities similar to a Community Manager, Tech Author, Developer Evangelist, Developer Advocate, and sometimes even Growth Hackers and Marketers.

Their prime responsibility revolves around building a positive relationship with the developers on their team. They work between product, engineering, and marketing teams.

To work in the DevRel tech space, you'll need to:

• Be part of a community

• Build a presence in the community

• Learn how to interact with the community members

• Create content such as blog posts, articles, or videos

There are no specific tools developer advocates use because their roles are similar to other fields, so I will mention some essential tools:

• Notion

• Trello

• Code editor - because they often code as well.

Here are some resources to get started in Developer Relations:

• Intro to DevRel

• A complete guide to DevRel

• Prototyping your career in Developer Relations

Technical Writer

Tech Writer Skills Illustration

This is the best fit for you if you love writing and sharing your knowledge about various tech-related topics.

A technical writer generates innovative ideas for content (or works on assignments) while working as a team. They research products, services, technologies, and concepts and document/explain them clearly and concisely so anyone reading can understand how the product or tool works. A technical skill such as programming is needed to excel in this field.

Job responsibilities of a technical writer include:

• Generating ideas for content and workflow solutions

• Meeting with experts to ensure they appropriately cover and understand specialized topics

• Analyzing and explaining information about products, tools, policies, form documentation, and procedures.

• Also, they review and edit content developed by other team members.

Tools used by technical writers:

• Markdown editors such as StackEdit, Typora, Dillinger, and IA.

• API Documentation tools such as Bump, Redocly, Postman, and GitBook.

• Publishing Tools such as Document360 and Adobe Robohelp.

• Editing tools include Grammarly, Copy.Ai, Adobe Acrobat, Dropbox, Google Docs, and Evernote.

• Media management tools such as Snipaste, Loom, and Camtasia.

Note that different organizations use different tools, but those mentioned above are the most common tools for each category.

Here are some resources to get started with Technical Writing:

• Technical Writing Course

• Tech Writing Workshop

• A guide to Technical Writing

• Technical Writing for Beginners

Quality Assurance Testing

QA Skills Illustration

If you love writing and testing code, this is for you.

Quality Assurance (QA) testers are critical in delivering consumers high-quality, functioning software and web applications. They test and evaluate new and existing programs and help identify and remove bugs, glitches, and other user experience issues.

Tools QA Testers use:

• TestRigor

• Testim

• Kobiton

• Kualitee

Here are some resources to get started as a QA Tester:

• Quality Assurance Certification

• Software Testing Full Course

• QA Manual Testing Course

Motion Designer

Motion Skills Illustration

If you love CGI, this is for you.

A motion designer creates artwork for the web, television, and films, which include movie clips, trailers, commercials, and so on.

They use special effects called visual effects, animation, and other cinematic techniques to bring life to their created works.

Tools used in motion designing:

• Adobe After Effects

• 3D Blender

• Cinema4D

• Maya

Here are some resources to get started as a Motion Designer:

• Motion Graphics Tutorial

• Intro to Motion Design

• Motion Design Courses

Digital Marketing

Digital Marketer Skills Illustration

If you love selling products online, this is for you!

A digital marketer helps maintain a brand by working on marketing campaigns. It is online marketing because it promotes brands and connects potential users or consumers to the product through the internet.

Digital marketing is another form of digital communication. This is not limited to email, social media, and web-based advertising but also includes text and multimedia messages as a marketing channel for marketing.

Digital marketers' duties include:

• Creating content to help marketing campaigns

• Doing market research

• Strategizing with the marketing team

Tools used for digital marketing:

• Sprout Social

• Loomly

• Audiense

• SendGrid

• Ahrefs

Here are some resources to get started as a Digital Marketer:

• Digital Marketing Tutorial For Beginners

• Digital Marketing Course in 7 Hours

• Free Digital Marketing Course

Mobile App Developer

Mobile Developer Skills Illustration

If you love creating apps, this is for you.

The mobile development tech space is vast, and the tools and technologies you would use would depend on what area you chose to specialize in – Andriod app development and iOS development.

A mobile developer converts code into user-friendly applications. They work with other developers to develop functional mobile applications in a fast-paced environment.

Tools used for android development:

• Android Studio

• Eclipse

• Instabug

Tools used for iOS development:

• Xcode or App code

• Transporter

• Fabric

Some key responsibilities of app developers:

• Design the application,

• Test the application,

• Release the application

• Support the application.

Here are some resources to get started as a mobile developer:

• Android Development for Beginners - Full Course

• iOS Development Tutorial For Beginners

• Flutter Course for Beginners

DevOps

DevOps Skills Illustration

This is for you if you love working with infrastructure and cloud technologies.

A DevOps engineer works directly with developers and IT staff to supervise the release of code and brainstorm ideas for engineering and coding.

Their responsibilities include:

• Implementing automation tools and frameworks for automatic code deployment,

• Quality control and management of the code base,

• Designing procedures for system troubleshooting and maintenance and

• Writing scripts for service quality analysis, monitoring, and operation.

Skills you need as a DevOps engineer:

• Linux

• Basic knowledge of Python programming language

• Knowledge of cloud platforms.

Tools used as a DevOps engineer:

• Build tools such as Gradle and Apache.

• Package managers such as Npm and Mache

• CI/CD tools such as Jenkins.

Here are some resources to get started as a DevOps engineer:

• DevOps Tutorial for Beginners

• Microsoft Certified: Azure Fundamentals

• DevOps Engineering Course for Beginners

Game Development

Game Design Illustration

If you love games, this is a tech path for you.

Game designers translate design ideas into a functional game code. They create web games, mobile games, and iOS games.

Their responsibilities include:

• Coding the base engine of the game,

• Generating game scripts and storyboards,

• "Polishing" the game, maintaining the code, fixing bugs, and ironing out reoccurring problems

• Contributing to audio and animation design, and

• Creating game specifications and designing expansion packs.

Tools used as a game developer:

• GameFroot

• Flowlab

• Splender

• Construct

Here are some resources to get started in game development:

• Learn Unity - Beginner's Game Development Tutorial

• Basic Principles of Game Design

• Introduction to Game Development with Unity

Conclusion

Now that you have different options to get started in the world of tech, I hope you become less confused.

Choose a path and get started – the tech space is vast, so roles are constantly opening up. Don't fret because learning can be challenging. And remember – even senior techies suffer imposter syndrome.

• How I taught myself new skills

• How did I know that learning to code at 37 was not “too late”

• How I prepared for big tech coding interviews

• How I analyzed and minimized the risk of career change

• How I worked out that software engineering was “right” for me

• What languages I focused on

• Whether being a FANG/FAMGA software engineer is right for everybody (hint: tempting to think so but I saw plenty of evidence of it not being right for some people’s goals)

Note: I think “FAANG/FAMGA” is limiting, and prefer to refer to “big tech”since there are many highly prestigious companies other than the usual 4-5 everyone obsesses about.

Why I Wrote This Article

Each of those questions I listed above deserve their own article, even though I know our contemporary culture prefers “tweet-sized tips”. However, meaningful skills can’t be internalized from a few hundred characters.

So today I am going to share with you my answer to one of those questions – the approach I adopted when:

1. I made that first jump in careers from lawyer to coder at 38, and

2. How I prepared for big tech interviews at the ripe ol’ age of 39, with less than 2 years of coding behind me.

If you want me to write on any of the other questions I always get, please let me know! I’m going to put my contact details in this post somewhere, and the only way to find it will be to go through the article. 😊 That is also to encourage you to carefully read this article rather than skimming for a “quick tip”.

Uncovering the Real Goal

I hold the following opinions: getting coding interviews is harder than learning to code. Doing well at the interviews is often just as hard as getting the interviews. Behavioral interviews are hard if you don’t have solid experience – but your competition does.

When I made the switch I had zero coding background. Later, when I set my sights on Big Tech, I knew I’d be competing with PhDs, people who’d been coding since their teens (often 20+ years), and folks who'd achieved a lot more technically than I had in my one brief year’s experience as a developer.

And I had the added challenge of applying for big tech from outside the United States.

So I had to develop a plan that went well beyond just “learning to code”.

First, let me explain why I concluded that “learning to code” is the easy part, even though I’d tried and failed to learn to code 4 times, between 2012 and 2018.

This insight came to me in late 2018, when my startup was struggling. I had lost tens of thousands of dollars building my startup. I had no income for over 2 years.

And I decided to pull out over $40K from my mortgage. Why? I got into a top-rated bootcamp in San Francisco.

I left my family behind, and relocated to the US. I was meant to be there for over 14 weeks, but I withdrew from this top-rated bootcamp in week 1, and returned to Australia.

I had been super excited about the adventure (and scared from all the debt). But I developed grave doubts about the bootcamp strategy. I noticed that my instructors and the program were designed to help people "learn to code" rather than "becoming a coder".

From my experience on the hiring side in 3 other industries and 4 countries, I knew this was a mistake.

Learning to code is just a form of “literacy”. And literacy is not skill.

I was living proof: each of the 4 times I focused on “learning to code” I succeeded in a narrow sense. Whether it was HTML or Java or writing a simple Android app from a book, I always succeeded at learning how to read and write the basics. But I had no idea how to actually build anything useful. I was completely hopeless at applying my knowledge – I had no real “skill”.

In this century we don't get hired for what we know. We get hired for skill.

I quickly saw several reasons why a coding bootcamp was the wrong strategy for me.

This expensive bootcamp would likely give me some basic skills, the kind that may even get me an “entry level” job. But I could see things were going to be rushed, standardized, and focused on "getting out the other end".

I didn't want to "tick a box". I wanted skill. Competence. Confidence.

Moreover, bootcamps seemed to prepare everyone for entry level "junior developer" jobs.

I was 37 and I didn’t want to settle for an “entry-level job” mindset. Plus I don't believe anyone with 3 + years of experience is "junior" even if they're a total newbie in the field.

Then I discovered that several instructors and teaching assistants at the bootcamp were former students who hadn’t yet found jobs. They had never changed careers – many had never had a "career" as such. The job-search counselors had never even been on the interviewing side in tech.

How was I going to learn to do something from people who’d never done what I needed to do?

And then there was geography. Students based in San Francisco had advantages, whereas people coming from other parts of the US did not find work that easily and ran out of money in the long months after graduating and before getting their first job. Heck, I was based in Australia...how was this going to work for me?

I looked at my explicit goal. It was not to "learn to code" – it was to build a career that fulfilled me.

Plus, when researching bootcamps, I could see a path to learning “part time”. That seemed like a much more sustainable strategy to me because I could find a job and learn at night and on weekends. After over 2 years of no income, I needed to have cashflow in order to keep fear at bay, and focus on becoming a professional coder.

As the legendary businessman Harvey Firestone said:

“Having a surplus is the greatest aid to business judgment that I know.”

Having income while studying would give me the confidence to make better judgments. Better judgments are important for a career that is fulfilling in the long term.

I had no doubt that I would "learn to code" if I did 3-4 months in the bootcamp.

But would I learn enough for a good team to pay me money for my skills? I no longer believed bootcamps and online coding websites would help me achieve that.

Learning to code would not get me far. I had to be good enough to beat my competitors who had coding degrees, prior experience and networks. I wanted a career in code.

So I left the bootcamp, wrote off about $9,000 and returned to Australia. Sure, I had gained rudimentary coding literacy to pass the entrance test for the bootcamp. But I was very far from competent.

This analysis may be hard to understand if you’re new to the workplace. Another way to truly understand it is to notice that many of us play music, but aren’t in a band. As my mentor said:

"Michael Jordan didn’t want to learn to play basketball. He wanted to be in the NBA. Huge difference."

How to Use Your Advantages & Disadvantages

That one insight made all the difference. Within 8 months, in 2019, I got all 4 developer jobs I applied for. I simply followed the program I’d developed with the help of my (non-technical!) coach.

Don't be misled though. I had unexpected advantages. I benefited from 2 major advantages that initially appeared to be disadvantages.

This was not my first career change, and for almost a decade, I had been on the hiring side in previous careers. Today I’ve been on the hiring side in engineering too, and the patterns are very similar.

My biggest advantage was that I was no longer thinking about the job market challenge as a candidate. I was thinking about this from the perspective of the hiring manager. That had a significant impact on my plan because I had experience of how hiring managers think – their constraints, priorities, values, business needs, dislikes, red flags...

My experience (age?) helped me understand what impact I could deliver to a team and organization, and to identify the right people that I could learn from, who could help me with ideas, guidance, suggestions and referrals. What was a disadvantage was now an advantage – a career changer's advantage.

On the point of advantages, I want to call out something important.

The easiest thing in the world is to dismiss others for having “killer” advantages. It's easy to shrug and say "Of course – that’s why they succeeded". It’s easy to not notice that everyone has very compelling and serious disadvantages.

For me, my “disadvantages” were:

• Geography – I don’t live in the US or one of the other tech hubs

• No formal computer science qualifications

• Zero technical background

• A mortgage and financial responsibilities

• My “age” – learning new skills when you’re pushing 40 is harder than when you’re 25

• Cultural and social expectations, judgment, negativity

• Recruiters and bosses being younger than I was and uncertain of how to deal with me

• Compared to other candidates, people viewed my change as very, very “risky”

• I was going to earn less in engineering than I would as a lawyer

Every day I hear from people who let any one of these things stop them. While I cannot comment on whether or not they’re real reasons, I can say that if we argue for our limitations, we get to keep them.

Clinging on to our disadvantages does not help us overcome them.

With the help of my coach and a ton of mindset/psychology training, I was able to dig into my disadvantages and convert a few of them (not many!) into major advantages. And that’s when I realized that my experience with how interviewing, recruitment, and resourcing works would help me a lot in formulating a strategy.

Priority one: career change

When learning to code and intentionally setting the goal of becoming a professional coder, I found that I kept switching to short-term thinking and obsessing about my first role.

I wanted my first role to be glorious, to prove all my critics wrong, to pay me a gazillion dollars and save me from having to deal with self doubt and struggle for the rest of my life.

But I had to train myself to view things differently. My first role must be one that makes me learn and grow, and set me up for future success no matter what happened. It needed to pay fair market rates, but I was happy to take a slightly lower salary if the team was fantastic and the growth/learning was solid. It did not need to be my dream job.

I was very explicit in the tradeoffs I’d make:

• Team matters more than brand

• Team matters more than money

• Brand matters more than money (as it would set me up for future opportunities)

• Money matters more than stock (this was for my first dev role, as this would make my continued learning plan sustainable, even though stock may give me more financial upside)

• But, learning mattered more than brand or money – as learning more would save me time which is better than saving me money

• I would not trade off between team and learning. I needed both (but I was more likely to get reliable signals on the team than I would on the actual learning/growth I’d get on the job)

“Nailing it” or being comfortable was not a priority. My priority was to successfully change careers.

Accepting a rubbish coding job (and there are plenty of them…) would not be a “successful” career change for me. But equally I didn’t have to get into big tech (ever) for my career change to be “successful”. This was very personal – success to me meant loving the work I do and learning a lot doing it. Period.

How I Made a Customized Plan

After analyzing my advantages and "convertible" disadvantages, the next thing I needed to develop was a customized plan. I needed one that was tailored to me, that I could believe in.

I needed a plan that took into account my specific context, which includes my temperament, experience, beliefs, values, goals and skills.

Note that I’ve still not talked about the technical interviews, the algorithms and data structures, and so on. When developing my plan, I had to focus on all the many pieces that had nothing to do with my coding skills or technical capability.

It would also need to account for my psychological “runway” – how much time was I prepared to invest in this career change, before I’d give up, lose hope, or change my mind? I could not answer that without understanding how long it was going to take me to learn the minimum required skills.

To understand that, I needed to research and analyze what the minimum set of engineering skills that the market would value were.

And to understand that, I needed to analyze the dozens of engineering domains in the market, and which ones would suit my temperament, interest/passion and advantages. And from that analysis I’d need to pick the domains that I would focus on and exclude all others.

I'd have to find the overlap between my interests, my ability and what the market valued.

Again, my experience on the hiring side of the market gave me some (small but important) advantages. I knew that pure technical skill would not be enough – that’s just the starting point. the “invitation to the dance”.

I also knew that good teams don’t just hire for raw technical skill, they hire for essential non-technical attributes as well. What those traits are depend on the technical domain, the team culture, the current composition of the team, and so on.

Yes, you're right. A custom plan is extremely multi-dimensional, and getting things right is only moderately helpful, whereas getting things wrong can result in a giant loss of direction and waste of time.

Since I was almost halfway through my career, I was determined not to repeat past mistakes. I was going to be:

• Highly specific in my goals.

• Highly intentional in my choices and actions.

• Focused on what I wanted, paying no attention to the things I did not want.

• Willing to change myself, my habits and negative beliefs, so that I could change the world around me.

• Ready to focus on building a rewarding and fulfilling career rather than just “getting the next job”.

• Ready to focus on delivering value for my future team rather than a “what’s in it for me” mindset.

• Willing to play the long game – think in 5-10-25 year horizons rather than the next few weeks.

I must confess, doing these things consistently was much harder than I anticipated. I slipped up a lot, especially on the first three. But since I had my custom plan written down, I let that be my guide and the sole source of truth for what I needed to do.

My plan required me to focus on fundamental programming skills, and then narrow it down to the segment that I felt matched my long-term goals and skills. For me, this was web development. This meant completely and ruthlessly avoiding all the “shiny new things” and doing things like Python or Java.

And tutorials and endless videos were not going to make me beat the competition. I calculated that the minimum set of skills I’d need to develop for my city would require 900-1100 hours of focused coding, practicing the right things in the right sequence.

Preparing the plan took several weeks. I kept refining and strengthening it and didn’t rush it artificially. I am very inspired by Abraham Lincoln (another lawyer who changed careers!) and he once said “Give me six hours to chop down a tree and I will spend the first four sharpening the axe”.

I was so tempted to dive right into my plan and get “busy” but I’d learned that being busy was so not the same as being effective. Once the plan felt as complete as it could be with the information I had at my disposal, I turned to executing on that plan, with total focus.

This meant a lot of sacrifice, and many, many days of self doubt, battling the temptation to switch, and learning to manage my energy. I developed some amazing habits during this time, but they were only obvious to me in hindsight. During those 6 months of work, I was constantly assailed by uncertainty, fear and occasional loss of hope.

Later on, I adapted this planning process to create a plan for Big Tech and especially for Google. That plan took another 500-600 hours of intentional study that was completely different from my plan to become a developer. More on that later.

Early Results, and then…Google SWE

Another lesson I’d learned from 4 years of trial, error, and failure was that I was very likely to change plans midway, switch resources, courses or focus.

This is a much more serious problem than we realize because every time we switch focus or plans we throw out the hard work we’ve done, go back to square 1 and…start…all…over…again.

Imagine if you were driving from A to B and kept taking U-turns and going back and restarting. You’d never get anywhere.

But I’d made myself a promise (it’s easier to keep a single promise than to keep a bunch of them!): I was going to complete my plan and then decide whether I would keep going. This time I wasn’t going to stop until I completed my plan.

I didn’t have to like doing it. I just had to like the possibilities that lay at the end of doing it.

My plan had a specific time when I would start interviewing even if I didn’t feel ready for interviews. But to get to that stage I had to get good at generating interview opportunities.

Again, my past experience in other careers helped me. I applied all my learnings over 18 years and secured 4 interviews within a few weeks, and got all 4 offers even though there were plenty of candidates with more experience, skill, and qualifications than I had.

It wasn’t because I was better at coding. I don’t see how that could be, given that I’d only been in the game for a few months.

I believe I got all 4 offers because during the interview process I demonstrated that I was a better candidate for the hiring manager. This approach was critical in how I presented myself.

Getting the offers is great, but I had an unexpected problem. Since my plan required me to be highly intentional about the kind of work I’d pursue, all 4 roles I’d applied for were the ones I really believed would be a fantastic start to my new career. How was I going to choose?

Yes it’s a great problem to have, but that doesn’t make the decision easy!

To resolve this problem intelligently, I learned to ask myself a very important question:

Do I know this or do I simply think this?

Very often we make decisions based on assumptions and beliefs that are completely untested, and we mistake our opinions or fantasies for reality. What we actually know is way less than what we believe without truly knowing.

Being intentional required me to focus on what I know rather than what I wished, or merely thought. I had to either find evidence to back my thoughts, or disregard thoughts for what I knew.

That framework developed my analytical powers and helped me choose the right first role in early 2019. I turned 39 around that time.

Till today I continue to use this know vs think framework in my personal decision making as well as in my engineering decision making. I find it to be an excellent framework for analyzing tradeoffs in complex decisions.

Looking back, I learned a TON about sticking to my plan, revisiting my goals, self-awareness and practicing being intentional.

A few months into my new role, I noticed that a lot of lawyers were starting to reach out and ask me how I did this. Curiously, many of them were people who insisted I was making a huge mistake and that wanting to learn to code at this stage was immature and foolhardy.

Now they wanted to “learn to code”. And that made me think.

What else have others said is “not possible”? Do they know that or do they just think that?

And my goals hadn’t changed. For me learning, growth, and team were still more important than brand or money. But I was almost 40 and I also wanted to explore life in a way that I’d never had the courage to do in the first half of my career.

So I decided to set myself a stretch goal: I was going to find out what being a software engineer at Big Tech was like. I’d worked in huge companies before and I knew that it isn’t for everyone – that’s the reason I went into startup and smaller companies in the first place.

But wouldn’t I learn and grow SO much by being surrounded by some of the “best” people in their field, from engineering to product and sales? Did I know this? Or did I just think it?

I did the research and found that on average people were happy in Big Tech. But I also found that most people were not as intentional as I was. So I confined my research to people who were very intentional about their careers. And they (almost universally) said they grew a lot from Big Tech, even if they decided to leave. Leaving Big Tech was also intentional, in pursuit of their end goals.

So I decided to try for big tech (including 3 of the FAMGA companies) and several others, in Silicon Valley, New York, and Seattle. I was still based in Australia, so this was a massive challenge.

I re-designed my plan. Several of the steps were the same but the coding curriculum would have to be massively overhauled. I also needed to find out how US big tech recruitment is done, and be worthy of a referral.

About 7 months later, I started generating interviews. I worked very hard to prove myself worthy of referrals for those 7 months, and people offered to give me referrals based on my efforts and proven commitment.

I got referred to Meta (it was called Facebook then) but I didn't get the interview as my skills were not the right match. This was a massive learning for me as I thought I’d been careful to only apply for roles where my skills matched – and I was wrong.

That was when I realized that sometimes the position description is written in ways that mean one thing for the hiring company but means very different things outside that company. This is because different organizations use the same words to mean different things. Both the hiring side and the candidate side can be unaware of this!

All these learnings added up. Within 3 months I got offers from 2 big tech companies, and missed out on a third at the final interview because I just didn’t know how to write a filesystem from scratch (I didn’t understand much about the Linux world at all!).

And then I got an offer from Google.

Again, I was faced with a very difficult decision. Google is a cultural force that is very hard to be objective about. But I really wanted to stay true to my goals, my plan, and my intentions.

Trying to separate what I knew from what I thought was EXTREMELY hard when it came to Google. But I was absolutely sure about one thing: the team I’d interviewed with were amazing people.

And this is where I believe luck matters. No matter what people say about skills, brains, smarts and all that stuff, luck and "magic" have a role in life.

My interviewers from Google were friendly, kind, cheerful and highly focused engineers. They were not looking to prove I sucked. They wanted to help me prove I was good. They answered my questions with enthusiasm, and I felt like collaborators from the first minute.

Is this a Google thing? Maybe. But later, when training to be a technical interviewer at Google, I witnessed a very wide variety of interviewer/hiring manager styles and beliefs. I saw candidates with great skill losing their nerve, struggle to communicate their process, and so on. And I came to appreciate the role of chance in all this.

So yes – I was lucky that I had the kind of interviewers I did, and that on interview day I happened to know how to work through the code.

This is also where my ultra-focused preparation on type of work and relevant skills paid off. There are a very large number of engineering roles at Big Tech that I would never have been suited to (like the one at Meta). Even with my prior experience in other careers, I had no idea how HUGE the engineering world is, and how many flavors and types there are, and how hard it is to tell them apart.

By forcing myself to be highly intentional and not randomly and blindly applying for big tech engineering roles, I improved my chances in small but important ways. I dug deep into each role and researched them carefully by speaking to friends in the industry (again – my age and experience was an asset because I had built relationships over 15+ years never expecting that they’d be so useful later on!).

For each offer I got, I had researched the role deeply, and prepared for the technical interviews well. On interview day the stars were aligned, and things worked out. Though I don’t think I “nailed” my interviews, I did well enough to communicate that I was a suitable candidate for the team’s needs.

Which leads me to the question: How did I prepare for the Big Tech interviews?

How to Prepare for Big Tech Interviews

Answer: In two phases that took me over 500 hours to execute.

Phase 1: Learn the Realities and Competitive Landscape

If I wanted to tackle Big Tech, from another country, with less than a year of industry experience, and 15+ years in an unrelated career, with no Computer Science degree, I needed to have a very clear view of the realities, especially the competitive landscape.

This means there was room for informed hope, but no room for dreamy-eyed, pie-in-the-sky magical and wishful thinking.

Hard truths (see my initial YouTube Videos on this here). Hard realities. Hard work.

I had to fully internalize and appreciate the following:

• Coding is just the starting point. Not the ending point. Learning to code was the first step of many, one small piece of a much larger puzzle. In other words, it is necessary, but not sufficient to get a coding job (and especially at big tech).

• My biggest enemy would be my own mind. It would either let the negativity of others get me down, or it would turn against me and undermine my own confidence. I had to build the habits that would help me have a resilient mindset. I focused on recovering from setbacks rather than avoiding them.

• My competitors would likely not be career changers. Or if they were, they’d be from closely related fields like computer engineering, mechanical engineering, or electronics engineering. The vast majority would have technical qualifications, maybe even PhDs (this turned out to be true!), and several years of industry experience.

• As an outlier and a “wildcard”, the hardest part would be getting the interviews. Learning algorithms and data structures would be easier. And “cracking the coding interview” (whatever that means…) would be easier too. Why? Code is deterministic – identical code generally produces identical results. But life is not deterministic, and getting interviews is highly subjective. In the job market, identical actions do not produce identical results.

• I needed to shape myself into the kind of person seasoned engineers would want to work with

• I assumed most of my competitors would have at least 3 -5 years of experience. I couldn't catch up with them, let alone overtake them. Instead, I needed to outperform them on non-technical skills and compare favorably (if not outperform them) on the technical stuff.

• I had to communicate better than the others. If I didn’t know something, I’d need to say so and then communicate how I’d solve it if given the right time and opportunity. I also had to communicate to show interviewers that I understood their business needs and wasn’t just focusing on my selfish dreams.

• Which means I had to really work on understanding what the hiring team valued, was looking for, wanted, and needed.

• I could not control my competitors (their skill, their performance, how much they knew, and so on), or what my interviewer was thinking, wanting, what they valued, or whether they liked career changers or not. I could not control most things. I could only optimize my effort, my focus, my psychology, and how much learning I extract out of each experience, good or bad. I could only control my choices and actions. So focusing on anything outside that would be a waste of precious energy.

• I had to accept the role of luck. Jordan, Tendulkar, Federer – they’ve all had bad days. I would too. Or maybe I'd do great, but on the day someone else would do better. Or someone else would just be a better fit for what the team needed. No harm, no foul. I’ve made those hard decisions on the interviewing side countless times myself, so I know how these things work.

• If I was successful at more than 1 offer I would need to pre-think and pre-agree with myself about what signals and factors I would use to decide (I’d learned from my experience of choosing between my first 4 offers!).
  If you’re wondering how I knew how to do all this…I didn’t. Not all at once. What you’re reading is a summary in hindsight. But I had to work most of this out in “real time” based on “first principles thinking”. And I worked with my mentor to tighten them up as I went along. It took a lot of time and I was so impatient to “start coding”. But …I knew what advice Abraham Lincoln would give me…

Phase 2: How I Chose My Learning Resources

I know everyone thinks there is a secret “magic bullet” out there. Some blog, video, resource, tutorial, podcast, PDF cheatsheet…_something…_that will unlock the entire “secret” and make us instantly learn things.

Nope.

I’ll bang on about this till the day I die – information is a commodity.

Learning is hard, but it’s made much harder because there is too much free information.

We all fall into the trap of thinking there is some missing piece of information. There isn’t.

Why? Because no matter where you live, what language you speak, what color your eyes, skin, or hair are, what gender you identify with – all resources are going to teach you things that “work”. They’re all “the same” at a very fundamental level.

They have to be, because that’s how computers work.

If you and I write an identical function in JavaScript or Python or Java, we are going to get identical results. That’s how computers work – they’re deterministic algorithms.

But life (and interviewing) is most decidedly not deterministic. Identical effort, grades, skill, intelligence will not produce identical results.

Again, I had to teach myself to learn. I had to teach myself to shift my attention away from resources/blogs/websites/courses and put my attention on building solid mental models, identifying relevant skills, drilling down on concepts rather than code implementations, applying what I already knew in new ways, reasoning, problem solving, and communicating my reasoning while I reasoned.

Now you’re going to be surprised by the resources I used for my Google and other Big Tech interviews.

Yes, I used Leetcode, Algoexpert, InterviewCake and Jenny’s CS Lectures and perhaps a few others. But I didn’t complete a single one of them.

This wasn’t because I switched or lost focus. I was being intentional. I realized that they all teach the same thing, but with slightly different styles and content. So I used these resources to learn concepts and mixed and matched all these resources based on my analyses of interview patterns.

My reasoning was simple. Having been on the hiring side, I know that every year the quality of candidates (at good companies) improves. I personally think that focusing on the company is a huge mistake – we should focus on the team, people and kind of work.

But the world works a certain way, and because of that, everyone rushes to the big companies. This increases competition which makes it harder for hiring managers to assess candidates.

The only way for hiring managers to deal with this is to raise the bar, making it harder for candidates. The overall number of candidates keeps increasing, but the “pool” of candidates that get invited to the interview stays within a narrow range – usually 2 -10 people. Regardless of how many hundreds apply that’s about the number that will even get a chance to interview.

Therefore, the number of candidates that don’t hear back or meet with rejection increases, especially in bull markets.

If the competition is increasing and the resources on the internet are also increasing, but the shortlisted number stays more or less constant, then “learning more” cannot be the solution. Everyone is “learning more”, so relative to the competition there is no change.

I also realized that Big Tech would have lists of interview questions (this is “efficient” as interviewing is very time consuming, and so it makes sense to save time by having a question bank that interviewers could use). Naturally, they would not use these questions if they were “leaked” – that would defeat the interview process.

So, logically, hiring managers will not ask questions that are available on Leetcode or Algoexpert or other sites. This produces a kind of “arms race” – the more questions are made publicly available, the more questions in the question bank are changed. That results in more innovation and variance in questions and hiring strategies.

This left me only one choice. I had to learn to solve problems using mental models and by classifying them. Chances are I was never going to be asked to sort a Linked List or to implement Dijkstra’s shortest path algorithm. Instead, I would need to know how to apply these sorts of algorithms to “real world”, practical problems.

Often real world problems don’t look, sound, or smell like the practice questions we study. Practice questions and competitive coding questions tend to be “neatly” packaged up with clear constraints.

But as an interviewer, I wanted to know how the candidate thinks, reasons, analyses, interprets information, and collaborates. Solving the problem is a bonus. Often they have the right solution but run out of time – but ask great questions and clearly know how to tackle the problem. These candidates can still get the offer.

Later, as an engineer at Google, I could always tell if someone knew how to solve something even if they were unable to solve it in time. Equally, it’s immediately obvious when a candidate does not know how to solve something (and that's OK – we are all learning).

By adopting my approach of understanding problem types and solutions rather than specific code implementation, I could focus on learning to reason rather than learning to write specific algorithms.

This approach meant that I completed less than 40% of Algoexpert (and back then it had half the questions it has now). I also did maybe 50-60 questions from Leetcode and most of them weren’t the “hard” ones.

I figured that “hard” questions would probably show up in 45 minute interviews about 20% of the time which means 80% of the time they’d be easy or medium questions. So it made sense to optimize for the 80% given I was still relatively new to engineering and the hard problems would get in the way of understanding easy and medium ones.

I used these resources to recognise patterns rather than just “complete” and get a certification. That’s why I didn’t complete any of them. And no, I didn’t use “Cracking the coding interview” either.

Along the way I also started a systematic process of understanding system design questions. I documented system design preparation in a long form blog on the essential concepts for system design interview questions.

I also decided to focus on one language: JavaScript. It wasn’t the best for interviewing (seasoned engineers discourage it on Quora and elsewhere) but I didn’t see how it mattered. The purpose of the interview was not to test my choice of languages – it was to test my ability to think abstractly and solve complex computer science-y problems.

The language is just a tool (another core belief I hold). In fact, using an untyped language like JS would give me opportunities to talk about its limitations or strengths, which is an opportunity to demonstrate that I understand the tradeoffs in language choices. That way, I could showcase broader knowledge and insight without actually having to implement it all in code.

But a lot of the resources I learned from used Java or C++. These languages are the dominant languages at Google. So being forced to read these languages and understand the principles forced me to not focus too much on “spitting out the code” and more on reasoning through the code so that I could write it.

That was my entire plan. Practice, Pattern Recognition, Mental Models/First Principle Thinking, System Design, doing fewer things really well, and focusing on getting interviews rather than just learning more code.

How to Stand Out During Interviews

As I mentioned, we all have advantages and disadvantages. And we all think our disadvantages are special and huge and our advantages are common, unremarkable, and probably not of much use.

This is not true. Logically, if we all think our disadvantages are severe, then we should all succumb to them. Yet some people overcome them. Only to find that others had it even worse and overcame those.

It’s way better to focus on what we can do well. For me, I truly believed that I could add a lot of value to the team. I don’t care about being the smartest or the best. But I care about being an outstanding learner, and maintaining my growth mindset at all costs.

And so I tried to use this to stand out as best I could. I learned to ask really good questions of recruiters, interviewers, and hiring managers.

But there was a deeper reason for this. Asking good questions was my way of interviewing the company. Like I said, I didn’t want to repeat the mistakes of the first half of my career. So asking really good questions was important for me to assess whether the company was a fit for me and not just the other way around.

Since I had decided that I was going to value the team and the learning over all else, I never asked about the compensation until the recruiter raised it. It was going to be lower than what I earned as a lawyer anyway!

Instead I focused very hard on learning about the team, its dynamics, its group beliefs and values, how the manager solved problems (especially people problems), what the team was interested in, what the company division was interested in, how its balance sheet was doing, what its strategy was, what its resource allocation and budgeting looked like, and so on.

All these things were things I'd learned in other industries, as an individual contributor, as a manager, executive, founder and so on.

And all of these things also showed that I was being highly intentional. I was genuinely interested in the team, and the company, its product and its future. This wasn’t just another job I was applying for. This was active and personal…not passive and opportunistic.

And I believe that helped me stand out. Maybe not for all the roles I interviewed for, but for many of the offers I got.

When I was on the hiring side, I’d always prefer candidates who were genuinely interested in the role, the people, the product and the company. Those that showed up just “to get a job” didn’t have the kind of energy and drive we wanted.

Interview Planning and Strategy

The last aspect of my roadmap required me to deeply understand the different types of coding interview processes.

This included technical and non-technical interviews, the format of interviews, the way companies organize them, run them, plan them, staff them, evaluate them, and weigh them. But it also required me to understand my strengths and weaknesses.

When going for Big Tech in the US I was aiming for 2-3 interviews per month – a huge goal given that I was not even in the US and was in a timezone that was 17 hours ahead of the west coast.

I had to plan and structure interviews at weird hours so I could accommodate my day job as a developer and also my study time. Some interviews took 6 hours, some took 10 or more. Some were “pair programming for a day” type interviews.

All this took a ton of planning, and mental training. I had to be careful to get the right sleep, the right exercise, maintain my mindset and confidence, deliver on my day job, be there for my family, study and maintain focus on my goals.

For this, I had to be honest with myself at what I was good at. For example, I am not a morning person. But I can endure late nights. So I structured interviews, work, sleep, or even exercise accordingly.

There were some interviews that were scheduled at 2am or after, and I wouldn’t sleep before (as I really am not good at waking up on time!). So I’d do a full workout at 1am to get my energy and focus up, then interview, then sleep till 10 am, then go to work and manage my schedule accordingly.

I would also be careful to plan interviews so that I wasn’t doing two of them back to back unless they were very similar and time bound. For example, doing a take-home test and doing a timed test in the same week require different planning from doing a take-home and a live-coding interview – all while managing work and family.

To schedule the interviews appropriately I’d work closely with the recruiter and be very transparent with them. This had two advantages: I gained credibility and trust with the recruiter for being collaborative and communicative, and they also got to see that I had other opportunities going, which increased the value of my candidacy. Competition is a good thing.

Concluding Thoughts

I am sure many of you were expecting this article to give “insider” tips and a specific set of languages, and DSA questions to learn. I believe I’ve given you something much better. Rather than giving you fish, I am showing you how to fish.

Apart from the ethics of it, insider tips are of limited value, especially in Big Tech. In huge companies things can be vastly different from team to team and city to city. You need to understand the principles of recruitment and career development, rather than just the specific languages and algorithms. Assuming that all interviews are the same is a big mistake.

And as for our obsession with data structures and algorithms…managing your career is the ultimate algorithm. Your mind is the ultimate data structure. Learn how to work with both and you’ll always do well, despite the occasional failures. Powerful ideas aren’t grandiose – they’re elegantly minimal.

If you have read this article you will have noticed some of the things I linked to include multiple ways to reach me. You can also get invited to my webinars, mini-courses and newsletters if you want to go beyond just “learning to code” and learn how to build a career that is right for you.

Perhaps the most important message I can leave you with is that it is a mistake to obsess about big tech. Yes, they’re great to be part of, but if we believe they’re the only thing that is right for us we will miss out on all the other amazing opportunities.

Big Tech has glamor because of cultural trends these days. Sure, it’s nice to work for a great organization, but plenty of great organizations are not well known. Plus what is “great” for one person is pain for another.

Your number one priority is to be happy, fulfilled, and live the life that you want. This is not derived from a company. This comes from the people you spend time with (especially colleagues) and the kind of work you do. Big Tech companies have their share of bad managers, teammates, and work, just like any other company.

If you build skill, stack a great plan on top of the right mindset, and train yourself to set the right goals, you can achieve much more than you dreamed of – with or without Big Tech.

Post Script

If you would like to learn more about my journey from lawyer to software engineer, check out episode 53 of the freeCodeCamp podcast and also Episode 207 of "Lessons from a Quitter". These provide the blueprint for my career change.

If you are interested in teaching yourself to code, changing careers and becoming a professional coder, or becoming your own technical co-founder, please reach out here. You can also check out my free webinar on Career Change to Code if that is what you're dreaming of.

A popular Chinese proverb says: “The best time to plant a tree was 20 years ago. The second best time is now.”

The same applies to acquiring new tech skills. No matter if you’re a junior developer or a seasoned software engineer, there is always something you can work on and improve.

But how do you choose this “something” that might help you advance your career in the IT industry? With plenty of online courses and new IT skill sets demanded by employers, you can easily get dizzy.

Don't worry – DevSkiller is coming to the rescue with data-backed insights based on the findings from the 2022 edition of our Top IT Skills Report. We’ve arrived at these insights by analyzing thousands of coding tests sent to candidates from 191 countries through our TalentScore tech screening solution by companies recruiting for IT-related positions.

Based on our proprietary data, we’ve compiled a set of useful tips on what to learn. This is based on what job you hope to get in the future.

Choose wisely and remember that the IT industry is waiting not only for seasoned developers but also for greenhorns. As the data from the DevSkiller platform show, around 40% of technical test invitations are for junior developer roles.

If you want to grow together with the market

You've likely heard that “data is the new oil”. But only a handful of the big tech companies have figured out how to extract this "oil" and process it in order to be able to fuel their businesses.

This has brought about the accelerating demand on the job market for data-related roles like data scientists, data analysts, or data engineers.

If the thought of organizing random numbers in a set of structured tables or charts positively tickles your mind, a data-related role might be the right fit for you.

Just keep in mind that the market of data-related positions is not as structured as the dashboards you might be expected to create. As the market develops and gets more mature, you might be expected to learn new skills which we can’t even imagine right now.

Having said that, the reward for this flexibility and eagerness to learn may be huge.

According to the insights from the latest edition of the DevSkiller report, data science tops the ranking of in-demand IT skills of the future. The popularity of recruitment tasks from this area grew in 2021 by 295% on a yearly basis.

If you want to enter the IT job market ASAP

Another big thing as far as in-demand IT skills of the future go is Python. But this demand isn't the only advantage when it comes to your choice of programming language to learn.

The data we compiled for our Top IT Skills Report show that Python – with a 54% ratio of test invites for junior roles – was the most sought-after technology among developers beginning their careers in the IT industry.

Given the fact that Python is relatively easy to learn in comparison to other programming languages, it might be a perfect choice to speed up your entrance to the IT job market. Just remember that the fastest way is not always the most satisfying one.

If you want to work in a big company

Trying to find your place on the job market may be compared to driving a car. Some people like to drive fast and reach their destination quickly, but others prefer to move forward slowly but securely.

If you’re in the latter group, you should consider learning one of the most mature and popular programming languages like Java or SQL. This can help you land a job in one of the large corporations. This may be not as exciting as working for a cool ever-pivoting startup, but it'll provide you with a certain level of stability and security you might find appealing.

As the data compiled from the DevSkiller TalentScore show us, both Java and SQL are in the top of the ranking of IT skills sought after by hiring companies. Each of those languages was seen in 19% of coding test invites sent by tech recruiters via our platform.

It's worth mentioning that there seems to be a shortage of those skills on the market. From the insights in our report, Java and SQL developers wait the longest to complete their coding tests in comparison to specialists with other tech skills.

One of the reasons behind this trend is that the recruitment pool is shallow and companies are competing for the same limited set of candidates.

In 2021, the average time to submit a Java coding test by a recruited candidate amounted to 4 days and 11 hours while in the case of SQL it was 3 days and 6 hours. The industry average for all languages in 2021 was 2 days and 16 hours.

If you want to unleash your creativity

Do you consider yourself to be a creative person who cares not only about how things work but also how they look? If that’s the case, you should consider pursuing a career as a front-end developer.

Maybe you won’t enjoy as much artistic freedom as a graphic designer, but rest assured that if you supplement your bias towards aesthetics with the practical coding skills, you’ll find a job you enjoy.

If that sounds appealing to you, remember that the front-end development is not just about HTML or any single language anymore. You’ll probably need to be able to surf across at least a couple of technologies during any given project.

Through the findings from our report, the 5 most commonly paired IT skills tested by recruiting companies nowadays are JavaScript and HTML, JavaScript and TypeScript, JavaScript and CSS, JavaScript and Angular, and CSS and HTML.

If you don’t want to code (or only a little bit)

Given the rising popularity of low-code/no-code platforms and tools, you no longer have to become a full blown software engineer in order to land a job in the IT.

Sure, in this industry, you will always be expected to possess a certain level of computer literacy and understand the key concepts of software development. But you no longer have to actually code in order to be an attractive candidate for employers.

The rising popularity of low-code/no-code is reflected in the dynamic growth of the number of tests checking the skills related to Salesforce available on DevSkiller TalentScore. Since 2020, it has grown by a whooping 1300% in response to the needs of our customers, that is hiring companies.

And keep in mind that Salesforce is just one of plenty low-code/no-code platforms used by your potential employers.

If you want to help others enter the IT industry

Last but not least, maybe after careful consideration of your skills and preferences, you’ll decide that you’re more of a people person, and solving technical problems on a daily basis is not for you. Or you might be burned out in your current role and would like to try something new.

Don’t worry, the IT industry is not only about 0s and 1s and there are a number of options available for you to land your dream job that don’t require learning coding skills.

One of them is related to helping others find a well-suited job – that is, becoming a tech recruiter.

If this sounds like a good fit, you can start developing in this direction by acquiring the industry-recognized DevSkiller Tech Recruitment Certification. Even though it may not look very difficult at first glance, our data show that only 61% of users pass our certification exam in the first attempt.

The digital skills gap is working to your advantage

As software has been eating the world for quite some time now, the IT industry has become one of the main drivers of job opportunity growth in the global economy.

In the European Union alone the gap between the supply and demand of IT specialist has been estimated at a minimum of 500,000 vacancies. And this doesn't include all of the IT-related roles like tech recruiters and other positions that require at least some level of digital skills.

So if you're hesitant whether your upskilling or reskilling efforts will pay you off, the answer is: yes. The probability that you'll get a raise or move to a better paid job is close to 100%. The worst-case scenario? You'll simply find joy in learning something new.

Coding is fun, after all.

It is, after all, hard to know whether or not you’ll like something that you’ve never done.

If you choose a career path based on the wrong reasons, you might end up unhappy in your job which can negatively affect your quality of life. You also might not be making as much money as you wanted and end up credentialed for a job which you're simply not good at.

Fortunately, there are some methods you can use to help you decide what a good career path is for you. Picking the right path can help you to look like this:

While those who get stuck in the wrong career wind up looking like this:

In this article, I’m going to talk about whether a career path as a developer might be the right one for you. (Hint: if you want to do it, you can. And here I'll share how.)

I’m writing this article with substantial input from Marc Gray, who is the founder of Odyssey College Prep.

Among other things, Marc has extensive experience in administering aptitude tests and assisting young people with choosing career paths. He provided a lot of great insight for this article which goes beyond your typical “pick a career” type writings.

The goal of this article is to give you a framework which can help you decide whether or not they want to become a software developer. My goal is also to help you pick an area of focus if you decide that development is for you.

Finally, I'll provide some general advice on how to avoid some of the big mistakes people tend to make in developer job interviews. If you’re like I am, and prefer written information to video format, then read on. Or, if you prefer watching your tutorials, Marc and I address these topics in this video:

I’m going to be diving into quite a few topics. To jump to a particular section, simply click “jump to section” in the table of contents below. So…shall we?

Table Of Contents

1. Is programming a good fit for you? (jump to section)

   1. Why it is important to enjoy your job. (jump to section)

   2. Will you like being a programmer? (jump to section)

   3. Do you have the ability to become a developer? (jump to section)

2. Current programmer job openings & salaries (jump to section)

3. How to find a job as a software developer. (jump to section)

   1. How to stand out in an interview. (jump to section)

   2. Common interviewing mistakes to avoid (jump to section)

Is programming a good fit for you?

(back to top)

The preliminary question in deciding whether you should become a programmer is whether or not you will be happy doing it.

While this may sound like a “duh” statement, I’ve come to appreciate how many people dive into a career path without ever considering whether it fits them as a human.

Choosing a career that is not a good fit for your personality is a good way to increase the odds that you go on to be miserable.

The following part of this article will address the importance of actually liking your job in general, how to tell if you might enjoy being a developer, and whether or not development is something you can actually be good at.

Let’s look at each of these in turn.

Individuals choosing a career path must understand the importance of liking their job

(back to top)

When deciding whether you want to become a developer, the first step is to determine whether it is a field that you will like and which will interest you.

Being genuinely interested in the field should take precedence over considerations of money or prestige. This is because, while it’s easy to say “of course people should like their job” and it seems obvious, the fact of the matter is that most people work in careers they don’t enjoy.

Hating your job stems from:

• not putting a lot of time or research into making career choices, and

• jumping into a career simply because an opportunity popped up and not due to thinking about whether the new field was actually a good fit.

This results in quite a few problems. These include a lack of success at work, higher levels of unhappiness when you're not at work, personal relationship problems, and more.

Let’s quickly look at why being at least interested in your job does matter and the impact of doing something you don’t enjoy.

Many will say that they “don’t let their job define them” or some similar rhetorical statement in an effort to claim that disliking their job isn't a “big deal.”

Whenever someone tries to tell me that being excited about their career choice isn’t important, I tend not to believe them.

Why do I say this? Well…here are a few reasons, off the top of my head. First, if your work isn’t “important to you” then why do you spend as much, if not more, time at work than you do with your family, sleeping, or engaging with your hobbies?

Given the amount of time you spend at work, it’s clearly a big priority in your life. If you think that what you do for a living doesn’t matter to your personal happiness, then you’re likely not being honest with yourself.

It’s also important to remember that you’re very unlikely to be successful in a career you choose if you’re not happy in the field.

According to Business Insider, people who are happy in their job are absent less often and they tend to earn higher salaries. The reasons behind this aren’t rocket science. If you're happy with what you do, and you're interested in the work, then you are willing to put more effort into it. This increased effort equates to greater success.

By contrast, if you see your daily tasks as drudgery, then you're going to do the bare minimum and do everything you can to get out of doing any extra work. Because of this, being unhappy with your career choice will, therefore, lead to you failing at work.

Liking your field also likely leads to a happier home life. The realistic chances that someone can be miserable in their workplace all day, and come home in a happy mood are essentially zero. This leads to problems with your significant other, children, and so on.

Hating your job can also lead to higher rates of alcoholism, substance abuse, and poor mental health. Add to this the fact that you’ll be more likely to struggle financially, and the importance of liking what you do should become clear.

Fortunately, as Marc stated while assisting with this article, “interests are like fuel.” If you can find a field which you find interesting and engaging, then you flip the whole paradigm. You become more likely to put in the extra effort, to excel, to make more money, and this has a positive spillover effect in your life.

This is not to say that you can pick a career that is nothing but fun with no stress. Such jobs don’t exist. There are plenty of things about my career as a front-end developer which I find annoying. The aspects which interest me and keep me engaged, however, far outweigh the downsides.

When deciding whether you should be a programmer or enter some other field related to software development, it is important to understand that the first step in your decision making is to decide whether you will even like the field.

How to decide if you will enjoy being a programmer or software developer

(back to top)

Are there areas in an industry field that your personality and interests align with? Answering that question is the key to determining whether you will enjoy being a programmer or software developer.

This is an important part of the career choice process which many people miss. Too often people choose a career path because of perceived high salaries, perceived social status, or simply because they think the job “looks cool.” They don’t stop to think about whether the job actually entails activities which they will genuinely enjoy.

Fortunately, there are ways to figure out whether being a developer, in general, is a good fit for you, and to determine which particular niche in the dev world might align with your interests. Let’s dive into this.

The first step in deciding whether development is for you is to take stock of your interests. In other words, list activities you find enjoyable.

By making a list of the activities you enjoy, you develop a starting point for choosing the right career.

You’ll then want to identify the professional equivalents of those interests.

For example, I greatly enjoy analytical problem solving and the process of putting things together. I also enjoy analyzing situations in finance, in which one input may impact a given output. It’s also easy for me to spend hours playing puzzle based games. This is why my niche of providing front-end development services to small businesses is greatly appealing to me.

Whatever it is that you find enjoyable, there is a good chance that it translates into some sort of professional equivalent. So, when picking a career, the first thing to do is to identify the types of activities which you enjoy.

The second step in deciding whether to become a programmer is to determine what these aforementioned “professional equivalents” of activities you enjoy actually are.

This allows you to enter freeCodeCamp, or some other curriculum, with an idea of where you are headed and what type of job you will eventually want to apply for.

When deciding which fields may fit your personality and interests, here are some things to consider:

If you are considering "front end" development:

Think of a “front end developer” as someone who works with the public facing part of a website or an application. They build/maintain the components which individuals interact with.

You may do well in this type of environment if you have a high “visual memory.” This means that you tend to have a strong memory for what things look like. You also tend to care quite a bit about visual appearances.

You might be well-suited for this work if you're able to consider how components interrelate to each other. For example, you would have an ability to consider how the placement of a button on a website impacts the likelihood of the button actually being clicked on by the end user.

While by no means an exhaustive list, these are just a few examples of traits typical in those best suited for front end work.

If you are considering “back end” work:

A “back end developer” is someone who develops the application which runs on the front end. So, for example, if you have built a website which helps someone find homes which are available for rent, the back end developer builds out the necessary databases, search functions, and so on.

You'll likely be best suited for this type of work if you have a desire to deal with concrete facts. To put it another way, if you often like to take inputs and create something useful out of it, back end work might be a great fit.

Another common trait among back end devs is that they tend to be able to remember numerical sequences and aren’t intimidated by large bodies of text.

There are many other tracks in software development other than the first two I just listed. Other options can include:

• Full-stack developer

• Information Systems Management

• Data analyst/data science

• Quality assurance

To get a better understanding of a field which may interest you, I suggest taking a look at the freeCodeCamp curriculum and researching the type of traits typical to someone working in a given field.

The big takeaway from this section of the article should be that you can look at your personal traits and find fields in software development which align with those traits.

Do you have the skills or abilities to become a programmer?

(back to top)

There is one big question which many people may have even after they’ve determined that a) they want a career which they will actually enjoy and b) they’ve decided that being a developer aligns with their personal interests.

Here it is:

Do you have the capacity to become a developer?

Many people don’t take the opportunity to get into development because they believe that they lack the skills or aptitude to be good at it.

The good news is that you can get into development with some hard work. To understand why this is, let’s look at the difference between aptitudes and skills. Once we understand this difference, we’ll find that anyone can do something in the software arena.

Think of “Aptitude” as someone’s “natural ability” to do something. “Skill,” by contrast, is the ability to do something which comes after practice and repetition.

While aptitudes can certainly give someone a head start at something, the person with a high aptitude will likely never be truly great at something if they don’t put in the practice.

What this means, at the end of the day, is that someone with a high aptitude for engineering or solving technical problems can possibly still be a decent developer without working overly hard at it.

But someone who works hard at developing the skill, however, will likely succeed even if they begin with a lower aptitude.

Now if you’re someone who has a high aptitude, and is willing to put in the work and develop the skill, then the sky's the limit.

The truth of the matter is that natural aptitude will get you to a certain point, but that point stalls out real fast. No matter how naturally inclined you are at learning languages, for example, if you've never spoken or heard French then you're not going to understand a word of it.

The ability to expand a learned skill, however, has a much higher ceiling. This means that if you want to become a programmer then you likely have the capacity to do so.

Here are a few tips I would offer if you're hoping to develop your programming skills:

Code every day

When you’re learning to code, then you are also learning to think of things in a different way. Not only are you learning programming languages, you’re learning how frameworks interact with each other and you’re thinking about problems in a way which is probably novel to you.

You might be surprised at how fast you pick things up if you work on it every day and allow your mindset to shift.

You’ll be equally shocked at how much harder things seem if you take an extra day off here and there. For the first several months of your journey in learning to code, try to work on it every day.

Pick a curriculum where you build projects

There are some online code education platforms which do not require you to actually build something or have you build something that is simple in nature.

Such platforms, for example, may show you how to create a hyperlink in HTML or change a font with CSS, but they don’t require you to actually build a website containing the hyperlink or the font.

By choosing a curriculum that requires you to put the skills you're working on to use, before declaring you done with the program, you will greatly improve your ability.

Don’t get stuck in constant tutorials

Many, many, many (many) people feel that they are “not ready” to look for a job and they just keep going through tutorials over and over again.

The cold and hard truth is that constantly completing tutorials is a drop in the bucket compared to the skill you will develop with a real-world employer.

Also, your employer will be well aware that you are a newbie. As soon as you feel you meet the requirements to apply for a job, then you are ready to get out there.

The key takeaway here is that you don’t have to be a “natural engineer” or a math prodigy to become a software developer/programmer. In fact, many who work in the field aren’t.

If you are willing to learn and put in the time then you have a good chance of success.

This, going back to the earlier part of this article, is why it is so important to pick a track that interests you: you are unlikely to want to put in the time for something that doesn’t truly interest you.

So, by picking a field that peaks your interest you put yourself in a position where you will be willing to build the necessary skills, even if you don’t have the most natural ability.

The bottom line is that you can become a programmer with time and hard work.

Career options for software developers

(back to top)

We’ve just discussed a few threshold questions to consider if you're thinking about becoming a programmer. These include the importance of liking your career choice and understanding that no job is worth it unless you'll be interested in the field.

We also talked about how to decide which fields of development you may find interesting and how you can develop the necessary skills to succeed in software development.

In this section of my article, I’m going to dive into the economics of a few possible software development tracks. This is important to the question of “should I become a programmer” for a simple reason – those entering a field need to support themselves.

In preparation for this article, I did some research on Indeed.com as to current openings, salaries, and so on. Here’s what was available in the United States as of April 7th, 2022:

Front End Development

• Total job openings: 41,000+

• Entry level openings: 5,700+

• Starting salaries over $60k: 2,900+

Back End Development

• Total job openings: 20,000+

• Entry level openings: 1,800+

• Starting salaries over $85k: 8,600

Other Possibilities (Average Salaries)

Source: Indeed (as of April 26, 2022)

• Full-stack developer: $109,000

• Information Systems Management: $84,810

• Data analyst/data science: $98,230

• Quality assurance: $88,550

If you feel like you may be interested in front-end development, based on the discussion above, then you should learn HTML, CSS, Javascript. I would also suggest becoming familiar with the various front-end libraries (like React, Angular, and Vue).

For those who are more interested in application/back-end development, then it is important to understand that, in today’s world, you will still be writing a fair amount of code – but you will also be spending an extreme amount of time working with various microservices to build a product out of existing tools.

There are also large numbers of openings for those with skills relating to data visualization, security, as well as the jobs listed under “other possibilities” above.

One key point I would stress here is that such jobs are often willing to hire someone even if they don’t strictly meet the experience requirements. If you put in a résumé, after all, the worst someone can do is say no.

How to find a job as a software developer

(back to top)

An important thing for anyone attempting to get a job as a programmer is to do well on the interview. As someone who has employed people in multiple businesses, I have to say that the mistakes people make on interviews truly baffle me. In this section of the article I’m going to look at how to properly interview for a coding job and mistakes which people should avoid.

How to do well at a coding interview

(back to top)

I understand that in this “how to do well” section, the points I’m going to make may sound like “duh” statements.

The truth of the matter, however, is that probably ninety percent of the percent of the people I’ve interviewed over the years don’t get all of these things down. So, with that said:

Show Up Prepared

Showing up prepared doesn’t just mean appearing for the interview. It’s important to actually do some research on the company as well as the individual who will be interviewing you.

This means that, before your interview, you should spend time doing research on the company. Find out what services they offer, who their target customer is, how long they’ve been in business, and so on.

Looking up the individual who is interviewing you will give you the opportunity to learn more about them. This includes their work history, role at the company, and more.

During interviews I tend to ask questions which let me know whether the interviewee had done their homework. If it shows that they haven’t, then I have to ask myself: “if they can’t even research a company for an interview, then how can I assume that they will be proactive in the researching of potential solutions?” A little preparation goes a long way.

Show how you will add value to the company

Researching the company, as explained above, puts you in a position to show how you will add value to the business. When you are asked questions about yourself then you can relate the answers in a way which shows how you will add such value.

For example, in my company we build websites and automation solutions for owner-run to medium-sized companies. If someone has done their research on our company, and I ask them why they applied, they can respond by explaining how excited they are about the idea of working with small business owners directly. They can also make their answer about how their interests align with the types of automation products we work on. This tells me, as an employer, that they are thinking about how they will add value to the business.

In other words, your answers to questions should relate back about how you will add value when serving the customers of the business.

Don’t be shy about needing to look things up when coding

In any coding interview, you’re going to need to answer some basic coding questions. I usually have an interviewee perform 5-6 simple tasks. I make sure, however, that at least some of them are things which the interviewee is unlikely to know off the top of their head.

What I’m looking for in the interview is for someone to not get frazzled and who will ask for one moment while they look up the solution (I only use questions which I know can be found through a quick Google search). It’s OK in an interview to ask to look things up.

Mistakes to avoid in coding interviews

(back to top)

Now it’s time to look at some common mistakes which people make during job interviews. And, yes, I have had individuals make these mistakes when interviewing with me.

Showing up at the last minute or, worse, late

If you want to send a clear message to the potential employer that a) you don’t care about the job or b) that you have no time management skills, show up at the last minute or even late.

I recently had someone who actually showed up late for a virtual interview (I didn’t think that was possible). If someone is about to start your interview, and it’s clear to them that you weren’t early, then you just decreased your chances significantly.

If you are interviewing in person, then show up early and wait. If you are interviewing virtually, then log on to the chat early and wait for the interviewer to enter.

Making the interview all about you or generic

Don’t make the mistake of assuming the interviewer wants to hear about you generically as a person.

First, when an interviewer asks you to tell them about yourself, then don’t start reciting your résumé (they can read your résumé) and don’t start simply talking about your personal interests. They don’t care.

Instead, you should be talking about how your interests align with those of the company (see above). This shows the interviewer that you are prepared to provide value to the company.

Also, when asked to tell a little bit about yourself, avoid generic answers about what a hard worker you are. Instead, again, answer the question in the context of how you will provide value.

Behave professionally (please!)

This might be the one that is the most annoying to an employer. You need to act like you are taking the opportunity seriously.

Here are two examples of people I’ve interviewed where the problems are obvious. The first individual who managed to immediately disqualify himself strolled in with his sunglasses on the top of his head and a frappuccino from Starbucks in his hand.

The second was a virtual interview. When I started the interview by saying “hi [name of person]”, he responded by saying “Hey brother!” Do I really need to say why neither of these individuals were considered?

Show up for the interview dressed appropriately. This is true whether the interview is in person or virtual. Also, if it is a virtual interview, make sure you’re in a quiet place with an appropriate background. Refer to the interviewee as Mr. [Name], or Mrs. [Name], until they tell you to call them by their first name (note: if you annoy them enough they might not say this).

When you introduce yourself, make sure you thank them for taking the time to interview you and thank them again upon completion.

Don’t make inappropriate jokes or comments during the interview either. While I think these things are “common sense,” I’ve come to the conclusion that such “sense” is not actually “common.”

Conclusion

If you are wondering whether you should become a programmer, then the first step is determining whether it is a profession you would be interested in and would otherwise enjoy.

Next it is important to determine which type of developer you would like to be. Because you must support yourself, it is also important to understand career possibilities within the field.

Finally, handling an interview correctly will put you ahead of more people than you may think.

Hopefully you found this article helpful when you're making your career decision. Happy coding!

About Me

I am a front-end developer and the founder of Modern Website Design. I enjoy writing on business/employment related issues and believe strongly that the world’s problems are solved through entrepreneurship. To keep up with my babbling, follow me on Twitter.

In this article, I will talk about the typical day of a junior developer and what to expect on the job.

The Onboarding Process

When you get started with a new company, you will go through what is considered the onboarding process. This is a term that refers to the process of getting introduced to the company.

You will first go through a period of filling out important paperwork for the company. This will include stuff like payroll information needed for the HR department.

You will also start to gain access to some of the company's project codebase, staff calendar, meetings, and staff chat room.

Before you get started with your first day, you will probably be receiving tons of emails. It is really important that you get your company email setup and check it periodically throughout the day to setup everything you need to.

In the first few days on the job, you will have a few meetings to get you introduced to your manager, your team, as well as an overview of the company and its expectations.

It is completely normal to be overwhelmed with the sheer volume of new information. Try to take notes during the meetings and ask questions.

Tips for Getting Set Up with the Project

You might be overwhelmed when you try to setup the codebase for the first time or you might not understand all of the code in it. It is important to remember that your company is not expecting to learn everything about the codebase during your first week.

They understand that it will take some time before you get used to where everything is and how things works. Take your time studying the codebase and ask questions about things you don't understand.

Also, if you have trouble getting set up with the project, make sure to reach out to a team member. If the setup process is not documented that well, this could be a good opportunity for you to update the documentation so future developers will have a smoother onboarding process.

What are Tickets and Project Boards?

Project boards are used so teams know the current status of a project and understand what work still needs to be completed. These boards will have what are called tickets which represent tasks in various stages of completion for the project.

This is an example of what a project board might look like. Here is an example from one of my personal projects.

Developers will assign themselves to a ticket listed on the board and read through the requirements.

Some of these tickets might be small bug fixes for an existing project. Or you might be asked to build out a new page or component for the site.

When you are finished working on the ticket, you will submit a PR (pull request) and ask for a code review. Once your code has been reviewed and approved, then it will be pushed into production.

If you have any clarifying questions about the ticket's requirements, just reach out to your project manager.

What are Code Reviews?

The code review process involves another developer looking over your code and submitting their comments for improvement. These code reviews will help catch small bugs, code inconsistencies, and improve code quality.

It is important not to take code reviews personally. Remember that your team is there to help you and offer constructive criticism.

As a junior developer on your first job, you might not be used to having other people looking at your code. You also might not be aware of the current best practices in building large scale production level apps.

Code reviews can be a great learning opportunity for you and help you become a more mature developer.

What is the Role of a Manager?

Engineering managers hold several responsibilities, including being involved with the planning, and coordination of projects as well as supervising engineering teams.

These are individuals that have years of software experience and have to balance project management with people management.

Here are are some core day to day activities for engineering managers:

• Being involved with daily standup meetings
• Meetings with other managers, clients, and stakeholders
• One-on-one meetings with engineers
• Might participate in some code reviews or coding

I believe that a good manager is someone who can effectively communicate with the team and is a good problem solver when issues arise. They are also responsible for providing feedback to their engineers on what they are doing well and areas of improvement.

What are Standup Meetings?

Standup meetings are when the entire team meets up and each member shares the work they did, the work that still needs to be done, and anything that is blocking them from moving forward.

It is really important that if you are stuck with something or blocked that you bring it up with the team. As a new member of the team, especially as a junior, make sure to ask for help if you can't proceed with the project.

Remember that your team is there to help you and you shouldn't feel ashamed to ask for help.

What to Expect from the Company's Group Chat

A lot of companies will have a designated chat server or group where teammates can connect with each other throughout the day. My company uses Slack and has a variety of channels for specific projects, software topics, and miscellaneous non-tech conversations.

I believe a healthy company culture will not expect you to be available for every single second on the group chat. It is ok if someone messages you and you don't respond back right away because you were busy with something else.

But it's typically not alright to go completely silent throughout the whole day where no one can get a hold of you. If you are working virtually as a junior developer, communication is really important.

It is up to you on how involved you want to be in the company chat. But I would suggest checking in once in a while throughout the day just so you remain up to date on what is going on with your team and the project.

Conclusion

Your first few weeks working as a junior can be overwhelming. It is important to remember that your company understands that you are still new to the industry and have a lot to learn.

Just try to take it one day at a time and learn as much as you can. Ask questions on what you don't understand and ask for help if you are stuck on an issue.

Make sure to try solving the issue on your own first by reading documentation and other articles before reaching out for help. Also do the best you can communicating exactly what the issue is with a lot of detail so others can best help you.

Try to learn from your co-workers because they have different levels of expertise and experience.

And most importantly, be easy on yourself. It will take awhile before you will get comfortable with the codebase and the workflow requirements.

I hope this article helped you understand what to expect working as a junior developer! Best of luck on your developer journey.

Here is the story of how I learned how to code using freeCodeCamp and the lessons I learned along the way.

My life pre-pandemic

The Southeast Symphony

In my previous career, I led a very active life of teaching, composing, and performing in recording sessions, operas, musicals, orchestras, and wind ensembles all throughout Southern California.

My main instrument was the oboe, which I studied in college at the Eastman School of Music (Bachelor's degree) and the University of Michigan (Masters degree). Here is clip of me performing a concerto with the Los Angeles Winds.

I also had an entrepreneurial spirit and ran my own sheet music company called JDW Sheet Music for 8 years. I was very happy with the career I had built, but March of 2020 changed everything for me.

At first, I thought the pandemic was only going to last for a few months and I would be able to return to my music career. But to my surprise, the pandemic opened me up to the world of software development.

The project that inspired me to learn how to code

Black Excellence Music Project

In June of 2020, racial tensions in the United States were at an all time high because of the murder of George Floyd. There were sweeping protests across the states and discussions of lack of diversity in many industries including in the classical world.

Many friends and colleagues of mine were reaching out about resources to learn more about black classical and jazz artists from the past and present. I quickly realized there was no central website where people could find all of this information.

That is when the idea of the Black Excellence Music Project was born. I wanted to create a site that was educational and filled with hundreds of artist profiles and games.

So I decided to learn how to code – but had no idea where to start.

Hello freeCodeCamp

freeCodeCamp homepage

In the beginning of my coding journey, I bounced around to different online resources to start learning HTML and CSS. While I enjoyed learning with these classes, I really wanted to find a resource that I could stick with and follow a particular path.

In July of 2020, I discovered freeCodeCamp and decided to give the curriculum a try. I really enjoyed the interactive learning environment and learned a lot by building the certification projects.

I spent the next few months working my way through the Responsive Web Design course and JavaScript Algorithms and Data Structures course.

While I was learning, I wanted to join a community and connect with other self taught developers like myself. So I decided to join the freeCodeCamp forum and hopefully learn from other developers.

Little did I know, my participation on the forum was going to lead to new career opportunities.

How I met Quincy Larson

my freeCodeCamp profile

When I first joined the freeCodeCamp forum, I never planned to be that active. But the energy was so welcoming and informative that I found myself answering a lot of questions and offering words of encouragement.

After a month of being active on the forum, I received a message from the man himself, Quincy Larson.

We set up a google meet and ended up talking about our previous careers prior to tech. He then suggested I become a writer for the freeCodeCamp News publication.

I was shocked but excited for the opportunity, so I decided to fill out the application and was accepted as a volunteer author.

I spent a few months writing topics I was familiar with like HTML, CSS and JavaScript.

And just when I didn't think things could get any better, another opportunity came knocking at the door.

Looking for a Junior Developer

Around the same time Quincy reached out to me in October 2020, I received an email from a guy looking for a junior developer to do some small tasks for his software company.

At first, I wasn't sure if that was legit or some sort of scam. So I decided to do some research and found out this was legit.

The meeting ended up going well and the type of work I would be doing sounded interesting. This wasn't a full time job, but it was enough to gain me some experience while still learning how to code.

Before I said yes to the job, I did ask him one question, "Why did you pick me?"

At this point, I knew a little bit of HTML, CSS, Vanilla JavaScript and had just started learning React. But there were plenty of more qualified junior developers that knew more than me, so why was I chosen?

He explained that he found me on the forum and liked the answers I was providing other users. He understood that I was very early on in my career but figured I could learn well and pick things up quickly.

2020 had ended on a strong note and I was ready for the challenges ahead with this new part time developer job.

My first experience of imposter syndrome

When I got started with this new part time job, there were plenty of times where I felt out of my element. The first moment was probably when I had to setup the project on my local machine.

Up until this point, I had never worked with a real world application. I had only built small projects for classes or deployed personal projects using GitHub Pages.

But I had never dealt with setting up a project that included a database and backend system. My boss was walking me through the setup and giving me list of commands to run in the terminal, but I barely understood any of it.

In that moment, I started to doubt if I was really cut out for this and maybe it was a mistake to hire me. But he reassured that I was doing fine and it was completely normal to struggle with this stuff.

Over the course of 2021, there were plenty of moments where I felt like maybe I wasn't able to do the task assigned to me. But I keep trying to reassure myself that this was a learning opportunity and I was meant to grow from it.

That first gig was very valuable, because I started to learn how to work in a real codebase and was learning how to refine my code from a senior developer. I now consider him a mentor and good friend.

2021 was looking like a promising year in tech and during the summer, Quincy reached out to me again and offered me a position to write as part of the freeCodeCamp team.

With my confidence at an all time high, I decided to pursue a new career opportunity in late 2021.

Hello This Dot Labs

This Dot Labs homepage

I was first introduced to This Dot Labs in early 2021 when their Twitter account started to follow me when I was posting about my Black Excellence Music Project.

They left a comment on one of my posts about joining their next Women in Tech meetup and so I signed up to check it out. I fell in love with the atmosphere of the meeting and met some incredible female software engineers.

I continued to attend their monthly meetups and started becoming more active with the other events they hosted. I also started to reach out to other current and former members of the company to set up short coffee chats to learn more about them.

For the next few months, I continued to build up relationships and my technical skills. In December of 2021, I decided that the time was now to hit apply.

The interview process

The interview process for This Dot Labs consisted of a set of behavior questions, take home project, and final technical interview.

The take home project was similar to the projects you can find in freeCodeCamp's Coding Interview Prep section. In the final technical interview they asked me questions about my previous developer work experience and my personal projects.

They wanted to know about the features of the Black Excellence Music Project, why I choose React for the project and future improvements. I felt like I developed a good rapport with the interviewers and made sure to answer all of the questions as honestly and in as much detail as possible.

When I received the email that I had gotten the job, I was excited. I knew this would be a good learning opportunity for me and a great next step in my career.

My first couple of weeks on the new job

My This Dot Labs team profile

My first day as a junior developer at This Dot Labs was on Valentines Day 2022. The morning was filled with onboarding meetings to help me get introduced to my manager, the team, and the project.

It was a little overwhelming at first, because I had some trouble getting the backend setup with the new project and there was a flood of new information to digest. But I tried to do my best with asking questions and connecting with my new teammates.

The first few weeks were filled with meetings, code reviews and completing my first few tickets. I had moments of imposter syndrome because I was much slower than the rest of my team who are more senior than I am.

But my team was very supportive and reassuring that I was progressing well. I started to find a groove and gained more confidence in my skills.

Lessons I learned along the way

This last year and a half has been one crazy, unexpected, fun, and sometimes frustrating experience. But I did learn a lot of good lessons along the way.

Learn the fundamentals well and don't rush through things

I came from a non technical background, and learning how to code didn't always come naturally to me. There were plenty of moments where I struggled with lessons or class projects and started to doubt if I could learn how to code.

But I kept going and decided to take things slow. I knew there was no benefit from skipping the fundamentals and rushing through the learning process.

My advice to newcomers is to build a good foundation in the fundamentals and build a lot of projects along the way.

I built tons of small projects just for learning purposes. Building projects allows you to better understand how the technologies work and builds up your technical and debugging skills.

Build a substantial unique project you can talk about in interviews

One of the biggest mistakes beginners make is displaying class projects on their résumés and portfolios. The problem with this approach is that hiring managers and recruiters have seen those same projects dozens of times.

Class projects are great for learning purposes and serve as good practice when you are first learning. But it is important to also build projects that take some time and have more substance to them than small toy apps.

Remember that interviewers will ask you about your projects and the features you added. If it is a small class project that took an hour or two to build then there won't be a whole lot to talk about.

My advice would be to build something inspired by your previous career or personal hobbies. Or maybe even build something that helps you automate some tasks at work or something that benefits the community you are in.

Learn in public

Learning in public can be a great way to connect with other developers and possibly lead to unexpected job opportunities. I would suggest joining Twitter and posting periodically about your progress.

You can post about classes you are going through or projects you are currently building. The 100 days of code challenge is a popular way to do that.

Remember that consistency is key and posting good content over a period of time will help you build out a following. You also never know who will be reading your posts.

Join a community and connect with other developers

No matter where you are at in the your learning journey, it is extremely important to join a community of developers to learn from and connect with. I have learned a lot from the communities I am a part of and met great people along the way.

When you are connected in a community, they can help you through the difficult learning moments and help you find good job opportunities. Hopefully, you can lift others up and help them along the way, too.

There are plenty of tech communities to join including meetups, discords, chats, Slack groups, Twitter and more. Try to find a group that is supportive of beginners and allows you to participate in ways you feel comfortable in.

Learn how the job process works

In the beginning of my journey, I made sure to study how the job process actually works. I read dozens of forum posts in the career advice section from those currently going through the job hunt.

I learned the dos and don'ts from others and learned what worked for landing that first junior developer job.

I have heard a lot of people complain that the process should just be as simple as filling out applications and they shouldn't have to do extra stuff like building an online presence or network.

In a perfect world, that would be the case. But the software hiring process does not work that way.

My advice is to learn how to write good résumés, learn how to network, learn how to write a good LinkedIn profile and how to find good job leads.

Here are some helpful resources to look into:

• How to Build Your Developer Résumé Without Job Experience
• How to Get Your First Dev Job – Insights from Reviewing Career Switchers' Résumés
• How to Write a Developer Resume that Recruiters Will Read
• Why Your Resume Is Being Rejected - and How to Fix It
• HOW TO USE LINKEDIN AS A DEVELOPER to get a job in tech! How to network!
• How To Get A Job As A Software Engineer
• Interview Secrets
• Blogging For Developers! Sponsored by Hashnode!

I hope you enjoyed this article and best of luck on your programming journey. You can also connect with me over Twitter.

It takes more than a stable internet connection to make a living as a freelancer. In order to make the big bucks, you’ve got to put in your time and know your stuff when it comes to selling your services.

In fact, there are quite a few things that most freelancers don’t even do that could save them a bunch of money. This article covers some of the most efficient ways for you to get started as a freelancer, and how you can hit the ground running right from the beginning.

Is freelancing right for you?

This is the gig economy!

The future of freelancing looks bright – and not just in regards to national workforce growth. The number of self-employed workers has grown steadily over the years, and at a rate higher than employment growth for employees.

It’s estimated that by the end of 2021, 42% of the American workforce will be freelancing.

As someone who has worked both as a freelancer and an in-house professional, I know that things aren’t always as straightforward as they might first appear.

I’ve never known anyone who went from having no clients to lots of clients overnight. It takes time to gain the confidence of potential clients and win their trust.

And if you want to work with big companies or internationally famous people, this process is even harder.

Make sure you want to work for yourself

Firstly, you need to be independent. The nature of freelancing means you’ll be working for yourself. If you’ve never worked in this way before, it can be a tough and isolating experience.

It takes a lot of time and effort to deal with the demands of running your own company, so you need to be an independent worker if you want to succeed.

Whether you’re a web designer, developer, or content creator, you have the opportunity to work on projects that you truly care about. And you'll get both the praise when something goes right, and the blame when it doesn't. Either way, if you’re a freelancer, then every outcome is a direct result of your efforts.

The flip side of being self-employed is that you have no one to rely on but yourself. There’s no one to assign tasks or remind you when they’re not completed.

At the same time, you need to market yourself. But how do you do this and still have the time to work on the actual assignments that you love?

How to Find Freelance Clients

Many new freelancers underestimate how important marketing is to getting hired as a freelancer. To some degree, you can make yourself look more professional and respectable by taking the time to show potential clients how you do business.

It’s not just about drawing up a few mockups, sending them to a client, and waiting for the cash to roll in. Craft, creativity, and promotion are all equally important when it comes to being a successful freelancer.

We could talk all day about the best practices for achieving success as a freelancer—or even the way to use tools like LinkedIn effectively.

But today, I wanted to provide you with specific ways to get more freelance clients, whether you’re just starting out or are looking for new approaches.

Network with other people in your industry

Your potential client pool is probably much easier to access than you think.

Don’t just ask your friends and family for work – this is a good way to burn bridges and to get into the habit of waiting for others to give you work.

Instead, engage with people in your industry and come up with ways you can help each other out. Maybe your colleague from your first job needs some voiceover work done on their podcast. Recommend yourself for the job. And if they say no, offer to record it for free as a special gift for helping you out.

Even if you don't know people in your industry in your city, search for them on LinkedIn and start getting in touch with people in that network—even if it isn't local. Ask them if they know anyone looking for a freelancer or if they have any advice for finding clients. You might even make some new friends!

This offline-to-online connection will put them in a prime position to be your advocates.

If they know of any opportunities, or if they have advice for finding clients in your field, you can bet they’ll pass it on to you, and likely with enthusiasm. And who knows—they might even hire you on the spot for a project once they know that you are freelancing.

Cold calling best practices

Cold calling is still a viable lead generation tactic, second only to social media. For example, during 2019, 69% of buyers report accepting one or more cold calls.

I know, many people will say that the number of organizations that actually do it are few and far between. But what they fail to recognize is that this is where the opportunities are hidden – the ones not being addressed by your competition.

If you plan on using this technique during your sales process, you need to get over your fear of rejection.

All you need is someone to practice with. Then ask them to give you mean criticism, without any tact or sugarcoating, for something you’re seeking from them. It can be a critique on a product idea, a pitch, your blog post, your haircut — whatever.

Remind yourself of the great testimonials you already have and move on to the next call.

Initially, you can think of a cold call like a job interview, making it easier to stay on track with the prospect and avoid going off on a tangent about your business. By prospect, I mean anyone you communicate with who has not requested information from you or your organization.

The only way you can get better at cold calling and closing sales is to keep doing it over and over again.

Writing effective cold emails

Cold emailing is exactly what it sounds like—contacting people you don’t know without any introduction. You’re putting yourself out there by putting your reputation on the line. Cold emailing gives you the ability to connect with anyone, but it can also put you in uncomfortable situations where your messages are not welcome.

Cold emailing has been a controversial undertaking for a very long time. Every now and then, an article comes out about how you shouldn’t be doing it at all.

However, cold emailing is a solid way of leaving your mark in the business world. There is a fine line between spamming people and giving them a good offer that they cannot refuse.

In order to generate the most response from cold emails, there are certain things you need to keep in mind.

Build a connection before selling to your prospect.

Not every recipient will be familiar with what you do or who you do it for, so give them some background information about your company or service.

If you’re writing to them because you want to provide them with some sort of solution, identify what problems they might be facing and explain how you can help.

Do your research.

Especially during the earlier stages, you need to choose your clients carefully. Don’t make the mistake of assuming that something that works for one type of client will work for another.

When it comes to your prospect, you should know as much as possible about them. If you understand who they are and what their interests are, you can strike up a conversation that will give off the impression that you know all there is to know about them. Just don't go overboard.

Introduce yourself as the solution to their problem.

You’ve heard it before: “People don’t buy products, they buy solutions to their problems.” Well, no matter what you’re selling, the prospect is going to ask, “How is this going to help me?”.

You can also try creating a list of their pains and the ways you can solve them if they choose your product or service. Make sure that your product or service is something that will genuinely benefit the customer and that the customer needs.

Collaborate with other agencies or freelancers

As you begin working on your own, you’ll go through growing pains. No one can deny that. But moving towards becoming a freelancer allows you the chance to have control over your time, your projects, and your future.

If you miss working in a team, you can always collaborate with other freelancers or agencies. You need to create a network of freelancers with different skills. While you have your favorite writers, designers, or social media marketers, think about new people who might provide great value for your business and vice versa.

As any professional freelancer or agency knows, the best way to collaborate with other freelancers and agencies is by establishing good relationships.

These ties can help you in furthering your career and in doing your work in the most efficient and productive manner possible. But in order for you to collaborate successfully with other freelancers and agencies, you should take into consideration the following tips:

Learn as much as you can about them.

Working with a collaborator is a great way to get a project done to a high standard, but it’s important that you choose the right person. Asking someone to work with you can be a little daunting, especially if you don’t know them personally at all, so it’s best to have some information about them beforehand.

Use the same collaboration tools.

You might be working in a completely different field and collaborate with someone who is miles away and in an entirely different part of the world.

The technology that we use every day can bridge that distance and make it easier for you to communicate and form the bonds that will define the way you work together. Make sure that you both work with the same tools to maximize efficiency.

Always ask for feedback.

Whether you’re collaborating with an agency or other freelancers, it’s important to continuously give and receive feedback. This should never be seen as criticism or a personal attack. It’s simply feedback on how you worked on the project. The person you worked with may even have ideas on how they would work differently in the future too.

Join popular marketplaces

There are many freelance platforms where you can win projects and make a lot of money.

However, before signing up with any website, you must do some background research on whether or not they are legitimate. By making a comparison of the best freelance marketplaces, you will be able to find a trustworthy platform for freelancers.

Here are the top 3 freelance platforms that are vetted by thousands of people:

Option #1: Upwork

Upwork is an online platform that allows freelancers to publish their skills and employers to search for the right person for the job.

It lists some 3 million freelancers across more than 100 different categories, some of whom will be capable of handling more complicated projects than others.

Its clients also spend at least $5,000 per year.

The users can set out their hourly or daily rate, experience levels, relevant skills and what languages they speak. The employer then selects freelance candidates and can use an instant messaging tool to chat with them directly through Upwork. After a fee is agreed, everyone moves on to Upwork's secure payment system.

Option #2: Fiverr

Fiverr is an online marketplace where you can sell any kind of service for $5. Though they started as a place to find simple tasks, Fiverr has become competitive with freelancer services that charge anywhere from $50 to thousands of dollars for projects.

Option #3: People Per Hour

PeoplePerHour (PPH) is one of the largest freelance marketplaces in the world, with over 2.5 million users and 400,000 freelancers. It brings companies and independent professionals together for projects ranging from graphic design to programming and writing.

No matter which marketplace you choose, make sure it suits your needs and services.

Conclusion

Becoming a freelancer can’t happen without its uncertainties, and there are roadblocks along the way to watch out for.

But don’t let that put you off, because it’s well worth it in the end. Allow yourself to be inspired by other freelancers and learn from their mistakes.

If you can do this, you’ll be well on the path to greater success with your freelancing career.

Hey everyone, my name is Santosh. In this article, I will tell you how I ramped up my career and ended up increasing my salary as a developer.

I'll share what I learned from each job along the way, how you can stand out, tips for negotiating salary, and how I got to where I am today.

Here's a little bit more about me: I am from India, and I am an Angular GDE, India's First GitHub Star, and Auth0 Ambassador. I also live stream on Twitch and YouTube. You can find more about me here.

How It All Started

I started my developer journey in 2008. I couldn't get a job after college – 2008 was the worst year for the entire tech industry, as many already know.

When I was in college doing my CS degree, my friends used to tell me that'd I'd be able to quickly get a job making 300000 INR ($4000) per year. But by the final semester, it became clear that it wasn't happening.

After finishing college, my friend and I went around to every job consultancy to share our resumes. But we couldn't get any bites. We updated our resumes on every job platform available, but no one was hiring freshers.

How I Got My First Developer Job

Finally, one of my father's friends who ran a consultancy got me an interview scheduled. I was looking for a job as a developer in C#, and I joined the company the next day after the interview. It was 18th October 2008.

The organization was small, but the CEO had a big vision with the product he was building. I don't want to call it a Startup, because it was an HR consulting firm, which was his main business. My salary was 60000 INR ($800) per year.

I had a lot of free time, and I took the opportunity to use that time to learn more. Still, I was not that serious and enjoyed my free time. I learned a little bit from a senior developer on my team, though. I decided to quit after ten months, as I realized it wasn't good for my career.

From Jobless to Small Time Contracts

After I decided to quit that first job, I went home for one month. With my friend's reference, I got a contract position for a few months.

The pay was a little bit more, this time 120000 INR ($1600) per year, which was double what I was making before. But the work was more operations-focused and working with Oracle DB sometimes.

My first love was C#, but my family's finances were terrible, so I had no option but to take that job. By the end of 2009, it was clear – I wouldn't have this contract next year. So again, I tried hard and got a job.

My First Real Programming Job

I got my first real programming job in January 2010. I started working with Capita India, but I joined as a contractor on another company's payroll. It was like a contract position, but more stable than the last job.

My salary was 144000 INR ($1900), money was low, but of course, I was getting an opportunity to learn as well. My manager was terrific, and my co-worker was the Database Admin. Yes, you guessed it right – I was the only developer on the team.

For the first three months, I had a lot of work to do. I was working on a Windows App for the finance team. But soon work stopped coming. I spoke to my manager, and he said I should use that time to learn more.

After a few months, I became part of a larger team after some organization-level changes. I started getting some work on ASP.NET, but I decided to move on in November 2010.

Something I learned from this job: Use your spare time well. You won't always have enough work to do to keep you busy all the time. Use your spare time to read blogs, watch some courses, read, and create some proof of concepts with whatever you've learned.

The time I invested in learning paid off. I got an offer with a 100% raise. My manager provided a lot of motivation which is why I got that raise. As I had no computer at home, I read a lot, which was the best chance to improve myself.

Working for a Bank and on a Big Team

Like my previous job, my next role was also on the payroll of another company. I was working for ICICI as a contractor, the same as my last Job at Capita.

But for the first time, I was working on a team of more than 60 people, and my salary was 288000 INR ($3900). I felt like I was finally making good money as a dev, but I finished the project I was working on in ten months, and the work stopped coming in again.

At this job, I learned more about working on a team and saw how bad managers could make people quit. By the time I left, there were fewer than ten people on the team. This place became toxic over the months, and devs were terrified to share anything with the manager, and so that manager had trust issues with all developers.

I also learned that you shouldn't stay and work in a toxic environment. I have seen many developers working in toxic work environments. A toxic work culture is terrible for everyone, and it can turn your co-workers against you. It also makes you less productive, more insecure about your job, and it can make you burn out. Quit as soon as possible – you deserve better.

Fortunately, I invested time in learning some new packages introduced in .NET, and I found that there were a lot of job opportunities for that tech here. I interviewed at a startup and showcased tech I never used at work. And it paid off – I ended up getting the job with a more than 70% raise.

Here are some tips for negotiating your salary:

Always Know Your Worth

In the tech industry, you will find different devs doing the same job but not getting paid equally. Some organizations take advantage of you and pay you less. Always study the market if you are looking for a job. Ask for the salary range if possible.

Never Negotiate Salary Based on Your Last Pay

Always ask your recruiter for a salary range. If you hear it will be 30% above your last salary, you might skip them. Always keep the figure you want in your mind, and negotiate based on that. I have even received a 100% raise from my last salary.

Know the Job Description

Before joining any organization, know about the job description; money should not be your only focus. I declined a job offer with more salary once because the job was more of support, and I was about to get a work opportunity at the startup.

Joining the Startup

At this point, I started to push myself more, as I wanted to make sure I could give my family a better life.

I joined a startup in 2012 with a salary offer of 450000 INR ($6000), which was a good raise from my last salary. It was also my first job where I worked for more than a year – I stayed for almost five.

I had been promoted to Team Lead by the time I left in 2016, and my salary was 1200000 INR ($16500). But I decided to go as I was not writing much code, my manager was very toxic, and I could not give much time to my family.

At that startup, though, I got to work with some fantastic managers and developers. We made an incredible team, and I am still proud of it. I think it was one of the best achievements of my career. I learned a lot about people management, which still helps me a lot.

Also, the growth was tremendous. I was able to get a raise of more than 30% every year until 2015.

Here are some things I learned from working at the startup:

Don't Fall in Love with Your Organization

Even if you are the best employee at work, you are replaceable. I had worked extra hours for the startup, even though no one asked me to do it.

Because I loved the organization, I learned the hard way not to make that mistake again. Family time is more critical than an organization where you are just another employee.

Keep Your Skills Up to Date

Keep learning! Sometimes we get stuck into the same tech stack over the years. Then when you go back into the job market, it has already moved on, and there is a new stack everyone's using.

A lot of organizations have a Pluralsight or other learning platform subscription, so use that if you can. If your company doesn't have one, there are plenty of free learning resources out there you can use instead or in addition.

Once I decided to leave, I failed many interviews. But it was an eye-opening experience. I had learned everything I needed to work at my old job – but was I updated with what tech stack was currently in demand? No.

Moving to Pune for a Better Life

In 2016 I decided to Join Synechron and moved to Pune. I joined as an individual contributor and started working on .NET with Angular.js.

My salary increased a little, but the cost of living was much cheaper than in Mumbai. My salary was little bit more than last pay, and I started making some extra income in 2017 by conducting online Angular Training. That was a great help as my finances were terrible.

It was the first time since 2011 that I had worked 40 hours a week, which meant that I had more time for me. I started learning Angular and teaching it as well.

The team was great, and the client gave me access to Pluralsight, which helped me learn Angular, a new Front-end framework. I completed all the courses by Deborah Kurata to learn more. I got some contracts to teach Angular and led me to get my next job at the Bank.

By the last quarter of 2017, we realized that the client we were working with was not going to give us any more work, and we needed to be prepared to move to another project.

Working for Another Bank

In Oct 2017, I joined a Bank with a good increase in salary. It was now around 40% more than last pay, thanks in part to my experience teaching Angular which impressed my hiring manager. I was also getting extra money from my training.

I got the chance to take complete control of the framework built on top of Angular. I talked to different teams about the feature they needed and helped them implement those features.

And more than that, I still had enough time to improve myself. I read more about Angular, and made the framework better.

I even received a performance bonus of 100000 INR ($1300) in 2018.

I was able to apply learnings from my previous jobs and I learned to say no. The most crucial skill you need as a developer is to be able to say no when you need to.

There will be times when your manager needs you to work extra hours – say no. One thing I learned is that very few things are critical and they can all usually be done the next day. Especially if it's a new feature and some not crucial bug fix.

Starting Open Source Contribution

By 2019 I decided to get more involved in the Angular community. I decided to start making Open Source contributions and began working with the NgRx and Angular projects.

I started writing blogs, giving talks, and even created some of my own open source projects. 2019 was more focused on the community, and I started improving my skills in Angular too by learning in public. This was all possible thanks to support from my manager.

I gained a lot working here. The critical thing I learned was how to stand out, which is still helping me to get new work.

And here are some more tips to help you improve:

Learn in Public

At work, as a developer, we get to face so many issues, but often we just solve the problems and move on. You know you can share that experience with other developers. Start writing blogs, and create content. You will learn more by sharing your knowledge.

Contribute to Open Source

I have learned more by contributing to Open Source than from almost anything else. It lets me promote myself, too. It might even help you get your next job. I got better opportunities because of my Open Source Contributions and the connections I made in those communities.

Starting My Remote Job

By the end of 2019, I had the opportunity to speak at some conferences, which the bank wouldn't let me do. So I decided to quit, and one of my friends Serkan helped me land a new job because of all the contributions I was making to the Open Source community.

I received around 50% raise from the last salary. I was going to start working remotely, which meant more time for family and community efforts. At this job, I got to work on a product and used Nx DevTools for the first time. I also learned how I could improve the performance of the App.

In 7 months, I implemented SSR and optimized bundle size. I converted the app to smaller libraries, so it was easier to add more apps in the future. I also shared these learnings with the community.

Going Solo

I decided to quit my full-time job in Oct 2019 and move into consulting. I had a good connection on Twitter, and everything started with a tweet.

Many developers responded with some solid leads. Finally, I got my first client and started working in October 2020. I got my next client in November 2020, all thanks to my community contributions.

Around the same time, I became India's First GitHub Star. Both are good-paying clients, and I make much better salary now. I was able to pay off the loans I took out in 2012 to pay medical bills for my daughter and wife.

So far, the consulting gig is fantastic. I get to help many developers and I improve my knowledge while improving the platform.

It also helps me give time to the community and support Open Source developers by donating some money towards OSS.

Conclusion

Working for the community did wonders for my career. It took me 12 years to move from $1,000 to a more stable salary, but the journey so far has been worth it. I saw days when I had to think how we would survive, and I wondered how I would give a better life to my daughter and my family.

The experience at every job has been different. I suggest that you start learning in public. It always helped me give my best and it built up my confidence so that I knew I could sell my skills.

And don't forget that salary negotiation is an important skill. Never underestimate yourself when negotiating. You can always make more money than you think.

You can read my life story here:

Cover photo by Ian Schneider on Unsplash.

Lately, I've been talking about my move into the Web3, Ethereum, and crypto space since making the switch from a traditional web, mobile, and cloud background.

Since making that move, a shocking number of people have reached out to me who are also thinking about doing the same.

It's really great to see so many other people interested in these fields. And if I'm being honest – it feels validating to know that so many others are also on the fence and are so deeply interested in the space as well.

As for me, I was nervous about making the career switch. Moving into a completely new area of specialization, with a technology I was still getting ramped up on, and a community I was not yet involved with, was a big leap. Especially compared to a very comfortable role with a FAANG company that paid really well (and a team that I really loved).

After over a month, I have zero regrets with the change. I'm also the happiest I've been in a long time, and am excited and energized about the things I have the opportunity to work on everyday.

I decided to write this post to give a blueprint for anyone looking to get into blockchain, crypto, Ethereum, and Web3 from a traditional development background. I can point people to this blog post the next time I get asked how to get into the space.

I'll break this article up into a few main parts:

1. Technologies and resources to learn
2. Tradeoffs and considerations
3. People to follow
4. Companies hiring and doing interesting stuff
5. General tips and landing a job

Let's dive in.

Technologies and Resources to Learn About Ethereum and Blockchain

What I'm most interested in is usually a function of where I predict technology will be in the near future and where I see the current momentum being. So that's what I will focus on here (and this is what I am doing personally).

To me, the most exciting parts of this space are decentralization, DeFi, governance / DAOs, and decentralized web infrastructure.

Because of this, I'm focusing on both Ethereum development and Solidity. With the Solidity programming language ,you can program smart contracts for Ethereum as well as for many other EVM compatible blockchains.

As of this writing, Ethereum also has the powerful and important combination of momentum, developer mindshare, and existing production dapps.

Ethereum is also currently moving to a new consensus mechanism, proof of stake. This addresses the environmental concerns I used to have about how cryptocurrency works at a core level.

Once you learn how everything works fundamentally, I encourage you to then check out other blockchains and projects outside of Ethereum and EVM.

This will give you a better understanding of the industry as a whole. It will also help you see if there are other projects that attract you or that you believe are better approaches to achieving the goal that is Web3.

Consider looking into Solana, Polkadot, Near, Avalanche or Cosmos.

To get started learning blockchain development with Ethereum and Solidity, I suggest you do the following:

1. Read the Ethereum docs

Scan through the Ethereum docs. Be sure to check out the section Intro to Ethereum as well as anything else that catches your eye.

Also be sure to check out the dapp showcase to get a good understanding of the successful apps being built and used in the current ecosystem.

2. Read the Solidity documentation

The Solidity docs are a really good place to get started, especially solidity by example. This gives you a few examples of popular smart contracts like voting, an auction, remote purchase, and micropayments.

You can copy and paste these contracts in the Remix IDE to start executing and modifying them to see how they work.

I also did a video walkthrough of the voting contract here.

3. Get comfortable with the Remix IDE

It's really easy to play around with and start building smart contracts without having to set up any type of development environment by using the Remix IDE. It's part of the Remix Project which is funded by the Ethereum Foundation.

This Remix IDE allows you to create, edit, and execute smart contracts directly from your browser. It offers a perfect environment for learning how solidity works. It's also great for building out various types of smart contracts and playing around with them as you are learning both solidity and how to interact with Ethereum

4. Try building out a full stack dapp

In addition to Solidity, the other parts of the the development stack include a local Ethereum environment like Hardhat or Truffle, a wallet like Metamask, as well as a client-side library that allows you to interact with the blockchain, like either Ethers.js or Web3.js.

To understand how all of this all fits together, it's useful to build out a full stack dapp on this stack from scratch. You can set up the front end project as well as the local development environment and deploy, run, and interact with a smart contract on the blockchain.

Here are two introductory courses to get you going with this:

1. Ethereum Programming Tutorial - DeFi, Solidity, Truffle, Web3.js
2. The Complete Guide to Full Stack Ethereum Development (and here it is in article form, too)

5. Consider reading these books

The space itself moves very quickly, so technical books often get out of date just as quickly. The fundamentals of what Web3 is, though, have not changed much at all.

There are a few really great books that helped me not only grasp the current state of everything, but that also helped open my eyes to the future possibilities and opportunities that lie within it.

Token Economy - How the Web3 reinvents the internet

If you only read one of these books, this is the one I'd say is the most important. It is a masterful deep dive into all of the shortcomings of the web as we know it, what Web3 aims to be, how it will affect various parts of our lives as we know it, and what needs to happen for this vision to be realized.

You can view the book here.

The Infinite Machine - How an Army of Crypto-hackers Is Building the Next Internet with Ethereum

This is the amazing story of how Ethereum came to be, walking you through the history of it all. It is a very thorough and entertaining account of the origin story of Ethereum, I highly recommend checking it out.

You can view the book here.

New Village - Power Back to People

This is a really cool story of how blockchain technologies and decentralization will affect the future of the world.

You can view the book here

How to DeFi

As you can probably tell by the title, this book focuses on how you can start using DeFi today. It gives you a good understanding about how you can use it today as well as some applications of it that we will see at some time in the future.

You can view the book here

The Spatial Web

The Spatial Web is a book that explores the future of the web and all of the implications, not only of Web3 and decentralization, but how everything will come together to enable things that we may have not yet considered.

It does a good job weighing the positive and negatives as well as ways that we may be able to address any negative outcomes of what is to come.

You can view the book here

And here are a couple of solidity books:

• Hands-On Smart Contract Development with Solidity and Ethereum
• Mastering Ethereum

6. Listen to these podcasts

Here are some good podcasts:

• Founders of Web 3 – The people that are creating and building the next phase of the internet.
• Bankless – The Ultimate Guide to Crypto Finance
• Into the Ether – Podcast about Ethereum
• Crypto 101
• Epicenter – Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies

7. Watch these YouTube channels

• Ethereum Foundation
• Eat the Blocks – Short videos on blockchain development
• Finematics – Sharing interesting DeFi videos
• Dapp University – Videos in the Ethereum space
• BlockGeeks – General Blockchain Training
• The Daily Gwei
• Austin Griffith

I've also begun doing videos and tutorials on Ethereum and Solidity, so consider checking out my YouTube channel.

Tradeoffs and Considerations of Switching Careers

There are always things to consider when making a career transition, but especially when considering this space.

There are a lot of positives, but there are also unknowns as well as negatives. Let's talk about some of them.

It's nascent tech

While there are many existing dapps and companies already flourishing, this space is very much still coming into existence in many ways.

There are a lot of problems that we still need to solve, and there are no clear answers for many questions you'll have. The problems being solved are often complex, sometimes combining one or more aspects of distributed systems, game theory, cryptography, economics, social and political science, identity, psychology, and more.

Because of this, there are still things that we cannot yet build with the existing solutions that are available.

I personally think this is one of the more exciting things about all of it it, but it's not for everyone.

It's a volatile space

Many of the projects are built around various types of tokens. The value of many of these tokens rises and falls dramatically, and you often see that people gain and lose excitement in the entire space based on these swings.

If you haven't fundamentally bought into the ideas behind decentralization itself, you may find these ups and downs mentally taxing.

It's full of speculation

Because a lot of people only buy into certain tokens in a speculative way, it attracts some people who are in it only for the money.

You see things like scammers trying to get over on people and steal their money, endless talk about price swings from people who are speculating, and outright scam projects that often discredit the industry as a whole.

This is an annoying part of it and I don't really see it going away anytime soon.

This thread

I would also check out this Twitter thread. Although I have not experienced all of these things, he is definitely shining a light on some of the things I have seen.

General Tips and How to Land a Blockchain or Crypto-Related Job

There are many areas within the space that you can focus on and provide a positive impact on a team. I'd look into the different areas like governance, DeFi, NFTs, and decentralized web protocols to see what interests you the most and then focus on that.

There are a lot of opportunities and a lot of ways to stand out and get noticed. If you find an interesting project and would like to get involved, jump right into their community and ecosystem and start learning. Then see where you may be able to help out. Join their Discord or look at their GitHub issues to find ways that you can contribute.

This will give you an opportunity to meet people involved in the project and will open up discussions for potentially landing a role with them. In fact, it is very common for people within the teams to take notice of active community participants, they will then often reach out and try to recruit you without you even applying.

The pay is usually good. Depending on where you are coming from, it could be more or less, but it's probably not going to be at the high levels of what you see at FAANG companies.

There is probably more potential upside. Most companies offer a combination of base pay + equity in the form of their digital token, so if you stick around and can help make the project successful and the value of the token goes up, you can often make more than what you would in many other areas.

People to follow on Twitter

Here are a few people who you may consider following on Twitter:

Vitalik
Ashleigh Schapp
Arthur Hayes
Stani Kulechov
Gloria Kimbwala
Niran Babalola
Ric Burton
Dennison Bertram
Mana Silvora
Austin Griffith
Santiago Palladino
Zaki Manian
Anthony Sassano

I also found this comprehensive list created by someone on Twitter.

A few people on my team at Edge & Node:
Yaniv Tal
Tegan Kline
Eva Beylin
Adam Fuller
Brandon Ramirez

Teams doing interesting stuff (and hiring)

Compound
Uniswap
Chainlink
Skynet Labs
Aave
Matic
Livepeer
Consensys
ENS
OpenZeppelin
Foundation
Zora
Synthetix
Digital Currency Group

You can also find a pretty decent list of job opportunities in cryptocurrency here.

Also, my team at Edge & Node is hiring!

Conclusion

Did I mention this space is volatile? Be ready for some high highs and low lows, but also for some of the most fun you may have in your career.

You'll be working alongside some of the smartest people in tech trying to solve some of the most complex problems that I think will ultimately have a massive positive impact on humanity.

In this article I'm going to share with you ten important lessons I learned during this career transition.

I finished law school in Bangalore, India, a year before Google listed on the Nasdaq. That was a long time ago. The world was very different. I think Facebook was still “thefacebook”.

I started my career as a litigator in the courts in India. Two years later I switched to corporate law, and then ended up moving to Australia to join one of the world’s largest law firms, in their Melbourne office.

Several years later, after surviving the Global Financial Crisis of 2008, I became an Australian citizen and moved “in-house” – the term for when lawyers move from working at a law firm to working internally at one specific company.

I loved being a lawyer, because it was filled with smart, ambitious people and it paid well. But there was always a part of me that longed to code, to create, and to contribute to the internet’s repository of useful tools.

To me, programming a computer is such a magical act. To write text, and have machines follow your commands – there is something so powerful, so limitless about that. It fired my imagination.

But I really did not view myself as “mathematical” or “nerdy” or a “brainiac”. Every bit of social messaging around hackers, coders, programmers, and technical founders (which by 2012 was a status symbol!) reinforced the myth that programming was the domain of “wickedly smart” math wizards.

I unwittingly reinforced that myth to myself – I tried to teach myself to code THREE times. In 2014, in 2015 and in 2017. And all three times I quit because I tried to jump too high, set myself up for failure, and then assumed I was not smart enough (when actually, I had just tried to run before I’d learned to walk).

Programming felt beyond my reach. Just. Too. Hard. I had no clarity on where to begin, what bits to learn, and most frustratingly, what bits to ignore.

Instead, I started a tech company and hired a team of coders. One of them became my technical co-founder. He quit a year into it, and I was left with partnerships and contracts with local governments that I had to honour.

Faced with the choice of being defeated or learning to code, I chose to try again – to learn to code.

I was 37. In 2020 COVID hit, and just as it was getting very serious, I signed my contract to be an an engineer at Google. I had just turned 39.

It felt odd to be “starting” over. But it also feels incredibly fun to be a beginner again. In fact, I can actually truly relate to what Steve Jobs said at his famous 2005 Stanford Commencement Address:

“The heaviness of being successful was replaced by the lightness of being a beginner again, less sure about everything. It freed me to enter into one of the most creative periods of my life.”

I had left a successful legal career and then a less than successful startup journey to be a beginner again. As a coder and coach, I am being more creative than I’ve ever had the privilege of being.

This is not about Google or any other fabled tech company. This is about you. It doesn’t matter what your goal is. I want you to know that transformations are not “special” or “miraculous” – they just feel that way.

The people I coach have gained an understanding of how I “found” my roadmap to becoming a coder, in a world where there is way too much information and consequently way too little clarity. But there isn’t enough time here to go into that.

Today I want to help you by whittling down my 10 most important principles for people wanting to transform their lives and achieve their goals.

You’ll see that this is true of coding, or anything else. But since I am now a self-taught engineer, working at Google, it is particularly relevant to others who are coders or aspiring coders.

At the end of this piece, I’ve put down some ways to reach out to me if you have any questions.

5 Things NOT to Do When Changing Careers

I am starting with the “don’ts” because it’s easier to identify things we do that hold us back, than to develop new habits. Tackling the don’ts first will give you quick wins that will build your confidence – and from there you can build up to the “Dos”.

DON'T Look at the Mountain Top

For a long time, you’re going to be climbing a steep mountain. It’s going to feel long in the moment, but it’s a short period in the context of Life.

The mountaintop will not get closer no matter how often you look at it. But the more often you look at it, the more you’ll get discouraged because somewhere, we are all in a hurry. Things take time. And as Jeff Bezos says, you can’t skip steps.

If you lose your optimism you lose confidence, and then you lose energy and momentum.

Instead, just focus on the process of learning. No matter how much code you write, you are always learning new tools, techniques, practices, languages, frameworks and so on. And if you rush yourself into feeling “competent” you will disappoint yourself, because at first you’re going to get suck.

That’s normal. You can’t skip the novice stage when you’re learning, and if you try to skip it, you will get frustrated and lose your passion.

The process of learning is to do a little bit consistently, rather than a ton of stuff in an inspired burst. 60 minutes every day for 3 months is far more effective than blitzing it for 20 hours on a weekend and then not doing anything for a month.

So don’t focus on “becoming a good engineer” or “getting that job”. Instead, focus on learning and getting your repetitions up until things start to feel comfortable.

DON’T Mistake Doubts for Evidence

You’re going to have doubt and fear with you every step of the way. If you think of it as a shadow, you may stop paying so much attention to it.

Doubts have a way of convincing us they’re real. They spotlight our weaknesses and over-emphasise our failures. And then, without realising it, we take them as evidence of our ability.

This one takes practice. And since you’re never going to be doubt-free no matter how much of an expert you are, you should practice making space for your doubts while not paying too much attention to them.

No matter what your doubts tell you, there is only one thing you know for certain: if your doubt is right, it is right only right now. Tomorrow it could be wrong. If not tomorrow, the day after that.

Your doubts don’t prove anything about tomorrow. Chances are your doubts are not right at all – they’re just insecurities and exhaustion.

Rather than fight doubt, it’s better to do some vigorous 10 minute exercise or take a nap. If doubts disappear (and you’ve experienced that!) then they can’t be all that real.

DON’T Measure Reality Against your Secret Wishes

All of us have secret hopes and fantasies. We hope we will be recognised as brilliant and our boss will promote us without us having done much, or that we can get super-fit bodies with 2 months of going to the gym, or that our first 3 blogs will get a bazillion comments and shares on social media. We secretly wish for success, without too much effort, and very quickly.

Maybe. Statistically, some people will get that lucky, just as a dead clock will tell you the right time twice a day.

But if you’re not aware of this secret wish and its power over your mind, you will feel disappointment. And you will not find the energy and discipline to keep going.

The truth is pretty much any goal that is beyond your current skills takes a lot of time, energy, focus, and discipline. And it requires you to maintain those practices well past the point you were secretly hoping for instant gratification. In fact you could go for months without much positive reinforcement from the world around you.

So measuring your results against your secret wishes is a recipe for giving up. Instead measure your results against your previous results.

I use a simple technique for this – my personal motto is to be 1% better every day. As long as you’re getting a little bit better each day (maybe you just read a blog, or did some deliberate practice for 30 minutes), then you would have improved yourself. These micro-improvement don’t stack – they compound.

Measure yourself against your past results, not your secret fantasies and you will feel tremendous motivation to keep going.

DON’T Take Big Decisions on Bad Days

You’re going to have a lot of bad days. Don’t negotiate with that – accept it and don’t put too much emotional weight on it. Even when you’re the best at what you do, you’re going to have bad days.

So you must expect a lot more of them, a lot more frequently, when you’re learning complex new skills. You must fully expect that you will have such bad days that the only rational-feeling thing to do is to quit.

You will have such bad days that you cannot see how things can get better. You will have such horrible days that you will assume the way you feel right then is how you’re going to feel forever unless you give yourself the relief of quitting.

I went through this so many times. Not just in coding – but in every single job I’ve ever had. This is why people respond so well to having a coach. A coach is “an external mind” that can see more clearly than you when you’re lost, struggling, confused, or discouraged.

The threat of quitting on a bad day is so high that I developed a technique to get around this. Rather than constantly arguing and negotiating with myself in my head, and confusing myself to exhaustion, I simply follow one rule: is this a bad day? Oh yes. Ok, no decisions today.

Rather than quit, take a break. When I was learning to code, I would sometimes stop studying and coding for a week if I was dangerously close to giving up. I figured I’d rather lose 1 week of progress than quit altogether. Most often, in 2-3 days my internal “state” would change and I’d be back at it, harder than ever.

In fact I found a rule from an olympic gymnast that I adopted for myself. I even wrote about it when I found it, as a way to ensure I followed her advice.

You can give up any time you like….as long as you’re having a good day. But you cannot give up when you’re having a bad day.

DON’T Assume Your Results Reflect Your Ability

It is easy to assume that your results reflect your ability. In a sense, that is true – they either reflect your effort or they reflect your current ability. And that’s the most important distinction to make.

If it’s not a failure of effort, then it is a shortcoming in your current skills. And that’s great, because skills can always be improved. It’s just hard because we secretly wish it would be faster, easier, and more glamorous to get to success!

Most importantly, it is critical not to let your internal dialogue switch from “I don’t know how to do X” to “I cannot do X”.

We often unwittingly confuse lack of knowledge or skill with lack of ability or potential. This is particularly easy to do when we’re surrounded by people who are a whole lot better than we are.

I felt this so many times. As a junior lawyer and then 15 years later as a junior engineer. I assumed other people were talented or gifted and I was not. As I grew in experience, other “juniors” viewed me as talented or gifted. It was just experience and learning.

There is a line from T. Harv Ecker that I really found to be true in my various careers:

“If you’re not doing as well as you’d like, all that means is there’s something you don’t know.”

Also, as a close cousin to this principle, follow John Wooden’s advice:

"Never let what you cannot do get in the way of what you can. "

There will be many weeks when you’re grappling with something that you simply don’t know how to do. It won’t come easy. It won’t come quick. And you may feel very stuck.

But there will always be something – maybe it’s something small – that you can do to take one step forward. By always moving forward, even if it's a tiny step, you will keep your momentum. And usually those small steps are the small learnings you need to stack up to solve the bigger problem that has you so badly stuck.

5 Things to DEFINITELY Do When Changing Careers

DO Work on Your Growth Mindset

If you practice the top 5 Don’ts, you will automatically start building a growth mindset. At first you may not have a growth mindset – it’s more likely to be that you will gradually remove the unproductive “fixed mindset” habits that we all have.

If you aren’t familiar with the concept of the growth mindset, take a look at this TED talk by Carol Dweck. She has even published her research in a bestselling book. This is a foundational worldview that will help in everything you do.

Note that I say “work” on your growth mindset. This is not a weekend hack. It is a lifestyle. It requires constant practice and self-awareness.

In my experience, the most powerful impact of practicing a growth mindset is that I asked radically different questions when I was failing or struggling.

For example, instead of asking myself “why can’t I figure this out?” I trained myself to ask “how can I find someone or something to help me figure this out”.

I remember when I was learning JavaScript promises, and I was really struggling to get the concept. At first I sank into depression because I read a few blogs and I just couldn’t grasp some of the intricacies and mental models. I felt drained and frightened, overwhelmed and very alone.

I watched this TED talk and I immediately asked myself – do I know any JavaScript developers? I went to LinkedIn and searched my contacts (I was too shy to ask total strangers on Twitter – a sign of my fixed mindset!).

I found a guy I’d met at a startup event, who was self taught and had built a JavaScript webapp. I reached out to him and it turned out his office was 15 minutes from my house. Two days later he spent his lunch break showing me how to use promises. It felt easy after that.

Carol Dweck was right – it wasn’t that I didn’t know JavaScript promises, it was that I didn’t know them...yet.

DO Make Friends with the Impostor Syndrome

Impostor Syndrome is when you secretly think that you’re not good enough to do what you’re doing and that you will get found out and exposed as a fraud, or an impostor. I wouldn’t say it’s common. I’d say it’s almost universal.

When onboarding at Google, I heard this topic come up so many times. There are tons of blogs, resources, and internal guidance on how to deal with it. Engineers feel it everywhere. Heck, the co-founder of Atlassian did a TED talk on it.

So, it’s a form of doubt, and we already covered how to deal with doubt in the DON’Ts section.

Impostor Syndrome has some added layers to it, because it typically arises in professional settings. That’s why it gets special treatment here in the DOs section.

Professional contexts produce more fear of embarrassment because we have all this baggage about performance, and promotions, and being reviewed by bosses. All that extra baggage gives it more power over us.

As you start to get successful in your coding journey, make friends with Impostor Syndrome and joke about it – it will oddly make your mindset more growth oriented, because by owning that you don’t know something, you open yourself to learning it.

If you hide it, you spend a lot of energy on soothing yourself that you could otherwise use to learn the thing you don’t know yet.

DO Practice Reframing Failure and Setbacks as Moments of Learning

We all hate the feeling of failing. We also can’t avoid it. What do you do when you can’t avoid something you dislike intensely?

You attach a different meaning to it.

If you classify setbacks and disappointments as failures, then you will emotionally respond to them as failures. If you classify setbacks and disappointments as information about what you need to learn, then you respond to them as lessons.

Let me be clear – this is not easy to do! Like everything else I’m writing about here, this takes practice. Just like coding.

As clichéd as it is, the emotional impact of the glass is half full versus the glass is half empty debate is very real. In fact marketers know this. They don’t tell you your fruity yoghurt is 20% fat. They tell you it’s 80% fat-free.

You’re absolutely going to fail, and if you learn from it then you have to ask yourself – did I fail or did I just learn something?

Put all your attention on understanding what you learned from that failure, analyse, deconstruct, and internalise it. That way, you won’t notice failing so much.

DO Hold Yourself Accountable by Making Fewer Decisions

As a lawyer, I can tell you that our minds are experts at arguing for both sides, depending on what suits it. If you ask your mind why it’s OK to skip a run today, it will tell you. If you ask your mind why running is important, it will tell you that too.

How do we get anything done with a mind that changes with the wind?

We don’t ask the mind. We simply commit to one action. If we ever discuss this action with our mind, then we will get sucked into a negotiation with, or rather against, ourselves. This wastes a lot of energy.

Have you ever gone around in circles in your head wondering whether you really need to do the assignment now, or whether you can finish watching the movie on Netflix and then find time for it later? We all have.

It’s much easier if we say, from 8 to 10pm I do nothing but X. Until I do X I will not do Y. But once I do X I will reward myself with Y, and not get distracted by Z.

If it sounds like a lot of effort, I can promise you that it’s way less effort than having the same internal debate every few days and then beating yourself up for it later.

Commit once and save yourself the headache of constantly negotiating with yourself. This is the best way I’ve found to keep myself accountable, because I don’t need to keep checking in. I just check against one rule that is not up to my mind to decide.

DO Focus on the Insight Rather than the Implementation

This one is important for coders and is a little less meta than the other points.

Ultimately, most people reading this are looking to code professionally or for economic gain of some sort. It is easy to be in a hurry when progress has taken longer than you secretly wished, or planned for.

As a result, we tend to try and learn “tricks” and “shortcuts”. These are tactically useful as they will help us make some progress. But they also come at a cost – those shortcuts may not help us apply the principles to unfamiliar contexts.

For example, if you’re learning how to use recursion, it’s tempting to memorise the approach rather than build your mental intuition around it. But if you can’t see how the same technique can be used to solve other problems or a “class” of problems, then you’re missing out on the real power of the tool.

This can then catch up with you in interviews or at the workplace. In interviews, you may fail to recognise the underlying “class” of problems.

For example, when I was first teaching myself data structures I once failed to recognise a problem about HR reporting structures as a tree/graph traversal problem. That actually happened during a mock interview! I had practiced graph traversals and memorised implementations but hadn’t fully internalised the concept.

Similarly, without understanding concepts you cannot communicate effectively with team members or people who come to you to learn. This will set you back at the workplace because effective engineers need to communicate abstract concepts well.

At a more general level, adopting this “DO” means that you won’t fake it. It will force you to be patient and persistent in developing your understanding, rather than a hack around true comprehension.

No matter what skill you’re learning in life, having clarity of concepts is much more scalable than knowing just one implementation of the concept.

Conclusion

On a departing note – these are my top 5 Dos and Don’ts. If you make them yours I can guarantee that you will make progress, and come up with your own - that is extremely important as your own framework can only emerge from confidence and practice.

But having your own framework will make you a real weapon, because it’s reusable across any learning context.

I really hope that these lessons are of value to you. I truly believe that if one person can do it, I can too, and if you believe that, you will be able to do it, too.

Post Script

If you would like to learn more about my journey from lawyer to software engineer, check out episode 53 of the freeCodeCamp podcast and also Episode 207 of "Lessons from a Quitter". These provide the blueprint for my career change.

If you are interested in teaching yourself to code, changing careers and becoming a professional coder, or becoming your own technical co-founder, please reach out here. You can also check out my free webinar on Career Change to Code if that is what you're dreaming of.

When applying for jobs, everyone says they are passionate about coding and development. As a developer and hiring manager, what I'm looking for is evidence of that passion.

This week, I took a look at multiple CVs from people who were switching careers and looking for their first developer job. I spent around 2-5 minutes per person before deciding if they would make the cut.

That's not a lot of time to impress a stranger! Here's a shortlist of things I looked for:

• Regular commits on GitHub
• Personalised projects
• Evidence of good written communication

Regular commits on GitHub

What does your GitHub contribution history look like? If you are passionate about coding, then I assume you are coding regularly.

Once easy way to demonstrate this passion is to code publicly. Set up a repository on GitHub, learn about making atomic commits, and push them.

This gives employers a nice signal that you are coding every day, and that you really mean it when you say you are passionate about coding.

What I look for is a nice green chart. Let's look at this person's public contribution history on GitHub:

Example contribution history on GitHub

This person is coding publicly only during certain times of the year: November, December, March and July. I suspect these coincide with bootcamp projects, a.k.a. projects that were compulsory. When looking at candidates from the same bootcamp cohort, and every person has the same contribution graph, it's hard to stand out.

As an employer, it doesn't send a strong signal to me about passion. There are several months of the year which are empty.

This person may have been coding every day on her personal laptop, but as an employer, I have no way of seeing that and acknowledging that effort.

Let's look at another person's contribution history:

Almost daily contributions to GitHub

This person is making almost daily commits to GitHub. This is a very strong signal that she is interested in coding, and has been coding daily for the last twelve months.

This is fantastic, especially if she's not a coder by trade. I'd want to speak to this person and learn what she's been working on! Even if the bulk of her commits are text edits to a README.md file, it's still a great sign of commitment and consistency.

Personalised projects

Link to your projects, and make sure they shine!

Some ways to do this:

• Put in real content
• Inject it with your own personality. Find images that mean something to you.
• Take pride in your work: it doesn't need to be beautifully designed - I'm looking for an engineer, not a visual designer. But there's a basic level of care: do things overlap? Is there enough white space? Does it work on mobile as well as web?

Common pitfalls I noticed:

• No links to projects
• Putting up a bootcamp project with no personality, or with lorem ipsum. When I have CVs from 20 graduates from the same bootcamp, this gets old very quickly. It doesn't affirm the "I'm passionate" aspect if you haven't bothered to personalise your portfolio.
• Links to projects that no longer work. Make sure you get a friend to test it on a different device than yours.
• Links to projects that require setup. Make it easy for us! Have a great README.md file with the details on how to set it up. Put in lots of screenshots, UX flows, sequence diagrams, and so on. Chances are an employer will point and click, but I'd say it's highly unlikely an employer will download your project. So the screenshots, UX flows, and so on will need to demonstrate what your project does.

Looking for some "good" vs "bad" examples? I don't want to pick on anybody's work, so here's an example of one of my projects, with no personality:

My drum machine project

Look familiar? It's my drum machine project from the freeCodeCamp curriculum. I haven't personalised it at all. And what's worse - there are thousands of other people who have done this project, and made it MUCH cooler! I would never tell an employer to visit this project as a sign of my passion.

A different project from the freeCodeCamp curriculum is the personal portfolio. I spent much more time personalising this project. It's not perfect by any stretch of the imagination (it isn't responsive which really bugs me!), but it is uniquely mine.

My personal portfolio project

My portfolio also demonstrates another hidden pitfall listed above: links to broken projects. When I created this portfolio, my pomodoro timer looked beautiful.

What my pomodoro timer used to look like, with a nice background image

Fast forward a few years, and the stock image I was relying on is no longer available. So my live pomodoro timer looks a little on the sad side. It's not the end of the world, but it's definitely not putting my best foot forward. It tells employers that whilst I'm asking them to click on the link, I haven't bothered doing the same myself.

What my pomodoro timer looks like now - no images

Bottom line: if you tell an employer to click a link, then you should click it first and see if you're happy with it.

Evidence of good written communication skills

I would say that every tech job out there relies on written skills. There's the documentation in your code (although ideally your code is self-documenting). There's also Slack and pull requests as part of your every day job.

It's another easy dot point to include on CVs: "excellent communication skills". Every CV lists it. As an employer, I glaze over this point because it's difficult to assess through a CV.

However if you follow up this assertion with links to some well structured README.md files on GitHub, or online articles you authored, or your personal blog, then bingo!

As an employer, I'll definitely click on those links. They help me gauge what your personality is like, your communication style, the amount of detail and effort you put into structuring your thoughts, and so much more.

Below is an example of a rubbish README.md file of mine. I haven't put any effort into this file, so I wouldn't link to this project in my CV without first updating the README.md file.

However I would definitely put a link to some tutorials I've written on freeCodeCamp.

Wrapping up

As a career switcher, it can feel daunting to find your first dev job. Please stick with it! You bring a raft of transferrable skills with you.

I hope this article shows you it's within your own control to create a CV that stands out from the crowd, shows off your unique personality, and helps you land that first job.