freeCodeCamp Podcast (freeCodeCamp.org)

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Gary Simon, a developer and designer who started DesignCourse.com and has published several courses on freeCodeCamp.org over the years.

We talk about:
- Growing up in rural Ohio, marrying young, and staying out there despite his success as a developer and entrepreneur.
- Early client work, and how he designed thousands of logos for clients before becoming an all-out web developer.
- Using his skills to help his wife start her own lactation consultant business online
- Gary's guitar shredding chops.

I recorded this podcast live and I haven't edited it at all. I want to capture the feel of a real live conversation, with all the human quirks that entails.

Can you guess what song I'm playing on my bass during the intro? It's from a 1995s Nintendo game.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

Also, I want to thank the 9,331 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during the interview:

- Gary's Learn UI Fundamentals course on freeCodeCamp: https://www.freecodecamp.org/news/learn-ui-design-fundamentals-with-this-free-one-hour-course/

- Gary's freeCodeCamp live stream series: https://www.freecodecamp.org/news/design-course/

- Gary's tool for memorizing the Guitar fretboard and it's 49 notes: https://fretastic.com/

- Gary's Retrowave Guitar music video: https://www.youtube.com/watch?v=yDc2OvReYh0

Abbey Rennemeyer interviews Erica Peterson, the founder of Moms Can: Code and Science Tots, and Founder Gym alumna. 

Erica started her career in biology, but after being told that she should leave her graduate program once she became pregnant with her first child, she started to look for other options.

Three years ago, inspired by her desire to understand how her children were learning, she founded Science Tots, a non-profit that helps introduce children to the world of STEM.

And just over a year ago, Erica founded Moms Can: Code, an organization that helps mothers learn to code so they can both support their children's learning and open new doors for themselves.

In 2018, Erica has been a South By Southwest accelerator pitch finalist, Project Entrepreneur finalist, and Startup of the Year semifinalist - so it's been a busy year for her!

Erica is extremely active in her local community, and spends a great deal of her time helping people learn. Today, she'll tell us all about how she got into the tech world, how and why she became a founder, and why being a mom who codes is so awesome.

Interview by Abbey Rennemeyer: https://twitter.com/abbeyrenn

Erica Peterson on Twitter: https://twitter.com/foundermama

Moms Can: Code website: https://www.momscancode.com/

Intro music by Vangough: https://fcc.im/2APOG02

today I'm joined by Brian Douglas. He's a software engineer who's worked at tech companies like GitHub and Netlify. And now he's an entrepreur runs his own startup – OpenSauced.pizza.

Brian grew up in a small town in Florida, and his family was the only black family in town. He worked hard in school and earned a full scholarship to Florida State University, where he studied business.

He started off working in sales, but gradually taught himself how to code. It took a while to get into the software, but he was ultimately able to move his family out to the San Francisco Bay Area.

If you dig this podcast, be sure to leave us a review. And tell your friends.

Follow Brian Douglas on Twitter: https://twitter.com/bdougieYO

And check out his open source tool: https://opensauced.pizza

On today's episode, Quincy Larson interviews Ali Spittel. She's a Washington DC-based developer and artist.

Ali runs the popular Zen of Programming blog, where she writes about design, data visualization, and other programming topics.

She talks about how her interests in political journalism lead to a passion for data and data journalism.

Ali also talks about her love of Python. She reads the poem "The Zen of Python" and talks about how it has influenced her programming style and her way of thinking about software development.

Interview by Quincy Larson: https://twitter.com/ossia

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Hiroko Nishimura. She's a special ed teacher turned system administrator turned technical instructor. 

Hiroko grew up in Japan and moved to the US as a kid. In her early 20s, she was diagnosed with a vascular tumor in her brain. After life-saving surgery, she had to work to regain the ability to walk and talk. She still lives with disabilities to this day. 

Despite this, she's gone on to author technical books, become an AWS hero, and create the popular AWS Newbies community. More than 500,000 people have taken her LinkedIn Learning course.

We talk about:

- How Hiroko moved to the US as a kid and learned English and American culture

- Hiroko's vascular tumor diagnosis, and how she recovered from brain surgery and brain damage

- Her big move to NYC and her years working as a system administrator and ultimately cloud engineer there

- How she made the jump to teaching system administration full-time as a course creator

Can you guess what song I'm playing on my bass during the intro? It's from a 1990 song by a Scottish rock band.

Also, I want to thank the 10,443 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during our conversation:

- Hiroko’s article about her brain surgery: https://hiroko.io/my-words/

- Hiroko's book AWS for non-engineers: https://www.manning.com/books/aws-for-non-engineers

- Hiroko's AWS course: https://introtoaws.com

- And her AWS linktree: https://aws.hiroko.io 

- My history of the 100DaysOfCode challenge: https://www.freecodecamp.org/news/the-crazy-history-of-the-100daysofcode-challenge-and-why-you-should-try-it-for-2018-6c89a76e298d/

On this week's episode of the podcast, I interview Logan Kilpatric, a software engineer and ChatGPT creator Open AI's first-ever Developer Advocate hire. The week Logan started, ChatGPT hit 1 million users. (It now has 180 million monthly users.)

During our conversation, Logan shares his journey from Illinois to Harvard, NASA, and now the world's most-watched tech company, Open AI. Along the way, he joined the board of NumFOCUS, which oversees Data Science Python libraries like NumPy, Pandas, and Matplotlib.

This is my long, intimate conversation with an emerging star in the AI and Machine Learning world. Logan is also a prolific freeCodeCamp.org contributor. It was a blast talking with Logan for nearly two hours. I think you'll dig it.

You can follow Logan on Twitter: https://twitter.com/OfficialLoganK

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Andrew Brown, a CTO-turned co-founder of ExamPro.co.

Andrew created this cloud certification exam prep website with another Andrew – also from Canada, who also loves Star Trek.

We talk about Andrew's early career fixing computers in the 90s, and his early freelance web development work. These ultimately lead to jobs and promotions that leveled him up to CTO.

Andrew also shares his advice to devs who want to learn DevOps and Cloud Engineering, and which certs to prioritize.

Andrew suffers from Muscle Tension Dysphonia, a disease that causes voice loss. He shares how he's using AI tools to get around this.

Andrew also talks about his love of Tetris Attack (also known as Panel de Pon or Pokémon Puzzle League). He built a frame-perfect port for competitive online play.

And of course, Andrew's favorite Star Trek episodes of all time.

Can you guess what bass line I'm playing on my bass during the intro? It's the theme from a 90s cartoon.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

Also, I want to thank the 8,933 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during the interview:

Just a few of Andrew's many freeCodeCamp cloud cert prep courses. (He has dozens more on freeCodeCamp's YouTube channel): https://www.freecodecamp.org/news/author/andrew/

His website, ExamPro.co: https://www.exampro.co/

American Mall simulator browser game by Bloomberg: https://www.bloomberg.com/features/american-mall-game/

The Greatest Generation podcast: https://maximumfun.org/podcasts/greatest-generation/

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Daniel Bourke. He's a Machine Learning Engineer and creator of many popular tutorials on YouTube. He's also a frequent freeCodeCamp contributor.

We talk about:

- How as a kid he hacked into his school's network and gave himself good grades, just like the kid from Wargames. (Don't try this at home.)

- What he learned from helping fix 5,000 people's computers

- How Machine Learning actually works. What the AI models are actually doing for you in the background.

- His advice for anyone getting into Machine Learning in 2024, in terms of what to prioritize learning

Can you guess what song I'm playing on my bass during the intro? It's from a 2020 song by an Australian musician.

Also, I want to thank the 9,779 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during our conversation:

Daniel's 26-hour PyTorch course on freeCodeCamp: https://www.freecodecamp.org/news/learn-pytorch-for-deep-learning-in-day/

Nutrify, Daniel's "pokedex for food". Uses computer vision to map photos of food to nutrition data: https://www.youtube.com/watch?v=-jpLqtAWKfo

Daniel's Charles Bukowski-inspired novel "Charlie Walks": https://www.charliewalks.com/

The research website Daniel mentions: https://arxiv.org/

Daniel on Twitter: https://twitter.com/mrdbourke

Today I'm joined by Patrick San Juan, a software engineer who first learned to code in his 30s.

I've known Patrick since the early days of freeCodeCamp. He has always been a positive, supportive force within the community.

Patrick grew up the son of first-generation immigrants from the Philippines. His family didn't have much money, and what they did have, they plowed into his education. He studied economics at the University of California at Santa Cruz, then went to work at a charity focused on helping underserved youth.

After 5 years, Patrick decided to transition into a career where he could better support his family. And for him, that meant learning to code.

I hung out with Patrick at the Alameda Public Library, in the San Francisco Bay Area where Patrick lives. We talk about the ups and downs of his journey into tech. Patrick doesn't sugarcoat anything. Getting a job as a developer is hard. But he's proof that with sustained effort, you can build a career for yourself in tech.

I'm proud of Patrick and his achievements. And I'm proud to be the first person to ever interview him for a podcast.

If you dig this podcast, be sure to leave us a review. And tell your friends about this show. Let's inspire more folks to learn to code and build careers for themsleves in tech.

Patrick on LinkedIn: https://www.linkedin.com/in/patricksanjuan/
 

This is it – my full FREE 2023 book in audiobook format. How to Learn to Code and Get a Developer Job. Written, read, edited, mixed, and mastered by me, Quincy Larson.

The text version of the book (also free): https://www.freecodecamp.org/news/learn-to-code-book/

Table of Contents:

Preface: Who is this book for?

500 Word Executive Summary

Chapter 1: How to Build Your Skills

Chapter 2: How to Build Your Network

Chapter 3: How to Build Your Reputation

Chapter 4: How to Get Paid to Code – Freelance Clients and the Job Search

Chapter 5: How to Succeed in Your First Developer Job

Epilogue: You Can Do This

Song "From the Ground Up" by Quincy Larson from the Learn to Code RPG Original Soundtrack: https://www.youtube.com/watch?v=8TDsGUFFXSY

Additional Reading:

Article: How to Contribute to Open Source: https://www.freecodecamp.org/news/how-to-contribute-to-open-source-projects-beginners-guide/

Article: We fired our top talent. Best decision we ever made: https://www.freecodecamp.org/news/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde/

Article: How to negotiate your developer job offer salary: https://www.freecodecamp.org/news/salary-negotiation-how-not-to-set-a-bunch-of-money-on-fire-605aabbaf84b/

Article: How to ask for a raise as a developer: https://www.freecodecamp.org/news/youre-underpaid-here-s-how-you-can-get-the-pay-raise-you-deserve-fafcf52956d6/

Article: Why recruiters are an underrated tool in your toolbox: https://www.freecodecamp.org/news/the-tech-recruiter-red-pill-967dd492560c/

Welcome back to the freeCodeCamp Podcast.

I'm Quincy Larson, teacher and founder of freeCodeCamp.org. And I'm bringing you insight from developers, entrepreneurs, and ambitious people getting into tech.

It's been 4 years since we published a podcast episode. It's good to be back.

This is the first of three interviews I'm publishing this week – my interview with Danny Thompson. Danny's a bit a legend among career changers. 

He had a kid early in life. For 10 years he worked at a gas station in Tennessee, frying chicken for people to eat. He sometimes worked 80 hour weeks just to provide for his family.

And yet, Danny had ambition. He taught himself to code using freeCodeCamp. He built his network through local tech events. And eventually, he landed his first job as as software developer. 

Danny's since worked at tech companies like Google and Front Door, and he's now a software engineer at AutoZone, a major US retail chain.

Danny has helped so many people along the way. He's developed a free course on how to leverage LinkedIn as a developer. And he's helped start a ton of local developer meetups.

I couldn't dream of a better interview to kick off this new season of the freeCodeCamp podcast.

New season. That's right. I've got dozen interviews lined up, and I'm recording these all in-person, in public libraries across Dallas, San Francisco, and New York City.

I'm publishing 3 episodes this week, and then a new episode every Friday.

We're talking about DevOps, cybersecurity, AI – tons of topics that I know you're gonna find helpful as you continue to expand your skills.

If you dig this podcast, be sure to leave us a review. And tell your friends.

Danny on Twitter: https://twitter.com/DThompsonDev

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews prolific programming teacher John Smilga. John grew up in the Soviet Union. He worked construction for 5 years before becoming a developer. Today he has taught millions of fellow devs through his many courses on freeCodeCamp.

John spent his childhood in Latvia before the Soviet Union fell. He sought work in the UK as an expat hospitality worker on the tiny island of Guernsey.

But he had his sights set on moving to the US. There he worked construction and taught himself to code. He also attended online university courses to get a degree.

He met his wife, a nurse from Ukraine. Together they started a family and live together in Florida.

During this conversation, John talks about his journey into teaching the programming and computer science concepts he's learned. He talks about his free courses on freeCodeCamp and his paid courses that help him pay the bills.

John's voice is instantly recognizable by developers. He shares that this is because he has condition where is vocal cords are partially paralyzed, for which he has to receive frequent injections.

I hope you enjoy our conversation.

Can you guess what bass line I'm playing on my bass during the intro? It's from a 1982 song produced by Quincy Jones.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

Also, I want to thank the 9,003 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during the interview:

Guernsey island: https://en.wikipedia.org/wiki/Guernsey

John's personal website: https://johnsmilga.com/

John Smilga on Twitter: https://twitter.com/john_smilga

Learning how to code can be overwhelming - especially if your intro course asks you to build a Facebook clone. But if you focus on the fundamentals, have the right guidance, and develop a strong inner motivation to succeed, you'll master the basics and be ready to move on. In this episode, you'll learn how to do just that.

Written by Rainer Hahnekamp: https://twitter.com/rainerhahnekamp

Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

Original article: https://fcc.im/2LOmUao

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02 

Transcript

I have been programming for more than 20 years. During that time, I’ve had the pleasure to work with many people, from whom I learned a lot. I’ve also worked with many students, coming fresh from university, with whom I had to take on the role of a teacher or mentor.

Lately, I have been involved as a trainer in a program that teaches coding to absolute beginners.

Learning how to program is hard. I often find that university courses and bootcamps miss important aspects of programming and take poor approaches to teaching rookies.

I want to share the five basic pillars I believe a successful programming course should build upon. As always, I am addressing the context of mainstream web applications.

A rookie’s goal is to master the fundamentals of programming and to understand the importance of libraries and frameworks.

Advanced topics such as the cloud, operations in general, or build tools should not be part of the curriculum. I am also skeptical when it comes to Design Patterns. They presume experience that beginners never have.

So let’s look at where new programmers should start.

Test-Driven Development (TDD)

TDD brings a lot of benefits. Unfortunately, it is an advanced topic that beginners are not entirely ready for.

Beginners shouldn’t write tests. This would be too much for their basic skill levels. Instead, they should learn how to use and work with tests.

Each programming course should center around exercises. I extend my exercises with unit tests and provide the students an environment which is already setup for running those tests.

All the students have to do is write their code and then watch the lights of the testrunner turning from red to green. The resulting gamification is a nice side effect.

For example: If the selected technology is Spring, I provide the exercises and tests within a Spring project. The students don’t need to know anything about Spring. All they need to know is the location of the exercises and the button to trigger the tests.

Additionally, students must know how to use a debugger and have a Read-Eval-Print Loop (REPL) handy. The ability to analyse code during runtime and to have a playground for small experiments is essential in TDD.

The main point is to ensure students don’t have to learn basic TDD behaviours after they’ve acquired core programming skills. Changing habits later in the students’ career will be much harder than learning those habits now. That’s why they should live and breath unit tests from the beginning.

Later in their professional life, they should have an antipathy for projects without unit tests. They should intuitively see the absence of unit tests as anti-pattern.

Fundamentals First

I hear very often that rookies should immediately start with a framework. This is like teaching people how to drive by placing them in a rally car and asking them to avoid oversteering. This simply ignores the fact that they still mistake the brake for the throttle.

The same applies when we start students with a framework like Angular. Beginners need to understand the fundamentals of programming first. They need to be familiar with the basic elements and what it means to write code before they can use somebody else’s.

The concept of a function, a variable, a condition, and a loop are completely alien to novices. These four elements build the foundations of programming. Everything a program is made of relies on them.

Students are hearing these concepts for the very first time, but it is of the utmost importance that the students become proficient with them. If students do not master the fundamentals, everything that follows looks like magic and leads to confusion and frustration.

Teachers should spend more time on these fundamentals. But, sadly, many move on far too quickly. The problem is that some teachers struggle to put themselves into the role of a student. They have been programming for ages and have forgotten what types of problems a beginner has to deal with. It is quite similar to a professional rally driver. He can’t imagine that somebody needs to think before braking. He just does it automatically.

I design my exercises so that they are challenging but solvable in a reasonable amount of time by using a combination of the four main elements.

A good example is a converter for Roman and Arabic numbers. This challenge requires patience from the students. Once they successfully apply the four elements to solve the challenge, they also get a big boost in motivation.

Fundamentals are important. Don’t move on until they are settled.

Libraries and Frameworks

After students spend a lot of time coding, they must learn that most code already exists in the form of a library or a framework. This is more a mindset than a pattern.

As I have written before: Modern developers know and pick the right library. They don’t spend hours writing a buggy version on their own.

To make that mindset transition a success, the examples from the “fundamentals phase” should be solvable by using well-known libraries like Moment.js, Jackson, Lodash, or Apache Commons.

This way, students will immediately understand the value of libraries. They crunched their heads around those complicated problems. Now they discover that a library solves the exercise in no time.

Similar to TDD, students should become suspicious when colleagues brag about their self-made state management library that makes Redux unnecessary.

When it comes to frameworks, students will have no problem understanding the importance once they understand the usefulness of libraries.

Depending on the course’s timeframe, it may be hard to devote time to frameworks. But as I already pointed out, the most important aspect is shifting the mindset of the student away from programming everything from scratch to exploring and using libraries.

I did not add tools to this pillar, since they are only of use to experienced developers. At this early stage, students do not need to learn how to integrate and configure tools.

Master & Apprentice

In my early 20s I wanted to learn to play the piano. I did not want a teacher, and thought I could learn it by myself. Five years later, I consulted a professional tutor. Well, what can I say? I’ve learned more in 1 month than during the five years before.

My piano teacher pointed out errors in my playing I couldn’t hear and made me aware of interpretational things I never would have imagined. After all, she instilled in me the mindset for music and art, both of which were out of reach for me as a technical person.

