In this week's episode of the podcast, freeCodeCamp founder Quincy Larson interviews Robby Russell. Robby created the open-source project Oh My ZSH.  Oh My Zsh is a framework for managing your Zsh configuration for your command line terminal. It's been extremely popular among developers for more than a decade. Robby is also the CEO of Planet Argon, a developer consultancy he created two decades ago. He's done work for Nike and lots of other companies. 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 Sandy Mets 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

Beau Carnes has run the freeCodeCamp community YouTube channel for the past 5 years, taking it from 75,000 subscribers all the way up to 9 million. Beau started out working as a Special Education teacher at a Michigan high school. He taught himself how to code before working as a software engineer. He has since taught dozens of programming tutorials and helped curate more than 1,000 courses for the freeCodeCamp community YouTube channel. During our conversation, Beau shares the challenges he faced during his career transition as a father of 3 kids. He talks about how he finished a second degree in software development in just 6 months. And he even talks about his love of stilt-walking. For the first time ever, I've published this interview as a YouTube video podcast as well:  https://www.youtube.com/watch?v=DNPF0oPcMDs 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. 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/

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

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

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

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. 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. 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  

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 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/  

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

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    

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/  

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/  

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/    

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/

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/  

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/ 

#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  

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/

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/

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

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

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 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

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

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

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

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. Jessica grew up around computers, and her mother was a software engineer. But she didn't take a serious interest in coding until a bit later in life. After studying photography in college, she held a series of odd jobs before taking a contract data entry position. That data entry job happened to be at a small web dev shop, and while she was there she learned the basics of the trade. Once she'd honed her beginner's skills for a couple years, she got her first proper job as a web developer working for a small ad agency. She jumped in the deep end, learned a ton of new skills on the job (most of which she taught herself and figured out by googling and asking questions on Stack Overflow), and gradually got over her intense feelings of imposter syndrome. “When you’re going up against these people who have degrees in computer science and engineering, it really creates strong imposter syndrome. And unfortunately I think the only real cure for imposter syndrome is simply time. Just learn one new thing every day and in time you’ll keep progressing in your skills. Just try to make incremental changes and improvements.” Jessica realizes that part of her difficulties in learning how to code came from the fact that there weren't as many resources out there online when she was learning. The bootcamp explosion hadn't happened yet, freeCodeCamp didn't exist, and it was a lot harder to figure things out. But she pushed through. And she gained some important perspective on learning to code - which, she admits, is really, really hard. But after sticking with it for a while, she learned something important: “Over time, I learned that if I just spent time googling, asking people, finding and reading documentation, I knew I’d be able to figure out pretty much anything. So that realization that I could teach myself was a big confidence boost.” After about four years with the ad agency, she moved across the country and started working remotely. Which led her to realize she wanted to be her own boss. She also started her educational website and blog, Coder Coder, around that time. “I felt really passionate about coding – I really love web development. And I think seeing how many other people were struggling learning – I was part of these groups for newbie coders and I saw all these questions I had when I was learning to code. So it stemmed from my desire to help beginners and add my own voice and style to the other resources out there.” To give herself more time to work on the site and her side projects, she decided to strike out on her own and get into freelancing. Now, Jessica writes articles for her blog and other sites (including Developer News), posts tutorials and info on Instagram and Twitter, and has lately started live streaming on YouTube. She focuses on CSS, responsive web design, and other web dev topics. One of her goals for the coming year is to grow the YouTube channel and work on creating super high quality videos with her video editor/animator husband. And she's working on another huge project: a course on responsive web design for beginners. She has all sorts of fun ideas about how to make it engaging, so be on the lookout. In this episode, Jessica discusses so many valuable skills developers should have, like how to teach yourself to code how to beat imposter syndrome how to be your own mentor how to work with clients as a freelancer how to get the most out of online tutorials and how to tackle the job hunt among many other beginner-friendly topics. Regarding the job hunt, and building your portfolio, Jessica offered this perspective: “First of all, focus on learning the basic skills. Then once you have the skills to create portfolio projects, that’s a huge thing that can help you even if you don’t have actual clients. You don’t have to have an actual working website - but you need to be able to demonstrate to a potential employer what your skills are. Because if they can’t see what skills you have, why would they hire you?” And she's all about encouraging new developers to keep going and not give up. She knows how hard it is to learn to code - again, it's really hard - and she offered a treasure trove of helpful advice (like setting sustainable pace for your learning, having realistic expectations of yourself, and finding an online community). You can find Jessica on Twitter here: https://twitter.com/thecodercoder Check out her website here:https://coder-coder.com/  

On today's episode of the podcast, Abbey chats with software engineer Jackson Bates who lives and works in Melbourne, Australia. Jackson used to be a high school English teacher, but gradually taught himself to code and landed a pretty sweet gig as a React dev, partly by chance. Today he works part time as a developer, part time as a stay at home dad, and volunteers his time with various open source projects. Finding his way into tech Jackson grew up in England, and studied English in school. Although going into education seemed a logical choice, he dabbled in other fields - like working at a prison cafeteria - for a while before landing a teaching job. That first job had some unpleasant aspects, and he began to doubt if teaching was for him. After moving to Australia to be with his wife, he started dabbling in basic HTML and CSS. Even though he continued teaching high school English, Jackson couldn't tear himself away from coding completely. We’ve all got computers, but being able to write code and make your computer do something – once you learn to do that it becomes quite an addictive thing. I just loved the problem solving aspect and how creative you could be. Learning to code After about six years of teaching without all the proper Australian certifications, he decided to go back to school and get his masters. He budgeted a bit too much time for his studies, however, and ended up with six months before he was scheduled to go back to work. So he dove back into learning more about coding. And those teaching skills? They came in quite handy when he was teaching himself to code. As a teacher, you kind of understand what it really takes to learn something. When you’ve helped 11-18 year olds overcome really frustrating experiences in their own learning, you learn to give yourself a break when you hit roadblocks. You learn to put in the work that’s necessary, but you get a more realistic expectation of the timeframes involved to learn something. And he was hooked. He got through one more year of teaching before deciding to try to get a job as a software engineer. Getting that first tech job But the job hunt sucked. While this was no surprise, it was particularly demoralizing when he was rejected for the most basic role for which he felt quite overqualified. I always had it in the back of my mind that I was never really ready enough – and I know everyone always says oh I’ll just finish this certification and brush up my CV and do this course…we always give ourselves a million reasons not to do it, and really those reasons will always be there. At that point, a friend encouraged him to try out a new meetup group, just for the heck of it. So he went. And ended up meeting his future boss. You might get knocked back from things you’re overqualified for – but it only takes the right person to see you and decide you’d be a good fit for their team, and then all the rejections don’t matter anymore. You just have to keep putting yourself out there. A tentative follow-up email, a quick round of interviews, and an onsite later, he had the job. It was an excellent cultural fit, and he's never looked back. He gets to work on fun internal projects, support the data scientists on his team, and pick up new skills constantly. And he's even developed a refreshing perspective on debugging and facing challenges in his code: I really like working with broken code. Because you know staring down a bug until you’ve fixed it really gives you a better understanding of the whole thing that you’re trying to do. Even though it’s a bit slow, it helps it sink in a bit more. Now, 14 months later, he's learned a lot about different tech, Machine Learning, how to learn new skills, and what it takes to switch careers. It really is a long game that you’re playing. It’s easy to be discouraged, but people have made the change you’re trying to make. It feels impossible but people do actually do it. In this episode, Jackson offers valuable advice about job hunting, finding your learning style, dealing with imposter syndrome, and how to take chances - among many other things. Find Jackson on Twitter: https://twitter.com/jacksonbates

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

In this week's episode of the freeCodeCamp podcast, Quincy Larson interviews Ruben Harris, who runs Career Karma, a social network for people interested in attending coding bootcamp. He also hosts the Breaking into Startups Podcast. Ruben just finished Y Combinator, a startup accelerator, where he and his team raised their first round of venture capital funding. Ruben grew up in Atlanta and worked in finance. He met his future co-founders - Ukrainian-born brothers Artur and Timur Meyster - years ago. The three of them agreed to spread out, get jobs in different industries, then later regroup to build a startup together. Ruben shares his insights on coding bootcamps. He also shares what he learned going through Y Combinator. And he talks about his close bond with his co-founders. Follow Ruben on Twitter: https://twitter.com/rubenharris Follow Quincy on Twitter: https://twitter.com/ossia Subscribe to the Breaking Into Startups podcast: https://breakingintostartups.com/ Ruben interviews Quincy way back in 2017 (50 minute listen): https://breakingintostartups.com/quincy-free-code-camp/ Ruben interviews Gary V (an episode he mentions during this interview): https://breakingintostartups.com/76-gary-vaynerchuk-ceo-vaynermedia/

On this week's episode of the freeCodeCamp podcast, Abbey interviews senior software engineer and prolific content creator Ohans Emmanuel. They discuss how he got into tech, how he ended up in Berlin, what goes into writing a book, and how he stays focused through it all. When Ohans was young, he learned a very important lesson from his parents: you must take responsibility for yourself and your actions. He was lucky enough to grow up with a computer in the house, and gradually learned computer basics. In school, he studied engineering, but didn't learn much programming. So he had to teach himself. And it was hard. He lacked a community, had to struggle through things on his own, and felt like it was much harder than it needed to be. "I don't understand what it was - I was a smart student, but when I started to teach myself to learn how to code, that was the most difficult thing I had to teach myself to do. I was really on my own, I didn't join any groups. It was really just me trying to figure out the road map for myself. And that was really difficult." But having a supportive mentor helped. And eventually he started freelancing and teaching young adults how to code. He also began to fall in love with design and writing. As his passion for design grew, he began to appreciate its usefulness as well: "There is something about a front-end engineer who understands design. You see things differently. You can have meaningful conversations with the designers, and you have different opinions. You're not just building stuff - you understand how it affects the users." As Ohans learned more skills and came across more and more tough topics, he decided to research and then write about them. Again and again. He has written a number of free, full-length books about React, Redux, CSS, and many other topics. And his approach to the process is unsurprisingly organized and measured. "The first step is deciding what to write about. So I find a subject that is challenging or that I think maybe the community hasn't really explored. Or if I think that a lot of beginners are finding this subject difficult, it just makes me want to write about it more." "I'm really passionate about teaching things in plain, simple language. So you take a difficult subject and you break it down. It's so much fun. And when you do this over and over, it helps a lot of people. And it puts smiles on my face." Now isn't that enthusiasm contagious? In addition to writing books and articles and helping kids learn to code, Ohans has a full-time software engineering job in Berlin. Deciding to make the move away from friends and family wasn't easy, but with their support he went for it. During the interview process, he learned a lot about job interviews in general and what it took to go through them successfully. He believes being good at your job as an engineer and being good at interviews are two very different things. Despite this, Ohans believes that anyone can conquer the interview process. And his go-to advice? "Just smile. It keeps you calm and makes the interviewer calm as well. They want to give you time and let you think. You're smart, you can do it - you just have to stay calm and figure it out." Part of Ohans' success is derived from his commitment to deep work and deep focus. He firmly believes that anyone can learn anything if they put their mind to it and have a plan. "I believe that the act of focus itself is a skill - just as much as you can learn to play the piano, you can learn to focus as well. And I think people really need to take their attention as seriously as possible. If you covet your attention, and take it like it's important, I think you'll be careful how you spend your time." In this interview, we discuss how he overcame the obstacles he faced when learning to code alone, how he got a job in another country, how he creates so much valuable, free content, and how he advises new developers to approach interviews, mentors, and many other tough subjects. "If you try something for a day and it doesn't work, go on and try it for a week. If it still doesn't work, try for two weeks. If it still doesn't work, re-evaluate what you're doing. If you still think you're heading in the right direction, try for another month. Or two months. And if you're still sure you're going in the right direction, don't give up - you're gonna get it.

On this week's episode of the freeCodeCamp podcast, Abbey chats with UX designer and musician Andi Galpern about how she creates engaging and unique experiences in the tech world. Andi shares stories about past jobs, how she started her company, her favorite moments from events she's produced, and how to break into the design market. Andi grew up in Florida and was first and foremost a musician at heart. Once she decided that she needed a plan other than becoming a rockstar, she picked up and moved across country to the Bay Area. After attending various tech events and taking photos, she started making connections and growing a network. In between regular jobs, she was trying to learn more about design - but couldn't find any meetups or events that fit the bill. So she started creating her own. And they were successful. After a while, she founded her company, Cascade SF, with the goal of helping other designers, product managers, and engineers learn more, meet other people in the community, and help each other out. As her strategy and process changed, so did her events. "I used to only get big name speakers. But now that I'm in control of the content, I help designers, product managers, and people in tech tell their stories. I help them design a program so they can share their knowledge and we can create more people like them. So it's more about creating new leaders, and creating content the industry needs." Andi kept learning more and more about different facets of design, and she shared many insights she gained along the way. "The product design process is holistic and a lot like life. We don't have to have all the answers, we just have to be willing to watch people try things out and grow and learn. There are no mistakes, there are only hypotheses and data and making decisions." Once her events grew large enough, and she started holding after work conferences, she realized the importance of a new skill: asking for what she wanted. "Asking for what you need or want can be really scary. But sometimes you're pleasantly surprised - you get a response back. You never really know unless you ask. But organizing a successful event requires much more than that. For Andi, it's all about the quality of the content. She does her research, figures out what people want, and then puts it all together. "Great design is about content first, so it's about comprehension. Make sure the purpose of the event is clear. You can continue to keep tweaking your design until everyone gets it immediately. You just have to distill it down into your one core message." "A big part of UX design is just making things simpler and more usable so people can enjoy their lives more." Now, hundreds of events and conferences later, she's running Cascade, working as a content strategist for growth at Adobe, volunteering with various organizations, dabbling back in photography and music, and dreaming of expanding her brand to different cities. In this episode, Andi shares advice on how to put on a successful tech event, how to survive the job interview process, and how to learn all sorts of design skills. We discuss challenges she's faced, solutions she's created, and why she loves pinball so much, among many other things. Find Andi on Twitter here: https://twitter.com/andigalpern Find Abbey on Twitter here: https://twitter.com/abbeyrenn

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

This week, I got to chat with Briana Swift, who used to teach music to elementary school children. She loved teaching and loved her job, but realized it wasn't what she wanted to do for the rest of her life. So she started looking around for what might be the next steps, and started learning about the world of tech. After going to a number of meetups and looking around online for various free resources, she stumbled upon freeCodeCamp. Over the course of a couple years, she got her full-stack certification while sharing videos of herself learning various concepts. When she started looking for a job, she experienced what so many new developers experience: rejection and frustration. She had to adapt, learn how to learn, and keep trying. But one day, after attending a random meetup, someone drew her attention to a role at GitHub that seemed tailor-made for her skill set. Doubting that she'd get through the interview process, she applied anyway - and got the job. She identifies a few of the skills that helped her get the job: "On the one hand, it was the actual skills I learned [before working at GitHub]. But on the other hand it was the mindset. Because even if I'd learned everything perfectly 2-3 years ago, it was such a different ecosystem out there now. Knowing how to search the documentation or find the answer or Google to get what you need - I don't think that will ever go out of style." Three and a half years later, she's worked her way up through a couple different roles at GitHub and couldn't be happier with her job. She's learned how work with a diverse and passionate team, she's learned how to stand up for herself, and she's come to appreciate how much soft skills matter. "Anything that's a technical thing can be learned. But working with a bunch of really smart, passionate people can be challenging because they're so passionate. And I think navigating that and trying to meet people where they are while still getting the best work done that I can is something I'll be working on for the rest of my life." One thing she emphasizes again and again throughout our chat was not being afraid to ask questions and have confidence in yourself: "Ask questions even if you think it's gonna make you look dumb. Sometimes no one else is asking because they want to look smart. But on the other hand, trust yourself - don't let anyone convince you that you don't know something if you've done your research. You can be the person who asks dumb questions and the person who's an expert on something at the same time." In this episode, we discuss how she transitioned into tech, how she learned all the skills she needed to work at GitHub - and how she continues to learn, what she does to support diversity in her tech community, and how she stays fueled up and motivated day to day. She's gained a lot of insight on creativity, and shared her perspective on staying creative: "Creativity is like a body of water. And if you let yourself become like a pond, where nothing's coming in, then nothing's gonna go out. If you want something to go out, you have to have new experiences, new things going in." Briana also offers advice on learning to code, asking questions, achieving balance in your life, and being a good team member, among many other things. Find Briana on Twitter here: https://twitter.com/brianamarie132 Find Abbey on Twitter here: http://twitter.com/abbeyrenn

In this week's episode of the freeCodeCamp podcast, Abbey chats with software developer and freelancer Kyle Prinsloo who lives and works in South Africa. Kyle knew from a young age that he wanted to pursue a career in business. He launched websites with his brother, worked various jobs, and eventually gained experience in marketing and tech. Although he had a job he enjoyed working for people he respected, he wanted more from his work and life. He wanted to marry his now wife, and he wanted to be his own boss. So he started doing some freelancing work on the side. Little by little, as he built relationships with clients and gained more experience, his portfolio grew and he started making more from his side business than from his regular job. So he decided to make a change. In this podcast, you'll learn how he launched his business and educational website, how he prices his services, and how he advises others to become successful freelancers as well. Kyle offers actionable tips on gaining experience, shares anecdotes from his own journey, and discusses how he balances his many responsibilities. You can connect with Kyle on Instagram. Check out his website here.

In this week's episode of the freeCodeCamp podcast, Abbey chats with software developer and army veteran Jami Gibbs about her journey into tech. Jami was born and raised in the Chicago area, and her first encounter with programming was in high school. While majoring in English in college, she joined the National Guard and did several tours overseas. During her time in the army, she came back to the world of tech and started learning more about coding. After leaving the military and finishing her English degree, she realized she wanted to switch careers and commit to becoming a software developer. She taught herself most of what she knows, supplemented it with a boot camp, and got her first job working on WordPress themes. Through building a number of side projects, enhancing her skills, and working her way up to other tech jobs, Jami reached her current position as a software engineer in Chicago. When she's not spending all her free time coding, she runs races, enjoys the Chicago craft beer scene, and roots for the Chicago Bears. In this episode, Jami discusses the hiring process, what it was like getting a tech job in her 30s, how her time in the army helped during the job hunt, and more. Find Jami on Twitter here: https://twitter.com/JamiGibbs Find Abbey on Twitter here: https://twitter.com/abbeyrenn  

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

On this week's episode of the freeCodeCamp podcast, Abbey chats with developer and wearer of many hats Princiya about how she changed careers, moved to Berlin, and worked her way up to a lead role. Princiya grew up in India and studied computer science in school - like many of her family members and friends. She even taught some computer science and web development classes at the university level, but missed coding. So she decided to get back into it. After working at a startup and starting to speak at conferences, Princiya took a trip to Berlin that changed her life. The community was welcoming, she made some great connections, and ended up applying to and getting a job there soon after. Princiya now works at a startup in Berlin where she's also in charge of the recruitment process. She's a maintainer at Firefox Dev Tools, a Mozilla Tech Speaker, and an active and enthusiastic mentor. She attends many local meetups in her community and strongly believes in giving back to the groups that helped her get her start in her new city. In this episode, Princiya shares how she worked her way up to a lead role, why she believes the hiring process needs to change - and how she wants to change it - and how she's building healthy and productive relationships within her team and organization. She also discusses why she loves being a mentor, how communities can help young developers, and why she believes in the therapeutic power of doing the dishes - among many other things. When she's not helping her team work better together or working on her latest conference talk, she loves to cook and explore Berlin's food scene.     Connect with Princiya on Twitter here: https://twitter.com/princi_ya  

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. Joe had his life planned out: he'd get a PhD in linguistics, get a teaching job, and be part of the academic world. But as he worked his way through his Masters degree, he began to realize that the academic lifestyle didn't suit him as well as he'd thought. So he took a big chance, and left his program. Once Joe started learning to code, he also started creating opportunities for himself. He got his first dev job, started creating content, and got more involved in his local tech community. Today, he co-runs a GraphQL meetup, creates courses for Egghead.io, writes articles and makes videos, and speaks at events and conferences regularly. And in this episode, Joe shares with us exactly how he accomplished all these things not long after typing his first lines of code. When he's not coding - which isn't very often - you'll find him reading, meditating, getting some exercise, or hanging out with his wife and friends. You can find Joe on Twitter here: https://twitter.com/jsjoeio You can find Abbey on Twitter here: https://twitter.com/abbeyrenn  

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/

In this week's episode of the freeCodeCamp podcast, Abbey chats with Greek developer and designer Eleftheria Batsou about her passion for creating content and how she balances work, school, travel, and personal time. Eleftheria moved around a lot when she was young, but settled in Thessaloniki in northern Greece as a teenager. When she had to decide which track to take in school, she picked technology, science, and math. It turned out to be a good decision! After bouncing around a bit and completing some internships, Eleftheria found a place that suited her. She learned to code by supplementing her education with free online resources (like freeCodeCamp!), leveled up her skills by completing numerous challenges like #100DaysofCode, and realized she had a passion for design as well as front-end development. Today, she works as a developer, she's getting her Master's degree in design, she attends numerous conferences throughout Europe - and speaks at many of them - and she has a growing YouTube channel. She also has a blog where she shares all kinds of tips, tutorials, and bits of knowledge for beginning developers. When she's not busy juggling her many tasks, she likes to workout to clear her head and hang out with her friends.   Find Eleftheria on Twitter: https://twitter.com/BatsouElef Visit her website here: eleftheriabatsou.com

On this week's episode of the freeCodeCamp podcast, Abbey chats with self-taught developer Rick West who lives and works in the UK. Rick shares how he went from owning his own successful HVAC business to stumbling upon coding and slowly falling in love with tech. Even though Rick's plumbing business was booming, he told himself that, by the time he was 30, he wanted to start another career. And he ended up doing just that. After meeting a couple developers through various contracts, he became fascinated with coding. When he had a break between jobs, he started teaching himself the basics. Not long thereafter, Rick emailed some tech companies and found one that would take a chance on a very junior, very inexperienced developer - and the rest is history. He has just started a new job - as well as a Software Engineering degree - and he's a self-professed constant learner. When he's not studying or coding, Rick enjoys hanging out with his family and leading a relatively quiet life. In this episode, you'll hear all about how Rick made the big career transition and why. We discuss how his life is different now, what it's like to be enrolled in a degree program while working full time, and how he prioritizes his time - among many other things. Find Rick on Twitter here: https://twitter.com/rick_west8  

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. Growing up, Madison's parents encouraged her to follow her curiosity - she once spent months learning everything she could about dinosaurs. She was 10. Once she decided to learn to code, this self-directed learning greatly came to her aid. After leaving college before getting her degree, Madison was inspired to get into the world of tech. Her sister was a developer in San Francisco, and Madison thought - if she can do it, why can't I? While she struggled to get into coding at first, she tried and tried again, and she was soon hooked. Madison taught herself to code with free online resources and decided that she wanted to give something back to the community. She created her own free coding course, she mentors a number of junior developers, and she regularly sends out tips and resources. When Madison's not learning more about the backend or working on projects for Mediavine, she loves meeting with other devs in her local community and spending time with her family. In this episode, you'll hear some great advice about how to figure out your learning style and teach yourself to code, what books to read, how to use imposter syndrome and failure to your advantage, and how to create opportunities for yourself - among many other things. Find Madison on Twitter: https://twitter.com/Madisonkanna Visit Madison's website and get her free course: https://www.madisonkanna.com/ Check out Madison's review of Clive Thompson's book Coders: https://www.madisonkanna.com/book-notes-coders  

In this week's episode, Abbey chats with artist and game dev Angela He who's a college student at Stanford University. Angela creates beautiful digital art and develops games that speak to emotional issues - and she's almost completely self-taught. Angela grew up in a wealthy suburb of Washington, D.C., and started studying art at the tender age of 3 (after her parents found her drawing on the walls of their home). From there, she has worked with and learned about all different kinds of art, and has taught herself much of what she knows. As she grew older, she got into game development and started figuring out what sort of games - and art - her peers and the general public might like. When she came to Stanford to start university, she continued to explore new tech and expand her skills. Now, Angela is launching a clothing and accessories line inspired by her art while going to school and landing internships at companies like Microsoft and Niantic. She loves exploring the Bay Area with her friends, enjoys shopping for house plants, and eventually wants to write an anime, among many other things. You can find Angela on twitter here: https://twitter.com/zephybite You can check out her website here.

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

Saron on Twitter: https://twitter.com/saronyitbarek Quincy on Twitter: https://twitter.com/ossia Get tickets to Codeland in NYC on July 22, 2019: http://codelandconf.com Quincy's review of his Codeland experience: https://medium.freecodecamp.org/5f01cadf0a42 In this week's podcast, Quincy interviews Saron about her childhood, and her winding path into tech as an adult. Saron moved from Ethiopia to the US as a child. Her parents had high standards for her academics, and they would even make up extra homework for her each night. After studying liberal arts, Saron worked in science journalism. Eventually she decided to learn to code. After some self-study, she attended a coding bootcamp. From there, she got her start as a developer at ThoughtBot, and then worked at Microsoft. Saron founded CodeNewbie in 2014 and started hosting Twitter chats for people who were interested in learning to code. Then she launched the CodeNewbie podcast, which now has more than 200 interviews with developers around the world. Even though Saron is extremely productive, this productivity doesn't come easy. She talks about was recently diagnosed with Bipolar Disorder and General Anxiety Disorder, and she has adapted to her situation by being extremely methodical about how she invests her time and energy. Enjoy the interview, and be sure to subscribe to both the CodeNewbie podcast and the freeCodeCamp podcast for new interviews each week.

In this episode of the freeCodeCamp podcast, Abbey chats with freelance Ruby on Rails developer Colleen Shnettler about how she switched from electrical engineering to development, how she founded her business, and how she makes time for kids and family - among many other things. Colleen studied electrical engineering at Purdue and then went to work for Motorola in Chicago - a job she loved. After getting married and moving to Virginia to be with her husband, she worked one of the only tech jobs available in her area: defense contracting for the military. But she wanted to be her own boss, and so she decided to learn how to code. After falling in love with Ruby on Rails and working on a few projects, she founded her own company, Bitmapped Designs. She now works from home designing and consulting on web apps for a wide range of clients. When she's not working, Colleen spends time with her children and husband, attends Ruby on Rails meetups, travels, and contributes to the open source community. She dreams of helping other developers, especially military spouses and moms, find ways to work and make money that are inspiring and challenging. Find Colleen on Twitter here: https://twitter.com/leenyburger Find Abbey on Twitter here: https://twitter.com/abbeyrenn  

In this episode, Beau chats with Jesse Weigel, who live streams on the freeCodeCamp.org YouTube channel and is a Senior Software Engineer at DICK'S Sporting Goods. He talks about his career path, live streaming, getting a developer job, speaking at conferences, React Native, dealing with mental health issues, and more.    Jesse's career has benefited a lot by live streaming. He talks about the benefits and offers suggestions for other people who want to get started with it.   Jesse currently builds progressive web apps with React and GraphQL. He talks about why more people should be using React Native for their projects. He also talks about getting the confidence to speak at conferences and offers some tips that helped him deal with mental health issues.   Links to topics Jesse discussed: Direct Neural Interface & DARPA: https://youtu.be/nvUHDK59Igw Brain Scan Clinic: https://www.amenclinics.com/   Find Jesse on Twitter: https://twitter.com/JesseRWeigel   Also consider following Jesse's wife, Bekah, on Twitter: https://twitter.com/BekahHW   Find Beau on Twitter: https://twitter.com/CarnesBeau  

In this episode, Abbey chats with Kate Illsley, a tech recruiter and budding developer in Melbourne, Australia. Kate talks about how learning to code helps her be better at her job, and they also discuss Kate's journey into tech, how she got so involved in volunteering for various organizations in Melbourne, and what she loves about working with young women just starting out. Kate's path from university to her current job was fairly straightforward, but once she discovered coding, she realized there was so much more she could be doing to help job seekers find their perfect fit. She started volunteering with Startup Weekend in Melbourne, helped found Grad Girl, and got involved with VicITC for Women. Through her work with these non-profits, she discovered a passion for helping young people, especially young women, find careers in STEAM. Kate attends and speaks at a variety of events, and loves discussing how to do well in interviews, how to get into tech, and how women can nurture their love of coding. When she's not running around the city and organizing events, she makes sure to spend plenty of time in her veggie patch with her rescue dog, Cookie, getting some quality time away from her computer. Find Kate on Twitter: https://twitter.com/kate_illsley Find Abbey on Twitter: https://twitter.com/abbeyrenn  

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.

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  

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

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  

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 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...

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  

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/  

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. For podcast listeners, Zubin has a special promotion. The first 20 people to buy the course on Udemy before the end of March can get it for free using the Promo Code: FCC_FREE_PROMO   Course link: https://www.udemy.com/how-not-to-quit-coding/   If you're not among the first 20, the next 50 can get it before April 30 at the discounted rate of US$10, using the Promo Code: FCC_PROMO_50   If you're a later listener, get in touch at the webform on https://matchfitmastery.weebly.com, and mention FCC in the message to get a discount code.

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

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/ Learn to code for free at: https://www.freecodecamp.org 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 Sacha Greif on Twitter: https://twitter.com/SachaGreif   Sacha's personal website with links to many of his projects: http://sachagreif.com/   Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02

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 Lyle Troxell on Twitter: https://twitter.com/lyle   Lyle's 18-year running tech podcast: https://geekspeak.org   The "Wat?" talk Lyle mentions: https://www.destroyallsoftware.com/talks/wat   Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02

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 Ali Spittel on Twitter: https://twitter.com/aspittel   Zen of Programming website: https://zen-of-programming.com/ Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02

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 Laurence Bradford on Twitter: https://twitter.com/learncodewithme   LearnToCodeWith.me Website: https://learntocodewith.me Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02

On today's episode, Quincy Larson interviews Alexander Kallaway, the creator of the #100DaysOfCode challenge.   In addition to talking about the 100DaysOfCode challenge itself - a challenge which, at this point, thousands of people have taken - Alex and I also talk about how he and his wife moved from Russia to Canada to advance their careers, and how he used freeCodeCamp to gain the skills he needed to get his first developer job.   Alex is an incredibly motivated person, and in this interview we'll delve into how he keeps himself so fired-up day after day. Interview by Quincy Larson: https://twitter.com/ossia Alexander Kallaway on Twitter: https://twitter.com/ka11away   100DaysOfCode Website: https://www.100daysofcode.com/ Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02

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 Description:   On today's episode of the freeCodeCamp podcast, Quincy Larson interviews Dylan Israel.   Dylan is a software engineer, a YouTuber, and the creator of several programming courses. We talk about how he dropped out of college, drove from California to Florida, and hustled to get his first developer job.    We also talk about how important his YouTube channel has been in helping him land job offers. And Dylan shares some details of his latest job search, which resulted in 4 job offers.   Dylan was ultimately able to use those job offers a bargaining chip so he could get a massive raise at his current company without having to change jobs.

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.

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.

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.

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.

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.

Have you ever had to deal with legacy code - code that someone else wrote a long time ago? Are you temped to just rip everything apart and rewrite it? Bill explains why this is a bad idea and how to approach - and respect - legacy code instead. Written by Bill Sourour: https://twitter.com/billsourour Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2KJahRe Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: At some point in your developer career, your boss will hand you a piece of legacy code — code that someone else wrote a long time ago. Your boss will tell you to learn this legacy code, fix it, and add new features to it. I’ve been in this situation many times over the last two decades. I can help. How to understand legacy code If you’re lucky, you’ll have documentation, or at least in-line comments. Maybe one or two of the original authors will still even be around to help. But most of the time, you will not be so lucky. Let’s talk about what you’re going to do in those unlucky cases. First, you need to be humble. Respect the code, and the developers who wrote it. It’s easy to look at work that came before you and decide it’s no good and that you can do better. This is the wrong attitude. It will lead you down a very dangerous path. If you go down this dangerous path, you’ll start making changes before properly understanding the impact of those changes. You’ll “fix” things that aren’t broken, because they are written in a style that you don’t like, or are based on an older way of doing things. Ultimately, you’ll waste an incredible amount of time with this attitude. So stop. Take a step back and realize that everything in that codebase was done a certain way for a reason. Until you know the code forward and backward, you have to assume that there were good reasons for it to be written the way it is, and that you just haven’t figured them out yet. This is a much more productive attitude, and it will save you from breaking everything, then just wanting to jump out of a window when you can’t put it back together quickly enough. Don’t Humpty Dumpty your codebase. The best way that I’ve found to learn a codebase is to start at the user interface level, then work my way back into the code. Pick a single user flow, like logging in, placing an order, writing a review, or whatever is relevant to your particular application. Go through the flow as an end user. Then look at the code, starting with the user interface code — it should be the easiest to recognize — and follow each step on back, all the way to the database. As you go along, draw a sequence diagram to help illustrate what is happening. If you’re not sure what a sequence diagram is, or how to draw one, check out this free tutorial. If you don’t have a good tool for drawing UML, here’s a free one. Once you’ve completed your first sequence diagram, using a local copy of the codebase that you can easily restore, start to make subtle changes to some of the components you’ve encountered. See if you can predict the effects of your changes on the application. This is a good way to test your understanding. Keep repeating this process, adding to your diagrams until you have a complete picture of the entire application (or at least all the parts you are responsible for). For bonus points, make sure you share your notes and diagrams. Put them in a highly visible place where the next developer who comes along can easily discover them. Don’t worry about making them perfect, or even pretty. Just do what you can. Every little bit helps. Overall, the most important thing is to be patient, and avoid beating yourself up. Code is a complex thing. Understanding legacy code takes time. Stay calm. How to fix legacy code The biggest challenge you’ll face when fixing legacy code is deciding how far to go with your fix. I strongly advise you to make the minimum viable change first. This means you should make the least disruptive change that completely fixes the problem before attempting to clean and refactor any code. This gives you an escape hatch. Worse case scenario, if you get pulled away to address some other priority — or if you’re on a tight deadline — at least you’ll have pulled together some working code that you can fall back on. Once you’ve gotten your code working, if you still have time left, you can start making small, incremental improvements. Martin Fowler has put together a catalog of refactorings which will give you a good idea of the types of changes you can make to incrementally improve a codebase. Check it out here. The idea is to always leave the code in better shape than it was when you found it. Sometimes, you’ll encounter a bug that is actually the result of a structural defect. These bugs can’t be fixed by a simple change to some conditional logic. They require more invasive changes. This is where things get hairy. You have to be brutally honest with yourself about what the minimum viable change is. Every fiber of your being will want to pull the code apart and re-write the whole thing. Don’t do it! Stick to a quick fix, followed by an incremental improvement that refactors it and cleans it up as much as time permits. Your goal is just to make the code a little better every time. The longer you maintain the codebase, the better it will get. To truly make this approach work, make sure you’re always padding your estimates to allow time for a bit of refactoring. Sometimes, the structural defects are so bad that a strategy of forever patching just won’t work. This situation is actually much more rare than you might think. Again, you have to be brutally honest with yourself about the cost/benefit of a rewrite or redesign. You need to accept that, ultimately, this will be a business decision and not a technical one. Prepare to state your case in business terms. What will it cost to do a major restructuring of the code? What are the real business risks of not doing it? If you have a solid case, you will eventually be heard. Don’t be surprised if it takes a few more cycles of patching first, though. Remember: if you are doing a major overhaul, first make sure there’s support for the change and a reasonable budget to go along with it. Don’t try to fly under the radar with this. Unless, of course, you relish awkward conversations with management when you start breaking things and missing deadlines. How to add new features to legacy code Finally, you will eventually be called upon to add features to legacy code. At this point, you have an important decision to make. Do you “go with the flow” of the current codebase, or take things in a new direction? Again, I advise you to be brutally honest in your evaluation. Would continuing to follow the patterns and practices evident in the existing codebase make it worse, or pile onto an existing problem? Most of the time, you’ll want to keep things stable. Just make incremental additions using the existing patterns and practices of the code. Re-use existing elements. Make the least disruptive changes possible, while making small, incremental improvements by cleaning and refactoring. If you believe that a new direction is absolutely necessary, then you’ll need to find a way to isolate your changes and couple them as loosely as possible to the existing codebase. Try carving out the new feature as a separate project. You can then expose an API that lets the legacy code plug into your new code. This makes it so that your new code and the old legacy code don’t need to know much about each other. This starts to get a bit tricky when you need to use functionality from the legacy code in order to implement the new feature. The best way to isolate the old code from the new code is to use the Adapter Pattern. DO Factory has a good explanation of the Adapter Pattern: “The Adapter pattern translates one interface (an object’s properties and methods) to another. Adapters allow programming components to work together that otherwise wouldn’t because of mismatched interfaces. The Adapter pattern is also referred to as the Wrapper Pattern. One scenario where Adapters are commonly used is when new components need to be integrated and work together with existing components in the application. Another scenario is refactoring in which parts of the program are rewritten with an improved interface, but the old code still expects the original interface.” Here are some links to explanations and examples in various languages. JavaScript example of the Adapter Pattern C# example of the Adapter Pattern Java example of the Adapter Pattern Key takeaways In summary, here are the key points that will help you tackle and ultimately conquer any codebase: Never judge legacy code or change it until you’ve taken the time to fully understand it. Sequence diagrams are your friend. Prefer small, incremental improvements over wholesale re-writes or changes. Each change should attempt to leave the code a little better off than it was when you found it. If you need to make big changes, make a business case and get approval first. When adding new features, try to “go with the flow.” If you need to take the code in a new direction, isolate your changes and use the Adapter Pattern to integrate. Hopefully you found this article useful. My mission is to help as many developers as I can.

When Maxime worked at Facebook, his role started evolving. He was developing new skills, new ways of doing things, and new tools. And — more often than not — he was turning his back on traditional methods. He was a pioneer. He was a data engineer! In this podcast, you'll learn about the rise of the data engineer and what it takes to be one. Written by Maxime Beauchemin: https://twitter.com/mistercrunch Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2tHLCST Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: I joined Facebook in 2011 as a business intelligence engineer. By the time I left in 2013, I was a data engineer. I wasn’t promoted or assigned to this new role. Instead, Facebook came to realize that the work we were doing transcended classic business intelligence. The role we’d created for ourselves was a new discipline entirely. My team was at forefront of this transformation. We were developing new skills, new ways of doing things, new tools, and — more often than not — turning our backs to traditional methods. We were pioneers. We were data engineers! Data Engineering? Data science as a discipline was going through its adolescence of self-affirming and defining itself. At the same time, data engineering was the slightly younger sibling, but it was going through something similar. The data engineering discipline took cues from its sibling, while also defining itself in opposition, and finding its own identity. Like data scientists, data engineers write code. They’re highly analytical, and are interested in data visualization. Unlike data scientists — and inspired by our more mature parent, software engineering — data engineers build tools, infrastructure, frameworks, and services. In fact, it’s arguable that data engineering is much closer to software engineering than it is to a data science. In relation to previously existing roles, the data engineering field could be thought of as a superset of business intelligence and data warehousing that brings more elements from software engineering. This discipline also integrates specialization around the operation of so called “big data” distributed systems, along with concepts around the extended Hadoop ecosystem, stream processing, and in computation at scale. In smaller companies — where no data infrastructure team has yet been formalized — the data engineering role may also cover the workload around setting up and operating the organization’s data infrastructure. This includes tasks like setting up and operating platforms like Hadoop/Hive/HBase, Spark, and the like. In smaller environments people tend to use hosted services offered by Amazon or Databricks, or get support from companies like Cloudera or Hortonworks — which essentially subcontracts the data engineering role to other companies. In larger environments, there tends to be specialization and the creation of a formal role to manage this workload, as the need for a data infrastructure team grows. In those organizations, the role of automating some of the data engineering processes falls under the hand of both the data engineering and data infrastructure teams, and it’s common for these teams to collaborate to solve higher level problems. While the engineering aspect of the role is growing in scope, other aspects of the original business engineering role are becoming secondary. Areas like crafting and maintaining portfolios of reports and dashboards are not a data engineer’s primary focus. We now have better self-service tooling where analysts, data scientist and the general “information worker” is becoming more data-savvy and can take care of data consumption autonomously. ETL is changing We’ve also observed a general shift away from drag-and-drop ETL (Extract Transform and Load) tools towards a more programmatic approach. Product know-how on platforms like Informatica, IBM Datastage, Cognos, AbInitio or Microsoft SSIS isn’t common amongst modern data engineers, and being replaced by more generic software engineering skills along with understanding of programmatic or configuration driven platforms like Airflow, Oozie, Azkabhan or Luigi. It’s also fairly common for engineers to develop and manage their own job orchestrator/scheduler. There’s a multitude of reasons why complex pieces of software are not developed using drag and drop tools: it’s that ultimately code is the best abstraction there is for software. While it’s beyond the scope of this article to argue on this topic, it’s easy to infer that these same reasons apply to writing ETL as it applies to any other software. Code allows for arbitrary levels of abstractions, allows for all logical operation in a familiar way, integrates well with source control, is easy to version and to collaborate on. The fact that ETL tools evolved to expose graphical interfaces seems like a detour in the history of data processing, and would certainly make for an interesting blog post of its own. Let’s highlight the fact that the abstractions exposed by traditional ETL tools are off-target. Sure, there’s a need to abstract the complexity of data processing, computation and storage. But I would argue that the solution is not to expose ETL primitives (like source/target, aggregations, filtering) into a drag-and-drop fashion. The abstractions needed are of a higher level. For example, an example of a needed abstraction in a modern data environment is the configuration for the experiments in an A/B testing framework: what are all the experiment? what are the related treatments? what percentage of users should be exposed? what are the metrics that each experiment expects to affect? when is the experiment taking effect? In this example, we have a framework that receives precise, high level input, performs complex statistical computation and delivers computed results. We expect that adding an entry for a new experiment will result in extra computation and results being delivered. What is important to note in this example is that the input parameters of this abstraction are not the one offered by a traditional ETL tool, and that a building such an abstraction in a drag and drop interface would not be manageable. To a modern data engineer, traditional ETL tools are largely obsolete because logic cannot be expressed using code. As a result, the abstractions needed cannot be expressed intuitively in those tools. Now knowing that the data engineer’s role consist largely of defining ETL, and knowing that a completely new set of tools and methodology is needed, one can argue that this forces the discipline to rebuild itself from the ground up. New stack, new tools, a new set of constraints, and in many cases, a new generation of individuals. Data modeling is changing Typical data modeling techniques — like the star schema — which defined our approach to data modeling for the analytics workloads typically associated with data warehouses, are less relevant than they once were. The traditional best practices of data warehousing are loosing ground on a shifting stack. Storage and compute is cheaper than ever, and with the advent of distributed databases that scale out linearly, the scarcer resource is engineering time. Here are some changes observed in data modeling techniques: further denormalization: maintaining surrogate keys in dimensions can be tricky, and it makes fact tables less readable. The use of natural, human readable keys and dimension attributes in fact tables is becoming more common, reducing the need for costly joins that can be heavy on distributed databases. Also note that support for encoding and compression in serialization formats like Parquet or ORC, or in database engines like Vertica, address most of the performance loss that would normally be associated with denormalization. Those systems have been taught to normalize the data for storage on their own. blobs: modern databases have a growing support for blobs through native types and functions. This opens new moves in the data modeler’s playbook, and can allow for fact tables to store multiple grains at once when needed dynamic schemas: since the advent of map reduce, with the growing popularity of document stores and with support for blobs in databases, it’s becoming easier to evolve database schemas without executing DML. This makes it easier to have an iterative approach to warehousing, and removes the need to get full consensus and buy-in prior to development. systematically snapshoting dimensions (storing a full copy of the dimension for each ETL schedule cycle, usually in distinct table partitions) as a generic way to handle slowly changing dimension (SCD) is a simple generic approach that requires little engineering effort, and that unlike the classical approach, is easy to grasp when writing ETL and queries alike. It’s also easy and relatively cheap to denormalize the dimension’s attribute into the fact table to keep track of its value at the moment of the transaction. In retrospect, complex SCD modeling techniques are not intuitive and reduce accessibility. conformance, as in conformed dimensions and metrics is still extremely important in modern data environment, but with the need for data warehouses to move fast, and with more team and roles invited to contribute to this effort, it’s less imperative and more of a tradeoff. Consensus and convergence can happen as a background process in the areas where the pain point of divergence become out-of-hand. Also, more generally, it’s arguable to say that with the commoditization of compute cycles and with more people being data-savvy then before, there’s less need to precompute and store results in the warehouse. For instance you can have complex Spark job that can compute complex analysis on-demand only, and not be scheduled to be part of the warehouse. Roles & responsibilities The data warehouse A data warehouse is a copy of transaction data specifically structured for query and analysis. — Ralph Kimball A data warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of management’s decision making process. — Bill Inmon The data warehouse is just as relevant as it ever was, and data engineers are in charge of many aspects of its construction and operation. The data engineer’s focal point is the data warehouse and gravitates around it. The modern data warehouse is a more public institution than it was historically, welcoming data scientists, analysts, and software engineers to partake in its construction and operation. Data is simply too centric to the company’s activity to have limitation around what roles can manage its flow. While this allows scaling to match the organization’s data needs, it often results in a much more chaotic, shape-shifting, imperfect piece of infrastructure. The data engineering team will often own pockets of certified, high quality areas in the data warehouse. At Airbnb for instance, there’s a set of “core” schemas that are managed by the data engineering team, where service level agreement (SLAs) are clearly defined and measured, naming conventions are strictly followed, business metadata and documentation is of the highest quality, and the related pipeline code follows a set of well defined best practices. It also becomes the role of the data engineering team to be a “center of excellence” through the definitions of standards, best practices and certification processes for data objects. The team can evolve to partake or lead an education program sharing its core competencies to help other teams become better citizens of the data warehouse. For instance, Facebook has a “data camp” education program and Airbnb is developing a similar “Data University” program where data engineers lead session that teach people how to be proficient with data. Data engineers are also the “librarians” of the data warehouse, cataloging and organizing metadata, defining the processes by which one files or extract data from the warehouse. In a fast growing, rapidly evolving, slightly chaotic data ecosystem, metadata management and tooling become a vital component of a modern data platform. Performance tuning and optimization With data becoming more strategic than ever, companies are growing impressive budgets for their data infrastructure. This makes it increasingly rational for data engineers to spend cycles on performance tuning and optimization of data processing and storage. Since the budgets are rarely shrinking in this area, optimization is often coming from the perspective of achieving more with the same amount of resources or trying to linearize exponential growth in resource utilization and costs. Knowing that the complexity of the data engineering stack is exploding we can assume that the complexity of optimizing such stack and processes can be just as challenging. Where it can be easy to get huge wins with little effort, diminishing returns laws typically apply. It’s definitely in the interest of the data engineer to build [on] infrastructure that scales with the company, and to be resource conscious at all times. Data Integration Data integration, the practice behind integrating businesses and systems through the exchange of data, is as important and as challenging as its ever been. As Software as a Service (SaaS) becomes the new standard way for companies to operate, the need to synchronize referential data across these systems becomes increasingly critical. Not only SaaS needs up-to-date data to function, we often want to bring the data generated on their side into our data warehouse so that it can be analyzed along the rest of our data. Sure SaaS often have their own analytics offering, but are systematically lacking the perspective that the rest of you company’s data offer, so more often than not it’s necessary to pull some of this data back. Letting these SaaS offering redefine referential data without integrating and sharing a common primary key is a disaster that should be avoided at all costs. No one wants to manually maintain two employee or customer lists in 2 different systems, and even worse: having to do fuzzy matching when bringing their HR data back into their warehouse. Worse, company executive often sign deal with SaaS providers without really considering the data integration challenges. The integration workload is systematically downplayed by vendors to facilitate their sales, and leaves data engineers stuck doing unaccounted, under appreciated work to do. Let alone the fact that typical SaaS APIs are often poorly designed, unclearly documented and “agile”: meaning that you can expect them to change without notice. Services Data engineers are operating at a higher level of abstraction and in some cases that means providing services and tooling to automate the type of work that data engineers, data scientists or analysts may do manually. Here are a few examples of services that data engineers and data infrastructure engineer may build and operate. data ingestion: services and tooling around “scraping” databases, loading logs, fetching data from external stores or APIs, … metric computation: frameworks to compute and summarize engagement, growth or segmentation related metrics anomaly detection: automating data consumption to alert people anomalous events occur or when trends are changing significantly metadata management: tooling around allowing generation and consumption of metadata, making it easy to find information in and around the data warehouse experimentation: A/B testing and experimentation frameworks is often a critical piece of company’s analytics with a significant data engineering component to it instrumentation: analytics starts with logging events and attributes related to those events, data engineers have vested interests in making sure that high quality data is captured upstream sessionization: pipelines that are specialized in understand series of actions in time, allowing analysts to understand user behaviors Just like software engineers, data engineers should be constantly looking to automate their workloads and building abstraction that allow them to climb the complexity ladder. While the nature of the workflows that can be automated differs depending on the environment, the need to automate them is common across the board. Required Skills SQL mastery: if english is the language of business, SQL is the language of data. How successful of a business man can you be if you don’t speak good english? While generations of technologies age and fade, SQL is still standing strong as the lingua franca of data. A data engineer should be able to express any degree of complexity in SQL using techniques like “correlated subqueries” and window functions. SQL/DML/DDL primitives are simple enough that it should hold no secrets to a data engineer. Beyond the declarative nature of SQL, she/he should be able to read and understand database execution plans, and have an understanding of what all the steps are, how indices work, the different join algorithm and the distributed dimension within the plan. Data modeling techniques: for a data engineer, entity-relationship modeling should be a cognitive reflex, along with a clear understanding of normalization, and have a sharp intuition around denormalization tradeoffs. The data engineer should be familiar with dimensional modeling and the related concepts and lexical field. ETL design: writing efficient, resilient and “evolvable” ETL is key. I’m planning on expanding on this topic on an upcoming blog post. Architectural projections: like any professional in any given field of expertise, the data engineer needs to have a high level understanding of most of the tools, platforms, libraries and other resources at its disposal. The properties, use-cases and subtleties behind the different flavors of databases, computation engines, stream processors, message queues, workflow orchestrators, serialization formats and other related technologies. When designing solutions, she/he should be able to make good choices as to which technologies to use and have a vision as to how to make them work together. All in all Over the past 5 years working in Silicon Valley at Airbnb, Facebook and Yahoo!, and having interacted profusely with data teams of all kinds working for companies like Google, Netflix, Amazon, Uber, Lyft and dozens of companies of all sizes, I’m observing a growing consensus on what “data engineering” is evolving into, and felt a need to share some of my findings. I’m hoping that this article can serve as some sort of manifesto for data engineering, and I’m hoping to spark reactions from the community operating in the related fields!

You've probably heard a lot about bitcoin over the last few years. But do you truly understand how it works? This article explains the concepts in straightforward language (like you were 5) so you'll never be out of the loop again. Written by Nik Custodio: https://twitter.com/nik5ter Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2tzvh1E Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: We’re sitting on a park bench. It’s a great day. I have one apple with me. I give it to you. You now have one apple and I have zero. That was simple, right? Let’s look closely at what happened: My apple was physically put into your hand. You know it happened. I was there. You were there. You touched it. We didn’t need a third person there to help us make the transfer. We didn’t need to pull in Uncle Tommy (who’s a famous judge) to sit with us on the bench and confirm that the apple went from me to you. The apple’s yours! I can’t give you another apple because I don’t have any left. I can’t control it anymore. The apple left my possession completely. You have full control over that apple now. You can give it to your friend if you want, and then that friend can give it to his friend. And so on. So that’s what an in-person exchange looks like. I guess it’s really the same, whether I’m giving you a banana, a book, or say a quarter, or a dollar bill…. But I’m getting ahead of myself. Back to apples! Now say, I have one digital apple. Here, I’ll give you my digital apple. Ah! Now it gets interesting. How do you know that that digital apple that used to be mine, is now yours, and only yours? Think about it for a second. It’s more complicated, right? How do you know that I didn’t send that apple to Uncle Tommy as an email attachment first? Or your friend Joe? Or my friend Lisa too? Maybe I made a couple of copies of that digital apple on my computer. Maybe I put it up on the internet and one million people downloaded it. As you see, this digital exchange is a bit of a problem. Sending digital apples doesn’t look like sending physical apples. Some brainy computer scientists actually have a name for this problem: it’s called the double-spending problem. But don’t worry about it. All you need to know is that, it’s confused them for quite some time and they’ve never solved it. Until now. But let’s try to think of a solution on our own. Ledgers Maybe these digital apples need to be tracked in a ledger. It’s basically a book where you track all transactions — an accounting book. This ledger, since it’s digital, needs to live in its own world and have someone in charge of it. Say, just like World of Warcraft. Blizzard, the guys who created the online game, have a “digital ledger” of all the rare flaming fire swords that exist in their system. So, cool, someone like them could keep track of our digital apples. Awesome — we solved it! Problems There’s a bit of a problem though: 1) What if some guy over at Blizzard created more? He could just add a couple of digital apples to his balance whenever he wants! 2) It’s not exactly like when we were on the bench that one day. It was just you and me then. Going through Blizzard is like pulling in Uncle Tommy(a third-party) out of court(did I mention he’s a famous judge?) for all our park bench transactions. How can I just hand over my digital apple to you, like, you know— the usual way? Is there any way to closely replicate our park bench, just you-and-me, transaction digitally? Seems kinda tough… The Solution What if we gave this ledger — to everybody? Instead of the ledger living on a Blizzard computer, it’ll live in everybody’s computers. All the transactions that have ever happened, from all time, in digital apples will be recorded in it. You can’t cheat it. I can’t send you digital apples I don’t have, because then it wouldn’t sync up with everybody in the system. It’d be a tough system to beat. Especially if it got really big. Plus it’s not controlled by one person, so I know there’s no one that can just decide to give himself more digital apples. The rules of the system were already defined at the beginning. And the code and rules are open-source. It’s there for the smart people to contribute to, maintain, secure, improve on, and check on. You could participate in this network too and update the ledger and make sure it all checks out. For the trouble, you could get like 25 digital apples as a reward. In fact, that’s the only way to create more digital apples in the system. I simplified quite a bit …but that system I explained exists. It’s called the Bitcoin protocol. And those digital apples are the “bitcoins” within the system. Fancy! So, did you see what happened? What does the public ledger enable? 1) It’s open source remember? The total number of apples was defined in the public ledger at the beginning. I know the exact amount that exists. Within the system, I know they are limited(scarce). 2) When I make an exchange I now know that digital apple certifiably left my possession and is now completely yours. I used to not be able to say that about digital things. It will be updated and verified by the public ledger. 3) Because it’s a public ledger, I didn’t need Uncle Tommy(third-party) to make sure I didn’t cheat, or make extra copies for myself, or send apples twice, or thrice… Within the system, the exchange of a digital apple is now just like the exchange of a physical one. It’s now as good as seeing a physical apple leave my hand and drop into your pocket. And just like on the park bench, the exchange involved two people only. You and me — we didn’t need Uncle Tommy there to make it valid. In other words, it behaves like a physical object. But you know what’s cool? It’s still digital. We can now deal with 1,000 apples, or 1 million apples, or even .0000001 apples. I can send it with a click of a button, and I can still drop it in your digital pocket if I was in Nicaragua and you were all the way in New York. I can even make other digital things ride on top of these digital apples! It’s digital after-all. Maybe I can attach some text on it — a digital note. Or maybe I can attach more important things; like say a contract, or a stock certificate, or an ID card… So this is great! How should we treat or value these “digital apples”? They’re quite useful aren’t they? Well, a lot of people are arguing over it now. There’s debate between this and that economic school. Between politicians. Between programmers. Don’t listen to all of them though. Some people are smart. Some are misinformed. Some say the system is worth a lot, some say it’s actually worth zero. Some guy actually put a hard number: $1,300 per apple. Some say it’s digital gold, some a currency. Other say they’re just like tulips. Some people say it’ll change the world, some say it’s just a fad. I have my own opinion about it (and you can check out the link in the original article). That’s a story for another time though. But kid, you now know more about Bitcoin than most.

One day, Sean was working as a route setter at a rock climbing gym in Tennessee. The next, he was driving to San Francisco, without a plan, to start his career in tech. This is the story of his challenging, winding, but ultimately successful path to his first job as a software engineer. Written by Sean Smith: https://twitter.com/bonham_000 Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2JQwSXI Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: One year ago, I was working part-time as a route setter at a rock climbing gym in Tennessee. Today I’m working as a software engineer at a cyber-security startup in San Francisco. My journey to this point has been unforgettable and life-changing. And yet as challenging as everything was, I think that any sufficiently-motivated person could do the same. Knowledge has become democratized. All you need to reach a competitive level in your field is time and dedication. This is especially true for the field of software engineering. In 2016, my life was falling apart When I started learning to code in 2016, I guess you could say my life was falling apart. I’d gone to college as a pre-med student, with degrees in biochemistry and anthropology. But I quickly became disenchanted with science and medicine, and left college with no clear path. I started working as a routesetter at rock climbing gyms for almost 2 years, but things were not going so well. I knew I was in need of a big change. I had been putting off learning to code for a long time, but I knew this was what I wanted to do. Finally, on my birthday in 2016, I committed to learning to code. I didn’t look back. At this point in time, I was vaguely familiar with the coding bootcamps that have become quite ubiquitous over the last few years. Luckily, I quickly discovered freeCodeCamp. When I realized that finishing their curriculum entailed writing software for non-profit organizations, I promptly joined and resolved that I would finish freeCodeCamp’s open-source curriculum before even considering a bootcamp. freeCodeCamp rapidly became the core of my education. I supplemented it with many other resources, such as podcasts, tutorials, open-courseware, and healthy doses of documentation and Stack Overflow when needed. Typical days involved me working through freeCodeCamp challenges and projects, which allowed me to progressively improve my skills. When sitting and writing code became unproductive, I would absorb material through other channels: audio, video, and so on. I moved back and forth between different learning methods, which was very useful in maintaining a strong level of engagement and focus. This was basically my process, and it allowed me to dedicate many hours to learning. Here it is by the numbers (roughly estimated): Total duration learning: less than 12 months Total hours: ~2,500 Total projects completed: 70+ Total CS courses watched: ~10 Total GitHub commits: 1,500+ Total lines of JavaScript written: 20,000+ Most of this learning took place in Knoxville, Tennessee, where I was living at the time. I had a strong desire to move to one of the major tech cities, so one day I woke up and naturally decided it was time to drive to San Francisco. That’s about exactly how it happened. That night I left, and about 3 weeks later arrived in the Bay Area. Plenty of time to listen to podcasts on the road. Arriving in San Francisco for my first real job search After arriving in San Francisco and completing the core freeCodeCamp curriculum (front-end, data visualization, and back-end certifications) I had a brief go at job applications. Around 65 or so. Literally no response. Remember, I had just driven into the Bay Area from across the country. I had no idea how competitive it would be, nor how much my skills were even worth to employers at their current level. Did freeCodeCamp actually measure up to the education of an in-person coding bootcamp? These feeler applications gave me a clear reading: I had to do more. The market is pretty competitive. So I rapidly revised my plans, extended my time horizon, and reached out to freeCodeCamp to begin a non-profit project, since I was now eligible to start one. Meanwhile, I began networking in the city as much as possible. The networking came easily enough, as freeCodeCamp has many self-organized campsites throughout the world’s cities. I got a quick response from freeCodeCamp’s team about the nonprofit projects. Some of my React projects had caught the eye of Michael D. Johnson and Quincy Larson, and they asked me whether I’d be interested in helping write their React curriculum. (freeCodeCamp itself is a nonprofit.) I also helped build a conference management tool for the Conference on Crimes Against Women. I was very excited about the opportunity to give back to this awesome community, so I quickly accepted the challenge. My React and Redux challenges are being incorporated into their newly expanded curriculum, which is now live in beta form live here. In addition, I chose to advance my timeline to 2017. I would continue studying on my own for the remainder of 2016 before applying for jobs again. I left San Francisco, droving north through Portland and Seattle to Bellingham, Washington. It was during these weeks in the Pacific Northwest that I worked non-stop to complete the React and Redux challenges. I collaborated with another freeCodeCamp contributor from New York, Peter Weinberg, and built around 80 coding challenges in total. This was probably one of the key moves that helped set my resume apart, because it represented a significant project that served a real-world organization’s needs. In late December, we finished the initial draft of the challenges and moved them into an official alpha release which is still generating feedback from the community. My triumphant return to San Francisco Back in San Francisco, I was almost ready to dive into job applications again. I had decided to join Outco, a crash course in interview preparation for software engineers. I had always been pretty opposed to spending money at a coding bootcamp (partly because I didn’t have the money), but I chose to join Outco because in my view they are trying to serve a different purpose. Outco is specifically targeting the interview process for software engineers, a process which causes friction for many, even experienced and skilled engineers. Although I could write JavaScript pretty well at this point, I definitely was not prepared to solve arbitrary algorithm questions on a whiteboard. That’s one of the key areas Outco tries to prepare students for, because, for better or worse, whiteboarding remains a favorite interview tactic of tech companies. In addition, I could defer payment to Outco until after I got a job. And, a reality check: I had been going many months now at a strong pace of probably 50+ hours a week of coding and learning, and I was now literally risking it all on my ability to get a job in one of the most expensive and competitive cities in the US. I had already made a sincere effort to apply to companies and failed miserably! The pressure and stress were definitely bearing down on me at this point. I knew success was going to depend heavily on my performance of the next few months. I joined Outco because I expected that their structured program and support would prove indispensable in this last miles of my journey, and it did. 2017 arrived and I started Outco. I began to work even harder than before. Tons of algorithms and data structures practice, whiteboarding questions, technical questions, pair programming, mock phone screens, systems-design questions—you name it, and lots of it. Not to mention applying to jobs again, and a lot more than I did the first time. And, of course, once you begin to get responses from companies it becomes very time-consuming (not to mention very stressful) to begin juggling all of these interviews at once. Practicing for interviews everyday is hard enough. Standing in front of a whiteboard in a real interview as they ask you about binary trees is much harder (and yes, interviewers asked me about binary trees). Again, the numbers tell the story more eloquently: Total applications: 192 (including the 65 from 2016) Total phone interviews: 17 Total take-home code challenges: 6 Total technical screens: 5 Total onsites: 3 Total offers: 1 Total time to offer: 6 weeks Success Rate: 0.52% That one offer was from TruSTAR Technology, and I have been so happy to join their team! TruSTAR is building a platform that allows companies to share cyberintelligence data in order to prevent and mitigate cyberattacks. I’m working on the frontend side of their application and putting to use the JavaScript skills I gained through freeCodeCamp. The experience has been incredible so far, and I have been honestly surprised by how well prepared I have been to begin making meaningful contributions to their codebase. Lessons I learned over the past 12 months Now, finally, here is some advice I would have for anyone looking to do something like this: You need real-world skills and you have to learn a lot. That means a lot of hours of work, there’s no way around it. Passion helps. Building projects is an excellent way to learn, and once you know enough it is not very hard to find open-source projects or other high impact projects to work on. JavaScript and React are great to learn and in high demand! But learn what interests you. It’s critical that you cultivate a community of others who are learning to code or working as engineers. Network in your city. Network online. Find collaborative projects to work on. Ask for help. If you can afford it, try to have some patience. This is what I struggled with the most. There you have it — the journey that led me across the US to begin a career as a software engineer! I’m sure everyone’s path will look different, that’s part of the fun. Find your own path and don’t be afraid to disregard other people’s views if you believe strongly enough in your own. That includes my views. The opportunities in the tech industry are real, and if you want them badly enough, you can find a way there. As an engineer, your job will be to solve problems, and if you are self-taught, the first problem you must solve is how do you teach yourself? Cheers everyone, and happy coding! P.S. A huge shoutout and thank you to the entire freeCodeCamp community and everyone I mentioned in this article (and a few others: Archie, Christian, Susan, Beemer Girl and all my friends from home). You have all proven invaluable in helping me accomplish this goal.

In this episode, Oh My Zsh founder Robby Russell tells the story of how he unexpectedly launched one of the most popular zsh configuration frameworks out there. He shares his process, some mean tweets, and his advice for people starting open source projects. Written and read by Robby Russell: https://twitter.com/robbyrussell  Original article: https://fcc.im/2HzyjYN Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: How I unexpectedly built a monster of an open source project It was the summer of 2009. I found myself helping a coworker debug something in their terminal. As I attempted to type in a few command lines, I noticed that the prompt wasn’t responding to the shortcuts that my brain had grown accustomed to. Frustrated, I exclaimed, “when are you finally going to switch over to Zsh?!” (yeah, I was the type of annoying coworker that would constantly point out that X was better than Y when given the chance. In hindsight, I don’t know how they put up with me…but between you and me, I had a point.) At that point in time, I had been a daily Zsh user for a little over three years. Some of my #caboose friends shared a few of their .zshrc configurations within our IRC channel. After a few years, my .zshrc file grew into a tangled rat's nest. Honestly, I didn’t know what ~30% of the configuration did. I trusted my friends enough to run with it, though. What I did know was that I had some git branch and status details, color highlighting for a few tools (i.e., grep), autocompleting file paths over SSH connections, and a handful of shortcuts for Rake and Capistrano. Working on a machine with a default Bash profile felt remarkably archaic; I’d become dependent on these shortcuts. A few coworkers were happy to copy/paste the .zshrc file that I shared and begin using it. A few others wouldn’t because they knew that I didn’t know what some of it did. Fair enough. After a few attempts to convert them and getting nowhere, I opted for a different approach. First, I reorganized my .zshrc configuration, which involved breaking it up into a collection of smaller files. My thinking here was that this would a) help me better understand how all of these bits worked while b) helping educate my peers when they went to read the code. Pre-empting their next question, “how do I get this to work on my machine?”, I drafted the first setup instructions. Most importantly, I packaged all these files into a shiny new git repository. I figured that if I tossed it up on Github, my peers would be able to collaborate with me on improving it. While not a huge leap, it was a step above inviting people to copy/paste a text file from Pastie. On Aug. 28th, 2009, Oh My Zsh was born. …but, wait a minute!! Where are the themes? Where are the plugins? Installation scripts? Logo? This might come to a surprise to most of the Oh My Zsh user base, but none of those were features that I had considered. My goal with the project was not to build a framework for maintaining Zsh configurations but to share my own config with my coworkers so that they’d use Zsh. Within a day of sharing it with all of my coworkers, everyone at Planet Argon had migrated from Bash to Zsh. Victory! …or so I thought. The first feature request came in the next day. “How do I customize MY prompt?” Two coworkers asked me how they could customize their prompt. They wanted to change the colors and the information that was displayed. What the hell!? Wasn’t my prompt compelling enough for them? So nitpicky. ;-) I pointed to the prompt.zsh file and said they could modify that. Quickly, this became an issue as they now had their own version of that file. As a result, this would add some complexity if we all wanted to share some of our shortcuts and features as we’d have conflicts to deal with. Hmm… So, a day after first announcing Oh My Zsh on my blog, I began introducing the initial concept of themes. Meanwhile, I got my first external pull-request from Geoff Garside to add a few aliases for TextMate. (Notice how that went straight into a catch-all aliases.zsh file) A day later, another theme was sent over. Groovy, I better add a link on the README to see some screenshots on the wiki. Within a month, we had a dozen themes contributed to the project. This began to be a really popular aspect to Oh My Zsh and we had to start hitting the brakes on accepting themes once we passed 100. (we’re currently at ~140 and rarely accept new ones) Simplifying setup with an installer It occurred to me that the initial setup was requiring people to run a handful of commands. Rather than asking people to re-type and/or copy/paste a handful of commands, I felt that it would be more efficient for both parties (as it’d reduce the questions my coworkers would have when they hit a problem and/or skipped a step). An installer was born. My initial thoughts were to handle save folks a few steps by automating the installer. If everyone ran the same commands, then we could cut down on human error (skipping a command, typos, etc.). I also wanted to be mindful that people might be switching from either Bash or an existing cobbled-together Zsh configuration. To help them with a possible switch back to the previous shell, we made a backup of their original configuration file. Finally, we’d switch their default shell to Zsh. “Hooray! Oh My Zsh has been installed.” Oh, right. How will people be able to stay updated with the new changes to the project? The next day, I added an upgrade script that strolls over to the Oh My Zsh directory, fetch updates from the git repository, and returns you to your previous working directory. Far from rocket science. About three weeks later, it became obvious that my coworkers weren’t manually keeping up with all of the new updates to the project. Rather than reminding them to do that from time-to-time, I added functionality that would periodically prompt the user to check for updates. Up until this point, this felt like the most complicated piece of code in the project. I wish that I could remember who gave me the great idea to use an epoch value here. In my opinion, it was also the turning point for the project. While a handful of people were using it, this functionality would allow nearly every user to stay up-to-date on project changes and more importantly, stay engaged. When they would run the updater, they’d see a list of files changed and that would, subtly, introduce them to new features… a la, “I wonder what that theme looks like..” Sadly, not everyone has been a fan. Despite a few vocal opponents over the years, I’ve stood by my decision to keep this as a default setting. Back in 2012, we made a change to reduce the frequency of auto-update prompts by 50%. The auto-update has allowed us to ship new features, performance improvements, and bug fixes without relying on everyone manually doing it. I’m convinced that this feature has helped keep the community engaged. This Muffin Needs Candy While the project was attracting a lot of themes, I really felt like the project could benefit from branding. My solution? Ascii art. I have no idea what prompted the git commit message. My thought process here was… sure, you get a bunch of useful shortcuts and themes when you begin using Oh My Zsh, but I really felt like the first impression after the installer would run was an opportunity to delight new users. People have been asking me to print shirts with the ascii art for quite some time. (we’ll likely do that this summer — follow us on twitter) Plugins Ten months after open sourcing the project, users had begun to request the ability to not have everything get loaded up. For example, a Python developer might not need the Rake and Capistrano related aliases to get loaded like a Ruby developer would. So, we implemented a basic plugin system that would allow folks to decide which to load on initialization by changing a value in .zshrc. When this feature was released, there were five plugins bundled. Within a few months, I started to get pull requests for new plugin ideas. Within a year, I had accepted over 40 plugins. Within two years? Over 70 plugins. Currently, we have plugins for adb, ant, apache2-macports, archlinux, autoenv, autojump, autopep8, aws, battery, bbedit, bgnotify, boot2docker, bower, branch, brew, brew-cask, bundler, bwana, cabal, cake, cakephp3, capistrano, cask, catimg, celery, chruby, chucknorris, cloudapp, codeclimate, coffee, colemak, colored-man-pages, colorize, command-not-found, common-aliases, compleat, composer, copydir, copyfile, cp, cpanm, debian, dircycle, dirhistory, dirpersist, django, dnf, docker, docker-compose, emacs, ember-cli, emoji, emoji-clock, emotty, encode64, extract, fabric, fancy-ctrl-z, fasd, fastfile, fbterm, fedora, forklift, frontend-search, gas, gem, git, git-extras, git-flow, git-flow-avh, git-hubflow, git-prompt, git-remote-branch, gitfast, github, gitignore, glassfish, gnu-utils, go, golang, gpg-agent, gradle, grails, grunt, gulp, heroku, history, history-substring-search, httpie, iwhois, jake-node, jhbuild, jira, jruby, jsontools, jump, kate, kitchen, knife, knife_ssh, laravel, laravel4, laravel5, last-working-dir, lein, lighthouse, lol, macports, man, marked2, mercurial, meteor, mix, mix-fast, mosh, mvn, mysql-macports, n98-magerun, nanoc, nmap, node, npm, nvm, nyan, osx, pass, paver, pep8, per-directory-history, perl, phing, pip, pj, pod, postgres, pow, powder, powify, profiles, pyenv, pylint, python, rails, rake, rake-fast, rand-quote, rbenv, rbfu, rebar, redis-cli, repo, rsync, ruby, rvm, safe-paste, sbt, scala, scd, screen, scw, sfffe, singlechar, spring, sprunge, ssh-agent, stack, sublime, sudo, supervisor, suse, svn, svn-fast-info, symfony, symfony2, systemadmin, systemd, taskwarrior, terminalapp, terminitor, terraform, textastic, textmate, thefuck, themes, thor, tmux, tmux-cssh, tmuxinator, torrent, tugboat, ubuntu, urltools, vagrant, vault, vi-mode, vim-interaction, virtualenv, virtualenvwrapper, vundle, wakeonlan, wd, web-search, wp-cli, xcode, yii, yii2, yum, z, zeus, zsh-navigation-tools, zsh_reload. In total… 214 plugins. Admittedly, not everyone has been impressed by this. I do agree that could be drastically improved. The few times that I considered it, I found the proposed approaches to be too complicated for folks who aren’t yet familiar and/or comfortable with the terminal. Perhaps a more sophisticated approach for version 2 of the framework. (more on this later) There has, also, been a part of me that has felt like this project would only be of interest to people for a few years. As users gained more experience and/or as technology evolved, the framework would be left behind by shiny new projects that solved problems far better than we had. I never thought Oh My Zsh would still be building momentum nearly seven years later. Where do all these new users keep coming from? I ❤ you people! While I have many stories to share (and intend to write more on this topic), I wanted to speak to those who have been debating the idea of open sourcing a project. Eight Considerations For Your Open Source Project Don’t start with a wildly ambitious goal. Start your project with a simple, attainable goal. What does success look like? In my scenario, I wanted 1–2 people on my team to use my scripts. The project was a success in under 24 hours. Everything since has been extra-credit. Don’t try to account for every scenario. If I had gotten hung up on some long-term details for the project, Oh My Zsh would never have happened. Nearly everything that has been added to the project has come organically post-initial release. One of the beautiful aspects of an open source project is that your user base can help shape it. Don’t try to make it perfect. Worrying how other people are going to react about your code shouldn’t be your biggest concern. Does it work? How do they feel when they’re interacting with it should be a higher concern. In my case, I’ve had some great contributors over the years who have helped tidy up and improve the quality of the code that I originally released. Rarely has anyone said anything critical about my old code — maybe they should have, though. ;-) Don’t try to be everything to everyone. There have been a few points in the history of the project where we hit a crossroads. In particular, there was a time when a huge rebuild was proposed, which I was quite excited about until I was able to wrap my head around some of the changes. As a result, a fork was rebranded and we agreed to follow different paths. Not everyone was happy with my decision here, but it was during this period that it became clear (to me) that I wanted to focus my attention on folks who weren’t too comfortable with the terminal and/or git. Don’t stop thanking contributors. If anybody helps your project out, please let them know how much you appreciate their effort. I can’t thank my contributors enough. One of my biggest self-critiques related to this project is that I’ve not been consistent enough in being vocal about my appreciation. There are 910 people from all over the world who have their code accepted into the master branch of Oh My Zsh at the time of writing this. It’s such a long list that Github can’t even list them all. In particular, thank you. (you know who you are) Don’t forget the documentation. Over the years, documentation of plugins and functionality has been vital to helping inform users on how to take advantage of the framework. I wish we had adopted this convention several years before. The README file is going to be seen the most…so make it count. In my case, I opted to introduce people to my personality and dry sense of humor. Honestly, seeing tweets like this means the world to me. Don’t forget about the rest of your life. Again, I never anticipated the project turning into what it is today. Are you familiar with the anecdote about the frog in a pot of boiling water? It took me 3–4 years, too many, to finally bring in another person to help maintain the project. I kept thinking that I could catch up with all the open pull requests and issues. What I kept telling myself was that folks who know how to fork the project can make their desired changes and work off of that, so reviewing and approving pull requests is a nice-to-happen versus a need-to-happen. In practice, it’s somewhere in between. I do feel a bit bad for old pull requests lingering, but I also don’t keep Oh My Zsh as one of the top few projects on my plate. Outside of Oh My Zsh, I run a 19-person agency, play guitar in an instrumental post-rock band, sit on the board of directors of a local homeless shelter non-profit, travel with my camera a lot, ride my motorcycle, ride my bicycle, and try to keep a social life with my friends. Oh My Zsh fits somewhere in amongst all of these. It’s not at the top of my priority list. It’s not at the bottom. It’s somewhere between. This isn’t an excuse to not being able to keep up with the community, but more of a reminder that those other things should matter to you, too, if you’re about to start your own project. (I will write more on the topic of leading an open source project w/maintainers in another story… ❤ are you following me? ❤) Don’t forget to have some fun. When you start your project, decide if this is going to be serious work time or play time. Perhaps it can be somewhere in the middle. Oh My Zsh has, always, been a play time activity project for me. Knowing that one of my playful projects has been and continues to be enjoyed by people is such a wonderful feeling. Some might call it a passion project. I call it playtime. Interested in my fun open source project? You can learn more at http://ohmyz.sh.

Have you built your app on someone else's code? And beyond that, does the "secret sauce" of your product depend on external libraries or frameworks? While it's tempting to use the latest and greatest tech as soon as it comes out, that's not always a great idea. In this episode, Bill explains why, and what to do to protect your code. Written by Bill Sourour: https://twitter.com/BillSourour Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2HerXO5 Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: “Change is the only constant…” – Heraclitus (Philosopher) The tools, libraries, and frameworks we use to build our web applications today are drastically different from the ones we used just a few short years ago. In a few short years from now, most of these technologies will have changed dramatically again. Yet, many of us make these a central, inextricable part of our apps. We import, use, and inherit from the flavor-of-the-month frameworks as if they’re all going to be around and unchanged forever. Well… they’re not. And that’s a problem. After 20+ years of developing, designing, and architecting web applications, I’ve come to appreciate two important truths: External dependencies pose a great threat to the long term stability and viability of any application. It’s increasingly difficult — if not impossible — to build any kind of non-trivial app without leveraging external dependencies. This article is about reconciling these two truths so that our apps have the greatest chance of long-term survival. The rabbit hole is very deep indeed. If we start thinking of all the things our web apps depend upon it’s easy to think of a dozen or more before we even get to the code: Power Connectivity Firewall DNS Server Hardware (CPU, Disk, Ram, …) Cooling Virtualization Platform Container Platform Operating System Web Server Platform App Server Platform Web Browser As developers, it’s good to be aware of these things, but there’s often not much we can do about them. So, let’s ignore them for now and talk only about the code. In code, there are three kinds of dependencies: 1. Dependencies we control This is code written and owned by us or our organization. 2. Dependencies we don’t control This is code written by a third party vendor or open-source software community. 3. Dependencies once removed These are the code dependencies our third-party code dependencies depend upon. (Say that three times fast!) We’re going to talk mainly about dependencies we don’t control. Dependencies we control and dependencies once removed can still cause headaches, but in the case of dependencies we control, we should be able to directly intervene and mitigate any problems. In the case of dependencies once removed, we can usually rely on a third-party to take care of it for us, since they are dependent on these, too. Why third-party code dependencies are good A large portion of your web application exists to solve common problems: authentication, authorization, data access, error handling, navigation, logging, encryption, displaying a list of items, validating form inputs, and so on... Regardless of which technology stack you use, there’s a good chance that common solutions to these problems exist, and are available as libraries that you can easily acquire and plug-in to your codebase. Writing any of this stuff completely from scratch is generally a waste of time. You want to concentrate on code that either solves an uncommon problem or solves a common problem in an uncommon way. That’s what makes your application valuable: the code that implements the business rules that are unique to your app alone — the “secret sauce.” Google’s search and page ranking algorithm, Facebook’s timeline filtering, Netflix’s “recommended for you” section and data compression algorithms— the code behind all of these features is “secret sauce.” Third-party code — in the form of libraries — allows you to quickly implement those commoditized features of your app, so you can stay focused on your “secret sauce.” Why third-party code dependencies are bad Take a look at any non-trivial web-app built in the last couple of years and you’ll be absolutely astounded by the amount of code that actually comes from a third-party library. What if one or more of those third-party libraries changes drastically, or disappears, or breaks? If it’s open-source, perhaps you can fix it yourself. But how well do you understand all the code in that library you don’t own? A big reason why you use a library in the first place is to get the benefits of the code without having to worry about all the details. But now you’re stuck. You’ve completely tied your fortune to these dependencies that you don’t own and don’t control. Perhaps you think I’m exaggerating, or speaking from a purely academic point of view. Let me assure you — I have dozens of examples of clients who completely snookered themselves by embedding third-party code too tightly into their app. Here‘s just one recent example… A former client of mine built their app using a Backend-as-a-Service provider owned by Facebook, called Parse. They used a JavaScript client library provided by Parse to consume the Parse service. In the process, they tightly coupled all of their code — including the “secret sauce” code — to this library. Three months after my client’s initial product launch — just as they started getting some good traction with real, paying customers — Parse announced it was shutting down. Now instead of focusing on iterating on their product and growing their customer base, my client had to figure out how to either migrate to a self-hosted, open-source version of Parse, or replace Parse completely. The disruption this caused for a young, fledgling application was so huge that my client eventually scrapped the app entirely. Balancing the good and the bad Several years ago, my go-to solution for overcoming the risks while retaining the benefits of third-party-libraries was to wrap them using the Adapter Pattern. Essentially, you wrap the third party code in an adapter class or module that you’ve written. This then works to expose the functions of the third party libraries in a manner that you control. Using this pattern, if a third-party library or framework changes, or goes away, you only have to fix a bit of adapter code. The rest of your app stays intact. This sounds good on paper. When you have self-contained dependencies that only provide a few functions, this will do the trick. But things can get ugly fast. Can you imagine having to wrap the entire React library (including JSX) before using any of it? How about wrapping jQuery, or Angular, or the Spring framework in Java? This quickly becomes a nightmare. These days I recommend a more nuanced approach… For each dependency you want to add to your codebase, evaluate the level of risk it will introduce by multiplying two factors: The likelihood that the dependency will change in a material way. The amount of damage a material change to the dependency would do to your application. A third-party library or framework is less likely to change when some or all of the following things are true: It has been around for several years and has had several major releases. It is widely used by many commercial applications. It has the active support of a large organization — preferably a household name company or institution. A third-party library or framework will do less damage to your application when some or all of the following things are true: It’s only used by a small portion of your application, rather than being used throughout. The code that depends upon it is not part of that “secret sauce” I talked about earlier. Removing it requires minimal changes to your codebase. Your entire application is very small and can be rewritten quickly. (Be careful with this one — it’s rarely true for very long.) The riskier something is, the more likely you should be to wrap it or avoid it altogether. When it comes to the code that is really central to the value proposition of your application —your “secret sauce” — you need to be extremely protective of it. Make that code as independent as possible. If you absolutely need to use a dependency, consider injecting it rather than directly referencing it. Even then, be careful. Sometimes this means saying “no” to a third-party library you think is really cool, or that you really want to use for one reason or another. Be strong. Trust me, it will pay off. Just ask all those people who invested heavily in the very first release of Angular, or my former client who used Parse everywhere. It’s no fun. Believe me. Speaking of fun, take a look at this… The image above is the dependency graph for an application called TinyTag Explorer. Generating a dependency graph for your existing apps is a great way to understand the level of risk being introduced by your dependencies. I’ve put together a list of free tools for generating graphs similar to the above in a variety of languages including JavaScript, C#, Java, PHP, and Python. You can get it here. Help me help others I want to help as many developers as I can by sharing my knowledge and experience with them. Please help me by clicking the ❤ recommend button (green heart) below. Finally, don’t forget to grab your list of free dependency graph generators here (link in original article).

Austin had a biology degree, a poor GPA, and a job in the medical field, but he wanted to transition into tech. He had no experience, but he figured out how to gain it quickly and landed offers from his dream companies. In this episode, he shares his advice and methods so that you can do the same. Written and read by Austin Belcak: https://cultivatedculture.com Original article: https://fcc.im/2LydTlZ Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: In this episode I’ll show you how to quickly gain experience in any field, as well as how you can leverage that new experience to land job offers in that field. I personally used this strategy to transition from the medical field — where I was working in hospital operating rooms — to the tech industry, where I received offers from Google and other tech companies (along with a 200% raise). Myths about things you DON’T need when switching fields Before we dive in, I think it’s important to address a few “myths” about changing industries: You don’t need an extensive network of contacts. In fact, you don’t need any contacts at all — you can make them all on your own. You don’t need a degree in the field you want to switch to. Perception is reality, and results speak volumes when it comes to perception. They are worth more than any degree or previous job title. More on that later. You don’t need money. Everything you need to know can be learned for free. In fact, I’m going to show you how this process can actually help you generate a second stream of income. Next, I’m going to outline the exact steps I used to land a job in a totally different industry so you can make it happen for yourself. Part 1: Painting a picture of the perfect candidate The good news about entering a completely different field is that you are a blank canvas. You can choose your skills and mold yourself into the perfect candidate. What does perfection look like? In order to become the ideal candidate, we must first understand what “ideal” looks like in the eyes of the people who will be hiring you. There are two ways to accomplish this: Job descriptions Job descriptions are essentially resumes in reverse. They spell out the exact skills you need in order to be successful in that particular role. That sounds obvious, but we are going to be looking at this from an atypical lens. Let’s take a look at this Growth Marketing Analyst role that I grabbed from Facebook’s site: Responsibilities - Leverage data to understand our products in depth, identify areas of opportunity, and execute projects to drive growth and engagement of Facebook users. - Drive projects focusing on new user growth, mobile usage, and revenue — working closely with design, product, engineering, and data teams. - Work both on core Facebook products like news feed, notifications, and mobile, and offsite marketing channels like SEO, SEM, and email. - Use tools like Hadoop/Hive, Oracle, ETL, R, PHP, Python, Excel, MicroStrategy, and many other internal tools to work efficiently at scale. Minimum Qualifications - BS or MS in Engineering, Computer Science, Math, Physics, Statistics. - 1+ years experience with SQL. - 2+ years of quantitative or statistical analysis experience. - 1+ years of experience managing a project. - 1+ years of experience in marketing, advertising or growth. - Ability to process and analyze data sets, and interpret them to make business decisions. - Communication skills and ability to manage a project or product. Preferred Qualifications - Software development experience. - Internet Marketing experience. What do you see here? What does the ideal candidate look like? What do they need to get hired? My guess is that you’re thinking, “Ok, they need a degree in computers or math. Then they need at least two years of experience coding and managing projects at a company.” Well, here’s what I see: Facebook is looking for someone who understands how to identify trends/patterns within big data that will have a direct impact on revenue. That person also has enough knowledge of programming to efficiently make those discoveries and present them in a simple, concise fashion. The main issue a lot of people have is that they think the only way to get “experience” is to work at company or have fancy degrees. This is one of the biggest myths when it comes to job searching. In order to understand it, let’s take a step back and think about why companies hire. They want someone who will come in and have a large, positive impact on their bottom line. Someone could have a PhD in Computer Science and be fluent in all of the programming languages mentioned above, but if they lack the ability to clearly convey results, the company isn’t going to benefit. On the other hand, someone who may not have a degree or total fluency but understands how to find impactful insights and presents them in a concise, actionable manner is extremely valuable. Your goal is to become that second person. Informational interviews In addition to combing through job descriptions, it’s equally important to get in touch with people who work in the industry. They will be able to help you prioritize the skills you found in those job applications, as well as give you some inside info on the intangibles (nuances of the hiring process, putting you in touch with their contacts, etc.). I’ve found that the best way to make this happen is by leveraging LinkedIn’s advanced search filters. You can search for people at specific companies, with specific titles. If you have LinkedIn Premium, you can even search for people who used to work in your industry and now work in your target industry — or even at your target company. Then you can use this email script to reach out: Subject: Quick Question Hi [Name], My name is Austin and I currently work at Cultivated Culture. I was browsing through LinkedIn and came across your information — I hope you don’t mind me reaching out of the blue here. I saw that you have extensive experience in Facebook’s Growth Analytics vertical and I’m very interested in learning more about that space. I would love to have the opportunity to run some questions by you, as well as tap into any advice you may have given your knowledge of the industry. I know that your time is extremely valuable so please don’t feel to need to respond in depth. If you do have 5 minutes to chat, I would really appreciate it. Best, Austin When they agree to a meeting, you’ll want to prepare some questions. They should focus on: Identifying which skills are the most crucial for performing daily activities (this will allow you to prioritize) Providing some background on how that person got to where they are (you’d be surprised at how many people came from other industries) What they would do if they were in your shoes — trying to get this job with little to no experience in the field Here are those bullets in question form to help get you started: I’ve been doing some research and it seems like [Skill 1] — [Skill 3] are common in the space. Which of these do you think is the most crucial to success? I was looking through your LinkedIn and saw that you came from [Previous Role/Company]. How did you initially get involved in this industry and how did you end up at [Current Role]? Let’s say you were in my shoes — you’re new to the industry and don’t have too much experience. How would you go about getting your current job? What specific steps would you take? Bringing It All Together Now you have an understanding of the skills that you need, where they stand in terms of priority, and a roadmap from someone who has/had the role you want. Next, you need to build a foundation with those skills and use them to generate results that directly align with the company’s goals for that role. Part 2: Nailing The Basics (On The Cheap) Over the next month or two we’re going to focus on building a rock solid understanding of the basics needed for the skills you identified above. For now, the best ways to do this are by reading books, taking courses, and creating a sandbox you can use to test your knew knowledge. Reading Up (For Free) Books are a fantastic way to understand the basic concepts of a specific subject. They also happen to be very easy to get for free. Remember that public library your parents wanted you to check out when you were a kid? It’s actually still there! Amazing, right? The good news for you is that even public libraries have caught up with the times and now carry ebooks. You can borrow them for free like any other book, but they will be sent directly to your phone so you can read them anywhere, anytime. All you need to do is install the Kindle app (which you can get for free for iOS and Android). In order figure out which books to read, I would Google “best books on [subject]” or go ask some folks on Quora. Taking Courses (For Free-ish) While books are giving you the 30,000 foot view of your topics, courses will help you figure out the nitty gritty. They are a better way to learn the actual skills because they tend to be interactive and are updated regularly. One of the best resources for our purposes is Coursera. Coursera aggregates courses from the best professors at the best schools in the country (I’m talking Princeton, Stanford, Harvard — they don’t mess around). These courses are fantastic because they are structured like an actual course you would take in college. They have videos, but they also have tests, projects, and forums where students can collaborate. This is key because it helps make the course “sticky” due to the fact that you are committing to all the above rather than just watching a few videos. Best of all, at the end of the course, you can receive a certificate stating that you passed the course. It will even have the seal from that university on it! It does cost ~$49 but it’s well worth it because you can put that right on your resume: Subscribing To Industry Blogs & Newsletters Next, you’re going to want to sign up for some newsletters. Blogs stay in business by having the highest quality, most up-to-date information and getting it out there as quickly as possible. This is the easiest way for you to stay on top of current events in the industry while picking up tons of knowledge along the way. You can find them using the same method you used to find the books — Googling and hitting up Quora. Additionally, try to find a niche blog as they tend to have highly detailed information on your topic. Here are some examples: SEO: The 10 Chapter Beginner’s Guide To SEO Content Marketing: The Advanced Guide To Content Marketing Facebook Ads: The Ultimate Guide To Making Money With Facebook Ads Free Resources (Where Applicable) Many industries and fields have a ton of free resources out there to help your learn. For example, if you’re an analytics person — Google Analytics is completely free to set up. Additionally, Google offers an entire course on the platform for free. If your plan is to break into the development field, you’re already in the right place. Free Code Camp is one of many great resources that will help you learn the basics of programming for free. Be sure to do a thorough search on your industry. Chances are good that free training resources exist. Bonus Pro Tip: Google Alerts Google Alerts are an awesome way to save yourself hours that you would have spent searching for articles on specific topics or companies. You can set them up for anything that you could feasibly search for in Google, but probably want to stick with the salient points like a specific industry, certain skills, the company you want to work for and Beyonce. Then, every day, Google will crawl the web and find the most relevant (and worthy) articles on your specific subjects and deliver them straight to your inbox. You can sign up for Google alerts here. Part 3: Getting Paid To Hone Your Skills Yup, you read that right. We’re going learn how to have someone pay you to learn the skills you need to change industries. Building Credibility & Real-World Results Now that you understand the basics of these skills, it’s time to really develop them. I’ve found that the best way to truly learn something is by doing it. I can’t think of a better way of “doing” than selling your skills for some cold hard cash. Rapidly Develop Your Skills By Freelancing While it may seem like a daunting task, it’s fairly easy to get started in the freelance world even if you have no prior “experience.” As Tim Ferriss says, the definition of an expert is someone who knows more than the person they are dealing with. There are two ways of going about finding clients when you’re starting out — freelance aggregator sites and traditional cold outreach: Upwork (A Freelance Aggregator) Upwork is a community where business owners come to find freelancers for everything under the sun. The beauty of Upwork is that it removes the need for you to invest a lot of time in marketing yourself. It is an inbound site meaning your services will show up to people who are already looking for that particular service, making them more likely to hire. That may also be attractive to someone who is uncomfortable with a traditional sales process. The trade off is that, while you save time, Upwork charges a hefty fee for saving you that time. For our purposes, that’s not too terrible because you’re mostly in it for the learning while the money is icing on the cake. I recommend using Upwork if you’re having trouble managing the sales process on your own, or if you’re just starting out and need to build up a few success stories. If you really want to expand your initial reach, check out Hubstaff’s comprehensive rundown of Upwork alternatives and get yourself on multiple platforms. Cold Outreach The second option, and the path that I recommend, is handling the sales process on your own. That way you get to keep 100% of the revenue and remove the middle man. This can be a bit tougher initially because those businesses may not be actively looking for your services and if you don’t have much sales experience, the learning curve can be steep. In this section we’ll through the steps that I used to land my initial clients, build success stories and then use those results to expand my portfolio (and increase my revenue). Define Your Niche Our first step on our freelancing journey is defining our target prospect. Most articles out there tell you that when you start a business your niche should be laser-focused, like Male Golfers, Ages 47–54 who suffer from back pain. While I agree that it should be targeted, it’s not reasonable to expect that you’re going to know your target audience in that level of detail before you’ve even worked with a single client. You’ll begin to hone in on your ideal niche as you go, but for now we’re going to use the following process to determine our target audience (actually, we’re going to choose 3). Defining Your Initial Target Prospect Start by making a list of 50 people that you know. It can include everyone from your best friend’s parents to a connection on LinkedIn you met at a conference last year. The only criteria they need to meet is that you must feel comfortable reaching out to that person. Add these people into this spreadsheet I created for you along with their company type and industry (ignore the email column for now, we’ll get to that later): Now that we have our people, let’s take a look at their company type and industry. Which industries and company types match up best with your knowledge and skill set? If we take my list, I know that my marketing skills could benefit a tech company, but they could also benefit a health & wellness startup looking to build an audience. Additionally, know that it’s much easier to sell into startups than corporations when you’re first starting out. With that in mind, my ideal mix is: Company Type: Startup Industry: Advertising, Tech, Web Development & Health/Wellness Now we have one “niche,” but my list here is only 10 people. I want you to try and find 3 different niches where one or more of your skills apply. Then I want you to assign each niche a number and label your spreadsheet (you can also highlight too if that helps): Awesome! You just defined 3 areas that you can sell into and you have your first set of prospects. Key Takeaway: Don’t get caught up in finding a super-specific niche before you’ve ever booked a client. Keep things broad, take on a few initial clients and your niche will narrow over time. Create Time & Be Consistent I have spent a lot of time reading about success. I’ve also spent a lot of time building businesses in hopes of chasing it. After sifting through the thousands of pages and lessons, I found that one thing had the greatest influence on whether I was successful or not: Consistency The ability to work on something every single day — regardless of how you feel, how crazy your job is or how many friends tell you to go to happy hour — is the difference between succeeding and failing when you start a business. In order to be consistent, you have to create time. Time that you know is not going to be interrupted. For me, that means waking up at 5:30am. For you, early may work, or maybe late at night is your thing. Whatever you do, make sure that it’s a natural fit for you. You don’t want to feel like you have to drag yourself to do this, otherwise it will never work. Put It In Your Calendar Start by opening up your Google calendar and finding a 1.5 hour block of time that works for you at least 5 days every week (yes, that includes weekends). Create an event and set reminders for 1 hour before and 15 minutes before. Mark that time as “busy” on your calendar: Hold Yourself Accountable Now it’s real — ink on paper. However, your calendar invite isn’t going to get you out of bed the day after you went out a little too hard or help you say no to those free concert tickets to see Kanye. If we truly want to stick with this, we’re going to need a little outside help. I personally recommend StickK because I’m a competitive person who doesn’t like losing. StickK basically lets you bet yourself that you will start your business. You put down a dollar amount (I recommend $100) and you set a goal. Then you’ll be assigned a “referee” who will hold you accountable. If you complete your goal, you get your $100 back. If you don’t, that money is donated to the charity of your choice. I can personally tell you that the thought of $100 being yanked out of my wallet has helped me push through many hangovers. Getting Your First Client Now that we’ve got our service and our niches nailed down, it’s time to get some paying customers. Since we don’t have much in the way of a portfolio, we’re going to want to start by aiming for a prospect where we have a personal connection. Then we’re going to leverage the current experience that you have to land the deal. Let’s head back to our spreadsheet and look through the list of names that we highlighted in each niche. I want you to go ahead and rank each of these people in the order of how likely they are to help you. Then we’re going to reach out to each from top to bottom. Finding Emails If you don’t already have their email, you can easily find it by using VoilaNorbert or FindAnyEmail.net. Once you have it, go ahead and plug it into your spreadsheet for future reference. Reaching Out Now we’re going to reach out to our contact and ask them if they can help us set up a meeting. Here is the exact email template you can use for that: Subject: Quick Question Hi [Name], Hope you’re doing well! I wanted to let you know about a business I’m starting up called [Company Name]. It’s aimed at helping companies [Insert Value Prop]. Most recently we were able to [Insert Success Story]. I did a quick audit of [Prospect’s Company] and I have some ideas that I’d love to share with you. Could you help me get in touch with the correct person? Either way, would love to catch up soon! Best, [Your Name] All you need to do is fill in their name, your skills and press send. I would also highly recommend getting an email tracker such as Hubspot (free) or Yesware (better, but costs $). These will allow you to see if your prospect read your message and help you determine whether or not to follow up. If they open your email once, that trail is dead. However, if they open it multiple times across multiple days, feel free to follow up with them after 4–5 business days. I have personally followed up with people 8–10 times before eventually getting a response that led to a deal. Preparing For The Meeting Once the meeting is set, we want to make a compelling case for why this company needs your services. The best way to do that is using what I like to call The Audit Technique. It’s extremely simple and effective: Carefully review our prospect’s current set up (website, social media, content, copy, health — whatever fits your service) Identify as many issues/improvements as we possibly can Determine the measurable impact of fixing these issues Share specific strategies for solving 2–3 of the issues and then showcase the potential result of fixing all of them Tell them that, regardless of whether or not they hire you, they can keep the audit report Boom! Easy. Closing The Deal In the beginning, most of your prospects aren’t going to be seeking you out. That means that you have to convince them that your services will be worth their time and money. The best way to do that is via the following framework: 1. Address We’re going to start off the meeting by addressing the issues that you found with their site. Don’t be too critical. The goal here is to make them feel good about their business while also letting them know that there is a lot of untapped potential out there. Hand them your Audit Report and walk them through each of the issues. Explain what is happening, why it’s hurting their business, and what the solution is. 2. Illustrate Potential Once you’ve explained the issues, you want to clarify what the prospect is missing out on. The more quantifiable this is, the better. For example: Your call to action on the site isn’t strong enough. Your conversion rate is probably 5% lower than where it should be. If your site gets 30,000 visitors a month, that’s 1,500 people we’re not capturing! Instagram accounts like yours typically see 100–300 followers every day, but you are only netting 20–30. If you implement the strategy I laid out here you should see an immediate boost within a few days. That could mean an additional 2,400 followers each month! Show them how this is impacting their bottom line. Walk them through the math: You: What is your typical sales conversion rate from your email list? Prospect: Hmmm, it’s around 3% You: Wow, that’s pretty good! And how much profit do you make from each sale? Prospect: Typically we net around $150 per sale. You: Awesome. Based on my audit, I’m seeing that we’re missing out capturing an additional 3–5% of your site’s traffic due to poor copy and CTA placement. I poked around and saw that your site gets ~30,000 visitors per month which means that we could be capturing an additional 1,500 people every month. Based on the numbers you just gave me, that’s $6,750 per month! If you charge $2,000 per month, that’s a no brainer for your prospect. Any business owner would pay $2,000 if they knew it would result in an incremental profit of $4,750 — and you just made $24k this year! Ask Them For The Sale Now that you’ve proven out the value — ask them for the sale: Tell them that the Audit Report is theirs to keep regardless Reiterate the potential opportunity they have to gain Outline what next steps look like for hiring you Ask them if they want to move forward Chances are good that they’ll want some time to think about it. No worries at all — drop note on your calendar to follow up with them 72 hours later. You just booked your first client! Now I want you to rinse and repeat this process for everyone on your spreadsheet. If you can get your foot in the door, you can expect about a 5%-10% close rate. Consolation: Offering Your Services For Free Since we’re mostly in this for the learning, this is great option to consider if the above process isn’t initially working out. I found that it was much easier to land clients when I had success stories I could speak to. It’s important to figure out a way to get some results before you go all-in on pitching for money. You can reach out to businesses, same as above, and offer your services for free. This takes away all of the risk for the company, making them much more likely to agree, while allowing you to get right to the learning and create real-world results. Remember, we’re in this to try and find a job we love that pays us what we deserve. That is worth a LOT more than a few paid freelance contracts. If the freelancing turns into a source of revenue, that is icing on the cake. Leveraging Your Results To Land Your New Job There you have it — a step-by-step plan to build the experience you need to land a join a different industry. Now it’s time to get out there and get your foot in there door. First up, edit the resume. Add Your Experience To Your Resume As soon as you have some concrete results under your belt, you’re going to want to add them straight at the top of your resume. This will be the first thing that your potential employer will see and it helps remove any doubt about your qualifications. Way back up at the top of the article we took a look at why companies hire. The qualifications of X years is just an arbitrary number set by the company to make them feel like they are hiring someone who can do the job. Adding in your freelance experience not only shows that you can do the job, but also that you have an understanding of how to run a business. This knowledge is extremely valuable to an employer, especially for a technical hire because technical folks typically get tunnel vision and have trouble seeing how their work relates to the larger picture — making money. Identify Influencers At Your Target Company Now that you have the relevant experience, you’re going to want to start connecting with influencers who can help refer you into your dream job. I outline that exact process in my article How To Land A 6-Figure Job In Tech With No Connections so be sure to check that out when you’re ready.

Some people have very strong coding instincts. They can solve problems just by looking at them, and feel like rockstars. But being a rockstar coder can only get you so far. You need one other crucial element: discipline. In this podcast, Bill shares his disciplined approach to writing code and to work in general. Written by Bill Sourour: http://twitter.com/billsourour Read by Abbey Rennemeyer: http://twitter.com/abbeyrenn Original article: https://fcc.im/2IzwWdH Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: I wrote my first few lines of code almost 32 years ago, when I was 6 years old. I developed very strong coding instincts. I could look at any problem and immediately know how to solve it, just by intuition. By the time I started coding the web for a living, I felt like a rock star. I found and fixed bugs faster than any of my co-workers. My team started assigning me all the most challenging features and the most nagging bugs. They even started calling me a “wizard.” But following your intuition can only take you so far. I hit a plateau. And no amount of coding instinct was going to push me past it. The trouble with trusting your gut Unfortunately, intuition as a technique for learning and problem solving doesn’t scale very well. When you rely on instinct and intuition alone, you get a curve that looks like this (See original article for graph). Of course, you can choose to accept your limits and only ever deal with problems below the line. This will indulge your “rock star coder” fantasy, but it will quickly begin to limit your growth and your career. Plus, it’s boring. As I pushed myself further and further ahead in my career — and started to really challenge my own abilities — I began to notice a disturbing trend. I was no longer the fastest kid on the block. I had always known that I’d eventually run into people smarter and more talented than me. (My delusions of grandeur were still grounded in reality. I’m no genius.) But when I looked around, I realized that some of the people beating me were not using a superior intellect or some sort of innate gift for code. They just had a secret weapon that I sorely lacked: discipline. It turns out that a consistent, repeatable, methodical approach to learning and problem solving will eventually outperform any natural gifts — or instincts — that you may have developed. Let’s tool up those problem solving abilities Regardless of who you are, how much passion or natural talent you have, you will eventually hit a hard ceiling. I’m going to share with you a few techniques that will dramatically improve your disciplined problem solving abilities. I’m assuming that, if you have a debugger, you’ve already run it, Googled the output, and had no luck. I’m also assuming that if the problem was reported by someone else, you have been able to reproduce the problem. This second assumption is a big one. If you can’t reproduce the problem, then that needs to be your first step. You need to compare the context and environment in which the problem occurred to the context and environment in which you are trying to reproduce it. Start eliminating any differences you can, one by one, until you can reproduce. Once you can reproduce the problem, and after the debugger has failed to be of any use, you can try the following disciplined approaches. RTFM Read the documentation, you fool! (Admittedly this isn’t what RTFM stands for exactly, but there may be children reading.) Actually read it — more than once if you need to. Don’t just skim it looking for something you can copy, paste, and pray will work. The problem is you want an answer fast. You want that thrill of victory. But you’re not willing to put in the work. So slow down. Take a breath. Grab a coffee. And read the relevant documentation all the way through. If you have no documentation, consider creating some, then sharing it with others after you’ve fixed the problem. Test Your Assumptions If you expect something to work and it doesn’t, it’s because you’ve made a bad assumption somewhere along the way. Take an inventory of your assumptions and try to prove that each one is true. Start with the most basic assumptions that can be quickly tested. Is the server actually running? Is it connected to the network? Is everything spelled correctly? Are all the brackets and semicolons in the right place? If you don’t start with the simple things, and it does turn out to be one of these things, when you finally figure it out you will want to jump out a window. So save yourself the headache. Disassemble and Reassemble Remove components from the solution until it starts working again, then put the components back one-by-one in order to find the broken piece. This feels tedious and scary, but it is one of the most effective, disciplined ways to find the cause of a bug in your code. Make sure you have a backup before you start though, in case you accidentally end up with Humpty Dumpty code (code that you can’t put back together again). By the way, if you find yourself in a situation where you don’t know how to reassemble the code back to how it was, this is an indication of a potentially bigger problem: you don’t understand the codebase you’re working with. That’s bad bananas, my friend. If you’re on a tight deadline, seek help immediately from someone who understands the codebase better than you. If no such person exists, dig in for a long night, and prioritize getting to know and understand how this code works, so that you can fix it. Eliminate Variables Anything that can change from one trial to the next should be made to remain static while you’re debugging. You can’t hit a moving target. This is where Test Driven Development (TDD) comes in handy. If you’re using TDD, then you should have some mock objects at your disposal. Mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts. — Wikipedia If you didn’t do TDD, then you’ll need to mock out any moving parts now, so that you can find the bug under stable conditions. Here’s a tip: if you mock an object and the bug suddenly goes away, then the bug is likely in the object you mocked. Use the “Saff Squeeze” There’s a technique called the “Saff Squeeze” — named and popularized by Kent Beck — that is sort of a cross between the two ideas above. He describes it this way: “To effectively isolate a defect, start with a system-level test and progressively inline and prune until you have the smallest possible test that demonstrates the defect.” — Kent Beck So instead of formal mocks or code disassembly, you simply add the body of the functions that you’re testing into the test itself, then move the assertions down until the bug goes away. This has the added benefit of leaving you with smaller, more specific tests. Edit: Thanks to Jim Balter for pointing out this link to a good example and explanation of the Saff Squeeze. After You Fix It, Break It and Fix It Again Never leave a bug until you fully understand how you fixed it. You should be able to reproduce the bug and fix it again at will. I can’t stress this enough. If you fix a bug and you’re not sure exactly what caused it or how you managed to fix it, that bug will come back to bite you at the worst possible time. What About Those Instincts? Now that you’ve learned these techniques, does that mean you should always use them first instead of relying on your instincts? No. Absolutely not. What I recommend is that you give your instincts a time box in which to succeed. If you have a strong hunch about what the problem might be — and you can test your hunch quickly — do that first. If the bug is below the green line in the chart above, chances are that your instincts will be the fastest path to a solution. Once you’ve quickly tried your first or second hunch and been wrong though, stop the shotgun approach and start doing things methodically. Having both instincts and discipline will make you one of the top coders on any team. To help you even more, I have put together a free PDF list of my five favourite code refactoring techniques — that lead to fewer bugs — get it by clicking the link in the original article.

You’ve heard it before: “There’s no such thing as a free lunch.” We're taught so from an early age. But history has shown: you often can get something for basically nothing. In this episode, Quincy discusses how we can all enjoy the abundance economy and - for all intents and purposes - get a free lunch. Written and read by Quincy Larson: http://twitter.com/ossia Original article: https://fcc.im/2wxPlpS Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Check out the book Abundance: The Future Is Better Than You Think by Steven Kotler and Peter H. Diamandis Transcript:  You’ve heard it before. Maybe you’ve even said it. “There’s no such thing as a free lunch.” “You can’t get something for nothing.” “Somebody has to pay.” People recite these sayings with confidence, as though they were quoting Newton’s Laws of Motion. But history has shown: you often can get something for basically nothing. And even when somebody has to pay, that somebody doesn’t have to be you, and the amount doesn’t have to be very much at all. In some cases, the benefits so vastly outweigh the costs that it is — for all practical intents and purposes — a free lunch. How we eradicated Polio from the face of the Earth In the early 1950s, the US was recovering from its worst Polio epidemic ever. Thousands of children died from this virus, and many more suffered life-long paralysis. No one was safe from this horrible disease. Even US president Franklin D. Roosevelt contracted it at age 39. He spent the rest of his life in a wheelchair. Enter Jonas Salk, a medical researcher who had mainly studied flu viruses before turning his efforts toward Polio. Dr. Salk spent 7 years assembling a team of researchers and working to develop a Polio vaccine. He conducted the most extensive field test ever, involving what historian Bill O’Neal says were “20,000 physicians and public health officers, 64,000 school personnel, and 220,000 volunteers.” The vaccine was a success. So Dr. Salk set to work immunizing everyone on Earth. He pushed the marginal costs of the Polio vaccine as low as possible — to just the raw materials necessary — by forgoing any financial benefits his intellectual property would have brought him. When asked about his patent, he said, “There is no patent. Could you patent the sun?” Dr. Salk stared down a massive problem and threw himself into it with everything he could, without any aspiration for personal gain. And in the process, he and his colleagues basically wiped out one of the worst diseases ever. Today, everyone’s life is better off as a direct result of this one massive free lunch. “The reward for work well done is the opportunity to do more.” —Dr. Jonas Salk Free lunches are important Before I run through some modern-day examples of free lunches, let me give you some background on myself, and why the notion of a free lunch is so important to me. I run a nonprofit, open source community where you can learn to code, practice by building software for nonprofits, then get a job as a developer. Thousands of people have gotten developer jobs so far. And it’s free. I was so committed to the idea of it being free that I put the word “free” in the name. Free can mean both libre — free as in free speech, and gratis — free as in free beer. Just like the “free” in “Free Open Source Software” (FOSS), the “free” in “freeCodeCamp” means both of these. But still, every day I encounter people who are skeptical. They tell me they don’t use freeCodeCamp because “it sounds too good to be true.” “There’s no way all this can be free,” they say. “I’ll sign up and give you my email address, and only then will I find out that I need to pay $20 a month, right?” Or: “You’re free for now, but soon you’ll throw up ads and paywalls, like everybody else does.” Well, I’ve said this publicly a hundred times, and I’ll say it publicly again: freeCodeCamp will always be free. We operate on the fringe of capitalism. The frontier where marginal costs asymptotically approach zero, and the very laws of classical economics begin to unravel. A place called the abundance economy. And we’re not alone. Low overhead engineering with lichess.org Meet Thibault Duplessis, the founder of lichess.org — the second most popular chess website on the planet. As of a year ago, lichess had 78,000 unique daily visitors, who play a total of 260,000 games of chess each day. Thibault has no employees. He doesn’t even work on lichess full-time. He still has a job at a development consultancy. Lichess’s main competitor, Chess.com, is a privately-held behemoth that makes millions of dollars each year off of banner ads and premium membership up-sells, then spends that money acquiring their competition. Contrast this with Thibault, who has open-sourced lichess’s server code. He has promised that lichess will be free forever, and that it will never show ads. But wait — how can he do this? Because of the nature of modern web applications, and the economics of their near-zero marginal costs. Despite lichess’s complexity — and the scale at which it operates — Thibault’s server costs are a mere $416 a month. This cost is covered by merchandise and donations from his grateful users, who increasingly include some of the best chess players in the world. How Craigslist covers costs by charging only 0.1% of its users Remember classifieds? People used to pay a dollar per word for tiny ads that appeared in the backs of newspapers, sandwiched between other ads. Then, 20 years ago, Craigslist utterly disrupted classifieds. They provided a directory of ads online, for free. It was searchable. You could use as many words as you wanted, and include pictures. You could repost your ads as many times as you wanted, in as many nearby cities as you wanted. But if placing ads on Craigslist was free, how did Craigslist make money? Well, if you asked a random Craigslist user, they probably wouldn’t be able to tell you. Most people just assume that Craigslist is a nonprofit, supported by donations or something. But Craigslist made $400 million last year. They did it by charging to post in a few key categories within a few key cities. If you want to list an apartment in New York City, or a job in San Francisco, you have to pay Craigslist a small fee. This means that less than one in a thousand people who use Craigslist actually pay any money to do so. Those real estate agents in New York City and those recruiters in San Francisco are paying for everyone else’s free lunch. Craigslist doesn’t have investors. It keeps things simple. It has a small team of about 40 people. Craig still works at Craigslist. He handed over the role of CEO to his long-time friend so he could focus on doing what he loves: providing support for Craigslist users around the world. Like the other people mentioned in this article, he doesn’t seem to care about money. From what I can tell, he donates most of his money through his charity CraigConnects. And he spends his downtime advocating for causes he cares about, like supporting veterans and helping more women start their careers in tech. Crowd-sourcing contributions with Wikipedia Before Wikipedia, the most popular encyclopedia was written by paid experts, and printed in massive books. The Encyclopaedia Britannica was so expensive that they wouldn’t even tell you its price in their TV spots. (It cost $1,400.) Jimmy Wales — Wikipedia’s visionary leader — had a better idea. He leveraged the power of the internet and the wisdom of volunteer contributors. And he made it free. The number of volunteer-contributed articles on Wikipedia exploded. It quickly surpassed traditional encyclopedias in the scope of its content. Instead of waiting for a new physical edition to hit the press, Wikipedia editors could instantly publish updates to articles. Wikipedia was so up-to-date that many people started using it for news on current events. Traditional encyclopedias were quickly backed into a corner. They were paying expert writers and editors to create their content. Surely this resulted in more accurate information than Wikipedia’s volunteer-driven free-for-all. But in 2005, a major academic journal published an analysis comparing the factual accuracy of Wikipedia versus the Encyclopaedia Britannica. It found: “Jimmy Wales’ Wikipedia comes close to Britannica in terms of the accuracy of its science entries, a Nature investigation finds.” — The abstract from Nature’s analysis In a last-ditch effort, The Encyclopaedia Britannica pushed back, but Nature upheld its finding. This was the final blow to the encyclopedia industry, which had flourished for decades by selling stacks of books door-to-door to guilty parents. A decade later, Wikipedia is now the 6th most visited website on the planet. And covers its operating costs through more than $70 million in donations each year from grateful patrons. But despite all of Jimmy’s accomplishments, people seem to be much more preoccupied with his money. Or rather, his lack-there-of. Here’s what you get when you type “Jimmy Wales net worth” into Google: Below this result, Google shows you pictures of people who started other large websites. Each of them has a net worth that’s five orders of magnitude larger than Jimmy’s paltry $1 million. People have a hard time accepting that someone would set out to build something as important as Wikipedia without bothering to make money out of it. One person went so far as to ask straight up on Quora: “Is Jimmy Wales rich?” Jimmy responded: “By any sane standard of measurement, yes, of course I’m rich. Nearly half of the people on earth live on less than $2 a day. I spend more than that on my cellphone bill.” There’s so much more to life than money. Why are people so preoccupied by money, and the net worth of famous people? Because they’re operating in a scarcity mindset. They are so preoccupied by the risk of not having enough that they can’t see the real risk: missing out on the potential for so much more. The traditional scarcity mindset approach to creating value at scale goes something like this: Figure out a problem you can solve for a large number of people 2a. If people will pay for your product, sell it to them, then re-invest the profits into growing your business (bootstrapping) 2b. If your solution isn’t something people will pay for, raise a bunch of venture capital to fund development. Once it’s big enough, make money some other way — usually by selling ads. But there’s an alternative. An abundance mindset. This approach shrugs off concerns for basic needs (worst case scenario, I have to get a job in fast food) and instead focuses on upside potential. When you apply an abundance mindset, you approach problems from a different perspective. You try to identify opportunities for free lunches. Your approach to creating value at scale will look something more like this: Figure out a problem you can solve for a large number of people Keep costs low, fund development yourself, and ask for donations, sell merchandise, or find a few users with deep pockets who can subsidize everyone else. This is how all of these organizations I’ve discussed here operate. And this is how they can always be free.

There’s no time for anything. At least that’s how it feels doesn’t it? No time to refactor that ugly code, no time to work on documentation, no time to actually live your life. But if you take the time to listen to this podcast, you’ll find yourself with more time for what’s important. Written by Bill Sourour: https://twitter.com/BillSourour Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2rqbKAp Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: There’s no time for anything. At least that’s how it feels doesn’t it? No time to learn all the things you think you need to learn to stay ahead of the curve. No time to go back and refactor that ugly piece of code. It works (sort of) and there’s a deadline approaching. No time to write unit tests for everything. No time to write documentation or comments for the next guy who gets stuck maintaining what you wrote. No time to think. No time to breathe. No time! Well… if you take the time to read this article, I promise you’ll find yourself with more time for what’s important. I used to think that the only way to be a great developer was to work myself sick. My health, friendships, and family all suffered because of it. Understanding the following 5 truths about time management for a developer is what saved me. 1. You don’t need to learn every new thing in order to stay relevant. There is no question that a good developer should always be learning, but where you focus your learning can make a huge difference in the amount of time it takes to stay on top of your game. “The old thing is dead. Long live the NEW, about-to-be-old thing!” First of all, don’t get suckered in by headlines on dev blogs that announce a new standard every 37 seconds. Most new technologies, frameworks, and features will never get any real traction and you’ll never need to know them. Those that do emerge will take a lot longer to gain adoption than the blogosphere — and the vendors who hock these new technologies — would have you believe. Companies are invested in their tech stack and, other than a handful of tiny tech startups, they can’t just turn on a dime. So, relax, your career is safe. Focus your learning on three areas, in the following order of priority: Fundamentals — It’s a lot easier to pick up new skills when you have a real command of the underlying fundamentals. For example, if you understand JavaScript deeply, you can master any new JavaScript framework in record speed. If you understand Object Oriented Programming deeply, you can master new object oriented languages quickly, too. Deeply learning the fundamentals will 10x your learning efficiency. Always focus on improving fundamentals above all else. The latest version/feature of the stack(s) you use the most — There’s a stack of technologies that you probably use every day. These are the tools that will put food on the table for you and your family. When new versions of these tools are released, it’s worth investing the time to learn about them. In-demand tech that is backed by market leaders — if a big, well established company like Google, Facebook, or Microsoft puts out something new and it starts getting some buzz, it’s worth looking into. There were a hundred and one JavaScript frameworks all vying for attention and then Angular and React showed up and wiped them off the map. I’m not saying there won’t be disruptors that come from nowhere and become the next big thing but, more often than not, no-name tech is just noise. Learning time should be a part of your schedule. Set aside a specific amount of time for learning every day. It doesn’t need to be a lot of time, even 25 minutes of reading and experimentation every day adds up quickly. 2. Writing good code takes less time than writing bad code, BUT it doesn’t feel that way. You probably feel like the time you spend on a new feature ends when you run the code and it appears to work. But that’s just the beginning of your time investment. Time spent on a feature includes time spent debugging that feature later and also time spent refactoring and working other code around any poor design decisions you made when implementing that feature. When you start to understand your time investment this way, it becomes obvious that, in the long run, fewer errors and better design are a worthwhile investment. There are two things you can do that will reduce errors in your code and lead to better design. Use test-driven development. Write the test first, then write the code that satisfies the test. This not only leads to less buggy code but also to better design, because when you have to structure code in a testable way, you end up making smaller, simpler functions that have fewer dependencies. Use an iterative design approach. Don’t spend time trying to make code perfect before you’ve spent time trying to make the code work. You’ll never, ever get it right completely in your head. You have to get those fingers banging on a keyboard and produce code that runs and does what’s expected. The problem is that developers tend to make one of two common mistakes; either they spend too much time thinking and not enough time actually doing, or they don’t spend enough time improving their first solution. Follow the mantra first stated by Kent Beck: “make it work, make it right, make it fast” — and in that order. 3. Working 24/7 does NOT make you a hero. Managing expectations does. This is the one that nearly killed me. I used to agree and commit to any crazy timeline my boss or client could come up with. I was afraid of saying “no.” I was afraid of letting anyone down. I would do whatever it took to deliver. I have literally slept under my desk, and pulled multiple caffeine-fueled 40+ hour marathon coding sessions. At first I was a shining star. I would get a big pat on the back and I felt like a hero. But I set an expectation that was impossible to live up to. Working like that is unsustainable. Eventually, I started to burn out, get sick, and miss deadlines. I started getting a reputation as unreliable and inconsistent. It was bad news. What I eventually came to understand, and what you should commit to learning too, is that the real heroes are the ones who are consistently reliable. They say what they’ll do and do what they say. The only way to be that kind of hero is to manage expectations. You need to take control of the timelines so that you are always and without fail delivering high quality work exactly on time. This is incredibly difficult at first. It means having to say “no” and having to push back. In the beginning, your boss or client won’t be thrilled by your resistance, but once you demonstrate that you are trustworthy and reliable, everything will start to change. Over time, other developers will be late, deliver sloppy work, or burn out and become unreliable. Then you will become the real hero of your team. In fact, learning this made me one of the most in demand consultants in my market. I’ve built a stellar reputation for quality and timeliness, because I vigorously manage expectations. 4. Not all time spent “improving” code has the same ROI. Spending time is an investment. Like all investments, it’s reasonable to expect a return on investment (ROI). You should be getting back at least as much — and hopefully more — value than you put in. We talked about “make it work, make it right, make it fast.” It’s a good mantra but there is a trap: “right” does not mean perfect, and “fast” does not mean absolutely as fast as possible. “Right” means that the code works consistently and is easy to refactor. “Fast” means that the speed of execution does not have a negative impact on the overall user experience. The most important thing is that your application feels fast to the user. So, don’t waste time trying to shave time off a function that is barely used, or trying to save another few milliseconds on something that already runs faster than a human can blink (~300ms). And don’t waste time trying to refactor working, well-structured code because you just learned some new technique or approach that you’ve convinced yourself you suddenly have to go back and apply to everything you’ve ever done. 5. Scheduled down time makes you more productive. This was a very hard one for me to learn and accept. How can you possibly be more productive when you’re not spending all your time producing? Well, it’s true. According to Allison Gabriel, an assistant professor of management at Virginia Commonwealth University who studies job demands and employee motivation, “There is a lot of research that says we have a limited pool of cognitive resources. When you are constantly draining your resources, you are not being as productive as you can be. If you get depleted, we see performance decline. You’re able to persist less and have trouble solving tasks”. Always working sets off strain reactions, such as stress, fatigue, and negative mood. These drain your focus and your physical and emotional resources. The brain’s ability to self-regulate — to stay disciplined — wanes with each exercise of self-control during the day. It’s a loss of resources that must be replenished. Otherwise it becomes harder to stay on-task, be attentive and solve problems. Your mind and body need down time, and they’re going to get it whether you like it or not. So, schedule that down time. Actually plan and put on your calendar real scheduled breaks. This will allow you to take down time without feeling guilty about it. It will make work-time easier to endure because you’ll know that you have a scheduled break right around the corner. More help and resources To help you even more, I’ve put together a list of free and useful resources (videos, tutorials and websites) that can help you better understand and implement the insights I’ve just shared with you. You can get it here: https://www.devmastery.com/signup/time/index.html  

Austin was stuck in a job he hated. But given his non-traditional background and lack of Silicon Valley network, he knew he'd have to work extra hard to launch a career in tech. In this podcast, he details the steps he took to land interviews at Google, Twitter, and other prestigious companies that led to his dream job. Written by Austin Belcak: https://cultivatedculture.com Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2F8uE2H Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: Shortly after college, I began chasing something many people want but few ever get: a job they love. I left school with a biology degree and a job in the medical field. It took me about two weeks to realize I absolutely hated it. I was working 6 days a week, waking up at 3:30am in order to be at the hospital by 5:30. Making next to nothing, I quickly racked up $10,000 in credit card debt. I knew I deserved more, but I had no idea how to get it. I saw people in my graduating class living in New York or San Francisco, making six figure salaries and going on exotic trips. I often wondered what they had figured out that I hadn’t. What was their secret? I dedicated the next 12 months of my life to finding the answer. In this article I’m going to share everything I learned along the way. First, I’ll walk you through the exact process you can use to get a job interview at your dream company even if you don’t know a single person there — you won’t even need to apply online. Next, I’ll teach you how to ace the interview process, get the offer, and land a salary you deserve. I personally used these exact strategies to get interviews and offers at companies like Google, Uber and Twitter. They are also the same tactics that my students have used to land interviews and offers at Google, Microsoft, Slack, Deloitte, PWC, American Express, ESPN and more. Referrals Are The Most Effective Way To Get Hired A recent LinkedIn survey on talent trends showed that 1 in 3 people were actively looking for new work. As of January 2017, the population of employed people in the United States was 123 million. This means that, at any given time, 41 million people are looking for work. On average, an open role at a well known company gets ~250 resumes. 75% of these resumes came from some sort of online portal (like the company’s online application, or a career aggregator site like Indeed.com). Once submitted, these applications are screened by Applicant Tracking software that scans them for keywords. At the end of the process, ~5 resumes make it into the hands of a recruiter. That’s 2% at best. Additionally, The Wall Street Journal published an article stating that 80% of jobs aren’t advertised online. That means that 75% of people applying for jobs are all competing for 20% of the opportunities! Oops. When it comes to getting hired, referrals are the most effective way to secure an interview and land the offer. Here are some stats from a recent Jobvite survey: 40% of hires come from referrals, the next largest channel is via career sites at 21% (almost half as many) Referrals get hired in an average of 3 weeks while other applicants take up to 7 weeks Referrals get paid more on average than cold applicants 40% of hires come from referrals (courtesy of Jobvite.com) Finally, over 50% of six figure jobs are filled via referral. Moral of the story? If we want to get hired at our dream job, we need to find another way to get a referral from an insider. The problem is, many of us don’t happen to have friends or family working at places like Google. Part 1: How To Get A Job Interview When You Don’t Know A Single Person At The Company Know Your Role (And Find It) The first step is having a solid idea of the specific role you are looking for, down to the company and title if possible. Next, you need to make sure that role is available. For today, let’s assume that you want to be an Account Manager in the Technology B2B vertical at Google. Looks like a spot is open in New York: Locate Potential Influencers Next, you are going to find someone who not only knows about the role, but could potentially have an impact on hiring for it. Time to fire up LinkedIn. In the search bar, plug in the company name + all of the information I highlighted above (title, vertical/industry, preferred city). However, before you hit “Search,” we need to remember that you are looking for someone who can influence the hiring process. With that in mind, I usually use a title that is one level up from the position that I’m looking for. If you’re not familiar with title hierarchy structures in the corporate world, here is a quick guide (if you are already familiar with how titles are structured, feel free to skip this section): Side Note: A Brief Guide To Company Organizational Structures By Title Every company has a hierarchy starting at the top with the CEO/Founder all the way down to the entry level employees. When researching companies, especially people to speak to within those companies, it helps to know where certain titles fit in the food chain. That way you can ensure you are talking to the right person. Here is a general list of titles that fits almost any company, starting at the top: C-­Level (CEO, CTO, CFO, COO, etc.) Vice President (VP) Director Senior Manager Manager Coordinator (Entry Level) Associates, Executives, and Seniors In many companies, the above titles have some sort of variation that allows for greater segmentation within that level. The most common forms of this are Associate, Executive, and Senior. Here is what those mean: Associate: this title is usually given to someone who is halfway between positions for some reason (maybe there is typically a 4 year gap between levels and they are 2 years in). A person with Associate in their title is usually one notch below a person with the original title. For example, an Associate Account Manager would most likely be one level below an Account Manager. Senior: ­this title is the more experienced version of an Associate. People with Senior in their title are usually one notch above the original title. For example, a Senior Account Manager would be one notch above an Account Manager. Executive: ­this title is usually given to people who are very senior, or around the level of Vice President. The two most common cases are Sales Executive/Account Executive (synonymous terms for a senior salesperson) or Executive Vice President who is two notches above a Vice President and one notch above a Senior Vice President. That should be all the info you need to make an educated decision around where people stand within the company you are researching. Now that you’re familiar with the company structure, let’s get back to finding that influencer who can help you land this job. Since we are looking for an Account Manager role, the next step up would be Senior Account Manager so your LinkedIn search would look like this: Our first result? A Senior Account Manager who works in B2B at Google: Obtaining Contact Info Now we’re going to reach out and set up a meeting. It’s best to do these in person but over the phone can work well if you’re dream job is in another state or country. In order to get in touch with our influencer, we’re going to need their contact info. Here are 3 strategies you can use to find almost anyone’s corporate email address: LinkedIn This one is obvious but it’s a big time saver and definitely worth the 10 seconds it takes to check. On the person’s profile, right under their picture, there can be a button labeled “Contact Info” (I say “can be” because people have the option to remove it). Occasionally, people will have their email address listed right there — voila! If not, let’s move right along… Reverse Lookup Head over to Voila Norbert and enter the first and last name of the person you are searching for, as well as their company’s website. For example, if we were trying to find Larry Page’s email, our form would look like this: Once it spits out their email you can confirm it using MailTester. Matching Formats If that doesn’t work, you can try finding someone else’s email at the company and use that format reverse engineering your target email address. For example, using Larry Page again, if I know that my buddy John Smith’s email is john at google.com then I can assume that Larry’s email is larry at google.com. The easiest way to get a hold of a company email address is to reach out to someone in sales or media because both of these departments usually have inbound lead forms and people on the other end ready to pounce on those leads. We can also use our LinkedIn method here and target salespeople. Salespeople almost always have their corporate email listed on their LinkedIn because it’s a free win for them. If someone is looking for their product and then finds them on LinkedIn, boom — they just got an effortless inbound lead. Once you have the format, you can use MailTester to confirm your target email address. Research, Research, Research Now that you have your potential influencer, it’s time to do some research so you can effectively reach out and build that relationship. Start with the usual suspects — LinkedIn, Facebook, Twitter, Instagram, etc. and look for common points of interest. To be honest, most people are better at this online research thing than I am, so I’ll get back to the meat here. One thing I will say is, don’t skimp. The more you get to know this person beforehand, the better your chances of landing a referral from them. Some people have said to me, “Austin, isn’t this a little weird? I feel like I’m kind of stalking this person.” I totally get it. However, this information is critical for quickly building a strong relationship and getting that referral. Also, in my experience, people tend to expect that you’ve done some research on them. The key is to understand what is kosher to bring up out of the blue and what isn’t. People are OK with you checking out their LinkedIn, but they may be a little weirded out if you mention that picture from Saturday’s Bar Crawl you saw on Facebook. My general rule of thumb is this: if it exists on LinkedIn, it’s fair game to bring up. If you found it somewhere else (Twitter, Facebook, etc.) use a different method. For example, if I see that my influencer is a skiing fanatic, I may bring up that I went on a ski trip a few weeks beforehand. Sending The Email Now that you have your potential influencer and their contact info, it’s time to reach out. Not only is this one of the scarier parts of this process, it is also the most pivotal. To help you get past that hump, I’ve included the exact email script that I used to reach out to people. In this case, I’m reaching out to Tim who works at Google: Subject: Quick Question Hi Tim, My name is Austin and I currently work at Cultivated Culture. I was browsing through LinkedIn and came across your information — I hope you don’t mind me reaching out of the blue here. I saw that you have extensive experience in Google’s Technology B2B vertical and I’m very interested in learning more about that space. I would love to have the opportunity to run some questions by you, as well as tap into any advice you may have given your knowledge of the industry. I know that your time is extremely valuable so please don’t feel to need to respond in depth. If you do have 5 minutes to chat, I would really appreciate it. Best, Austin There are a few key points to the email above: Address the person you are emailing by name State who you are and make it personable Include some flattery that positions the person as an “expert” As for the subject, Fast Company did a study where they emailed 1,000 C-level executives from Fortune & Inc 500 companies. They found that the subject line “Quick Question” made up 66.7% of total replies. I saw similar results. All of that said, this script is just a framework. You will most likely need to tweak your emails to fit the situation. When that time comes, I recommend checking out Sam Parr’s incredible guide on how to cold email like a boss (Sam has started conversations with Jeff Bezos and Brian Lee (aka Jessica Alba’s Honest co-founder) via cold email). It’s the same guide I used to help craft my email templates. Now hit Send! Prepare For Your Meeting In order to prepare, we have to know what we’re preparing for. The goal of your meeting is to position your influencer as an expert, make them feel special, and build a relationship. You should not and will not mention anything about the opening at their company. People innately enjoy helping others and if you follow the steps above, they will bring this up naturally. You will want to prepare a list of questions that gets them to open up about themselves and the company. I like to ask them several softballs to get things warmed up and then hit them with a few questions they are guaranteed to remember. Here is a quick set that I’ve had success with in the past (I’ve found the last one really seems to stick): I saw you worked at [Previous Companies]. How did you end up going from [First Industry] to becoming interested in [Current Company]? You hear a lot about [Current Company] in the news, but I’d love to hear more about why you love working there. What’s your favorite part? What is one totally unexpected lesson you’ve learned from working at [Current Company]? The “Million Dollar” Question Regardless of the questions you choose, there is one that you must always be sure to ask: “What is the biggest challenge your team is facing right now?” Really dig in here, get them to be specific. This information is going to be critical in helping you land a referral from this person, as well as getting the offer farther down the road. Your Homework: Adding Value (In A Big Way) Okay, so you met with your influencer, things went great, and you identified a major pain point that the team is having. Now we’re going to focus on that last piece. Over the next week you are going to research the crap out of your influencer’s problem. Then you are going to come up with a solution and draft up a proposal for how you would solve it. Your proposal should include: A summary of the problem (to illustrate that you understand their pain) A step-by-step framework of how you would solve this problem A brief outline of how your skill set positions you as an asset to implement that solution Truthfully, this process deserves a post of its own but this should give you a good idea of what you need to do. If you’re the type of person that likes concrete examples, check out this guerrilla usability test that Raghav Haran ran for Airbnb. Once you have all of this information, consolidate it into a Word document, head over to Upwork, and hire a graphic designer to make your proposal look amazing. If you’ve never hired on Upwork before, here is an amazing guide by Dave Nevogt on how to do it right. Following Up With Your Proposal Now we’re going to reach back out to our influencer with the proposal. Here’s the template I used: Hi [Influencer], Thanks again for taking the time out to chat last week. I spent a lot of time thinking about what you said regarding [team’s biggest challenge]. In fact, I created a short framework that should help you solve it. Please find that attached. If you have some time, I would love to chat about it in more detail. Please let me know if you have any questions, I’m looking forward to hearing your thoughts! Best, Austin It’s very important that you do not mention the open position in any of your emails or the proposal. Be patient and wait for their response. When they do get back to you, they will not only bring up the opening but they will ask you if you’re interested. Kindly accept and play it cool. You’re in! Part 2: How To Breeze Through The Interview Process Fast forward — our influencer passed along our resume to HR and they have reached out to set up a phone screen. Once we get past that, we’ll be on to interviewing with the team, and then getting the job. A note to developers: The advice below does not cover technical interviews, which are typically required for developer/software roles. However, the advice below will help create more time to prepare for technical interviews by minimizing the amount of preparation needed for other parts of the interview process. If you are applying for a development role, I suggest you read Cracking The Coding Interview by Gayle Laakmann McDowell. Interviews can be daunting, especially at companies like Google, Amazon, or Uber. I’m sure you’ve read the horror stories about crazy questions they ask people like “Quick — How many golf balls can fit inside a school bus,” or, “how many gas stations are there in Manhattan?” The truth is, most of these companies have done away with those questions. They crunched the numbers and found that the answers didn’t correlate with high employee performance (shocker, I know). In fact, Google’s own Senior Vice President of People Operations called them a “complete waste of time.” These companies have since reverted back to the standard style of interviews, which is great for us because it makes it much easier to identify patterns. We can essentially “guess” what questions will be on the test and prepare answers that will blow our interviewers away (it works way better than it did in college, I swear). Here is the process I used to prepare for each one. Nailing The Basics: Questions You’ll Get In Every Interview According to renowned career guru Penelope Trunk, one of the easiest ways to be a better interviewer is to prepare for the most obvious questions. You may be saying “well duh,” but you’d be surprised by how many people spread themselves too thin by trying to prepare answers to every possible question. 99% of the interviews you go on will follow the exact same template. If you can master the format, your confidence will skyrocket and you’ll be prepared for almost any situation you get thrown into. The Universal Job Interview Format: Tell me about yourself (your experience, why you are interested in this role, etc.) A mix of behavioral questions, which we’ll dive into shortly What questions do you have for me (the interviewer)? Let’s tackle each individually. Tell Me About Yourself This is your first impression. More importantly, it’s the only part of the interview that you totally control. Do NOT rattle off your resume like a grocery list. In order to nail this part you need to craft an interesting story — your story. You want it to be concise (around 2–3 minutes) and you need to think about what you want to convey. I recommend: Choosing 2–3 themes to build your story around (for me, those themes were Persistence, Agility, and Success) Including quantitative metrics whenever possible Addressing the question of why you want to leave your current position (they are going to ask you this anyways, addressing it early shows that you’re aware it’s a concern of theirs and helps put them at ease) To help get you started, here is what my story looked like. To give you some context, I was a biology major who was interested in landing a job in digital marketing: Growing up, like most people, I wanted to be a doctor. I went to [college] where I majored in biology and planned my course to medical school. Not long after, I decided that pre-med wasn’t for me. I wanted to get into digital marketing, and I wanted to be in New York. I set my sights on this goal and created a plan that would get me there. In 2013, I graduated with my biology degree and took a job in medical device sales where I worked from 5:30am — 12:30pm covering surgical cases in the operating room. Then, every day, I would come home and study digital marketing until 8:00pm. In order to gain relevant experience, I got certified in Google Analytics & AdWords and created my own consulting firm that focused on using search engine marketing to generate leads for private golf communities. We were able to increase home sales by an average of 20% while reducing the cost per lead by around 10%. Armed with my new credentials, I began to look for positions in New York. Eventually, I was offered a position at my current company (a promotional analytics company in New York). During my tenure there I have grown my book of business by 467%, spearheaded the creation of an internal group dedicated to marketing the company on the internet, and helped close the second largest deal in company history. However, the company has restructured several times since I was brought on. I’ve had 3 different managers over the past year, as well as 3 titles with different sets of responsibilities. I’m looking for something a bit more stable and [company I am interviewing at] has been somewhere that I have wanted to work since I got into this industry. I’m really excited to have this opportunity. Pro Tip: You are telling a story. Don’t be afraid to embellish a bit. I’m not saying you should lie or make up stories, but you want to sell yourself and you can bet your butt that your competition isn’t afraid to inflate their credentials. Behavioral Questions Next up is the dreaded set of behavioral questions. The ones meant to tease out your thought process and your ability to be a “team player.” This is the part where our educated “guesses” are going to come in handy. The behavioral section is broken down into two parts that I call Standard Questions and Company Specific Questions. Let’s start with the former. Standard Questions You are going to be asked a variation of one, if not all, of these questions in every single interview you go to: Why do you want to work for us? Tell me about a time you exhibited leadership Tell me about a time where you had to work as a team Tell me about a time you’ve had to work with a difficult person, or difficult people Tell me about a time you failed Tell me about a time you overcame an obstacle Tell me about a time when you had success If you can answer these 6 questions, you can handle 9 out of 10 interviews with no other preparation and be totally fine. Just follow the same set of rules I mentioned above in the Tell Me About Yourself section: Craft a concise story Make sure to include quantitative metrics that illustrate your success Anticipate and address objections Company Specific Questions These are questions that fall in the middle of the 7 listed above and “why are man hole covers round?” Never fear though, we can anticipate these too. Head over to GlassDoor. If you’ve never heard of GlassDoor, it’s a great resource for any job seeker that includes salaries, reviews, and interview information for almost any company in the world. First, you are going to search for the position you’re applying for. In keeping with our theme, we’ll search for “Google” under Companies & Reviews: Next, we’re going to click on the “Interviews” Tab: Then scroll down and click on “Filter Interviews” which will bring up some advanced settings. Here we’ll type in the title of the job we want (Account Manager, in this case) and the location (New York, NY). We’ll also select “Received Offer” because the people who didn’t receive offers tend to be slightly, ahem, biased: This will pull up a list of reviews from everyone who interviewed and received an offer for that position. The general comments are really helpful, but we want to focus on a section called Interview Questions towards the bottom. I usually comb through 10–15 of these and add all of the interview questions into a Word doc so I can answer them later: Now you have your second set of questions to prepare for. What Questions Do You Have For Me? Finally, once they are done peppering you with questions, your interviewer will ask if you have any questions for them. This is the most crucial part of the interview. Why? Because so many people neglect it. If you can ask some questions that are even slightly outside of the box, I’ve found that really sticks with the interviewer more than any other part of the meeting. After every interview I’ve been on, I asked for feedback. Without fail, the interviewer made a positive comment about the questions I asked. The good news for you is that I asked the same exact questions in every single one. Here they are: What is your favorite part about working here? What is the biggest challenge you are facing right now? Let’s say that, in one year, you are looking back on this hire. What has that person done to exceed expectations on every level? Ask about a current event (for example — I saw that [Competitor X] came out with this product. How do you see that affecting your business?) What is the most unexpected lesson you’ve learned while working at [company]? Tell me a little bit more about you, what do you like to do outside of work? These questions work because they are based on specific principles of behavioral psychology. They break down barriers and help build a positive association in your interviewer’s mind. If you’re interested in the details, you can read more about it here. Say Thank You While we’re on the subject, be absolutely sure to send a thank you note to everyone you interviewed with. Also include a personal touch to each one (something that you gained from that last question). Many people I talk to say “but I don’t have their email.” Ask for it! At the end of every interview always, always ask for a business card or write down the person’s email in your notebook. If you forget, try using the techniques I outlined above for finding people’s emails and you should be fine. Part 3 — Following Up & What To Do If They Say No This is one of the most common mistakes I see from job applicants. I understand how nerve wracking it is to sit there and wait while everything is completely out of your hands. One of the toughest things I had to learn throughout my interview process was that, while this is a HUGE deal to you, it’s really just another agenda item on the hiring manager’s schedule. They will get back to you, and if they don’t? You don’t want to work for someone who doesn’t have the courtesy of replying to the people they do business with. When Can I Send Them A Reminder? The rule of thumb is one business week. If you interviewed on a Tuesday, wait until the next Tuesday to email them (as J.T. O'Donnell says, never send a nudge on a Monday). When you do, don’t push or be blunt. Keep it short and sweet: Hi [Interviewer], I hope you had a great week! I wanted to quickly follow up and see if there was anything else I could help with regarding the application process. If so, please let me know. Best, Austin That’s it. If they don’t respond to that after another 3–4 days, you have your answer and it’s time to move on. What Happens If They Say No? Ugh. The worst case scenario. Don’t get down just yet though, we’re not done here. I have this quality where I have trouble taking “no” as an answer. When I was interviewing with Google, the initial screener told me that she wasn’t going to put me through because she “didn’t think I was qualified, and didn’t want to waste the team’s time.” I was not happy. So I sent her this: Hi [Recruiter], Thank you again for carving out the time to speak this afternoon. I really appreciate your feedback, and I wanted to add one final note: I completely understand your concerns regarding my experience with [skill]. You are correct that I didn’t have much experience with that at [previous company]. That said, this doesn’t stem from an inability to produce results, but rather a lack of opportunity to do so. While my experience on paper may not match up to the initial expectations of the position’s description, I have do have two qualities that work in my favor: I am an extremely efficient learner, and am also very effective at translating those learnings into practice. Second, I’m much more tenacious than your average individual. My career has hinged on these two qualities. I left college with no digital experience and a biology degree — all of my digital knowledge was obtained through self study. I spent 8 months selling myself without the on-paper experience to back it up. When I was finally given the opportunity to apply my knowledge in a business setting, I playing a critical role in landing the company’s 2nd largest deal in history. I am confident that I can have the same success in this role. I have the resources necessary to learn what I need in order to be successful at [company], and am prepared to do whatever it takes to make that happen. I understand that [company’s] interview process is extremely challenging, and that only the top talent ends up with an offer letter at the end. I also believe that I am worthy of a shot at that letter. [Company] is known for hiring people who excel at the intangibles, as well the ability to learn new things and apply them to existing knowledge. That is my forte. I am not asking for an offer. I am simply asking for the opportunity to speak with the hiring manager to make my case for the position. I’m sure you will find the best person for the position, I would just like to have a legitimate shot at being that person. If you give me that chance, my next set of answers will not disappoint. Thank you again for your continued consideration. Best, Austin Now that may be a little aggressive… Ok, it was pretty aggressive. But she wrote me back an hour later and pushed me through to the next round! Mission accomplished. The moral of the story here is, don’t give up if you get a “No.” Try to identify why you were turned down and then send a note to hiring manager addressing those items (feel free to copy mine). Taking Action There you have it. The exhaustive, step-by-step guide to landing an interview and then getting an offer from the company of your dreams. What are you waiting for? Get out there and start researching!

For several days not that long ago, Jordan Reid's site, ramshackleglam.com, did not belong to her. She got it back, but only after the involvement of fifty or so employees of six different companies, middle-of-the-night conferences with lawyers, FBI intervention, and what amounted to a massive sting operation. Here's her story.  Written by Jordan Reid: https://twitter.com/ramshackleglam Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2EA3OjL Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:  For several days not so long ago, RamshackleGlam.com — the domain name that I have owned and operated since March of 2010 — did not belong to me, but rather to a man who goes by the name “bahbouh” on an auction website called Flippa, and who was attempting to sell off the site to the highest bidder (with a “Buy It Now” price of $30,000.00). He promised the winner my traffic, my files, and my data, and suggested that I was available “for hire” to continue writing posts (alternatively, he was willing to provide the winner with “high-quality articles” and “SEO advice” to maintain the site’s traffic post-sale). I learned that my site was stolen on a Saturday. Three days later I had it back, but only after the involvement of fifty or so employees of six different companies, middle-of-the-night conferences with lawyers, FBI intervention, and what amounted to a sting operation that probably should have starred Sandra Bullock instead of…well…me. Of course I’ve heard of identity theft, and of cyber hacking, but honestly, my attitude towards these things was very much “it could never happen to me.” And even if it did…I didn’t exactly understand why it was such a huge deal. Couldn’t you just explain to people what had happened, prove who you were, and sort it all out? We live in such a highly documented world, it seemed completely impossible to me that someone could actually get away with pretending to be someone else with any real consequences beyond a few phone calls and some irritation. It’s much, much worse — more threatening, more upsetting, and more difficult (if not impossible) to fix — than I’d ever imagined. I found out about the hacking from my father. His friend Anthony (who runs a web development and consulting company called ThoughtBox) had been surfing around on Flippa and had — in an impossibly lucky coincidence — noticed that my site was up for auction, with what appeared to be a highly suspicious listing. Suddenly, I remembered the email I had gotten the day before — an email that I had disregarded as spam — from someone “interested in the purchase” of my “weblog.” I remembered the notification from YouTube that someone had accessed my account from a different location — a notification I had ignored, assuming that I had logged in on a mobile device or that my husband had accidentally logged into my account instead of his own. But even after I saw the listing, I didn’t panic: this seemed like something that could be fixed with a couple of emails. Except the auction site was located in Australia and didn’t appear to have a phone number, and when I sent an email with a scanned ID and proof of ownership what I got back was a form letter. And when I called HostMonster, the site I pay to operate my website, I discovered that I was no longer the owner of my site: someone had used their email confirmation system to authorize the transfer of my domain name into a private account at GoDaddy (another web registrar service of whom I’m also a client). Why is this a big deal? If you have a business that depends on a URL, you understand why this was such upsetting news: With control over my website’s domain name, a hacker would be able to take the site down, or redirect it elsewhere. Further, it was later verified that the hacker had control over all of the site’s content, as well; he could have just rerouted everything I’ve ever written to any location he wanted. Ramshackle Glam may be “just” a lifestyle blog about things like parenting and fashion and decor…but it’s also a site that I’ve spent five years of my life building, and the idea of it falling into the hands of someone with malicious intent was heartbreaking. I could switch to a new URL and export a copy of my content (which I do back up), but that would result in the loss of a substantial amount of traffic. The website is my primary source of income, and with a house, two children, a book coming out, and a husband in business school, this was not a joke. The loss of my URL had the potential to be devastating for my business and for my family in a very real way. So what did I do? The events of the next few days were complicated, so rather than go through them chronologically I’m going to explain how each path I took ended up panning out (I’m going into detail so that I can be as much help as possible to anyone who goes through this themselves). 1. I tried to resolve the situation directly with GoDaddy and HostMonster. This did not work. From Sunday through Tuesday, I spent most of the day (and much of the night) on the phone with GoDaddy, HostMonster, or both at the same time, and nearly every person I spoke with gave me the same response: “Sorry, can’t help you.” HostMonster maintained that because they no longer controlled the domain name, there was nothing they could do. GoDaddy maintained that because the account was private and the person had obtained ownership of the domain through a transfer from HostMonster, there was nothing they could do. What finally made a difference: I cited ICANN’s policy on Domain Name Dispute Resolution.* This got my case upgraded, but it did not result in action. Here’s why: the legal department at HostMonster informed me that in order for them to initiate a transfer dispute that would result in GoDaddy releasing the domain back to me, their “internal investigation” would have to turn up evidence that they had done something wrong in releasing the site. In other words, they would have to admit that they had screwed up…which would in turn open them up to a lawsuit. Needless to say, I never heard from the legal department again. Despite the fact that everyone seemed clear on the fact that I owned my website and that it had been transferred without my authorization, nothing was going to be done unless I initiated a time-consuming and costly lawsuit that, in any case, would not result in action quick enough to save my domain name from being sold. So that avenue came to an end. 2. I called the FBI. This was a major step in the right direction. The morning after I found out about the unauthorized transfer, I also called the FBI. I felt silly and dramatic making the phone call, but the reality is that this is an international cyber crime issue, and that’s FBI territory. And this is my business. It’s how I support my family, and it may be a “small matter” in the grand scheme of things, but it is not a small matter to me. And let me tell you: of all the surprises I’ve had over the past week or so, most surprising of all has been the FBI. They responded immediately, with follow-up phone calls and emails, an in-person interview with two special agents at my own home within 24 hours, and a follow-up visit from two agents yesterday. Beyond that, each and every agent I have interacted with over the past week has been, without fail, compassionate, thoughtful, invested, respectful, and committed to action…in addition to treating me not like a case number, but like a human. What I expected was to leave a message with a general mailbox and at some point receive a form letter; I certainly did not expect to see an active investigation opened immediately. I’m not going to write more about the investigation because it’s still ongoing (although I did ask for and receive permission to write about this), but I think it’s important to say how absolutely blown away I have been by the FBI’s response. 3. I tried to regain control by dealing directly with the “seller”. This worked, but not without considerable drama. While all of the above was going on, I was also working to regain control over the site directly from the individual who was trying to sell it. I didn’t want to contact the “seller” directly, because I felt that if he thought the “real” owner of the site was aware of the sale, he would try to extort more money. So I asked Anthony — the person who had found the original listing, and who had an active account with a positive history on Flippa — to DM “bahbouh” to see if he was interested in a “private sale”. After some back-and-forth we reached an agreement, and it was decided that a third-party money-transfer website (Escrow.com) would be used to make the sale: the money would only be released to the seller upon confirmation that the domain name had been transferred. This appeared to be going smoothly until Tuesday night, when the seller suddenly demanded that the funds be released immediately (prior to receipt of the website). When we pushed back, he announced that he was selling it to someone else: “Sorry, bye.” So here was my thought process: if we did not release the money to the seller, we were guaranteed to not get the website. If we did release the money to him, there was a possibility that he would take the money and run, and also a possibility that he would deliver the site as promised. It wasn’t a gamble I wanted to take…but I didn’t see any option. And so I authorized the wire transfer. I spent twenty minutes sitting in front of the dummy GoDaddy account I had created to receive the domain name from the seller, waiting to see whether I was out thousands of dollars and a domain name, or just thousands of dollars. And then it came through. I immediately transferred the domain into a different account and placed it (and all of my other domain names) on what amounted to lockdown. And then I called the wire transfer company and placed a stop on the payment. The end result RamshackleGlam.com is back in my possession, thanks to a number of people who dedicated hours (in some cases days) out of their lives to doing whatever they could to help me. My other accounts — bank accounts, et cetera — have been secured. I don’t have my money back yet, but the man who stole my site from me doesn’t have it, either, and won’t be getting it, ever. And that’s an ending I’m pretty damn thrilled with. So why am I still angry? Of course I’m angry with the person or people who stole the site, but that’s out of my hands. The reason I’m writing this post is to let people know that this really can happen — to anyone — and to offer suggestions for how to minimize the chances that it will happen to you (below), but beyond that, I’m writing this post because this incident made me very, very angry at GoDaddy and HostMonster. And I want you to know why. No one at either company questioned my statement (supported by written proof) that the website belonged to me. No one doubted that it had been transferred without my authority. And yet I had to spend days — days during which the hacker could have done virtually anything he wanted — trying to reach one single person who was able to do anything, because the support staff and supervisors I spoke with (who had to have numbered fifty or more) were completely uninformed as to how to handle this situation beyond saying, “Jeez, that sucks. Can’t help you.” And once I reached people who could help me — who could literally make a single phone call or push a single button and return my property to me (or simply freeze it so that it could not be sold or destroyed) — they would not. They hid behind their legal departments and refused to do anything, knowing full well that their inaction would force me to either interact with and pay off a criminal, or lose an essential component of my business. And hackers know that these companies will do this. They rely on it. There is a serious problem when a criminal enterprise not only exists “despite” a company’s policies, but actually thrives as a direct result of that company’s prioritization of their own interests over the security of the clients they allegedly “protect”. Do I understand why companies like HostMonster and GoDaddy are focused on protecting themselves against lawsuits? Of course I do. But the fact is that they not only do not “help” their customers, but actively contribute to creating situations that threaten small businesses and the families that they support. And these companies know that when they stonewall clients whose property has obviously been stolen that these clients will have no other recourse than to pay off criminals or watch their businesses — sometimes their very lives — collapse. They know that by standing in the way of immediate action they create the very environment that these criminals depend upon to perpetuate their business model. And they do nothing. This has to change. My opinion, for what it’s worth Support personnel at hosting companies should be made intimately familiar with ICANN regulations involving domain disputes, and should be able to initiate a plan of action the first time a client makes them aware of a situation, not after hours and hours of repeated calls. Further, the establishment of a TEAC** should result in an immediate freeze on the account in dispute until the situation has been resolved. This should not require an admission of culpability on the part of any parties; simply an acknowledgement that a dispute exists and an awareness that while the dispute exists the domain must be held safe from sale or transfer. What you can do to reduce the chances that this will happen to you: Have a really, really good password, and change it often. Your password should not contain “real” words (and definitely not more than one real word in immediate proximity, like “whitecat” or “angrybird”), and should contain capital letters, numbers and symbols. The best passwords of all look like total nonsense. If possible, use a separate computer (an old one or a cheap one purchased for this purpose) for things like banking; if your family computer is the same one that you use for bank transactions you risk having your kids click on a bad link that results in a hacking. Turn off your computer and personal devices when they’re not in use. Have antivirus software on your computer (but remember that virus scans only catch 30–40% of viruses, so unfortunately a “clean” check doesn’t necessarily mean that you’re safe). Purchase CyberRisk Insurance (learn more about it here; it basically protects businesses from cyber attacks and data breaches. But if it does happen to you, here’s what to do: Begin taking careful notes (and screenshots) immediately. Don’t delete any emails or other information; it could all be important later on. Immediately change all of your passwords (including — but not limited to — domain registrar, website hosting, website login information, email, bank accounts, wireless home electronics, and Apple ID) according to the rules stated below. I changed mine every few hours while this situation was still up in the air, and am continuing to change them every few days for the time being. Contact the registrar(s), citing the ICANN policy below, and see if together you can arrive at a speedy resolution. Don’t be surprised if you find yourself running into dead ends. Make sure to inquire about “filters” and “rules” that may have been placed on your email (basically, any kind of device that the hackers may have placed to forward emails, et cetera). Contact appropriate law enforcement (I contacted the FBI because it appeared to be an international issue, and was at the very least an interstate issue because Escrow.com is located in California, and I’m in New York). Note: Every situation is different, and I can’t wholeheartedly recommend the steps that I took that ultimately resulted in me regaining control over my domain name largely because they involved interacting with criminals. Obviously that isn’t ideal, and can have unpredictable consequences. (Although my husband says that he would like it to be known that he thinks I’m a huge badass. While this is ordinarily very far from the truth, in this specific instance…I’ll take it.) The End. (That was long. Thanks for reading.) *ICann.Org is the Internet Corporation for Assigned Names and Numbers (ICANN) is responsible for managing and coordinating the Domain Name System (DNS). ICANN’s policy on Domain Name Dispute Resolution essentially states that in the case of a domain dispute, the Losing Registrar (the registrar that maintained possession of the domain name pre-transfer, as opposed to the “Winning Registrar”, who maintains possession of the domain name post-transfer). must immediately establish a Transfer Emergency Action Contact (“TEAC“) in an effort to get the ball rolling in the direction of resolution right away). Once I had this information, my case was immediately upgraded. **TEAC: A contact that is established by ICANN and used by other registrars and ICANN if there is a need to quickly address issues with domain transfers between two registrars. The contact must respond to inquiries within four hours, though final resolution may take longer.

Jane wanted to help others with non-traditional backgrounds succeed on take-home coding challenges. So she wrote an extensive guide for anyone who has received such a challenge and wants to attack it in the best possible way. She divulges mistakes to avoid, how to get organized, and how to go above and beyond. Written by Jane Philipps: https://twitter.com/janephilipps Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2t5215F Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: Introduction Hi, I’m Jane. I wrote this guide because I want to help others with non-traditional backgrounds succeed on take-home coding challenges. Please read it, take notes, apply the material, and let me know about your results. You can reach me via email at jane@fullstackinterviewing.com. This guide is intended for anyone who has received a take-home coding challenge as part of the technical interview process and wants to attack it in the best way. This Essential Guide is a distilled version of a longer Ultimate Guide to Take-home Coding Challenges, which goes into much more detail and walks through an example challenge from start to finish. So, if you’ve just received a challenge and are anxious to get started, start here, and then check out the full guide when you want to learn the material more deeply. Good luck! Mistakes to avoid making when working on a take-home coding challenge There are several mistakes you can make with take-home challenges. Some of these are small mistakes that are easily correctable, while others will leave you frustrated and unable to finish your assignment. I want to address these mistakes first, so when you’re given a take-home challenge, you know exactly what not to do. Here are four mistakes you can make: 1. Time management and scope creep 2. Trying to learn too many new things at once 3. Making too many assumptions 4. Starting to code right away Let’s look at each one in detail. 1. Time management and scope creep Time estimation is one of the hardest problems in programming, and even experienced engineers struggle with it. This plays into take-home challenges in a couple of ways. First, some challenges come with “estimated time.” I usually ignore these, as they are rarely based in reality. Second, some challenges are open-ended. Many people, especially newer developers, will want to add tons of features because they think it will be impressive. Actually, it’s more impressive if you keep the scope relatively narrow, but finish everything you set out to do. In this situation, it’s better to do one thing really well than to do a million things poorly. A good question would be: what counts as “going above and beyond” versus what counts as “scope creep?” My rule of thumb would be if your idea accomplishes or improves on the requirements of the assignment, that is likely a good idea, but if it seems tangentially related or “just cool,” it’s probably scope creep. But, as I describe later, always make it work first. 2. Trying to learn too many new things at once While a take-home coding challenge can be an excellent opportunity for learning, it is possible to take on too much learning. If you’re given a challenge where you must use a specific language or framework, but you’re not familiar with it, don’t add additional complexity by setting out to learn something new on top of that. For example, if you are using a new backend framework for a full stack app, stick to a frontend framework that you’re already comfortable with. If your challenge is language/framework agnostic, but you’ve been itching to try out some new technology, pick JUST ONE to experiment with. Between reading the docs, getting your challenge properly set up, and getting used to any new syntax, you will have your hands full. Even learning one thing will eat up a lot of your time, so I would highly suggest limiting yourself to one new piece of technology per challenge. 3. Making too many assumptions As a developer, if you make too many assumptions, you are bound to build an application where the requirements are off, or the user experience is bad. When given a set of requirements for a take-home challenge, ALWAYS take the time to review the requirements and make sure you fully understand them. And, if you have any questions at all, always ask. First, this shows that you are willing to ask for help when you don’t quite understand something, an important trait for a developer to demonstrate. Second, many companies will intentionally give you product requirements that are vague or not fully fleshed out in order to see how you react in these situations. They are actually testing your ability to make sense of requirements that may have gaps in them. So, when in doubt, ask questions. Asking questions is also a signal that you are engaged and interested in the challenge. 4. Starting to code right away One last mistake you can make is to jump in and start coding right away. I guarantee if you do this, you will regret it. Why? Two reasons: Without proper planning, your code will suffer Without first getting organized and making sure you fully understand ALL of the technical requirements, you may find yourself missing edge cases or rewriting parts of the functionality. I know it seems counter-intuitive, but you will actually SAVE yourself time if you plan ahead. You will spin your wheels trying to get your app set up properly Especially for newer developers, initial app setup can be one of the hardest parts of a take-home coding challenge. It’s not something you do every day, so it often takes some research and reading documentation to get reacquainted with the process and ensure you’re going about it in the best way. So, there you have it — a summary of mistakes to avoid making. You’ll find that a lot of these are also applicable to your day to day work as a developer. In the next section, we’ll dive into further detail on how to get organized before you write a single line of code. Get organized: how to plan before you write a line of code Now it’s time to get to work! But, it’s NOT time to write any code YET. Why? Because, as you’ll see, a lot of the work actually happens before you write a single line of code. This may seem counterintuitive, but again — the more time you spend up front planning, the less time you will spend writing code. So, now you have your coding challenge in hand and you are ready to get started with the planning process. Here are my six suggested steps: 1. Understand the requirements and ask any questions 2. Identify technical decisions you need to make 3. Technical design & whiteboarding 4. Test plan 5. App setup plan 6. Organize your tasks 1. Understand the requirements and ask any questions First, you need to make sure you completely, absolutely, 100% understand the requirements of the project. If any part of the requirements are unclear, it is up to you to reach out to your contact and ask questions. Sometimes companies will purposefully make their requirements vague, in order to see how you approach the problem. In these cases, it is always best to ask questions as it shows you are thinking about the problem and not just making assumptions and building an app to a vague spec. 2. Identify technical decisions you need to make Your next step will be to identify the technical decisions that you need to make. Making a list of all of your technical decisions up front and thinking about them before you’re in the middle of building your app will help you immensely. Not only will it cut down on time figuring things out later, but it will allow you to make big picture decisions up front, as opposed to trying to focus on both the big picture and the small details at the same time. 3. Technical design & whiteboarding Now it’s time to plan out the rest of your app. For anything that you need to draw out, now is the perfect time to do that. Thinking through these decisions at the start serves two purposes: You’ll be able to reference these drawings and your original plan while you’re building your app. Then if you get stuck at any point, you can always come back to your notes. Later, when you are having a discussion with an engineer about your coding challenge, you can use these notes as a reference when they ask you why you made certain design or architecture decisions. Once you’ve thought through and answered some of the bigger design and architecture questions for your challenge, the next step is research. If you’re planning to use a new technology or something you’re a bit rusty with, use this time to search for documentation and other resources. 4. Test plan Another very important step to take before writing a line of code is developing a test plan. Although you won’t get peer feedback on this test plan, it will help you look at the challenge from a different angle, making sure you’re meeting all of the requirements. By thinking through and writing out a test plan before you start coding, you are able to brainstorm possible edge cases that you should account for in your code and you will use this as a basis for testing your app later. 5. App setup plan If you’re starting an app from scratch, figure out if there are any generators you can use to make your app setup easier and faster. Application setup is one of the hardest parts of take-home coding challenges, because it’s something that developers do rather infrequently. Best practices are always changing, so it’s easy to forget how to do. Also, when setting up an app with a specific combination of technologies for the first time, it can be challenging to get everything configured and working together properly. If you are not using a generator, reading documentation and finding working examples are the two most important steps you can take. Being able to play with a working example and compare it to your own app will help you if you get stuck. 6. Organize your tasks The last step before you start coding is to break down and organize your tasks. Breaking down your tasks is essential because it will help you stay on track as you’re working on your challenge, and it will give you a game plan for execution. Note that you shouldn’t be a perfectionist here, because there will always be unexpected bumps in the road. Here is an example task list for a classic Tic Tac Toe app: - Understand requirements - Choose technologies - Brainstorm test plan - Hello World app setup - Build board with HTML/CSS - Implement Tic Tac Toe gameplay with Javascript - Add reset button - Make board responsive - Add ability to add additional boards - Error handling & tests - Code cleanup - README Some of these tasks can be broken down even further into smaller steps. For example, in order to implement the Tic Tac Toe gameplay with Javascript, here are some smaller tasks: - Add a click handler to each square that logs a message - Get click handler to add an X to the square that is clicked - Get clicks to alternate between X and O - Don’t allow a square to be clicked more than once - Implement a function to find the winner and end the game - Handle a tie game 3. Writing tests: just do it! Testing can be overwhelming, because there are so many different types of tests: acceptance tests, integration tests, and unit tests, not to mention test driven development vs. ad hoc testing. Why should you include tests in your take-home coding challenge? It’s simple: your tests will make your submission shine. First, adding tests shows that you know or are willing to learn another technology/framework. It also demonstrates that you take ownership of what you’re building, because you are taking responsibility to make sure it works. Testing also shows that you’ve considered edge cases, which many newer engineers often overlook. Many companies take tests very seriously. Some will not tell you that they expect tests for your coding challenge, but will automatically reject you if you leave them out. Therefore, my recommendation is to write tests no matter what when given a take-home challenge. Not only will it make you a better developer, but for companies that were not expecting tests, you will stand out even more! How do you go about writing a tests? First, create a plan. Here’s my 80/20 suggestion for how to come up with the right test cases: 1. Test the happy path For the classic Tic Tac Toe example, the happy path is starting with an empty board and playing a game until X wins. 2. Think about variations on the happy path A variation on the happy path would be if O wins, or if there is a tie game. 3. Think of edge cases An edge case would be if a player tries to play a move in the same square more than once. 4. Test anything that is complex The algorithm to find the winner is the most complex part of this example. Here’s a sample test plan: - Test that the initial state of the board is correct (i.e. board is visible and empty) - Test that a move can be played - Test that moves alternate between X and O - Test that a move can be played to a square only once - Test that a winner can be found in a row - Test that a winner can be found in a column - Test that a winner can be found in a diagonal - Test that a draw can be found So, now it’s your turn. Think about your app and, as a baseline, think of 5–10 tests that you can write. 4. Make it work, then make it pretty, then make it fast The title of this section sums it up pretty well, but when you’re working on building out your challenge, you should follow these 3 steps IN THIS ORDER: 1. Make it work 2. Make it pretty 3. Make it fast 1. Make it work When you’re given a take-home coding challenge, no matter what you do, the most crucial part of the challenge is to make it work. If you submit an app that has a nice UI, that will not matter if your app does not work or meet all of the requirements. Because building features to spec is a key aspect of your future job as a developer, you first and foremost need to focus on the functionality of your app and prioritize that above all else. This is also key if you are low on or run out of time. Coding challenges can be a lot of work, especially if you want to go above and beyond to ensure that you make it to the next interview round. But, I can guarantee that you will not make it to the next round if your app doesn’t function properly or is missing some key components. So, if you’re building a front-end app, this means focusing on making it work first, and styling/UI last. If you are building a back-end or full-stack app, focus on making it work before trying to refactor your code into the most elegant solution, and only then worry about optimization. Even if you end up without any time to go back and refactor your code or style your UI, having a working app to present is more important. You can always talk to the interviewer about how you would improve your app, and refactoring some of your code might even be part of the next round of interviewing. 2. Make it pretty Make it pretty has two interpretations here. One is making the code pretty, and the other is making the UI pretty. Making the code pretty can be done in several ways. First, ensure indentation is consistent and your code is readable. Second, if you got something to work in a quick, hacky way, think about how you can refactor it to be a more elegant solution without overcomplicating it. If you’re doing a front-end or full-stack challenge, you can also make the UI pretty as part of this step. Whether you use a library or write your own custom styles for your app, making the UI look good will show your interviewer that you’re taking the user experience into consideration when building a feature. For some more front-end-focused challenges, you’ll be given a specific mockup to match. In these cases, making sure you’re detail oriented down to the last pixel is incredibly important. Part of your role may involve translating mockups from designers into user interfaces, so companies want to get a sense of how you approach those types of tasks. 3. Make it fast Once you’ve made your app work, made it pretty (in the code, UI, or both), it may be time to make it fast! This is where understanding performance and BigO notation comes in handy. You should take a look at your code and see if there are any areas where increasing the scale might be an issue. For example, are you using a double for loop somewhere? What if the arrays you’re looping over become super long? If you think about these kinds of edge cases, you can then come up with plan to improve your code. Taking something that would have been running O(n) and making it O(1) will show that you’re thinking about performance when you’re building things. How to make your code shine When given a take-home coding challenge, many people think about how to build an app that works, but stop there. In this section, I’ll go over things an engineer reviewing your code will look for, so you can take your challenge to the next level and make your code shine. When an engineer is reviewing your code, they will look for several different things. They will likely try to run your app to play around with it and see it working. After that, they will delve into the actual code, looking to see how you organized your app architecture and reading code in individual files. There are several things you can do to make your code stand out. You want your code to be: Readable Easy to follow Well organized Clean (properly indented, free of syntax errors and unnecessary whitespace) These are the basics that don’t take much effort outside of mindfulness to get right. Now let’s talk about three of the more involved code style considerations: 1. How to name things 2. How to use comments effectively 3. How to format your code as you write it 1. How to name things Naming is one of the hardest problems in programming. One of the keys to naming things is to make sure you’re naming them in a way that another developer who is unfamiliar with the code can easily jump in and understand. For functions, think about what exactly the function is doing. Is the function checking whether there is a winner on a row of a Tic Tac Toe board? Then a great name would be checkRow. Is your function handling a click on a square of the Tic Tac Toe board? Then a great name would be handleClick. One quick tip: if you find yourself losing your flow because you keep stopping to think of the perfect name, split your process into two steps. First, write working code with any names (like foo, bar, and baz). Then take a second pass through to improve them. 2. How to use comments effectively Adding comments can be a great way to capture what you were thinking at the time you wrote a specific piece of code. This can be useful to you, or anyone else who comes across your code in the future and needs to understand it, tweak it, or rewrite it. Think of comments as adding clarity to your code. But, pay attention, because there is such a thing as too many comments. Here is where you most likely do not need comments: When you declare a variable When you declare a function The variable or function name should be enough to explain exactly what it does. If you need a comment to explain it, then you need to give it a better name! Here are some examples of where comments can be useful: HTML CSS Technically tricky lines of code First, let’s talk about HTML. Markup seems pretty self-explanatory, right? So, why would you need comments? Let’s say you have a really long HTML file with A LOT of s. Comments can be a good way to signal which tags close which sections. In CSS, comments are a good way to divide up your styles if you have a lot of styles in one file. This way, when you come back to the code later and want to make a change, it’s easier to find the styles for that one section you need to update. Comments in CSS are also very useful whenever you are hard-coding any math or adding an arbitrary number of pixels as margin, padding, and so on. Comments can be useful to explain things like this that are specific to your application. One of the best uses for comments is when you’ve written code that is technically difficult or just not intuitive. You should always strive for simple, understandable code as much as possible. However, sometimes you will have confusing code — maybe you’ve chained a bunch of methods together or are using a complex regular expression — and it would help to explain what is happening in a comment. You are almost done learning how to make your code shine! Just one more step. 3. How to format your code as you write it I’m a STICKLER about formatting when it comes to code. And, it’s not just me. You’ll find that the best engineers also care about well-formatted, clean code. Why? First, it’s much easier to read! Coding can be really challenging, so when code is easier to read, it makes our jobs as developers that much easier. Also, writing clean code sends a message to your interviewers that you take pride in the craft of writing code, and for many teams, this is a big deal. So, how do you make sure the code style sticklers will approve of your code? There are a few simple tricks you can use as you’re working through your coding challenge to ensure the end result comes out clean and you don’t have to spend time at the end reformatting everything. Choose tabs or spaces and be consistent across your entire application (i.e. no 2 spaces in some files, 4 spaces in others) Indent your code properly as you go so that it stays readable and isn’t all over the place Get rid of trailing whitespace! Whitespace can sometimes wreck havoc, so it’s best to just get rid of it as you write your code. Keep your syntax consistent throughout your entire app. If you’re using a linter, this will be easier, but requires setting one up. If you don’t have time to set one up, pay attention. Don’t use ES5 in some places in your app and ES6 in others. Pick one and stick with it! Remove unnecessary logging and debug statements when you’re done using them! Unless logging is part of your application, you’ll want to remove any temporary statements you were using while building your app. Always leave a newline at the end of every file That’s it! It’s pretty simple, and once you’re in the habit of doing this, not only will your code be easier for you to read, but it will also be easier for others to read and maintain. Many new developers haven’t been exposed to very much code maintenance, but trust me, when you have to clean up code someone else has written, you will be more thankful if it was neatly organized to start. Pay it forward! How to take your challenge to the next level Here are 3 ideas for how you can take your coding challenge to the next level: 1. Bonuses 2. UI/UX design (for front-end or full-stack challenges) 3. Data validation and error handling 1. Bonuses Not all coding challenges come with bonuses, but if yours does and your goal is to get a job offer, do them! Why? It’s pretty simple. If you go above and beyond in your coding challenge, it will show that you will go above and beyond once you’re hired at this company. Completing bonus requirements is a high competence trigger for the interviewer. 2. UI/UX design (for front-end or full-stack challenges) Some front-end or full-stack challenges will mention UI/UX design as a bonus, but if they don’t, putting in some effort to make the UI look nice and be easy to use will go a long way. You can either go the route of adding your own custom CSS or plugging in a library or two to help make your styling even more painless. If you use a library, just make sure that you understand how it works enough to explain how you’ve used it. 3. Data validation and error handling Data validation and error handling are key components in production apps. Adding either one of these (or both!) to your challenge will help make it stand out. Many developers who are new to coding and haven’t worked in a production codebase before don’t have a ton of exposure to either of these, so if you add error handling for edge cases it will show that you thought through a lot of different situations. How to write an awesome README You may be done writing code, but you’re not done writing yet — it’s time to write your README. Why you should include a README READMEs are incredibly important, both for professional developers and for job seekers working on take-home challenges. Including a README shows that you care about documentation. Documentation helps spread knowledge across teams and serves as a supplement to your code. Having documentation for your take-home challenge ensures that anyone else (or future you) can jump into your code with a clear understanding of what you’ve built without any guessing games. Your README is also the KEY to making sure that everyone reviewing your challenge has the most painless experience possible. Finally, your README is a way of proving to your reviewer that you successfully met the requirements of the challenge. How to write your README Writing a great README is not hard, and you will stand out a great deal from the other applicants with one. Here are the five sections I’d recommend you include: 1. Installation instructions 2. Discussion of technologies used 3. A section demonstrating that you met the requirements 4. If there are bonuses, a section demonstrating that you met them 5. For algorithms and data structures, time and space complexity 1. Installation instructions When writing your README, don’t make any assumptions. Write out all of the steps to run your app locally and test them yourself. This includes cloning the repo from Github, running installation commands, and starting up a server. Also, make sure to include versions of software that you are using. This will ensure that the developer reviewing your code has a seamless experience setting up and running your app, and if they do happen to run into any trouble due to versioning, they will have all of the information they need right there in the README. 2. Discussion of technologies used This section is as simple as it sounds — make a list of all of the technologies you used including frameworks and libraries. If you had to find a library for a specific piece of functionality in your take-home challenge, mention it here and include a link to the docs. 3. A section demonstrating that you met the requirements Usually your take-home challenge will come with some sort of requirements spec, so make sure to include a section in your README where you describe the requirements and how you met them. In some cases, you can take the product spec you were given and write a short explanation of how you met each requirement in a list. In other cases, you can simply include a short paragraph explaining how you satisfied the requirements. It’s totally up to you how you do it, just make sure you include it. 4. If there are bonuses, a section demonstrating that you met them Similar to the requirements section above, you’ll want to highlight any bonuses you completed while working on the take-home challenge. If you attempted a bonus, but couldn’t quite get something to work, then the README is also a good place to address that. You can discuss the approach or approaches you tried and what worked or didn’t work. 5. For algorithms and data structures, time and space complexity If you had to write any algorithms or data structures as part of your take-home challenge, it’s helpful to include the space-time complexity of your final algorithm. This can be done in Big O notation. One final word of advice: write your README in markdown so it looks nice! This will demonstrate that you know (or are willing to learn) another language that will come in handy as a full-time developer. Final steps before you hit send Now that you’ve written your README, you’re almost ready to hit send! Before you do that, take the time to double check all of your work using the following checklist: Re-read the take-home challenge instructions to make sure you didn’t miss any requirements Review your app’s code to ensure that it shines Run your app’s automated tests and make sure they are all passing Test your app manually and make sure everything is working properly Test your app installation instructions from your README Start an email draft and copy your README into it for convenience If requested, make sure to attach a zip file of your code Write an email to your contact at the company Your email can be short and sweet — I always like to highlight something I enjoyed about the challenge or something I learned. Here’s an example: Hi , I hope you had a great week! I had fun diving back into React with this challenge. Here is my Github repo and I’ve included my README below. Please let me know if you have any questions. Just so you know, I’m interviewing with a few other companies and I just received an offer yesterday — I need to get back to them next week. Of course, I am excited about the opportunity at , so I’m looking forward to hearing from you! Thanks, Note that you should only mention interviewing with other companies or offer deadlines if either is actually the case. I feel you should be honest and candid about your situation and maintain leverage for a potential future compensation negotiation at the same time. Now, finally, hit send! Conclusion I hope this Essential Guide was helpful and you learned something that you can apply to a take-home challenge or in your day-to-day work. If you have any comments, questions, or other feedback, please don’t hesitate to reach out. You can reach me at jane@fullstackinterviewing.com.  

If you're over the age of 20, you might think you're too old to learn how to code. But 56 year old VM Vaughn's here to tell you that's not true. In this podcast, he shares his epic beat-down of his critical inner self and lays out his path towards an exciting second career. Written by VM Vaughn: https://twitter.com/vmvaughn Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2oJnBY1 Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:  I’m 56 years old and learning to code. Why? Because I love it. And I’ve got a knack for it. That doesn’t mean it’s easy. It’s hard. And that’s OK. I love losing myself in an algorithm challenge. I love squeezing in a few extra minutes testing just one more thing. I love thinking “maybe I’ve got it this time.” And getting to “Yes! It finally works!” But here’s the thing. I’ve never been one for hobbies. I don’t like activities that don’t pay. I can’t keep on doing something simply for the fun of it. What I work on during my off time has to have some economic upside for me. OK, coding pays. It can pay big. So what’s the problem? Well, before I could fully embrace myself as a 56-year-old programming rookie, I had to deal with my Critical Inner Self (let’s call him CIS for short). Learning all this stuff is hard enough without my CIS whispering in my ear the whole time. If I can give my CIS an epic beat-down, then I should be able to handle anyone who appears to work on his behalf. And these agents of CIS often appear out of no where, asking critical questions. CIS: Why are you doing this at your age? Me: What you really mean is how much longer will I live. And do I really have enough time left to make money programming. Let’s break that down. I’m an American. My life expectancy is 78.8 years. So that means I’ve got a better than average chance of living another 22.8 years. That may not seem like a lot when you’re 20, but I’m 56 and dancing in the street over here. (And because I’m 56, I’ve got better odds of making it to 78 than a 20 year old. But that’s beside the point.) Now, let’s say I’m a snail and it takes me 4 years to finish Free Code Camp’s 1-year curriculum to become a fledgling full stack developer. That puts me at 60 years old looking for a job as a junior developer. Let’s say it takes me another 2 years to land a job because of my age, and let’s assume that 70 is the limit for how long an employer wants me hanging around. That’s 8 years to practice my craft. That’s plenty of runway to get pretty good. And because I’ve been around the block and know the grass ain’t always greener on the other side, I’m much more likely to stay with that employer who hired me first. What 20-year-old stays with their first developer job that long? CIS: But who’s going to pay you the kind of money that you already make now? Me: You could ask me that even if I didn’t learn to program. But I know what you’re getting at. Chances are an entry level developer job will pay me less than I’m making now. Well here’s a thought for you. My paycheck is less today than it was five years ago. And that’s with 5 more years of experience. There’s no guarantee that the job I have now will last. And when it doesn’t, I’ll have to find a new job anyway. At my age, I very well may have to accept entry level wages doing something… anything. I’d rather have the skills and portfolio to go for an entry level position that can lead to much greater earnings — or at least the ability to beat the bushes and pick up some freelance work. CIS: But all the big tech companies want to hire young kids right out of college. Me: That’s easy. I don’t want to move to Silicon Valley and I’m not looking to work for a big tech company. You’ve read the same stats as me. By 2020 there will be 1,000,000 more programming jobs than people trained to fill them. Not all of those openings will be at the “big 4” — Google, Facebook, Amazon, or Microsoft. In fact, most programming jobs aren’t even in the technology industry. My first computer job was in a hospital. I didn’t program, but most of the employees in the IT department were programmers. And that was way back in 1982. CIS: Then how are you going to get a job? Me: First things first, I’m going to apply to a lot of jobs, build a network of hiring managers, and make sure I get a lot of interviews. It’s a numbers game and I’m going to play it. All that wonderful stuff I did before the year 2000? Gone from my resume. Once I’m in the door for an interview, it’s not like I’m going to act like someone’s grandfather. I’ll be just another candidate who’s passionate about programming and excited to learn more. And I won’t act like I know more than I do. And most importantly, I’ll be prepared for common coding challenges and whiteboard interview questions. I’m sure I’ll mess up a few interviews. But the good news? There are plenty of companies out there hiring developers. I’ll keep trying. CIS: Programming teams are full of young people. How are you going to fit in? Me: If by “fit in” you mean how do I become one of the bros? In that case, you’re right. I won’t fit in. At my current job, I show up every day knowing that somebody at work has something to teach me. So I listen. I don’t presume to know everything that’s going on in my boss’s day, so I give him a break. And when I mess up, I say so. That’s how I’ve fit in at every job I’ve had over the last 36 years. CIS: You’ve got a decent job. Why not just accept it? You are where you’re going to be, especially at your age. Me: Accept it? Too late. I’ve already re-framed it. Learning to program energizes me. Working toward a second career gives me the boost I need to get through the daily slog of the one I’ve got now. And really? You know where I’m going to be at 60, 70, and (hopefully) beyond? I sure don’t. CIS: How do you know you’re not just wasting time? Me: What you’re really asking is: “What if you don’t get a 9-to-5 paycheck after this?” My answer: “So what?” I can get good enough, in time enough, to program well enough: to build web apps to build an audience…and offer them even more value from my billable services. to grow a web business helping local businesses grow and nurture their own customers. to combine my programming know-how with existing SaaS APIs to offer a productized service to a niche community. To put it another way, I can learn how to build an idea. To put it out there for people to use. To offer value. To make money. With or without a 9-to-5 J.O.B. So that’s why even though I’m 56, I’m learning to code.

This episode is for anyone who wants to effectively orchestrate a development process without becoming the butt of their team’s water-cooler jokes. It's more attainable than you think, because it's all about process. Don't be a Bill Lumbergh - be awesome. Written and read by Jonathan Solórzano-Hamilton: https://twitter.com/jhsolor Original article: https://fcc.im/2GW6xFX Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: Laurence Peter formulated the principle that “managers rise to the level of their incompetence” in 1969. In particular, non-technical leaders have earned a poor reputation with software developers. Office Space depicts the non-technical manager in Bill Lumbergh, pictured above. Dilbert provides the classic “Pointy-Haired Boss.” This article is for anyone who wants to effectively orchestrate a development process without becoming the butt of your team’s water-cooler jokes. I’ll share what I’ve learned over the years managing development and release processes as a manager and software architect at UCLA and Stanford University. The biggest lesson I’ve learned is that the key to sustaining successful software releases is completely non-technical. It’s about process. Some aspects of a development process benefit from technical know-how, but it’s not required. Successfully releasing software into production is much more a question of robust process architecture than design or code alone. For the purpose of this article, we’ll assume you’ve already agreed to start building something. The product approval pipeline is a different process. Today we’re focusing on getting the agreed-upon product from concept to production. What to build Your team needs to assemble a clear roadmap for their code. Architects and manufacturers use blueprints. You should too. Your roadmap should include a set of schematics which each fulfill a different purpose. These schematics differ for individual applications. A user-interface mock-up, application architecture diagram, and business process model are common. More detailed component diagrams such as Unified Modeling Language (UML) diagrams and flow models are often useful as well. Technical expertise lets you use these schematics to critique your team’s architecture and ensure they’re on the right track. Even without technical skill, these schematics will be critical. You can use them to drive productive conversations about product completion. No more will you have to draw a “% complete” out of thin air or best-guess from the development team. You can track the status of each item on the diagram to determine how close the app is to completion. You can also project future velocity based on how quickly the team completed prior components. There is no “right” amount of pre-development documentation, but there is one wrong amount: none. Work out with your team what constitutes an acceptable roadmap before they start coding. The first checkpoint in your development process will be to review this documentation and ensure they’ve met this agreement. What not to build Your team can’t build everything. Nor should they. You need to ensure that your developers have a laser focus on what they actually need to build. Why are you building this app in the first place? Define the key differentiation from existing products. 80% of your team’s time should go toward supporting that differentiation. The schematics you should now have will be helpful here. Does your application include a logging component? A sign-up and login process? There are already excellent free, open-source software (FOSS) frameworks in most languages for these components. Some are available under extremely permissive licenses. Tesla provides a great illustration of this concept. Their first key differentiator was to use a lithium-ion battery to make electric cars competitive with gas. Lithium-ion achieved this by reducing battery weight and increasing range. The first Tesla prototype simply converted a pre-existing electric sports car from lead-acid to lithium batteries. Their first production run was mostly a Lotus Elise roadster (a pre-existing sports car) that had a Tesla battery and motor. The lesson for your team is to use what already exists wherever possible. If you can use or adapt a FOSS package, do it. Even if you need to license for-pay code from somewhere else, it’s almost always worth it. Get all the scaffolding in place quickly so you can test your “lithium-ion battery.” Then you can iterate through and replace whatever will help further differentiate your product without stressing about delaying production-readiness. The second checkpoint of your development process is to review the planned architecture with your team and identify what very limited part they intend to build from scratch. If it sounds like something that already exists, and it’s not the core focus of your product, challenge your team to see why they believe they need to re-do it. Don’t just throw it over the wall Once you have identified what pre-built technologies you’ll use, make sure to review these with your production support group. Database and server administrators will need to plan for installing and supporting any new technologies. This is the third checkpoint in your development process: operations readiness. Keeping the production support team in the loop early is 90% of the secret sauce known as “DevOps.” If you haven’t heard of this, DevOps is the idea that software development and production operations teams should unify under common goals. The proposed benefits include much quicker releases, more reliable code, and more time spent developing due to automation. These are all great boons, but they follow from a strong communication process. Automation follows, not replaces, collaboration. Implementation and Testing Now your team writes the code. Collaborate with your implementation team to devise a process for dividing the work among themselves. There’s no one-size-fits-all approach, and this is where the “soft skills” of leadership dramatically outweigh any technical skill. Some developers will want to hog all the “interesting” work and ignore any drudge work. They may believe that they’re the smartest person in the room and should get their pick of assignments. Others may resist change and only want to do the same kind of work they’ve done before. Lead your team into an equitable distribution of work. Challenge everyone to grow appropriately and to share and collaborate. One more technical aspect of the implementation is that the code must include sufficient automated tests. These are code-defined tests that a test system can execute. If the code’s going to crash, don’t you want these guys’ resumes to be on the line instead of your own? (public domain: US Government photo) Manual “test scripts” where a human interacts with the code to see if it works are insufficient and reflect technical debt. Your technical team should at least include unit tests. Test-driven development is a popular approach for ensuring that critical code is always tested. You can drive a non-technical conversation with your team about their “test coverage” (the portion of the code that is tested). It’s pretty simple: ask them to list their assumptions. Then ask where and how they test these assumptions. The checkpoint at which the code is believed complete by the developers is referred to in my shop as dev-complete. It means the primary development (dev) process is over, but additional code may be written to address issues that come up in the review process. In an agile development process, you will typically divide the implementation process into multiple checkpoints instead of one all-or-nothing deadline. These are typically called iterations. Refer to the roadmap you defined in the first step. Before starting new component(s), ensure that what you’ve already started is at least dev-complete. This provides you with an accurate view of the speed of development and reduces risk. As you complete the iterations, you can push the code to an environment for “acceptance testing.” This involves pilot or test users (or an internal team playing that role) who interact with the partial product. They test to ensure it meets the design expectations and provide feedback on how it could be better. Acceptance testing is not a substitute for the unit testing mentioned earlier. It serves a different purpose. Letting your development team lean on acceptance testing to catch basic functional bugs is a recipe for disaster. Feedback from the acceptance testers can be incorporated into the next iteration. This is another good reason not to bite off a big chunk of the product all at once. You want to leave room to change course once people start playing with the product. Once you’ve accumulated enough tested code to constitute a sufficient product release, you’re ready to begin the release management process. Looking for bugs in all the right places Your developer or team has reached a point where they believe the code is done. Acceptance testers are satisfied with the way the product is working. The next checkpoint in the process is to validate the belief that you have code ready to become a product. Let’s start reviewing the code! You may not be comfortable or have sufficient technical know-how to review the team’s code yourself. That’s ok! You don’t have to. Your process has to. Work with your team to identify a process for code review that works for them. If you have more than one developer, peer code review works great. If you don’t, are there other developers in your organization outside of your team? Work across team boundaries to establish a peer code review program. If there really is only one developer, then sit down with them and have them walk you through the code. Use your schematics as a reference point, and ask them to tell you how the code accomplishes the schematic’s goals. At the conclusion of the code review process, the developer and reviewer(s) should feel comfortable with being held accountable for the code. The code review is also a good time for reviewing two other critical points: documentation and security. I’ve already written about a sustainable documentation architecture — check it out if you’re interested! Security review should be a part of any code review. In general, this involves taking a second look at the code to spot weaknesses where an attacker could exploit it to reveal private data or gain control of the server. It must be done by a technical person. The Open Web Application Security Project (OWASP) publishes a free comprehensive guide to security review. Your developer can do this if they’re the only one on the team, even if they just run an automated security code analysis tool. There are free tools for helping with this process which are linked through the OWASP wiki. Eject, eject, eject! The code has passed the review process. It’s ready to become a product. But that doesn’t mean it’s ready for production. The last checkpoint to clear is deployment readiness. Is your code in a state where it’s easy to deploy to production? This should involve as few manual steps as possible. It also means you need to have a plan for reverting the change in case the code doesn’t work as planned. This is called a “rollback plan.” If you have a separate software operations team, this is where they come back into the picture. They should review the deployment and rollback documentation and let you know if it’s sufficient. If you don’t have these personnel you can perform this step yourself. Make sure that there are clear, simple instructions for deploying the product. There should be very few manual steps, as each manual step introduces a chance for human error. There should be a clear, sufficient plan for returning to the prior state of affairs if the deployment doesn’t succeed. This may be as simple as restoring a backup, or it may involve customer communication or data conversion. Whether the plan is sufficient depends on how thoroughly your team tested the code, and how widely the product is being released. Consider also any risks associated with the product or with this particular release. Once you’ve passed this checkpoint, push that code into production! Post-release Succeed or fail, it’s important to circle back and review how the process went. Did your team accurately estimate the effort required to release a product? Did the testing adequately model the production scenario? Revisit the implementation and testing checkpoints, and review how well the team performed. How is the product running in production? It’s a good idea to visit the operations staff and obtain their feedback. This further creates trust between the development and operations teams, and will lead to more DevOps benefits down the road. Where are the remaining gaps in your product? If they’re in third-party code, now’s the time to consider whether to customize your packages or re-implement from scratch. Otherwise, you now have input on what to build for the next release. Above all, hold yourself and your team accountable for the results of your effort. Accountability facilitates independence and promotes individual growth. As your team grows accustomed to being held accountable for each step in this process, they’ll adjust their performance accordingly. Conclusion You don’t have to be the least bit technical to run a successful software release process. Technical skill can help, but it can also become a crutch. The key to successful software release is a well-documented, well-understood process for moving software through the pipeline from idea to product. You now have a starting point for drafting your own software release process. What’s most important is that you participate with your team in filling in the blanks and creating a repeatable process that works for all of you. It doesn’t have to be perfect for anyone, but it does have to be understood by everyone. You also need to ensure that the velocity of your product through these checkpoints matches the demand for the product. None of these items need to be multi-day show-stoppers. It could be a simple one-page checklist. You need to define a process that fits your environment. As with any process, you should also iterate. Just like with the code, your first, untested draft isn’t likely to be perfect. Tune the process on each run-through and you’ll end up with a smooth, predictable software release path. And remember to brush your hair. You don’t want it looking…pointy.

Given the state of college recruiting today, your chances of interacting with companies on campus are slim - unless your campus is a top school. It’s not fair, and it sucks, but that's the way it is. But does it have to be? Does where you went to school really affect your performance in technical interviews? Turns out: it doesn't. Written by Sam Jordan: sam@interviewing.io Recorded by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2Dg3HJA Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: interviewing.io is a platform where engineers practice technical interviewing anonymously. If things go well, they can unlock the ability to participate in real, but still anonymous, interviews with top companies like Twitch, Lyft and more. Earlier this year, we launched an offering specifically for university students. It was intended to help level the playing field right at the start of people’s careers. The problem Here’s the sad truth: given the state of college recruiting today, if you haven’t attended one of a very few top schools, your chances of interacting with companies on campus are slim. It’s not fair, and it sucks, but university recruiting is still dominated by career fairs. Companies pragmatically choose to visit the same few schools every year. Despite the fact that the career fair is one of the most antiquated, biased forms of recruiting that there is, the format persists. This is likely because there doesn’t seem to be a better way to quickly connect with students at scale. So, despite the increasingly loud conversation about diversity, campus recruiting marches on, and companies keep doing the same thing expecting different results. In a previous blog post, we explained why companies should stop courting students from the same five schools. Regardless of how important you think this idea is (for altruistic reasons, perhaps), you may still be skeptical about the value and practicality of broadening the college recruiting effort. You probably concede that it’s rational to visit top schools, given limited resources. Society is often willing to agree that there are perfectly qualified students coming out of non-top colleges, but they maintain that they’re relatively rare. We’re here to show you, with some nifty data from our university platform, that this is simply not true. To be fair, this isn’t the first time we’ve looked at whether where you went to school matters. In a previous post, we found that taking Udacity and Coursera programming classes mattered way more than where you went to school. And way back in the day, one of our founders figured out that where you went to school didn’t matter at all — but that the number of typos and grammatical errors on your resume did. So, what’s different this time? The big, exciting difference is that these prior analyses were focused mostly on engineers who had been working for at least a few years already. This made it possible to argue that a few years of work experience smoothes out any performance disparity that comes from having attended (or not attended) a top school. In fact, the good people at Google found that while GPA didn’t really matter after a few years of work, it did matter for college students. So, we wanted to face this question head-on and look specifically at college juniors and seniors while they were still in school. Even more pragmatically, we wanted to see if companies limiting their hiring efforts to just top schools were getting higher caliber candidates. Before delving into the numbers, here’s a quick rundown of how our university platform works and what kind of data we collect. The setup For students who want to practice on interviewing.io, the first step is a brief (~15-minute) coding assessment on Qualified to test basic programming competency. Students who pass this assessment (that is, those who are ready to code while another human being breathes down their necks) get to start booking practice interviews. When an interviewer and an interviewee match on our platform, they meet in a collaborative coding environment with voice, text chat, and a whiteboard and jump right into a technical question. Interview questions on the platform tend to fall into the category of what you’d encounter during a phone screen for a back-end software engineering role. Interviewers typically come from top companies like Google, Facebook, Dropbox, Airbnb, and more. After every interview, interviewers rate interviewees in a few different categories, including technical ability. Technical ability gets rated on a scale of 1 to 4, where 1 is “poor” and 4 is “amazing!” On our platform, a score of 3 or above has generally meant that the person was skilled enough to move forward. On our platform, we’re fortunate to have thousands of students from all over the U.S., spanning over 200 universities. We thought this presented a unique opportunity to look at the relationship between school tier and interview performance for both juniors (interns) and seniors (new grads). To study this relationship, we first split schools into the following four tiers, based on rankings from U.S. News & World Report: “Elite” schools (like MIT, Stanford, Carnegie Mellon, UC-Berkeley) Top 15 schools (not including top tier, like University of Wisconsin, Cornell, Columbia) Top 50 schools (not including top 15, like Ohio State University, NYU, Arizona State University) The rest (like Michigan State, Vanderbilt University, Northeastern University, UC-Santa Barbara) Then, we ran some statistical significance testing on interview scores vs. school tier to see if school tier mattered for both interns (college juniors) and new grads (college seniors). Our sample comprised a set of roughly 1,000 students. Does school have anything to do with interview performance? In the graphs below, you can see technical score distributions for interviews with students in each of the four school tiers (see legend). As you recall from above, each interview is scored on a scale of 1 to 4, where 1 is the worst and 4 is the best. What’s pretty startling is that the shape of these distributions, for both juniors and seniors, is remarkably similar. Indeed, statistical significance testing revealed no difference between students of any tier when it came to interview performance. Just to note: of course, this hinges on everyone completing a quick 15-minute coding challenge first, to ensure they’re ready for synchronous technical interviews. We’re excited about this because companies can replicate this step in their process as well! What this means is that top-tier students are achieving the same results as those in “no-name” schools. So the question becomes: if the students are comparable in skill, why are companies spending egregious amounts of money attracting only a subset of them? Okay, so what are companies missing? Besides missing out on great, cheaper-to-acquire future employees, companies are missing out on an opportunity to save time and money. Right now, a ridiculous amount of money is being spent on university recruiting. We’ve previously cited the $18k price tag just for entry to the MIT career fair. In a study done by Lauren Rivera through the Harvard Business Review, she reveals that one firm budgeted nearly 1 million dollars just for social recruiting events on a single campus. The higher price tag of these events also means that it makes even less sense for smaller companies or startups to try and compete with high-profile, high-profit tech giants. Most of the top schools that are being heavily pursued already have enough recruiters vying for their students. Unwittingly, this pursuit seems to run contrary to most companies’ desire for high diversity and long-term sustainable growth. Even when companies do believe that talent is evenly distributed across school tiers, there are still reasons why companies might recruit at top schools. There are other factors that help elevate certain schools in a recruiter’s mind. There are long-standing company-school relationships (for example, the number of alumni who work at the company currently). There are signaling effects, too — companies get Silicon Valley bonus points by saying their eng team is comprised of a bunch of ex-Stanford, ex-MIT ex-and so on students. A quick word about selection bias Since this post appeared on Hacker News, there’s been some loud, legitimate discussion about how the pool of students on interviewing.io may not be representative of the population at large. Indeed we do have a self-selected pool of students who decided to practice interviewing. Certainly, all the blog posts we publish are subject to this (very valid) line of criticism, as is this post in particular. As such, selection bias in our user pool might mean that 1) we’re getting only the worst students from top schools (because, presumably, the best ones don’t need the practice), or 2) we’re getting only the best/most motivated students from non-top schools — or both. Any subset of these results is entirely possible, but there are few reasons why we believe that what we’ve published here might hold truth regardless. First of all, in our experience, regardless of their background or pedigree, everyone is scared of technical interviewing. Case in point: before we started working on interviewing.io, we didn’t really have a product yet. So before investing a lot of time and heartache into this questionable undertaking, we wanted to test the waters to see if interview practice was something engineers really wanted — and more so, who these engineers that wanted practice were. So, we put up a pretty mediocre landing page on Hacker News…and got something like 7,000 signups on the first day. Of these 7,000 signups, roughly 25% were senior (4+ years of experience) engineers from companies like Google and Facebook. Now, this isn’t to say that they’re necessarily the best engineers out there, but it does suggest that the engineers the market seems to value the most still needed our services. Another data point comes from one of our founders. Every year, Aline does a guest lecture on job search preparedness for a technical communication course at MIT. This course is one way to fulfill the computer science major communication requirement, so enrollment tends to span the gamut of computer science students. Before every lecture, she sends out a survey asking students what their biggest pain points are in preparing for their job search. Every year, trepidation about technical interviewing is either at the top of the list of 2nd from the top. And though this doesn’t directly address the issue of whether we’re only getting the “best of the worst or the worst of the best” (and I hope the above has convinced you there’s more to it than that), here’s the distribution of school tiers among our users. I expect it mirrors the kinds of distributions companies see in their student applicant pool as well: So what can companies do? Companies may never stop recruiting at top-tier schools entirely. But they ought to at least include schools outside of that very small circle in the search for future employees. The end result of the data is the same: for good engineers, the school they attended means a lot less than we think. The time and money that companies spend to compete for candidates within the same select few schools would be better spent creating opportunities that include everyone. They could also develop tools to vet students more fairly and efficiently. As you saw above, we used a 15-minute coding assessment to cull our inbound student flow, and just a short challenge leveled the playing field between students from all walks of life. At the very least, we’d recommend employers do the same thing in their process. But, of course, we’d be remiss if we didn’t suggest one other thing. At interviewing.io, we’ve proudly built a platform that grants the best-performing students access to top employers, no matter where they went to school or where they come from. Our university program, in particular, allows us to grant companies the privilege to reach an exponentially larger pool of students, for the same cost of attending one or two career fairs at top target schools. Want diverse, top talent without the chase? Sign up to be an employer on our university platform!

The concept of a legacy usually conveys permanence, value, and greatness. But what about in relation to your code? In this article, Jonathan explains how his team broke up with their legacy codebase, why it was necessary, and how your team can do the same. Written and read by Jonathan Solózano-Hamilton: https://twitter.com/jhsolor Original article: https://fcc.im/2FEuAcR Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:    The concept of legacy conveys permanence, value, and the greatness we bequeath to our children and our successors in the community. People make ludicrously generous donations to charitable causes to establish their legacy. They create eponymous endowments or buildings and strive to protect the name their children will inherit. It’s therefore striking that software developers have gotten their “legacy” so catastrophically wrong. Google “legacy,” and you’ll see the first definition matches what I’ve laid out for you here. It’s a definition that’s persisted since the 14th or 15th century. The second definition provides a shocking contrast: legacy. adjective (computing) “denoting software or hardware that has been superseded but is difficult to replace because of its wide use. Dictionaries around the internet agree with this definition. It applies only to the field of computing. We developers have managed to invert the definition of our own legacy in the historical eye-blink that is computer science. That’s almost impressive! If you’re an experienced developer, you’ve certainly been tasked with supporting at least one legacy system in your career. For the uninitiated, well — buy a lot of caffeinated beverages. I’m about to relate to you the brief story of our toxic relationship with our legacy codebase. I’ll then describe how we broke up with it, and what we’ve changed to avoid falling back into bad relationships with high-maintenance code. The Breakup It took eight months of seven-day weeks and twelve-hour days to complete our last legacy system overhaul. Our predecessors had pushed code into production for years without writing a single line of documentation. In fact, some of it wasn’t even in source control, as we later learned. But that’s another story. I’m sure you’ve seen gems like this before: ... hundreds of line of incomprehensible code // TODO: Fix this bug!!! ... hundreds more lines in the same method, no idea where or what the bug is That is the approximate ratio and quality of the only documentation we had on the project. I wasn’t exposed to direct sunlight again until April, and I’d had enough. It was time for a break-up. The importance of documentation In his book “The Art of Unit Testing,” Roy Osherove defines legacy code as any code that doesn’t have tests. He was an optimist. I more loosely regard as legacy any code which contains more technical debt than the time it took to write. As our organization had, many development teams fall into the trap of instant-legacy code: code that already fits the “legacy code” label at the time of release. In my experience, documentation is the most important aspect of avoiding such legacy code. I have yet to meet a developer who loves the idea of documentation. On the other hand, I also have never met a developer who loves crawling inside the skull of a stranger to reverse-engineer a legacy implementation without any documentation. As they say, breaking up is hard to do. But in this case, I promise it will be worth it. So let’s get started on converting your legacy into something you’ll be proud to bequeath to your successors. Let’s get documenting! Our approach: four layers of documentation We created, and began rigorously following, a four-layer architecture for documentation. We maintain three layers of persistent documentation for the project through its life-cycle. We also communicate through one layer of ephemeral documentation during our release management process. The three persistent layers of documentation correlate to three different velocities in our development process. We include documentation review as part of code review to avoid falling back into bad habits. // The front lines: in-line comments keep maintainers sane The most granular tier of explicit documentation is in the code. We perform complete documentation of all classes and methods, their inputs, expected outputs, and exception pathways. We also document “unusual” code in-line. As a predominantly C# shop we use /// documentation ubiquitously. This decorates class, interface, and method declarations. The /// helper auto-generates XML stubs to document the nuts and bolts of the API. These pop up when your code is being referenced by an external project or DLL (dynamic-link library), provided that you’ve distributed the debugging files. Our IDE (integrated development environment) renders this as tool-tip help wherever a reference appears. This greatly aids developers, who are diving into our code for the first time, when trying to fix a bug or extend it for a new use case. It’s worth researching your language and IDE of choice to learn how to extend it with contextual help for your libraries. If you’re not used to documenting your APIs, I suggest reading these articles to get started. We also include regular // comments beyond API documentation. We add these wherever the code is counter-intuitive, or if we’ve found a particularly elegant solution to a problem. We also use these to create “to-do’s” for later refactor when putting in a quick-and-dirty fix. These are invaluable to whoever has to come along and revert the change or fix the code. Because it’s in-line with the source code, this documentation changes at the highest velocity — right along with the code it supports. README: making implementation a breeze We use README files as an implementer’s guide. This documentation is for whoever will be consuming our libraries. It serves a secondary purpose as tactical-level documentation of the particulars of the implementation. We use GitHub for source control, so we place readme.md (Markdown) files in each folder in our GitHub repository. GitHub very nicely renders Markdown files and automatically shows the rendered readme.md files in each folder. This results in a much more usable help file than a simple .txt document. Storing this documentation in the code-base helps developers maintain the documentation. Anyone making a code change can easily open the .MD file in their source code editor or an online markdown editor, and immediately update the documentation. Thus the source-controlled Markdown files live next to, but not within, the code they support. It’s also somewhat more “zoomed out” than inline comments. These two factors result in a lower velocity of updates on this documentation. Because you can still include it in the same commits it changes with higher velocity than offline documentation. The final advantage of this format is that anyone who downloads the source code has immediate access to the implementation guides. Coupled with the inline documentation, this provides both maintainers and consumers with sufficient documentation. They can develop a basic understanding of the project without jumping into another system, such as a wiki. Wiki: where business meets development We use the wiki-level documentation to marry the implementation to the business requirements. This documentation consists primarily of requirements, enterprise architecture diagrams and considerations, and tactical diagrams such as unified modeling language (UML) flow charts and class diagrams. We also use pages (on the same wiki) as meeting minutes, and to record decisions. We use a wiki which has versioning so that we can see a complete history of how requirements and designs have changed over time. We thereby ensure a complete history of the requirements process and how it relates to the changing architecture. Incidentally, GitHub also provides a wiki feature, but we use a third-party wiki which integrates with our project management software. Release management: commit and pull request comments Our release management process includes code review. Our code review includes documentation review. As GitHub is our source control platform, we bake code review into our pull requests. The platform supports commenting upon check-in, inline comment threads on portions of commits, and a conversation thread on the pull request. The key to using these communication channels successfully is to ensure that all discussions result in a tangible output. Either clarify the code itself, or extend the permanent documentation in response to questions. If the reviewer doesn’t understand the code as it is written, future developers won’t either. Rewrite the code to be more self-explanatory, or extend the in-line or readme documentation. It’s not sufficient to end the conversation by replying to the thread: we treat this documentation as ephemeral, and on a long-lived code-base it’s a pain to review the full commit history. Bonus round: self-documenting code Finally, one quick plug for so-called “self-documenting code.” I’m a firm believer that the code should be self-explanatory at the surface. Explicit documentation should provide context or improve maintainability. There are already good articles about this (here’s one), so I won’t go into detail here. Final thoughts I hope that you learn from our experience. Our four-layer documentation architecture may not work for you, but it’s important to figure out what will. The big take-aways? First, it’s necessary to develop a healthy understanding of yourself and your own needs before you entangle yourself with a new code base. Second, it’s easier to stay out of a bad relationship with legacy code than to extract yourself once you’re already committed. And third, you only leave one legacy. But every commit you make contributes to it. They won’t all be good, they won’t all be bad, but they should at least be clear. Please think about what you’re leaving for those who come after you. Together we can reclaim our legacy as developers.

Many people have a vague or incorrect idea of what the fairly common term "API" means. Heads up: it's not a type of beer! Petr lays out the basic details of an application programming interface in plain English so you'll never be confused again. Written by Petr Gazarov: https://twitter.com/PetrGazarov Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2FHPHer Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:  Before I learned software development, API sounded like a kind of beer. Today I use the term so often that I have in fact recently tried to order an API at a bar. The bartender’s response was to throw a 404: resource not found. I meet lots of people, both working in tech and elsewhere, who have a rather vague or incorrect idea about what this fairly common term means. Technically, API stands for Application Programming Interface. At some point or another, most large companies have built APIs for their customers, or for internal use. But how do you explain API in plain English? And is there a broader meaning than the one used in development and business? First, let’s pull back and look at how the web itself works. WWW and remote servers When I think about the Web, I imagine a large network of connected servers. Every page on the internet is stored somewhere on a remote server. A remote server is not so mystical after all — it’s just a part of a remotely located computer that is optimized to process requests. To put things in perspective, you can spin up a server on your laptop capable of serving an entire website to the Web (in fact, a local server is what engineers use to develop websites before releasing them to the public). When you type www.facebook.com into your browser, a request goes out to Facebook’s remote server. Once your browser receives the response, it interprets the code and displays the page. To the browser, also known as the client, Facebook’s server is an API. This means that every time you visit a page on the Web, you interact with some remote server’s API. An API isn’t the same as the remote server — rather it is the part of the server that receives requests and sends responses. APIs as a way to serve your customers You’ve probably heard of companies packaging APIs as products. For example, Weather Underground sells access to its weather data API. Example scenario: Your small business’s website has a form used to sign clients up for appointments. You want to give your clients the ability to automatically create a Google calendar event with the details for that appointment. API use: The idea is to have your website’s server talk directly to Google’s server with a request to create an event with the given details. Your server would then receive Google’s response, process it, and send back relevant information to the browser, such as a confirmation message to the user. Alternatively, your browser can often send an API request directly to Google’s server bypassing your server. How is this Google Calendar’s API different from the API of any other remote server out there? In technical terms, the difference is the format of the request and the response. To render the whole web page, your browser expects a response in HTML, which contains presentational code, while Google Calendar’s API call would just return the data — likely in a format like JSON. If your website’s server is making the API request, then your website’s server is the client (similar to your browser being the client when you use it to navigate to a website). From your users perspective, APIs allow them to complete the action without leaving your website. Most modern websites consume at least some third-party APIs. Many problems already have a third-party solution, be it in the form of a library or service. It’s often just easier and more reliable to use an existing solution. It’s not uncommon for development teams to break up their application into multiple servers that talk to each other via APIs. The servers that perform helper functions for the main application server are commonly referred to as microservices. To summarize, when a company offers an API to their customers, it just means that they’ve built a set of dedicated URLs that return pure data responses — meaning the responses won’t contain the kind of presentational overhead that you would expect in a graphical user interface like a website. Can you make these requests with your browser? Often, yes. Since the actual HTTP transmission happens in text, your browser will always do the best it can to display the response. For example, you can access GitHub’s API directly with your browser without even needing an access token. Here’s the JSON response you get when you visit a GitHub user’s API route in your browser (https://api.github.com/users/petrgazarov). The browser seems to have done just fine displaying a JSON response. A JSON response like this is ready for use in your code. It‘s easy to extract data from this text. Then you can do whatever you want with the data. A is for “Application” To close off, let’s throw in a couple more examples of APIs. “Application” can refer to many things. Here are some of them in the context of API: A piece of software with a distinct function. The whole server, the whole app, or just a small part of an app. Basically any piece of software that can be distinctively separated from its environment, can be an “A” in API, and will probably also have some sort of API. Let’s say you’re using a third-party library in your code. Once incorporated into your code, a library becomes part of your overall app. Being a distinct piece of software, the library would likely have an API which allows it to interact with the rest of your code. Here’s another example: In Object Oriented Design, code is organized into objects. Your application may have hundreds of objects defined that can interact with one another. Each object has an API — a set of public methods and properties that it uses to interact with other objects in your application. An object may also have inner logic that is private, meaning that it’s hidden from the outside scope (and not an API). From what we have covered, I hope you take away the broader meaning of API as well as the more common uses of the term today.  

Nishant Shukla is the author of Machine Learning in TensorFlow, and is also the VP of Engineering at a startup focussing on Artificial Intelligence technologies for education. In this episode, he discusses the basics of machine learning. Learn more about his book at http://tensorflowbook.com/   Interviewer: Beau Carnes - https://twitter.com/CarnesBeau Interviewee: Nishant Shukla - https://twitter.com/binroot   Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02  

Changing careers is very difficult. Add in a full-time job and a couple of kids, and the task seems nearly impossible. But even if you're busy, you can make the time to build the skills to level up your career. Here's how Michael Tombor did just that. Written and read by Michael Tombor: https://twitter.com/michaeltombor Original article: https://fcc.im/2BK2vkm Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:  “Instead of saying “I don’t have time” try saying “It’s not a priority,” and see how that feels.” — Laura Vanderkam Changing careers is very difficult. Add in a full-time job and a couple of kids and the task seems nearly impossible. Yet, even if you are busy, you can prioritize and make the time to focus on what matters to you and build the skills to level up your career. Engineer your future with code I started my coding journey just six months ago. Now I am one project away from completing my front-end developer certificate on freeCodeCamp. I’ve also completed the web developer boot camp course by Colt Steele on Udemy. And I did this all while raising two kids and working in a full-time job. When I began using these tips, I saw my progress increase tenfold. I know I would have accomplished much more if I had implemented them earlier in my journey. I have not only benefited from increased productivity, but I feel more balanced and am having more fun than ever before. My pivot into web development After being in health care for the last five years, I realized that it wasn’t what I wanted to do for the rest of my life. Don’t get me wrong - I loved helping people on their path to health, but I hated seeing the system break down for them. I hated when people could not afford their medication, or when their care plan wasn’t in sync with the treatment they needed. I wanted to do more to help these people. But I knew that I couldn’t do more unless I took a step back and looked at the bigger picture. I was not always interested in coding, but the more I looked at the forces making real change in today’s world, the more I saw that tech was behind these advances. I saw an opportunity to make meaningful change, and that is when I became interested in coding. Why are you coding? Whatever the reason is, really think about it and pin it down. Use it as motivation to propel you towards your coding goals. Having this end goal will help you bust through plateaus and push through the hard parts (coding is hard). Every day that I spend at my current day job motivates me to get home, boot up my laptop, and continue my journey of learning how to code. The good news is that building coding skills is simple. All you have to do is code a lot. But unfortunately, this is where the hard part comes in. Fitting time into your busy life to routinely code is difficult, to say the least. How to climb the coding mountain There is a gap between where you are now and where you want to be. That is why you are reading this article. That is why you work day in and out, and end up sacrificing time with your family and loved ones. If we are spending all this time working towards our goal, it is paramount to make the most of the time we spend learning how to code. Here are five steps to turn this dream into a reality: Create your personalized goals To make the most of your time, nothing is more important than making actionable short-term goals. This will not only help you feel a sense of accomplishment every time you meet a goal, but it will help make the coding journey feel a lot less daunting. Goals Exercise! To help you come up with focused goals, I want to encourage you to do a quick exercise that I picked up from Laura Vanderkam. 1. Picture yourself one year from now. You have crushed ALL your coding goals and landed your dream job. You have given five talks at conferences around the world, and you built up your App and it was successful. Whatever success looks like to you, picture your future self. Please be ambitious, maybe even dream a little. 2. What 3 - 5 goals did you accomplish in that year that made it so successful? 3. Write these goals down. 4. Repeat this exercise for your personal life goals. It is impossible to work all the time, and to be successful you need work life balance (or you will burn out). Now you have 6 - 10 ambitious goals that you want to accomplish during the next year. To break these larger goals down into action items, think about and plan about how you can meet these goals. For example, if you want to complete the freeCodeCamp front end certificate, you need to schedule time to work on it throughout the week. If you want to run a marathon, you need to buy running shoes, sign up for a marathon, and schedule time to train regularly. 2. Make a Schedule I’ll be honest - I am definitely not the scheduling type. I thought that I could wing it day by day. But realistically, you need to set time aside to focus, or your goals will pour over into the rest of your life. I found myself feeling anxious about coding during time with my family or when I was putting my kids to bed, because I hadn’t coded yet that day. The thing I looked forward to all day (coding) started to negatively impact my quality of life. Splitting your time into focused blocks allows you to be 100% in the present moment. When it is coding time, you can have tunnel vision and hack away. When it is time to unwind, or hang out with people you care about, you can be present because you coded that morning, or have time scheduled later in the day. I schedule a lot of family time. Family is really important to me. Your schedule will look a lot different, but the point is to create a schedule that will allow you to meet your goals without you hating life along the way. Just try to account for everything, so you can stick to your schedule. 3. Audit yourself to find time opportunities Write down all the activities in a given day or week and see what you really do with your time. You will likely be surprised by exactly how much time you spend mindlessly scrolling through your Instagram feed, or binge watching a new Netflix show (I love Stranger Things). I’m not telling you to cut all of it out but keep a balance. You can definitely turn some of that idle time into some serious coding gains. There is more time than you think If you are still thinking to yourself, “yeah, but I still work a lot and (insert excuse here) so I can’t find time”, then here is a fun fact! There are 168 hours in a week. If you work a full 40 hour week and subtract 8 hours of sleep per night (which I definitely don’t get) you still end up with 72 hours of “free” time. Look at all the time you have in your life situation and squeeze as much “good” stuff into that time as you can. There IS time. 4. Fill your time with quality Here are some tools that I use to help me accomplish my coding goals and stay focused on my learning path: freeCodeCamp Seriously one of the best tools for meeting goals. The curriculum is right there for you to follow and work on, it even tracks your progress! JavaScript 30 30 JavaScript projects really help you master array methods while filling up your portfolio with projects (plus it is tons of fun). Wes Bos is a solid instructor who provides a quality free course. You can complete it in 30 consecutive days, or work it into your learning schedule. 100 Days of code on Twitter This 100 day challenge consists of coding every day and tweeting about what you did. It is a great tool for tracking progress and measuring how far you have come. This community is full of inspiring people from all over the world and is a great way to meet like minded developers. The Web Developer Boot Camp I am almost finished with this course, and it has patched a lot of holes in my coding knowledge. Colt doesn’t just show you how to do something, he also explains why you do it a certain way. Plus, there is now an advanced web developer boot camp that I am going to take once I’m done. Live It! This isn’t a resource, but you should embrace the tech community by living it. Listen to podcasts while you drive to work or do the dishes. Follow leaders in the industry on Twitter. Read articles. Immerse yourself in tech and you will learn without realizing you are learning. 5. Multiply your time We have set goals, and now have several larger goals broken down into actionable goals. We have gone through how to fit these goals into your busy life and I have helped give you some ideas on how to fill your time. Now, I want to tell you how you can make the most out of the time you put into coding. The Answer: Be Happy! What does being happy have to do with managing time, you ask? Simply put: it is everything. The idea is called multiplying your time. Being present and deeply focused leads to increased productivity. This in turn multiplies the time you spend by increasing efficiency. Plus, who doesn’t want to be happy? According to Shawn Achor, who studied the effects of happiness and its link to productivity, your brain performs 31% more productively when you feel happy. Dopamine, which floods into your system when you feel positive, does two things: It makes you happier (duh!) It turns on the learning centers in your brain. They help you learn things more easily, and allow you to spend less time on learning while retaining more information. Turn your brain into a dopamine producing machine! You can release more dopamine by creating lasting, positive change. There are five things you can work into your routine to turn your brain into a dopamine producing machine: 1. Write three new things that you’re grateful for each day. This creates the habit of scanning the world for positive things, instead of negative ones. 2. Journal about a positive experience you had in the last 24 hours. This allows you to relive the positive experience which leads to the same dopamine response. 3. Exercise. Go on a short walk before a coding session, or bust out a quick workout. Exercise releases tons of dopamine. 4. Meditate. Meditation trains your brain to focus more on the task at hand, all while releasing dopamine. 5. Random acts of kindness. Thank someone in your social support network for helping you, or help someone out. This not only releases dopamine for you, it also does the same for the person you helped (and they may pay it forward). Use blocks of time to build your future Even if we are busy, we must take out time for the things that matter the most. When you focus on what matters, you can build the life you want with the blocks of time you have.  

It’s true. John spent thousands of hours reading books, writing code, and watching computer science lectures, all to prepare for his dream job interview at Google. When things didn't go his way, he shifted gears. Here's his story. Written by John Washam: https://twitter.com/startupnextdoor Read by Quincy Larson: https://twitter.com/ossia Original article: https://fcc.im/2ERJpuC Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:  It’s true. I’ve spent thousands of hours reading books, writing code, and watching computer science lectures, all to prepare for the Google software engineer interview. How I Got Here I started programming in middle school, but when it came time for college I pursued a degree in Economics. My rationale was that there would be too many programmers looking for jobs by the time I graduated. Boy, I was wrong. Later, I joined the Army to become a programmer, but the recruiter talked me into a military intelligence position, and I spent the next two years studying the Korean language. I served in South Korea for 2 years afterward. Before I left the Army, I attempted to get back into programming and was surprised at the difficulty. I had learned BASIC in middle school and kept programming it through high school. But I restarted my programming studies with C++, and the leap was too large. I just couldn’t grasp it. I did enjoy making websites, however, but I used software with a Word-like interface that I used to publish my websites. I didn’t know how to make websites from scratch. After the Army, I decided to stay in Korea for a year and teach English. I used my nights and weekends to study web programming, using Perl, HTML, CSS (which was new at the time), JavaScript, and SQL. After a year of intense study, I landed a job in the Seattle area, and I’ve been here ever since. I’ve been a web developer now for 15 years. I’ve started 3 companies, 2 of which are still running and generating revenue. I’ve worked at large and small companies, helped startups launch and grow, and recruited and managed teams. I’ve been a product manager, a CEO, a designer, and a marketer. I’ve had a successful career and learned a lot along the way. But I’m not done yet. Seeking a Career Change Remember the part where I didn’t get a computer science degree? It has made a difference. A few years ago, I thought I could get hired anywhere. I thought I was hot stuff: the elusive full-stack web developer. But during my job search in 2013, I realized my skills were lacking. I had spent so much time chasing dollars by running startups in my spare time, that I had let my skills atrophy. I hadn’t kept up with technology. For years, I had learned just enough to get by. I had a wide skill set but wasn’t an expert in anything. Don’t get me wrong, I could still get hired, but not in the technologies or areas I wanted to work in. I could get hired for areas where the tech stack was somewhat outdated, like me. There’s big money in there, but I didn’t see exciting prospects. The realization reached its peak last year at a career fair. I was interested in perhaps working for one of the local companies that were startup labs run by venture capital firms. However, the fact that I lacked a computer science degree, and the skills and knowledge that accompany such a degree, meant I didn’t have a chance. I was working full-time on my businesses at the time, and still am today. At the beginning of 2016, I decided it was time to make a career change from web developer to software engineer. I would need to study hard and practice in order to compress a computer science degree into a few months, but once I did, I could start a new career. You may not see web development and software engineering as different positions. Both involve programming and craftsmanship, but software engineering adds to it knowledge of data structures and algorithms, compiled languages, memory considerations, and understanding the impact of coding and architecture decisions on the machines where they reside. Large companies that hire for software engineering positions expect candidates to have this knowledge. I reached out to an acquaintance who works at Google and asked him questions about his experience at the company. I had been reading How Google Works and was pretty familiar with Google already. Through another contact, I received a copy of Google’s coaching notes that are provided to interview candidates. This became the basis of my study plan. Google is a pretty awesome place to work, but before I even knew that, Google was my goal. Why Google? Google sets a very high bar for hiring. They want to hire only the best. So if I set my sights high (getting hired at Google), I’ll still be quite hireable elsewhere even if I’m not selected. The more I learn about Google, the more I want to work there. In brief, Google is a company that hires smart, creative people, and treats them well. Google rewards merit, encourages big ideas, and gives employees the freedom to make good decisions for the user. The hiring process is calibrated to bring in smart, passionate people. Google has honed the recruitment and interview process over the years. The brain teaser questions are long gone. Nowadays candidates are chosen based on coding ability, technical knowledge, and Googleyness. There’s a lot going on in that one word. Management is different. Managers don’t micro-manage. They trust engineers to make the right decisions. Trusting employees changes the role of managers at Google from what most folks envision when they think of management. In addition, managers can’t unilaterally, hire, fire, or promote. Many of the important management decisions that could be perceived as office politics are handled by a committee to remove that danger. Google’s people operations (HR) has learned what works over time, and they use data and employee feedback to improve evaluation systems, the hiring process, promotions, compensation, benefits, and more. Read Work Rules! by Laszlo Bock (SVP, People Operations) for more. Yes, the benefits are amazing. I went on a tour of the Google office in Kirkland, WA, and it surpassed my expectations. And my expectations were already high. Google Interview University Remember the coaching notes I received telling me what to study? The list of topics seemed manageable, even though I didn’t know anything on the list. I turned the topics on the notes into an outline and started filling in the topics with YouTube videos of lectures from MIT and UC Berkeley. A video on linked lists in one place, a video about queues in another. The list started to grow. I published the list on Github because my Github account was pretty empty. Since all the code I wrote for my businesses and work was private, my Github account made it look like I didn’t code at all. I needed to build up a portfolio. I originally called the project “Project 9894”. Google launched on Sept 4, 1998. Hence the name. I later renamed it to “Google Interview University”. Over time I added some optional topics that I discovered along the way. I was pretty amazed I had gotten so far in my career without even knowing how a CPU processed a program, how memory worked, or any of it. I had known “just enough” to be a success. My little Github project started getting a few stars, and I published a blog post celebrating 20 stars. One morning, I awoke to find it had grown to 120 stars. Someone famous had tweeted about it during the night, and that led to it ending up on the Github daily trending report. I was #1 trending on Github for a few days. Many kind people reached out to thank and encourage me. It turns out there are thousands of people who want to not only work at Google but want to work as a software engineer, and this list was just the to-do list they needed. It’s now at over 21,000 stars. I still can’t believe it. What If I Don’t Get the Job? It won’t be the end of the world. I’ve put the time and dedication into my studies for the goal of getting hired as a Google software engineer, but even if I fail, I’ll still be armed with the skills and knowledge required to work as a software engineer at any company. Wherever I end up, I’m going in as an entry-level software engineer. I’m not going in with 15 years of software engineering experience because I simply don’t have it. When it comes to this stuff, I’m the equivalent of a fresh CS grad. But I have the enthusiasm of a new grad, too. This is a new world for me. I’m just getting started. I’m not afraid to make mistakes. I know I will. I also want to learn everything I can and be an excellent addition to any team. Don’t Study As Much As I Did Yes, I took 8 months. But I could have abbreviated the process. Like any startup with a big goal, you make mistakes and do things that waste time. There are many things I wish I go back and do differently. I studied topics I didn’t need to, some because I thought I would need them for the interview, and some because I wanted to have the knowledge on hand for when I started working. I didn’t want to be a burden on the team I’m assigned to. It turns out I simply over-prepared. I spent 3 weeks reading a 1,000-page book on C++. I don’t remember 1,000 pages worth, but I know a good bit about C++ now. As it turns out, I’m using Python for the interview, not C++. I had assumed I needed C++, C, or Java, but I was wrong. It’s good to ask, not assume. I read way more books than I needed to. There are only 3 or 4 books I should have read. I have a code catalog of dozens of algorithms that I review, most of which I wouldn’t expect in an interview. You don’t need to do that. I watched many hours of YouTube videos but could have watched far less, and spread out topics over time. I should have stopped reading books and watching videos earlier and started on coding problems sooner. I would have been able to spend more time applying the topics I learned. Spaced repetition is the key to memorization. Once you learn something, review it again later, and again even later. At each repetition, you reinforce your learning. Spending hours and hours at one time on priority queues won’t make you an expert. You become an expert by revisiting and reviewing over time. If you do so, you’ll get to the point where can’t forget details. To help review, I made 1,792 flashcards (digital flashcards). This is way too many. I review them on my phone or tablet whenever I get a spare moment (such as during Christmas shopping). Flash cards and spaced repetition go hand-in-hand. Once I get an answer on a flashcard right, I don’t mark it as known. I keep it in the deck and once I’ve seen it and answered it correctly many times, then I mark it as known. My sense of fear (“What if they ask me a question about red-black trees?”) led me to study far more topics than I needed to. But I didn’t want to just prepare for the interview, I wanted to prepare for a career at Google, solving large-scale problems. That means knowing algorithms that will save computing resources of time, space, and I/O. I may never need to know a maximum flow algorithm (Ford-Fulkerson), but it’s nice to know I have that tool available if the situation arises (without memorizing the implementation), and can recognize its application to a problem space. Conclusion Early on, I wished I could skip all this learning, and just hurry up and get hired so I could instead spend my time learning the languages and tools for the team I join. But along the way, I realized how important this knowledge is, and even though most of it may not be applicable on a daily basis, I’m glad I put in the effort. I have a new appreciation of the history of computing, the greats in the field, data structures and algorithms (and how they complement each other), and how computer systems work at low-level. I’ll be putting in my application soon. It’s been a long journey getting to this point — almost an entire year. It began back in January, but I wasn’t able to commit to full-time study until April. I’m about as prepared as I can be. I can’t keep studying and putting off the application forever. At some point, I have to take the leap. I see a bright future ahead. First of all, thank you to everyone who cheered me on and supported me with your kind words over the last few months. I appreciate all of you so much. Your encouragement helped me get back to the whiteboard every day and practice. Why didn’t I get hired? I don’t know why. Last week I received a rejection email from the recruiter, and at first, I thought it was a mistake, and laughed it off. I checked in with my referral and he inquired into it and lobbied on my behalf, but in the end, it didn’t change the situation. The thing that bothers me is that I didn’t even get a phone screen. I didn’t even talk to a recruiter over the phone. After all this work and enthusiasm, I didn’t even get a chance to prove myself. I’ve done a lot of speculation about the reason why, but I won’t do that here. It’s all just guessing, which accomplishes nothing. But I still like Google. However, I don’t know if I’ll apply again in the future. I want to get hired and stay at a company for a long time. I don’t want to hop around. The company that ends up hiring me will get a loyal, hardworking, enthusiastic employee. There are a lot of places where I can strive for greatness and have that effort rewarded. Respect your Recruiter Recruiters look at hundreds of resumes every day, and they are highly tuned to detecting quality candidates and rejecting those who don’t match up with their model. For some reason, I just didn’t fit the profile. They probably are doing me a favor. It’s possible that I would have been in over my head and continually dragged my team down. Google is known for having false negatives in their selection process, but if you’re good enough for Google, you’ll eventually get in. Recruiters know what works, and what doesn’t. So respect their decision and be polite. I’ll bet they deal with irate rejected candidates on a daily basis, so don’t be like that. Just get more experience and knowledge and try again later. As you may know, the last 11 months have been very difficult for me. As a self-taught web developer of 15 years, my computer science study plan took me months to get through, and the main motivator was to start a new career as a software engineer, tackling large problems at a large tech company. Google was the company I had audaciously set my sights on, but in the end that turned into disappointment. If you haven’t read about my story, you’re missing out. Go ahead and read it first. Well, I reached out to my network, and made a lot of new friends. I got connected with every tech giant in the Pacific northwest. Of all of them, Amazon had always stood out — even more than Google — as the most innovative company over the last 10 years. I applied via a referral, whom I had met at a startup event in 2013, and got the process rolling. After so many months of non-stop effort, sacrifice, and worry, I’m pleased to announce that I finally made it! Today I accepted an offer to be a Software Development Engineer at Amazon.com.

In this episode, Alex, a Romanian developer, tells the tale of how he and his friends grew their small side project into a $17,000 a month business. In the beginning, they were coding in a Starbucks. Now their team has grown, they've sponsored 20 hackathons around the world, and business is booming. Here's their story. Written by Alexandru Paduraru: http://twitter.com/axelut Read by Quincy Larson: https://twitter.com/ossia Original article: https://fcc.im/2F5yfQX Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:  In 2014, my friends and I set out to build the best possible web design tools. We built UI kits, Admin Dashboards, Templates, and Plugins. We’ve always tried to create products that are helpful in the development process, and that we ourselves would use for building websites for clients. From a revenue’s perspective, if we don’t take into consideration the Black Friday sales (which doubled the amount that we made in November 2016), we are grossing around $22,000 per month. Part of that goes toward paying our affiliates’ commissions, collected VAT, payment vendors’ taxes, and other expenses. We end up netting around $17,000 each month. In this case study, I’ll share exactly how we built our products and grew our business. You’ll hear all about: What motivated us to start our startup, Creative Tim, and how we built our initial product How we got our first users Marketing strategies we used to grow How our business model works The story behind our revenue sources Biggest lessons we’ve learned so far 1. What motivated us to get started with Creative Tim and how we built the initial product We started out as a two-person agency in Romania with no funding from third parties. We didn’t have enough cash to rent an office — even desks at a co-working space —so we just worked out of a Starbucks. We were barely able to pay our daily living expenses by doing work for clients. Creative Tim was a side project that we thought would come in handy to web developers like ourselves. We noticed that we were always “reinventing the wheel” when working with clients, and creating the same items over and over again for their websites. So we wanted to create a few standard components, like login and register modals, calendars, wizards, headers, and footers. Over the span of a few months, we dedicated our time to implementing the platform and a few freebies (alongside the agency work). In the beginning, we didn’t have any Twitter followers, Facebook fans, or email list subscribers. We posted a lot of stuff about our freebies on various design forums and we used the “stalk web developers on Twitter” technique to spread the word about our products. 2. How we got our first users At first, nobody really understood what we wanted to do. They didn’t understand the value we could provide by helping them improve their businesses. We decided that it would be better to create a more complex product that would help people understand what we were doing 🤔 We launched the Get Shit Done Kit, a UI Kit based on Bootstrap. It was featured on Designer News, and it was quite popular. We got over 11,000 users from that source, which was a huge spike for our business. Then two weeks later our startup was featured on Product Hunt. That gave us another spike with over 5,000 users. After that, the situation was stable, and we graduated from 0 users/week to a consistent 2,000 to 3,000 users/week. A couple of months later, motivated by the success of free Get Shit Done Kit, we released Get Shit Done Kit PRO the premium version of GSDK, with more components and ready-to-use example pages. Initially, we only made a few sales. The product was generating about $200/week, which was not nearly enough to sustain our business. At the same time we were working on a web project for one of our clients. Then in December, we got published on Bootstrap Expo, the most popular gallery for showcasing websites created with Bootstrap. This was another important spike for our business. Since all of the people who go to Bootstrap Expo for inspiration already know Bootstrap or have previously worked with it, they were the perfect audience for our business. Later, we discovered that getting traffic on your website is not enough to create a long term relationship with your users, and most of them forgot all about us after their first interaction. We did some research and discovered what most marketers probably already know: people forget things that they aren’t reminded of. Then we implemented the “Remember us email system” following the rules from the forgetting curve. We wanted to give our users a reminder that we still existed and that we’re a valuable resource for their projects or their clients’ projects. Currently, we send emails at the following schedule: After 3 days from their first download, we send an email with other recommended products. On day 10 we send an email requesting feedback and asking if they need help. On day 15 we remind them that they can upgrade to PRO. On day 30 we ask them again for feedback and offer to promote something they’ve built in our gallery and social media. We send a final reminder on day 60. 3. Marketing strategies we used to grow Most of our marketing strategies consisted of submitting our content to different communities like Reddit, Product Hunt, Designer News, Hacker News, and GitHub. Some important subreddits that work well in our area include /r/web_design, /r/html5, /r/frontend, and /r/webdev. We also paid between $100–200 for newsletter campaigns a couple of times. Even though the ROI ratio matched the amount we invested, the campaigns did not meet the expectations. (Maybe this was just in our case, that wasn’t profitable and it works better for others.) Then we paid $400 for Get Shit Done Kit PRO to appear in the Sidebar.io newsletter, a curated list of the 5 best design links made by Sacha Greif. This was a very rewarding newsletter for us, generating about $1,500 in sales. Then we purchased the “Review + Newsletter” package ($550) from eWebDesign. There were about 5,000 users who participated in the giveaway, and the total sales amounted $2,800. We also thought about different places where we could find web developers who could use our products, and we realized that hackathons were exactly what we needed. Presenting how our tools can help during the Hackathon Subsequently we started talking to people that were organizing hackathons to offer them free licenses for our “premium products.” We sponsored over 20 hackathons in different cities around the world (you can check them here). All the developers were happy to get free licenses, which made us happy that we could help them create better projects faster and they also found out who we are, so a win-win situation. Critically, being physically present at some of the hackathons also gave us a lot of information about how the developers were using our products and how we could improve them in order to make them more user-friendly. In March 2015, we finished the agency’s contracts and we switched from “Agency mode” to “Startup mode.” With some revenue in the bank and a few monthly sales, our team moved to working full time for our startup. As we put everything together and constantly launched new products, our sources of traffic and revenue grew. 4. How the business model works We realized that the best business model for Creative Tim was freemium: we create high quality freebies that help web developers build great websites, then release the PRO versions for those freebies, which contain more elements, sections, plugins, and example pages. At this moment, we have 8 premium products, each of which have their own freebies. Their prices range from $19 to $599, depending on the license and archive type (HTML, HTML + PSD, HTML + Sketch). The freebies appear everywhere on different communities, blog posts, newsletters, and social websites — and they are driving all of our traffic. Our business model: create high quality freebies that help web developers build great websites, then release the PRO versions for those freebies which contain more elements. 👌🏼 The basic idea is that those freebies are always appearing on top 10 lists in these big communities. Each post that’s in the top 10 (depending on how big is the community) gives us between 1,000 and 15,000 targeted users in one day. You can imagine how much that would cost if you wanted to do a regular targeted marketing campaign. 😮 Some examples: Paper Kit — 380 upvotes on Reddit Material Kit — 560 upvotes on Reddit Light Bootstrap Dashboard Angular — 210 upvotes on Reddit Material Kit — 180 uvpotes on Hacker News (peak position 9 with over 14,000 users coming to our website in 1 day) Material Kit — 860 upvotes on Product Hunt etc… you got the idea 5. The story behind our revenue sources Direct Product Sales Here we have the regular sales that are done on our website, which are worth about 24% of our overall sales. This doesn’t include the Big Bundle. What is this Big Bundle, and how did we create it? We noticed that some of our users were downloading all our free products. (When I say all, I literally mean all of them in about 2–3 minutes after they have created an account.) We also noticed that some of our clients were purchasing all the products that were premium. So we decided to test a new product called the “Big Bundle” which gives you access to all our products with huge discounts (over 60%). This big package was getting around 6–8 purchases per month. Since the prices for this Big Bundle is $299 (instead of $500) for the personal license and $669 (instead of $2,127) for the developer license, it’s a good source of revenue and a great deal for the web designers and agencies who are using our products for multiple clients. It’s a win-win situation. Affiliates Sales We’ve created an affiliate network, and our affiliates are very happy because they get 50% to themselves from each transaction. For example, one of our most important affiliations is done through a very popular GitHub Repo: Bootstrap Material Design (17,000+ stars on GitHub). Currently, affiliates account for around 25% of our overall revenue. Organic Search (SEO) We saw that we were also getting around 22% of our revenue from SEO. So we decided to invest more in SEO, we brought on an SEO consultant, whom we pay around $500/month to improve our products’ ranks in Google. Other revenue The remainder of our monthly revenue comes from Facebook, Twitter, and our newsletter. Here’s how our revenue has evolved over time, along with some historically important moments, so you can understand why it has grown in some months: 6. The biggest lessons we’ve learned so far It sounds cliché, but having a great product is crucial. A lot of founders really struggle trying to market and sell something that people don’t want or don’t need. If your product is crap, there is no marketing strategy — and no source of investment — that can keep it alive for long. At the moment, our products are used by over 134,000 web developers around the world. We have people from Microsoft, Ubisoft, Vodafone, Orange, Harvard University, Stanford University, and governmental institutions downloading and using them as different internal tools, and we’ve sponsored more than 20 global hackathons from 14 countries. Don’t look to be the next Facebook. Try to solve a real problem instead. Every step in our development seemed like the natural thing to do at the time. Looking back at our evolution, we wouldn’t change anything. But with all we’ve learned, we could definitely do everything faster the second time around. We’ve always created and improved our products based on our customers’ feedback, and that is the best way to develop a business. It doesn’t matter what you personally like — you need to make sure you solve a real problem for a real customer. Read, read, read. In the past three years, I’ve read more than I’d read in my entire life, and this makes me feel great. Here are some of my favorite books, which I recommend to everybody: How to Win Friends and Influence People — Dale Carnegie Zero to One — Peter Thiel The Hard Thing About Hard Things — Ben Horowitz Law of Success — Napoleon Hill Think and Grow Rich — Napoleon Hill Good to Great — Jim Collins The Lean Startup — Eric Ries The Charisma Myth — Olivia Fox Cabane Lean Analytics: Use Data to Build a Better Startup Faster — Alistair Croll I really do think that the secret weapon is to deliver great products combined with a great user experience and a great customer support. The best decision that we made was to put our customer in the first row, and make sure that they were receiving a great UI kit/Dashboard that really solved their problems. That guided us through the whole journey. Our secret weapon is that we deliver great products combined with a great user experience and great customer support. Everything is possible. We are living in a world where anybody can become anything they want as long as they want to invest the amount of time that is needed. I’m saying time, and not money, because we all have time. I want to recommend two books that talk about this: Karaoke Capitalism by Jonas Ridderstråle and Kjell Nordstrom, and Zero to One by Peter Thiel (a PayPal co-founder). At this point, there are no limits. You can go anywhere on the planet and you can talk with whomever you want just by contacting them through social media. Today an ordinary person can achieve more influence than the president of a small country. Think of those Instagram accounts with millions of followers. If I — a regular guy from Romania — can build a profitable business in 2.5 years that is making 60x my country’s monthly minimum monthly wage, then boy, just about anything is possible.

Elvis was "just a village boy from Nigeria who had nothing but a dream and a Nokia J2ME feature phone." Today, he's a 19 year old Android developer who has worked on over 50 apps and currently works for an MIT startup. This is his story. Written by Elvis Chidera: https://twitter.com/elvisnchidera Read by Quincy Larson: https://twitter.com/ossia Original article: https://fcc.im/2Bwp50Y Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:  In 2012, I was just a village boy from Nigeria who had nothing but a dream and a Nokia feature (J2ME) phone. Today, I’m a 19 year old Android developer who has worked on over 50 apps and currently works for an MIT startup. My name is Elvis Chidera and this is my story. My journey began with my curiosity about how to build a website. Growing up, I spent a lot of time online as I loved downloading games and reading Society Of Robots. I would save for weeks to buy a 10 MB internet bundle for 100 Naira ($0.28), and back in 2012, that could last for a month. When learning to code, I took the first and simple step of doing a Google search about how to build a website. I got millions of results. Not knowing where to start, I clicked on the first link I saw, which was from W3CSchools. The article explained that I need to learn some languages (HTML and CSS) to be able to build a website. I checked some other resources to confirm that I actually needed to learn these things. Then I started the W3CSchools HTML and CSS course. Each day after school I would head over to the website to study. Initially, the code examples and explanations didn’t make much sense to me. But I kept studying regardless. I referred to various tutorials when I was stuck. This helped me view the problems I encountered from many different angles. When I was younger, I struggled with my reading and writing skills in school. I was only able to get better at them through continuous practice. So I already had this model in my head: if I continue to practice — no matter how long it takes — I will ultimately be able to understand these programming languages. A few months of intensive learning got me acquainted with HTML, CSS, and JavaScript. While I was still learning, a friend showed me the movie “The Social Network.” And after watching it, I was super motivated to build the next big thing. Thank you, Hollywood. I had a eureka moment a few days later. The idea was to build a better version of Facebook. At that time, you couldn’t see your Facebook friends that were online. Also, Facebook was built to connect with people you already knew in real life. So that was my billion dollar startup idea: build a social network with all the features Facebook didn’t have. Mark Zuckerberg - I’m coming for you - or so I thought. I spent the next few months building a better social network by adding any feature I could even think of using. I was naively confident that I was going to win. After completing the project, I did what anybody without an advertising budget would do. I spammed the internet for days and days. After several days of marketing, reality slapped me hard in the face. I only got 200 users, which I had to keep begging to come back to the site. I was depressed! A few months of hard work spent in vain. This taught me two important lessons the hard way: I needed to recognize the cold start AKA chicken and egg problem that new platforms face early on. I was building something I thought people needed. But I ended up building just another feature factory. While it’s okay to be motivated by a project, you also need to know when you’re headed down a dead end. I spent a few more months trying to see if I could get more people on my site, but retention numbers kept dancing toward 0%, and I eventually gave up on the project. But I was motivated by the motto of Lewis in Meet the Robinsons, “Keep moving forward.” Seeking inspiration for my next project, I reflected on the needs of my local community. This time around, I wanted to build something that people actually needed and are willing to pay for. I came up with an idea to make text messages cheaper and easier to send to multiple people at a time. This was more like Whatsapp backed by SMS. After speaking to different people about it, I decided this was the next thing to do. I named the project Xmx Me. It was going to be a J2ME app. This meant I had to learn Java. Looking back in time, I have to admit that it was the biggest challenge I’d yet encountered. I had to read some tutorials several times to fully understand them. After completing a few Java courses, I was ready for work. Relentlessly typing one line of code after another, I carefully built the backend with PHP, the frontend with HTML and CSS, and the mobile app with J2ME. The app was coming to life. But here’s the thing — I didn’t own a laptop. I was building out all of these pieces of my app on my J2ME feature phone. Wait. What? You read that right. I wrote my code on a Nokia 2690 How I built my production apps on a feature phone At this point in my life, I had never actually programmed on a laptop. I simply couldn’t afford one. My parents wanted to help me. But it was difficult for them because they had to choose between paying my school fees (and other necessities) versus buying me a laptop. I hadn’t used a laptop before, and my only interaction with computers was at cyber cafes. I remember watching some videos about how to use a computer (left click, drag, drop, and other basic stuff) and then walking into a cyber cafe to practice them. I was lucky that a relative had gifted me a feature phone (The Nokia 2690). This phone changed my life. It’s what I used to develop Xmx Me, my failed social network, and several other projects. With nothing but a phone and the will to succeed, hour after hour I typed my code on that tiny keyboard. I was lucky again to have found an app that allowed me to compile my J2ME projects. Yes, building a J2ME app on a J2ME phone is possible. The SDK was resource hungry, so my battery often died. I would carry on, writing out all my code on paper and try to review it for any syntax errors. I don’t think I’ll fail any Java whiteboard coding tests after having done this for so long. :) Launching my group SMS app After several months, I had the product ready. I was able to convince someone I met on an internet forum to help me pay for the website hosting and the bulk SMS service for a limited number of SMS units. The app launch went well — at least better than my first project. We got some local press, and one of Kenya’s top blogs even wrote about the app. We grew organically to about 5,000 users. We were in business. And we were getting transactions a couple of times a day. With no prior experience running a business, I made some huge mistakes, some of which were: There was no easy way to charge users in Nigeria. Not everybody has a debit card. So I allowed people to pay using their mobile phone credit. The problem here was, there was no official way to convert this credit into money. I had to sell to vendors, who bought it back at a ridiculously low rates. There was little to no accounting. I was losing money and I didn’t know about it. I didn’t factor in some overhead costs. There were several missing pieces. I was considering selling the App to buy a laptop. Not knowing what to do, I went online to beg. Yes, I was that shameless and hungry. It didn’t turn out well. Somebody accused of being a scammer, which I eventually resolved. Again, I was inexperienced and I handled the situation poorly. After borrowing money multiple times to keep the business running, I decided to throw in the towel. Looking back, I think this was a bad decision. With a little more learning and experience, I would have been able to make things better. Maybe I didn’t see any future in an SMS app. Well, I released a throwback app recently, and many of the users still use it and love it. Lessons I learned along the way I realized that if I was going to be able to afford a computer anytime soon, I would need to work hard for it. So I began saving all the money I could. I cut my daily expenses and lived as simple a life as possible. I asked my relatives for help. I even sold some personal belongings to raise money for the laptop. Still, it wasn’t enough. Determined to achieve my goal, I took on a freelance job of building a website so I could earn the remaining sum. How do you use a feature phone to build a website designed for PC users? Simple: have a Facebook friend who you disturb every night to view your website on his computer and give you feedback. It was cheaper than going to a cyber cafe repeatedly. I also made heavy use of Ideone which allowed me to run my PHP scripts to see if they work before uploading them. Well, I finally was able to get that laptop. I can still remember the feeling of joy I had. That smell of plastic when you unbox a brand new cheap computer. I could now work on any project I wanted without feeling restricted because of my phone. Since J2ME devices were slowly dying out, I eventually switched to building for the Android platform. My Java skills were still relevant there. I just needed to learn some platform-specific things. The next year in 2015, after high school, I decided to start working to support my family. So I began freelancing. I was always active in local forums and groups, looking for people who wanted help with building an Android app. Because I didn’t have a good portfolio, I would build apps for some people before they even paid, without any guarantee that I’d be paid. I was stung by this approach several times, but it allowed me to build a good enough portfolio. I would like to share something I wish I knew while I was freelancing: Don’t spread yourself too thin. Taking up too many responsibilities is not good for your health, your family, or the clients. I worked with several clients from different parts of Nigeria who loved my work. I eventually got a full-time job in Lagos, Nigeria after working with a client remotely. Then, while going through my news feed, I saw a job advert for an Android developer position at Dot Learn. I looked them up and realized they are an MIT startup working in an education technology field that I was passionate about, and in a market I understood. They had a unique idea: to solve the problem of access to online education by making educational videos that are extremely data-light — as low as 1MB for every hour of video. This was almost unbelievable, and I knew it was key to making education very accessible to a lot of people. I am very passionate about revolutionizing education in Africa. In fact, I have already built a free (ad-supported) exam prep app called PrepUp that has over 30,000+ installs and was one of the finalists at the West Africa Mobile Awards in 2016. So I wanted to be part of what Dot Learn was building. So I went through the developer job requirements and I felt I had a chance. But impostor syndrome didn’t want me to be great. For days I had conflicting thoughts. Should I apply or not? Then I realized one thing: I had nothing to lose. The worst that could happen would be that I got rejected. But I wouldn’t die. So, I went ahead and applied. Fingers crossed, I started re-watching several of the videos I had downloaded from MIT OCW. I also spent some nights watching some coding interview solution videos. In the past, I had mostly been hired based on my strong portfolio and previous job experience, but I didn’t want to be caught off guard if they gave me a coding interview. Well, long story short: after lots of preparation, answering some difficult questions, a phone interview, and some coding projects, I was accepted. I couldn’t believe it. I was ecstatic. Looking back at it, this was one of my best decisions. Working at Dotlearn, I have had exponential growth in my career and have met with lots of awesome people from MIT, Harvard, and other great places. From attending big events like the Techcrunch Battlefield (I ended up missing my flight) to realizing I could rap, it’s been a fun and exciting experience so far.  

An Australian developer thought his local police force was spending way too much money on their new license plate scanning system. So he decided to build one himself. Here's how he did this, and how he ended up catching a criminal. Written and read by Tait Brown: https://twitter.com/taitems Original article: https://fcc.im/2iJWWuE Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: The Victoria Police are the primary law enforcement agency of Victoria, Australia. With over 16,000 vehicles stolen in Victoria this past year — at a cost of about $170 million — the police department is experimenting with a variety of technology-driven solutions to crackdown on car theft. They call this system BlueNet. To help prevent fraudulent sales of stolen vehicles, there is already a VicRoads web-based service for checking the status of vehicle registrations. The department has also invested in a stationary license plate scanner — a fixed tripod camera which scans passing traffic to automatically identify stolen vehicles. Don’t ask me why, but one afternoon I had the desire to prototype a vehicle-mounted license plate scanner that would automatically notify you if a vehicle had been stolen or was unregistered. Understanding that these individual components existed, I wondered how difficult it would be to wire them together. But it was after a bit of googling that I discovered the Victoria Police had recently undergone a trial of a similar device, and the estimated cost of roll out was somewhere in the vicinity of $86,000,000. One astute commenter pointed out that the $86M cost to fit out 220 vehicles comes in at a rather thirsty $390,909 per vehicle. Surely we can do a bit better than that. The Success Criteria Before getting started, I outlined a few key requirements for product design. Requirement #1: The image processing must be performed locally Streaming live video to a central processing warehouse seemed the least efficient approach to solving this problem. Besides the whopping bill for data traffic, you’re also introducing network latency into a process which may already be quite slow. Although a centralized machine learning algorithm is only going to get more accurate over time, I wanted to learn if an local on-device implementation would be “good enough”. Requirement #2: It must work with low quality images Since I don’t have a Raspberry Pi camera or USB webcam, so I’ll be using dashcam footage — it’s readily available and an ideal source of sample data. As an added bonus, dashcam video represents the overall quality of footage you’d expect from vehicle mounted cameras. Requirement #3: It needs to be built using open source technology Relying upon a proprietary software means you’ll get stung every time you request a change or enhancement — and the stinging will continue for every request made thereafter. Using open source technology is a no-brainer. My solution At a high level, my solution takes an image from a dashcam video, pumps it through an open source license plate recognition system installed locally on the device, queries the registration check service, and then returns the results for display. The data returned to the device installed in the law enforcement vehicle includes the vehicle’s make and model (which it only uses to verify whether the plates have been stolen), the registration status, and any notifications of the vehicle being reported stolen. If that sounds rather simple, it’s because it really is. For example, the image processing can all be handled by the openalpr library. This is really all that’s involved to recognize the characters on a license plate: A Minor Caveat Public access to the VicRoads APIs is not available, so license plate checks occur via web scraping for this prototype. While generally frowned upon — this is a proof of concept and I’m not slamming anyone’s servers. Results I must say I was pleasantly surprised. I expected the open source license plate recognition to be pretty rubbish. Additionally, the image recognition algorithms are probably not optimised for Australian license plates. The solution was able to recognise license plates in a wide field of view. Annotations added for effect. Number plate identified despite reflections and lens distortion. Although, the solution would occasionally have issues with particular letters. A few frames later, the M is correctly identified and at a higher confidence rating. As you can see in the above two images, processing the image a couple of frames later jumped from a confidence rating of 87% to a hair over 91%. I’m confident, pardon the pun, that the accuracy could be improved by increasing the sample rate, and then sorting by the highest confidence rating. Alternatively a threshold could be set that only accepts a confidence of greater than 90% before going on to validate the registration number. Those are very straight forward code-first fixes, and don’t preclude the training of the license plate recognition software with a local data set. The $86,000,000 Question To be fair, I have absolutely no clue what the $86M figure includes — nor can I speak to the accuracy of my open source tool with no localized training vs. the pilot BlueNet system. I would expect part of that budget includes the replacement of several legacy databases and software applications to support the high frequency, low latency querying of license plates several times per second, per vehicle. On the other hand, the cost of ~$391k per vehicle seems pretty rich — especially if the BlueNet isn’t particularly accurate and there are no large scale IT projects to decommission or upgrade dependent systems. Future Applications While it’s easy to get caught up in the Orwellian nature of an “always on” network of license plate snitchers, there are many positive applications of this technology. Imagine a passive system scanning fellow motorists for an abductors car that automatically alerts authorities and family members to their current location and direction. Teslas vehicles are already brimming with cameras and sensors with the ability to receive OTA updates — imagine turning these into a fleet of virtual good samaritans. Ubers and Lyft drivers could also be outfitted with these devices to dramatically increase the coverage area. Using open source technology and existing components, it seems possible to offer a solution that provides a much higher rate of return — for an investment much less than $86M. Remember the $86 million license plate scanner I replicated? I caught someone with it. A few weeks ago, I published what I thought at the time was a fairly innocuous article: How I replicated an $86 million project in 57 lines of code. I’ll admit — it was a rather click-bait claim. I was essentially saying that I’d reproduced the same license plate scanning and validating technology that the police in Victoria, Australia had just paid $86 million for. Since then, the reactions have been overwhelming. My article received over 100,000 hits in the first day, and at last glance sits somewhere around 450,000. I’ve been invited to speak on local radio talk shows and at a conference in California. I think someone may have misread Victoria, AU as Victoria, BC. Although I politely declined these offers, I have met for coffee with various local developers and big name firms alike. It’s been incredibly exciting. Most readers saw it for what it was: a proof of concept to spark discussion about the use of open source technology, government spending, and one man’s desire to build cool stuff from his couch. Pedants have pointed out the lack of training, support, and usual enterprise IT cost padders, but it’s not worth anyone’s time exploring these. I’d rather spend this post looking at my results and how others can go about shoring up their own accuracy. Before we get too deep into the results, I’d like to go over one thing that I feel was lost in the original post. The concept for this project started completely separate from the $86 million BlueNet project. It was by no means an attempt to knock it off. It started with the nagging thought that since OpenCV exists and the VicRoads website has license plate checks, there must be a way to combine the two or use something better. It was only when I began my write-up that I stumbled upon BlueNet. While discovering BlueNet and its price tag gave me a great editorial angle, with the code already written. There were bound to be some inconsistencies between the projects. I also believe part of the reason this blew up was the convenient timing of a report on wasteful government IT spending in Australia. The Federal Government’s IT bill has shot up from $5.9 billion to $10 billion, and it delivered dubious value for that blow out. Media researchers who contacted me were quick to link the two, but this is not something I am quick to encourage. A Disclaimer In the spirit of transparency, I must declare something that was also missing from the original post. My previous employer delivered smaller (less than $1 million) IT projects for Victoria Police and other state bodies. As a result, I’ve undergone police checks and completed the forms required to become a VicPol contractor. This may imply I have an axe to grind or have some specific insider knowledge, but instead I am proud of the projects we delivered. They were both on time and on budget. Visualizing the Results The following is a video representation of my results, composited in After Effects for a bit of fun. I recorded various test footage, and this was the most successful clip. I will go into detail about ideal camera setups, detection regions, and more after the video. It will help you better understand what made this iPhone video I took from through the windscreen a better video than a Contour HD angled out the side window. An Ethical Dilemma If you saw the hero graphic of this article or watched the video above, you may have noticed a very interesting development: I caught someone. Specifically, I caught someone driving a vehicle with a canceled registration from 2016. This could have happened for many reasons, the most innocent of which is a dodgy resale practice. Occasionally, when the private sale of a vehicle is not done by the book, the buyer and seller may not complete an official transfer of registration. This saves the buyer hundreds of dollars, but the vehicle is still registered to the seller. It’s not unheard of for a seller to then cancel the registration and receive an ad hoc refund of remaining months, also worth hundreds of dollars. Alternatively, the driver of the vehicle could well be the criminal we suspect that they are. So, although I jokingly named the project plate-snitch when I set it up on my computer, I’m now faced with the conundrum of whether to report what I saw. Ultimately, the driver was detected using a prototype of a police-only device. But driving on a 2016 registration (canceled, not expired) is a very deliberate move. Hmm. Back to the Results Of the many reactions to my article, a significant amount were quite literal and dubious. Since I said I replicated the software, they asserted that I must have a support center, warranties, and training manuals. One even attempted to replicate my results and hit the inevitable roadblocks of image quality and source material. Because of this, some implied that I cherry-picked my source images. To that I can only say, “Well, duh.” When I built my initial proof of concept (again, focusing on validating an idea, not replicating BlueNet), I used a small sample set of less than ten images. Since camera setup is one of, if not the most, important factors in ALPR, I selected them for ideal characteristics that enhance recognition. At the end of the day, it is very simple to take a fragile proof of concept and break it. The true innovation and challenge comes from taking a proof of concept, and making it work. Throughout my professional career, many senior developers have told me that things can’t be done or at least can’t be done in a timely manner. Sometimes they were right. Often, they were just risk averse. “Nothing is impossible until it is proven to be.” Many people bastardize this quote, and you may have seen or heard one of it’s incarnations before. To me, it neatly summarizes a healthy development mindset, in which spiking and validating ideas is almost mandatory to understanding them. Optimal ALPR Camera Setups This project is so exciting and different for me because it has a clear success metric — whether the software recognizes the plate. This can only happen with a combination of hardware, software, and networking solutions. After posting my original article, people who sell ALPR cameras quickly offered advice. Optical Zoom The most obvious solution in hindsight is the use of an optical zoom. Though I explore other important factors below, none lead to such a sheer increase in recognition as this. In general, professional ALPR solutions are offset at an angle, trained on where the license plate will be, and zoomed into the area to maximize clarity. This means the more zoom, more pixels to play with. All the cameras I had at my disposal were of a fixed lens. They included: A Contour HD action camera. These came out in 2009, and I use mine to record my cycling commute and to replay each week’s near death experience. The featured test run was recorded on my phone. My only method of replicating an optical zoom was using an app to record at 3K instead of 1080p, and then digitally zooming and cropping. Again, more pixels to play with. Angle & Positioning The viewing angle of 30° is often referenced as the standard for ideal plate recognition. This is incredibly important when you learn that BlueNet uses an array of cameras. It also makes sense when you consider what a front facing camera would generally see — not very much. What a front facing ALPR camera sees — not much. If I had to guess I’d say a mostly forward-facing array would be the ideal setup. It would consist of a single camera pointed dead center as above, two off-center at 30° each side, and a single rear-facing camera. The value in having most of the cameras pointed forward would come from the increased reaction time if the vehicle is traveling in the opposite direction. This would allow a quicker scan, process, and U-turn than if the rear facing cameras picked up a suspect vehicle already ten meters past the police vehicle. A four camera array would need to be angled similar to this. Icons from Freepik. A Gymbal When compositing the video, I thought about stabilizing the footage. Instead I opted to show the bumpy ride for what it was. What you saw was me holding my phone near the windscreen while my wife drove. Check out that rigorous scientific method. Any production-ready version of a vehicle-mounted ALPR needs some form of stabilisation. Not a hand. Frame Rate Both the attempt to replicate my project and my recordings since then explored the same misconception that ALPR sampling frame rate may be linked to success. In my experience, this did nothing but waste cycles. Instead, what is incredibly important is the shutter speed creating clean, crisp footage that feeds well into the algorithm. But I was also testing fairly low-speed footage. At most, two vehicles passing each other in a 60km/h zone created a 120km/h differential. BlueNet, on the other hand, can work up to an alleged 200km/h. As a way of solving this, a colleague suggested object detection and out-of-band processing. Identify a vehicle and draw a bounding box. Wait for it to come into the ideal recognition angle and zoom. Then shoot a burst of photos for asynchronous processing. I looked into using OpenCV (node-opencv) for object recognition, but I found something simpler like face detection, taking anywhere from 600–800ms. Not only less than ideal for my use, but pretty poor in general. Hype-train TensorFlow comes to the rescue. Able to run on-device, there are examples of projects identifying multiple vehicles per frame at an astounding 27.7fps. This version could even expose speed estimations. Legally worthless, but perhaps useful in every day policing (no fps benchmark in readme). To better explain how high-performance vehicle recognition could couple with slower ALPR techniques, I created another video in After Effects. I imagine that the two working hand-in-hand would look something like this: Idea: how vehicle object detection could remove ALPR frame limits by processing asynchronously. Frame Rate vs Shutter Speed A different manifestation of frame rate is largely influenced upon shutter speed, and more specifically, the rolling shutter issues that plague early or low end digital movie recorders. The following is a snapshot from some Contour HD footage. You can see at only 60km/h the rolling shutter issue makes the footage more or less unusable from an ALPR point of view. Adjusting frame rate on both the Contour HD and my iPhone did not result in noticeably less distortion. In theory, a higher shutter speed should produce clearer and crisper images. They’d become increasingly important if you were to chase the 200km/h BlueNet benchmark. Less blur and less rolling shutter distortion would ideally lead to a better read. Open ALPR Version One of the more interesting discoveries was that the node-openalpr version I was using is both out-of-date and not nearly as powerful as their proprietary solution. While an open source requirement was certainly a factor, it was amazing how accurately the cloud version could successfully read frames that I couldn’t even identify a plate on. ALPR Country Training Data I also found that the main node-openalpr package defaults to US country processing with no way of overriding it. You have to pull down someone else’s fork which allows you to then provide an extra country parameter. Slimline Australian plates need their own separate country detection to regular Australian plates? But this doesn’t always help. Using the default US algorithm I was able to produce the most results. Specifying the Australian data set actually halved the number of successful plate reads, and it only managed to find one or two that the US algorithm couldn’t. Providing the separate “Australian Wide Plate” set again halved the count and introduced a single extra plate. There is clearly a lot to be desired when it comes to Australian-based data sets for ALPR, and I think that the sheer number of plate styles available in Victoria is a contributing factor. Good luck with that. Planar Warps Open ALPR comes with one particular tool to reduce the impact of distortion from both the camera angle and rolling shutter issues. Planar warp refers to a method in which coordinates are passed to the library to skew, translate, and rotate an image until it closely resembles a straight-on plate. In my limited testing experience, I wasn’t able to find a planar warp that worked at all speeds. When you consider rolling shutter, it makes sense that the distortion grows relative to vehicle speed. I would imagine feeding accelerometer or GPS speed data as a coefficient might work. Or, you know, get a camera that isn’t completely rubbish. What others are doing in the industry Numerous readers reached out after the last post to share their own experiences and ideas. Perhaps one of the more interesting solutions shared with me was by Auror in New Zealand. They employ fixed ALPR cameras in petrol stations to report on people stealing petrol. This in itself is not particularly new and revolutionary. But when coupled with their network, they can automatically raise an alert when known offenders have returned, or are targeting petrol stations in the area. Independent developers in Israel, South Africa, and Argentina have shown interest in building their own hacked-together versions of BlueNet. Some will probably fare better than others, as places like Israel use a seven digit license plates with no alphabet characters. Key Takeaways There is simply too much that I’ve learned in the last few weeks of dabbling to fit into one post. While there have been plenty of detractors, I really do appreciate the support and knowledge that has been sent my way. There are a lot of challenges you will face in trying to build your own ALPR solution, but thankfully a lot of them are solved problems. To put things in perspective, I’m a designer and front end developer. I’ve spent about ten hours now on footage and code, another eight on video production, and at least another ten on write-ups alone. I’ve achieved what I have by standing on the shoulders of giants. I’m installing libraries built by intelligent people and have leveraged advice from people who sell these cameras for a living. The $86 million question still remains — if you can build a half-arsed solution that does an okay job by standing on the shoulders of giants, how much more money should you pour in to do a really really good job? My solution is not even in the same solar system as the 99.999% accurate scanner that some internet commenters seem to expect. But then again, BlueNet only has to meet a 95% accuracy target. So if $1 million gets you to 80% accuracy, and maybe $10 million gets you to 90% accuracy — when do you stop spending? Furthermore, considering that the technology has proven commercial applications here in Oceania, how much more taxpayer money should be poured into a proprietary, close-sourced solution when local startups could benefit? Australia is supposed to be an “innovation nation” after all.

5 years ago, Ken was a college dropout who woke up every day at 4 a.m. to drive a forklift. He taught himself to code and kick-started his career by convincing a local web development company to hire him. Ken shares his advice on how to go from a hobbyist to a professional developer. Written and read by Ken Rogers: https://twitter.com/KennethARogers Ken's original article: https://fcc.im/2FeA24K Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: A few years ago, I was bouncing back and forth between landscaping jobs and restaurant jobs. I had just left college, and didn’t know what I was going to do with my life. I had a lot of ideas, but no direction. During that time, I started teaching myself programming. At first it was a hobby. I thought it was cool to be able to build things using nothing but my brain and some code. But then I started thinking about where my life was going, and saw this as a potential living. At first, I put the idea out of my head. I couldn’t afford real education. I already dropped out of college once because of money, and if I went in for computer science, I’d have to start over. I’d leave with 6 years of school and well over $50,000 in debt if I took that route. So that wasn’t an option. Then I started thinking that I could teach myself web development well enough to get an internship. My initial plan was to introduce myself to a few companies in my town, and ask if they would want to meet with me. I wanted to discuss the potential of me working with them while I was in school. That way I could pay for school and get some experience at the same time. So I got serious about web development. Instead of tinkering I started to build a real portfolio and document my skills. I started becoming active on places like Stack Overflow. I built a few practical applications and put them on GitHub. They were nothing fancy, but they demonstrated that I knew how to code. One company didn’t offer me a part time job. They didn’t say to come back after I had my degree. They offered me a full-time job on a 6 month trial basis as their new Junior Developer. I was over the moon. It turns out that once I got serious and started developing with a purpose, I taught myself quite a bit. I was able to answer their questions. I was able to walk them through the modest applications I had built. And I was able to explain how my projects worked. I stayed at that company for two and a half years, and then took a job as a web developer for the city I live in. View yourself as a lifelong apprentice An important part of my transition into a professional developer role was viewing the time I spent with my previous company as an apprenticeship. I learned as much as I could. The real-world knowledge gained from working at a company is invaluable. Knowing how to work with clients, coworkers, and within constraints is essential. This is something you can only learn in the field. While I may know more now than I did when I first started that job, I’ll never stop viewing myself as an apprentice. One of the requirements for being a great developer is the desire to continue learning. The minute we see ourselves as having mastered a skill is the minute we stop growing. Hemingway said it best: We are all apprentices in a craft where no one ever becomes a master. He was talking about writing, but it applies to development as well. The combination of teaching myself and working for a company has allowed me to learn so much (I’m even writing a book). I understand the technical practice of web development, and also how to go from a hobbyist to a professional. It’s a path that anyone can take, regardless of your time or abilities. To give you some perspective, I was working two jobs at once — one of which involved getting up at 4 a.m. to drive a forklift around. Learning to code as a busy adult takes determination, drive, and a stubborn persistence. Making the transition from Hobbyist to Professional Here’s a process that you can follow. The exact journey will be different for everyone, but there are steps you can take to get you on the right path. 1. Realize that you can do this Anyone can teach themselves to be a developer. There’s this idea that being self-taught is something only a certain type of person can do. They’re right in a sense. You need to be self-driven and motivated by something other than immediate payment. But anyone can become this type of person. There’s this idea present in our society that some people are born with certain traits and others aren’t. It’s detrimental to growth, and one of the reasons why so many people feel unfulfilled in life. If you always felt that you either “had it” or you didn’t, it would be very easy to get discouraged. I want to put that myth to bed right now. Anyone can learn to be self-motivated and teach themselves programming. Or start a successful business. Or achieve a long-term goal. It’s not about catching a big break, or being born with the right traits. It’s about perseverance. If you can put your head down, push through the hard times, and commit, you can do anything you want to. That last part is super important, but I want to provide a warning before moving on. People are often too quick to embrace their own successes and the successes of others. It’s known as survivorship bias. There is an element of luck in everything. Sometimes things just work out. For example, I contacted a web development agency and was lucky enough that they happened to be looking for someone at that moment, and I happened to fit what they were looking for. But what is luck? Sure, I was lucky to get that job, but I never would have been lucky if I hadn’t made the decision to teach myself development. And then made the decision to apply to that job. Luck does play a factor, but the myth is that it is all up to luck. You can increase your odds of getting lucky, you just have to be willing to put yourself out there. But luck will never find you if you don’t commit to being great at something. 2. Commit to being incredible at your craft One of my biggest weaknesses is that I get bored and distracted. I want to jump into the next project. This tendency will kill your success. It feels like freedom. Being able to bounce between whatever project happens to suit your mood that day, but... It’s a trap! If you take away nothing else from this article, let it be this: The number one key to succeeding in becoming a professional developer is to commit. Commit and never stop until you make it happen. This applies to everything. People stress out about which framework to use. But what matters is picking one and sticking with it. You can transfer and learn new languages and frameworks later. What matters is the problem solving skills you will gain when developing. The ability to think like a developer. I taught myself programming using Laravel, but the company that hired me used CakePHP. It didn’t matter. They knew I could pick up the technical skills required to switch frameworks. Pick a direction and see it through, no matter what. You have to remove the possibility of getting distracted by something else. Few feelings can compare to the relentless pursuit of mastery of a craft. It isn’t easy. Once you learn to ignore distractions, you will notice an increase in enjoyment of your work. Mike Rowe is fond of saying that people shouldn’t start with finding their passion. People are so unhappy because they look for the perfect career. They look for the one that they are passionate about. But passion comes from an unstoppable desire to be incredible at your craft. Once you adopt that mindset, your abilities as a developer will take on a new life. 3. Start building things immediately Aspiring developers can get stuck in the trap of reading too much without taking action. Tutorials and books are great for learning the basics. The problem is that they instill a false sense of confidence in the developer. Have you ever finished a programming book and gone to build something on your own only to realize you had no idea how to go about doing it? Then you know what I’m talking about. The solution to this is simple, but not easy. Start building. Make something. Make an app that solves a problem you have in your own life, or that addresses an issue for someone close to you. Make something for fun. Make something and put it out there. Make it open source and put in on GitHub. You aren’t doing it for anyone else, it’s for you, so don’t worry about other people’s opinion of it. Your code will be ugly at first. I look back at some of the code I wrote even a few months ago and want to vomit. But you can’t learn development without building stuff. Books are fantastic, and I am obsessed with reading as many as possible. Then you must apply that knowledge. You’re going to run into issues and you’re going to struggle. That’s good. Those are the times we learn the most. Start off by building things that solve problems, I’ll talk more about that in step 6 below. 4. Set up an online presence As soon as you start building things, you’ll want to set up an online presence. Your GitHub account will be a great start. This is where you’ll be able to house the projects you are working on and share them with the world. But you want to go further than this. I recommend setting up your own portfolio site. This site will do a few things: - It will serve as a public place to tell potential employers about yourself - It will be another place where you can showcase your work - It will serve as your platform - That last one is huge. Once you start building things, you should immediately start writing about them. Start a simple blog where you share what you are working on and teach everything you know. This is one of the best ways to give potential employers a taste of who you are and what you can do. It’s a way to get your name out there and start building a platform for yourself. This can lead to job opportunities and the possibility to make more income on the side by writing books or freelancing. Your site should serve a very specific purpose. Most people create an online resume, but you should do more. What is your specific goal? Your website should be designed and created around that goal. If you want to get a job working on a certain kind of project or with a certain framework, put that in your site. I recommend having 4 core areas for your site: 1. Home page Your home page is the entry point to your site. It should provide a very brief overview about who you are and what you do. And should direct people to go where is most relevant for them. For example, you could have two main buttons. One leading people to your writing section to learn more about web development, and one leading to a hire me page if someone is interested in hiring you. 2. Writing This is where your blog and your tutorials will live. Write as much as you can here, and don’t be afraid to share it. 3. About A simple about section that goes into more detail about who you are and what you do. Don’t make this a life story. Again, target this section to be relevant towards what you want to do. Rather than talk about your personal life, talk about what led you to web development, your journey so far, and where you want to go. Mention some of your favorite projects and link to them. 4. Hire Me An essential part of your site, this is where people will go if they are interested in hiring you as a developer. Make sure to find the right balance between selling yourself and being honest. There may be some overlap between this page and your about page, but this page will be more specific about your skills and what you bring to the table. This page should also have a contact form so people can get in touch. In addition to your own site, start offering to write for other major publications. Then you can provide a link back to your site in the bio section. 5. Start teaching everything you know Nathan Barry is a big fan of teaching everything you know. He tells the story of Chris Coyier, founder of CSS Tricks. That site started out as Chris publicly writing about what he was learning so others could follow along. Now it’s one of the biggest web development sites out there. The lesson here is that you don’t have to be the world’s greatest expert to start writing about something and teaching it. In the online business world, there is this idea of the relative expert. It’s the idea that everyone is an expert in something relative to someone else. I have my issues with this, especially when it is used by someone to justify selling something that maybe they shouldn’t be selling. But it is a useful comparison to make. What bothers me is the use of the word expert. I don’t think there is anything wrong with teaching what you know, and even potentially selling that information if it is valuable to someone else. But calling yourself an expert may be taking it too far. So when you write your content, approach it honestly. I prefer the term learning in public. There are many people who got their start by simply being a public learner. They were learning a craft and documenting what they were learning along the way. This is the perfect way to approach teaching everything you know. As you learn more and more, you build up your content, and become a better writer in the process. Over time, others in your industry will start to see you as an authority in your space. This will be invaluable both when it comes to finding a job and if you ever want to strike out on your own. 6. Build to solve problems One of the most important aspects of becoming a professional developer is doing everything with a specific intention. It’s one thing to build random apps for fun, it’s another to build apps and sites that solve specific problems. Web development shops aren’t really in the business of coding, they are in the business of solving problems. The coding is just their preferred tool to make that happen. Read any marketing or copywriting book and they will tell you to sell the benefits of your product, not the features. Web developers should market their apps to show how they effectively solve a customer’s problems. And then back up their claims with specific metrics. Customers are generally more responsive to this approach than if the developers talk about the bleeding edge technologies they use. You will be a very attractive prospect for employers if you can demonstrate your programming skills as well as your ability to code with the specific intention of solving problems and making meaningful applications. Think about benefits vs features when you are communicating with potential employers or clients, and when writing the content for your site. Of course, you should also mention your coding proficiency, but most people spend all their time on this. Mention it briefly so potential employers know what you do. If you have a portfolio of effective applications, your coding skills will mostly speak for themselves. 7. Take on an apprentice mindset The day you think you have mastered something is the day you stop learning. Adopt the mindset of a lifelong apprentice. There is always more to learn and always more to improve on. This is especially important in the early stages of your career. If you get a part time job or internship or land a role as a junior developer, you need to immediately get in the mindset of learning and growing as much as possible. You should really be doing this right away, even before you have an actual ‘mentor’. In his book, The Art of Work, Jeff Goins talks about the 21st century version of the apprentice-master relationship. Back in medieval times, the relationship was very formal. A master would take on an apprentice for years, and they would slowly start to master their craft until they reached the title of master, at which point they would take on an apprentice. The relationship has changed, but it is still very important to consider yourself an apprentice. The main difference is that now you have to keep an eye out for potential mentors and learning opportunities, and there will be many throughout your journey. In the world of web development, we are constantly on the internet, so this can come in various forms. Books, tutorials, courses, forums, and other forms of learning are all valuable. I think, however, the most valuable form of apprenticeship comes from learning from someone who is currently in the position you want to be in. This is why it is so important to be eager and willing to learn. Getting your first development job is not the end of the journey, it’s the beginning. That is when you will really start learning and exponentially growing your knowledge. 8. Learn to collaborate One of the biggest differences between coding as a hobby and coding for a living is learning to collaborate with people. You’ll need to interact and work with peers, bosses, colleagues, clients, partner companies, and all kinds of personalities throughout your career. Learning how to effectively work with other people is important. In the field of web development, communication is key. When a company comes in and tells you what they want, and you aren’t clear about exactly what that looks like, it can cause a lot of problems and headaches in the future. Likewise, if you can’t communicate with the people you work with, your work will suffer and you won’t be able to do your job as well. While you’re still learning, there are a few great ways to do this. Part of this will come when you start teaching everything you know. People will interact with you, sometimes negatively, and you’ll learn how to deal with those situations. I also highly recommend contributing to open source projects. This gives you a taste of what it is like to collaborate on a project where different people may have different ideas on the best way to do things. Contributing to open source projects can be intimidating, but it will do wonders for your development career. Check out this site to get started. Get out there and make a living Being a web developer is hard. It means a life of non-stop learning and adapting to new technologies. It’s one of those careers where you need to be well-versed in not only technology, but business and communication as well. It’s an extremely rewarding path. You get to make things that solve people’s problems and make their lives easier, while making a fantastic living at the same time. There are countless resources to help you learn to code, many of them completely free, but there seems to be a lack of resources helping people make that transition into professional developer. I hope this short guide provided a good road map for you to get started becoming a professional developer. Remember, nothing will happen unless you take action. Build a simple portfolio website, email a few potential employers, write some posts on Medium. Just start doing something. The more you put yourself out there, and the more you do, the sooner you’ll make the shift from amateur to professional.

For Haseeb's first software developer job, he was able to negotiate a total compensation package of US $250,000 for his first year at Airbnb. He believes negotiation is a skill that can be learned, just like any other. And it isn't particularly elusive or hard to understand. In this episode, he explains how anyone can negotiate effectively. Written and Read by Haseeb Qureshi: https://twitter.com/hosseeb Haseeb's original article: https://fcc.im/2mBOOea Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:  So you’ve maneuvered through the initial offer conversation. You’ve lined up counteroffers from other companies. Now it’s time to enter the actual negotiation. Naturally, this is the part where everything goes horribly wrong. But don’t worry. I’m going to turn you into a superhero negotiator. (Or at least an eccentric billionaire negotiator, which is sometimes better?) Seriously though. In this article, we’re going to deep-dive into the negotiating process, and discuss my final 4 rules on how to negotiate a job offer. If you didn’t read my first 6 rules, you can read them here (or you can just skip ’em and keep reading): Ten Rules for Negotiating a Job Offer When the story of how I landed a job at Airbnb went viral, I was surprised at how infatuated people were with my… What does it take to be a good negotiator? Most people think negotiating well is just looking the other person in the eye, appearing confident, and asking for tons of money. But being a good negotiator is a lot more subtle than that. What Good Negotiators Sound Like You probably have a friend or family member who’s infamous for refusing to take no for an answer. The kind of person who will march into a department store and bullheadedly argue with the management until they get a purchase refunded. This person seems like they often get what they want. They make you cringe, but perhaps you should try to be more like them. Rest assured, this person is actually a terrible negotiator. They’re good at being difficult and causing a scene, which can sometimes convince a waitress or shift manager to appease them. But this style of negotiating will get you nowhere when negotiating with a business partner (that is, an employer). A good negotiator is empathetic and collaborative. They don’t try to control you or issue ultimatums. Rather, they try to think creatively about how to fulfill both your and their needs. So when you think of negotiating a job offer, don’t imagine haggling over a used car. Think more like negotiating dinner plans with a group of friends, and you’ll fare much better. Slicing up the cake Another important difference between good and bad negotiators is that bad negotiators tend to think of a negotiation as a zero-sum game. Imagine we’re negotiating over a cake. In a zero-sum negotiation if I get one more slice, you get one less. Any gain I make comes at your expense. This seems obviously true with cake, right? So what makes a job negotiation any different? Ah, but it’s not actually true for cake. What if I hate corner pieces and you love them? What if I really like the cherries? What if I’m full and you’re starving, but you’ll agree to treat me to my favorite cake next time? Of course, when I posed the question I didn’t mention anything about cherries or my feelings on corner pieces. It might seem like I just made stuff up. But this is exactly what good negotiators do. They bend the rules. They question assumptions and ask unexpected questions. They dig to find the core what everyone values and look for creative ways to widen the terrain of negotiation. While you were thinking about how to haggle over slices, I’m thinking about how to give both of us more than just half of a cake. Different parties in a negotiation almost always have different value functions. We may value the same things — we both care about cake, after all. But we don’t value them in exactly the same way, so there’s probably a way to give each of us more of what we want. Most people go into a job negotiation thinking they need to stubbornly haggle over salary like slices of cake. They don’t ever stop to ask — hey, what do I actually value? Why do I value it? What does the company value? Why do they value that? There are many dimensions to a job negotiation: - salary - signing bonuses - stock - year-end or performance bonuses - commuter benefits - relocation expenses - equipment - an educational stipend - a childcare stipend - extra vacation time - a later start date - getting a dedicated hour a day to work out or study or meditate or play solitaire. You could choose which team you’re assigned to, what your first project will be, what technologies you’ll be working with, and sometimes even choose your title. Maybe you’re a frosting person, and the company is more into cherries. You never know if you don’t ask. Hold onto this mindset. Okay. Let’s pick up the negotiation where we left off. All the offers are in, and recruiters are eagerly waiting for you to get the ball rolling. Let’s start negotiating. Phone VS Email Your first decision is whether you want to negotiate over the phone, or keep correspondence over e-mail. Talking on the phone not only signals confidence, but more importantly, it allows you to build a strong relationship with your recruiter. Talking on the phone enables bantering, telling jokes, and building connection. You want your recruiter to like you, understand you, empathize with you. You want them to want you to succeed. Likewise, you want to care about your recruiter and understand what’s motivating them. The best deals get made between friends. It’s hard to make friends over e-mail. However, if you don’t have confidence in your negotiation skills, you should try to push the negotiation to e-mail. Written, asynchronous communication will give you more time to strategize and make it easier to say uncomfortable things without being pressured by a recruiter. That said, recruiters will always prefer to get you on the phone. It’s essentially their home turf. They’re also well aware that negotiating is easier over e-mail, and they have little interest in making it easier on you. They’ll often be vague about the offer over e-mail and only offer to discuss specific details on the phone. If you want to stick to email, you have to push back against this. There’s no secret to it: just be honest and ask for what you want. Tell them: “Hi recruiter, I hope your day is treating you well! Re: your previous e-mail, I’d prefer to discuss the details of the offer over e-mail. I sometimes get nervous during important phone calls, so discussing the offer over e-mail helps me to keep a clear head and communicate more clearly. I hope this is okay with you. :)” No BS, no huff-puffery. Just telling the truth and asking for what you want. There’s tremendous power in honesty and directness. Take advantage of it. (Also, note how I wrote “discuss the details of the offer” rather than “negotiate.” Never describe what you’re doing as negotiating — that sounds immediately adversarial and haggley. Describe it instead as a discussion, and they’re less likely to recoil.) Having Alternatives I mentioned before how essential it is to have multiple offers. I’ll reiterate again — it’s very, very valuable to have multiple offers. With other offers on the table, if your negotiation doesn’t work out, they know you’ll just accept another offer. Your negotiating position suddenly becomes a lot more credible because they know you’re willing to walk away. This effect is strengthened if you get an offer from a prestigious company. And the effect goes through the roof if you have an offer from a company’s primary competitor (now they’ll really want to poach you from the big bad competitor-corp). Some of this behavior is stupid tribalism. And some part of it is rational in trying to deprive competitors of talent. Either way, take advantage of it, and be tactical in which companies you aim for. But what if you don’t manage to get any other offers? Does all the negotiating just go out the window? Not at all. What’s important here is not actually having other offers. More specifically, it’s in having strong alternatives. Which is why Rule #6 of negotiating is: have alternatives. A negotiation needs stakes. If there were no risk and you knew for sure the other side would sign a contract, what incentive would you have to offer them anything more? Your alternatives are what give a negotiation its stakes. By signaling your alternatives, you allow your interlocutor to develop a mental model of when and why you’ll walk away from the negotiation. Your alternatives also have an anchoring effect on how much the other side thinks you’re objectively worth. In negotiation literature, your best alternative is often referred to as your BATNA (Best Alternative To a Negotiated Agreement). Basically, it’s what you’d do if you walked away. I like the term BATNA a lot, mostly because it sounds like a gadget Batman would lob at bad guys. So what’s your BATNA if you don’t have other offers? Do you even have one? Of course you do. Your best alternative might be “interview at more companies” or “go to grad school” or “stay at your current job” or “go on sabbatical in Morocco for a few months” (as it was for a friend of mine who was deliberating between joining a startup and gallivanting through North Africa). The point is, you don’t need to have another offer to have a strong BATNA. Your BATNA’s strength comes from: - how strong the other side perceives it to be, and - how strong you perceive it to be. If your recruiter thinks that going to grad school is an awesome thing to do, then they’ll see you as having a very strong alternative, and the stakes of the negotiation will be raised. But even if they think grad school is ridiculous — if you convince them that you’d be totally happy to go to grad school — then the burden is on them to make this deal more attractive to you than going to grad school. Thus, you need to communicate your BATNA. This doesn’t need to be ham-fisted, but you need to make it a background to the negotiation. (Note: usually whenever you signal your BATNA, you should also re-emphasize your interest in reaching an agreement). Examples: “I’ve received another offer from [OTHER CORP] that’s very compelling on salary, but I really love the mission of [YOUR COMPANY] and think that it would overall be a better fit for me.” “I’m also considering going back to grad school and getting a Master’s degree in Postmodern Haberdashery. I’m excited about [YOUR COMPANY] though and would love to join the team, but the package has to make sense if I’m going to forego a life of ironic hatmaking.” Note: one of the biggest mistakes I see here is from people who are currently working. If you already have a job, staying where you are is often your BATNA. This means if you tell your interlocutor that you hate your job, then they know your BATNA sucks, and have no incentive to negotiate with you (on top of potentially thinking that you’re a negative person). Always emphasize the pros of your current company, your seniority, your impact, and whatever else you like about where you currently work. You should make your decision seem like a genuinely difficult one — then it will appear to be a strong BATNA. What a Job Negotiation Means to an Employer I’ve kept saying that in order to be an effective negotiator, you need to understand the other side. So let’s take a look at what it’s like to negotiate as an employer. (I’m going to have to use the tech industry in my examples here, but the details will differ by industry.) First, we have to rewind and understand what brought us to this offer in the first place. What kind of resources have they spent so far in trying to fill this position? - Writing and posting a job description on all appropriate channels ($300) - Reviewing ~100 or more resumes ($1,250) - About 15% of those resumes need to be phone screened, so roughly 15 phone screens ($2,250) - Around 75% of those initial phone screens warrant a technical screen, so roughly 11 technical screens ($9,000) - About 30% pass through to an on-site, so roughly 3 onsites. These onsites require the coordination of 6–7 employees ($10,800) - Finally, they make one offer. The recruiter (and potentially the executive staff) need to spend time on the phone with the offeree convincing and negotiating. ($900) Numbers nabbed from here. All-in-all this process took about 45 days from start to finish. Now say you end up turning down their offer. They’ve spent over $24,000 just extending this single offer to you (to say nothing of opportunity costs), and now they’ll essentially have to start over from scratch. This is what a company faces if you turn them down. Realize what a gauntlet they’ve been through! Realize how important it is that you’re the one! Out of the droves and droves who’ve shown up on their doorstep, you’re the one they want. They want to usher you into their tribe. They went through so much crap to get you here, and now they’ve found you. And you’re worried that if you negotiate, they’ll take it away? Further yet, understand that salary is only one part of the cost of employing you. An employer also has to pay for your benefits, your equipment, space, utilities, other random expenses, and employment taxes on top of all of that. All-in, your actual salary often comprises less than 50% of the total cost of employing you. Which means they expect that your value to the company — in terms of the revenue you’ll generate — to be more than 2x your salary. If they didn’t believe that, they wouldn’t be hiring you at all. So, this is all to say: everything is stacked in your favor. It doesn’t feel that way, but it absolutely is. Realize that, while you are agonizing over whether to ask for another few thousand dollars, they’re just praying with bated breath that you’ll sign the offer. If you don’t sign the offer, they lose. Losing a good candidate sucks. No one wants to believe that their company isn’t worth working for. They want to win. They will pay to win. And yet, you might worry: “but if end up negotiating more, won’t they have higher expectations? Won’t my boss end up hating me for negotiating?” No, and no. It’s your role that will determine your performance expectations, not how much you negotiated. Making 5k more or less in salary doesn’t matter at all. Your manager will literally just not care about this. Remember how expensive it is to even employ you in the first place! Nobody’s going to fire you because you’re performing 5K worse than they expected you to. The cost of firing you and hiring someone else is a lot more than 5K to begin with. And no, your boss won’t hate you now. And in fact, at most big companies the person you’re negotiating with won’t even be your boss. Recruiting and management are totally separate departments, completely abstracted from one another. And even if you’re at a startup, trust me that your boss is used to negotiating with candidates and doesn’t place nearly as much significance on it as you do. In short: negotiating is easier and more normal than you think. Companies are completely willing to negotiate with you. If your intuition tells you otherwise, trust that your mental model is wrong. How to Give the First Number In part 1, I mentioned how valuable it is not to have to give the first number. But there are times when you just can’t avoid it. In these situations, there are ways to give the first number without actually giving the first number. If a company asks you “what are your salary expectations?” you might say: “I don’t have any particular numbers in mind. I’m more interested in learning whether this will be a good mutual fit. If it is, I’m open to exploring any offer so long as it’s competitive.” Sounds good. But they push back, “I understand that, but we need to have a clear idea of what you think is competitive. I need to know whether it’s worth going through the interview process. We’re a young startup, so I need to make sure we’re on the same page as far as compensation.” That’s a strong push. But you can still push back. “I completely hear you, and I agree it’s important that we’re on the same page. I really have no particular numbers in my head. It all depends on the fit and the composition of the offer. Once we decide we want to work together, I think that’s the best time to figure out a compensation package that makes sense.” Most employers will relent here. But there’s a small chance they push further: “Okay, look, you’re being difficult. Let’s not waste each other’s time. What’s an offer that you’d be willing to take?” This is a decision point. They’re trying to take away your negotiating power and pin you to a premature decision. That said, you probably will have to say a number at this point, or risk damaging the trust in this relationship. (They are making a valid point that startups can’t offer the same kind of cash as large companies, nor should you expect them to. They might be sensing that you’re not aware of this.) But you can give a number here without actually giving a number. “Well, okay. I know that the average software engineer in Silicon Valley makes roughly 120K a year in salary. So I think that’s a good place to start.” Notice what I did here. I didn’t actually answer the question “what’s an offer you’d be willing to take,” I merely anchored the conversation around the fulcrum of “the average software engineer salary.” So if you’re forced to give a number, do so by appealing to an objective metric, such as an industry average (or your current salary). And make it clear that you’re merely starting the negotiation there, not ending it. How to Ask for More An offer is out there, and now you want to improve it. As always, be direct and ask for what you want. Here are generally the steps you should take. First, reiterate your interest in the company. This is as simple as “I’m really excited about the problems you guys are working on at Evil Corp…” Now frame why you’re asking for more. There are two choices here: you can say that you’re on the fence and that an improvement might convince you, or you can go stronger and say that you’re outright dissatisfied with the offer. Which approach you choose depends on how much leverage you have, how weak the offer is relative to your BATNA, and whether you have other offers (the weaker your negotiating position, generally the more tentative you should be). Either way, be unfailingly polite. If you’re dissatisfied with the offer, you might say something like “I appreciate the work you guys put into constructing this offer. But there were a couple things I was unsatisfied with.” If you want to be more reserved, you can say something like: “The offer you guys extended was strong. Right now my decision is basically between you and [XYZ CORP]. It’s a genuinely difficult decision for me, but there are a couple of dimensions where if this offer improved, it would be much more compelling.” Don’t just say something like “Thanks for the offer. Here are some ways I think it could improve.” This makes you sound like an ass. Be polite, and if you want to strengthen the offer, tell them clearly how you feel about it. This builds trust and conveys seriousness. Let’s say you want to raise the salary. Now that you have a specific ask, it’s time to employ rule #7: proclaim reasons for everything. We all implicitly know the catch-22 of negotiation: if you say you want more salary, you’ll sound greedy. And no one likes greedy people, right? So why would they want to give more money to a greedy person? I suspect this is the primary reason why so many candidates recoil from negotiating. They don’t want to feel greedy. It goes against all of their social conditioning. And yet, there are some situations in which most people would be totally fine negotiating. Specifically, when they have to. If you had to raise your salary or you wouldn’t be able to afford rent, or if you had to negotiate health insurance to cover a medical condition, you’d negotiate without a twinge of regret. The difference? That you have a reason for what you’re requesting. It’s kind of a brain-hack, both for yourself and for your negotiating partner. Just stating a reason — any reason — makes your request feel human and important. It’s not you being greedy, it’s you trying to fulfill your goals. The more unobjectionable and sympathetic your reason, the better. If it’s medical expenses, or paying off student loans, or taking care of family, you’ll bring tears to their eyes. I told employers that I was earning-to-give, so since I was donating 33% of my income to charity, I had tonegotiate aggressively to leave myself enough to live off. But honestly, even if your reason is inane and unimpressive, it will still carry this effect. Just saying “can you improve the salary?” sounds like you’re boringly motivated by money. But if you say “I really want to buy a house within the next year; what can we do to improve the salary?” This suddenly seems a lot more legitimate. If they turn down your request now, they’re implicitly telling you “No, Jennifer, you can’t buy your house. I guess you don’t deserve one.” No one wants to do that. They want to be the one who says, “All right Jennifer, I talked with the director and I made it happen. You’re getting that new house!” (Of course, it goes without saying that you want money so you can spend it on things. I know. It’s stupid. But it works.) Just go with it, state a reason for everything, and you’ll find recruiters more willing to become your advocate. Assert your Value One effective move you can make in a negotiation, especially after an ask, is to emphasize the unique value you’ll be bringing to the company. Example: “Blah blah blah, I want X, Y, and Z. I know that you guys are looking for someone to build out your Android team. I believe I bring a lot of experience leading a team of Android developers and I’m confident that I’ll be able to bring your mobile offerings up to parity with your competitors. Let me know your thoughts.” Be confident without boasting or trying to hold yourself to specific metrics (unless you’re supremely confident). Whatever you assert should be something you’ve touched on earlier in your discussions. But it’s okay to repeat it now as a gentle reminder. It reminds them of the carrot, and shows that you’re still excited to add value. This is not appropriate in every negotiation, especially for very junior positions, where it’s harder to differentiate yourself. But later in your career (or for more specialized/consulting roles) this can be a really valuable nudge. What to Ask For This brings me to rule #8: be motivated by more than just money. Note, this is not code for “if you seem like you’re motivated by more than just money, you’ll get more money.” There is no bigger turn-off to a company than somebody who only cares about money. This is something you’re not going to be able to fake. Actually be motivated by other things. You should be motivated by money, too, of course, but it should be one among many dimensions you’re optimizing for. How much training you get, what your first project will be, which team you join, or even who your mentor will be — these are all things you can and should negotiate. Among these factors, salary is perhaps the least important. What do you really value? Be creative. Don’t try to haggle over slices of cake when there’s so much more on the table. Of course, to negotiate well you need to understand the other side’s preferences. You want to make the deal better for both of you. That’s why rule #9 is: understand what the company values. How do you figure this out? Well, there are a few good rules of thumb. First, salary is almost always the hardest thing to give, for a few reasons: - It must be paid year after year, so it becomes part of a company’s long-term burn rate. - It is almost always the thing that people gossip about, so paying someone significantly more salary can cause unrest. - It tends to be the most tightly constrained by pay bands, especially at large companies. So if you want more financial compensation, you should think about structuring as much of it as possible outside of salary. A signing bonus, for example, is easier to give than salary. A signing bonus has the advantage of only needing to be paid once. It gets the candidate excited about joining (because everyone likes wads of cash), and it’s generally not as public. Remember that you can always get salary raises as you continue to work at the company, but there’s only one point at which you can get a signing bonus. The easiest thing for a company to give though is stock (if the company offers stock). Companies like giving stock because it invests you in the company and aligns interests. It also shifts some of the risk from the company over to you and burns less cash. If you are genuinely risk-neutral or early in your career, then you should generally try to assume as much stock as possible. If you aggressively trade cash for stock, you can end up with a higher expected value offer (albeit with higher risk). A Brief Primer on Equity First, understand there are two completely different classes of companies: public companies and private companies. If the company is public (i.e., it has IPO’d and is listed on the stock market), then its stock is as good as cash. You will usually be granted RSUs (Restricted Stock Units), which are just shares like you can purchase on the stock market. Once these shares vest (that is, are released to you), you can turn around and sell them on the stock market. This is how they turn into money. If the company is private, then things get a lot more complicated. For private companies, most of the time they will not actually issue you stock grants. Usually, they will issue you stock options. An option is a pre-agreed right to purchase shares of stock at a frozen price. It’s important to note that when you want to leave a company, if you have options, your life becomes really complicated. You may have to pay a bunch of money to actually exercise your option (that is, buy your pre-agreed upon stock at the previous frozen price, or risk losing it), with no way to actually sell it yet. The only way to truly liquidate your options is when the company IPOs or is acquired. And many companies don’t ever do this. Thus, options are very risky. It’s easier to get screwed by options, especially on tax implications. For a lot more information, see this post by Scott Kupor of a16z. Equity Shenanigans Many companies will try to play mind games with you when it comes to equity. Several companies pulled these on me. A common one is presenting the total value of the stock grant rather than the annualized value, despite the stock not vesting evenly, or vesting over 5 years instead of the standard 4. But the most egregious thing that companies will do is tell you absurd stories about the value of their stock. They’ll say: “okay, we’re worth this much now, but at the rate we’re growing, we’re going to be worth 10X that in a year. So really, the value of your options is many millions of dollars!” To not mince words: this is cynically dishonest BS. Don’t buy it even for a second. I got this a few times, and the only reason I didn’t walk away from the offer immediately was because it was always a recruiter pulling this crap. If it was a manager I would’ve turned down the offer outright. Here’s why this is infuriatingly stupid: a company’s valuation is determined by investors. These investors see the financials and the growth rate of the company, and invest at a price that reflects the current growth rate of the company. In other words, they invested at a valuation that already took their 10x growth rate into account. Investors are not idiots. And unless you (or your recruiter) think you have privileged information or insight that the company’s investors don’t, you should probably take the investors’ word for it. Also, a company’s nominal valuation is almost always inflated due to preferred shares, debt, and survivorship bias. But let’s ignore that for now. So if a company gives you this hock of crap, fire back and tell them thank you, but you’ll be considering the stock at the same valuation their investors valued it at. I mean, be nice. But don’t let them try to strong-arm you into accepting this garbage. A job is not a suicide pact. Choose a company that is judicious and transparent, and you’ll be much more likely to find yourself respected and taken care of. Other things you can ask for Because I’d be remiss if I didn’t point out a few other things. Relocation expenses often come out of separate budgets at big companies, so this is generally very easy to get. Look for creative benefits that would be particularly valuable to you. Maybe it’s covering your commuter expenses, asking for dedicated volunteer or learning time, getting sponsored for conferences, or even charity donation matching. Don’t assume anything’s off the table until you’ve tried bringing it up. That said, don’t throw the entire kitchen sink at them. A negotiation can quickly become cumbersome for an employer if you bring up a litany of changes. Keep the changeset as pithy as you can. Negotiating Jiu Jitsu Recruiters love trying to trick you into ending the negotiation early. They’re going to do this relentlessly. Don’t fault them for it — I suspect they can’t help themselves. Just keep breaking out of their shenanigans. Don’t let yourself be pressured into ending a negotiation until you’re actually ready to make a final decision. This is especially grave if you have multiple offers, and you let one company pressure you into canceling the others. Companies succeed in doing this all the time, so I want to equip you with the skills to jiu jitsu out of these techniques. Here are two situations you can break out of. These are both real situations that happened to me during my negotiations, though the numbers and details are invented. Situation 1: I ask for a 10K increase in signing bonus. The company gets back to me and says, “That’s really tough for us to do. I’m going to try. I think you’re worth it. But I can’t really go to my boss and fight for you unless she knows you’re going to sign. Are you going to sign if I get you that 10K?” You should be thinking: ah, this person is trying to force me to a decision point and take away my negotiating power. I respond, “Okay, so what I’m hearing is that you’ll have to expend some personal reputation to get me a 10K bonus. If you end up going to bat for me, are you confident you’ll be able to get that 10K?” “I think I can, it just comes down to you Haseeb. If you’re serious about joining us, then I’ll go fight for you. But I need to know for sure you’ll sign.” Great. Time to jiu jitsu. “That makes sense. Unfortunately I can’t commit to signing yet; I’m not yet at the stage where I can make a final decision. Like I told you before, this weekend I’m going to sit down with my family and talk things over with them. Choosing the company I’m going to spend the next few years at is a commitment I take really seriously. So I want to be sure I’m making a well-considered decision. “But since you’re confident that you can get an extra 10K, let’s do this instead: in my mind, I’ll pretend this offer is [X + 10K] and as I’m considering my final decision, that’s where I’ll value it. I know it’s tough for you to go and get that from your boss, so I don’t want you to do that until I’m certain I’m going to sign.” They then vaguely recant and promptly get approval for the 10K bonus. Situation 2: I ask for a 20% increase in stock package. The hiring manager, knowing that I’m negotiating with other companies, then fires back: “I want to get this stock package for you. And I know I can, we’ve got the budget. But before I do that, I need your word on something.” “What’s that?” “I need you to give me your word that if I improve your offer, you’re not going to just turn around and take our counter-offer to [COMPETITOR_COMPANY] to improve your offer with them.” You should be thinking: so basically they’re asking me not to negotiate. “Let me see if I understand what you’re saying. You are willing to improve my offer, but only if I agree that I won’t tell [COMPETITOR] what you’re offering me. Is that correct?” “Well no, I can’t legally do that. What I mean is… what I mean is, look. I like you. But if I improve your offer and you just take our offer to [COMPETITOR], you’ll be violating my trust.” “Okay, let me be sure I understand you here. If you give me this offer and I tell [COMPETITOR], I will be violating the trust under which you’re granting me this improved offer. Is that correct?” “Uhh… Look. How about this. In my mind, I’m going to go get you this stock package okay? And in my head, I’m going to do it with the assumption that you’re the kind of person I think you are, and you’re going to consider our offer in its own right and not just shop it around. Fair enough?” I nod. He gets the improved offer. I continue to negotiate. Antics averted. (In case you’re wondering, if he had said “yes,” I would have turned down the proposal.) The Path to Signing It’s not enough to just continually ask for stuff. Companies need to sense that you’re actually moving toward a final decision, and not just playing games with them. Your goal in a negotiation is not to be difficult or elusive. True, you should assert your value and carefully consider your options, but you can do so in a way that’s respectful and considerate toward the companies you’re talking to. Don’t go dark on people. Be open and communicative. I keep saying be honest and I mean it — be honest. Aside: I keep talking about honesty, and you might protest that this is antithetical to my earlier rule of “protect information.” It’s not. True, you should protect information that might weaken your negotiating position, but you should be as communicative as possible about everything else (which is most things). Negotiating is all about relationship, and communication is the bedrock of any relationship. This brings me to the final rule, Rule #10: be winnable. This is more than just giving the company the impression that you like them (which you continually should). But more so that you must give any company you’re talking to a clear path on how to win you. Don’t BS them or play stupid games. Be clear and unequivocal with your preferences and timeline. If there is nothing that a company could do to sign you, or you don’t actually want to work for them, then don’t negotiate with them. Period. Don’t waste their time or play games for your own purposes. Even if the company isn’t your dream company, you must be able to imagine at least some package they could offer you that would make you sign. If not, politely turn them down. It costs each company money to interview you and to negotiate with you. I didn’t negotiate with every company I received an offer from, but if there was one key mistake I made in my job search, it was that I still negotiated with too many (in large part because I didn’t think my job search would be successful). Making the Final Decision Okay, it’s decision time. (Yes, you do have to make one.) Three things to keep in mind here: - be clear about your deadline - assert your deadline continually - use your final decision as your trump card When you start negotiating, you don’t have to be clear about your timeline because you probably don’t have one yet. But once you get into intermediary stages, you should set for yourself a deadline on which you’ll sign. It can be for an arbitrary reason (or no reason at all), but just pre-committing to a deadline will allow you to negotiate more clearly and powerfully. “A weekend with the family” I found works nicely, as it has the added benefit of roping other decision makers in. Then when companies push you to end negotiations early, you can re-assert this deadline. Companies should all be totally aware of when you’re going to make your decision. This will raise the stakes and galvanize negotiations as the deadline approaches. This deadline also lets you defer your decision while still improving offers. Your narrative should basically be “I want to see the strongest offer your company can muster. Then I will go into my cave, meditate for 10 days, and when I emerge I will have decided in my heart which company to join.” This gives you enormous power to avoid any on-the-spot decision points or premature promises. Eventually, deadline day will come. Try to make this a business day (say, a Friday or a Monday) so that you can communicate with recruiters during this day. If a hail mary is going to happen, it’ll happen here. Even if there’s only one company in the running, you should always always wait until the last day to sign your offer. Yes, even if you’re certain you’re going to sign and even if it’s your dream job. I’ve seen many scenarios in which offers spontaneously improved as deadlines approached, or a fallen player gets up and presents you the holy grail in the 11th hour. Either way, there’s no harm. Finally, your trump card. Save this for the very end. Your trump card is these words: “If you can do X, I will sign.” Note, this is NOT “If you give me X, the offer will be more compelling blah blah blah.” We’re past that. It’s time to make a promise. Every company that’s still on the table, let them know what it would take to sign you (unless there’s nothing they could do). And when you make the final ask, don’t forget reason-giving, even if it’s the same reason as before! “Hi Joel, I’ve been thinking it over and it’s genuinely a really tough decision for me. I loved everyone at [COMPANY] but the one thing that makes it hard for me is the salary. As you know I’m trying to pay off my student loans so salary is really important to me right now. If you can improve the salary by 10K a year, then I’ll be totally ready to sign.” With luck, they meet you half-way. Or, with a little more luck, they’ll meet all of it. And just because I know someone will ask — yes, once say you’re going to sign, you should always sign. Never go back on your word. It’s a small world. People talk. These kind of things will come back to haunt you. (More importantly, never go back on your word because you’re the kind of person who never goes back on their word.) Tell all of the other parties that you’ve made your final decision. Thank them for the negotiation. If you did it well, they’ll usually thank you back, tell you to keep in touch, and to reach out again in a couple years next time you’re on the market. And that’s it. You did it! Congratulations! You’re still alive, right? … You’re not moving. Well, that’s fine. It’s time to celebrate your new job, you beautiful fool! (Drinks are on you.) If you got some value out of this article, share it with a friend who’d benefit from it. Or better yet, follow me on Twitter and I can be your friend. There’s a lot more in the works. Until next time, —Haseeb  

For Haseeb's first software developer job, he was able to negotiate a total compensation package of US $250,000 for his first year at Airbnb. He believes negotiation is a skill that can be learned, just like any other. And it isn't particularly elusive or hard to understand. In this episode, he explains how anyone can negotiate effectively. Written and Read by Haseeb Qureshi: https://twitter.com/hosseeb Haseeb's original article: https://fcc.im/2FiLq0v Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:  When the story of how I landed a job at Airbnb went viral, I was surprised at how infatuated people were with my negotiations. Media stories portrayed me as some kind of master negotiator — a wily ex-poker-player who was able to con the tech giants into a lucrative job offer. This is silly. It’s silly for a lot of reasons, but one of the main ones is that in reality, my negotiation skills are nothing special. There are lots of job candidates who are better negotiators than I, to speak nothing of recruiters and other professional negotiators. It just so happens that most people don’t negotiate at all, or if they do, they negotiate just enough to satisfy themselves that they did. Worse yet, most of the advice out there on negotiation is borderline useless. Almost anything you read on the subject will be a vague and long-winded exhortation to “make sure you negotiate” and “never say the first number.” Beyond those two morsels of advice, you’re pretty much on your own. I thought to myself: why is there so little actionable advice out there about negotiation? I suspect it’s because deep down, many people believe that negotiation is inexplicable, that it’s something some people can do and others can’t, and that there’s no real way to break it down so anyone can learn it. I say that’s BS. Negotiation is a skill that can be learned, just like any other. I don’t believe it’s particularly elusive or hard to understand. So I’m going to try to explain how anyone can do it. Three caveats. First: I’m not an expert. There are people who really are experts at this, and when my advice contradicts theirs, you should assume I’m wrong. Second: negotiation is tricky to generalize about because it’s deeply intertwined with social dynamics and power. The appropriate advice for an Asian male in Silicon Valley may not be appropriate for a black woman in Birmingham, Alabama. Racial, sexual, and political dynamics accompany you to the negotiating table. At the same time, I want to caution against overemphasizing these factors. Being afraid to negotiate out of fear of discrimination can often be just as deleterious as discrimination itself. Ceteris paribus, negotiate aggressively. Third: I’m the first to admit that negotiation is stupid. It’s a practice that inherently benefits those who are good at it, and is an absurd axis on which to reward people. But it’s a reality of our economic system. And like most collective action problems, we’re probably not going to be able to abolish it any time soon. In which case, you might as well improve at it. So here’s my guide to negotiation. It’s going to be split into two parts: this first part will be about conceptualizing the negotiating process, about how to begin the process and set yourself up for maximal success. The second part will be advice on the actual back-and-forth portion of negotiating and how to ask for what you want. Let’s take it from the top. What it means to “get a job” In our culture we call entering the employment market “trying to get a job.” This is an unfortunate turn of phrase. “Getting a job” implies that jobs are a resource out in the world, and you’re attempting to secure one of these resources. But that’s completely backwards. What you are actually doing is selling your labor, and a company is bidding for it. Employment is just striking a mutual deal in the labor market. Like any market, the labor market only functions well if it’s competitive. This is the only way to ensure fair and equitable pricing. Imagine you were a farmer selling watermelons. Would you just sell your watermelons to the first buyer who agreed to purchase them? Or would you survey the marketplace of buyers, see the best price (and business partner) you could get, and then make an informed decision on which buyer to sell to? And yet, when people talk about the labor market, they think “oh, a company wants to give me a job! What a relief!” As though having a job were in itself some special privilege for which a company is the gatekeeper. Dispel yourself of this mindset. A job is just a deal. It is a deal between you and a company to exchange labor for money (and other things you value). This might sound like an abstract point, but you should absolutely approach negotiation from this perspective. The role of negotiation Negotiating is a natural and expected part of the process of trying to make a deal. It’s also a signal of competence and seriousness. Companies generally respect candidates who negotiate, and most highly attractive candidates negotiate (if for no other reason, because they often have too many options to choose from). At the risk of spouting truisms: always, always negotiate. It doesn’t matter how good or bad you think you are. You never damage a relationship by negotiating. In all my time as an instructor at App Academy, out of hundreds of offers negotiated, only once or twice were offers ever rescinded in negotiations. It basically never happens. And when it does, usually the candidate was being an unconscionable asshole, or the company was imploding and needed an excuse to rescind the offer. You might think to yourself: “well, I don’t want to set high expectations, and the offer is already generous, so I ought to just take it.” No. Negotiate. Or maybe: “I don’t want to start off on the wrong foot and look greedy with my future employer.” No. Negotiate. “But this company is small and — “ No. Shut up. Negotiate. We’ll talk more in the next section about why a lot of these objections are BS, and fundamentally misapprehend the dynamics of hiring. But for now, just trust me that you should always negotiate. The ten rules of negotiating I’ve tried to boil down negotiation to ten rules. The rules, in order of appearance, are: - Get everything in writing - Always keep the door open - Information is power - Always be positive - Don’t be the decision maker - Have alternatives - Proclaim reasons for everything - Be motivated by more than just money - Understand what they value - Be winnable We’ll only get through some of these in this blog post, and the rest will appear in the second part. But I’ll explain each rule as we get to it. So let’s start from the top and try to walk through a negotiation process from the very beginning. For most, that starts when you receive an offer. The offer conversation You’ve just received the phone call: your interview went well, and after much deliberation they decided they like you. They want to make you an offer. Congratulations! Don’t get too excited though. The fun is just getting started. Thank your recruiter. Sound excited — hopefully this won’t be hard. Before jumping into details, try to ask for specific feedback on your interview performance. If they give it to you, this will help you gauge how much they want you, as well as tell you things you can improve on in your next interview(s). Now time to explore the offer. Rule #1 of negotiating: have everything in writing. Eventually, they’ll give you information about the offer. Write it all down. Doesn’t matter if they’re going to send you a written version later, write everything down. Even if there are things that are not directly monetary, if they relate to the job, write them down. If they tell you “we’re working on porting the front-end to Angular,” write that down. If they say they have 20 employees, write that down. You want as much information as you can. You’ll forget a lot of this stuff, and it’s going to be important in informing your final decision. Depending on the company, they’ll also tell you about the equity package. We’ll look more specifically at equity in part II, but be sure to write everything down. The rule from here on out is that everything significant you discuss will have some kind of a paper trail. Often, the company won’t even send you an official offer letter until a deal is finalized. So it falls to you to confirm all of the important details in subsequent e-mails. So yadda yadda, lots of details, writing stuff down, oh there’s a joke, time to laugh. Now the recruiter is done talking and you’re done asking all of your questions. Your recruiter will now say something along the lines of “so what do you think?” This seems innocuous, but your reply here is critical, because there’s a lot you can say to weaken your position. This is your first decision point. A decision point is a moment in the negotiation where your interlocutor wants to compel you to make a decision. If they succeed in tying you to a position, they will close the door on further negotiating. Of course “what do you think?” is a subtle prod. But it is the beginning of many attempts to get you to make a premature commitment. This leads to rule #2 of negotiating: always keep the door open. Never give up your negotiating power until you’re absolutely ready to make an informed, deliberate final decision. This means your job is to traverse as many of these decision points as possible without giving up the power to continue negotiating. Very frequently, your interlocutor will try to trick you into making a decision, or tie you to a decision you didn’t commit to. You must keep verbally jiu-jitsu-ing out of these antics until you’re actually ready to make your final decision. Protecting information There’s an uncomfortable silence by now, and their “what do you think?” is hanging in the air. If you say “yes, that sounds amazing, when do I start?” you implicitly accept the offer and completely close the door on the negotiation. This is your recruiter’s number one favorite thing to hear. It stands to reason you probably shouldn’t do this. But their second favorite thing to hear you say is “can you do 90K instead of 85K?” This also closes the door, but for a different and more subtle reason. And it’s the number one reason why most people suck at negotiation. Rule #3 of negotiating: information is power. To protect your power in the negotiation, you must protect information as much as possible. A company doesn’t give you insight into what it’s thinking. It doesn’t tell you its price range, how much it paid the previous candidate with your experience, or anything like that. It intentionally obfuscates those things. But it wants you not to do the same. A company wants to be like a bidder in a secret auction. But unlike the other bidders, it wants to know exactly how high all of the other bids are. It then openly intends to exploit that knowledge, often by bidding one cent more than the second highest bid. Yeah, no. Screw that. It’s a silent auction, and to keep it that way, you must protect information. In many situations, the only reason why you have any negotiating power at all is because the employer doesn’t actually know what you’re thinking. They might not know how good your other offers are, or how much you were making in your last job, or how you weigh salary vs equity, or even how rational you are as a decision-maker. Bottom line, you want them to be uncertain on exactly what it would take to sign you. When you say “can you do 90K instead of 85K,” you’ve told them exactly what it will take to make you sign. The sheet’s pulled back, the secret auction is up, and they’re going to bid 90K (or more likely, 87K). And they know there’s almost no risk in doing so, because you’ll probably accept. What if you were the kind of person who wouldn’t even consider an offer below 110K? Or the kind of person who wouldn’t consider an offer below 120K? If you were, you wouldn’t ask for 90K, and if they offered it as conciliation, you’d tell them to stop wasting your time. By staying silent, they don’t actually know which of those kinds of people you are. In their mind, you could be any of the three. A corollary of this rule is that you should not reveal to companies what you’re currently making. There are some exceptions, but as a rule you should assume this. If you must divulge what you’re making, you should be liberal in noting the total value of your package (incorporate bonuses, unvested stock, nearness to promotion etc.), and always mention it in a context like “[XYZ] is what I’m currently making, and I’m definitely looking for a step up in my career for my next role.” Companies will ask about your current compensation at different stages in the process — some before they ever interview you, some after they decide to make you an offer. But be mindful of this, and protect information. So given this offer, don’t ask for more money or equity or anything of the sort. Don’t comment on any specific details of the offer except to clarify them. Give away nothing. Retain your power. Say instead: “Yeah, [COMPANY_NAME] sounds great! I really thought this was a good fit, and I’m glad that you guys agree. Right now I’m talking with a few other companies so I can’t speak to the specific details of the offer until I’m done with the process and get closer to making a decision. But I’m sure we’ll be able to find a package that we’re both happy with, because I really would love to be a part of the team.” Think like the watermelon farmer. This offer is just the first businessman who’s stopped by your watermelon patch, glanced over your crops, and announced “I’ll take all of these right now for $2 a melon.” Cool. It’s a big market, and you’re patient — you’re a farmer after all. Just smile and tell them you’ll keep their offer in mind. And this is super important: always be unequivocally positive. The importance of positivity Staying positive is rule #4 of negotiation. Even if the offer sucks, it’s extremely important to remain positive and excited about the company. This is because your excitement is one of your most valuable assets in a negotiation. A company is making you an offer because they think you’ll do hard work for them if they pay you. If you lose your excitement for the company during the interview process, then they’ll lose confidence that you’ll actually want to work hard or stay there for a long time. Each of those makes you less attractive as an investment. Remember, you are the product! If you become less excited, then the product you’re selling actually loses value. Imagine you were negotiating with someone over buying your watermelons, but the negotiation took so long that by the time you’d reached an agreement, your watermelons had gone bad. Companies are terrified of that. They don’t want their candidates to go bad during a negotiation. Hence why they hire professional recruiters to manage the process and make sure they remain amicable. You and the recruiter share the same interest in that regard. If a company feels like you’ve gone bad, suddenly they’re a lot less willing to pay for you. So despite whatever is happening in the negotiation, give the company the impression that 1) you still like the company, and that 2) you’re still excited to work there, even if the numbers or the money or the timing is not working out. Generally the most convincing thing to signal this is to reiterate you love the mission, the team, or the problem they’re working on, and really want to see things work out. Don’t be the decision-maker You can wrap up the conversation now by saying: “I’ll look over some of these details and discuss it with my [FAMILY / CLOSE_FRIENDS / SIGNIFICANT_OTHER]. I’ll reach out to you if I have any questions. Thanks so much for sharing the good news with me, and I’ll be in touch!” So not only are you ending the conversation with the power all in your hands, but note there’s another important move here: you’re roping in other decision-makers. Rule #5 of negotiation: don’t be the decision-maker. Even if you don’t particularly care what your friends/family/husband/mother thinks, by mentioning them, you’re no longer the only person the recruiter needs to win over. There’s no point in them trying to bully and intimidate you; the “true decision-maker” is beyond their reach. This is a classic technique in customer support and remediation. It’s never the person on the phone’s fault, they’re just some poor schmuck doing their job. It’s not their decision to make. This helps to defuse tension and give them more control of the situation. It’s much harder to pressure someone if they’re not the final decision-maker. So take advantage of that. Okay! We have our first offer. Send a follow-up e-mail confirming all of the details you discussed with your recruiter so you have a paper trail. Just say “just wanted to confirm I had all the details right.” Groovy. Next step is to leverage this to land other offers and find the best deal we can find in the job market. Getting other offers Turns out, it doesn’t matter that much where your first offer is from, or even how much they’re offering you. Just having an offer in hand will get the engine running. If you’re already in the pipeline with other companies (which you should be if you’re doing it right), you should proactively reach out and let them know that you’ve just received an offer. Try to build a sense of urgency. Regardless of whether you know the expiration date, all offers expire at some point, so take advantage of that. “Hello [PERSON], I just wanted to update you on my own process. I’ve just received an offer from [COMPANY] which is quite strong. That said, I’m really excited about [YOUR AMAZING COMPANY] and really want to see if we can make it work. Since my timeline is now compressed, is there anything you can do to expedite the process?” Should you specifically mention the company that gave you an offer? Depends. If it’s a well-known company or a competitor, then definitely mention it. If it’s a no-name or unsexy company, you should just say you received an offer. If it’s expiring soon, you should mention that as well. Either way, send out a letter like this to every single company you’re talking to. No matter how hopeless or pointless you think your application is, you want to send this signal to everyone who is considering you in the market. Second, if there are any other companies you are looking to apply to (whether through referral or cold application), or even companies at which you’ve already applied but haven’t heard back, I would also follow up with a similar e-mail. So why do this? Isn’t this tacky, annoying, or even desperate? None of the above. It is the oldest method in history to galvanize a marketplace — show that supplies are limited and build urgency. Demand breeds demand. Not every company will respond to this, but many will. Isn’t it stupid that companies respond to this though? Why companies care about other offers When I wrote about the story of my own job search, I mentioned how having an offer from Google made companies turn around and expedite me through their funnels. Many commentators lamented at the capriciousness of these companies. If Uber or Twitch only talked to me because of Google and until then weren’t willing to look at me, what did that say about their hiring processes? What legitimately are they evaluating, if anything at all? I think this response is totally backwards. The behavior of tech companies here is actually very rational, and you would do well to understand it. First, you must realize what a company’s goal is. A company’s goal is to hire someone who will become an effective employee and produce more value than their cost. How do you figure out who will do that? Well, you can’t know for certain without actually hiring them, but there are a few proxies. Pedigree is the strongest signal; if they did it at other companies, they can probably do it at yours. And if someone trusted within the organization can vouch for them, that’s often a strong signal as well. But turns out, almost everything else is a weak signal. Weak in the sense that it’s just not very reliable. Interviews, if you think about it, are long, sweaty, uncomfortable affairs that only glancingly resemble actual employment. They’re weird and can’t tell you that much about whether an individual will be good at their job. There’s no way around this. There are a few stronger signals, like bringing someone in for a week or two on a contract-to-hire position, but strong candidates won’t consider this. So candidates as a whole have effectively forced companies to assume almost all of the risk in hiring. The truth is, knowing that someone has passed your interview just doesn’t say that much about whether they’ll be a good employee. It’s as though you knew nothing about a student other than their SAT score. It’s just not a lot of data to go off. Nobody has solved this problem. Not Google nor anyone else. And this is precisely why it’s rational for companies to care that you’ve received other offers. They care because each company knows that their own process is noisy, and the processes of most other companies are also noisy. But a candidate having multiple offers means that they have multiple weak signals in their favor. Combined, these converge into a much stronger signal than any single interview. It’s like knowing that a student has a strong SAT score, and GPA, and won various scholarships. Sure, it’s still possible that they’re a dunce, but it’s much harder for that to be true. This is not to say that companies respond proportionally to these signals, or that they don’t overvalue credentials and brands. They do. But caring about whether you have other offers and valuing you accordingly is completely rational. So this is all to say — tell other companies that you’ve received offers. Give them more signal so that they know you’re a valued and compelling candidate. And understand why this changes their mind about whether to interview you. As you continue interviewing, remember to keep practicing your interview skills. The single strongest determinant of your final offer will be the number and strength of offers that you receive. Some advice on timing You want to be strategic about the timing of your offers. Generally, you should try to start interviewing at larger companies earlier. Their processes are slower and their offer windows are wider (meaning they allow you more time to decide). Startups are the other way around. Your goal should be to have as many offers overlapping at the same time as possible. This will maximize your window for negotiating. When you receive an offer, often the first thing you should ask for is more time to make your decision. Especially in your first offer, more time is by far the most valuable thing you can ask for. It’s time that enables you to activate other companies and end up with the strongest possible offer. So be prepared to fight for time. How to approach exploding offers Hoo boy. Exploding offers are offers that expire within 24–72 hours. You won’t see this much at big companies, but they’re becoming increasingly common among startups and mid-sized companies. Exploding offers suck, and I share most people’s disdain for this practice. But I do understand it. Exploding offers are a natural weapon for employers to combat a strong hiring market for tech workers. Companies know exactly what they’re doing with exploding offers — they play on fear and limit your ability to seek out counteroffers. In a sense, it’s unsurprising that if startups have more difficulty attracting and securing talent, they’d resort to this practice. What I don’t like is the dishonesty about it. Employers often justify this by saying: “If you need more time than this, then that’s a sign you’re not the kind of person we’re looking for.” Please don’t buy this crap or feel guilty over it. They’re simply doing this to improve their chance of closing candidates. Needing more than three days to make a life decision isn’t a sign of anything other than thoughtfulness. So what should you do if you receive an exploding offer? Exploding offers are anathema to your ability to effectively navigate the labor market. Thus, there is only one thing to do. Treat the offer as a non-offer unless the expiration window is widened. In no uncertain terms, convey that if the offer is exploding, it’s useless to you. Example conversation: “I have one big concern. You mentioned that this offer explodes in 48 hours. I’m afraid this doesn’t work at all for me. There’s no way that I can make a decision on this offer within a 48 hour window. I’m currently wrapping up my interview process at a few other companies, which is likely to take me another week or so. So I’m going to need more time to make an informed decision.” If they push back and say this is the best they can do, then politely reply: “That’s really unfortunate. I like [YOUR COMPANY] and was really excited about the team, but like I said, there’s no way I can consider this offer. 48 hours is just too unreasonable of a window. The next company I join will be a big life decision for me, and I take my commitments very seriously. I also need to consult with my [EXTERNAL_DECISION_MAKER]. There’s no way that I can make a decision I’m comfortable with in this short an amount of time.” Pretty much any company will relent at this point. If they persist, don’t be afraid to walk away over it. (They probably won’t let that happen, and will come grab you as you’re walking out the door. But if they don’t, then honestly, screw ‘em.) I was given several exploding offers during my job search. And every time, I did essentially this. Every single offer immediately widened to become more reasonable, sometimes by several weeks. I want to emphasize, lest I be misunderstood here — what I’m saying is not to just silently let an exploding offer expire, and assume that everything will be fine and they’ll still hire you. They won’t. For exploding offers to be a credible weapon, a company has to have a reputation of enforcing them. I’m saying explicitly call this out as an issue when they make the offer. Don’t let a company bully you into giving away your negotiating power. The Negotiating Mindset Before we enter into the actual back-and-forth, I want to examine the mindset you should have as a negotiator. This applies not just to how you approach the conversation, but also to how you think about the company. Do not fall into the trap of valuing companies solely along one dimension. That means don’t just value companies based on salary, equity, or even on prestige. Those are all important dimensions, but so are cultural fit, the challenge of the work, learning potential, later career options, quality of life, growth potential, and just overall happiness. None of these inherently trump any of the other. Anyone who tells you “just choose wherever you think you’ll be happiest” is being just as simplistic as someone who says “just choose the one that offers the most money.” All of these things matter, and your decision should be genuinely multi-dimensional. Be open to being surprised as you explore different companies. It’s also important to understand that companies don’t all value you along the same dimension either. That is, different companies are genuinely looking for different skills, and there are some companies at which you will be more and less valuable. Even at peer companies this is true, especially so if you have a specialized skill-set. The more companies you talk to, the more likely you are to find a company to which you are significantly more valuable than the rest. Chances are this is where you’ll be able to negotiate your strongest offer. It might surprise you which company this turns out to be; keep an open mind, and remember that a job search is a 2-sided process. One of the most valuable things you can do for yourself in this process is to really try to understand how employers think and what motivates them. Understanding your interlocutor is extremely important in negotiation, and we’ll be exploring that a lot in the next blog post. But most of all I want to emphasize: be curious about the other side. Try to understand why employers think the way they do. Be sympathetic toward them. Care about what they want and help them try to get it. Adopting this mindset will make you a much stronger negotiator, and accordingly, a much better employee and team member. Okay. That’s as far as we’re going for today. In the next blog post, I’m going to cover the last four rules of negotiation. I’ll also go over the actual back-and-forth process — how to ask for what you want, how to strengthen offers, and how to dismantle the tricks that companies will try to pull on you. Also a lot more on the theory of negotiation, which I really dig.

Roger explains why everyone should learn to code, even if they don't intend to go pro. "Learning something difficult, however, is beneficial in and of itself. The process is the prize. Struggling with code, while frustrating, is medicine for the mind." Written and Read by Roger Collier: https://twitter.com/RogerAFCollier Original article: https://fcc.im/2keLLrU Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:  It was far past midnight. My wife and kids had long gone to bed. But sleep was not an option for me. I had to figure it out. So I tweaked the code again, for the googolth time, and hit run. Hmm, looks promising. If I click here, the program should call the “compute next move” function. Yes. And if I click here, that function should call itself. Good. Now, if I click here, I should get…not that. Argh. More tweaks. More errors. More hours tick by. Learning programming is hard, I thought. My next thought? Yes, and that’s why I like it. How programming became my hobby I began to learn how to code using JavaScript four months ago, starting with freeCodeCamp’s front-end curriculum. For me, programming became a hobby. Over the past few years, I had become disappointed with my creation-to-consumption ratio. Too much of my free time was spent consuming. Netflix, podcasts, Twitter, magazines, televised sports, Facebook, blogs, Medium, newspapers, novels — the list goes on. There is nothing wrong with any of these activities, but they are all pure input. Even reading a great book is an act of consumption. Sure, I was generating plenty of output in my job as a journalist, but I could no longer accept the fact that hard work was something I did only when it would result in a paycheck. With a family and a career and other obligations, I had only so much free time. I was spending far too much of it scarfing down media. And I felt like a pig. So far, my programming hobby hasn’t result in all that much output. I made one simple app, which I wrote about in a previous article. I’ve completed all the front-end challenges and projects on freeCodeCamp. But it’s a start. My goal is not to create amazing things to impress people. It is simply to immerse myself in the act of creation, to challenge myself, to attempt something difficult — if for no other reason than to finish it. Harder is better In my home province — Ontario, Canada — there is a movement to improve physical health called Make Your Day Harder. The basic premise is that making small tweaks to daily routines to increase physical activity can add up and improve health. Take the stairs instead of the elevator. Get off the bus one stop before your destination. Take the parking spot farthest away from the entrance at work. I couldn’t agree more. Those elevator-hating far-parkers are onto something. Of course, sitting in front of a computer writing code isn’t going to improve your physical health. JavaScript is great for building apps, not abs. I don’t think it’s too much of a stretch, though, to suggest that learning how to program is healthy for your brain. Healthier, at least, than bingeing Iron Fist or thumbing through celebrity Instagram accounts. For me, even after I started coding, the default during downtime is still too often leisure. This month, for instance, I have already spent dozens of hours watching genetic outliers throw a ball at a metal ring. This is otherwise known as the NBA playoffs. Since I’m a Toronto Raptors fan, you could also call it self-induced torture. Does watching so much basketball — alone, in my basement — benefit me in any way? Well, I drink more beer when I watch sports. I eat more nachos and wings and potato chips. Mike and Ikes have made several appearances. Oh, and I often stay up late to watch the West Coast games, so I’m getting less sleep. In other words, watching sports, for me, is a vice. I enjoy it, but it’s actually bad for me. It provides me with entertainment, but nothing else. Except for love handles and the occasional mid-afternoon yawn attack. But it’s easy. It’s oh so easy. Plop on couch. Crack open Corona. Kick up your feet. Sit there for three hours. The easy path is more tempting. The difficult path is more rewarding. Embracing difficulty I was again reminded of the value of embracing difficulty while watching the movie Hidden Figures. The film featured an excerpt of John F Kennedy’s “We choose to go to the moon” speech. The United States pursued space travel not despite it being difficult, the president declared, but rather because it was difficult. “We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.” — John F Kennedy The words “hard” and “difficult” are often used to describe something negative. In many cases, that’s appropriate. It is hard to watch a loved one fall ill and suffer. It is difficult when a relationship fails or a pet dies. Some situations are all pain, no profit. Learning something difficult, however, is beneficial in and of itself. The process is the prize. Struggling with code, while frustrating, is medicine for the mind. If you happen, along the way, to create something amazing and users flock to your app with open wallets, that’s great. If not, code anyway. If you master JavaScript and become a YouTube guru with more subscribers than the New York Times, that’s great. If not, code anyway. Many people learn programming to attain a specific goal. Perhaps your job is boring and you want a more challenging one. Nothing wrong with that. Maybe you want to break into tech because you need a higher income to support your family. Hey, someone has to buy the bagels and flip flops, and keep the WiFi pumping. But you don’t need an endgame in mind to start your coding journey. Just begin. And if that journey becomes difficult, don’t despair. It means you’re on the right path. The hard one.  

Genius is a fickle beast. Sometimes you have the good fortune to work with a mad genius. Other times you are doomed to work with pure madness. There are also times when it is hard to tell the difference. In this episode we explore "brilliant jerks" and how to save your development team from them. Written and Read by: Jonathan Solórzano-Hamilton Follow him on Twitter: https://twitter.com/jhsolor His full article on freeCodeCamp's Medium publication: https://fcc.im/2BAhnm6 Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02   Transcript: “You will never be able to understand any of what I’ve created. I am Albert F***ing Einstein and you are all monkeys scrabbling in the dirt.” And so our resident genius, our Dr. Jekyll, explosively completed his transformation into Mr. Hyde. He declared this in front of the product design team, developers, management, and pre-launch customers. One of our project sponsors had the temerity to ask when the problem crippling our product would be fixed. Genius is a fickle beast. Sometimes you have the good fortune to work with a mad genius. Other times you are doomed to work with pure madness. There are also times when it is hard to tell the difference. This story is about the fall from grace of an extremely gifted team member with a deep understanding of our product’s architecture. He had an uncanny ability to forecast future requirements, and a ton of domain-specific knowledge. He was our top contributor. He was killing our flagship project. We’ll call this person “Rick.” Rick was universally recognized on the team as the top talent. He was the lead developer and architect of our software projects. Any time anyone had a question about code or needed help with a task, they would go to Rick. Rick had a giant whiteboard installed in his office used only for this purpose. It was always cluttered with the ghosts of past discussions that wouldn’t quite erase. Any time there was a particularly challenging problem, Rick would handle it. Rick had a server with the same specs as our production server installed at his desk. He used this to run the entire application stack independently and troubleshoot every layer at once. Rick didn’t need anybody else. Rick preferred to work alone in his private work-space. Rick didn’t need anything anybody else built. He built everything he needed from scratch because it was infinitely better than the paltry offerings of mere mortals. Soon, Rick stopped attending meetings. Rick didn’t have time for meetings any more because there was too much to code. Rick closed his door. His whiteboard lay fallow. Rick no longer had time to train anyone because he had too much to solve on his own. A backlog grew behind Rick. Bugs were popping up in old tools he’d built. They sapped his attention from meeting commitments on new product development. Of course, these bugs were happening because the users had misstated their assumptions. Of course there wasn’t any problem in his work. Of course. On our project dashboard, green flags changed to yellow. Yellow changed to red. Red lights started blinking. One by one, task statuses changed to “Impeded.” Everyone was waiting for Rick. The project manager got a six-month extension from the sponsor. At the end of the six months, production-readiness was estimated to be seven months away. At the end of a year, production-readiness was two years out. Rick was churning out code faster than ever. He was working seven-day weeks, twelve hours a day. Everyone knew only Rick could pull the team out of this mess. Everyone held their breath and waited for Rick to invent the miracle cure that would mend this crippled project. Every day, Rick grew more belligerent and isolated. The mask was coming off. Jekyll was becoming Hyde. I participated in my first meeting with the project team about two years after the original agreed release date. I’d been aware of the project for a while, because it had grown infamous in my organization, but hadn’t been assigned to it. I was sent in to see if we could save it. My first meeting on the project was the aforementioned “Albert Einstein” meeting. Hmm. I dove into the source code. Rick was right: no-one could possibly understand what Rick had created. Except for Rick. It was a reflection of the workings of his own mind. Some of it was very clever, a lot of it was copy-pasta, it was all very idiosyncratic, and it was not at all documented. I went to our CIO with the verdict. Only Rick would ever be able to maintain this product. Plus, every day that Rick worked on the project moved the delivery date back a week. Rick was destroying our product faster than he was creating it. We sat down with Rick and had a conversation about his role in the project. We reviewed our concerns. We sidestepped his self-comparison to Albert Einstein. We explained our new strategy. The team was going to collaborate on building a new product from scratch. This effort would be very limited in scope and would only provide the bare essentials to get us to production. The whole team would contribute and be able to support it. No more bottlenecks. How did Rick react to this? The only way Rick could. Rick exploded. Rick wanted no part of this farce. If we couldn’t appreciate his genius, that was our fault, not his. Rick predicted that within months we’d come crawling back to him begging him to save us. Rick screamed that we lacked the basic mental capacity to appreciate genius when it was staring us in the face. Sadly, after this, Rick rejected months of overtures by leadership. He refused to take time off or allow any work to be delegated. He rejected repeated attempts to introduce free open source frameworks to replace his hard-to-maintain bespoke tools. He reverted code changes — including tested bug fixes — by other developers. He asserted that he wouldn’t be held accountable for supporting other people’s work. He continued publicly belittling his colleagues. We fired Rick. It took about a week for the dust to settle. It took time for the shocked team to gather themselves after losing their embattled guru. Then I saw them huddled around a whiteboard. They collaborated. They designed a replacement product. It would be much simpler. It wouldn’t have all the bells and whistles. Nor would it anticipate requirements from five years down the product road map. Rick’s product supported a dynamic workflow with over fifteen thousand permutations. In reality 99% of our use cases followed one of three paths. The team hard-coded the workflow. This removed over 30% of Rick’s work. It wouldn’t have custom hand-coded components for every task. They stripped out every bespoke dependency that they could buy instead of build. This removed hundreds of hours of Rick’s contribution. But it also removed thousands of hours of technical debt. We obtained an agreement from the project sponsor to shut off some edge-case functionality. This had served only 5% of our pre-launch user group and was responsible for about a quarter of the product’s complexity. We re-released the product to this group. It consisted of 10% of Rick’s original code which was pretty stable. It also had a few thousand lines of new code to replace about 150,000 lines of incomprehensible mess. The team had replaced five years of work in about six months. Over the next few months we expanded from pilot to full customer release. Not only had we replaced what Rick had built, we sped past him and fully launched the product — all in under a year. The result was less than a fifth the size and complexity of what Rick had built. It was also hundreds of times faster and nearly bug-free despite having been assembled in a fraction of the time and serving ten times as many customers. The team went back to Rick’s other products. They threw away his old code there, too. They re-released another product of his after three years in development, with three months of concerted team effort. There were no Ricks left on the team. We didn’t have any mad geniuses building everything from scratch. But our productivity was never higher. Rick was a very talented developer. Rick could solve complex business logic problems and create sophisticated architectures to support his lofty designs. Rick could not solve the problem of how to work effectively on a team. Rick’s presence was destructive in several ways. First, he created a cult of dependence. Any problem eventually became a Rick problem, a myth he encouraged. Developers learned to stop trying and just wait for Rick. Second, he didn’t write maintainable code. He never documented or tested anything, and so failed in spite of his own intelligence. His belief in his personal infallibility trumped common sense. Third, he was personally destructive. Team members didn’t want to speak up and offer their own ideas because he always berated them for it. Rick only respected Rick and went out of his way to make everyone else feel small. Fourth, he lacked all personal accountability. No failure was his fault. He sincerely believed this, and it prevented him from learning from his own mistakes. I don’t believe Rick started out this way. I saw him at his worst. This was after years of working escalating overtime and facing increasing criticism from customers and colleagues. It’s sad that Rick descended this far. His manager shares in this responsibility. In fact, the original management team was held accountable: they were let go first. Unfortunately Rick was so far gone that he couldn’t, or wouldn’t, be brought back. No amount of coaching, feedback, time off, or assignment to other projects changed his toxic behavior. By this point the whole team knew he was destructive. But the cult of dependence was so strong that everyone believed he was the only option. There is always another option. Your team’s strength is not a function of the talent of individual members. It’s a function of their collaboration, tenacity, and mutual respect. Focus on building teams that value each other and try to bring the best out of one another. Together, they’ll be able to tackle greater challenges than Rick could ever fathom. I have published a follow-up story with our lessons learned if you are interested in reading more! You may also be interested in reading about my first job at a startup, which happened to be imploding around me. You can follow me here or on Twitter @jhsolor for more updates. Note: Some details (such as names) have been changed. I’ve never actually worked with anyone named Rick.

Madison tells her story of how she went from being a fashion model with no college degree to full-time software engineer in just one year. She used free online resources including freeCodeCamp, and worked for free at a startup until they hired her. Written and read by Madison Kanna: https://twitter.com/MadisonKanna Article link: https://fcc.im/2ApFnXO Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Resources mentioned: https://discoverpraxis.com https://www.freecodecamp.org https://www.udacity.com https://frontendmasters.com/ Transcript: In 2015 I knew almost nothing about coding. Today, I’m a software engineer and a teacher at a code school for kids. When people find out I work as an engineer, they often ask, “How can I get a job as a software engineer coming from a nontraditional background?” Well, you can’t get more nontraditional than me. I was homeschooled growing up, and I’m a college dropout. When I dropped out, I signed with an agency and modeled for fashion brands. I didn’t know what I wanted to do with my life, but my sister was a software engineer and she loved it. So one day, I took Udacity’s “Intro to Computer Science” course. And I loved it. Coding became my biggest passion. I knew I would become a software engineer. I also knew it might be the hardest thing I ever did. But I resolved to see it through. I was going to make this happen. If you love to code, and keep working toward your goal of becoming a developer, you will get there — no matter where you come from. Here’s how I did it. Figured out how you learn best. After months of teaching myself to code, I knew I needed that next step, so I applied to several coding bootcamps. Yet I realized that I learn best not by studying, but when I am working. Figuring out how I learn most efficiently was a huge help. For you, maybe you need to immerse yourself fully at a bootcamp, or take a part-time online program. For me, I realized I would learn best by jumping headfirst into an engineering internship. But… how could I get one? Build your personal brand. I knew I wanted real-world experience. So I enrolled in Praxis, a program that places young people into apprenticeships at startups. But Praxis focuses on marketing and sales roles, and I was determined to become an engineer. So, I decided to find myself an engineering internship and use Praxis to help me build my personal brand to increase my chances of being hired. I worked with Simon from Praxis, who helped me prepare for interviews and create my online presence. My mom, an entrepreneur and brand expert, encouraged me to blog about coding, speak at meetups, start a YouTube channel, and continue to build my GitHub portfolio. I kept sharing whatever I was learning about. Eventually, when you Googled me you could immediately see that I was passionate about coding. Google yourself. What do you see? Work for free and love the work. While originally I had hoped to get a paying internship, I quickly realized I had a better chance of getting experience as an engineer if I did free work. I found a startup I wanted to work for and pitched myself to them: I’d work for for free as an engineering dev for a few months. Then they could either promote me or let me go depending on how I did. They agreed, and I spent the next few months working harder than I ever have. I relished every moment I spent just fixing one little bug in the app. Later on, I realized that although I didn’t have a ton of technical skills going in, my passion to learn and my excitement to be a part of the team shone through and got me the internship. Even though I was working for free, I loved the work and the team more than any paying job I’ve ever had. Make your nontraditional background a strength, not a weakness. At first, I didn’t want to highlight just how nontraditional my background was. I feared I already stuck out enough just being a female programmer, let alone someone without a CS background. Then my mom said, “Own who you are. Use your previous experiences as a strength.” For my first dev internship, I made it clear I would help out the startup in any way that I could. I talked about the variety of other skills I had picked up way back when I worked for my mom’s company, and how I could utilize those skills while I was also growing into the role of junior developer. I didn’t just try to be an engineering intern. The first week of my internship, I did anything from uploading YouTube videos to writing code to making copy changes. For many startups, they want people who are hungry to learn and get things done — not just code monkeys. What skills from your previous career can you utilize to make yourself valuable, not just as a developer but as a member of the team? A few months into my internship, the company’s CEO, Bryan, sent me a Slack message. “Madison, we want you to work for us.” I was promoted to junior developer. For the first time, I was getting paid to code. Use the haters to push you forward. Many times, when I told someone I was working towards being an engineer, they would look at me and say, “You? An engineer? Are you sure?” For awhile this frustrated me. Then I realized that I wasn’t going to let what anyone said stop me. Each time I heard those comments, I went home and started coding. I used the haters as fuel to keep pushing myself towards my goal. People will always tell you that you can’t do it. When you ignore what they say and just keep going, you develop a trust in yourself and a determination that becomes unstoppable. On the other hand, having a support system who believes you can do it is immensely helpful. I couldn’t have become an engineer without the support of my family. Just keep coding. Getting that first junior developer position was the toughest and most rewarding thing I’ve done. If you focus on your love of code and just keep pushing forward, you will get there. No matter where you’re coming from. So what are you waiting for? Let’s code!

Quincy explores Felix Feng's journey from bootcamp grad to professional developer, and how he went from getting $60,000 job offers to $125,000 job offers through sheer practice and persistence. Article by Felix Feng: https://twitter.com/felix2feng Read by Quincy Larson: https://twitter.com/ossia Article link: https://fcc.im/2iX0LtS Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Resources mentioned: https://www.interviewcake.com https://www.hiredintech.com/classrooms/system-design/lesson/60 https://www.educative.io/collection/5642554087309312/5679846214598656 https://www.reddit.com/r/cscareerquestions/comments/1jov24/heres_how_to_prepare_for_tech_interviews/ https://github.com/h5bp/Front-end-Developer-Interview-Questions https://leetcode.com The email tool Felix uses: https://rapportive.com/   Transcript:  A less-talked about part of the bootcamper’s journey is what happens after you graduate — when you’re searching for that six-figure developer position. I completed Hack Reactor in July 2016 and took almost 3 months before accepting an offer with Radius Intelligence. I applied to 291 companies, did 32 phone screens, 16 technical screens, 13 coding challenges, 11 on-sites, and received 8 offers. The offers ranged from $60-125k in salary from companies all over the US, and for both front end and full stack roles. In total, 2.8% of applications became offers. Here are 5 things I wish I’d known before I began my job search. Insight #1: Get through to real people At first, I applied for companies using the shotgun approach. I applied through Indeed.com, AngelList, LinkedIn, StackOverflow, Hacker News, company websites, and even Craigslist. I’d submit a resume for any role that wanted React, Node, or JavaScript experience. In the first week, I applied to 15–20 companies a day. Pro-Tip: Find companies using this easy-application repo. My yield was low. Less than five percent of companies responded to me. I was throwing applications into a black hole. Everything changed when one of my cohort-mates, a former recruiter, shared a guide to the job search. He told us to send emails directly to real people with each application. It could be anybody. As long as someone read it. From then on, whenever I submitted an application, I searched for the company on LinkedIn and emailed someone on their engineering or hiring team. For most small companies or C-level executives, the email format is usually firstName@dreamCompany.com. For larger companies, it may be firstName.lastName@dreamCompany.com. To verify emails, I used Rapportive to cross-check emails with social media accounts. The results were amazing. With 150+ emails sent, my response rate was a whopping 22%. It also felt great to hear from real people. Surprisingly, CEOs and CTOs responded to me. Sometimes they even interviewed me themselves. Takeaway: If you’re applying through the front door, make sure you’re getting to human beings. Insight #2: Start small and work your way up You will face Level 1 interviews (a non-tech company that needs any dev), where interviewers ask you nothing more than JavaScript trivia. You will face Level 9 interviews (Google/Facebook level), where interviewers ask difficult data structure and algorithm questions. I strategically set up my process so that I had lower-level interviews earlier, and higher-level interviews later on. Early on, I gained experience, built confidence, and secured offers from companies that had less intensive interviews. As I got more experience, I effectively “leveled up.” I became capable of completing interviews at companies with higher hiring bars. This is illustrated below as a linear correlation between the number of weeks I was into the process and the base salary I was offered. There’s a direct correlation between time spent interviewing and offer salary. I unlocked tougher questions. I unlocked higher salaries. And eventually, I unlocked the job I took. Takeaway: Plan to tackle easier interviews early on and more difficult ones later on. Insight #3: Study like your future job depends on it (because it does) I hate to break it to you, but the most important thing you could be doing at any point is studying and preparing. Why? Because you won’t get the offer if you don’t have good answers to the questions they ask you. People won’t refer you if they don’t think you’re prepared for their interviews. Coming out of Hack Reactor, my weaknesses were data structures and algorithms. A study by Triplebyte has found that bootcamp grads are weaker in these areas than computer science grads. So I learned and practiced. Every day. I devoted entire days to learning sorting algorithms. Other days, I focused on understanding how the internet worked. If I didn’t fully understand a concept, I’d spend the day watching YouTube videos or searching StackOverflow until I did. I found the following study materials useful: InterviewCake: My favorite resource for data structures and algorithms. It breaks down solutions into step-by-step chunks — a great alternative to Cracking the Code Interview (CTCI). My only gripe is that they don’t have more problems! HiredInTech’s System Design Section: A great guide for system design interview questions. Coderust: If you’re avoiding CTCI like the plague, Coderust 2.0 may be perfect for you. For $49, you get solutions in almost any programming language, with interactive diagrams. Reddit’s How to Prepare for Tech Interviews: I constantly used this as a benchmark for how prepared I was. Front End Interview Questions: An exhaustive list of front-end questions. Leetcode: The go-to resource for algorithm and data structure questions. You can filter by company, so for example, you could get all the questions that Uber or Google typically ask. Takeaway: There’s no such thing as too much preparation. Insight #4: Put your best foot forward Breaking into the industry is hard. You have to perform well, even when you’re not fully prepared. In order to succeed, you have to be your own advocate. Sell Yourself At Hack Reactor, we’re trained to mask our inexperience. In our personal narratives, we purposely omit our bootcamp education. Why? Otherwise, companies automatically categorize us into junior developer roles or tag us as “not enough experience.” In one interview with a startup, the interview immediately went south once they realized I’d done a bootcamp. One company used it against me and made me a $60k offer, benchmarking against junior developers. Ultimately, you need to convince companies that you can do the job. At the same time, you need to convince yourself that you can do the job. You can. Focus on your love for programming. Focus on what you’ve built with React and Node. Focus on demonstrating your deep knowledge in JavaScript and any other languages you’ve learned. Only then can they justify giving you the job. It’s a Two-way Conversation Interviewing is a mutual exploration of fit between an employee and an employer. While it’s your job to convince employers to hire you, it’s also their job to win you over. Don’t be ashamed of using the interview as an opportunity to evaluate the job opportunity. I talked to any company, even if I had only the slightest interest. I did on-sites all over the country with any company that invited me out. I asked questions, and sucked up knowledge on engineering team organization, technologies and tools used, company challenges, and system architecture. Pro-Tip: During interviews, ask the following questions: What are some technical challenges you’ve recently faced? What do you enjoy about working at X company? How are teams structured and how are tasks usually divided? I treated every interaction as a learning opportunity. Each interaction helped me improve my presentation, interview, and technical skills. Each failure helped me find my blind spots. Takeaway: Don’t sell yourself short! And remember, it’s a mutual exploration. Insight #5: It’s a marathon, not a sprint The journey is by no means easy. For 3 months, I grinded 6 days a week. But I tried to take care of myself. What a typical day could look like in JavaScript Some days, I’d study with friends. Other days, I’d go find a cafe and study alone, or hang out at Hack Reactor’s alumni lounge. And every week I’d check in with our career counselor to talk about my progress. It’s easy to burn out during the process. Eat well, sleep, and exercise. It can get lonely. Spend time with friends who are going through the same experience. Takeaway: Prepare for the long game and make sure you take care of yourself. In summary, the key takeaways are: Get through to real people Start small and work your way up Study like your future job depends on it Put your best foot forward It’s a marathon, not a sprint The process may seem endless, but you’re going to make it. Keep putting in the hours. Keep sending in the applications. Keep taking caring of yourself. All of it pays off in the end.

Canadian software engineer Bill Sourour recounts a tragic experience early in his developer career when writing code for a pharmaceutical company. He explores developer ethics, the responsibilities developers have, and the challenges they face in sticking to their values.   Written by and read by Bill Sourour: https://twitter.com/billsourour   Original Article: https://medium.freecodecamp.org/the-code-im-still-ashamed-of-e4c021dff55e    The Future of Programming by Bob Martin: https://youtu.be/ecIWPzGEbFc    Business Insider Story: "Programmers are having a huge discussion about the unethical and illegal things they’ve been asked to do” http://www.businessinsider.com/programmers-confess-unethical-illegal-tasks-asked-of-them-2016-11?op=1   CBC Interview http://www.cbc.ca/radio/the180/stop-subsidizing-seniors-good-judges-can-make-bad-decisions-and-which-canadian-city-is-the-most-american-1.4028473/creating-a-code-of-ethics-for-coders-1.4028677   Code Newbie Interview https://www.codenewbie.org/podcast/the-ethics-of-coding   Developer Ethics on FCC Guide https://guide.freecodecamp.org/developer-ethics   Learn to code for free at: https://www.freecodecamp.org   Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q   Transcript:  If you write code for a living, there’s a chance that at some point in your career, someone will ask you to code something a little deceitful – if not outright unethical. This happened to me back in the year 2000. And it’s something I’ll never be able to forget. I wrote my first line of code at 6 years old. I’m no prodigy though. I had a lot of help from my dad at the time. But I was hooked. I loved it. By the time I was 15, I was working part-time for my dad’s consulting firm. I built websites and coded small components for business apps on weekends and in the summer. I was woefully underpaid. But as my dad still likes to point out, I got free room and board, and some pretty valuable work experience. Later, I managed to help fund a part of my education through a few freelance coding gigs. I built a couple of early e-commerce sites for some local small businesses. By age 21, I managed to land a full-time coding job with an interactive marketing firm in Toronto, Canada. The firm had been founded by a medical doctor and many of its clients were large pharmaceutical companies. In Canada, there are strict limits on how pharmaceutical companies can advertise prescription drugs directly to consumers. As a result, these companies would create websites that present general information about whatever symptoms their drugs were meant to address. Then, if a visitor could prove they had a prescription, they were given access to a patient portal with more specific info about the drug. The home page of edfactscanada.com circa 2001, via The Internet Archive One of the projects I was assigned to involved a drug that was targeted at women. The graphics and general style of the website made it clear that the client wanted to specifically target teenage girls. One of the features of this website was a quiz that asked girls a series of questions and recommended a type of drug based on their answers. Remember, this website was posing as a general information site. It was not clearly an advertisement for any particular drug. When I received the requirements, they contained the questions for the quiz, along with multiple choice answers for each question. Missing from the requirements was any indication of what I should do with the answers at the end of the quiz. So what rules determined what treatment the quiz would recommend? I spoke to the Account Manager about this. She emailed the client and got me the requirements. With those, I proceeded to code up the quiz. Before submitting the website to the client, my project manager decided to give it a quick test. She tried the quiz, then came over to my desk: “The quiz doesn’t work,” she said. “Oh. What’s broken?” I asked. “Well, it seems that no matter what I do, the quiz recommends the client’s drug as the best possible treatment. The only exception is if I say I’m allergic. Or if I say I am already taking it.” “Yes. That’s what the requirements say to do. Everything leads to the client’s drug.” “Oh. Okay. Cool.” And she was off. I wish I could tell you that when I first saw those requirements they bothered me. I wish I could tell you that it felt wrong to code something that was basically designed to trick young girls. But the truth is, I didn’t think much of it at the time. I had a job to do, and I did it. Nothing that we were doing was illegal. As the youngest developer on my team, I was making good money for my age. And in the end, I understood that the real purpose of the site was to push a particular drug. So, I chalked this tactic up to “marketing.” The client was extremely pleased with the site. So much so that their rep invited me and the entire team out to a fancy steak dinner. The day of the dinner, shortly before leaving the office, a colleague emailed me a link to a news report online. It was about a young girl who had taken the drug I’d built the website for. She had killed herself. It turned out that among the main side effects of that drug were severe depression and suicidal thoughts. The colleague who had emailed me didn’t show up to dinner. I still went. It was difficult and awkward. I never mentioned the news report. I just ate my steak quietly and tried to force a smile when I could. The next day, I called my sister. She was 19 at the time. We had discovered while working on the project that she had actually been prescribed the very drug I was building a site for. When we first talked about it, we thought the whole thing was a neat coincidence. Now, the tone of our conversation was very different. I advised her to get off the drug ASAP. Thankfully, she listened. There are a million and one ways for me to rationalize my part in later suicides and severe depression. Even today, there is ongoing litigation with former patients. It’s easy to make an argument that I had no part in it at all. Still, I’ve never felt okay about writing that code. Not long after that dinner, I resigned. As developers, we are often one of the last lines of defense against potentially dangerous and unethical practices. We’re approaching a time where software will drive the vehicle that transports your family to soccer practice. There are already AI programs that help doctors diagnose disease. It’s not hard to imagine them recommending prescription drugs soon, too. The more software continues to take over every aspect of our lives, the more important it will be for us to take a stand and ensure that our ethics are ever-present in our code. Since that day, I always try to think twice about the effects of my code before I write it. I hope that you will too.

Quincy reads his popular article on how to choose your first programming language when you learn to code. He discusses Python, Java, JavaScript, Ruby, and C++ in terms of: - the job market for the language - the long term prospects for the language - how easy the language is to learn - what projects you can build while you’re learning (and share with friends so you can stay motivated) Read by Quincy Larson (https://twitter.com/ossia) Article link: https://fcc.im/2yCMatt Learn to code for free at: https://www.freecodecamp.org Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q Transcript: Most people’s journey toward learning to program starts with a single late-night Google search. Usually it’s something like “Learn ______” But how do they decide which language to search for? “They always joke about Java on Silicon Valley. I guess I should learn that.” Or: “Haskell. So hot right now. Haskell.” Or: “That Go gopher is just so gosh-darn cute.” And then there’s the rest of us. We’ll probably search for something like: “Which programming language should I learn first?” Few questions are so commonly asked that they get the full infographic treatment. But this is one of them: Deciding on your first programming language can be a fun process — kind of like one of those “Which Quentin Tarantino character are you?” personality quizzes. But before you run off to learn Ruby because you enjoyed playing with Play-Doh as a kid, let me remind you: the stakes are pretty high here. It will take you hundreds of hours of practice to become even remotely competent with your first programming language. So you should consider the following factors: - the job market for the language - the long term prospects for the language - how easy the language is to learn - what projects you can build while you’re learning (and share with friends so you can stay motivated) Every year brings new programming languages, and with them, new academic papers. And new web comics. Seriously. Check out this gem from last month: When it comes to choosing a first programming language, there’s no shortage of options. To narrow it down a bit, here are the most common Google searches related to learning programming, over the past 12 years: Java has had its ups and downs. Python has gradually risen to become the most popular choice. But tucked away below these is the Little Engine That Could, slowly choo-choo’ing up in popularity over the past few years. And that engine is JavaScript. Before I talk about these programming languages, let me clarify: I’m not arguing that any one language is objectively better than any other I agree that developers should eventually learn more than one language I’m arguing that first they should learn one language well. And — as you can probably guess from the upside down text in my headline — that language should be JavaScript. Let’s kick things off by exploring how programming is currently taught in school. Computer Science 101 Universities have traditionally taught programming under the umbrella of computer science, which itself is often seen as an extension of mathematics, or tie-in to an electrical engineering degree. Of course, as you may have heard by now: “Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter.” — Eric S. Raymond As of 2016, many universities still treat programming like it’s computer science, and computer science like it’s math. As a result, many introductory programming courses focus on low-level-of-abstraction languages like C, or mathematically-focused languages like MATLAB. And department chairs generally stay the course, pointing to annual programming language leaderboards like the TIOBE Index, or this one from the IEEE: Most of these leaderboards look virtually identical to how they were 10 years ago. But change does happen. Even in academia. In 2014, Python overtook Java as a the most popular language of instruction at top US Computer Science programs. And yet another change is bound to… eventually… happen. Because if you look at the languages actually used by the workforce, it paints a very different picture: JavaScript is by far the most popular language used by the 49,397 developers who responded to Stack Overflow’s 2016 Survey. More than half of all developers use JavaScript. It’s vital to front-end web development and increasingly relevant for back-end development. And it’s rapidly expanding into areas like game development and the Internet of Things. Job postings also mention JavaScript more than any programming language other than Java: Data from the world’s largest job posting aggregator, Indeed.com It’s no accident that we built our open source community’s curriculum around JavaScript. Over the past two years, more than 5,000 people have used Free Code Camp to get their first developer job. I’m not advocating JavaScript because I teach it. I teach JavaScript because it’s the surest path to a first developer job. But is JavaScript right for you? Is it worthy of being your first programming language? Let’s explore those factors I mentioned earlier. Factor #1: The job market If you’re learning to program purely out of intellectual curiosity, feel free to skip this factor. But if you — like the vast majority of people learning to program — want to use this skill to get a job, this is an important consideration. As I mentioned earlier, Java is mentioned in more job postings than any other programming language. JavaScript is a close second. But here’s the thing about JavaScript: even though it’s been around for 20 years, it only recently became a serious tool that companies like Netflix, Walmart, and PayPal would build entire applications around. As a result, plenty of companies are hiring JavaScript developers, but there just aren’t that many on the job market. There are 2.7 Java developers competing for every open Java position. Competition for PHP and iOS jobs is similarly fierce. But for every open JavaScript position, there are only 0.6 JavaScript developers. It is very much a sellers’ market for developers with JavaScript skills. Factor #2: The long term prospects The average JavaScript project receives twice as many pull requests as the average Java, Python, or Ruby project. And on top of this, JavaScript is growing faster than any other popular language. Source: The GitHub’s 2016 State of the Octoverse JavaScript’s ecosystem also benefits from a heavy investment of money and engineering talent from companies like Google, Microsoft, Facebook, and Netflix. For example, TypeScript (a statically-typed superset of JavaScript) has more than 100 open source contributors, many of whom are Microsoft and Google employees being paid to work on it. This type of inter-company cooperation is harder to find with Java. Oracle — who effectively owns Java through its acquisition of Sun Microsystems — often sues companies who try to expand upon it. Factor #3: Difficulty to learn This is a parody of an XKCD comic. Most programmers would agree that high-level scripting languages are relatively easy to learn. JavaScript falls into this category, along with Python and Ruby. Even though universities still teach languages like Java and C++ as first languages, they’re considerably harder to learn. Factor #4: Projects you can build with it This is where JavaScript really shines. JavaScript runs on any device that has a browser, right there in the browser. You can build basically anything with JavaScript, and share it anywhere. Because of JavaScript’s ubiquity, Stack Overflow co-founder Jeff Atwood coined his now-famous law: “Any application that can be written in JavaScript, will eventually be written in JavaScript.” And with each passing month, Atwood’s Law holds strong. Java once promised to run everywhere, too. You may remember Java Applets. Oracle officially killed them off earlier this year. Python suffers from much the same problems: “How can I give this game I made to my friend? Even better, is there a way can I put this on my phone so I can show it to kids at school without them having to install it? Um.” — James Hague in Retiring Python as a Teaching Language By contrast, here are some apps that members of our open source community built in their browsers on CodePen. You can click through and use these right in your browser: - 1970s style Simon game - Conway’s Game of Life - Star Wars-themed Wikipedia Search - A roguelike dungeon crawler game Learn one language well. Then learn a second one. If you keep jumping from language to language, you won’t get far. In order to move beyond the basics, you need to learn your first language well. Then your second language will be much, much easier. From there, you can branch out, and become a more well-rounded developer by learning lots of languages: C is a great way to learn how computers actually work in terms of memory management, and is useful in high-performance computing C++ is great for game development. Python is awesome for science and statistics. Java is important if you want to work at large tech companies. But learn JavaScript first. OK, now I’m going to attempt the impossible — I’m going to try and anticipate objections from the comments section. Objection #1: But isn’t JavaScript slow? JavaScript is — for most practical purposes — as fast as high-performance languages. JavaScript (Node.js) is orders of magnitude faster than Python, Ruby, and PHP. It is also nearly as fast as high-performance languages like C++, Java, and Go. Here are the results of the most comprehensive recent cross-language benchmark: Objection #2: But JavaScript isn’t statically typed Like Python and Ruby, JavaScript is dynamically typed, which is convenient. But you can get into trouble. Here I intend for exampleArray to be an array. I set its values, then check its length — meaning the number of elements it contains. exampleArray = [1, 2] -> [1, 2] exampleArray.length -> 2 But then I accidentally assign it to be a string. exampleArray = “text” -> “text” exampleArray.length -> 4 These kinds of errors happen all the time in dynamically typed languages. Most developers just put checks in place to prevent them, and write tests accordingly. If you absolutely must have static typing in your first programming language, then I still recommend you learn JavaScript first. Then you can quickly pick up TypeScript. “Typescript has a learning curve, but if you already know JavaScript, it will be a smooth one.” — Alex Ewerlöf on TypeScript Objection #3: But I really want to make a mobile app I still recommend learning JavaScript first. JavaScript features several tools for making native mobile apps, such as Angular Cordova and React Native. In order for your mobile app to actually do anything interesting, it will probably need a proper back end, which you’ll want to build with a proper web development framework, like Node.js + Express.js. Also, it’s worth pointing out that the mobile app development’s best days may very well be behind it. For starters, as much as people use mobile apps, nearly half of all developer jobs are web development. Compare this with a mere 8% of jobs that involve mobile app development. The occupations of 49,525 developers, based on responses to the 2016 Stack Overflow survey. The grand vision of “there’s an app for that” has not come to pass. Instead, most smartphone owners have stopped downloading new apps. Sure — they still use apps. Mostly Facebook, Google Maps, and handful of others. As such, much of the demand for mobile app developers is concentrated in a few large employers. The outlook for those mobile development jobs is hard to forecast. Many aspects of developing, maintaining, and distributing mobile apps are easier with JavaScript. So companies like Facebook and Google are investing heavily in better tools for building these using JavaScript. As of 2016, pretty much all development is web development. Everything touches that big platform that is “the web.” And the next wave of devices that you’ll talk to around your home, and cars that pick your kids up from school — they’ll all be piped together using the web, too. And that means JavaScript. Objection #4: Isn’t JavaScript a toy language that was written in 10 days? JavaScript has a quirky history. You will undoubtedly hear people crack jokes at its expense. Well people love to hate on C++, too. And like JavaScript, C++ has succeeded despite this hate, and now it’s pretty much everywhere as well. So if anybody ever gives you a hard time for learning JavaScript instead of elite-language-of-the-week, just remember the famous words of the guy who created C++: "There are only two kinds of programming languages: those people always bitch about and those nobody uses." — Bjarne Stroustrup

Beau talks about his year of incredible productivity, during which he a degree and certifications, and taught himself to code - balancing his studies against an active family life. Beau's original article: https://fcc.im/2j0vxBr Read by Beau: https://twitter.com/carnesbeau Learn to code for free at: https://www.freecodecamp.org Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q Transcript: “The standard pace is for chumps. The system is designed so anyone can keep up. If you’re more driven than ‘just anyone’ — you can do so much more than anyone expects. And this applies to ALL of life — not just school.” — Derek Sivers, founder of CD Baby Learning to code can be challenging — especially when you also have a job and a family with small kids. Despite those things, I decided that the standard pace was not for me. My goal in writing all this is not to brag — though I am extremely proud of these accomplishments. My goal is to convince you that the standard pace isn’t for you, either. I’ve done a lot in the past year. I earned two Oracle Java Certifications, two CompTia Certifications, and freeCodeCamp’s Front End Certification. Each of these take most people many months of preparation, but I did them all in three weeks each. And last but not least, I completed all the coursework necessary to earn a second Bachelor’s degree in software development from an accredited university, in less than six months. I did this all while working full-time, spending time regularly with my wife and two young kids, and volunteering in my community. One of the keys to accomplishing all of this was an amazing and supportive spouse. 😍 But there were also some other things that helped. What’s Your Motivation? After being a K-12 teacher for five years, I realized I did not want to teach in a school the rest of my life. I loved the teaching part of teaching, but I hated the forcing-kids-to-do-things-they-don’t-want-to-do part of teaching. Classroom management in my urban school district was very stressful for me. I was also becoming disenchanted with the whole educational system. We seem to be preparing students for jobs that will no longer exist. I had always been interested in coding and even sometimes taught my students basic coding using Scratch and Code.org. I decided it was time to learn enough to do it full-time. Wanting a new job was great motivation. Everyday I spent at my teaching job was an incentive to keep pushing myself towards my goal. Research, research, research It’s important not to rush into learning. Not all schools or learning resources are equal, and the wrong choice can make a big difference in your ability to meet your goals. I tried to determine what learning method would work best for me and my family. While I know there are many ways to break into the tech industry, I decided on a somewhat traditional route: a Bachelor’s degree. I knew I had some classes already that would transfer into a new program. I looked into many school options but I decided on Western Governors University for the following reasons: It is all online so I would not have to take time from my family for transportation. You can work at your own pace, so I knew I could finish very quickly. As soon as you finish all the assignments and exams for one class, you can go immediately to the next class. The cost is low — about $3000 per six months. It is reputable, accredited, and has been recommended by President Obama and Bill Gates. The degree included industry recognized certifications. I knew those would add to the credibility of my education. Beating ambitions goals At first, my goal was to finish my entire Bachelor’s degree in one year. One month into the program, I decided to revise my goal and finish in six months. It was at this point that I did what helped me most in my goal to finish quickly: I made a schedule of the exact day I would finish each class so I could finish within 6 months. I scheduled between 1 and 3 weeks for each class, depending on class requirements. I also made plans at that time about how I would finish each class very quickly. It was very helpful to have many subgoals throughout the learning process to make sure I stayed on track.   Section of actual spreadsheet I used to plan for classes. Ambitious goals are important. These provided me additional motivation to push myself. A study by the Journal of Consumer Research showed that ambitious goals make people happier. I ended up meeting or surpassing all my self-imposed deadlines and that definitely made me happy! Detailed schedule I created a detailed weekly schedule to help me spend a lot of time learning without neglecting my family and other responsibilities. I scheduled in family time, volunteering time, time with friends, and even a weekly date night!   The schedule I created at the beginning of my degree. I have an even more detailed schedule now. A detailed schedule helped me make sure that my life stayed balanced. However, there is one thing I did not put on my schedule: television. I watched only 3 episodes of television the entire time I worked on my degree. I had such a tight schedule to keep so I could meet my goals so I did not have time for TV. Also, any time spent watching television meant less time with my family. Since graduating, I have continued to limit television so I can focus on coding. It was important for me to give things up in order to accomplish my goals. Ignore the haters! Every student at Western Governors University is assigned a mentor. Students have weekly calls with their mentors to help keep them on track. Whenever I shared my goals with my mentor she tried to encourage me to be a little more reasonable. Well, instead of being more reasonable I decided to set more ridiculous goals. I know she had good intentions but I decided to ignore her warnings and stopped sharing my goals with her. I have found that it is sometimes helpful to not share goals with certain people if they are not going to be encouraging. Maximizing time Besides my scheduled time to learn software development, I also found ways to fit in even more studying. For instance, I used most of my lunch breaks to study. Also, I often carried notes in my pocket that I could review whenever I had a free moment. Another thing I did (and still do) was to take days off my teaching job to work on my classes or programming projects. While completing my degree, I planned my days off to line up in my schedule when I knew I had harder classes to pass. I try to be constantly reevaluating my schedule and how I spend my time so I can have greater effectiveness. I used to code a lot after my kids went to bed. However, I noticed that by the end of the day, my brain just did not work as well. I switched up my sleep schedule so I now go to bed around 9pm and wake up at 4am to code (and create training videos). This may sound a little crazy but it has greatly increased my productivity. Learn what others do I spent a lot of time on the Reddit page for my college and various forums reading about what others did that helped them with their classes. For the industry certifications, there were even more resources available to help. This allowed me to better plan the quickest way to finish. There is almost always someone out there who has gone before you, and it’s important to identify them and learn from them. Learning from others was also very helpful while going through the freeCodeCamp curriculum. Experienced people in the community are always willing to help or offer suggestions in their forums and community chat rooms. Just ship it!   Shipping means to send out a completed product. There were many times when I wondered if I needed to put in more time working on projects or studying. Then I would realize that I didn’t have time if I wanted to meet my self-imposed deadlines. My deadlines forced me to act before I felt completely ready, and this definitely paid off. I’ve found that it’s more important to get projects out there than to make them perfect. If you try to make sure everything is just right, you may never finish. When in doubt, just ship it! The 80/20 Rule   The 80/20 rule states that for many events, roughly 80% of the effects come from 20% of the causes. When learning software development, this means that about 20% of the learning content will contain about 80% of what you will actually use. You can save a lot of time if you just focus on the top 20%. For my degree, I only read between 20–30% of the required content. According to the 80/20 rule, this was enough to understand over 80% of the subject matter. The trick is determining which 20% to focus on. I would often ask myself, “If I were designing the exam, would I include this material?” Really, when learning anything, you should ask yourself if it is part of the 20% of learning content that will give you 80% of value. This relates to the idea of just-in-time information. It’s usually not beneficial to learn something that you don’t plan to use in the near future, especially when your memory is as bad as mine. 😊 When working on projects I try to learn what I will need just for that project. Employers often care more about projects you’ve created than how you learned to code. Keeping this fact in mind will help you decide how to best use your time. Keeping things moving forward I didn’t take any time off from learning once my degree was finished. I realized the importance of projects, so I went straight into freeCodeCamp and started creating personal projects to build up my portfolio. I was able to continue to apply all of the strategies that I used while completing my Bachelor’s degree. I also continued to use these strategies when I decided to start creating JavaScript training videos. Now I’m posting JavaScript training videos almost every day on the freeCodeCamp YouTube channel. If you’re interested in the specific things I did for each class to finish my WGU degree quickly, you can check out this blog post. I hope some of the strategies I used can also be helpful to you, even if your life is as busy as mine. Remember: the standard pace is for chumps. You can do better!

Cecily Carver, a developer at Google, recounts her coding journey and the many lessons she learned along the way. Read by Ava. Cecily's article: https://fcc.im/2A5kphQ Read by Ava: https://twitter.com/avasond Learn to code for free at: https://www.freecodecamp.org Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q   Transcript: Before you learn to code, think about what you want to code Knowing how to code is mostly about building things, and the path is a lot clearer when you have a sense of the end goal. If your goal is “learn to code,” without a clear idea of the kinds of programs you will write and how they will make your life better, you will probably find it a frustrating exercise. I’m a little ashamed to admit that part of my motivation for studying computer science was that I wanted to prove I was smart, and I wanted to be able to get Smart Person jobs. I also liked thinking about math and theory (this bookblew my mind at an impressionable age) and the program was a good fit. It wasn’t enough to sustain me for long, though, until I found ways to connect technology to the things I really loved, like music and literature. So, what do you want to code? Websites? Games? iPhone apps? A startup that makes you rich? Interactive art? Do you want to be able to impress your boss or automate a tedious task so you can spend more time looking at otter pictures? Perhaps you simply want to be more employable, add a buzzword to your resume, or fulfill the requirements of your educational program. All of these are worthy goals. Make sure you know which one is yours, and study accordingly. There’s nothing mystical about it Coding is a skill like any other. Like language learning, there’s grammar and vocabulary to acquire. Like math, there are processes to work through specific types of problems. Like all kinds of craftsmanship and art-making, there are techniques and tools and best practices that people have developed over time, specialized to different tasks, that you’re free to use or modify or discard. This guy (a very smart guy! Whose other writings I enjoy and frequently agree with!) posits that there is a bright line between people with the True Mind of a Programmer and everyone else, who are lacking the intellectual capacity needed to succeed in the field. That bright line consists, according to him, of pointers and recursion (there are primers here and here for the curious). I learned about pointers and recursion in school, and when I understood them, it was a delightful jolt to my brain — the kind of intellectual pleasure that made me want to study computer science in the first place. But, outside of classroom exercises, the number of times I’ve had to be familiar with either concept to get things done has been relatively small. And when helping others learn, over and over again, I’ve watched people complete interesting and rewarding projects without knowing anything about either one. There’s no point in being intimidated or wondering if you’re Smart Enough. Sure, the more complex and esoteric your task, the higher the level of mastery you will need to complete it. But this is true in absolutely every other field. Unless you’re planning to make your living entirely by your code, chances are you don’t have to be a recursion-understanding genius to make the thing you want to make. It never works the first time And probably won’t the second or third time When you first start learning to code, you’ll very quickly run up against this particular experience: you think you’ve set up everything the way you’re supposed to, you’ve checked and re-checked it, and it still. doesn’t. work. You don’t have a clue where to begin trying to fix it, and the error message (if you’re lucky enough to have one at all) might as well say “fuck you.” You might be tempted to give up at this point, thinking that you’ll never figure it out, that you’re not cut out for this. I had that feeling the first time I tried to write a program in C++, ran it, and got only the words “segmentation fault” for my trouble. But this experience is so common for programmers of all skill levels that it says absolutely nothing about your intelligence, tech-savviness, or suitability for the coding life. It will happen to you as a beginner, but it will also happen to you as an experienced programmer. The main difference will be in how you respond to it. I’ve found that a big difference between new coders and experienced coders is faith: faith that things are going wrong for a logical and discoverable reason, faith that problems are fixable, faith that there is a way to accomplish the goal. The path from “not working” to “working” might not be obvious, but with patience you can usually find it. Someone will always tell you you’re doing it wrong Braces should go on the next line. Braces should go on the same line. Use tabs to indent. But tabs are evil. You should use stored procedures, but actually you shouldn’t use them. You should always comment your code. But good code doesn’t need comments. There are almost always many different approaches to a particular problem, with no single “right way.” A lot of programmers get very good at advocating for their preferred way, but that doesn’t mean it’s the One True Path. Going head-to-head with people telling me I was Wrong, and trying to figure out if they were right, was one of the more stressful aspects of my early career. If you’re coding in a team with other people, someone will almost certainly take issue with something that you’re doing. Sometimes they’ll be absolutely correct, and it’s always worth investigating to see whether you are, in fact, Doing It Wrong. But sometimes they will be full of shit, or re-enacting an ancient and meaningless dispute where it would be best to just follow a style guide and forget about it. On the other hand, if you’re the kind of person who enjoys ancient but meaningless disputes (grammar nerds, I’m looking at you), you’ve come to the right place. Someone will always tell you you’re not a real coder HTML isn’t real coding. If you don’t use vi, you’re not really serious. Real programmers know C. Real coders don’t do Windows. Some people will never be able to learn it. You shouldn’t learn to code. You’re not a computer programmer (but I am). “Coding” means a lot of different things to a lot of different people, and it looks different now from how it used to. And, funnily enough, the tools and packages and frameworks that make it faster and easier for newcomers or even trained developers to build things are most likely to be tarred with the “not for REAL coders” brush. (See: “Return of the Real Programmer”) Behind all this is the fear that if “anyone” can call themselves a programmer, the title will become meaningless. But I think that this gatekeeping is destructive. Use the tools that make it easiest to build the things you want to build. If that means your game was made in Stencyl or GameMaker rather than written from scratch, that’s fine. If your first foray into coding is HTML or Excel macros, that’s fine. Work with something you feel you can stick with. As you get more comfortable, you’ll naturally start to find those tools limiting rather than helpful and look for more powerful ones. But most of the time, few people will ever even look at your code or even ask what you used — It’s what you make with it that counts. Worrying about “geek cred” will slowly kill you See above. I used to worry a lot, especially in school, about whether I was identifying myself as “not a real geek” (and therefore less worthy of inclusion in tech communities) through my clothing, my presentation, my choice of reading material and even my software customization choices. It was a terrible waste of energy and I became a lot more functional after I made the decision to let it all go. You need to internalize this: your ability to get good at coding has nothing to do with how well you fit into the various geek subcultures. This goes double if you know deep down that you’ll never quite fit. The energy you spend proving yourself should be going into making things instead. And, if you’re an indisputable geek with cred leaking from your eye sockets, keep this in mind for when you’re evaluating someone else’s cred level. It may not mean what you think it does. Sticking with it is more important than the method There’s no shortage of articles about the “right” or “best” way to learn how to code, and there are lots of potential approaches. You can learn the concepts from a book or by completing interactive exercises or by debugging things that others have written. And, of course, there are lots of languages you might choose as your first to learn, with advocates for each. A common complaint with “teach yourself to code” programs and workshops is that you’ll breeze happily through the beginner material and then hit a steep curve where things get more difficult very quickly. You know how to print some lines of text on a page but have no idea where to start working on a “real,” useful project. You might feel like you were just following directions without really understanding, and blame the learning materials. When you get to this stage, most of the tutorials and online resources available to you are much less useful because they assume you’re already an experienced and comfortable programmer. The difficulty is further compounded by the fact that “you don’t know what you don’t know.” Even trying to figure out what to learn next is a puzzle in itself. You’ll hit this wall no matter what “learn to code” program you follow, and the only way to get past it is to persevere. This means you keep trying new things, learning more information, and figuring out, piece by piece, how to build your project. You’re a lot more likely to find success in the end if you have a clear idea of why you’re learning to code in the first place. If you keep putting bricks on top of each other, it might take a long time but eventually you’ll have a wall. This is where that faith I mentioned earlier comes in handy. If you believe that with time and patience you can figure the whole coding thing out, in time you almost certainly will.  

We conclude the tale of Alvaro Videla, who learned to code, got a job as a developer, and is now facing his first week on the job in Montevideo, Uruguay. He eventually went on to get jobs at Apple and other tech companies, but this is where he got his start.   Article by Alvaro Videla: https://fcc.im/2zJX3gN Read by Quincy Larson: https://twitter.com/freecodecamp Learn to code for free at: https://www.freecodecamp.org Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q   Transcript:  The Technical Interview The programmer who was interviewing me explained how things would go, that I was going to walk right into their offices, get my own desk, and program at one of their computers, with everybody else just doing their jobs, since “that’s how it’s going to be if you join us.” I thought that was pretty cool already. And just like he said, once I got into the office, everybody said hello and continued doing their jobs. Even though I wasn’t close to getting the job, I was already starting to feel like a part of something. The test consisted of building a website to list books for an imaginary library. It seemed simple enough: connect to a database, fetch a list of books, and display them on a webpage, with the buttons for the usual actions for adding books, deleting them, and updating their information. “I can do that,” I thought. While I was focusing on the test, behind me were programmers who were splitting their time between working on their tasks and playing with tennis balls in a very particular way: they were throwing them at each other, with a lot of force, up to the point where one shot hit the reset button of one of the computers and one guy lost what he was doing on his editor. “That’s a strange way to work, but it’s kinda cool,” I thought. I had expected a more formal working environment, but was pleasantly surprised at how relaxed the environment was. Meanwhile, halfway through my implementation, I got stuck. I couldn’t get my code to print the list of books, and nothing was showing up on the screen. “How do I get out of this one?” I wondered. I tried to debug it by adding print statements here and there, but that didn’t work, and I had no idea what was going on. The clock was ticking away, and I was starting to get really desperate. “Come on,” I told myself. “I can’t miss this opportunity because of this problem. What do I do? Should I ask for help? What if this disqualifies me instantly?” I thought about it some more. “I guess they help each other during work,” I reasoned. “OK, whatever, I’m going to ask for help.” I called the interviewer over and talked him through my problem, trying to explain everything I had tried so far, so he wouldn’t think I was cheating him into giving me an answer. Lucky for me, he also had no idea what was going on, so he told me it was fine and that I could leave it as it was. Unfortunately, I had used too much time on this debugging session so I didn’t have enough time to complete the second part of the test. Later on, I would value this lesson, since I saw that asking for help earlier would have saved a lot of time later — time that in this particular case was critical for me. And in the future, it could be critical for the company I would end up working for. I didn’t want to ask for extra time to try to solve the next problem, since I thought that wasn’t fair. I wanted to play by the rules, because I felt it was the right thing to do. As we’ll see later, I think that decision paid off. In the meantime, I had the second problem in front of me and I had to do something about it. I skimmed through it and saw that it was about parsing URLs out of some log files, so I gathered some courage. I put my most convincing face and told the guy that while I understood my time was up, the solution was a matter of just “splitting these lines by these characters, and then going with the URL splitting by using this and that character.” The guy nodded, and told me that indeed that was the solution. Then he said that the interview was over, and he asked me if I had any questions about the company or if there was something I wanted to add. Later on, I would value this lesson, since I saw that asking for help earlier would have saved a lot of time later “Well, now that you ask, yes,” I began. “I’ve been building this mapping application that I want to show you…” This was my opportunity to shine. I typed the website URL on the computer in front of us and started to pray to every god out there for it to load without problems. “Please, just this one time,” I thought. And as every element from the website finished loading, my anxiety decreased and my excitement increased. The creation I was most proud of was there, right in front of my eyes, and more importantly, in front of the eyes of the person who would decide if I had a job or not. I went through every feature of the app, explaining with passion the goal of the app, which features it had, and which features it lacked but that I knew I had to implement to have a clear business case. After a demo, he seemed impressed by Aleph Maps and gave me kudos for it, which made me happy I’d had the chance to run the demo for him and gone ahead with it. This showed me that all the demos I had run for various members of my family and for my friends had been worthwhile, since when it mattered, I was able to show that I could not only build things on my own, but also that I was good at explaining things. By then it was around 6 p.m. — time for them to call it a day, and for me to get back home. As we were leaving the building together, I asked the man who conducted my tests if he was attending university, because perhaps he knew my friend who had told me about this job opportunity. “Oh yeah, I know your friend, why didn’t you mention him before?” he asked. I didn’t answer, but the fact was that I didn’t want to bring it up and use it to my advantage during the interview. But in any case, it didn’t hurt afterward. He showed me how to get public transport back to the bus terminal and then we parted ways. Once on my own, I couldn’t believe I was done with the interview. Everything I had prepared for in the last two months had passed in what felt like the blink of an eye. All the stressing out about the little details — some that mattered, some that didn’t — was gone. Now it was me and Montevideo, and the streets crowded with people going back to their homes, and the cars, and the night falling over the city. I’d done it. Once I had processed all of it, the worst part came. It was time to take the bus and head home to wait for an answer, and waiting is something I’m really bad at. But that’s what it became. Waiting while staring at the ceiling of our room, wondering with my wife how our lives would change if I got the job. Waiting while looking at my books without knowing if I should have kept reading them or not. Waiting while making sure my phone had enough battery power so there would be no missed phone calls. Waiting, until at some point the wait was over, my phone rang, and again it was that number from Montevideo. “When can you start?” asked the voice on the other end. I was in. Yes, me. They wanted me: the guy who barely knew how to program, but let’s not worry about that now. “They want me,” I told myself, letting it sink in. “I’m in.” The whole gamble had paid off. Finally, after all those years of having jobs that paid nothing, working just because that’s what people do, even if having jobs meant forgetting about our dreams — finally, life was starting to turn around and smile on us, and from one day to the next, we could see a life that was worth living. I asked for one week to move to Montevideo, so they told me February 26 would be my starting date. “You will be working in PHP and JavaScript. You’re going to earn 15,000 pesos (500 USD) a month.” FIFTEEN THOUSAND PESOS! That was three times what my wife was making! “We are going to be rich!” I thought. I was going to be able to buy as much Coca-Cola as I wanted! We could probably even manage to save $100 per month and buy a house someday. We couldn’t believe what was happening to us. Finally, life was starting to turn around and smile on us, and from one day to the next, we could see a life that was worth living I spent that week prepping in JavaScript and trying to find a place to stay in Montevideo. A friend hooked me up with his apartment, since he was going to move out after Easter. The rent was good for us, so we decided that in about a month my wife would move to Montevideo and join us. The “apartment” was just one room, plus a kitchen and a small bathroom, and you could only fit two beds and a dining table in there. For a short while, it would be three of us living in that room, but honestly, that didn’t matter to us. I would be starting a new and exciting job, and we would have a place to live. Mission accomplished. First Week at Work My first day at work began with a nice twist: the person who conducted the interview was also my new manager. He brought me to office kitchen, we sat down at the table, and he started explaining what the company was doing, what the business model was, and so on. He then proceeded to lay down on a piece of paper depicting what the backend architecture was like, how things worked, what the server was doing, where the database was located, and many other details. I have to be honest: it was hard to follow. I recall hearing the term “production” a couple of times too. “This is our production setup,” “Here’s the production database,” and so on. I had no idea what this production thing he kept talking about was! Later, I learned that production referred to all the infrastructure, including code, that was facing clients and producing income for the company. We went through a couple of questions and answers here and there, and then came to what was, for me, the most significant part of that day. He looked at me and told me, honest and straight to the point: “We know that you’re not a good programmer, that you are just starting at this, and that you have no experience, so before you’re even able to commit one line of code to our codebase, we need you to study this book,” he said as he handed me a copy of PHP Objects, Patterns, and Practice by Matt Zandstra. “You have to know it by next week.” As straightforward it was, this was some of the most solid, sincere, and helpful feedback I’ve ever received as a programmer. To this day, I thank him for being forthright with me. During my career, I’ve learned how difficult it is to come by a manager who will give you this kind of feedback — feedback that’s useful for understanding your own shortcomings, but at the same time puts you on the right track in order to overcome them. Then he told me: “We know you are inexperienced, but during the interview you showed yourself as a person with a great attitude. That’s why we hired you.” I was speechless. I wondered what I’d done to deserve such an opportunity. Even more, I knew I had to prove I was worth it, so I set myself a goal of mastering the design patterns book as quickly as possible. First, I couldn’t disappoint my new boss who had taken a chance on me, and second, I finally had an opportunity in the big leagues, at the job I’d worked so hard for. It was time to shine. “We know you are inexperienced, but during the interview you showed yourself as a person with a great attitude. That’s why we hired you.” Fired After One Week on the Job During my first week, I studied that book like my life depended on it, because in a way, it did. I tried to learn as many of those design patterns as possible, practicing every example, and I tried to absorb as much knowledge as possible. By the end of the week, I wanted my manager to come to me and tell me, “Now you’re ready to start programming with us.” But as with every tale, this story needed a twist. That Thursday, some people from the company came and called me to another room to deliver some news: the company was conducting layoffs, and I was among the people being let go. “Nothing personal,” they said. “Business isn’t going too well, and we need to downsize, so we’re letting go of people who just joined the company. We hope you understand.” That day, I was one of around 50 employees who lost their jobs. I’m not sure I can accurately describe what I felt at that moment. “Why does life has to be like this?” I wondered, feeling somewhat discouraged and helpless. “What do I do now?” I asked to use the phone and called my wife. “Please don’t worry, but I have some bad news…” I began. I tried hard not to lose my composure, but meanwhile, the whole world was coming apart below my feet. All around me were employees coming in from other rooms and bidding farewell to all the people who were just fired, which only made me feel worse. Even so, I tried to convince myself that I shouldn’t despair. I had gotten this far, so it was simply a matter of applying to another job somewhere else. While I was saying goodbye to my short-lived colleagues, one of them tipped me off about some companies I should apply for, so I took note. From an internet cafe, I sent out job applications to the companies my brand new former colleague gave me, and when I was done, I headed back home. I tried to convince myself that I shouldn’t despair. I had gotten this far, so it was simply a matter of applying to another job somewhere else. “What a depressing day,” I thought. I entered the apartment and laid down on the bed, which for the record, was just a mattress on the floor. I remember the sky was gray, a perfect match for how I was feeling. I tried to nap, but my mind was lost, staring at the ceiling of that empty apartment and thinking about this new turn of events. “What if I hadn’t been fired?” “What did I do wrong?” I knew I had done nothing wrong. It was just bad luck, but it was hard to accept it. Suddenly my phone rang. “Is this Alvaro Videla? I’m calling from Intersys. We received your application and we want to have an interview with you. Is next Monday OK for you?” “OF COURSE THAT’S FINE WITH ME,” I thought, but instead I said, “Yes, that sounds great, I’ll be there.” As I hung up and placed my phone on the floor, I was in shock, unable to believe what had just happened. Montevideo was a city full of surprises. The next day I went down the street and asked the barber if he would give me a free haircut, since I had a job interview lined up but I had no money left. I still hadn’t received my salary from the week of work, so I needed a favor in exchange for being paid back the following week. Luckily, he was really happy to help me. I still remember his warm smile; he felt proud he was helping a neighbor get a job. While I was getting the haircut, he shared his story. I learned that in the early 2000s, he and his crew were the winners of some world hairdresser championship! I had no idea there were hairdresser championships. Don’t worry, I couldn’t believe him either back then. Either way, getting a haircut with a “world champion” was cool, but also meant that the service was expensive — $10 to be exact. It doesn’t seem like much, but keep in mind that in my hometown I could get a haircut for less than $2, and $10 could buy me at least five burgers and a soda. That said, it was quite an investment for my next job interview. I couldn’t complain though: a total stranger was doing me a favor when I needed it the most, and that raised my spirits. The next week came and I had my interview, which went great. The company I was just fired from was Live Interactive, after all, which happened to be well known in Montevideo due to being one of the biggest internet companies in the country. This meant that programmers coming from there were well regarded. Needless to say, I got the job. The salary wasn’t that great, but our plan of moving to the capital was still intact. Not bad for my first 10 days in Montevideo. Conclusion All in all, my plan had worked, and all my preparation and study paid off. I got my first job interview as a programmer and then passed it. I was hired and fired in the space of one week, but I didn’t give up and went on to secure a second job interview, landing a new position in my second week in Montevideo. But in order for this to happen, the first and most important step was being honest with myself. This allowed me to assess my skills to see what I was good at doing and where I had to improve. Being self aware helped me when I embarked upon the task of creating a program from scratch, because I was realistic about what I could do, but at the same time it forced me to do something about the areas where I was lacking. Additionally, dividing the project into actionable tasks helped me make progress and follow my idea through to completion. But it wasn’t just about skills; I also had to believe in myself, and that self confidence helped me whenever I faced a challenge that seemed like an insurmountable mountain. Meanwhile, humility always kept me in check, reminding me that what I had just climbed was but a little peak from among the many I had yet to climb. Finally, my family and friends offered help and support, and whenever I felt defeated, they kept me focused and reminded me why I was on my journey and what the destination was. In the end, because I persisted, I had become hirable, and now it was time to become an actual programmer.  

We continue the story of Alvaro Videla, as travels to Montevideo, Uruguay for his first developer job interview.  In this episode, Quincy tells the story of Alvaro Videla, who was living in poverty in Uruguay when he decided he wanted to learn to code. He had limited access to books and the internet. But he eventually got a job at Apple and other tech companies.   Article by Alvaro Videla: https://fcc.im/2AMqmfM Read by Quincy Larson: https://twitter.com/ossia Learn to code for free at: https://www.freecodecamp.org Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q   Transcript: Getting the Job During December 2006 and January 2007, I worked hard to get my maps application up and running. While building it, I wanted to learn as many programming notions as possible, trying to cram all the knowledge that would get me ready for the job interview into my head. Out of all the concepts I could learn, I identified the main ones that I thought would be relevant for getting the job. This narrowing of focus is a very important step toward achieving goals, since we don’t want to be all over the place, trying to grasp a bit of every subject but then failing to reach deepness on any of them. For my situation, I understood that I had to learn about object-oriented programming, since that was one of the most important programming techniques in use. On the technological side, I had identified PHP as the key programming language that would land me a job, while learning Flash programming would be the skill that would differentiate me from other candidates. How did I know that? It was a bit of hunch informed by what I was seeing mentioned on the web, along with what the computer magazines were writing about. Even back then, before I had the job, I knew it was very important to learn to understand and analyze the market I wanted to break into, and finding the right websites and publications is a very important step toward this. This is because these resources often have information that points to the ideas, trends, and technologies that we should focus on. Once my app was done and I felt I was ready for the interview, it was time to build my resume. However, I had no idea what should go on a tech resume and what should be left out. I listed things like MS Word and MS Excel as some of my skills, together with Adobe Illustrator and some InDesign. Why not, right? Wrong. Just thinking about that first resume makes me blush. If nothing else, what was clear about it was the message it was signaling: this person is a complete noob. The problem is that as someone trying to break into a new field and start a career, it was difficult to have something to write down on my resume that made me look competent. I had no idea what to include, so I listed everything. Today, if someone presented themselves for a backend developer position listing MS Word as a skill, I’m quite sure that person would be rejected straight away. Even worse, I think I would be the one rejecting a resume like that. But of course, hindsight is 20/20. Once my resume was complete and I got a cell phone number I could be reached at, I applied for the position of PHP programmer at Live Interactive. You’d better believe I read and reread every input box on that online form as I went over a mental checklist. “Did I spell my name correctly? Did I type the right phone number? Let’s double check the email. I don’t want to miss this opportunity because I wrote the wrong address.” I was all nerves, but at some point, I had to hit that send button. Click. Done. Exhalation. “I’ve done it. I’ve applied for my first job.” Once my app was done and I felt I was ready for the interview, it was time to build my resume. However, I had no idea what should go on a tech resume and what should be left out. After I submitted my application, I lingered at the internet cafe, browsing the web for random stuff. To my surprise, about half an hour later, my cellphone started to ring. “I don’t know this number,” I thought. The area code told me it was from Montevideo, but it was so quick, it couldn’t be them. Or could it? It took me a couple of seconds to understand that, yes, in fact, they were calling me! Can you imagine that? I honestly didn’t know what to do. “Should I take the call?” I wondered. “I’m probably not ready for this!” I quickly tried to get ahold of myself and walked outside to answer. “Hi, we’re calling from Live Interactive about your job application. Is this Alvaro Videla?” said the voice on the other end. Do you see what happened right there? I couldn’t believe it! I was being contacted by the company where I had just applied for a job. “Yes, it’s me,” I replied. The caller turned out to be the HR manager getting in touch, trying to set up an interview with me. She asked me when would it be a good time for me, so I told her that I needed a week, since “I have to arrange things here.” This wasn’t necessarily the case, as I could’ve just boarded the next bus and traveled there straightaway, but I wanted to prepare — to be 100 percent ready for it and not botch my only opportunity. I hung up at the end of that phone call having secured a job interview. Now it was time to get myself together and prepare for that interview. I had no doubt this was my once-in-a-lifetime opportunity and I couldn’t waste it. But first, I had to share my excitement with my mother and my wife: I needed to talk about what had happened with someone to help process my emotions. On one hand, all my hard work was starting to pay off, which felt great. But on the other hand, life had allowed me to see a tiny glimpse of a better future. Making that future a reality now rested entirely on my shoulders, but it was too much of a responsibility for me to handle alone. I spent the entire next week preparing for the interview, from reading and rereading the books I had, to trying to guess what kind of clothes I should wear for the interview. I had never worked as a programmer, and as such, I had no idea how the programmer culture worked and what kind of behavior would be expected from me. I didn’t have anyone to ask about this either, so at some point I decided to stop worrying too much about the appearance side and tried to focus on the technical aspect of the process, hoping my skills would speak for themselves. I had no doubt this was my once-in-a-lifetime opportunity and I couldn’t waste it, but first, I had to share my excitement with my mother and my wife: I needed to talk about what had happened with someone to help process my emotions. Unexpected obstacles The time passed quickly, and before I knew it, I was sitting on a two-hour-long bus trip, heading to Montevideo. I had the PHP Bible in my backpack and enough money to buy a burger and pay for the ticket from the bus terminal to the company’s offices in downtown Montevideo. I didn’t want to arrive late, so I was around the area an hour in advance, trying my best to fight off a nervous breakdown. I had to find something to kill time and occupy my worried mind, so I walked to a nearby square, found a bench, and sat down to keep studying. I couldn’t believe that all my struggles over the previous months would be decided in about an hour. “Did I prepare the best I could? That time I didn’t want to study that part of the book so I could go outside, was it worth it?” I wondered. Then I came to my senses. “Stop it,” I told myself. “It’s time to focus on the book in front of me right now, since there’s no reason for worrying about could haves.” Soon, it was time to head up for the interview. If this was a Tarantino film, my character would probably be called Mr. Blue: dark blue jeans, blue shirt, and dark blue hoodie. I got to the reception area and was welcomed by the HR manager, who I’d spoken to on the phone the week before. She asked me to sit and wait and offered me a glass of water. I took the offer and immediately started doubting myself. “Is this the right thing to do?” I wondered. “Am I being polite or impolite?” Anxiety was taking over. Meanwhile, people were walking around, going from one office to another. “Are any of them my interviewer?” I asked myself, studying each person who walked by. One man walked up to the HR manager and started talking. “Ah, it must be him,” I thought. But it wasn’t. After more of this wondering, the HR manager called my name and took me into a big conference room. She handed me a pile of paper and told me this was the first part of the interview: a psychological test with more than 100 behavioral and situational questions. What. Is. This? Nowhere in the PHP Bible did it mention that people needed to pass psychological tests to become a programmer! But I tried the best I could, second guessing the intention of every question. Of course, I had no idea if the answers I was choosing were correct, but I hoped they would bring me one step closer to getting the job I wanted. Once I was done, I returned the papers with my answers and then was asked to take a seat again and wait for the next stage. Soon the HR manager introduced me to someone who was going to conduct the programming interview. “Now or never,” I thought. “Now or never.” At that moment, I felt that all the pressure was on me, that I couldn’t let down my wife, my mom, my family. “If I don’t get this job, let it be known that it wasn’t because I got blocked mid interview, and didn’t know what to do,” I thought. “If I don’t pass the next stage, it’d better be because they didn’t want me, and not because I lacked the knowledge or preparation.”  

In this episode, Quincy tells the story of Alvaro Videla, who was living in poverty in Uruguay when he decided he wanted to learn to code. He had limited access to books and the internet. But he eventually got a job at Apple and other tech companies.   Article by Alvaro Videla: https://fcc.im/2fRSzwM Read by Quincy Larson: https://twitter.com/ossia Learn to code for free at: https://www.freecodecamp.org Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q Transcript: At the end of 2006, I arrived at a crossroads in my life. My hopes of becoming a secondary school linguistics teacher had vanished in an instant, as several factors had come together and made it impossible for me to continue with my studies. Back in my hometown of Durazno, Uruguay, my wife was working long hours for a meager $160 (USD) a month. Yes, that’s $1,920 a year. We had sacrificed our time together so I could become a teacher and get a better job because we were dreaming of a better future. The problem with dreams is they tend to vanish when you wake up, and life’s alarm clock had just gone off. Because my career trajectory had suddenly strayed off course, I moved back to my hometown to figure out my next steps. Needless to say, I was depressed at the way things were, and our living situation only made things worse. It was good to be back with my wife, but the reasons for it were stressful. Additionally, we were sharing a house with my wife’s aunt, so our privacy was restricted to our bedroom, and we always felt like we were overstaying our welcome. As a way to bring in extra income, we tried to sell homemade pasta on the streets. I would go door-to-door collecting orders for the weekend. “Hello, do you want to order ravioli to eat this Sunday?” I’d ask person after person. “Yes, they’re homemade. Just give us a time and we’ll deliver them.” Then, after people ordered them, we spent our entire weekends making 2,000 ravioli only to end up with 500 pesos in our pockets, which comes about $20, not counting expenses. The whole situation was disheartening, and it made us feel hopeless. My wife would work hard all week, then come home only to spend her weekends helping me prepare the ravioli. She couldn’t even have one day of the weekend for herself. She begged me to stop selling ravioli, even if that meant we would end up with less money to pay our bills. Eventually I agreed, but it meant I had to try to find a job — and finding a job wasn’t so easy in our rural hometown. Anxiety and desperation were starting to set in. One night, I was talking with a friend who was studying computer engineering at the university in Montevideo. He told me about the various job opportunities one could find in the capital city, with salaries that were the stuff of dreams for someone living in the countryside. “There’s this big company in Montevideo, Live Interactive,” he told me. “They’re always looking for programmers; maybe you could try to get a job there. They pay really well.” The salary he mentioned was around three times what we were making at the time, and I couldn’t help but imagine all the things we could do with that much money. We wouldn’t need to worry anymore about putting food on the table. We could finally pay for our own internet connection, get proper clothes and shoes, and even have our own washing machine! Not only that, but I already had experience with computers. I always liked working with them, mostly because they appealed to my knack for problem solving. Programming reminded me of having to crack a code or find the solution to a difficult puzzle — but in addition to being challenging, it was fun. What’s more is that I saw programming as a career with a lot of potential for growth. But there was one small problem: to work as a computer programmer, one usually needs to know how to program computers. Me? I could install Linux on my own, but that was probably the extent of it. How do you land a job as a computer programmer when you have almost no programming experience and you lack a university degree to prove your knowledge? How do you learn to program without internet access at home, without mentors to connect with, and without access to programming books? That was my problem back in 2006, and this is the story of how I tackled it. The Early Days I’ve been dabbling with computers since I was a teenager — most of the time when visiting a friend who had a PC. While we often used the computer to play games, I wasn’t interested in playing that much. Why? Back when I started secondary school, a friend’s father let us use his ZX Spectrum computer. He had good stack of cassettes with plenty of games for it, and of course, we could play all we wanted, but one day he showed me something that blew my mind: people could make their own games by programming the computer! He showed me some tricks in BASIC, like how you could generate random numbers using the RAND function. I was amazed. At that point, I realized computers were more than a glorified Nintendo with a keyboard: you could actually tell them to do things for you — cool things, like drawing lines using trigonometric functions and then painting them by applying random colors! You could even make music with them by passing different frequencies to BEEP. In fact, once I brought the Spectrum to my house and spent an entire afternoon playing different kinds of beep sounds on my TV — I’m sure my mom loved it. How do you land a job as a computer programmer when you have almost no programming experience and you lack a university degree to prove your knowledge? Later on, during my teenage years, I continued spending time with friends who had their own computers, and naturally we played games on them. Meanwhile, with my more tech-savvy friends, I learned a few operating system tricks — mostly MS-DOS. Every once in awhile, we would try some BASIC programming by copying, character by character, the code snippets that appeared in old computer magazines. To us, they seemed like magic spells or technological incantations. One thing we really liked was trying to edit the text messages a game would show for different situations. We thought we were such hackers! By the early 2000s, I managed to convince my grandfather to buy me a computer: a Pentium MMX with 32MB of RAM! What a machine! I installed Linux on it for the first time, using a SUSE CD that came for free with an Argentinean computer magazine. I spent quite a lot of time on that computer: trying different Linux distributions, getting familiarized with the command line, and so on, but never really doing any programming. When I look back to those days, I can’t understand why I wasn’t learning C programming — or any kind of programming for that matter. A friend even offered me the bible of C programming by Kernighan and Ritchie, so not having access to a manual wasn’t an excuse. But for some reason, after reading a few examples, it didn’t spark any interest in me, as I didn’t understand how what it covered would be useful for me. In any case, playing with Linux was the only thing I was doing with computers back then. From that point on, I had several minor jobs, played in a rock ’n’ roll band, and tried to become a linguistics teacher, all while getting married and moving all over the country together with my wife. Fast forward to November 2006 and I found myself in need of somehow becoming hirable by a software company. I had to become a credible computer programmer. Time for Some Goals If I wanted to get hired, the first thing to do was evaluate my skillset as a programmer. I had to be honest with myself so I could know where to focus my efforts. At the time, I knew a bit of ActionScript for Flash MX and the very basics of PHP programming. Earlier that year, I had started learning those technologies as a hobby. I’d also started a pet project to learn programming, thinking maybe it could become a secondary source of income. I came up with the idea of making a digital map of my hometown where you could drop pins that would point the user to the location of businesses, shops, and interesting locations. I would then charge those businesses money in exchange for appearing in my online map application. Of course I know what you’re thinking. “That’s just Google Maps,” you say. Yes, but back in 2006, the only thing Google Maps knew about my hometown was that it was crossed by a big national highway. Given that, my map seemed like a good idea. Also, I figured this project would be the perfect way to showcase my skills to a prospective employer. I had a clear goal of what I wanted to build; I just had to get down to work and make it happen. So at the end of 2006, I set myself a deadline: come February 2007, I had to have a working concept of the map application. This had to include a Flash frontend, served by a PHP backend, using MySQL for data persistence. The technologies I’ve just mentioned might not seem too relevant today, but the point here is that I had to nail down every detail of my plan so I would know which problems to tackle first, since time was ticking: every day that went by was another day where my wife was overloaded, working overtime to get food on our table. Additionally, to even have a shot at getting a programming job, I had to show potential employers that I could program in those particular technologies, because that was part of the job description. Naturally, I had nothing related to these skills on my resume, so I had to build up my knowledge from scratch, and my app would serve as the showcase of my programming expertise. The plan was to land an interview at the company my friend had mentioned before, and hopefully, with the combination of my skills and my app, I would end up getting a job there. Even then, I knew the importance of setting clear goals for yourself in order to achieve what you want. Learning project: a Map Application The map application I created was called Aleph Maps — a reference to Jorge Luis Borges’ 1949 story, “El Aleph,” about a place in the universe where everything — past, present, and future — is contained. Not ambitious at all, right? And to bring the idea into existence, I would have to learn how to program web apps. Having no internet at home is a real challenge for a future web developer. When I started, ADSL broadband adoption was almost nonexistent, limited only to businesses and maybe wealthy households. For the average family, connecting to the internet meant dialing in on a modem connection and paying high prices for a slow internet experience. I couldn’t afford that, which meant I had to go and bother friends every time I needed to access some online tutorial that explained how to program in PHP. So even though I had a computer and the will to learn, I still didn’t have easy or regular access to the information on how to do it. But I was determined to get that job, and I knew that even these setbacks wouldn’t deter me from learning PHP. When you don’t have time to waste, you don’t have time to feel desperate; instead, you have to focus on finding solutions. Meanwhile, due to the lack of internet access around town, cyber cafes started popping up in the city, charging around half a dollar for one hour of surfing. This struck me as a better solution than constantly bothering my friends. But this also meant finding an extra 50 cents and a couple of floppy disks in order to get to a cyber cafe, find the information I wanted, copy it onto one of those diskettes, and get it home onto my computer. More often than not, data got corrupted in the process of extracting it from the floppy disks. Imagine how angry and frustrated I was: I had made a trip to a cyber cafe and wasted 50 cents for nothing. Half a dollar! This might not sound like much, but at that time where we lived, you could buy a burger or a bottle of beer for a dollar. For us, it was a lot of money: it meant our daily bottle of milk or a loaf of bread. During those days, my routine consisted of trying to solve problem A to get to point B. Sometimes the tasks were rather easy and I felt like I was making quick progress. Other days, it felt like I was going nowhere. For example, say I had to implement a feature like “insert new data into the database.” This meant writing down all the obstacles I had to solve to achieve that — from how to write an SQL INSERT statement to how to execute it using PHP — and then integrating everything into the app. Each of these tasks was an item on my daily “shopping list” for when I went to the internet cafe. I would take a couple of floppy disks with me, and then I would google for blog posts, tutorials, and guides that would help me solve the items on my list. Once that was complete, it was time to save them on my diskettes and head home, all the while hoping the data had successfully saved and would be easily accessed on my computer. Because of the uncertainty involved, the bicycle trip back would be fueled by the worst anxiety ever. “What if the data isn’t there at all?” I wondered. “What if the bike shakes too much and the data gets corrupted? I really don’t have another dollar to spare until tomorrow, so this better work when I get home.” I was determined to get that job, and I knew that even these setbacks wouldn’t deter me from learning PHP. When you don’t have time to waste, you don’t have time to feel desperate; instead, you have to focus on finding solutions. Suffice to say, this wasn’t practical at all. Once I was back home, I’d use the information I’d brought back to help me accomplish the task in progress, but once it was complete, I lacked the knowledge to perform the next step. This means I was left sitting at home, thinking about a problem, and waiting until the next day, when I could squeeze another 50 cents out of our budget to go to the cafe and repeat this routine. Though at the time it seemed like my only option, eventually I had to admit to myself that it was time for a new strategy. I needed something that contained most of the information on how to write a web application with PHP and Flash MX, with guides explaining how to perform the most trivial of tasks, all in one single place. Not the internet, but books! It seems like such a no-brainer, but for someone in my situation, the kinds of books I needed weren’t necessarily in reach. The problem is that when you’re part of a marginalized sector of society, accessing books isn’t so easy. The closest thing to a programming book you could find at the public library would be some outdated manual on how to repair a computer — maybe some dusty MS-DOS guide, or perhaps a BASIC or Delphi book if you got lucky — but not much more. Well, at least one could buy books, right? Not really. In most towns in Uruguay’s countryside, technical books are usually absent from the bookstore shelves, and my town was no exception. Add to the problem the fact that most of the tech books — particularly those talking about cutting-edge technology — are written in English, and you can just forget about the local bookstore. In the end, this left me with only one option: Amazon. But it wasn’t that easy either. To buy books on Amazon, you need a little piece of plastic called a credit card, but to get access to a credit card, you need a good credit history — which for most people is not a problem. In my case, though, I was living in a completely different world: everything we bought was paid for in cash. We didn’t have the money or the economical certainty to enter into a credit plan. For us, it worked like this: if we wanted to buy something more expensive than our monthly income, we either saved month after month until we got enough money to buy what we wanted, or we asked some family member to buy the product for us and worked to pay them back later. And even if we’d had the option of buying books on Amazon, we hadn’t factored in the fact that shipping alone from the United States to Uruguay was nearly the cost of the book, not to mention it would take a month for it to arrive. In my case, though, I was living in a completely different world: everything we bought was paid for in cash. We didn’t have the money or the economical certainty to enter into a credit plan Sometimes the solution to these kinds of problems is closer to home than we think. Eventually, we ended up resorting to asking for help from family. My wife has an aunt who had been living in the US for quite a while, so we figured it was worth a shot to ask and see if she would buy me a couple of programming books. So on one of my internet excursions, I wrote an email to her explaining my situation, hit send, and basically crossed my fingers and prayed to every deity out there that she would help us. After a couple of days, I had a new email in my inbox. It was her answer, straight to the point: “Tell me which books you need and I’ll order them from Amazon.” After doing some research, I ended up asking for the Flash MX Bible and the PHP 5 and MySQL Bible. Those two books proved incredibly helpful in the weeks to come. They were both so thorough that I was able to make steady progress without needing to constantly visit the internet cafe in search of missing information. I could finally make headway on understanding what I needed to know to build my maps application. And finally, with access to the information I needed, it was time to sit down in front of my computer and get to work.   At the end of 2006, I arrived at a crossroads in my life. My hopes of becoming a secondary school linguistics teacher had vanished in an instant, as several factors had come together and made it impossible for me to continue with my studies. Back in my hometown of Durazno, Uruguay, my wife was working long hours for a meager $160 (USD) a month. Yes, that’s $1,920 a year. We had sacrificed our time together so I could become a teacher and get a better job because we were dreaming of a better future. The problem with dreams is they tend to vanish when you wake up, and life’s alarm clock had just gone off. Because my career trajectory had suddenly strayed off course, I moved back to my hometown to figure out my next steps. Needless to say, I was depressed at the way things were, and our living situation only made things worse. It was good to be back with my wife, but the reasons for it were stressful. Additionally, we were sharing a house with my wife’s aunt, so our privacy was restricted to our bedroom, and we always felt like we were overstaying our welcome. As a way to bring in extra income, we tried to sell homemade pasta on the streets. I would go door-to-door collecting orders for the weekend. “Hello, do you want to order ravioli to eat this Sunday?” I’d ask person after person. “Yes, they’re homemade. Just give us a time and we’ll deliver them.” Then, after people ordered them, we spent our entire weekends making 2,000 ravioli only to end up with 500 pesos in our pockets, which comes about $20, not counting expenses. The whole situation was disheartening, and it made us feel hopeless. My wife would work hard all week, then come home only to spend her weekends helping me prepare the ravioli. She couldn’t even have one day of the weekend for herself. She begged me to stop selling ravioli, even if that meant we would end up with less money to pay our bills. Eventually I agreed, but it meant I had to try to find a job — and finding a job wasn’t so easy in our rural hometown. Anxiety and desperation were starting to set in. One night, I was talking with a friend who was studying computer engineering at the university in Montevideo. He told me about the various job opportunities one could find in the capital city, with salaries that were the stuff of dreams for someone living in the countryside. “There’s this big company in Montevideo, Live Interactive,” he told me. “They’re always looking for programmers; maybe you could try to get a job there. They pay really well.” The salary he mentioned was around three times what we were making at the time, and I couldn’t help but imagine all the things we could do with that much money. We wouldn’t need to worry anymore about putting food on the table. We could finally pay for our own internet connection, get proper clothes and shoes, and even have our own washing machine! Not only that, but I already had experience with computers. I always liked working with them, mostly because they appealed to my knack for problem solving. Programming reminded me of having to crack a code or find the solution to a difficult puzzle — but in addition to being challenging, it was fun. What’s more is that I saw programming as a career with a lot of potential for growth. But there was one small problem: to work as a computer programmer, one usually needs to know how to program computers. Me? I could install Linux on my own, but that was probably the extent of it. How do you land a job as a computer programmer when you have almost no programming experience and you lack a university degree to prove your knowledge? How do you learn to program without internet access at home, without mentors to connect with, and without access to programming books? That was my problem back in 2006, and this is the story of how I tackled it. The Early Days I’ve been dabbling with computers since I was a teenager — most of the time when visiting a friend who had a PC. While we often used the computer to play games, I wasn’t interested in playing that much. Why? Back when I started secondary school, a friend’s father let us use his ZX Spectrum computer. He had good stack of cassettes with plenty of games for it, and of course, we could play all we wanted, but one day he showed me something that blew my mind: people could make their own games by programming the computer! He showed me some tricks in BASIC, like how you could generate random numbers using the RAND function. I was amazed. At that point, I realized computers were more than a glorified Nintendo with a keyboard: you could actually tell them to do things for you — cool things, like drawing lines using trigonometric functions and then painting them by applying random colors! You could even make music with them by passing different frequencies to BEEP. In fact, once I brought the Spectrum to my house and spent an entire afternoon playing different kinds of beep sounds on my TV — I’m sure my mom loved it. How do you land a job as a computer programmer when you have almost no programming experience and you lack a university degree to prove your knowledge? Later on, during my teenage years, I continued spending time with friends who had their own computers, and naturally we played games on them. Meanwhile, with my more tech-savvy friends, I learned a few operating system tricks — mostly MS-DOS. Every once in awhile, we would try some BASIC programming by copying, character by character, the code snippets that appeared in old computer magazines. To us, they seemed like magic spells or technological incantations. One thing we really liked was trying to edit the text messages a game would show for different situations. We thought we were such hackers! By the early 2000s, I managed to convince my grandfather to buy me a computer: a Pentium MMX with 32MB of RAM! What a machine! I installed Linux on it for the first time, using a SUSE CD that came for free with an Argentinean computer magazine. I spent quite a lot of time on that computer: trying different Linux distributions, getting familiarized with the command line, and so on, but never really doing any programming. When I look back to those days, I can’t understand why I wasn’t learning C programming — or any kind of programming for that matter. A friend even offered me the bible of C programming by Kernighan and Ritchie, so not having access to a manual wasn’t an excuse. But for some reason, after reading a few examples, it didn’t spark any interest in me, as I didn’t understand how what it covered would be useful for me. In any case, playing with Linux was the only thing I was doing with computers back then. From that point on, I had several minor jobs, played in a rock ’n’ roll band, and tried to become a linguistics teacher, all while getting married and moving all over the country together with my wife. Fast forward to November 2006 and I found myself in need of somehow becoming hirable by a software company. I had to become a credible computer programmer. Time for Some Goals If I wanted to get hired, the first thing to do was evaluate my skillset as a programmer. I had to be honest with myself so I could know where to focus my efforts. At the time, I knew a bit of ActionScript for Flash MX and the very basics of PHP programming. Earlier that year, I had started learning those technologies as a hobby. I’d also started a pet project to learn programming, thinking maybe it could become a secondary source of income. I came up with the idea of making a digital map of my hometown where you could drop pins that would point the user to the location of businesses, shops, and interesting locations. I would then charge those businesses money in exchange for appearing in my online map application. Of course I know what you’re thinking. “That’s just Google Maps,” you say. Yes, but back in 2006, the only thing Google Maps knew about my hometown was that it was crossed by a big national highway. Given that, my map seemed like a good idea. Also, I figured this project would be the perfect way to showcase my skills to a prospective employer. I had a clear goal of what I wanted to build; I just had to get down to work and make it happen. So at the end of 2006, I set myself a deadline: come February 2007, I had to have a working concept of the map application. This had to include a Flash frontend, served by a PHP backend, using MySQL for data persistence. The technologies I’ve just mentioned might not seem too relevant today, but the point here is that I had to nail down every detail of my plan so I would know which problems to tackle first, since time was ticking: every day that went by was another day where my wife was overloaded, working overtime to get food on our table. Additionally, to even have a shot at getting a programming job, I had to show potential employers that I could program in those particular technologies, because that was part of the job description. Naturally, I had nothing related to these skills on my resume, so I had to build up my knowledge from scratch, and my app would serve as the showcase of my programming expertise. The plan was to land an interview at the company my friend had mentioned before, and hopefully, with the combination of my skills and my app, I would end up getting a job there. Even then, I knew the importance of setting clear goals for yourself in order to achieve what you want. Learning project: a Map Application The map application I created was called Aleph Maps — a reference to Jorge Luis Borges’ 1949 story, “El Aleph,” about a place in the universe where everything — past, present, and future — is contained. Not ambitious at all, right? And to bring the idea into existence, I would have to learn how to program web apps. Having no internet at home is a real challenge for a future web developer. When I started, ADSL broadband adoption was almost nonexistent, limited only to businesses and maybe wealthy households. For the average family, connecting to the internet meant dialing in on a modem connection and paying high prices for a slow internet experience. I couldn’t afford that, which meant I had to go and bother friends every time I needed to access some online tutorial that explained how to program in PHP. So even though I had a computer and the will to learn, I still didn’t have easy or regular access to the information on how to do it. But I was determined to get that job, and I knew that even these setbacks wouldn’t deter me from learning PHP. When you don’t have time to waste, you don’t have time to feel desperate; instead, you have to focus on finding solutions. Meanwhile, due to the lack of internet access around town, cyber cafes started popping up in the city, charging around half a dollar for one hour of surfing. This struck me as a better solution than constantly bothering my friends. But this also meant finding an extra 50 cents and a couple of floppy disks in order to get to a cyber cafe, find the information I wanted, copy it onto one of those diskettes, and get it home onto my computer. More often than not, data got corrupted in the process of extracting it from the floppy disks. Imagine how angry and frustrated I was: I had made a trip to a cyber cafe and wasted 50 cents for nothing. Half a dollar! This might not sound like much, but at that time where we lived, you could buy a burger or a bottle of beer for a dollar. For us, it was a lot of money: it meant our daily bottle of milk or a loaf of bread. During those days, my routine consisted of trying to solve problem A to get to point B. Sometimes the tasks were rather easy and I felt like I was making quick progress. Other days, it felt like I was going nowhere. For example, say I had to implement a feature like “insert new data into the database.” This meant writing down all the obstacles I had to solve to achieve that — from how to write an SQL INSERT statement to how to execute it using PHP — and then integrating everything into the app. Each of these tasks was an item on my daily “shopping list” for when I went to the internet cafe. I would take a couple of floppy disks with me, and then I would google for blog posts, tutorials, and guides that would help me solve the items on my list. Once that was complete, it was time to save them on my diskettes and head home, all the while hoping the data had successfully saved and would be easily accessed on my computer. Because of the uncertainty involved, the bicycle trip back would be fueled by the worst anxiety ever. “What if the data isn’t there at all?” I wondered. “What if the bike shakes too much and the data gets corrupted? I really don’t have another dollar to spare until tomorrow, so this better work when I get home.” I was determined to get that job, and I knew that even these setbacks wouldn’t deter me from learning PHP. When you don’t have time to waste, you don’t have time to feel desperate; instead, you have to focus on finding solutions. Suffice to say, this wasn’t practical at all. Once I was back home, I’d use the information I’d brought back to help me accomplish the task in progress, but once it was complete, I lacked the knowledge to perform the next step. This means I was left sitting at home, thinking about a problem, and waiting until the next day, when I could squeeze another 50 cents out of our budget to go to the cafe and repeat this routine. Though at the time it seemed like my only option, eventually I had to admit to myself that it was time for a new strategy. I needed something that contained most of the information on how to write a web application with PHP and Flash MX, with guides explaining how to perform the most trivial of tasks, all in one single place. Not the internet, but books! It seems like such a no-brainer, but for someone in my situation, the kinds of books I needed weren’t necessarily in reach. The problem is that when you’re part of a marginalized sector of society, accessing books isn’t so easy. The closest thing to a programming book you could find at the public library would be some outdated manual on how to repair a computer — maybe some dusty MS-DOS guide, or perhaps a BASIC or Delphi book if you got lucky — but not much more. Well, at least one could buy books, right? Not really. In most towns in Uruguay’s countryside, technical books are usually absent from the bookstore shelves, and my town was no exception. Add to the problem the fact that most of the tech books — particularly those talking about cutting-edge technology — are written in English, and you can just forget about the local bookstore. In the end, this left me with only one option: Amazon. But it wasn’t that easy either. To buy books on Amazon, you need a little piece of plastic called a credit card, but to get access to a credit card, you need a good credit history — which for most people is not a problem. In my case, though, I was living in a completely different world: everything we bought was paid for in cash. We didn’t have the money or the economical certainty to enter into a credit plan. For us, it worked like this: if we wanted to buy something more expensive than our monthly income, we either saved month after month until we got enough money to buy what we wanted, or we asked some family member to buy the product for us and worked to pay them back later. And even if we’d had the option of buying books on Amazon, we hadn’t factored in the fact that shipping alone from the United States to Uruguay was nearly the cost of the book, not to mention it would take a month for it to arrive. In my case, though, I was living in a completely different world: everything we bought was paid for in cash. We didn’t have the money or the economical certainty to enter into a credit plan Sometimes the solution to these kinds of problems is closer to home than we think. Eventually, we ended up resorting to asking for help from family. My wife has an aunt who had been living in the US for quite a while, so we figured it was worth a shot to ask and see if she would buy me a couple of programming books. So on one of my internet excursions, I wrote an email to her explaining my situation, hit send, and basically crossed my fingers and prayed to every deity out there that she would help us. After a couple of days, I had a new email in my inbox. It was her answer, straight to the point: “Tell me which books you need and I’ll order them from Amazon.” After doing some research, I ended up asking for the Flash MX Bible and the PHP 5 and MySQL Bible. Those two books proved incredibly helpful in the weeks to come. They were both so thorough that I was able to make steady progress without needing to constantly visit the internet cafe in search of missing information. I could finally make headway on understanding what I needed to know to build my maps application. And finally, with access to the information I needed, it was time to sit down in front of my computer and get to work.