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.

Hey everyone! 🌈 The seasons are changing, and September is the perfect month to focus on new goals and start new adventures. Maybe you've been on vacation, enjoyed the sun 🌞 or the mountains, and you're ready to dive back into work.

New adventures are sometimes unexpected. But I hope that when you saw the title of this blog post, you decided to embark with me on this extraordinary adventure of becoming a software engineer.

How Can You Learn to Code in 6 Months?

Learning to code is a marathon, not a 100m sprint. You need to become a lifelong learner, and the more you know, the longer will be the list of things that you feel the need to discover.

But (there's a but), if we're talking about changing careers, I think it's totally possible to become a Software Engineer (entry-level or junior) in 6 months or less. You just need to quickly acquire a good set of entry-level skills.

How do I know that it's possible?

Simple. I did it in 2017. And I'm not the only one. If you search for it, you'll find lots of people who've accomplished the same feat.

How to Learn to Web Development Basics Quickly

Now, to get this done in 6 months or less you need to be 100% dedicated to it.

So, this time frame will likely make sense for those who are jobless and have the resources to remain so while studying, or those who have quite a bit of free time. It's also helpful if you're looking for new opportunities and are passionate about tech, computers, and creating new things.

Spoiler alert: expect to invest somewhere around 8 to 12 hours per day learning and studying.

For those who have a job currently, but want to become a software engineer, just keep reading! You can apply this process over a longer time frame and gradually transition in over the course of 9, 12, 18 or even 24 months. No pressure at all.

How do I start learning to code?

This is a simple question. Despite the fact that there are lots of bootcamps out there – some paid, some free – freeCodeCamp is one of the best (if not the best) places to start.

The freeCodeCamp curriculum has a well defined roadmap (you can just follow the path, not worrying about what to learn and in which order) and a great, diverse, and inclusive community spread across Discord, the Forum, Twitter and YouTube.

So, start by signing-up for freeCodeCamp and get yourself comfortable.

Before that, make sure you grab a cup of your favourite tea or coffee! ☕

Start the freeCodeCamp Curriculum

Well, during the first four months, you need to focus on grokking the fundamentals. What you need to do is to invest heavily in the 3 first certifications:

1. Responsive Web Design Certification (300 hours)
2. JavaScript Algorithms and Data Structures Certification (300 hours)
3. Front End Development Libraries Certification (300 hours).

We're talking about 900 hours, which, divided by 10 hours/day, gives us 90 days of intensive study. Yes, intensive.

Of course it might take a bit more of time if you decide to invest 8 hours a day. 900 / 8 is more or less 113 days. So it still fits in 4 months.

My suggestion here is that you divide your time between tackling the challenges, reading, watching talks, and listening to podcasts or ebooks. This way you avoid getting frustrated or bored while always doing the same thing.

Follow freeCodeCamp's advice: "Read, Search, Ask".

This is the formula to success. You'll improve the way you search on Google, you'll discover interesting articles, talks, and books, and you'll eventually reach out for help somewhere online. Focus on this process. 🙏

Soon you'll be able to get yourself unstuck and this is one of the best skills a programmer can have.

Start Networking and Find Tech Communities to Join

The 5th month represents an inflection point in your journey. You'll need to raise your head up from the keyboard and look around.

Invest some time in networking. Create a LinkedIn and a Twitter account. Start building your social image and personal brand. State that you're learning to code and that soon you'll be looking for an entry-level/junior role in a tech company.

Interact with people, meet people, and ask questions (no matter how dumb they are. The truth is that there aren't any dumb questions, and once you know the answer, you might be able to help someone later with the same doubts).

If there's any tech-focused community group around you, mingle with the people and get to know them. If there isn't anything local, well, you can always create one.

That's what I did and it went great (maybe I'll write another article about it 💡).

At this point your basic tech stack is: HTML, CSS, JavaScript, and React. It will be pretty easy to fit in a lot of companies/teams as a front end developer.

The tech industry usually hires for the short-term, and nowadays frameworks are the dish of the day, so React skills can definitely help pay your first salary. 💰

You'll also need to invest in some other skills in the meanwhile:

1. Learn Git. Invest at least one week in trying to understand how Git and version control in general works and how valuable it is to work in a team, remotely or not.
2. Invest a bit of time in mastering your OS so that you feel comfortable while working. This involves VSCode config, terminal config, account config, and so on. Try to do online meetings with friends and share your screen or use a whiteboard. Google Meet is great to train you in this skill.
3. Learn a bit about note-taking and pick an app to help you manage your notes. Notion, Obsidian, or even VSCode are great tools for that. It doesn't need to be perfect, just start by organizing your notes somehow and later you'll find out what fits you the best.
4. If English is not your main language, sharpen your English skills. Read books and listen to talks and podcasts, so that you can get used to people's accents.

In the meantime, don't stop coding. This is the perfect time to polish up your certification projects.

At this point you should have the following projects done:

1. Responsive Web Design Projects

2. Tribute Page

3. Survey From
4. Product Landing Page
5. Technical Documentation Page

6. Personal Portfolio Webpage

7. JavaScript Algorithms and Data Structures Projects

8. Palindrome Checker

9. Roman Numeral Converter
10. Caesars Cipher
11. Telephone Number Validator

12. Cash Register

13. Front End Development Libraries Projects

14. Random Quote Machine

15. Markdown Previewer
16. Drum Machine
17. JavaScript Calculator
18. 25 + 5 Clock

Wow...you've already done so much! Take a few days to breathe and to treat yourself well. Recognize the achievements and how proud you are of yourself!

Show family and friends what you've been working on, and share it on your social networks. Everyone should be proud of you at this point.

Build Your Developer Portfolio

Okay folks. Now we're in the game.

Now you're going to build your portfolio. This is extremely important because the people and companies who might be interested in hiring you will want to check it out.

They're not necessarily looking for expertise, or for a very knowledgeable or experienced person. They're looking for passion, effort, knowing how far can you go alone, learning to code with some community support, on your own.

These are definitely the 3 things you must show:

1. Passion
2. Energy
3. Capacity (to evolve and learn "alone")

Move all your projects to GitHub, and make sure you add some good README.md files, with good descriptions about what you've done in each project. If you wish you can add a small list of things you want to improve in the near future.

But don't stop there – keep improving and polishing your projects. Put yourself in the shoes of the people who are hiring, and give some love to details that make the difference (this is how you can show the 3 things above: passion, energy, capacity).

Show that you know how to create good layouts, well-spaced content, the right colors, readable fonts, and so on. Make things look as great as you're able to.

Take a look at other projects and see how are people solving the same problems. Getting inspiration from their ideas (just please don't blindly copy code without understanding what it means) is not cheating and you can learn a lot by doing that.

Evolve your Personal Portfolio Project and make it your homepage (landing page). Make sure to share your contacts and to state that you're available for work. Share all your other projects in your homepage.

Keep polishing your work, keep coding and learning everyday, improve the relationships with all the new friends you've made, and try to find opportunities through social networks.

Apply for Jobs and Prepare for Interviews

You'll need to invest a lot of time in applying for jobs and getting interviews. You need to practice interviewing and I bet that soon, much sooner than you expect, magic will happen! 🪄

Applying for Jobs

Don't worry about failing. It's absolutely normal that you might fail your first interviews. And that's okay – you're learning some good tricks for the next ones.

Now, it depends a bit on what your goals are for this job and for your career. If you want to apply to a FAANG company, the bar is high (very, very, high). You'll need to pass hard technical interviews.

But no worries, freeCodeCamp has your back. You'll find a lot of resources so that you can sharpen your skills in the Coding Interview Prep Section.

If you're applying to any other company, you might not need to know quite as much about Algorithms and Data Structures. Rely on your portfolio and show the interviewer you're a confident person who is able to communicate, to show passion, and to put effort into whatever you do.

The Interview Experience

People have different opinions about what makes a good, effective interview. Personally I don't like timed or live coding challenges. My anxiety grows and my ability to focus and to solve problems drops to less than zero.

Plus, the best companies shouldn't be worried about how fast you're doing something. They usually prefer that you take twice as long, but do it that much better, making sure you think about each detail that a certain feature needs.

I usually prefer take home challenges. I can make myself comfortable, with a nice cup of tea or coffee, and I can investigate properly and do my best.

My recommendation here is that you go the extra mile. Care a lot about what you do and why you do it.

Write some documentation about why you've picked A or B, what's missing, or what you'd do in the future to improve your code.

Usually interviews have 3-4 parts:

• Screening: people want to get to know you. To hear you speaking and discover what's your superpower (motivation, resilience, perseverance)
• Test assignment: it can be a timed challenge, a pair-programming challenge where you're the driver (real time), or a take home assignment.
• Discussion of the assignment and a few technical questions. Possibly know how much you expect to earn.
• Offer / Rejection (this is usually a video call, in case they have an offer, or a simple "thank you" e-mail, in case you're rejected).

Sometimes there are interviews with more than one part of the team. Some teams like to pick people that fit well and they want to see if you're able to cope with them for a while.

Expect some off-the-wall questions, such as Star Wars trivia, or if you prefer tabs or spaces. There are usually no wrong answers, but people look for a sense of belonging while discussing these things with you.

The funniest thing that happened to me was a set of questions that I needed to answer quickly, without thinking. So the guys started:"React or Vue?", "Emacs or VS Code?", "Tabs or spaces? ", "Semi-colons or no semi-colons?", "Beer or wine?!?" Yeah, all these are important issues! 🤣

Final Words

If you get a job, don't forget to reach out to tell me how it went. I love to read these stories and I feel proud of every single person who did it.

Maybe 6 months wasn't enough time to get through this big list of things (even though, at first glance, they may seem pretty easy to accomplish – they aren't ❤️).

Just remember to treat yourself well and don't push yourself too hard.

Also, if it takes you longer than 6 months, don't worry: You can do it. You just might need more time for whatever reason.

When people start to learn how to code, they start in very different situations. Some have a PhD in Math or Engineering, some are coming from History or Philosophy, or from McDonalds (which also provides you with great soft skills: talking to people, being polite and kind, having compassion, being organized, doing things on time, tracking and controlling processes, and much more).

So whatever your background, just remember – it doesn't matter where you started. What matters is where you're going!

I'm sure that at this point, if you forget the 6 month time barrier, you will get there. And as I said in the beginning, learning to code isn't a 100m sprint, it's a marathon. So keep focused and keep doing your work.

Don't forget about your body! Drink water, don't spend too much time sitting in your chair. Try to have a good posture, exercise, and get out of your home. People need a bit of sun and fresh air. The way you treat your brain is very important. Never forget about this.

Last but not least, be kind to yourself and to every human being. You're great! ❤️

I'm Edo and you can follow me on Twitter. I usually tweet about code and career change.

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.

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.

I recently switched jobs. And during my long journey of finding a new one, I was offered way more money than I had anticipated for a role that I was not as passionate about.

I wish I could say that it was an easy no for me. But it was not. I wanted to say no. But instead, I kept asking myself, “Am I really going to do this?”

I even talked to quite a few close friends about my decision. And everybody, including my parents, told me that I was insane to decline that big offer. But I did it anyway. I ended up choosing passion over money.

This post is about how I landed myself in such a situation. And the things I considered while making the decision to say no. I'll also talk about my mental model and circumstances that allowed me to make this hard choice.

I had often wondered in the past who would turn down more money. But this journey made me introspect a lot more and figure out where I wanted to be.

Without further ado, let's get started with my story of choosing passion over money.

The beginning

Once upon a time…

Nah, this is not going to be a novel. I will try and keep it as concise as I can since there is a lot to cover.

First, some context: I was desperate. I had not been successful in my interviews so far, because I refused to memorize data structures and algorithm questions. Or maybe I wasn't as good of a programmer as I imagined myself to be.

Whatever the reason, when you have had so many rejections, you just start applying left, right, and center to any job opening you see. And that was what I was doing – if the title said engineer in it, I applied. I was not reading the job description to see if it matched my skill set or not.

And this company called me up and told me the technology stack they were using. I mentioned that I had no experience in that stack. But they were willing to train me on it if I cleared the interviews, since it was a proprietary technology and they were unable to find developers for it.

I went through the process and cleared the rounds. And once they made the offer, that's when the dilemma appeared.

They offered me a huge load of money, but I would be working on something I did not really like.

So here's what I considered that brought me clarity and helped me make my decision.

I was clear on what I wanted

After going through numerous interviews and being rejected by the FAANGM companies, I realized that I was not really interested in working at a larger company. I enjoyed building products from 0 to 90% rather than optimizing for the last 10%. That clarity was one of the critical things the process provided me.

With that clarity in mind, I knew what I wanted. More importantly, I knew what I did not want. I was able to prioritize working at a startup and choosing passion over money because of this conviction.

This thought process resulting from the interviews and my introspection played a crucial role in figuring out if I was going to go for the lucrative offer or not.

I liked building things as a software developer, but the technology stack was a proprietary for me – and these two things were at odds with one another.

If I accepted that lucrative offer, I would be stuck in that role and not like it in the long run because of the restrictions of the technology stack. So that was going to be a huge roadblock for me if I kept working at that job.

I had a safety net

I was lucky that my parents taught me the value of financial independence early on in my life. And thus, I was living debt-free.

This was probably the second – if not the first – factor in my decision. I knew that I had the resilience to survive even if I declined that offer.

I had also not been fired from my current role. I had my current job, which I could have continued working at without having much to worry about. I know that I could wait it out and try for a few more offers if I found something that I did like. And even if something else wasn't as big of an offer, I could still be content with it.

If I had been financially stuck, it would have been almost impossible to say no, and I would not have even written this post. But I had a backup and was stable enough to work through the situation and find something that I was passionate about instead of choosing the job based solely on the money.

I'm young and risk tolerant

I am in my late twenties and I'm a single person. Not having any family to look after except for my parents was a positive for me. I could experiment without a lot of external pressure of having people dependent on me.

And it is easier to work at a startup, building products, dedicating large amounts of time when you do not have any other commitments.

While I was somewhat in my comfort zone in my current role, I had the appetite to take the risk of working at a startup and leaving my comfort zone. I know it's often difficult for us to do that. But I knew that I valued work more than a comfy place, which drove me to take action.

I was not happy about my current stagnation, and joining a smaller company did not scare me because I knew my passion was around building things.

I was going for an open road, along for the ride, with a good number of upsides. And the risk was worth it. If things worked out quite nicely, which they have so far, I would still be working on things I liked. And that would make work and life, in general, more enjoyable.

I had self-confidence and I trusted my instincts

While choosing to work at a startup on a visa might have been a bit of a gamble, I was willing to risk it because I had the confidence of being able to get another job if I needed to.

I knew that I had the skillset for getting a job, and while it had taken me longer than I had anticipated to find a job in the United States, this might have been linked to my visa restrictions.

And if, for some reason, things did not work out, I was confident that I could find something back home in India. Or, if push came to shove, I could have ended up doing some freelance work.

I was looking for growth and learning opportunities.

Luckily, after talking to the people at the startup I ended up joining, I knew it was the right choice for me. The team are amazing, and the technology stack was what I wanted to work on as well.

I decided to trust my instincts and have been working here for almost a month – and I'm happy that I made that choice. I already have learned a ton of things, and still love working with everyone around me, which is an invaluable feeling.

I had the motivation to make a change

While some people love living a lavish life and spending money, that is not my life’s aspiration. I have spent a lot of time with myself figuring out what motivates me and what my priorities are.

If you ask me what I want to be doing in the next 5 years, I still do not have an answer for that. But I have dug a bit deeper into myself to know what I don't want to be doing. Thinking from first principles made this choice easier just because I had thought it through.

I would rather have a meaningful life and work on something I love than aimlessly gather money. You might be someone who wants more money in life. And there is nothing wrong with that – who am I to judge what you like or want or need?

Go and live life on your terms. It is your life, and this is mine.

Wrapping up

These were my reasons for choosing passion over money. I wanted to write this post down not to say that I am cool. It took a crazy amount of courage to do it. And it was scarier because I was unsure of what kind of offers I would get in the future.

And I did take a salary hike when I switched jobs. It was not as huge as the lucrative offer, but it was still an incremental improvement. In the end, I wanted to enjoy the work I was doing, and it led me towards choosing passion over money.

I hope that this post provides some context to someone who might be stuck in the same dilemma as I was.

Read more of my posts at: https://www.wisdomgeek.com

Cover letters, like résumés, are hard. And most people are bad at them.

This makes sense – you probably only write a cover letter or résumé every few years. It involves selling yourself and your skills, which is something most people struggle with.

On top of this, it's difficult to sort through all the advice on the internet and figure out what's actually worth following.

In this article I'll go over some common reasons why your cover letter probably isn't that great, along with my top 10 ways to improve your cover letter and stand out from the crowd.

Why Your Cover Letter Needs Work

People rarely think that their cover letter is the problem, even if they've been struggling to get interviews. They'll often say something like, "But I've had tons of people review it and they all say it's okay!"

There are a couple of problems with this.

First, you want your cover letter to be better than okay – in order to stand out in an extremely competitive job market, it needs to be stellar.

Second, most people don't know how to write a good cover letter, and therefore they can't help identify the problems with yours.

It's often hard for reviewers to provide constructive criticism for fear of hurting someone's feelings. What you really need someone who has a lot of experience hiring or recruiting in your specific field in order to receive accurate advice.

My Top 10 Tips for Improving your cover letter

As someone who has reviewed a lot of cover letters (good and bad), here's a few of the most important things to keep in mind.

Stop Reusing the Same Cover Letter

You should write a personalized cover letter for jobs you care about.

Cover letters are a way that you can stand out from your competition and show the organization why you're interested in working for them. This is more important to some organizations than others (FAANG typically doesn't care), but a great cover letter will never hurt your chances of being hired.

It can also be a helpful exercise for you – it gives you the chance to think about and articulate why you're interested in working for this company – so when you're asked in an interview, "Why this organization?" you have an answer readily available.

Don't Follow Outdated Templates

You can skip listing your address or your employers at the top.

Instead, treat it like an email, and start the letter simply with "Dear Hiring Manager". Don't worry about hunting down a specific person to address your letter to, unless you already know it.

You also don't need to struggle for creativity for an opening line. Stick to the basics such as "I'm interested in X" or "I'm writing about Y position".

Tell the Company Why You Want to Work for Them

Do you like the company culture and values? Do you think the work they're doing is interesting?

Give them a specific reason that you're interested in working for them at the start.

Also, let them know how you found them. Did you read a company blog about interesting research they're doing? Did you see that they deeply value philanthropy and encourage all employees to get involved in a range of volunteer efforts?

However you found out about them, make sure to include it in your letter.

Interviewing and hiring people is extremely expensive and time-consuming for an organization. Companies would prefer to invest that time and effort into people who are truly interested in working for their organization (and are therefore likely to accept an offer that is made), not any generic company.

If you can show an organization that you're deeply interested in working for them, it will likely increase your chances of being interviewed.

A good litmus test for this is to ask yourself, "if I changed the company's name and the name of the job, could I send this cover letter to a different company?"

If the answer is yes, you need to re-write your cover letter.

Communicate Why They Should Hire You Instead of Another Candidate

Don't just summarize your resume.

They have your resume. They know what it says.

This is a chance for you to tell the potential employer who you are as a person and why you would be a great fit for the job.

Have you received great compliments on your work from past coworkers and bosses? Can you confidently say, "I am the go-to person for all things X"? Mention it here!

For example, are you so passionate about networking that you read the Illustrated TCP/IP guide on the beach? Write about it! Did you spend weekends working on a cool app idea you had? Talk about it!

A lot of this section is context dependent – ideally you should have a sense of the culture of the employer and base the stories you offer on this. But in general, you can treat cover letters as a conversation.

Be Specific

You want to tell the company how you can solve problems they currently face.

Use examples of how you solved problems at your previous job to show how you'll be helpful to this organization.

It's very important to show this with specific examples, rather than simply tell them. This makes your claims more reliable and easier for an employer to picture.

It's much less effective to say, "I am a flexible problem solver, with great attention to detail and an ability to manage complex code pipelines."

Instead, it's much better to write, "In addition to being extremely adaptable, I recently migrated my organization's code release process entirely to AWS, where I was able to implement a continuous CI/CD pipeline. This resulted in the organization moving from 1 release per week to daily releases, with fewer reported problems, and 10% improved developer satisfaction reports. I apply the same level of dedication and focus to all projects I am assigned, from code reviews to major project overhauls."

One of these is significantly more believable, and shows, rather than tells, a prospective employer about your abilities.

Ensure Your Cover Letter Sounds Like You

This doesn't mean that the cover letter should sound exactly the way you talk. But it should still sound like your voice.

If the letter is full of statements such as, "If you are looking for a hard-working, dedicated sales engineer with team spirit," it probably doesn't sound like you.

The people you're sending your cover letter to are real people. Often, they were in your position just a few years ago, and if you're hired they're going to be your coworkers.

Think of them that way, and write the cover letter as though you're describing to a coworker why you're the perfect fit for the position.

Keep It to One Page

Don't make your cover letter longer than a page.

If it's longer than a single page, you've written too much. If you're looking for things to cut - think about the points above.

Was anything you're writing about covered in your resume? Remove it. Are there meaningless phrases like "If you are looking for a hard-working, dedicated sales engineer with team spirit,"? Remove them. Keep it simple and tell a story about why you would be a great fit for this job, on this team, at this company.

Think of this as your 'elevator pitch' where you practice refining your story for an interview. You can use a modified version of this story when you get the dreaded 'tell me about yourself' request in an interview.

Explain Any Inconsistencies

If you've previously only had jobs doing one thing and are now applying for jobs doing something totally different, you need a clear and convincing explanation why you would be good at the job.

Employers often receive hundreds, if not thousands of resumes for a single position. They need a fast, easy way to sort through the resumes in order to decide who they want to give interviews.

If they sense anything wrong, like someone who is over or under qualified or has no experience in the field, they're likely to simply toss it in the "no" pile.

It's your job to convince the employer that you would be great at the job with your application materials. This is particularly relevant if you're attempting to change careers or coming from a self-taught or bootcamp background.

That doesn't mean you can't apply for those jobs (plenty of self-taught developers have successfully changed careers!), but it does make it a little harder.

You need to clearly show to employers why you're qualified with an excellent cover letter and a resume which highlights projects you've done and transferable skills from previous jobs.

Proofread Everything

Read your cover letter. Then read it again.

If you struggle with grammar and spelling, or English isn't your first language, check out Grammarly. It's free and will help you identify changes you should make to your writing.

If you can, ask a friend who got great grades in English to help you out. If your cover letter or resume is difficult to read due to spelling and grammatical mistakes, the focus won't be on your achievements.

Plus, communication is a big part of any job no matter how technical, and your application is a place to showcase your communication skills.

Since you've had essentially unlimited time to write and review your resume, cover letter, and application, it's expected that they will be free from grammatical mistakes or spelling errors.

Send Your Cover Letter The Right Way

When sending your application to a company, your cover letter should be in the body of your application email. Don't send an empty email with two attachments to the hiring manager.

Also, use a professional email address! Something like firstname.lastname@emailprovider.com is fine.

University addresses are also fine, though after you have been out of university for a few years, it's probably a good idea to update it.

Something like fantasydude@yahoo.com is not.

Looking for more advice about how to write the perfect cover letter? Check out these resources:

• The Developer Cover Letter
• Joel on Software: Getting Your Resume Read
• Sorting Resumes
• You Need to Write a Better Cover Letter
• Sample Cover Letter
• Another Sample Cover Letter

How I Learned to Code and Got My First Job

My coding journey began about two and a half years ago, and I started working my first full-time developer job recently (wooo!). This might seem like a long time for some of you, but I didn't rush it and wasn't trying to find work until two months ago. Many people have done it more quickly and I was probably ready for a while. So I've decided to share my story, my resources, and what worked for me when learning web development.

How I got interested in coding

I was living in Thailand, training and fighting Muay Thai while working about 10 hours a week as a social media manager. I wasn't really enjoying marketing as a career and it wasn't as flexible as I wished, since I needed to be active at certain hours of the day.

Luckily I had the time to learn something new. I'd looked at a few things online which sounded like good skills to have that were flexible and that could be done remotely. But it wasn't until I met a guy traveling through Vietnam, who was working as a web developer, that I was intrigued and started to play around a little bit with coding.

Where To Learn?

At first, I was jumping around trying out different sites such as Codecademy, freeCodeCamp, and others I can't recall. I never really got anywhere with these to start with but they got me interested.

After researching, I decided to take CS50 - Introduction To Computer Science, a famous Harvard course run by David Malan. It teaches the real basics of computer science such as data structures, algorithms, and the relevant workings of a computer. This is all done in C but the basics you learn and the confidence you build apply to every language.

Once I completed CS50 I started on freeCodeCamp. What I loved about freeCodeCamp most was the projects. They give you great ideas to practice and test your skills as you are learning. Once I got through the first couple of sections on HTML/CSS/JavaScript and onto more advanced topics, I didn't find the lessons thorough enough. So I ditched them for Udemy courses which went more in depth on a topic. Then I could go back and build the freeCodeCamp projects for practice.

I used this combination of Udemy and freeCodeCamp until I had a solid grasp of HTML, CSS, JavaScript, Node, React, and Redux. I also completed all of the projects on freeCodeCamp except for the data visualisation section using D3.js, as I didn't find this skill in demand when looking at jobs.

What Next?

Although I was confident in these skills, I still hadn't gotten involved in open source except for a couple of tiny pull requests. I simply didn't know where to get started. Every time I looked at issues I couldn't see anything interesting. Or those that were interesting had already been claimed by someone else.

Eventually, I got involved with freeCodeCamp as a contributor. I would recommend just making a habit of checking the issues once a week or so to see if there's something that you want to help with.

Along with my work with open source, I also got an internship as a front-end developer focused on React. It wasn't the ideal internship but it was remote and I learned a lot by working on a codebase someone else had built. I was the only dev on the front-end. This presented it's own challenges, like being given a problem and being responsible for researching and solving it. In this time, I learned about and implemented internationalisation as well as React Native.

Getting the Job

I had a strong mix of skills, projects and experience to show off, my résumé in hand, and a portfolio site promoting my work. I was ready!

Getting the job was mostly a game of patience. All together it took me 2 months of searching and applying every day to jobs. Most of the time I didn't hear back. I applied for a lot of jobs which were looking for mid level developers or more experience than I had, which didn't work out. Most of the jobs I found on job boards were advertised by recruiters and I found these the most fruitful. I often received a call and meeting with recruiters who were impressed by my résumé and skills and were looking for junior roles for me.

I was also attending meetups to network and look for jobs. I didn't find any roles directly, as the companies weren't looking for juniors. However, I did meet a recruiter at a React meetup whom I grabbed coffee with the next week. He had a role from a company that was open to juniors and this is where I ended up accepting a position.

The hiring process for this position consisted of a tech test (https://github.com/GlynL/tech-test-prendi), and then an interview where I was actually offered the job at the end. It's a great small company where I'm working with the senior developer and can bounce ideas and get help when I need it. It's a full-stack job, I get to use React daily, and I will get the chance to work with a lot of technologies as projects require them.

When I was interviewing, the thing that people appreciated most was that I had worked on a real application in an internship. Even if I could have done everything in a personal project it proved that I could work on a real world application with other people. I would certainly recommend seeking out internships as this will look great on your résumé and will be a talking point during interviews.

What would I do differently?

If I were to do it all over again, there's a couple of things I would do differently.

For starters, I would get more involved with open source projects much earlier on. There's always something you can contribute to a project even if you are still learning HTML and CSS. You may have to be more particular about the issues you pick up but you can definitely help! The skills you gain in navigating a large codebase and working with others are invaluable. And as you learn more you can pick more complex issues to match your skills.

Secondly, I would also start networking earlier as this might've led to securing internships and/or junior positions. If people know you are searching for an opportunity then they will think of you when they have something. Or it'll at least give you an advantage in the application process as they will know who you are and that you have a genuine interest in the field.

Please feel free to let me know if you have any questions or would like me to elaborate on any of the points. I'd be happy to help!

You can contact and connect with me on Twitter @glynwebdev.

You read the title right! I was offered a development position with a company and after some negotiating I accepted their very generous offer!

I am beyond blown away, excited, happy, and (if I'm being 100% honest) terrified - in a good way though. I'm still in disbelief that this is really happening but ecstatic to start working on production code.

I've had a lot of people ask me to distill my journey into an article to share and help others. So, buckle up because here we go.

Getting Started

I've always been interested in computers, tech, etc. Like many people my age, I got to 'cut my teeth' with development by creating a GeoCities site and later by personalizing my MySpace page with some basic CSS.

I didn't know it at the time but this was development, a crude version of it but still development nonetheless. At that time, I didn't know that people would pay for this kind of work or I might have stuck with it. So, I went to college and got a degree in nothing tech related - psychology. Not a useless degree, but one I ultimately never put into professional use.

Finding My Calling

Fast forward to the summer time in 2016 where I found myself with an abundance of free time on my hands outside of work. I had always wanted to teach myself to code/program and decided now was the time - no more delay. With the amount of free and accessible resources online to teach myself how to code it was the perfect time to jump in.

I started by searching for resources and came across Codecademy. I took handwritten notes by copying the entire question, answer, and result into a notebook. I wrote down everything thinking that I would need it. I came back to these notes from time to time to review them. It's also interesting to look back on them and compare what I considered difficult then to what I consider difficult now. ?

A friend introduced me to freeCodeCamp because he knew I was self teaching and told me this platform was built for people like me. I had planned to check it out, maybe do one or two lessons and then go to bed. I finished the entire section on HTML that night! I was hooked.

The more I learned the more questions I had. I felt this urge, this pull to find answers to those questions. So I continued on working through the lessons and projects. I finished 2 projects before the curriculum was overhauled and revamped on freeCodeCamp.

I was finding any excuse to learn and work on projects. While I was standing in any line waiting for something I would pull out my phone and instead of looking at social media, I began to read web development articles or watch a development related video.

I feel like this was a major shift in the way I viewed downtime as compared to previously where "mindless consumption" ruled my time. _(_If you enjoy social media or funny animal videos I'm not calling you mindless, I'm simply saying that type of consumption typically doesn't require you to be engaged. It's the type of consumption that you can do on auto pilot and frankly I still do it from time to time.)

During that time I had bounced around the various different sources and was like a kid in a candy store. At one point I had a folder that had roughly 300 links to material I had planned to work through. I now know that finding a resource and sticking with it is far better than hoping from one resource to another.

I was doing all of this at night when my wife and daughter were asleep. I was staying up until 12:30 AM sometimes as late as 2:00 AM and then having to get up at 6:00AM to do my normal day job. At first, when the topics weren't as mentally taxing this was not an issue. But as I started moving into JavaScript, learning the basics of networking, servers, accessibility, etc I noticed that the later it got, the more difficult it became to keep my brain engaged.

Needless to say, this routine only lasted a few months before having to change it.

I didn't want to stop working on projects/learning but I needed to alter my schedule in order to benefit my well being. That's when I decided to go to the other end of the work day spectrum.

I started getting up at 4:00 AM, instead of staying up late, to learn and work on projects before going to the gym then starting my day. I must say, this was a pivotal moment in my journey because I started to retain more of the information I was learning and that ultimately helped me move forward with more projects/material.

Also, this is the time when I started to buy up every resource I could find (Udemy courses and books mostly) dealing with any aspect of web development. I can tell you that this isn't a wise (or financially sound) choice to make. If you find a resource you like and that you're learning from then stick with that resource until it's exhausted. The last thing you want to be doing is jumping to the new resource each time you find one like I did.

Grow With Google & Udacity Scholarship

The image that came with my acceptance e-mail

In January 2018 I applied for and was awarded a scholarship to Udacity's Front-End Nanodegree program. This was not only an awesome opportunity to help propel me towards my goal but a humbling experience as well.

I came into this program with a basic knowledge of HTML, CSS, and a small portion of JavaScript in the vanilla flavor. In this course I was introduced to jQuery, functional programming, object-oriented programming (OOP), test driven development (TDD), accessibility, servers, API's, basic networking, React, AJAX, and so many more facets of web development that I hadn't previously been exposed to.

I'll be honest, it wasn't always easy or fun and there were times I seriously considered dropping out. I felt like I would never learn these concepts and that I was in over my head.

I'm happy that I didn't quit because no one ever accomplished their goals by quitting - first and only cliche statement I promise :D

I had the chance to build many awesome projects like the Card Matching Game, Arcade Game Replica, Restaurant Review App, and the Neighborhood Map App. More than the projects though, I got to meet many great people and valuable experience collaborating with other developers in the course.

Without this course, I can truly and honestly say that I would not be where I am today. I gained many valuable experiences and lessons in this 9 month course.

Job Hunting...dun dun duuuuunnn!

_Photo by [Unsplash](https://unsplash.com/@sxoxm?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Sven Mieke on <a href="https://unsplash.com/search/photos/job-search?utm_source=unsplash&utm_medium=referral&utmcontent=creditCopyText)

At this point I had been working diligently (sometimes slacking off as well) for about two years. I did not feel as though I was job ready but a friend who became my mentor told me that I'll never feel ready. He said that I should apply and if I get interviews then let them tell me I'm not ready if that's the case but to not exclude myself from an opportunity.

So, with a metric ton of fear, anxiety, and doubt I decided to start applying for jobs.

At first, I was only applying for jobs where I met the majority of the qualifications. I can tell you now that this is not the way to do it, however, at the time I was terrified that someone would actually call me about an interview. (Later down the road I was applying for anything that interested me. Senior developer - sure, I applied for that. Front-end ninja with React skills - yep, threw in an application for that as well. API developer with SQL experience - oh yeah! I applied for that one as well. I did this because you never know what will come of your application. Maybe you don't get hired for that senior role but maybe they like you and your personality so much that they ask you to interview for their junior role.)

That's exactly what happened after I'd been applying for about 3 months. I got a call for my first interview! I was so happy and scared at the same time. Now the pressure was really on.

I read articles, brushed up on my interviewing skills, read books, asked my wife to quiz me on topics, and tried to run through different scenarios that I thought would come up in the interview. I also prepared questions for interviewer because I wanted to know what it was like to work at this company.

Ultimately, I did what I wasn't supposed to do; I convinced myself that this was the perfect job and I wanted it. I wanted it more than anything I could ever remember wanting. I built it up as something that I had to have.

The day of the interview came and to say I was nervous is an understatement. I was sweating bullets. I answered all of the questions and when it was my turn I asked the questions I had prepared. After it was over I left feeling like the interview went well.

Ultimately, I didn't get the position and I was crushed. I felt like everything went like it should have but for some reason the stars just didn't align. Little did I know that this would be a common pattern among my interviews.

I decided not to let these disappointments define or destroy my confidence. I started working harder, learning more, using that disappointment I felt to fuel my passion. I would do whatever it took to ensure that one of these interviews would end with a full time offer.

Here are some metrics about my job search:

• Applications submitted across all platforms: 271
• Any form of contact from company after application: 28
• Phone Interviews: 7
• In person interviews: 8
• Job offers: 3 (one was contract with the (small) possibility for full time, one a part time freelance gig, and the eventual offer that I took for a full time position
• Companies that ignored me after expressing interest: Too many to count

If you are applying for jobs, in any field, don't let the numbers discourage you! Yes it is disheartening, yes it can be daunting, yes it stinks to fill out an application and never hear anything back, but don't quit! You can do this! I'm proof!

My Advice on Your Job Search

This is by no means an exhaustive list of tips/tricks but below are some pieces of advice I've picked up along my journey to getting a job in development:

• Develop thick skin - it's a must! Companies will disappoint you
• Apply for anything you're interested in
• Apply even if you don't meet all of the requirements (this is what I did and also how I landed my first developer job)
• Spend time perfecting your resume
• Just because companies turn you down doesn't mean you're a failure
• Show companies you can do the work by building projects outside of tutorials
• Ask for help if you need it (this was a hard one for me to learn)
• Apply for jobs on all of the major platforms but don't forget that platforms like GitHub jobs also exist
• Ensure you take care of yourself - get enough sleep, exercise, eat healthy (it's important for overall health!)
• Don't be afraid to take breaks
• Don't compare yourself, your job search, your situation, or your skills to others
• If it takes you 3 months or 3 years (like me) remember, this is not a race
• Work hard, learn well, and never give up!

As always, I wish you nothing but the best in all you do. If you need advice or help I'd be glad to do what I can. Connect with me on Twitter or LinkedIn. I'm always willing to help and I love meeting new people!

I also run a personal blog where I write articles related to web development. While you're there consider signing up for my newsletter that I send out once a month with articles and great finds from around the web.

Have an amazing day and happy coding!