It is the same in programming. If somebody has no experience in programming, then self-study can be a bad idea. Although there are many success stories, I question the efficiency of doing it alone.

Instead, there should be a “master & apprentice” relationship. In the beginning, the master gives rules the apprentice must follow — blindly! The master may explain the rules, but usually the reasoning is beyond the apprentice’s understanding.

These internalised rules form a kind of safety net. If one gets lost, one always has some safe ground to return to.

Teaching should not be a monologue. The master has to deal with each student individually. He should check how the students work, give advice, and adapt the speed of the course to their progress.

Once the apprentices reach a certain level of mastery, they should be encouraged to explore new territory. The master evolves into a mentor who shares “wisdom” and is open for discussions.

Challenge and Motivation

“Let’s create a Facebook clone!” This doesn’t come from a CEO backed by a horde of senior software developers and a multi-million euro budget. It is an exercise from an introductory course for programmers. Such an undertaking is virtually impossible. Even worse, students are put into wonderland and deluded into believing they have skills that are truly beyond their reach.

No doubt the teacher is aware of that, but creates such exercises for motivational reasons.

The main goal of an exercise is not to entertain. It should be created around a particular technique and should help the students understand that technique.

Motivation is good, but not at the sacrifice of content. Programming is not easy. If the students don’t have an intrinsic motivation, coding might not be the way to go.

Newbies should experience what it means to be a professional developer. They should know what awaits them before they invest lots of hours.

For example, many business applications center around complex forms and grids. Creating these is an important skill that exercises can impart. Building an application similar to Facebook might not be the best lesson for students to learn right away.

Similarly, a non-programmer might be surprised at how few code lines a developer writes per day. There are even times where we remove code or achieve nothing.

Why? Because things go wrong all the time. We spend endless hours fixing some extremely strange bugs that turn out to be a simple typo. Some tool might not be working just because a library got a minor version upgrade. Or the system crashes because somebody forgot to add a file to git. The list can go on and on.

Students should enjoy these experiences. An exercise targeting an unknown library under time pressure might be exactly the right thing. ;)

The sun isn’t always shining in real life. Beginners should be well-prepared for the reality of programming.

Final Advice

Last but not least: One cannot become a professional programmer in two weeks, two months or even a year. It takes time and patience.

Trainers should not rush or make false promises. They should focus on whether students understand the concepts and not move on too fast.

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews ThePrimeagean. He's a software engineer who streams himself programming. He recently left his job at Netflix to stream full-time.

We talk about:
- Prime's journey from his teacher telling him he'll never accomplish anything in life to working as an engineer at one of the most prestigious tech companies.
- Prime's love of "Nintendo Hard" video games, and how his love of challenge propelled him to "get good" at coding
- What it's like to live stream coding in front of more than 1,000 people for a dozen hours each week
- Leaving San Francisco to move his family of 6 to a horse ranch in South Dakota
- Prime's thoughts on AI and how he thinks it will actually create more developer jobs than it destroys

I had a blast talking with this guy. Though I don't agree with everything he says, I am right there with him on AI and how it's useful but over-hyped. We'll see what future versions hold and whether a "Moore's Law of AI" is really at work here, or whether it will plateau.

I also agree with Prime that devs need to slow down and improve their foundational skills. There are no shortcuts to anywhere worth going.

Can you guess what song I'm playing on my bass during the intro? It's from a 1996 rock song.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

Also, I want to thank the 9,331 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during the interview:

- Prime's Twitch, from which his YouTube videos are derived: https://www.twitch.tv/theprimeagen

- Prime's Harpoon library on GitHub, which he talks about maintaining: https://github.com/ThePrimeagen/harpoon

- A speedrun of Battletoads by The Mexican Runner, to show you how "Nintendo Hard" this game really is. 36 minutes is an excellent time for a non-pro speedrunner like Prime to achieve: https://www.youtube.com/watch?v=oTPGpA0ha9Y

Ben Dunphy studied international relations and had a short career in finance. Among other things, he co-authored a bill that eventually got passed in his state of New Hampshire.

But Ben saw the writing on the wall – that technology was becoming one of the most powerful ways to affect change. He learned to code and moved to San Francisco, where he and I first met back in 2013.

He built Real World React – a series of evening events and corporate training programs – and ultimately helped launched conferences like Reactathon and JAMstack conf. And now he's helping run the upcoming AI Engineer Summit.

I talk with Ben about his journey into tech and the lessons he's learned along the way. And if you're considering creating a tech event in your city, boy has Ben got some tips for you.

I hope you're digging these weekly freeCodeCamp podcasts. Be sure to leave us a review. And download a few episodes so you can learn on the go. Not only do we have Spanish and Chinese podcasts, but we just launched our Portuguese podcast as well.

And tell your friends. Let's inspire more folks to learn to code and build careers for themsleves in tech.

Ben on Twitter: https://twitter.com/Benghamine

Ben on LinkedIn: https://www.linkedin.com/in/benjamindunphy/

The Rise of the AI Engineer article by Shawn Wang AKA Swyx: https://www.latent.space/p/ai-engineer

The AI Engineer Summit Oct 9, 2023 through Oct 11 in San Francisco: https://www.ai.engineer/summit

The Isabella Gardner Museum in Boston: https://www.gardnermuseum.org/

On this week's episode of the podcast, I interview orchestral musician-turned software engineer Jessica Wilkins.

Jessica found success in the extremely competitive field of classical music, playing the Oboe in orchestras, recording sessions, and even at major events such as the NFL awards on national television.

She started her own business – a sheet music e-commerce website. This not only helped her survive in the high cost of living city of Los Angeles – it also helped her learn web development.

During the pandemic, many of her performance and recording gigs were cancelled. This inspired her to dive much deeper into coding. She now works as a software engineer at freeCodeCamp, and has contributed substantially to freeCodeCamp's core curriculum. Also, her many freeCodeCamp tutorial articles have more than 400,000 readers each month.

During our conversation, Jessica talks about the insane pressure she faced as a musician, where standards are incredibly high. So many people want to be professional musicians, and there is so little money in the industry. Jessica was a rare case of finding success. But even that success could not dissuade her from diving into software development.

This is a long, intimate conversation with one of the sharpest minds behind freeCodeCamp.org. It was a blast talking with Jessica for more than two hours. I think you'll dig it.

Some timestamps in case you want to skip some our lengthy discussion about music education and the music industry:

- 0:00:00 My bass intro. See if you can guess this 1970 classic bassline.
- 0:01:00 Our discussion of Jessica's upbringing by a school teacher and single mom, and her journey into classical music
- 1:07:00 Jessica Learns to code and builds a profitable sheet music e-commerce business
- 1:35:00 Jessica's decision to go all in on software development
- 1:44:00 Contract work and thoughts on what caused recent tech layoffs

Links we talk about during the interview:

One of Jessica's articles - 40 JavaScript Projects for Beginners – Easy Ideas to Get Started Coding JS: https://www.freecodecamp.org/news/javascript-projects-for-beginners/

The Black Excellence Music Project, Jessica's first React project: https://blackexcellencemusicproject.com/

Danny Thompson freeCodeCamp Podcast interview: https://freecodecamp.libsyn.com/site/were-back-danny-thompsons-journey-from-chicken-fryer-to-software-engineer

Danny's LinkedIn course that Quincy mentions: https://www.linkedin.com/learning/linkedin-profiles-for-technical-professionals/main-visuals-on-your-profile

Learning to code - or learning any new skill - is hard, but it doesn't have to be overwhelming. In this episode, Preethi discusses her tried and true strategies for learning, how to tackle challenging problems, and the methods that help her add new tools to her kit. 

Written by Preethi Kasireddy: https://twitter.com/iam_preethi

Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

Original article: https://fcc.im/2uG4B0F

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript

Being an efficient learner is at least as important as being an efficient coder.

When you’re a developer, your job requires you to learn every single day — in spite of the constant lure of distractions like Hacker News, Twitter, Reddit, and Facebook.

You constantly encounter new code bases and new technical challenges at work. Home is no better, as you tackle open source repos and personal projects, each with their own processes and challenges to tackle.

The tech world changes fast, and it can feel like a full-time job just keeping up with the latest tools, languages and frameworks.

Long story short: learning is hard. Yet, we need to be able to learn quickly and effectively to thrive.

In the past year, I went from not knowing how to use the Chrome debugger to working as a software engineer for a leading cryptocurrency company. In the process, I rapidly learned a new skill (coding).

That said, learning didn’t come easy for me.

Honestly, every new concept was a struggle. There were too many unknowns, and too much uncertainty.

“How in the world is this sustainable?” I thought to myself.

“If this is what learning to code is supposed to feel like every day, I’ll be miserable. Is this really my passion?”

“Wouldn’t this be easy for me if this was my passion? Do artists struggle to produce art? Do writers struggle to write a great book? Do athletes struggle to do well in a race? Are we supposed to struggle when we’re pursuing our passions?”

“Shouldn’t I be finding pleasure in this?”

Does it ever get easier?

Yes, it does. A year later, tackling new programming concepts is still “difficult” in the sense that it requires discipline and hard work.

But it’s also become an enjoyable process, rather than an overwhelming one.

What happened in the last year to make that shift possible?

Simple: I changed my perspective on learning. What once struck me as “difficult” became “engaging.”

In the rest of the post, I’ll explain how this transformation happened.

Just getting started

Learning to code is hardest at the beginning.

For example, think about the first programming language you have to learn. You want to tackle the small things like syntax and style. But first, you have to comprehend difficult core concepts like values, types, operators, control flow, functions, higher order functions, scopes, closures, recursion, and so much more.

It feels like learning to juggle — but starting with eighteen pins instead of two.

When I first learned about closures, it took me many weeks to truly understand the concept. I thought I understood it when I read about it. But when I tried to identify and use closures in practice, I’d find myself stumped.

That wasn’t unusual. I’ve observed this process as a teacher as well: new concepts don’t usually click the first time around. Or the second. Or even the tenth.

But for those who stick it out long enough, there will be a “breaking point” where things suddenly begin to make sense. In my example, I read literally every blog post, Stack Overflow post, and spec on the internet about closures.

Everything I read and experimented with gave me a new perspective, until eventually, I had a 360-degree mental picture of how closures worked. Closures “clicked.”

Getting to a point where I felt this sense of understanding of closures was super important, because it was rewarding and encouraged me to go for more — including writing my own blog post that explained the concept.

Learning is a process, not a goal
If we see learning as something we “have” to do, then we rush to get it done so that we can spend the rest of our time doing something more “fun” — something we “want” to do.

The problem is that it’s impossible to know everything about anything, so viewing learning as a race leads to burnout and disappointment.

Instead, if you see learning as a process, you’ll appreciate the small victories and insights along the way. This will drive you to constantly move forward.

You can compare it to exercise. Workouts hurt, and then the pain ends as soon as your workout ends. But it’s never gone. It’s waiting for you the next time you workout. Except each time, the pain becomes less piercing. You learn to cope with it. You become familiar with the pain, and it just becomes part of the routine. You are rewarded by better health and a better physique and are incentivized to keep going.

Exercise creates a positive feedback loop.

The same is true for learning.

Turning learning into an engaging process

Imagine building your very first web application.

At first, all you’ve got is a daunting, blank text editor. The task of building the app seems almost insurmountable. You know nothing, and have so much to learn before you can make this happen.

Thankfully, you decide to go for it anyway.

From then on, your main focus becomes to do one small step at a time.

First, you create an idea. What will you build? Who’s the end user? What are the constraints?

Second, you prototype or sketch out some rough designs for what you think it might look like. You ask your friends or the internet for feedback, and iterate to make it better.

Third, you research languages, tools, and frameworks that will work best with your requirements.

Step by step you discipline your mind to channel all its energy towards this one goal.

Sometimes you’re writing code.

More often than not you’re stalled at some bug or error.

Sometimes you’re too tired to do any work, so you take a break.

Other times, you don’t feel like writing code. That’s okay. You spend your time researching or reading up on topics related to your project.

Eventually, after a few weeks of hard work, you’ve built a foundation that can handle your big ideas. Suddenly, working on your app doesn’t feel as painful. You see the reward of the initial set of hard work, and now it’s just another piece of code you need to write or another bit of refactoring you need to do — which you’ve done 100s of times already, no problem.

You turned what was once a daunting or dreadful activity into one that is complex and engaging.

This is how we grow. This is how we get better. Whether it’s programming, dancing, running, or reading: it’s not easy, and there won’t ever be a time or place when you’re “done” learning.

Instead, enjoy the process of investing your energy into something, and enjoy the pain that comes along with it. You’ll start to notice that you no longer describe it as “pain” — because what was once painful becomes a symbol for what’s next: a sense of personal accomplishment and self-satisfaction.

In other words, struggle and enjoyment will start to mean one and the same thing. Remember the cycle:

One approach to learning technical topics

Let me tell you a little about the learning process I follow. This isn’t the be-all-end-all of learning styles, so if something different works for you, please share it in the comments! In case you can’t tell, I’m a nerd about this stuff :)

Let’s use the process of learning the React.js library as an example.

What is the motivation for learning this?
First step: I’d start with a Google search for the React.js documentation and read a bit about the background and motivation for the library.

Knowing the “why” behind any topic is incredibly helpful for framing the learning process. It answers questions like:

How is this different from other solutions?

How useful is this to me?

What problems does this solution aim to solve?

Is this just a new shiny tool that’ll only be useful for a few months or will it fundamentally change the way I think and code?

Reading and understanding core concepts

Second, I’d read through any intro articles or examples provided in the docs.

Notice I’m not touching any code yet. Reading and sinking in the core concepts comes before hands-on experimentation. It’s incredibly important to do this because it lays the foundation for the rest of my learning.

Even though I might be able to get away with blindly using React.js without learning the core concepts, eventually it’ll catch up to me when I run into a bug.

First time coding

After spending some time on the above steps, I start to get the gist of what’s going on, or maybe even feel like I totally get it. Then it’s time to jump into some code.

I typically try to build something really small with any new tool by following a video tutorial (e.g. on egghead.io) or a written tutorial before jumping into custom projects.

When you get stuck

…And then, inevitably, I get stuck.

Reading the docs seemed like a piece of cake, but actually using it in practice makes me realize I have no idea what’s going on.

This is when I start to feel that dreaded “just give up” feeling. But instead of giving in when the going gets tough, I remind myself that pain == gain. Turning back would be cowardly.

Here’s what I do instead:

I first narrow down and figure out what I’m actually stuck on — i.e. define the problem. Then I come up with a hypothesis for what I think could be the root cause or causes of the problem. Even if I have no idea, I just make a guess.

Then I step away from the problem and my computer and do something that relaxes me. This is incredibly hard to do when I’m so upset about the problem I’m stuck on, but letting go of the problem works wonders. (Ever notice how great ideas always strike in the shower?)

Now I try to debug with my hypothesis in mind. I get as far as I can on my hypothesis without looking for answers online — there’s something beautiful that happens when you try to solve problems by truly thinking deeply about them on your own first. Even if you’re going down the wrong path, the fact that you made the effort teaches you a lot and you remember the problem space much better next time you run into it.

If my hypothesis leads to an answer, hooray! I’m done. If not, I Google search for documentation, blog posts, or Stack Overflow posts that could help me get closer to the answer.

While reading, I take notes on any and all pieces of information that could potentially be helpful.

Still no solution? That’s fine. I’m sure I learned something valuable by reading through all that, even if it didn’t directly help me solve the problem at hand. Who knows when this knowledge might come in handy next time?

At this point, if I’m truly stuck, I will either post a question on Stack Overflow or ask a co-worker or developer I know.

Otherwise, I rinse and repeat until I get closer to the final solution. At some point, the answer always comes.

At times this process takes a few seconds, and other times it takes hours (or days). Either way, the process itself is incredibly beneficial to your skill set as a developer.

Getting stuck on a bug feels like stumbling in a dark tunnel looking for a ray of light. You eventually find it, but along the way you discover so much about the tunnel — and it’s knowledge about the “tunnel” that makes you strong as a coder.

Think of debugging as a chance to explore rather than a detour from your goal, and it becomes much more fun.

Rinse and repeat

By this point in the learning process, I’ve built something small and tackled some small hurdles along the way. As you can see, it was a struggle — clearly, I need some more practice with the new tool.

So, once again I try to build something on my own. Rather than jumping straight to a big custom project, I’ll look for a repo to base my application on.

For example, if there’s an online CRUD todos example (of course) using React.js, maybe I’ll build a different type of CRUD application. Just different enough to keep me engaged, but not so different as to make me discouraged if something goes wrong.

Mastery

Mastery requires repetition, so I keep building more small projects until I feel like I’ve got the core concepts down.

Eventually, I begin to be able to piece things together on my own without constantly referencing documentation or examples. Only then do I finally adventure out and build something from scratch on my own.

Throughout this process, I aim to make the process fun and engaging. I’m constantly pushing myself to work on things that are harder than what I am capable of in the moment, but not throwing myself into the deep end so that I get discouraged and never finish.

Finally, I make sure to step away as soon as I find myself getting too frustrated to enjoy the project.

Learning is fun

With some effort and structure, learning programming turns out to be incredibly fun. At first it’s incredibly complicated, and in my opinion that’s why so many people get scared away — not because it’s “boring,” but because it’s “hard.”

After you go through this learning process a few times, processing new information becomes a muscle memory. You don’t really think about it. You just learn to ride the pain wave and find joy in the reward.

Like magic, it becomes “easier” to learn.

In this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Jessica Lord, AKA JLord. She's worked as a software engineer for more than a decade at companies like GitHub and Glitch. 

Among her many accomplishments, Jessica created the Electon team at GitHub. Electron is a library for building desktop apps using browser technologies. If you've used the desktop version of Slack, Figma, or VS Code, you've used Electron.

I recorded this podcast live and I haven't edited it at all. I want to capture the feel of a real live conversation, with all the human quirks that entails. As with all my podcast episodes, I start by performing a classic bass line. Can you guess what song this bass line is from? It's a "cult" hit from 1990.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

Also, I want to thank the 8,427 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during the interview:

GitIt, Jessica's interactive Git course on Node School: https://github.com/jlord/git-it

Jessica's old craft blog (you may get an HTTPS warning from your browser but the site is just an old Blogspot site): http://www.ecabonline.com/

JSBin founder Remy Sharp's blog about JSBin and how he "lost his love of his side project": https://remysharp.com/2015/09/14/jsbin-toxic-part-1

