The freeCodeCamp Podcast

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.