Subdivisions song by Rush that Quincy mentions. Great early morning listening: https://www.youtube.com/watch?v=EYYdQB0mkEU    

Today I'm joined by Sarah Shook is a software engineer who started out as a recruiter, then started learning system administration on the job at a school.

She didn't finish university. She learned to code on the job, from studying freeCodeCamp, and from attending a short bootcamp that she won free admission to. And she did all of this while raising 3 kids.

She is a career-long remote worker, and insists she will never work somewhere where she needs to be away from her kids. Today she runs software development agency and works with clients. 

Sarah and I talk about her coding journey, how she's worked to overcome depression and severe shyness, and her love of front end libraries like Tailwind CSS.

If you dig this podcast, be sure to leave us a review. And tell your friends. It really helps.

Without further ado, my interview with Sarah Shook.

Sarah Shook on Twitter: https://twitter.com/shookcodes

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Jessica Chan AKA Coder Coder. She's a software engineer has worked in the field for more than a decade. Interestingly, she studied photography in school and never took a programming class.

We talk about:

- How she and her sister ran a dial-in Bulletin Board System (BBS) back in the pre-web days

- How her first year as a dev she "was just living in abject fear of losing my job."

- How she stayed at her first developer agency job for 7 years, and went from imposter syndrome afflicted newbie to getting promoted

- Her philosophy on creating programming tutorials: "You don't have to be on the cutting edge. I don't operate on the cutting edge."

Can you guess what song I'm playing on my bass during the intro? It's from a 1993 rock song.

Also, I want to thank the 9,779 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during our conversation:

Jessica's 7-hour "How to Build a Website" freeCodeCamp course: https://www.freecodecamp.org/news/create-a-simple-website-with-html-css-javascript/

Jessica's coding journey animated video: https://www.youtube.com/watch?v=jA14r2ujQ7s

Kevin Powell, the "King of CSS", who has also shared courses on freeCodeCamp: https://www.freecodecamp.org/news/author/kevin-powell/

Jessica on Twitter: https://twitter.com/thecodercoder

Zubin Pratap is a corporate lawyer who taught himself to code using freeCodeCamp.org and other learning resources.

Zubin develops software in Melbourne, Australia. He's a lover of hackathons and competed in freeCodeCamp's first hackathon at GitHub headquarters last November.

Follow Zubin on Twitter: https://twitter.com/ZubinPratap

Follow Quincy on Twitter: https://twitter.com/ossia

The following is a note from Zubin himself about a course he just launched. Note that freeCodeCamp.org does not receive any benefit from this, and has not reviewed his course - we just want to help him publicize it.

---

Zubin was a non-technical person for a long time, and set a goal to become his own tech cofounder. But he quit from discouragement twice.  It was much harder than it should've been, and Zubin put together a course on all the things he wish he'd known and all the techniques that made him not quit the third time. In 3 hours you can learn the roadmap that could save you months, thousands of dollars, and a lot of stress.

Today I'm joined by Lynn Zheng. She's a software engineer at freeCodeCamp and at Salesforce.

Lynn grew up in Shenzhen, China – the computer hardware capital of the world. Both of her parents were engineers. And from an early age, they encouraged Lynn to learn math and computer science. She got into the prestigious Computer Science program at University of Chicago, where she earned both Bachelors and Masters degree – all by the age of 21.

I met up with Lynn at the Redwood City Public Library in the heart of Silicon Valley. But they didn't have any study rooms available. so we climbed to a nearby rooftop and recorded there.

We talk about Lynn's many game development projects, which culminated in Learn to Code RPG, a Visual Novel game where you learn to code and get a developer job. And we talk about her experience working as an engineer at one of the largest tech companies in the world, even as she's stuck in work visa limbo.

Next week will be our 100th episode, and I've got something extra special in store for you.

Tell your friends about the freeCodeCamp podcast. Let's inspire more folks to learn to code and build careers for themsleves in tech.

Learn to Code RPG: https://www.freecodecamp.org/news/learn-to-code-rpg/

Lynn's Stable Diffusion course: https://www.freecodecamp.org/news/stable-diffusion-crash-course/

Lynn on Twitter: https://twitter.com/lynnzheng08

Lynn on LinkedIn: https://www.linkedin.com/in/ruolin-zheng/

Today I'm joined by Dr. Curran Kelleher. He's a data visualization expert and has taught a number of in-depth data visualization courses on freeCodeCamp's YouTube channel.

We talk about what it's like to get a Ph.D. under one of the pioneers of data visualization. 

We also talk about how he uses his visualization skills in industry, his many years living in India, and his love of teaching.

I think you're going to walk away with a deeper understanding of data, the human brain, and how we process information. You'll also learn some practical career tips.

I hope these weekly freeCodeCamp podcasts are firing you up about learning more about technology.

Tell your friends about the freeCodeCamp podcast. Let's inspire more folks to learn to code and build careers for themselves in tech.

Some relevant links from our discussion:

Curran's 20-hour Data Visualization with D3 course on freeCodeCamp: https://www.freecodecamp.org/news/data-visualizatoin-with-d3/

"Semiology of Graphics: Diagrams, Networks, Maps" book Curran mentions: https://www.esri.com/en-us/esri-press/browse/semiology-of-graphics-diagrams-networks-maps

Curran's portfolio of work: https://github.com/curran/portfolio

Bret Victor's talk "Inventing on Principle"： https://www.youtube.com/watch?v=NGYGl_xxfXA

On today's episode of the freeCodeCamp podcast, Abbey chats with  Tracy Lee, a prolific speaker, founder, JavaScript advocate, and open-source enthusiast.

Tracy is a Google Developer Expert and the founder of This Dot. She organizes numerous meetups, runs the Modern Web podcast, and is on the RxJS core team.

Tracy will share with us how she got into tech, what she's passionate about, and how you can become a badass person in tech, too.

Connect with Tracy on Twitter: https://twitter.com/ladyleet

Connect with Abbey on Twitter: https://twitter.com/abbeyrenn

Find Tracy on the web: https://www.thisdot.co/

Learn to code for free: https://www.freecodecamp.org/

Abbey and Quincy talk about the freeCodeCamp podcast itself, and the new weekly episodes starting on Monday.

Abbey on Twitter: https://twitter.com/abbeyrenn

Quincy on Twitter: https://twitter.com/ossia

Links mentioned:

The article Quincy mentioned: "The best podcasts for new coders, and the best tools for listening to them": https://fcc.im/2T2lMHT

Tools:

Listen Notes: https://listennotes.com

Audacity: https://www.audacityteam.org

Zencastr: http://zencastr.com

Libsyn: https://libsyn.com

In this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Per Borgen about AI engineering and interactive developer education. Per is the co-founder and CEO of Scrimba and is a software engineer.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

Links we talk about during the interview: 

Per's HTML + CSS course: https://www.freecodecamp.org/news/learn-html-and-css-from-the-ceo-of-scrimba/ 

Per's JavaScript course: https://www.freecodecamp.org/news/full-javascript-course-for-beginners/

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Ken Jee. Ken's a Data Scientist. He's also a Sports Analytics practitioner who works with US Team Golf and USA Basketball. 

Ken hosts the excellent Ken's Nearest Neighbors podcast and the Exponential Athelete podcast.

We talk about:

- How an injury pushed Ken out of pro sports and into data science

- How Ken explains his statistical insights to coaches and players to help them improve their performance

- Why Ken doesn't think building projects is all that useful anymore. "Data Scientists should instead build products."

- How Ken starts and ends each day with meditation, and writes down all the ideas that pop into his head after each session.

- Ken's observation that: "Who is the best suited to excel in a world where AI tools are prominent? Probably the people who are building them. People in the data science domain, people who are coding – they're the most prepared to use these tools for other things."

Can you guess what song I'm playing on my bass during the intro? It's from a 2006 dance song, and it was originally played on a synth.

Also, I want to thank the 10,109 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during our conversation:

Ken's Nearest Neighbors Podcast: https://www.youtube.com/channel/UCpEJMMRoTIHJ8vG8q_EwqCg

The Exponential Athelete Podcast, also hosted by Ken: https://www.youtube.com/playlist?list=PLAkSd12rP282takuFJKsAsYlHdpdEDhuE

The Founders podcast, which both Ken and Quincy listen to. James Dyson episode: https://www.founderspodcast.com/episodes/88384801/senra-james-dyson-against-the-odds-an-autobiography

Anna Wintour episode: https://www.founderspodcast.com/episodes/58741411/senra-326-anna-wintour

San Antonio caves that Quincy visited: https://naturalbridgecaverns.com/

Today I'm joined by Kevin Miller. He's a senior developer and host of the Coder Conversations YouTube channel.

Kevin studied accounting in Texas and worked overnight for 7 years at hotels, making only $11 an hour. But his knowledge of spreadsheets lead to him learning more about programming and automation.

After spending a year living with his parents and teaching himself to code full time, Kevin landed his first developer job. He immediately tripled his income. 

Kevin has since worked as a dev at several Fortune 500 companies. But it's been a bumpy ride. He's been laid off 3 times due to mergers and employers just running out of money.

He started Coder Conversations as a way for him and fellow developers to talk about technology and share career advice. He now has 200 episodes.

I hope you're digging these weekly freeCodeCamp podcasts. Be sure to leave us a review. And download a few episodes so you can learn on the go.

Tell your friends about the freeCodeCamp podcast. Let's inspire more folks to learn to code and build careers for themselves in tech.

Coder Conversations: https://www.youtube.com/@coderconvos254

Kevin on LinkedIn: https://www.linkedin.com/in/kevm254

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Colby Fayock. He's a Software Engineer and prolific teacher who has created 68 tutorials for freeCodeCamp, and more than 100 videos on his YouTube – all freely available.

We talk about:
- Colby's early days doing design work for local bands
- How Colby went to art school, then pivoted that into a software development
- His early career at ThinkGeek where he not only did web dev but also worked as a male model for their products.
- Colby's day-to-day work as a developer experience engineer, building demo applications and SDKs
- How Colby uses AI tools in his day-to-day work, and what he thinks its current limits are.

Can you guess what song I'm playing on my bass during the intro? It's from a 1995 punk song.

Also, I want to thank the 9,771 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during our conversation:

• Colby's freeCodeCamp course on building a clone of Google Photos using AI tools and Next.js: https://www.freecodecamp.org/news/create-a-google-photos-clone-with-nextjs-and-cloudinary/
• Colby's Trailer and web design work: https://photowall-colbyfayock.vercel.app/wall/design
• Colby's ThinkGeek Modeling. He's legit a male model: https://photowall-colbyfayock.vercel.app/wall/thinkgeek
• Colby's music from his band years: https://soundcloud.com/colby-fayock/sets/day-late-hero
• The XKCD comic I mention about how the scope of developer work can be non-intuitive: https://xkcd.com/1425/

Today I'm joined by Shawn Wang, AKA Swyx. I first interviewed Shawn in 2019. Back then, Shawn had quit his $350k a year finance job and taught himself to code using freeCodeCamp. He was working as a full stack engineer. It's a wild interview that you should go back and listen to... after of course you finish listening this.

Now a lot of people thought Shawn was crazy leaving finance. But this dude knew what he was doing. He has now risen through the ranks as a developer at tech startups. And now he's starting an AI startup of his own. He's already off to a strong start, having raised a $3 million pre-seed round from investors.

This is the first time I've ever invited a guest return to the freeCodeCamp podcast for a second interview. And there was so much to talk about, I feel like I could have interviewed Shawn for days.

The man has been eating, sleeping, and breathing AI engineering for the past year. I learned so much from talking with him. I'm confident that you will, too.

Watch Swyx's AI Engineering conference live stream: https://ai.engineer

The Latent Space Podcast: https://www.latent.space/podcast

Follow Swyx on Twitter: https://twitter.com/swyx

Beau's YouTube course style guide: https://www.freecodecamp.org/news/how-to-create-a-great-technical-course/

How I got a second degree and earned 5 developer certifications in just one year, while working and raising two kids https://www.freecodecamp.org/news/how-i-got-a-second-degree-and-earned-5-developer-certifications-in-just-one-year-while-working-and-2b902ee291ab/

Beau's personal website: http://carnes.cc/

In this week's episode, Abbey interviews Ariel Leslie, a software developer with an interesting background (she was once a knife salesperson, among other things!) who lives and works in Colorado.

While she can't discuss all the details of her super-secret job, she fills us in on how she got to where she is now. You'll hear about the benefits of her university degrees and how supportive communities have helped her along the way, why she loves tough problems and how she battles her insecurities, and why she takes time to learn new things, like how to play the Appalachian Mountain Dulcimer.

Ariel offers an interesting perspective on being a woman in tech, how various mentors have helped her become the developer she is today, and how she tackles imposter syndrome.

Find Ariel on Twitter: https://twitter.com/ArielLeslie

Find Abbey on Twitter: https://twitter.com/abbeyrenn

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Jerod Santo, host of The Changelog, a podcast about open source software development that has been going strong for 15 years.

Jerod is plugged in to the world of Open Source, going to all the big conferences and interviewing all the big open source creators. 

We have a fun, wide-reaching conversation about some of the current issues facing open source, such as AI models and Relicensing – essentially, a big company closed-sourcing a previously open source project after they buy out its creator. (Fun fact: this can't happen to freeCodeCamp because charities cannot be bought or sold.)

I ask Jerod about:

- his life as a remote dev in Omaha, Nebraska, raising his 6 his kids
- the Changelog News podcast with its weekly 10 minutes of updates on the world of open source
- his process, and how he researches and surfaces interesting news for his show
- and how The Changelog commissioned 3 full albums worth of music over the years, which you can stream for free.

Can you guess what bass line I'm playing during the intro? It's from a 1984 pop classic.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

Also, I want to thank the 9,331 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during our conversation:

Jerod's weekly Changelog News podcast that you should totally subscribe to (it's free): https://changelog.com/news

Jerod and Adam interview the head of the Open Source Initiative on AI models and open source, which he and I discussed during this podcast: https://changelog.com/podcast/578

Changelog Beats: https://changelog.com/beats

And of course, my interview with Jerod and Adam about their developer journeys, and the history of The Changelog on its 10th anniversary: https://www.freecodecamp.org/news/open-source-moves-fast-10-years-of-the-changelog/

On this week's podcast, I meet with Arian Agrawal in New York City to talk about her journey into tech startups.

Arian grew up in New York and studied at MIT. She worked in finance for a few years, then built her own Ecommerce Marketplace startup with a friend.

Along the way, Arian went through the South Park Commons startup accelerator, and she now leads their New York City branch as a partner.

We talk about technology, startups, and her journey from finance to building products.

I hope you're digging these weekly freeCodeCamp podcasts. Be sure to leave us a review. And download a few episodes so you can learn on the go.

Tell your friends about the freeCodeCamp podcast. Let's inspire more folks to learn to code and build careers for themselves in tech.

Arian on Twitter: https://twitter.com/AgrawalArian

Arian on LinkedIn: https://www.linkedin.com/in/arian-agrawal-46639439/

South Park Commons: https://www.southparkcommons.com/

This week freeCodeCamp founder Quincy Larson interviews Phoebe Voong-Fadel about her childhood as the daughter of refugees, and how she self-studied coding and became a professional developer at the age of 36.

Phoebe worked from age 12 at her parent's Chinese take-out restaurant. She was able to study history at the London School of Economics, before working in higher ed.

She left her job to raise two kids due to the high cost of childcare in the UK, and spent years self-studying coding before becoming a software developer at age 36.

I recorded this podcast live and I haven't edited it at all. I want to capture the feel of a real live conversation, with all the human quirks that entails. As with all my podcast episodes, I start by performing a classic bass line. Can you guess what song this bass line is from? It's from 1989.

Phoebe has earned multiple certifications from freeCodeCamp, and also published a number of articles on our publication.

How Phoebe went from stay-at-home mom to Front End Web Developer at age 36: https://www.freecodecamp.org/news/how-i-went-from-stay-at-home-mum-to-front-end-web-developer-39724046692a/

Phoebe's review of Harvard CS50: https://www.freecodecamp.org/news/cs50-course-review/

The BBC Take-away Kids documentary, which Phoebe said is what her childhood was like, working from age 12: https://www.bbc.com/news/av/stories-47007812

Phoebe's website, with her portfolio and links to her socials: https://www.thecodinghamster.com/

You can watch a video version of my interview with Phoebe here: https://youtu.be/WomQr-jRO1c

If you've read this far, consider supporting our 501(c)(3) public charity, and aiding us in our mission to create more free learning resources for everyone: https://www.freecodecamp.org/donate

In this week's podcast episode of the freeCodeCamp podcast, Abbey chats with Harry Wolff, an engineering manager at MongoDB in New York City.

Harry has been in the world of tech for over a decade, holding jobs in various startups before ending up at Mongo. They discuss his journey to his current managerial role, what it's like to work at Mongo, how to start a meetup, and dos and don't for migrating from legacy codebases.

Harry started his tech career working for startups. He liked the excitement, he liked learning new things, and he liked showing off his skills. After working for a few startups, he stumbled upon a position at MongoDB. One short week after beginning the interview process, he was in.

The decision to leave his previous job was easier than he expected, and he reflected on the reasons he made the change:

"For me, it was a matter of taking what I could from my job at the time, but knowing when it was time to move on. One of the ways you know it's time to leave is when the company's getting more out of you than you're getting out of the company."

Once Harry was settled in at Mongo, he got right to work. After a couple years as an engineer working on various projects, he achieved one of his major goals and became a manager.

Harry and I discussed his relatively new position in detail, and while he's still figuring things out, he has some valuable insights into his transition.

"One of the most difficult things about being a manager is that there's no easy way to evaluate the success of your day. There are no milestones to say you've accomplished a lot. You might have a eureka! moment where you figure something out, but you're definitely living in the grey a lot more. Because it's people - they change by the day and hour and minute."

But one of the best things for Harry is how much he gets to learn - constantly, from many different people, and about many different things. In addition to reading about new programming languages, discussing what's new in the JavaScript ecosystem in his podcast, and making every effort to stay on top of new tech, Harry has learned more nuanced skills as well.

"One hard skill I needed to learn was being assertive and truthful when I needed to be. Most humans prefer that uncomfortable situations just resolve themselves...but if you wait six months [to deal with something], it becomes a dealbreaker."

In addition to managing his team, working on his podcast, YouTube channel, and blog, and reading programming handbooks for fun, Harry has been working to update MongoDB's tech stack and move away from their legacy codebase. In the process, he's developed some insights into such migrations.

"You have to have a good reason for doing it. And part of this is scolding my former self who would say 'yeah, just do it!' But having learned more, you need to have a good reason. For us, it's more maintainable, less error-prone, and better for recruiting."

"But don't rewrite everything - that's seldom the right answer. Occasionally there are exceptions, but they're exceptions."

When Harry isn't working or creating content, he hangs out with his wife and new son in New York. He encourages people getting into tech to keep at it and not get discouraged.

       "Never give up. Just keep hustling. Take with a grain of salt the            feedback you get from companies and have confidence in what            you do and don't know. And stay humble. It's hard but you have          to just want it and keep hustling and stay curious."

Find Harry on Twitter here: https://twitter.com/hswolff

Find Abbey on Twitter here: https://twitter.com/abbeyrenn

Guest: Adam Hollett, developer at Shopify: https://twitter.com/admhlt

Host: Quincy Larson, the teacher who founded freeCodeCamp: https://twitter.com/ossia

On today's episode of the freeCodeCamp podcast, Quincy interviews Adam Hollett. He's a software developer at Shopify in Ottawa, Canada.

Adam started building basic websites and forums when he was in high school, but he never saw coding as something he could do professionally. He got a degree in English Literature, worked in food prep, and taught at a community college. He later worked as a technical writer, and set his eyes on working at Shopify, a major Canadian tech company based in Ottawa. Adam was able to gradually to learn new tools on the job that helped him transition into a role as developer.

We talk about Adam's journey - from meandering college student to software developer - and the many lessons he learned along the way.

On this week's episode of the freeCodeCamp podcast, Abbey chats with London-based software engineer Linh about how she left the field of biochemical engineering, taught herself to code, struggled to get her first dev job, and now gets to work at LEGO.

Linh moved to England when she was 11 years old. She spoke no English, but quickly learned and settled into her life there. She became fascinated with cosmetics and wanted to learn how to create them, so she decided to study biomedical and biochemical engineering in college - she even got her Master's degree in the subject.

But something didn't feel right - she didn't have the passion for it she thought she had. So she looked elsewhere. After briefly considering banking, and teaching for a bit, she stumbled into the world of tech through one of London's many fintech meetups.

As she started to learn more and meet more people, she realized she'd found her new passion: coding. So she decided to teach herself to code...and the rest is history. Just kidding - but you'll have to listen to find out what comes next :)

In this episode of the podcast, you'll learn all about how Linh taught herself to code, how she persevered through a long job search and got her first (and second and third) dev job, what exciting projects she's working on at LEGO, and how she'd advise anyone wanting to break into tech to go about it.

Find Linh on Twitter here: https://twitter.com/pinglinh

Are you trying to get a jump-start on your tech career while you're still in school? Have you found that perfect internship - or job - but you're not sure how to approach it? If so, this is the resource for you. Michael discusses how to craft your résumé, how to prepare for interviews, and much more.

Written by Michael Deng: https://twitter.com/themichaeldeng

Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

Original article: https://fcc.im/2BCESfo

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript:

Seven semesters ago, I started college with no programming background. The only thing I had was lofty aspirations of working in tech.

When recruiting season first rolled around, I applied to a bunch of companies. I got a few callbacks, but that’s it. No follow-ups. No onsite interviews. Nothing.

I kept trying. I applied to over 150 companies. I faced dozens of interviews.

I failed way more than I succeeded. But that’s all right. Because those failures made my moments of triumph all the more memorable.

Along the way, I met helpful mentors and guided ambitious mentees. These people are now working at places like Airbnb, Facebook, Google, SpaceX, and Snap.

As for me, I landed an internship at Uber last summer. And I’m on track to accept a full-time job at one of my favorite companies when I graduate.

Now that I’m in my final year of school, I want to share everything I’ve learned over the years. This isn’t meant to be the ultimate handbook. It’s only a modest guide born out of my love of helping others reach their goals (and my love of Legos).

By the end of this article, you’ll know everything I wish I had known when I first started sending in applications.

A few words before we begin…

Don’t let your struggle for the perfect job take over your life. School is a time of self-discovery and all-around personal growth. So go out there and meet people who are doing different things. Join diverse student organizations and take part in activities outside your comfort zone.

It’s all too easy to associate your self-worth with how prestigious of a job you can get. But remember: there are so many more important things in life than work.

My best memories of college aren’t spending weeks on end prepping for interviews or even getting offer phone calls. They’re exploring San Francisco for the first time with my closest friends. They’re playing volleyball with my hilarious teammates. I value these unique experiences I shared with people I love much more than any job.

To paraphrase my favorite quote by Twitter and Medium founder Ev Williams: “Failure of your [work] is not failure in life. Failure in your relationships is.” Don’t lose sight of what’s important.

It’s also no coincidence that everyone I know with a strong support system eventually found success. When you fall into a slump — and all of us do — you need your friends to be there for you. I would never have made it through my first year without amazing friends who kept me afloat.

Now, let’s get started. You pumped? I’m pumped!

Building fundamentals

Before we get to the good stuff, you need to build solid fundamentals. Seems obvious? Absolutely. But this is the hardest step of this guide, so listen up.

Now, this guide is designed for college students, so if you’re in high school, scram! Just kidding. In fact, I admire your initiative. When I was in high school, I didn’t have the faintest idea what I wanted to do.

Leading up to college, your top priority should be solidifying your math skills. Computer science relies heavily on mathematic concepts like probability, logic, and number theory. Without math, you’re not going to get far in hard weeder classes and technical interviews.

If you’re already proficient in math, keep reading. Most of this guide is just as applicable to you as it is to college students. Skip to the online classes section below and progress through the rest of this guide. Landing an internship as a high schooler is challenging, but certainly not impossible.

OK. Back to college students.

Building fundamentals starts with your intro programming classes. Pay attention and master the basics. A popular but misguided notion is “GPA doesn’t matter.” Although it’s true that most companies won’t scrutinize your GPA, any gaps in your fundamental knowledge will come back to bite you later. By getting a decent GPA, you’re also most likely getting a grasp of the basics.

Your classes will cover a lot of basic knowledge, but they’ll barely scratch the surface of modern technology. Go explore interesting topics around the core concepts taught in class. This is how you gain a breadth of knowledge and come up with future project ideas.

If you’re not studying computer science, don’t worry.

I have friends who changed their minds and started CS their Junior year. They still graduated on time with great job offers, so you’re not too late at all. This said, you will need to make sacrifices and take extra classes every semester.

If you’re not able to take CS classes in college, there are plenty of awesome online resources to help you out.

Two of the best online intro courses are Harvard CS50x on edX and CS101 on Udacity. After this intro, you need to master data structures and algorithms. I recommend Princeton Algorithms Part 1 and Part 2 on Coursera, or CS61B by UC Berkeley.

To make sure you’re on track, reference Google’s Technical Development Guide.

Don’t worry if you struggle at first.

A few weeks into my first semester, I was completely overwhelmed. I spent days studying concepts that took other students hours to grasp. I thought about giving up every week. “How am I ever going to catch up to those prodigies?”

But if you ask me or any of my friends who made it through, we’ll all tell you the same thing: Learning to program isn’t about how talented you are or how early you started coding. It’s about perseverance.

Building up your programming intuition takes a long time — much like learning a human language. You won’t see the light at the end of the tunnel for a long time. But trust me. If you take one step at a time, you will eventually get there.

Staying motivated is difficult, but there’s a secret.

Focus on mastery instead of results.

Make it your goal to get better at a skill rather than achieve a certain result. Dr. Heidi Grant Halvorson did a study where she asked two groups of people to solve various problems. The first group was told to score as high as they could. The second group was told to treat the problems as a learning opportunity.

The results were surprising. The first group got frustrated, whereas the second group persisted and solved more problems.​

By focusing on mastery, you view obstacles and time pressure as things that will help you grow. In contrast, a result-oriented mindset frames problems as irritating roadblocks impeding your way.

What’s more, you’ll see continual progress if you concentrate on mastery. Every time you read a new paragraph or solve a new question, you’re improving your skills. This kind of continuous gratification is incredibly satisfying.

So next time you’re studying for class or practicing for interviews, focus on getting better instead of acing the exam or landing the offer.

You can read more about this tactic in Edmond Lau’s Quora post.

Beyond basic coding skills, you need to know what’s happening in the tech industry.

This goes beyond sounding smart during recruiting. By paying attention to the industry, you’ll be the first to discover new opportunities to propel your career forward.​

For online reading, check out TechCrunch, Techmeme, Product Hunt, and Hacker News. If you’re a frequent Twitter user, follow tech news sources. On Medium and Quora, personalize your feeds to get insightful takes on the industry.

If you’re into email newsletters, look into Axios Pro Rata, CB Insights, and Mattermark Daily.

To do a deep dive on a particular company, use Crunchbase and the company’s blog. You can also learn about the company’s culture from Glassdoor.

Finally, don’t forget to actually talk to people. I learned so much about the tech world from casual conversations with friends and classmates.

Over time, you’ll read about a lot of interesting companies. Begin compiling a spreadsheet of companies you’re interested in from day 1. When you apply to these companies in the future, use this spreadsheet to track your progress.

Once you have the fundamentals down, it’s time to apply your skills. One of the best ways to do that is by…

Building projects

If you’re like me, you don’t have much experience to begin with, and that’s OK! The first step is populating that empty resume with projects.

When I first decided to work on a project, I had decision paralysis for days. “What should I make? What if it’s not original? What if people don’t like it?”

Later, I realized it doesn’t really matter what the project is. Learning something and finishing what you start is much more important. But this doesn’t mean you can make whatever you want. If your project is too trivial, you won’t impress any recruiters. If yourq project is too complex, you’ll lose momentum before completing it.

Aim to do a project you think you can complete in one to two months. The project should involve data structures, algorithms, and design decisions. And do something you’re interested in so you’ll actually take it all the way to completion.

Here’s a compilation of project ideas on Reddit for inspiration.

After coming up with an idea, take some time to plan, but don’t take too long. You want to start as soon as possible. Now, you might be wondering “Isn’t it irresponsible to jump in prematurely?”

Generally, yes. But personal projects are different from company projects. Personal projects should teach you something new and strengthen your background during recruiting. Unlike company projects, you don’t need to obsess over design and code quality.

If you’re feeling stuck at the beginning, write down some code — any code. Building a personal project is like writing, you just start. Don’t worry if it doesn’t make sense. Seeing code in an editor will get your juices flowing.

Track your project with version control. If you don’t know what that is, make a Github account and learn how to use Git. You need Github as it’s the primary way you save and display your projects.

If you can, make your project live so recruiters can play with it. Most recruiters won’t inspect your code, so a live demo is the best way to show off your project.

Aim to complete three to five projects by the time you start applying.

A terrific first project is a personal website.

You learn the basics of web development and get your own space on the internet to display your work.

Codecademy has two excellent tutorials on building websites:

Make a Website teaches you the basics of HTML, CSS, and Bootstrap.

Deploy a Website teaches you how to put your website on the internet. Step 3 of this tutorial isn’t necessary, just use the free .github.io domain.

Too easy? Convert your personal website into a dynamic blog. To do this, you need to learn a web development framework like Rails or Django. Check out the Ruby on Rails Tutorial or The Django Girls Guide.

The Muse and Awwwards have examples of personal websites if you need design inspiration. Also, you have to check out this wicked personal website.

Hackathons are great for motivating yourself to do projects.

Schools and organizations around the world host hackathons, which are project-building competitions lasting several days. In this short span of time, you’ll learn a lot, come up with unique ideas, and meet interesting people.

Many hackathons reimburse travel, so there’s no excuse not to go. Use Hackalist or Hackevents to discover upcoming ones.

Some of the top North American hackathons I know of are PennApps, HackMIT, HackNY, MHacks, HackTech, HackIllinois, CalHacks, TreeHacks, Hack the North, YC Hacks, and Greylock Techfair.

You can also contribute to open source projects.

Working on open source is an awesome way to add value to meaningful projects. Plus, you learn a lot from seeing code written by more experienced engineers.

Jumping into open source for the first time can be intimidating. Two good entry points are Google Summer of Code and Sayan Chowdhury’s article on open source for beginners. Github also just released their very own open source guide. Find a cool project and dive in. You’ll get the hang of it soon enough.

Research is an alternative to projects.

If your school has a student research program, great! Apply asap. If it doesn’t have one, look up what research your professors are doing. If their work seems interesting, email them and ask if you can contribute. You’d be surprised at how receptive they are to eager undergrads.

In the future, you can even ask your team to refer you to cutting-edge companies. Keep in mind research belongs under Experience rather than Projects on your resume.

It can be tough balancing projects and school.

One complaint I hear frequently is “I don’t have time to do side projects while taking classes.” I’m personally guilty of saying that from time to time.

It’s tough to set aside time for projects because, unlike school, you’re not held accountable by deadlines and exams. After a day of studying, it’s tempting to choose social media or video games over your project. But if you keep putting it off, the semester will be over before you know it.

To combat procrastination, force yourself to work on your project a little bit every day. Even if it’s just 15 minutes, you’ll form a habit of making continual progress.

This is also why hackathons and research projects are so great. They impose external deadlines and expectations so you can’t drag your heels.

Now that you have some experience, you need to put it somewhere.

Creating a resume

Writing a resume might seem pretty straightforward, but there are lots of nuances. After all, it’s the first thing recruiters will read about you. It’s crucial to make a good first impression.

…And you need to make that impression fast. Recruiters spend an average of six seconds reviewing a resume. You heard that right. Six seconds.

Almost all that time is spent on your name, companies, job titles, start/end dates, school, major, and project titles. Everything on your resume should be tailored towards helping recruiters find these key pieces of info as fast as possible.

Here are some important guidelines.

Easy to scan.

Stick to one page.

Keep it black and white if you’re not skilled at design. Colors are noisy.

Stick to a standard format (chronological, no weird fonts, 10.5 to 12 pt font size, 0.5 to 1 inch margins). Standard formats are more readable by resume-parsing programs and easier to skim by recruiters.

Keep it concise. Text walls discourage readers.

Highlight the key points

Make your name big.

Highlight company names, job titles, start/end dates, school name, major, and project titles.

Important content should be higher up. For a student, the order of importance is usually Education > Experience > Projects > Skills.

Cut the fat.

Objective and Summary are unnecessary.

Descriptions should say something tangible. “Exceptional team player” doesn’t work. “Increased user conversion rates by 20%” does.

People without technical background will be reading your resume, so get rid of convoluted details.
Don’t neglect the details:

Include the higher of your cumulative GPA and your major GPA. If they’re both less than 3.0, leave it off.
Include links to a live demo or Github repo for each project.

Don’t include anything you wouldn’t be comfortable answering questions about. Most people make this mistake when listing their skills.

After finishing your resume, have your peers review it. Ask them to be honest and harsh. My first draft was awful compared to my tenth draft.

Use online resume builders if you’re short on time.

Standard Resume and CakeResume are two outstanding tools that make it a breeze to generate a handsome resume.

If you don’t have a LinkedIn profile, create one.

LinkedIn enables recruiters to find you and helps you maintain your professional network. Plus, you need it for the cold-emailing recruiters later.

With a few projects under your belt and resume in hand, you’re ready to begin preparing for interviews.

Getting battle-ready for interviews

Interview problems can be separated into two buckets, behavioral questions and technical questions. You need to start practicing both at least two months before applying. Since recruiting season kicks off in August/September, summer break is a good time to begin.

Behavioral questions

The purpose of behavioral questions are to find out more about your background and if you actually did what you said on your resume. Don’t take the behavioral interview lightly. A poor performance can sink your chances of getting the offer.

To ace behavioral questions, you need a strong answer to “Tell me about yourself” and three stories to handle all other questions.

“Tell me about yourself” is the most common behavioral question you’ll get and you need to crush it.
Don’t make the cardinal mistake of regurgitating your resume. Instead, tell a story.

Capture the attention of the interviewer with a strong introduction. Then, transition into a commentary about your key projects and experiences. Don’t prattle on about the details — keep it simple and emphasize the outcomes. Finally, explain why you’re interested in the position.

It’s tempting to talk about every single thing you did, but you’ll lose your interviewer. Keep it concise. Your answer should be one to two minutes long.

Prepare three stories you can tell in response to all other behavioral questions.
Typically, you’ll be asked to give examples of leadership, overcoming a challenge, or failure. Each of your three stories should show at least one of these themes.

A story needs an initial summary, a problem, three to five action steps, and a final outcome. Here’s an example.

Summary: Lead an unmotivated team to complete CS project

Problem: Two team members didn’t do their work and wanted to drop CS

Action 1: Talked to them one-on-one to understand why they’re studying CS Action 2: Told them although it’s tough now, they can succeed if they work hard

Action 3: Emphasized that they’re invaluable to the rest of the team

Action 4: Used google calendar to plan meetings and Trello to track progress

Action 5: Held social events to bring the team closer

Outcome: Finished the project and all got at least A-

This story can be used to answer any question about leadership or overcoming a challenge. Now go think of your own!

Not all your stories have to be about tech. For example, I always talk about how I helped my volleyball team overcome defeat.

With this, you should be able to pass any behavioral interview. To learn more, read the Behavioral Questions section in Cracking the Coding Interview.

Technical questions

Technical questions are the essence of the tech interviewing process. Here’s a list of topics you need to know to pass technical interviews. To master these topics, use the following four resources:

Cracking the Coding Interview (~2 months before applying)

LeetCode (~1 month before applying)

Mock interviews (~2 weeks before applying)

Glassdoor (~2 days before interviewing)

Cracking the Coding Interview is one of the best resources out there.

Gayle Laakmann McDowell’s Cracking the Coding Interview is the quintessential tech recruiting manual. First, read the Technical Questions section. Take notes to help you remember the main ideas.

As for practice questions, concentrate on the Arrays and Strings, Linked Lists, Stacks and Queues, Trees and Graphs, Objected-Oriented Design, Recursion, and Sorting sections.

Also, familiarize yourself with the Bit Manipulation, Scalability, Databases, and Threads and Locks sections.

If you’re having trouble with any of the topics, study the first couple pages of that section. They contain a short and sweet explanation of the topic.

Attempt each question for at least 30 minutes before looking at the solution. After reading the solution, you should still implement it and test it on your own. Otherwise, you won’t fully understand the logic.

Finishing CtCI should take three to four weeks of dedicated effort.

LeetCode is the second resource you should tackle.

It has a huge list of problems ranked by difficulty. Each problem has its own tests, time complexity requirements, and solutions.

Aim to complete 30 to 50 questions and be comfortable with medium level questions before you start applying. If you do just three a day, you can finish 42 in two weeks.

It’s easy to get frustrated by Leetcode at first. In the beginning, I couldn’t solve a single easy problem. I improved over time, but I still get stuck frequently on medium and hard level problems. The good thing is interviews are different from Leetcode. In an interview, you get hints if you’re stuck. Plus, deducing the correct logic is more important than writing runnable code.

Although Leetcode isn’t the best simulation of real interviews, it’s phenomenal for building problem solving intuition.

Mock interviews are highly effective if you do them right.

The trick is emulating a real interview as closely as possible.

If you’re the interviewee, be professional, ask questions, and talk out loud. If you’re the interviewer, time the interview, engage in the conversation, and write down feedback.

I suggest booking a private room on campus and grinding through back-to-back interviews. Make sure the room has a big whiteboard to draw on.

Take turns interviewing and being interviewed by a friend who’s also recruiting. Being able to understand the interviewer’s perspective will improve your own interviewing skills.

Glassdoor is an invaluable resource for company-specific info.

In most cases, you don’t need Glassdoor until a few days before your interview. Unless the company is very large, Glassdoor won’t have many specific interview questions.

Glassdoor is better for learning about the company’s general interview process. Navigate to the Interviews section and filter by the position you’re applying for. Sometimes there are different labels for the same job, so look through all of them.

Read candidates’ experiences and think through the interview questions they posted. You likely won’t get the same questions, but working through them will give you an idea of what to expect.

Making your application stand out

It’s finally time to send out applications and start seeing your hard work pay off! Recruiting season begins in August/September, but you can reach out a month or two earlier. For off-season jobs, apply at least 6 months before.

First, you need a list of companies to apply to.

If you’ve been following the tech industry, you should already have some companies in mind.

To add to your list, check out The Breakout List, Wealthfront’s Career-Launching Companies List, and the CrunchBase Unicorn Leaderboard.

For more ideas, here’s a list of 163 companies I looked at when I was recruiting.

Don’t be picky about which companies to apply to. If you think the product is interesting or you’ve heard good things about the company, then apply. Worry about choosing after you get a few offers.

The application process

I recommend first applying and interviewing for companies you’re less interested in. This is a good way to train for future interviews of companies you want more. But don’t do too many — you don’t want to burn out.

When I recruit, I try to keep the process under 3 months and not do more than 10 onsite interviews. Anything more than that, I run out of steam and my performance suffers.

When you’re scheduling your interviews, spread them out. Interviews are mentally draining, so you need time to rest in between. Companies won’t mind if you ask for a week or two before starting their process.

Once you’re ready to apply, use a 5-pronged approach:

Referrals

Emailing recruiters

Career fairs

Online applications

This list is ordered by success rate and time commitment. For example, referrals have the highest success rate but require the most time.

Referrals are the single best way to land interviews.

When an employee refers someone, that’s the golden endorsement. Referrals make up for less than 10% of applications, but 20-50% of eventual hires.

Ask your friends or older students to refer you. You can also ask employees for a phone chat or coffee to learn more about the company and request a referral at the end. Don’t be shy about this. If you get hired, the employee who referred you gets a bonus — it’s win-win for both of you.

Cold-emailing recruiters is the next best thing to referrals.

For smaller companies without a formal recruiting pipeline, reach out to an Engineering Manager instead. For even smaller companies, just email the CEO or CTO.

The easiest way to get email addresses is asking your network for recruiter contacts.

You need a LinkedIn account to find email addresses. Look up the companies you want to apply to on LinkedIn and filter their employees by recruiters. Next, install Hunter or Slik, which lets you get the email address from a LinkedIn profile.

Hunter doesn’t like it if you try to sign up using a personal email, so use your school email.

Your emails should be concise. State your interest in a position and include a summary of your background. Remember to attach your resume. To save time, make a template. You just have to change the name of the recruiter, the name of the company, and your statement of interest.

If you don’t get a reply in a week, follow up. If you don’t get a reply in another week, follow up again.

Career fairs get you face time with recruiters and engineers.

For career fairs, check which companies are attending beforehand. Jot down the ones you’re most interested in because you might not have time to talk to all of them. Print out 10 to 20 copies of your resume to pass to recruiters. Be ready to answer questions about your experiences and projects.

I recommend going early — miss class if you have to. You’ll avoid the lines and catch recruiters before they’re exhausted from chatting nonstop.

Don’t feel pressured to ask recruiters questions if you don’t have any. You won’t offend anyone if you get straight to the point and ask if they have openings.

After your conversation, make sure to get their emails so you can follow up later. Oh yeah, and actually follow up! Don’t let those business cards gather dust with the free t-shirts and drawstring bags.

For hackathons, you’ll be targeting one company you really like instead of 10 to 20. Company sponsors will set up shop at the venue. This is your in.

Before the hackathon, find the sponsoring company you want to target. When you arrive, introduce yourself to its engineers and recruiters. Use their API in your project and interact with them throughout the hackathon.

On the last day, go show them your project. Then, ask about job/internship opportunities. At this point, they’ve already seen your work ethic, creativity, and interest in their company. You’re pretty much guaranteed an interview.

Hackathons can function as indirect career fairs also. I know people who’ve landed interviews through talking to engineers and recruiters from sponsoring companies at hackathons. For more advice on this strategy, read Ryan Norton’s article.

Online applications are the easiest way to apply.

Use a shotgun approach. Most applications only ask for your resume, so it’s easy to apply to a lot of companies in one go.

Intern Supply, the Easy Application List, and your school’s career website are essential for finding open positions.

Most of the time, you don’t need a cover letter. But if the company makes the cover letter mandatory or asks for a short answer response, be careful. In this case, the company really cares about fit, so craft a meticulous response.

I’ve been burned many times by disregarding mandatory cover letters and short answers. Take your time when writing — a hurried response will show.

For applying online, I also recommend TripleByte. You first complete a coding quiz. Then, TripleByte matches you with top companies and fast-tracks you through their hiring processes. Bear in mind this resource only works for finding full-time jobs.

Conquering the interview

For many people, this is the most nerve-wracking part of the process, but there’s no need to be anxious. The interviewer is on your side (even if it doesn’t seem like it).

Before we go any further, there’s one thing you have to keep in mind.

Show enthusiasm!

Enthusiasm plays a huge role in whether you get an offer. Companies these days love to talk about how much they value culture fit. What they basically mean is they want someone who’s enthusiastic about their mission and product.

The truth is most candidates aren’t good at being enthusiastic. The best way to ensure you do it is preparing a list of things you like about the company in advance. When answering behavioral questions or asking questions, bring up the items on your list. Use the company’s blog and its Crunchbase profile to find things you can talk about.

Now, let’s go over some best practices for technical interviews.

When you first hear the problem, write it down. Then, clarify with your interviewer what you think the question is asking. Don’t assume you understood the question the first time you heard it.

Next, write down a few example inputs and outputs and verify they’re correct. This gives you time to think of a solution and provides tests you can run later.

If you need more time to think, don’t be afraid ask for a minute to brainstorm. It shouldn’t be too hard to devise a brute-force solution. Talk through it with your interviewer while thinking of ways you can improve it.

Continue bouncing ideas off your interviewer until you come up with a better solution. Explain it to your interviewer and only start coding after they’re satisfied.

While you’re working through the problem, continuously communicate your thought process. How you think is more important than the actual answer. Be outspoken, but don’t blab on endlessly. Take pauses to think and let the interviewer make suggestions.

Don’t space out or look distant. You should direct your full attention towards the interviewer to engage them. If they’re engaged, they’ll give you positive signals if you’re on track and hints if you’re not. What’s more, they’ll be emotionally invested in you and want you to succeed.

At the end of the interview, you’ll get time to ask questions. Remember an interview is two-way. Don’t just ask questions you think the interviewer will like to hear. Ask questions you actually want to know the answers to. I suggest asking about personal experiences to get more authentic answers.

Remember these tips and you’ll be ready to ace technical interviews.

The average interview process looks like this:

Coding challenge > Recruiter chat > Phone interview > Onsite interview

The process varies by company. Sometimes the recruiter chat will be first. Sometimes you won’t have a coding challenge. But the general structure is similar.

The coding challenge is a straightforward test.

It’s usually hosted on Hackerrank. I suggest doing a couple of questions on it ahead of time to get familiar with the format.

There’s no trick to the coding challenge. Pass as many tests as you can. With enough practice on Leetcode, this should be a walk in the park.

The recruiter chat is an informal conversation.

It’s usually for setting up the phone interview and answering any questions you have. You might get one or two behavioral questions. Once in a while, you might get trivia-esque technical questions like “Explain how a hashmap works.”

Candidates rarely get rejected at this stage (although I’ve managed to do just that a few times). Treat this as a chance to learn more about the company. Ask high-level questions — recruiters generally don’t know technical details.

Make sure to ask about the format of the rest of the interview process so you aren’t caught off guard by anything.

The phone interview stage is one to two rounds of technical interviews.

Sometimes you’ll do a video chat instead of a phone call. You’ll typically code out the answer in a shared editor like Collabedit.

If the connection is bad or you’re having trouble understanding the interviewer, speak up. You’re not going to get docked points, so don’t try to tough it through.

The onsite interview is three to six rounds of interviews with a lunch in between.

A day of back-to-back interviews is exhausting — get enough sleep beforehand! Onsite interviews are mostly technical, but some companies mix in behavioral and design rounds. The lunch is for you to learn more about the company, so relax a little.

During the interview, use the whiteboard to your advantage. Leave plenty of space on the right side and between the lines so you have room to make edits.

After the interview, don’t dwell on it. Thinking about it isn’t going to change the final result. Treat it as if you were rejected and continue applying and practicing.

Evaluating the offer

Congratulations! You got an offer! Give yourself a big pat on the back — you earned it.

But your work isn’t done yet. First, thank your recruiter and re-express your enthusiasm for the company. Then, ask for your offer in writing.

It’s time to negotiate.

A job offer isn’t an act of generosity — it’s a proposal to strike a deal. Naturally, a deal involves negotiation.

I’m not going to elaborate too much on negotiation tactics. Just read Haseeb Qureshi’s killer guide on negotiation.

Bear in mind some offers are non-negotiable, but it never hurts to try.

Avoid unpaid jobs. In 90% of cases, it’s not worth it. I’m all for prioritizing learning over pay, but at least work for a company that values you enough to pay you.

If you have more than one offer, congrats! You’re awesome. But now you have to make a decision.

Choosing which offer to accept is a nice problem to have. The best offer depends on the specific candidate, but here’s one universal suggestion I hope serves you well.

Make a list of 10 professional and personal goals you want to achieve in the next 10 years.

It could be anything, like paying off student loans, founding a startup, or mastering a new hobby. Choose the job that brings you closest to these goals.

Here are a couple more tips to remember:

Your future manager is vital to your career growth. Find a great mentor who will double as your champion.

Do internships at different companies to gain broader experiences. You’ll learn more and expand professional network.

Optimize for learning and growth over pay, unless the pay is really bad.

Work at one brand name company. It’ll make recruiting in the future easier, but know that it’s not the end of the world if you don’t have one.

Choice of programming language doesn’t matter. What matters is learning good engineering practices and how to work in a team.

Choose an engineering-first company with a software/hardware product.

Don’t forget about passion. It’s an amazing feeling building a product you believe in.

Conclusion

This brings us to the end of this guide. I hope that with this, you’ll be much better prepared than I was when starting a career in tech.

In the beginning, getting an offer might seem impossible, but the key is treating it as a series of milestones rather than one enormous task. If you make a little bit of progress every day, you’ll be there before you know it!

When you do get that dream job, don’t forget to give back. Share your experiences and extend referrals. Pass on the love, and we’ll all fly higher.

In this week's episode of the podcast, freeCodeCamp founder Quincy Larson discusses AI and the future of education with Seth Goldin. Among other things, Seth is co-founder of College Compendium, an education charity, and studies computer science at Yale.

Also, the quote Quincy mentioned isn't by Ben Franklin. It's by William Blackstone in 1769 who said: "the law holds that it is better that 10 guilty persons escape, than that 1 innocent suffer (innocent person be convicted)."

Seth's free "Google Like a Pro" course: https://www.freecodecamp.org/news/how-to-google-like-a-pro/

Seth's free "The Ethics of AI and ML" course: https://www.freecodecamp.org/news/the-ethics-of-ai-and-ml/

Follow Seth on Twitter: https://twitter.com/seth_goldin

Seth's recommended article "ChatGPT is a Blurry JPEG of the Web": https://www.newyorker.com/tech/annals-of-technology/chatgpt-is-a-blurry-jpeg-of-the-web

Klara and the Sun book Seth recommended: https://en.wikipedia.org/wiki/Klara_and_the_Sun

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

On this week's episode of the freeCodeCamp podcast, Abbey chats with front-end developer Joe Previte who lives and works in Arizona. Joe shares the story of how he made the tough decision to leave grad school, how he discovered coding, and how he stays motivated and continues to learn.

On today's episode of the freeCodeCamp.org podcast, Abbey chats with Jennifer Bland, a Google Developer Expert, software engineer, prolific speaker, entrepreneur, and world traveler. You'll learn how Jennifer got into tech (twice!), what she's working on now, and how she helps many different communities of developers learn and grow.

Find Jennifer on Twitter: https://twitter.com/ratracegrad

Check out Jennifer's podcast: https://www.codeprep.io/podcast/

A bit more about Jennifer:

Jennifer Bland is a senior software engineer out of Atlanta, Georgia. Jennifer has a fascinating background - she started in tech at an early age after studying computer science in school, but then left the field, worked elsewhere, and retired at the age of 51.

Once she had some time to explore other interests, she rediscovered programming - through a JavaScript book on the clearance table at a local bookstore.

A number of years later, she's now working on some very exciting tech at Stanley, Black and Decker, she's an extremely active volunteer in her local tech community, she's on the leadership team for Women who Code Atlanta chapter, she speaks at numerous conferences, and she's recently become a Google Developer expert!

So in this episode, you'll hear about how she got to where she is, what she's passionate about, and her advice for getting into tech, conquering those pesky whiteboard interviews, how to network if you're an introvert (like she is) and much more...

Quincy interviews Jeff Meyerson, the creator and host of the Software Engineering Daily podcast.

Jeff grew up in Texas, played competitive poker, and ultimately worked as a software engineer at Amazon.

We talk about how he got into tech, how left Amazon to become an entrepreneur, and the many lessons he learned along the way.

Follow Jeff on Twitter: https://twitter.com/the_prion

And subscribe to software engineering daily: https://softwareengineeringdaily.com

Everyone makes mistakes, especially when they're first learning a new skill or tool. If you've just entered the world of programming, chances are you'll make your fair share of mistakes, too. In this episode, Jack discusses some of the missteps he's taken early on in his career, and how you can learn from them and avoid them.

Written by Jack Finlay

Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

Original article: https://fcc.im/2mOhFfY

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript:

When you first start out in the world of software development, things may seem daunting and unknown. Leaving university and venturing into the real world is a big step, and you will stumble many times on the path before finding your feet and confidence.

You may have confidence in your abilities already. But I ask you, “How many mistakes have you made?”

The start of a career in software development is the start of a journey in mastering your craft. As with any field, there will be challenges and chances to be correct, and chances where you can be completely wrong. This piece acts as a reflection on the mistakes I have made early in my career — and a guide to avoiding them.

Getting the job

Landing your first job out of university isn’t always easy. Make sure it’s the right one for you.

A company has to be a good fit for you, and where you want your career to go.

Find out what you are worth

I made this mistake twice. When I got my first software development job during university, in my second year, I was struggling financially. This led me to accept the first salary offer I was given. I felt I needed to just take the offer, as it was great compared to the abysmal pittance I was receiving from student benefits. Little did I know that it was well under the market rate for the location, position, and time.

As I said earlier, I made this mistake twice. Upon graduating, I managed to land a job elsewhere. They were going to pay me 25% more than I was earning at the time!

It was still at the low end of the market rate. I was low-balled, and I was happy to take it. I hadn’t learned yet that not all the power is in the employer’s hands.

You too can make an offer. If I had taken the time to do some proper research, I would have seen what I was really worth. I recommend sites like PayScale to give you an indication. You can even use sites like this as a source when negotiating.

Read the reviews

Glassdoor is a great resource. Real employees of the companies listed have taken the effort to rate the companies they work for. Generally the reviews can be quite polarized as to whether employees have had good or bad experiences.

Search out some of each and you’ll find the middle-ground for yourself. Had I read some of these reviews earlier, I would have avoided some terrible experiences when interviewing and beyond.

Know what you’ll really be working with

Earlier in my career, I was so keen to work for a particular company (a friend was working there and was enjoying it) that I forgot to stop and ask what I would actually be working on. It turned out that I would not be in the same department as my friend, and that I would be on the other side of the building, and later even on different floors. And I didn’t take the time to make sure the job would really fit me.

Another side of this mistake was not asking enough about the environments, tools, and languages I would be using.

When going for the next step in my career, I made sure to ask about the following:

Version control strategy and tooling
Is it industry standard? Git, TFS, SVN or Mercurial? If you’ve heard of it, it should be okay.

Is there CI/CD tooling and environments in place?
Deployments should be as automated as possible. It’ll make your life so much easier.

How often are deployments?

What frameworks/languages will I be working in?

What tooling do you use? Which IDE?
Visual Studio, Rider or IntelliJ are some good options.

What kind of projects will I be working on?

What kinds of technologies will the company be looking to use next? Also, what kind of horizon are these changes at?
How far off are they from becoming day-to-day in use at the company?

In the job

The challenges don’t stop once you are in the job. Every day will present some new way to challenge you.

Code is never self documenting

“My code is self-documenting, I don’t need comments”. 😒 I thought this when I first started programming professionally. I don’t make this mistake anymore.

Comments are the most powerful feature of any language. They can convey where your thoughts were at the time. You need to capture that in comments.

I’ve read countless sections of code where a single, simple comment would have made that complex code and the algorithms much easier to understand and update.

Commented out code is worse than no comments at all. When you are deep in investigation mode, trying to discover how something works, all that commented out code will do is make your job harder. As soon as you comment out a line, the next person to read it will have no idea why you did that.

Be judicious with your comments. Good comments will not only lighten the cognitive load, they will help you spot errors.

If something doesn’t look like it matches up to the comment, it’s probably wrong. Or it’ll give you a good chance to put the following section into practice.

Ask questions early

Don’t wait until you are down the wrong rabbit-hole before asking for help.

Waiting to ask for help may just lead you to the wrong conclusions, or worse, you’ll break something. Ask questions early, even if it’s just a quick Google search. Part of not asking questions when you really need to, through fear of appearing like an idiot, is how you end up building the wrong thing.

Asking questions is one of the most important things you can do to accelerate your learning, and to help get involved in projects right away. If you don’t ask questions when you need to, you may make some wrong assumptions.

Assume nothing

Assumptions are an important part of defining what you need to be building when you are working on a project. There will often be assumptions recorded against the tickets you’ll be working on (if your company uses a ticketing or task system).

Not every case has to be catered to when you’re designing a solution. A correct set of assumptions will help guide you towards the correct solution.

I have spent hours building things incorrectly and even building the wrong thing because I made incorrect assumptions. Usually, tasks will be quite fleshed out when they arrive from the Business Analysts, but often there will be gaps.

Don’t make any assumptions unless they have been stated for you, or you’ve asked about them.

Working from home

Don’t be afraid to ask to work from home every once in a while. Sometimes it’s a great way to get away from the stresses and distractions of the office and really focus. There are whole companies built on a remote workforce. It certainly works.

There will also be some companies that are fully against it. I worked for over a year with a team in Australia, from our office in New Zealand. Collaboration and cooperation still happened online. Through email, chat, and old fashioned phone calls, distance doesn’t stop you working with your peers. There was no practical difference whether I was in the office or at home, but I was forced to be at the office anyway.

Look out for the opportunity to spend the day working from home or somewhere different wherever possible.

Time actually programming

Unfortunately, you will not be programming 100% of your week. As much as this may pain you, it’s not all bad. Programming isn’t 100% code anyway.

Much of your time will be spent in meetings, usually to the point of reducing the amount of time you need to spend programming. This comes through making sure that you are writing the minimum amount of code possible to engineer the best possible solution.

Outside the job

Some say that it doesn’t really matter, but others say that what you do outside the job is just as important as what you do in the job.

Programming on your own time

Once I realized the crushing reality of how terrible proprietary tooling and languages really are, I started to work on skills that I knew would be transferable to another company.

If you find yourself stuck in the same type of environment, knowing a few things about more mainstream technologies will help you in finding your way out. It’s a polarizing opinion, but I believe that time spent on career development in your own time has a great effect on the opportunities you will become open to.

Read

Now I have made my way through a few, I wish I had picked up some more books earlier. There are countless things to learn from books. Grab a few and read them on your downtime, at the office, or on your way there. Most people I know have some kind of commute, and it’s a great way to pass the time.

Write

Writing can be a great way to further your career. That’s what I’m attempting here. This isn’t just an advice piece, it’s a reflection. A good blog can also help you when you face a particular issue you may have faced before. If you keep a log of what has challenged you, it may just come to your rescue.

It may seem strange at first, but writing things down is a great way to decompress and exhale after stress. I make (most of) my writings public, but you don’t have to. Half of my posts are still sitting in the drafts folder.

Exercise

For the first two years of my career I didn’t regularly exercise and it certainly caught up to me. As a programmer, most of your day will be spent sitting, generally inactive, staring at a screen. You will not get to program all day, sure, but between meetings and time at your desk, you won’t be moving much. Try to exercise as much as you are capable of.

Taking some time off

As important as it is to be available all the time for work, it’s also important to take some time off every now and then. If you are not saving up for a big holiday, it’s sometimes nice to just make long weekends extra long, or take a few days off here and there. Many countries provide a varying number of guaranteed weeks of leave. Make sure to take advantage of this wherever possible.

I made the mistake of saving up as many leave days as possible and getting burned out in the process. It was a good decision financially, but not for my mental and physical well-being.

Thanks for reading!

I hope this reflection of my first two years of programming as a full-time job provides some insight into where you may head in your career. This has been an interesting reflection for me, and I hope you can take something from it.

In this episode, Abbey interviews social engineering expert Rachel Tobac and learns how she transitioned from teaching to infosec by way of one exhilarating competition. 

Growing up, Rachel’s family didn’t have normal dinner table conversations. Her father was in medicine, so their chats revolved around strange diseases and scary edge cases. So when Rachel went to college, she aimed to follow in her father’s footsteps.

However, life had other plans, and she ended up becoming a teacher instead. But she wanted to do more than teach a small number of students – she wanted to help more people at scale. So she tried to figure out a way to do that. 

After moving across the country to Silcon Valley and learning more about the world of tech, she stumbled upon her true calling (with a little nudge from her husband and now co-founder): social engineering. She took a trip to Defcon four years ago, won second place in a social engineering capture the flag hacking event, and she was hooked.

She dove in head first, learned all she could about infosec, social engineering, and security, and never looked back. Now, she and her husband run Social Proof Security, the boutique educational security firm they founded two years ago, and boast some of the largest tech companies in the Valley as clients. Rachel is also chair of the board of the non-profit WISP (Women in Security and Privacy), helps get scholarships for women to attend Defcon each year, and travels and speaks at all kinds of conferences and events herself. 

When she isn’t educating companies about making their processes safer, she’s traveling the world, thinking up new ways to hack, or staring at her rescue dog. 

In this episode, you’ll learn all about Rachel’s somewhat meandering path into security, how she discovered her passion for educating teams about social engineering, what it takes to get into the field, and why she loves her job.

Find Rachel on Twitter: https://twitter.com/RachelTobac

Check out Rachel's company: https://www.socialproofsecurity.com/

Learn more about DefCon: https://www.defcon.org/

Read up on WISP: https://www.wisporg.com/

Find Abbey on Twitter: https://twitter.com/abbeyrenn

Today I'm joined by Malindi Colyer. Among her many skills, she's a Python developer and AI engineer.

Malindi grew up on a farm in rural Kansas, in the middle of the US. She trained to become a diplomat, and volunteered overseas. But along the way, she discovered a love of math and computer science. That passion has landed her jobs in New York City, London, and San Francisco.

I met up with Malindi in downtown Manhattan to learn all about investment banking, and how she modernized her department at JP Morgan using her software engineering skills. We talk about the high-stakes world of global finance, where she was executing trades sometimes worth hundreds of millions of dollars.

We also talk about her time as a venture capitalist. She researched thousands of startups to decide which ones her fund should invest in.

This is one of the most technical interviews I've done. I've done my best to make Malindi's world of math, AI, and high finance as accessible as I can. I hope you enjoy it.

Malindi on LinkedIn: https://www.linkedin.com/in/alexandra-malindi-colyer-46b95589/ 

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Ben Awad, a game developer who creates developer tutorials on YouTube and TikTok.

I hope you enjoy our conversation. Can you guess what bass line I'm playing on my bass during the intro? It's from a 1979 song.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

Also, I want to thank the 8,983 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during the interview:

Ben's game, Void Pet on Android and iOS (Built in React Native): https://voidpet.com/

XKCD coming on "Real Programmers" that Quincy mentions: https://xkcd.com/378/

React Native course by Ben Awad: https://www.freecodecamp.org/news/create-an-app-that-works-on-ios-android-and-the-web-with-react-native-web/

I can't find my Mac Control hotkeys video tutorial that I mentioned anywhere, so I wrote a quick article explaining how to use these: https://www.freecodecamp.org/news/mac-control-keyboard-shortcuts-hotkeys-that-work-everywhere-in-macos/

Today I'm joined by Joel Spolsky. He's co-founder of Trello and Stack Overflow, and author of the iconic developer blog Joel on Software.

I hung out with Joel in his New York City home to discuss his 4-decade-long career as a developer and a CEO. He shared his insights on software engineering, product design, running companies, and how he uses AI as a tool.

This interview is the culmination of years of learning from Joel through his blog and using the tools he's helped make. I hope you enjoy it as much as I did.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

The Joel Test: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/

Making Better Software video course series from the early 2000's playlist on YouTube: https://www.youtube.com/watch?v=wBfisaHMr-8&list=PLcIkt5s7w8D0ywp0CBmNFWRTFZic3pWNn

The ESP-32 microcontroller Joel mentioned: https://en.wikipedia.org/wiki/ESP32

On this week's episode of the freeCodeCamp podcast, Quincy interviews Shawn Wang (@swyx). We talk about "learning in public" and his transition into tech from finance, where he left behind a job that paid him US $350,000 per year.

Shawn grew up in Singapore and came to the US as a college student.

He worked in finance, but at age 30, he burned out. So he decided to learn to code. He used freeCodeCamp and a ton of other resources, and since then he's worked as a freelance developer, and at several companies including Netlify.

Follow Shawn on Twitter: https://twitter.com/swyx

Follow Quincy on Twitter: https://twitter.com/ossia

Here are some links we discuss in the interview.

Shawn's Projects:

The official React subreddit that Shawn moderates: https://reddit.com/r/reactjs

Shawn's article on No Zero Days: https://www.freecodecamp.org/forum/t/no-zero-days-my-roadmap-from-javascript-noob-to-full-stack-developer-in-12-months/164514

Job Search / Salary Negotation articles:

Cracking the Coding Interview: https://fcc.im/2UihbNm

Hasseeb Qureshi's story of getting a $250K/y developer job at Airbnb: https://haseebq.com/farewell-app-academy-hello-airbnb-part-i

Steve Yegge's "Get that job at Google" essay: http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html

Patrick McKenzie on Salary Negotiation https://www.kalzumeus.com/2012/01/23/salary-negotiation/

Quincy's recommended article: I spent 3 months applying to jobs after a coding bootcamp. Here's what I learned: https://medium.freecodecamp.org/9a07468d2331

Algorithm Expert: https://www.algoexpert.io

Full Stack Academy https://www.fullstackacademy.com

Shawn's Learn In Public movement:

Shawn's Learn In Public essay https://gist.github.com/sw-yx/9720bd4a30606ca3ffb8d407113c0fe5‌‌

Kent C Dodds' Zero to 60 in Software Development: How to Jumpstart Your Career https://www.youtube.com/watch?v=-qPh6I2hfjw&app=desktop‌‌

Cory House on Becoming an Outlier: https://vimeo.com/97415346‌‌

Brad Frost on Creative Exhaust: http://bradfrost.com/blog/post/creative-exhaust/‌‌

Patrick McKenzie on the origin of the word "friendcatcher": https://news.ycombinator.com/item?id=511089‌‌

Chris Coyier on "Working In Public": https://chriscoyier.net/2012/09/23/working-in-public/

Links to other things we discuss:

Shawn's Software Engineering Daily Interview with Sacha Greif: https://softwareengineeringdaily.com/2017/08/09/state-of-javascript-with-sacha-greif/‌‌

The origin of No Zero Days: https://www.reddit.com/r/getdisciplined/comments/1q96b5/i_just_dont_care_about_myself/cdah4af/‌‌

John Resig, creator of jQuery, telling his team to rip out jQuery: http://bikeshed.fm/180

‌‌Jeff Bezos' Two Pizza Team rule: https://buffer.com/resources/small-teams-why-startups-often-win-against-google-and-facebook-the-science-behind-why-smaller-teams-get-more-done‌‌

Shawn's "You can learn so much on the internet for the low, low price of your ego" quote draws from Paul Graham's Keep Your Identity Small: http://paulgraham.com/identity.html‌‌

Shawn's Impostor Syndrome Bootcamp Podcast: https://player.fm/series/impostor-syndrome‌‌

TypeScript's growth via npm surveys: https://mobile.twitter.com/seldo/status/1088240877107965953

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Dr. Chuck. He's a software engineer and Computer Science professor at University of Michigan, which has one of the top-ranked CS programs in the world. 

Dr. Charles "Chuck" Severance is also creator of many popular free learning resources like his Python for Everyone and C for Everyone, which millions of students have taken over the past decade.

We talk about:
- What seperates a Master Programmer from an average developer, and how to become one
- Dr. Chuck's mission to make programming knowledge freely available
- The fundamental shortcomings of how Computer Science is currently taught at universities – even elite universities like the one he's a professor at
- Dr. Chuck's theories on recent tech layoffs and what he thinks the near future holds
- Dr. Chuck's love of racing $2,500 "lemon" cars that he revives from the junk yard, and flying planes

Can you guess what song I'm playing on my bass during the intro? It's from a 1973 song.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

Also, I want to thank the 9,331 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during our conversation:

- Dr. Chuck's latest freeCodeCamp course on C programming: https://www.freecodecamp.org/news/complete-c-programming-course-from-dr-chuck/

- Dr. Chuck's Python for Everyone freeCodeCamp Course: https://www.freecodecamp.org/news/python-for-everybody/

- Kylie Ying's popular Machine Learning for Everyone course inspired by Dr. Chuck: https://www.freecodecamp.org/news/machine-learning-for-everybody/

- Dr. Chuck's website with his free interactive coursework: https://online.dr-chuck.com/

This week, for the last podcast episode of 2019, Abbey chatted with freelancer and content creator Jessica Chan - known as CoderCoder on social media - about how she got into tech and started her educational website and YouTube channel.

Today I'm talking with Sasha Sheng. She's a software engineer who worked at Yahoo and at Facebook. During her 9 years working at big tech companies in San Francisco, she worked on mobile apps and AI systems.

Sasha grew up in rural China, and was the first person in her family to attend university. She studied hard and was able to get into one of China's most competitive schools. She was able to move to the US and finish out her Mechanical Engineering degree at University of Michigan.

When Sasha got laid off 8 months ago, she hit the ground running. She immersed herself in learning the new wave of AI tools. And she applied those new skills at hackathons, winning several competitive events.

I caught up with Sasha to hear her thoughts on AI engineering, AI safety, and how we can get more women into tech.

If you dig this podcast, be sure to leave us a review. I'm excited to read any feedback you have for me. 

Check out Sasha on Instagram: www.instagram.com/hackgoofer

Follow Sasha on Twitter: and www.twitter.com/hackgoofer

One of Sasha's Hackathon projects: Chat Out Loud: https://github.com/ytsheng/chat_out_loud_gpt

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Scott Hanselman. Scott's a developer at Microsoft, a prolific teacher, and has hosted the Hanselminutes podcast for nearly two decades.

We talk about:

- How he leads a fully-remote team from his home of Portland, Oregon

- His 11-year journey to getting his degree

- What he learned from teaching programming at community college

- What he's learned about software development from recording 980 podcast interviews across 20 years

Can you guess what song I'm playing on my bass during the intro? It's from a 1994 punk song.

Also, I want to thank the 9,779 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during our conversation:

- Scott's Hanselminutes Podcast: https://www.hanselman.com/podcasts

- A personal tour of Lotus Notes founder Ray Ozzie's computer artifacts: https://www.youtube.com/watch?v=c4awQH6WhP4

- Scott on Twitter: https://twitter.com/shanselman

I interview Bruno Haid. He's a software engineer and tech founder from Austria.

We talk about growing up in the European countryside, his early passion for computers, and ultimately his move to San Francisco, where he's founded several tech companies.

Bruno's super excited about embedded systems and custom hardware. He's building home appliances that incorporate open source software and open datasets.

We talk about so many topics here. From Star Trek to the European Pirate Party.

I hope these weekly freeCodeCamp podcasts are firing you up about learning more about technology.

Tell your friends about the freeCodeCamp podcast. Let's inspire more folks to learn to code and build careers for themselves in tech.

A couple interesting links from our discussion: 

"Only Amiga" song from Comdex 1987: https://www.youtube.com/watch?v=PWeO5IkCssk

Halt and Catch Fire TV Show trailer: https://www.youtube.com/watch?v=pWrioRji60A

Dhawal Shah is creator of Class Central, a popular search engine for online courses.

Dhawal talk about the history of online courses and the Massive Open Online Course revolution of the early 2010s. We also talk about his childhood growing up in India, and how his life changed one day when he won a computer from a Cartoon Network sweepstakes.

Tell your friends about the freeCodeCamp podcast. Let's inspire more folks to learn to code and build careers for themselves in tech.

Links we discussed:

Dhawal's article: Here are 850+ Ivy League Courses You Can Take Right Now for Free: https://www.freecodecamp.org/news/ivy-league-free-online-courses-a0d7ae675869/

Dhawal's article: I uncovered 1700 Coursera Courses that Are Still Completely Free: https://www.freecodecamp.org/news/coursera-free-online-courses-6d84cdb30da/

Dhawal on Twitter: https://twitter.com/dhawalhshah

Dhawal's 3 recommended Massive Open Online Courses:

- Learning How to Learn: Powerful mental tools to help you master tough subjects: https://www.classcentral.com/course/learning-how-to-learn-2161

- University of Alberta's Mountains 101 Course: https://www.classcentral.com/course/mountains-101-7455

- Stanford's Data Structures and Algorithms Course: https://www.classcentral.com/course/algorithms-18869

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Rahul Pandey. He's a software engineer who left his $800K / year FAANG job to build his own startup.

We talk about:

- The post-layoff developer job landscape
- Developer interviews and how to differentiate yourself
- Why salary negotiation still makes sense
- His belief that 10x engineers exist – and even 100x and 1000x engineers

Can you guess what song I'm playing on my bass during the intro? It's from a 1969 mowtown classic.

Also, I want to thank the 10,443 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during our conversation:

- Rahul's Android app tutorial on freeCodeCamp (4 hour watch): https://www.freecodecamp.org/news/learn-how-to-build-and-publish-an-android-app-from-scratch/

- Rahul's video about post-college job offers: https://www.youtube.com/watch?v=rceUVaiXQgU

- Taro, Rahul's company: https://www.jointaro.com/

- The story of a software engineer who moves back to India to run his father's chemical business after his death: https://anandsanwal.me/2018/06/19/dad-company-sale/

- Conference talk about the correlation between interest rates and developer hiring, by Pragmatic Engineer: https://www.youtube.com/watch?v=VpPPHDxR9aM

- Rahul on LinkedIn: https://www.linkedin.com/in/rpandey1234/

Quincy Larson interviews Lyle Troxell, who's a senior software engineer at Netflix.

Lyle has hosted his own technology radio show for the past 18 years, and now he hosts the official Netflix podcast, too.

Lyle's parents were artists and a part of the 1960s hippy movement. Lyle didn't enjoy school, and in middle school he dropped out so he could focus on learning math and electronics. He eventually went to community college, got a 2-year degree, and did some basic web design work at a few companies during the dot com boom of the late 1990s.

Lyle spent the next 11 years as a teacher and administrator at University of California in Santa Cruz. Eventually he decided he wanted get into software development. He was able to dust off his skills and through a remarkable series of events get a software engineer job at Netflix.

Lyle and Quincy have known one another for years and had a lot to talk about, including the story behind how he built Apple co-founder Steve Wozniak's personal website.

Interview by Quincy Larson: https://twitter.com/ossia

Intro music by Vangough: https://fcc.im/2APOG02

Quincy Larson interviews Sacha Greif, who's a designer, developer, and prolific open source project creator.

Sacha created the Vulcan.js framework, the Sidebar.io daily design newsletter, and so many other important projects in the developer community.

Most recently, Sacha started the State of JavaScript survey, where he asks developers a ton of questions about which web development tools they use. He just finished the third annual survey, and soon he'll release the results from the more than 20,000 developers who took the survey.

Sacha grew up in Paris. His grandparents were Jewish refugees who fled to France from Poland during World War II. Sacha's father was an author who wrote books about computers, and shared this passion with his son.

Sacha has spent much of his adult life living abroad in China, Switzerland, and Japan. He and his wife currently live in Kyoto and they just had their first child.

During this interview, Sacha talks about how he got his start as a professional developer in Beijing, then got deeper and deeper into user interface design. He shares how his passion for both of these disciplines resulted in him creating so many important open source projects.

Sacha also talks about how he followed in his father's footsteps and wrote the "Discover Meteor" book - the most popular resource for Meteor.js - and how the book's financial success helped bankroll his other projects.

Sacha Greif is one of the most prolific developers I know. And it was a blast getting to learn more about his coding journey. So without further ado, here's Sacha.

Interview by Quincy Larson: https://twitter.com/ossia

Intro music by Vangough: https://fcc.im/2APOG02

Tim Myers is a developer from Denver. In the 1990s he finished high school and immediately enlisted in the US Army. When he got out, he started coding. He was working as a developer at an accounting firm when he got into a drunken brawl and ended up injuring somebody.

Tim was convicted of 2nd degree assault and got a 12 year prison sentence. He earned his college degree entirely while in prison, and was released after 8 years for good behavior.

He spent the next 3 years working various jobs like fast food while studying to get back into software development. And for the past 4 years, he's worked as software developer at several Denver companies.

In today's episode, Quincy interviews Tim about his journey from convicted felon to developer and family man.

Follow Tim on Twitter: https://twitter.com/denvercoder

Follow Quincy on Twitter: https://twitter.com/ossia

Help our community spread the word the old fashion way - tell a friend about this podcast.

CS50 is the most popular course at Harvard, and hundreds of thousands of people have taken the free online version of the course as well.

We recently posted the lectures for the course on freeCodeCamp's YouTube channel - including the CS50 game development course - all free and commercial-free.

During this interview, David Malan and Colton Ogden talk about how they got into technology. They share tips for how to effectively learn computer science, and some advice for teachers and community leaders as well.

Colton shares one of his favorite game development hacks, and David tell us the story behind the CS50 catchphrase: "this is CS50"

Follow CS50 on Twitter: https://twitter.com/cs50

Subscribe to the CS50 podcast: https://podcasts.apple.com/us/podcast/cs50-podcast/id1459708246

Test out CS50's Integrated Development Environment: https://ide.cs50.io/

And CS50's Sandbox: https://sandbox.cs50.io/

The article Colton mentions about Resident Evil 2 on N64 (PDF): https://twvideo01.ubm-us.net/o1/vault/GD_Mag_Archives/GDM_September_2000.pdf

The Steve Ballmer CS50 guest lecture: https://www.youtube.com/watch?v=7lhlKF6MECs

And Steve Ballmer's sales pitch of CS50 itself: https://www.youtube.com/watch?v=El2mr5aS8y0

Fun fact: Brian Kernighan, whom David mentions as the CS50 teacher who preceded him, is also the co-creator of the C programming language. He's even has his own card in freeCodeCamp Programmer Playing Cards: https://www.freecodecamp.org/news/introducing-programmer-playing-cards-d3eeeffe9a11/

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews John Washam, a software engineer at Amazon. John's also creator of one of the most popular open source projects of all time, Coding Interview University.

This is John's first-ever podcast interview, and the first time he's told his story. Interviewing him was an absolute honor.

We talk about:

- How John delivered pizzas to save enough money to buy his first computer in the 90s. "I was tired of being a broke kid."

- John's first career in the US military, where he worked as a translator in South Korea

- How John crammed Computer Science for 8 months and taught himself enough theory and coding skills to get a job in big tech, then published Coding Interview University on GitHub

- What it's like to work as a senior developer at a big tech company, and what you can expect the journey to be like

Can you guess what song I'm playing on my bass during the intro? It's from a 1986 rock song.

Also, I want to thank the 9,779 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during our conversation:

- Coding Interview University: https://github.com/jwasham/coding-interview-university

- The Starup Next Door, John's blog: https://startupnextdoor.com/ 

- Follow John on LinkedIn: https://www.linkedin.com/in/johnawasham/

- The Talent Code, the book John recommends: https://www.amazon.com/Talent-Code-Greatness-Born-Grown/dp/055380684X

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Emma Bostian. She's a software engineer turned manager at Spotify and Prolific coding teacher.

We talk about:

- How at her first developer job at IBM, Emma's boss told her: "You need to get your stuff together or you won't make it in this industry." And the transformation that followed.

- Emma's thoughts on Computer Science degrees. "Going to college gives you credibility and a network. You can get opportunities that way."

- How Emma hires software engineers. (Hint: she tries to disregard degrees completely.)

- How Emma intentionally procrastinates some big tasks to give her mind time to figure out the puzzle pieces

Can you guess what song I'm playing on my bass during the intro? It's from a 1979 punk song.

Also, I want to thank the 10,776 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during our conversation:

- Emma on Twitter: https://x.com/emmabostian

- The Ladybug Podcast about women in tech that Emma helped host for several years: https://www.ladybug.dev/

On this week's episode of the podcast, I interview Jabril. He's an indie game developer who's building a turn-based fighting game called ultrabouters.

Jabril has developed tons of other games as well. He runs the popular Jabrils gamedev focused-YouTube. He's also published a 5-hour introduction to programming course on freeCodeCamp.

We talk about:

- How Jabril got into gamedev as a kid when he got a copy of GameMaker
- Jabril's career working at a comedy club and a radio station
- The anime that Jabril's been working on for years
- Jabril's advice to gamedevs who want to make a career out of building video games

Can you guess what bass line I'm playing on my bass during the intro? It's a 2009 song that became popular in the 2010's by being associated with a meme.

Be sure to share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

Also, I want to thank the 8,909 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during the interview:

Jabril's full length Programming for Beginners course on freeCodeCamp: https://www.freecodecamp.org/news/programming-for-beginners-how-to-code-with-python-and-c-sharp/

That time Quincy angered the entire BTS army with a confused tweet: https://twitter.com/ossia/status/993171422863417344

"The best episodes of Shark Tank are the bad ideas." How Jabril created a Fake Shark Tank Episode Generator using AI tools: https://www.youtube.com/watch?v=gcGjYivktyc

Subscribe to Jabril on YouTube: https://www.youtube.com/@Jabrils

In this week's episode of the freeCodeCamp podcast, Abbey chats with Madison Kanna, a full-stack developer who works remotely for Mediavine. Madison describes how homeschooling affected her future learning style, how she tackles imposter syndrome and failure, and how she helps others teach themselves to code.

In this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Robby Russell. Robby created the open-source project Oh My ZSH. 

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

Links we talk about during the interview: 

- Robby reading his classic "d'Oh My Zshell" article recording on an older freeCodeCamp podcast episode: https://freecodecamp.libsyn.com/site/ep-34-doh-my-zsh

- The Sandi Metz interview episode of Maintainable that Robby mentions: https://maintainable.fm/episodes/sandi-metz-making-is-easy-mending-is-a-challenge

- The Mighty Missoula (Robby's Post Rock band) live set: https://www.youtube.com/watch?v=63DE2tNlAWY

- Planet Argon, the software development consultancy Robby co-founded two decades ago, and is CEO of: https://www.planetargon.com/

On this week's episode of the podcast, freeCodeCamp Founder Quincy Larson interviews Leon Noel, founder of 100Devs and head of engineering at Resilient Coders.

Growing up, Leon had it drilled into him that he had to become a doctor, lawyer, or dentist. But his ambitions grew and he went on to have an exciting career in tech.

After a successful exit from a startup, Leon wanted to help folks who were struggling during the pandemic. He started 100Devs, a charity which has helped 10,000s of people learn to code.

We talk about:

• dropping out of Yale
• getting into the selective Tech Stars startup accelerator
• Getting involved with Resilient Coders, a charity that helps court-involved youth learn coding
• Starting 100Devs and building a Discord server with 60,000 people learning to code together

Quincy recorded this podcast live and hasn't edited it at all. We want to capture the feel of a real live conversation, with all the human quirks that entails.

Can you guess what song he's playing on my bass during the intro? It's his arrangement of the intro to a 1990s cartoon.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

Also, we want to thank the 8,427 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during the interview:

The video that changed Leon's life on Spaced Repetition, by Ali Abdaal: https://youtu.be/Z-zNHHpXoMM

The official Anki app, which is free on web / desktop and doesn’t lock you into a subscription. Leon's advice: "Only create cards on one device, but review on any to save you from weird syncing issues." https://apps.ankiweb.net

Dr. Barbara Oakley’s Learn How to Learn course, which Leon calls "a masterpiece": 
https://coursera.org/learn/learning-how-to-learn

The 100Devs website (new cohort starting in early May): https://100devs.org/about

Trailer for X-men '97: https://youtu.be/pv3Ss8o9gGQ

Thelonious Monk [pianist Quincy mentions] "Straight No Chaser" documentary trailer: https://www.youtube.com/watch?v=dx0E9-ThvKc

Leon on YouTube: http://leonnoel.com/youtube

Leon on Discord: http://leonnoel.com/discord

Leon's Twitch for his live streams: http://leonnoel.com/twitch

Leon's website: https://leonnoel.com/

In this episode of the freeCodeCamp podcast, Abbey chats with developer advocate Alejandra Olvera-Novack about how she broke free from her restrictive cult upbringing, moved to the United States, and taught herself how to code.

Alejandra was raised without technology, without formal schooling, and in an extremely conservative environment. When she was in her late teens, she left her village and moved to Florida. 

After a couple years of googling everything under the sun to catch up on the world's events, and trying to attend college, she ran out of money. Since she was alone - having cut all ties with her family - she took a leap of faith, moved to Seattle, WA, and started looking for work.

She worked odd jobs for a while, but quickly realized she'd need something more to survive and thrive. So she started to learn about HTML and CSS, something she never thought she could do. Fast-forward a couple years later, and she was working her way up to a job at Amazon Web Services.

Today, Alejandra works with robots, helps developers be as happy and productive as possible at AWS, and runs the non-profit she founded that teaches women, minorities, and disabled how to code for free. She manages her anxiety and PTSD with the help of a service dog and some really great mentors and friends, and she still can hardly believe she's living her dream.

Find Alejandra on Twitter here: https://twitter.com/QuetzalliAle

Visit her website here: https://alejandraquetzalli.com/

Check out SheCodesNow, Alejandra's non-profit here: https://twitter.com/shecodesnow

Find Abbey on Twitter here: https://twitter.com/abbeyrenn

#94 Killing Cancer with Machine Learning with Dr. Amit Deshwar

 Today I'm joined by Dr. Amit Deshwar. He uses machine learning to discover new drugs to cure various diseases including cancer. He's a scientist who works in the growing field of Computational Biology, and has risen through the ranks at the Canadian biotech company Deep Genomics.

During College, Amit got two internships at Google as a platform engineer. He then decided rather than working in big tech he wanted to go back to school and get his Ph.D. He studied Electrical Engineering and Computer Engineering at the University of Toronto, and had his work published in Nature, one of the most prestigious scientific journals.

I met up with Amit at the Glen Park library in San Francisco, at the exact table where the FBI arrested notorious Slik Road Darknet marketplace founder Ross Ulbricht. 

We talk about how scientists and developers use machine learning to speed up drug discovery. I ask him a lot of my totally naive questions about how these therapies work and how they can fight various types of cancer and other diseases.

Photo of Amit arresating me at the Glen Park Library where the FBI arrested Ross Ulbright: https://drive.google.com/file/d/15B8HD4SGErnOd8zA-9gYW2MabAQFG58Q/view?usp=sharing

Photo of me arresting Amit:  https://drive.google.com/file/d/1OWyaVyzqT8YgLFYUVi5kqY9te6ShSdgr/view?usp=sharing

Amit on Google Scholar: https://scholar.google.com/citations?hl=en&user=QGCYxysAAAAJ

Amit's Twitter: https://twitter.com/amitdeshwar

Dylan is a software engineer, YouTuber, and creator of several programming courses. Quincy talks to him about how he dropped out of college, drove from California to Florida, and hustled to get his first developer job. On top of that, you'll learn how he was able to leverage a few job offers to get a massive raise at his current company. 

Quincy Larson: https://twitter.com/ossia

Dylan's YouTube channel: https://fcc.im/2NypFgS

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Suz Hinton. She's a software engineer, security researcher, and one of the first ever people to live-stream her coding on Twitch.

We talk about:
- How Suz started her career building browser ads in Adobe Flash, working around bandwidth early 2000s limitations.
- How she moved to the US from Melbourne to work at Zappos, and then Microsoft and Stripe.
- Her love of hardware and embedded development
- How she went back to school to study infosec, and launched a second career as a security researcher
- How she nearly burned out after 20 years in tech, and what she's doing to recover.

Can you guess what song I'm playing on my bass during the intro? It's a 2015 song from an Australian musician.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

Also, I want to thank the 9,331 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during our conversation:

- Suz's article on live coding on freeCodeCamp: https://www.freecodecamp.org/news/lessons-from-my-first-year-of-live-coding-on-twitch-41a32e2f41c1/

- NoClip video game development documentaries: https://www.youtube.com/@NoclipDocs

- The Dream Machine by M. Mitchell Waldrop. Suz says it's "Dense and long, but the best narrative about how computing came to be." https://press.stripe.com/the-dream-machine

- Space Rogue: How the Hackers Known as L0pht Changed the World by Cris Thomas. "A book about the original cult of the dead cow hacking group." https://www.barnesandnoble.com/w/space-rogue-cris-thomas/1142912008

On today's episode, Quincy Larson interviews Laurence Bradford. She's the creator the LearnToCodeWith.me blog and podcast, and the Newbie Coder Warehouse Facebook group.

As a college student, Laurence was so technologically illiterate that her school made her take a remedial computer class. This made her doubt that she had a future in technology. And she ended up studying Economics instead, and moving to Asia to work in economic development.

Years later, Laurence decided to learn some basic web development skills. She found a help-wanted ad on Craigslist and landed her first gig as a freelance developer.

Since then, Laurence has worked as a developer and a product manager. She's written extensively about technology and programming in Forbes and on her blog. And she's interviewed nearly 100 developers on her LearnToCodeWith.me podcast.

Interview by Quincy Larson: https://twitter.com/ossia

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

On this episode of the freeCodeCamp.org podcast, Abbey chats with Lauren Mayers, a web developer working in Ottowa, Canada. Lauren hasn't always lived in North America, however - she's from Australia - and hasn't always been in tech.

We'll hear about how she transitioned from being a registered nurse into the world of coding, how she moved halfway around the world, why she loves the open source community, and what she's learned along the way...among many other things.

Connect with Lauren on Twitter: https://twitter.com/laurenalexm

Connect with Abbey on Twitter: https://twitter.com/abbeyrenn

Today I'm interviewing a long-time friend and role model of mine, Megan Kaczanowski. We met up in Brooklyn to talk about her journey into information security.

She studied economics at University of Michigan before working in finance in New York City. But her ambitions lead her into cyber security – first as a threat analyst at a credit rating agency, and later as a Security Architect at a bank and a startups.

Over the years, she's volunteered at charities around New York, and she's authored dozens of security tutorials as a contributor to freeCodeCamp.

We talk about her journey into tech and her advice for folks getting into security – especially women. As with every time I talk with Megan, I learned a lot. And I hope you'll a lot, too.

If you dig this podcast, be sure to leave us a review. I'm excited to read any feedback you have for me. 

And tell your friends.

Megan's many information security tutorials on freeCodeCamp: https://www.freecodecamp.org/news/author/megansdoingfine/

Follow Megan on Twitter: https://twitter.com/megansdoingfine

Read the book she mentioned about the first ever worm: https://en.wikipedia.org/wiki/The_Cuckoo%27s_Egg_(book)

Watch Mr. Robot: https://www.youtube.com/watch?v=U94litUpZuc

Today I'm talking with Sean Smith, one of freeCodeCamp's earliest graduates. Sean's also a prolific open source contributor, having helped develop freeCodeCamp's original React curriculum.

Sean grew up in Tenessee and was an avid outdoorsman and rock climber. He went to college hoping to become a doctor. He even interned at the National Institutes of Health and published in the Journal of Virology.

But one day he decided to leave the field – with no clear plans for the future – Leaving his friends and family puzzled.

For two years, Sean worked at climbing gyms across Tenessee as a route setter, climbing the walls and installing climbing holds. And one day he decided he needed to learn to code.

I caught up with Sean in downtown San Francisco, in a café that both he and I had coincidentally worked out of early in our developer careers.

I learned a lot about Sean's journey into tech that took him from working in San Francisco to Singapore to Taipei.

And spoiler alert: during the podcast we talk about Sean's job search. I'm happy to report that since I interviewed him last month, he's landed a developer job at a company focused on AI and e-commerce.

If you dig this podcast, be sure to leave us a review. I'm excited to read any feedback you have for me. And tell your friends. It really helps us inspire more people.

Sean Smith on LinkedIn: https://www.linkedin.com/in/seanmatthewsmith/

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Alison Yoon. She's a Software Engineer who started off in fashion design and taught herself to code using freeCodeCamp.

We talk about:

- What it's like to work in fashion. "You're surrounded by exhausted, unhappy people."

- How she used freeCodeCamp and the 100DaysOfCode challenge to learn to code and start her software development career

- How she learned English and how to work on engineering teams in the UK.

- How she's leading the Korean translation effort for the freeCodeCamp community, with 10,000s of people now reading Korean articles each month

Can you guess what song I'm playing on my bass during the intro? It's from a 1985 song.

Also, I want to thank the 9,779 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during our conversation:

- freeCodeCamp's Korean edition, including Quincy's "Learn to code and get a developer job" book translated into Korean: https://www.freecodecamp.org/korean/news/learn-to-code-book/

- Alison on Twitter: https://twitter.com/aliyooncreative

- Devil Wears Prada trailer: https://www.youtube.com/watch?v=6ZOZwUQKu3E

As a software engineer, it's your responsibility to write a good design doc so that your team knows how to solve the problem you're addressing. But what makes a design doc good, what should you include, and how should you write it? Angela shares all her tips so you can make your design docs as effective and helpful as possible.

Written by Angela Zhang: https://twitter.com/zhangelaz

Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn

Original article: https://fcc.im/2vAL4io

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Transcript:

As a software engineer, I spend a lot of time reading and writing design documents. After having gone through hundreds of these docs, I’ve seen first hand a strong correlation between good design docs and the ultimate success of the project.

This article is my attempt at describing what makes a design document great.

The article is split into 4 sections:

Why write a design document

What to include in a design document

How to write it

The process around it

Why write a design document?

A design doc — also known as a technical spec — is a description of how you plan to solve a problem.

There are lots of writings already on why it’s important to write a design doc before diving into coding. So all

I’ll say here is:

A design doc is the most useful tool for making sure the right work gets done.

The main goal of a design doc is to make you more effective by forcing you to think through the design and gather feedback from others. People often think the point of a design doc is to to teach others about some system or serve as documentation later on. While those can be beneficial side effects, they are not the goal in and of themselves.

As a general rule of thumb, if you are working on a project that might take 1 engineer-month or more, you should write a design doc. But don’t stop there — a lot of smaller projects could benefit from a mini design doc too.

Great! If you are still reading, you believe in the importance of design docs. However, different engineering teams, and even engineers within the same team, often write design docs very differently. So let’s talk about the content, style, and process of a good design doc.

What to include in a design doc?

A design doc describes the solution to a problem. Since the nature of each problem is different, naturally you’d want to structure your design doc differently.

To start, the following is a list of sections that you should at least consider including in your next design doc:

Title and People

The title of your design doc, the author(s) (should be the same as the list of people planning to work on this project), the reviewer(s) of the doc (we’ll talk more about that in the Process section below), and the date this document was last updated.

Overview

A high level summary that every engineer at the company should understand and use to decide if it’s useful for them to read the rest of the doc. It should be 3 paragraphs max.

Context

A description of the problem at hand, why this project is necessary, what people need to know to assess this project, and how it fits into the technical strategy, product strategy, or the team’s quarterly goals.

Goals and Non-Goals

The Goals section should:

describe the user-driven impact of your project — where your user might be another engineering team or even another technical system

specify how to measure success using metrics — bonus points if you can link to a dashboard that tracks those metrics

Non-Goals are equally important to describe which problems you won’t be fixing so everyone is on the same page.

Milestones

A list of measurable checkpoints, so your PM and your manager’s manager can skim it and know roughly when different parts of the project will be done. I encourage you to break the project down into major user-facing milestones if the project is more than 1 month long.

Use calendar dates so you take into account unrelated delays, vacations, meetings, and so on. It should look something like this:

Start Date: June 7, 2018
Milestone 1 — New system MVP running in dark-mode: June 28, 2018
Milestone 2 - Retire old system: July 4th, 2018
End Date: Add feature X, Y, Z to new system: July 14th, 2018

Add an [Update] subsection here if the ETA of some of these milestone changes, so the stakeholders can easily see the most up-to-date estimates.

Current Solution

In addition to describing the current implementation, you should also walk through a high level example flow to illustrate how users interact with this system and/or how data flow through it.

A user story is a great way to frame this. Keep in mind that your system might have different types of users with different use cases.

Proposed Solution

Some people call this the Technical Architecture section. Again, try to walk through a user story to concretize this. Feel free to include many sub-sections and diagrams.

Provide a big picture first, then fill in lots of details. Aim for a world where you can write this, then take a vacation on some deserted island, and another engineer on the team can just read it and implement the solution as you described.

Alternative Solutions

What else did you consider when coming up with the solution above? What are the pros and cons of the alternatives? Have you considered buying a 3rd-party solution — or using an open source one — that solves this problem as opposed to building your own?

Monitoring and Alerting

I like including this section, because people often treat this as an afterthought or skip it all together, and it almost always comes back to bite them later when things break and they have no idea how or why.

Cross-Team Impact

How will this increase on call and dev-ops burden?
How much money will it cost?
Does it cause any latency regression to the system?
Does it expose any security vulnerabilities?
What are some negative consequences and side effects?
How might the support team communicate this to the customers?

Discussion

Any open issues that you aren’t sure about, contentious decisions that you’d like readers to weigh in on, suggested future work, and so on.

Detailed Scoping and Timeline

This section is mostly going to be read only by the engineers working on this project, their tech leads, and their managers. Hence this section is at the end of the doc.

Essentially, this is the breakdown of how and when you plan on executing each part of the project. There’s a lot that goes into scoping accurately, so you can read this post to learn more about scoping.

I tend to also treat this section of the design doc as an ongoing project task tracker, so I update this whenever my scoping estimate changes. But that’s more of a personal preference.

How to write it

Now that we’ve talked about what goes into a good design doc, let’s talk about the style of writing. I promise this is different than your high school English class.

Write as simply as possible

Don’t try to write like the academic papers you’ve read. They are written to impress journal reviewers. Your doc is written to describe your solution and get feedback from your teammates. You can achieve clarity by using:

Simple words
Short sentences
Bulleted lists and/or numbered lists
Concrete examples, like “User Alice connects her bank account, then …”

Add lots of charts and diagrams

Charts can often be useful to compare several potential options, and diagrams are generally easier to parse than text. I’ve had good luck with Google Drawing for creating diagrams.

Pro Tip: remember to add a link to the editable version of the diagram under the screenshot, so you can easily update it later when things inevitably change.

Include numbers

The scale of the problem often determines the solution. To help reviewers get a sense of the state of the world, include real numbers like # of DB rows, # of user errors, latency — and how these scale with usage (remember your Big-O notations?).

Try to be funny

A spec is not an academic paper. Also, people like reading funny things, so this is a good way to keep the reader engaged. Don’t overdo this to the point of taking away from the core idea though.

If you, like me, have trouble being funny, Joel Spolsky (obviously known for his comedic talents…) has this tip:

One of the easiest ways to be funny is to be specific when it’s not called for [… Example:] Instead of saying “special interests,” say “left-handed avacado farmers.”

Do the Skeptic Test

Before sending your design doc to others to review, take a pass at it pretending to be the reviewer. What questions and doubts might you have about this design? Then address them preemptively.

Do the Vacation Test

If you go on a long vacation now with no internet access, can someone on your team read the doc and implement it as you intended?

The main goal of a design doc is not knowledge sharing, but this is a good way to evaluate for clarity so that others can actually give you useful feedback.

Process

Ah yes, the dreaded P-word. Design docs help you get feedback before you waste a bunch of time implementing the wrong solution or the solution to the wrong problem. There’s a lot of art to getting good feedback, but that’s for a later article. For now, let’s just talk specifically about how to write the design doc and get feedback for it.

First of all, everyone working on the project should be a part of the design process. It’s okay if the tech lead ends up driving a lot of the decisions, but everyone should be involved in the discussion and buy into the design. So the “you” throughout this article is a really plural “you” that includes all the people on the project.

Secondly, the design process doesn’t mean you staring at the whiteboard theorizing ideas. Feel free to get your hands dirty and prototype potential solutions. This is not the same as starting to write production code for the project before writing a design doc. Don’t do that. But you absolutely should feel free to write some hacky throwaway code to validate an idea. To ensure that you only write exploratory code, make it a rule that none of this prototype code gets merged to master.

After that, as you start to have some idea of how to go about your project, do the following:

Ask an experienced engineer or tech lead on your team to be your reviewer. Ideally this would be someone who’s well respected and/or familiar with the edge cases of the problem. Bribe them with boba if necessary.

Go into a conference room with a whiteboard.

Describe the problem that you are tackling to this engineer (this is a very important step, don’t skip it!).
Then explain the implementation you have in mind, and convince them this is the right thing to build.

Doing all of this before you even start writing your design doc lets you get feedback as soon as possible, before you invest more time and get attached to any specific solution. Often, even if the implementation stays the same, your reviewer is able to point out corner cases you need to cover, indicate any potential areas of confusion, and anticipate difficulties you might encounter later on.

Then, after you’ve written a rough draft of your design doc, get the same reviewer to read through it again, and rubber stamp it by adding their name as the reviewer in the Title and People section of the design doc. This creates additional incentive and accountability for the reviewer.

On that note, consider adding specialized reviewers (such as SREs and security engineers) for specific aspects of the design.

Once you and the reviewer(s) sign off, feel free to send the design doc to your team for additional feedback and knowledge sharing. I suggest time-bounding this feedback gathering process to about 1 week to avoid extended delays. Commit to addressing all questions and comments people leave within that week. Leaving comments hanging = bad karma.

Lastly, if there’s a lot of contention between you, your reviewer, and other engineers reading the doc, I strongly recommend consolidating all the points of contention in the Discussion section of your doc. Then, set up a meeting with the different parties to talk about these disagreements in person.

Whenever a discussion thread is more than 5 comments long, moving to an in-person discussion tends to be far more efficient. Keep in mind that you are still responsible for making the final call, even if everyone can’t come to a consensus.

In talking to Shrey Banga recently about this, I learned that Quip has a similar process, except in addition to having an experienced engineer or tech lead on your team as a reviewer, they also suggest having an engineer on a different team review the doc. I haven’t tried this, but I can certainly see this helping get feedback from people with different perspectives and improve the general readability of the doc.

Once you’ve done all the above, time to get going on the implementation! For extra brownie points, treat this design doc as a living document as you implement the design. Update the doc every time you learn something that leads to you making changes to the original solution or update your scoping. You’ll thank me later when you don’t have to explain things over and over again to all your stakeholders.

Finally, let’s get really meta for a second: How do we evaluate the success of a design doc?

My coworker Kent Rakip has a good answer to this: A design doc is successful if the right ROI of work is done. That means a successful design doc might actually lead to an outcome like this:

You spend 5 days writing the design doc, this forces you to think through different parts of the technical architecture

You get feedback from reviewers that X is the riskiest part of the proposed architecture
You decide to implement X first to de-risk the project

3 days later, you figure out that X is either not possible, or far more difficult than you originally intended
You decide to stop working on this project and prioritize other work instead

At the beginning of this article, we said the goal of a design doc is to make sure the right work gets done. In the example above, thanks to this design doc, instead of wasting potentially months only to abort this project later, you’ve only spent 8 days. Seems like a pretty successful outcome to me.

Eric Leung grew up in Oklahoma and learned a lot of math in high school. His friends wanted to go to medical school and he originally planned to join them. But instead he got interested in the emerging field of bioinformatics – math applied to medicine.

After 6 years in graduate school, he made the big decision to leave without completing his Ph.D. But he was able to transition into the field of data science, and he now works as a data scientist at Disney.

Eric and I met up at a public library here in Dallas, Texas to talk about his journey into data science, including his time spent learning through freeCodeCamp and ultimately contributing to our open source codebase.

We also share our love of the US public library system, where we met to record this and where Eric worked when he was younger. And we talk about the ancient board game of Go.

If you dig this podcast, you should leave us a review in whichever podcast player you're listening. It helps more people discover the show.

Download some of our previous podcasts to your phone so you'll have something to listen to the next time you're offline.

And tell your friends. Let's inspire more folks to learn to code and build careers for themsleves in tech.
 
Eric Leung's freeCodeCamp articles: https://www.freecodecamp.org/news/author/erictleung/

Eric on Twitter: https://twitter.com/erictleung

The Standup Maths Minecraft Speed Run Cheating Scandal we talk about during the show: https://www.youtube.com/watch?v=8Ko3TdPy0TU

The AlphaGo documentary about Deep Mind's efforts to conquer the ancient game of Go: https://www.youtube.com/watch?v=WXuK6gekU1Y

XKCD comic on when to automate things: https://xkcd.com/1205/

Math for Programmers book: https://www.manning.com/books/math-for-programmers

Street Fighting Math MIT course: https://ocw.mit.edu/courses/18-098-street-fighting-mathematics-january-iap-2008/

I'm Quincy Larson, teacher and founder of freeCodeCamp.org. And each week, I'm bringing you insight from developers, entrepreneurs, and ambitious people who are getting into tech.

Today I'm joined by Kylie Ying. She's a software engineer and a teacher at freeCodeCamp.

We talk about Kylie's 5 years at MIT, her time at CERN working on the Large Hadron Collider, competitive figure skating, and even poker-playing AIs.

I hope these weekly freeCodeCamp podcasts are firing you up about learning more about technology.

Tell your friends about the freeCodeCamp podcast. Let's inspire more folks to learn to code and build careers for themselves in tech.

Links to things we discuss: 

- Kylie review of her 5 years at MIT (20 minute watch): https://www.youtube.com/watch?v=EtujJjKmfN0

- Kylie's video about CERN's Large Hadron Collider (17 minute watch): https://www.youtube.com/watch?v=CmJ44z9hl8c

- Kylie's Machine Learning for Everbody course (2 hour course): https://www.freecodecamp.org/news/machine-learning-for-everybody/

- Kylie's Hot Dog or Not Dog Neural Networks course (2 hour course): https://www.freecodecamp.org/news/convolutional-neural-networks-course-for-beginners/

- Real Genius movie trailer – classic 80s movie about graduate school (2 minute watch): https://www.youtube.com/watch?v=xuv7SIVNkx8

Interview by Quincy Larson: https://twitter.com/ossia

Learn to code for free at: https://www.freecodecamp.org

Intro music by Vangough: https://fcc.im/2APOG02

Today I'm talking with programmer legend Jeff Atwood. Jeff co-founded Stack Overflow with Joel Spolsky back in 2008. And software development has never been the same.

Jeff also co-founded Discourse, a beloved forum tool used by Apple, Roblox, and of course the freeCodeCamp community. And Jeff is a prolific writer through his blog, Coding Horror.

I met up with Jeff at his home in the San Francisco Bay Area, and interviewed him in the room where he builds so many of his software projects.

We talked about software development and community building. Among other things, he shared his thoughts on Large Language Models, VR, and Self-Driving Cars.

If you dig this podcast, be sure to leave us a review. I'm excited to read any feedback you have for me.

And tell your friends. It's a huge help for us. We're still early days with The freeCodeCamp Podcast. I'm interviewing so many other inspiring developers in the coming weeks.

Jeff's Blog, Coding Horror: https://blog.codinghorror.com/

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Adrian Twarog. He's a Software Engineer who started his career by working as the office IT guy at a school and other offices for 10 years. He's since published YouTube courses that millions of people have watched.

We talk about:
- How Adrian built his development skills by volunteering to taking on web design projects at work
- How he started making design tutorials on YouTube and published 300 in a single year
- How he was early to the AI engineering craze and published GPT tutorials with millions of views
– Adrian's many freeCodeCamp courses, and his gorgeous book on design fundamentals
- Being a dev in Perth, Australia – on the other side of the Earth from Silicon Valley – yet still staying at the forefront of the state of the art

Can you guess what song I'm playing on my bass during the intro? It's from a 1995 industrial rock anthem.

Also, I want to thank the 9,771 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during our conversation:

- Adrian's popular video "Real life RPG to track your life": https://www.youtube.com/watch?v=GMn9sxCWN0M

- Adrian's UX course on freeCodeCamp: https://www.freecodecamp.org/news/ui-ux-design-tutorial-from-zero-to-hero-with-wireframe-prototype-figma/

- Merge, Adrian's Discord community for devs: https://www.mergewebdev.com/

- Adrian's design book, Enhance UI: https://enhanceui.com/

In this special crossover episode, we celebrate 10 years of The Changelog. It's the home of the biggest podcast focused on open source, and a favorite of freeCodeCamp founder Quincy Larson.

This 4-hour episode is actually 2 interviews:

1. For the first 2.5 hours, Quincy interviews Changelog co-hosts Adam Stacoviak and Jerod Santo about how they got into software development and podcasting, and the history of their legendary podcast.

2. Then we end with Adam and Jerod turning the tables and interviewing Quincy about the past and future of freeCodeCamp.org.

If you haven't heard of The Changelog before, it is website that hosts a podcast about open source software. Each week they interview new developers from around the software galaxy and explore what makes those projects tick.

Adam Stacoviak founded The Changelog exactly 10 years ago. And Jerod Santo joined as co-host 7 years ago. Together - across 370 episodes - they've interviewed everyone from programmer legends, to the maintainers of open source projects you may have never even heard of.

Quincy has listened to hundreds of The Changelog episodes over the years, and credits The Changelog with giving him such a broad view of open source, and the philosophies of the developers who started these projects.

These interviews were conducted in-person in Adam's Houston-based studio.

If you haven't yet, you should subscribe to The Changelog podcast. They have a variety of shows. We recommend starting with their Master Feed, which lets you explore all of their shows: https://changelog.com/master

And check out the special website they built to celebrate their 10 year anniversary: changelog.com/ten

Follow Adam on Twitter: https://twitter.com/adamstac
Follow Jerod on Twitter: https://twitter.com/jerodsanto
And Quincy is: https://twitter.com/ossia

On this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Angie Jones. She's a developer and holder of 27 software patents. She's worked at companies like IBM and Twitter, doing both test engineering and developer advocacy.

We talk about:

- How a bad performance review from her boss early in her career taught her to be less timid and more vocal about her ideas.

- How she invented lots of software testing processes and holds 27 software patents.

- Her work at IBM, Twitter, and other big tech companies.

- How feature development and test development are completely different disciplines, which each require dedicated practice and their own mindsets

- Her interest in the game Second Life and the possibility of virtual worlds

- How she uses AI for debugging and test engineering

Can you guess what song I'm playing on my bass during the intro? It's a 1992 Acid Jazz song.

Also, I want to thank the 9,779 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during our conversation:

- Test Automation University learning paths: https://testautomationu.applitools.com/learningpaths.html

- Angie on Twitter: https://twitter.com/techgirl1908