I've answered technical questions one-on-one with the CTO and in a group with the dev team. I've taken quizzes with a timer and built features into existing apps in live mode.

I've live coded algorithms, done take home assignments, and demonstrated my system design skills.

And all this has given me a lot of knowledge and experience that I want to share with you now.

In this guide, I'll share my top tips, recommendations, and checklists to help you prepare for and pass your technical interviews. These will level up your game and increase your chances of getting a job.

What We'll Cover:

• Introduction

• The Secret That Will Increase Your Interview Performance By 53% (at Least It Did For Me)

  • 1. Big Tech / FAANG-level Companies

  • 2. Mid-size Product Companies / SaaS

  • 3. Startups (Early-stage)

  • 4. Design Agencies / Creative Studios

  • 5. Enterprise / Corporate Companies

  • 6. E-commerce & Marketing Agencies

  • 7. AI-first / Modern Tech Companies

  • 8. Freelance / Indie / Micro-SaaS

• Step 1: Building a Strong Foundation in Core Web Development Concepts

• Step 2: Going Deeper Into Subject Matter

• Interview Preparation Guide

  • 1. Answer Technical Questions (1-on-1 / Many-to-1)

  • 2. Go Through Quizzes with a Timer

  • 3. Build Features into Existing Apps (Live Mode)

  • 4. Live Code Algorithms

  • 5. Take Home Assignments

  • 6. System Design

  • A Fun Story

• Most Important Part

  • PDCA Framework

• Conclusion

  • P.S.

Introduction

The technical interview is designed to test how you think, code, and communicate. It's about both explaining your reasoning and showing what you can do. Think of it like a performance: the more you practice, the more natural and confident you’ll feel when you're actually doing it.

You’ll usually go through three main steps:

• Technical screening: a short 15–30 minute call to check your basics and interest in the role.

• Coding challenge: you’ll solve problems either through a take-home project or a live coding test. This shows how you write, structure, and test your code.

• Whiteboard interview: you solve problems on a shared screen while explaining your thinking out loud. It’s less about being perfect and more about how you approach problems.

During these stages, interviewers focus on a few key areas:

• Data structures: Ways to organize data (like folders in a filing system).

• Algorithms: Step-by-step methods to solve problems.

• System design (for senior roles): Planning how large systems work, similar to designing a building that supports many users at once.

Overall, they’re looking at how you think, not just what you know.

The Secret That Will Increase Your Interview Performance By 53% (at Least It Did For Me)

The secret is: narrow your focus.

Before you spend even one minute preparing, specify exactly what type of company you want to work for.

Why?

Because this choice will reveal what exactly you'll have study and practice before your technical interview.

Let's go over the main categories of companies so you can work on narrowing your focus.

1. Big Tech / FAANG-level Companies

(Google, Amazon, Meta, Apple, Microsoft)

Core skills:

• Data structures & algorithms

• System design (scalability, distributed systems)

• Computer science fundamentals (OS, networking)

2. Mid-size Product Companies / SaaS

(Shopify, Stripe, Notion)

Core skills:

• Strong stack knowledge (React, Next.js, Node.js)

• API design & integrations

• Database design (SQL/NoSQL)

3. Startups (Early-stage)

Core skills:

• Full-stack development

• Rapid prototyping

• Shipping features end-to-end

4. Design Agencies / Creative Studios

Core skills:

• Advanced HTML, CSS, JavaScript

• Animation (GSAP, Framer Motion)

• Pixel-perfect implementation

5. Enterprise / Corporate Companies

Core skills:

• Backend development (Java, .NET, and so on)

• Databases (SQL, enterprise systems)

• APIs & microservices

6. E-commerce & Marketing Agencies

Core skills:

• Shopify / WordPress

• Frontend development

• SEO & performance optimization

7. AI-first / Modern Tech Companies

(OpenAI, Anthropic)

Core skills:

• AI API integration (LLMs, embeddings)

• Prompt engineering

• Backend & data handling

8. Freelance / Indie / Micro-SaaS

Core skills:

• Full-stack development (Next.js)

• Payments & authentication systems

• Deployment & basic marketing

Keep in mind that these are just high-level recommendations. There are, of course, other skills you'll need to focus on depending on the role you're hoping to get. This is just a general guideline to get you started.

Also, fun fact: if you ask a top FAANG developer to code an Awwwards-style landing page, they'll most likely fail. And similarly, an award-winning web designer from a top notch agency will probably perform poorly at an algorithm assignment. Why? Each field requires its own skillset. So make sure you choose and focus on yours.

Step 1: Building a Strong Foundation in Core Web Development Concepts

So, now I assume that you've decided on the type of company you want to work for.

The next step is check whether you have or need to work on the basic fundamentals. Most candidates fail not because they lack experience, but because their basics are shaky.

A solid foundation makes everything else easier: coding challenges, system design, and even real-world tasks.

Focus on learning the core building blocks:

• HTML & CSS

• JavaScript fundamentals

• One solid framework: Get really good at one stack (like React + Next.js).

• APIs & backend basics: Learn how data flows. Understand REST APIs, authentication, and how frontend connects to backend.

• Databases: Know the difference between SQL and NoSQL. Be comfortable with basic queries and data modeling.

• Git & workflows: You should be confident with version control, branching, and collaborating on code.

The goal is not to know everything. The goal is to be clear, confident, and consistent in the fundamentals.

If your basics are strong, you’ll solve problems faster, explain your thinking better, and stand out naturally in interviews.

One of the most effective ways to get better at fundamentals is by practicing with flashcards. I've created a system called the 99cards app that can help with this if you want to check it out.

Step 2: Going Deeper Into Subject Matter

By this step, you've chosen the type of company you want to work for and you're confident that you know core web development skills.

Next, you'll need to practice specific skills related to your company and preferred job type (for example algorithms or building features in live mode).

Hint: In about 80% of cases, the first step is an HR interview. This happens before the technical round. Use this opportunity to your advantage.

When I get invited to a technical interview, the first thing I do is ask the HR manager what I should prepare. Just a simple question – and surprisingly, I almost always get a clear answer concerning:

• What topics to focus on

• What kind of tasks to expect

• Sometimes even tools or formats they’ll use

This gives you a huge advantage. Instead of guessing, you can prepare with intention.

Interview Preparation Guide

1. Answer Technical Questions (1-on-1 / Many-to-1)

This is usually a conversation with a CTO or a full dev team. They'll want to understand how you think, not just what you know. Stay calm and treat it like a discussion, not an exam.

Keep your answers simple and structured:

• Explain your thought process step by step

• Use real examples from your experience

• If you don’t know something, say it and think out loud

In many-to-one interviews, don’t get overwhelmed. Focus on one question at a time and engage with the person speaking.

For example, when I was looking to hire a web developer for my micro SaaS, I didn't care about algorithms, but I cared deeply that they have thorough Next JS skills.

For that, I tested candidates via flashcards in live mode.

How to effectively prepare

Practice explaining concepts out loud, not just in your head. Pretend you’re teaching someone.

Do mock interviews with a friend or record yourself. Focus on clarity and structure.

• Prepare stories from past projects

• Review core concepts (JS, React, APIs)

• Practice saying “I don’t know” confidently

2. Go Through Quizzes with a Timer

Timed quizzes test your speed and basics. These are often multiple-choice or short coding questions. The goal is accuracy under pressure.

A few tips:

• Don’t spend too long on one question. Skip and come back if needed.

• Practice common patterns beforehand.

Speed improves with repetition. Train like it’s a game.

How to effectively prepare

Use platforms with timed tests to simulate pressure. Track your speed and accuracy.

Focus on common topics that appear often.

• JavaScript fundamentals

• Basic algorithms

• Output-based questions

Practice daily in short sessions. Consistency beats long study sessions.

3. Build Features into Existing Apps (Live Mode)

During technical interviews, you’ll often work on a real or mock project. This tests how you read code, understand structure, and make changes safely.

Focus on:

• Understanding the codebase first

• Asking clarifying questions

• Writing clean, simple solutions

Talk while you work. Explain what you’re doing and why.

How to effectively prepare

Practice working with someone else's codebase (not your own). Clone open-source projects and explore them, for example.

Train your ability to navigate and understand code quickly.

• Read files before coding

• Trace data flow

• Make small, safe changes

Also practice explaining your actions while coding.

4. Live Code Algorithms

This is where many developers struggle. You’ll solve problems in real time while explaining your thinking.

Don’t rush to code. First:

• Clarify the problem

• Talk through your approach

• Start with a simple solution, then improve it

Interviewers care more about your thinking than a perfect answer.

How to effectively prepare

Practice common algorithm problems regularly. Focus on patterns, not memorization.

Solve problems out loud, as if someone is listening.

• Arrays, strings, hash maps

• Sorting and searching

• Basic recursion

Time yourself and review your solutions after.

5. Take Home Assignments

These simulate real work. You get time to build something properly. This is your chance to stand out.

What matters most:

• Clean, readable code

• Good structure and naming

• Clear README with your decisions

Don’t overbuild. Focus on quality, not quantity. A smaller, more focused take-home project that's done is better than an overly complex or overly ambitious one that's incomplete.

How to effectively prepare

Build small projects with real-world structure. Practice finishing, not just starting.

Pay attention to presentation and clarity.

• Write clean commits

• Add a clear README

• Handle edge cases

Think like you’re submitting work to a real client.

6. System Design

This is common for mid to senior roles. You’ll design a system from scratch or improve an existing one.

Start simple, then expand:

• Define the requirements

• Sketch a basic architecture

• Discuss scaling, performance, and trade-offs

Think like a builder, not just a programmer. Show how you make decisions.

How to effectively prepare

Study common system design patterns and real-world architectures. Start with simple systems.

Practice breaking problems into parts.

• APIs and data flow

• Databases and caching

• Scaling basics

Watch system design interviews and practice explaining your ideas clearly.

For each of these interviews you can use my free checklists to prepare even more effectively.

A Fun Story

Once I applied to a front-end web developer job at company that focuses on building Awwwards-style websites. The tech interview was take home assignment: I had to rebuild Figma design into a modern GSAP-animated website. I failed to do that.

In 18 months, the same company had an open position. I applied. Can you guess what the tech assignment was? 😄

It was the same.

Draw your own conclusions.

Most Important Part

Here's a helpful framework to keep in mind when you're going through this process:

PDCA Framework

P - plan
D - do
C - check
A- act

It's my go to framework for every subject I want to get better at. Let me explain how to apply this to tech interviews.

Plan: in this stage, you plan your preparation routine and work on your interview performance game.

Do: in this stage, you're actually trying to do what you have planned.

Check: here, you compare your Plan and Do stages. Analyze the difference and see what you can improve.

Act: finally, make adjustments that will help improve Plan 2.0.

Repeat until you get the desired result.

Conclusion

Technical interviews are not about being perfect. They’re about showing how you think, communicate, and solve problems under pressure. The more you practice the right way, the more confident and natural you’ll feel.

Focus on the basics, prepare for your target company, and train in real interview conditions. If you do that, you’ll already be ahead of most candidates.

P.S.

If you want to speed up your prep and stop guessing, I put together a complete toolkit for you.

It contains:

• Interview Checklists

• CV Template

• Cover Letter Template

• List of Top 50 Remote-First Companies

• Job Application Tracker Spreadsheet

You can find it here: 99cards.dev/toolkit

If you’re a junior, mid-level, or self-taught developer who keeps getting rejected and you don’t fully understand why, I hope this helps.

Here’s what I’ll cover:

1. My 18-Month Job Search Struggle

2. The Interview Problem I Didn’t Expect

3. Discovering Active Recall and Flashcards

4. My Interview Preparation System

5. The Results

6. Changing How I Looked for Jobs

7. Turning My System Into a Small Tool

8. Lessons I learned

9. Final Thoughts

My 18-Month Job Search Struggle

For 18 months, I was trying to land a remote or relocation web developer job.

During that time:

• I applied to more than 1,000 positions

• I went through around 20–30 interviews

• I failed most of them

It was exhausting. I felt like I was putting in a lot of effort but getting almost no results. Over time, I started doubting my skills and wondering whether I would ever find a job I’d actually be satisfied with.

What made this even more confusing was that a few years earlier, in 2021, I had found a remote job at a US company in just three weeks – with almost no experience

Something clearly wasn’t working anymore.

The Interview Problem I Didn’t Expect

After dozens of interviews, I noticed a pattern: I wasn’t failing because I couldn’t solve complex algorithm problems or build features under pressure. I was failing on basic technical questions.

Questions like:

• “What are portals in React?”

• “Can you explain how an HTTP GET request works?”

These were not hard questions. They were things I had learned before. But during interviews, under pressure, I just couldn’t recall. Or simply I skipped it during preparation because there were no systems in place.

That’s when I realized the real issue: I didn’t have a problem understanding concepts. I had a problem recalling them quickly.

My first instinct was to study more. More tutorials, more articles, more videos.

But passive learning didn’t fix the problem. I still froze during interviews. What I actually needed was a way to train my memory, not just consume information.

Discovering Active Recall and Flashcards

That’s when I came across flashcards and the concept of active recall.

Active recall means testing yourself repeatedly on what you’ve learned instead of just rereading material. You try to answer a question from memory first, then check the answer. This approach has been backed by research for more than a century.

I started practicing small, specific concepts this way, like:

• React fundamentals

• JavaScript basics

• HTTP methods

• Browser behavior

I repeated them until recalling the answer felt automatic.

This made a huge difference during interviews.

Flashcards help you cut through the noise and actually learn what matters. It's not just about memorizing facts – it's about really understanding, remembering fast, and building a solid base in every concept you study.

So to help you prepare for your interviews, I’ve taken years of experience and scientific learning methods and turned them into a tool and approach that gives you the right info at the right time.

My Interview Preparation System

Once I found the right learning method, I built a simple system around it.

Step 1: Ask What to Prepare For

Instead of guessing what to study, I started asking recruiters directly:

“What topics should I prepare for the technical interview?”

Surprisingly, many of them replied with a clear list, which helped me focus only on what actually mattered and avoid over-preparing random topics. In my experience, many HR reps are quite helpful to job applicants.

For example, when I applied for a position as a Frontend Web Developer in React, the HR specialist advised me to focus mainly on React and JavaScript. So I prepared for all the popular questions around hoisting (JS), the event loop (JS), how react works under the hood, what props are and how they work, and so on.

Overall, that interview went well – but when I got a question on React Portals, I couldn’t explain it properly. And so I didn’t get the position. But I don’t blame myself for this one, as that’s a very rare topic. 😊

I also applied for another Front End Developer role where the HR specialist advised me to prepare mainly for questions about GSAP, Framer Motion, and React/Next JS. This made sense, as the company mainly builds modern animated websites.

In my interview, the theory round went well, but I failed the take home assignment. I realized then that I didn’t have enough skills in these areas.

At another company, I asked HR about the cultural interview, which was the last round. The rep said: ”No worries, all the hard work is done from your side. Prep for just a human dialog.”

And for the last application I submitted (and after which I actually got the job offer), the HR specialist told me to strongly prepare for CSS – especially Flexbox and Grid. This made sense, as the position was for an HTML markup developer. And so I practiced all the ins and outs for these topics, even the more rare ones.

I use the same approach for each round of interviews.

Step 2: Use Flashcards (With AI Carefully)

I used ChatGPT to generate flashcards for each topic and reviewed them daily.

One important thing I learned: AI can be wrong sometimes. To reduce mistakes, I started adding links to official documentation in my prompts so the answers were grounded in reliable sources.

I kept sessions short and consistent. That consistency mattered more than long study sessions.

AI mistakes was the reason I created 99cards.dev

Here is the prompt I use in ChatGPT:

You are a web development expert with 20 years of experience. Your task is to help me to prepare for the interview.

Prepare 10 flashcards on CSS Flexbox topics. Format one question with four answers. One answer is correct.

You're going to serve all the questions one by one. After I answer, you give me feedback and then give me the next question.

Note that you should tweak your prompts for your needs, and based on what you need to review.

You can experiment with various factors, such as:

• Difficulty: beginner or advanced

• Specificity: from vague (for example: I want to practice with CSS) to highly specific (for example: I want to practice with the flex property in CSS Flexbox)

• Number of questions: sweet spot is between 10 and 20

• Add context: good practice is to add links to official docs, as it decreases the chances of AI hallucination

Here is a typical flashcard created by ChatGPT:

If you provide an answer, you’ll get feedback like this:

The Results

After a few weeks, interviews felt very different.

I was calmer. I answered basic questions without panicking. I could explain concepts clearly and confidently.

In my final interview process, I passed four rounds in a row and scored 95% on the technical test.

Soon after, I received an offer: $5,500 per month and a paid relocation package for my family and me.

For the first time in a long while, my effort finally matched the results.

Changing How I Looked for Jobs

About six weeks before getting the offer, I also changed where I searched for jobs.

Instead of relying only on large job platforms, I started using smaller communities like Telegram job groups.

This helped for two reasons:

1. Less competition: many smaller companies post roles there with fewer applicants

2. Direct communication: I could message recruiters before applying

Before submitting an application, I would ask:

“I saw this position. Here’s my CV and LinkedIn. Am I a good fit?”

If the answer was yes, I applied. If not, I moved on immediately.

This saved me a lot of time and energy.

Turning My System Into a Small Tool

While preparing for interviews, I created thousands of flashcards for myself. Managing them in notes became difficult, so I eventually turned them into a small tool called 99cards.dev.

It’s simply a collection of fact-checked web development flashcards grouped by topic, based on the same approach that helped me stop failing basic interview questions.

Here are some screenshots from the app:

Lessons I Learned

Here are a few takeaways from this experience:

• Failing interviews doesn’t always mean you lack skills

• Passive learning is not enough for interview prep

• Being able to recall basics quickly matters a lot

• Job searching is a skill, not just a numbers game

• Consistency beats cramming every time

Final Thoughts

If you’re struggling with interviews right now, especially as a junior, mid-level, or self-taught developer, don’t assume you’re bad at what you do.

In my case, the problem wasn’t effort or talent. It was preparation and approach.

I also created a free interview checklist based on my experience, covering HR, technical, behavioral, system design, live coding, take-home tasks, algorithms, and cultural fit.

I hope this story saves you some time and stress.

You’re often just one good interview away.
— Ilyas

Then I joined a real team.

Suddenly, I was introduced to this thing called Kanban – and I realized I’d been treating software like a solo art project, not a process.

If that sounds familiar, you’re in the right place.

This guide will walk you through how Kanban actually works, how developers use it to track and prioritize work, and how it can help you stay sane when juggling bugs, features, and real-world deadlines.

Without further delay, lets get into it.

Here’s what we’ll cover:

• So… What Is Kanban?

• The Classic Kanban Board: Three Simple Columns

• How Developers Use Kanban in Real Life

• Kanban vs Scrum: What’s the Difference?

• So which one should you use Scrum or Kanban?

• What Tools Do Teams Use for Kanban?

• How to Use Kanban to Manage Your Own Coding Projects

• Final Thoughts: Why Kanban Isn’t Just a Board

So… What Is Kanban?

At its core, Kanban is a visual way to manage work. It helps teams (or team members) see:

• What needs to get done

• What’s in progress

• What’s finished

• Where things are getting stuck

The concept comes from lean manufacturing, but in tech, it’s often used in Agile teams that need flexibility without the structure of Scrum sprints.

Think of Kanban like a whiteboard that tells a story. Not just what’s done, but how work flows.

The Classic Kanban Board: Three Simple Columns

So what exactly is a Kanban board? At its core, it’s a visual representation of your workflow – a board that shows all the work your team (or you, solo warrior) are juggling, and where each task stands.

It can be physical, like an actual whiteboard with sticky notes that move from one column to the next. Or digital, using tools like Trello, Jira, GitHub Projects, or Notion. The key is that it’s visual and up-to-date. You can walk into a room or open a tab and instantly understand: What’s being worked on? What’s ready to go? Where are things stuck?

It’s like having your brain on a wall, but organized. And slightly less chaotic.

The beauty of Kanban is how dead simple it is to get started. At minimum, your board has three columns:

Each task – or card – moves from left to right as it gets worked on.

Let’s say your team is building a blog platform. Your Kanban board might have cards like:

• “Create signup form”

• “Fix image upload bug”

• “Deploy staging build”

Now, while Kanban is flexible, it can absolutely be taken too far.

I’ve seen boards with more columns than a Greek temple: “Needs Review,” “Pending Client Feedback,” “QA Rework Round 2,” “Blocked but Still Hopeful,” “In Existential Limbo,” and so on. Every card had six tags, three owners, two checklists, and one migraine.

The lesson? Don’t turn your board into a bureaucratic jungle.

You don’t need to account for every edge case. Start simple: “To Do,” “In Progress,” “Review,” “Done.” These basic stages cover most workflows. If you discover a real need for something more – like a dedicated “QA” column or “Blocked” column – add it intentionally, not because you feel like your board needs to look fancy.

Remember: A Kanban board should be helpful, not overwhelming. If you spend more time managing the board than doing the work on it… it’s doing the opposite of what it’s meant to do.

How Developers Use Kanban in Real Life

Here’s how you might interact with a Kanban board on a dev team:

1. You pick up a card from “To Do” – let’s say, “Add dark mode toggle.”

2. You move it to “In Progress.”

3. When it’s ready for review, you might move it to a temporary “Review” or “Testing” column.

4. Once it’s merged, tested, and deployed, you move it to “Done.”

5. You smile, drink some coffee, and grab the next card.

That’s it. But over time, this process helps the whole team:

• Spot bottlenecks

• Prevent duplicate work

• Reduce context switching

• Keep everyone aligned

What’s a WIP Limit — And Why Should You Care?

WIP = Work In Progress. This is the most important concept to keep us in check.

One of Kanban’s key principles is limiting how many things you’re working on at once. Because guess what? Multitasking kills momentum.

A typical WIP limit might look like:

• No more than 2–3 cards per person in “In Progress” Again this is best practice, but folks do pick up a lot and then they end up being the bottleneck.

• No more than 5 tasks waiting on QA.

Why? Because when everything’s urgent, nothing gets done. WIP limits force you to finish one thing before you start more – and that’s how real velocity happens.

If there are more than 5 tasks in the “To Do” column, the team doesn’t take up new ones. Instead, everyone chips in to see how they can help unclog the bottleneck. A bottleneck is your worst enemy in Kanban, and you want to resolve it so items move smoothly on time and on target.

Here’s a video recapping key concepts.

Kanban vs Scrum: What’s the Difference?

You’ve probably heard Scrum and Kanban mentioned in the same breath – and both are popular Agile frameworks. But they’re not interchangeable.

Scrum is structured, with roles like Product Owner and Scrum Master, and work gets organized into time-boxed sprints. It’s perfect for teams that benefit from rhythm and rituals – like sprint planning, daily standups, and retrospectives.

Kanban, on the other hand, is a little looser. No official roles, no set sprint timelines. Work flows continuously, and change can happen anytime. It’s perfect for teams who need more flexibility and fewer ceremonies.

So how do they compare in practice? Let’s break it down:

Bottom line:

• Scrum is a scheduled loop. Kanban is a living flow.

• One’s a playbook. The other’s a status window.

Here’s a video on the main differences between Scrum and Kanban you can watch if you want more detail.

So which one should you use Scrum or Kanban?

So… which one should you use?

It really depends on your team, your product, and your pain points.

✔️ If you’re working on a brand-new product where requirements shift a lot, and your team thrives with structure and routines – Scrum is likely the better fit. Sprints give you a sense of pacing, and ceremonies help ensure alignment.

✔️ If you’re managing ongoing work like bug triage, tech debt, infrastructure tasks, or anything that’s more “whenever it comes in” than “we need to ship this in two weeks” – Kanban gives you flexibility and visibility without the overhead.

And yes, there’s such a thing as Scrumban – a hybrid approach where teams use visual boards and WIP limits from Kanban, but keep some of Scrum’s structure like standups and retros. It’s like Agile tapas: you get the flavors that work best for your appetite.

Here is a detailed video that’'ll teach you more about how Scrumban works in practice.

Watch the Scrumban video only when you are familiar and comfortable with both Scrum and Kanban – otherwise, you might get confused from the cross-pollination of ideas and frameworks.

I personally have never seen a Scrumban implementation thats scaled well – too many folks trying too many things and none of them work. But thats just based on my experience – it may work for you and your team. I’ll let you be the judge.

What Tools Do Teams Use for Kanban?

You’ve probably seen (or used) one already:

• Trello – Simple and great for solo or small teams

• Jira – Enterprise-level, customizable workflows

• GitHub Projects – Lightweight but powerful for devs

• ClickUp / Asana / Notion – Integrated with docs/tasks

Kanban isn’t tied to any one tool – you can use an app, a browser tab, or a whiteboard and a pack of sticky notes from the office supply closet. What matters is how you use it. But let’s walk through some of the most common tools and what they offer in a Kanban context:

🟩 Trello

Trello is probably the easiest way to start with Kanban. It gives you a simple digital board with columns and cards you can drag and drop. It’s great for devs or small teams who don’t need tons of automation – just a clean place to track work visually.

🟨 Jira

Jira is a heavyweight – and while it’s built for Scrum, it also supports robust Kanban boards. You can define custom workflows, use built-in reports like cumulative flow diagrams, enforce WIP limits, and manage team velocity. Ideal for large teams that need traceability, integrations, and permissions.

🟦 GitHub Projects

If your code lives in GitHub, GitHub Projects is a clean way to stay close to your codebase. It lets you create Kanban-style boards with issues and pull requests as cards, so you’re never toggling between tools just to track what’s in progress.

🟧 ClickUp / Asana / Notion

These are all-in-one productivity platforms. They combine Kanban boards with documentation, team chat, calendars, and reporting. If your team needs more than just “move card left to right,” these tools let you manage projects, meetings, notes, and workflows in one place.

🟪 Whiteboard + Sticky Notes

Don’t underestimate the analog approach. It’s fast. It’s visible. It’s tactile. Physically moving a task from “Doing” to “Done” gives you a sense of progress no digital tool can match. And when something’s blocked? Slap a red sticky on it and call it a day.

Bottom line: The best tool is the one your team will actually use. Fancy doesn’t beat consistent. And the actual tool doesn’t matter as much as the discipline your team has to actually use it.

How to Use Kanban to Manage Your Own Coding Projects

Even if you're not on a team yet, Kanban is great for your own workflow. Here’s how you can use it to help yourself out:

1. Create a basic 3-column board (To Do, In Progress, Done)

2. Write out every task, big or small

3. Set a WIP limit (for example, no more than 2 tasks at once)

4. Update it daily. Make it a ritual.

5. Review your flow weekly – What got stuck? What moved fast?

Example:

You’ll be shocked how much clearer your thinking gets when you can see your work. It’s simple but super powerful to visualize your work it in this way.

Final Thoughts: Why Kanban Isn’t Just a Board

Kanban isn’t just a tool – it’s a mindset.

It helps you focus. It helps your team collaborate. And it gives everyone – even non-technical folks – visibility into what’s going on.

If you’re learning to code and want to feel more confident working with others, learning Kanban is low-effort, high-impact.

So don’t wait until your first job. Start using it now – and show up to that standup with confidence.

I hope this small 101 Guide to Kanban was helpful to you all. My sole purpose to write this was to help beginner developers understand Kanban as a practical workflow system – especially for those transitioning from solo coding to collaborative, real-world development environments. It aims to demystify the methodology in a casual, beginner-friendly tone while still offering actionable guidance.

I hope you enjoyed my beginners guide to Kanban.

Until next time, keep Learning, Unlearning and Relearning, folks….

You’ve been grinding through tutorials. You've built a portfolio site, maybe deployed a few projects on GitHub. And now you're trying to land a job or join a team.

Then the interviews start.

Suddenly, people ask:

• "Are you familiar with Agile?"

• "Have you worked in a Scrum environment?"

• "What’s your experience with sprints?"

Cue the imposter syndrome. Because no one teaches this stuff in JavaScript 101.

This guide is for you.

I’ll help make the Scrum process – a very common way developers work together – make actual sense. I’ll walk you through the basics, but also tell you what developers actually do, how standups feel when you're new, and what’s expected of you when you’re no longer coding in a vacuum.

Let’s break it down.

Here’s what we’ll cover:

• What Even Is Scrum?

• The Three Roles in Scrum (and Who Does What)

• The Scrum Rhythm: What a Sprint Actually Looks Like

• Who attends the Ceremonies:

• Standups: Where You Talk Like a Human, Not a Robot

• Sprint Planning

• What’s a User Story and Why Does It Sound Like a Children’s Book?

• What Counts as “Done”? Definition of Done and Why It’s Important

• Demos, Retros, and Saying the Hard Things

• Tools You Might Encounter

• If You’re Preparing for a Job, Here’s What You Can Do

• Final Thoughts

What Even Is Scrum?

Scrum is not a tool. It’s not a software. It’s not some elite thing only PMs care about.

It’s a lightweight framework that helps software teams build things incrementally, together, in short focused cycles called sprints.

Scrum is used by everyone from FAANG teams to indie dev shops because it helps:

• Keep teams aligned

• Deliver working software fast

• Course-correct often

• Spot problems early (before they go nuclear)

It’s the opposite of the old-school “build for a year and pray it works” model.

The Three Roles in Scrum (and Who Does What)

Scrum officially defines three roles. Here's what that means in practice:

1. Product Owner (PO)

Think: Vision-holder. They decide what the team builds and why. A product owner:

• Writes user stories (think of these as feature requests written from a user’s point of view)

• Prioritizes the work

• Clarifies what success looks like

• Says “yes” or “not yet” to features

2. Scrum Master (SM)

Think: Air-traffic controller meets therapist. They make sure the process works. The are master Facilitators, like between Dev and PO’s. A Scrum Master:

• Facilitates meetings

• Removes blockers (“Your AWS access is stuck? I’ll escalate it.”)

• Coaches the team on Scrum practices

• Doesn’t manage people – manages flow

3. Developers (YOU!)

Think: Builders. You write code, test it, ship it, fix it, and improve it. You also:

• Break down stories into tasks

• Pick up work from the team board (like Jira or Trello)

• Communicate progress

• Demo what you’ve built at the end of the sprint

You might also work with designers, testers, or DevOps folks – but within Scrum, you’re all “developers” building a product together.

The Scrum Rhythm: What a Sprint Actually Looks Like

Image Source: https://www.invensislearning.com/blog/what-are-scrum-ceremonies/

Understanding the Scrum Cycle

So, what does it actually look like when a team uses Scrum to build software?

Let’s walk through a full sprint – not just the buzzwords, but what really happens when a group of humans tries to plan, build, review, and improve together. Think of this as your backstage pass to the rhythm of modern teamwork.

📦 Step 1: Build and Refine the Product Backlog

Before any coding starts, the team needs to agree on what they might build – not just this week, but in the near future too.

That’s where the Product Backlog comes in. This is a big, running list of everything the product might need – features, bug fixes, improvements, ideas, and maybe a few wild dreams. It’s like the wishlist for the product, but more organized (ideally).

The Product Owner is responsible for maintaining and prioritizing this list. They decide what’s most important to work on based on customer needs, business goals, and feedback.

But the PO doesn’t do this in isolation. Enter the Backlog Refinement meeting.

In these sessions, the Scrum Team – that’s the PO, the Scrum Master (SM), and the Developers – come together to:

• Review the most important upcoming items

• Clarify any vague or confusing parts of each task

• Break big items down into smaller, buildable pieces called user stories

• Estimate effort (how much time or complexity is involved for each story)

This meeting makes sure the team isn’t caught off guard in the sprint – that they understand the work ahead and can actually start sprinting when the time comes.

🧭 Step 2: Sprint Planning – What Are We Building This Time?

Now that we’ve got a solid backlog, it’s time to pick what to build right now.

At the start of each sprint (which typically lasts 1 to 4 weeks), the team holds a Sprint Planning meeting. This meeting sets the stage for the entire sprint – it’s like the huddle before the big game.

In Sprint Planning, the team:

• Reviews the top items from the backlog

• Discusses what can realistically be completed based on their availability and capacity

• Chooses a handful of these stories to commit to

• Defines a Sprint Goal – a simple statement that captures the purpose of this sprint

For example, the Sprint Goal might be:
🎯 “Allow users to reset their passwords.”

Every user story chosen should contribute to that goal. The collection of these stories becomes the Sprint Backlog – basically, the to-do list for the sprint.

So when we say:

“The team selects an ordered list of user stories to comprise the Sprint Backlog for the next sprint, which will be achievable to satisfy the Sprint Goal...”

We’re really just saying:
👉 “Pick a realistic number of important tasks that, if completed, will help us hit our target for the sprint.”

Not too vague. Not too ambitious. Just achievable and focused.

☀️ Step 3: Daily Standups – Stay in Sync

Now the sprint is underway! But how does everyone stay aligned and avoid working in silos?

That’s where the Daily Standup comes in. Every day – usually in the morning – the team has a quick check-in (about 15 minutes) where each person answers three questions:

1. What did I do yesterday?

2. What am I working on today?

3. Is anything blocking me? (that is, am I stuck?)

Example:

“Yesterday I set up the login API integration. Today I’ll work on the UI validation. I’m blocked on getting access to the staging database — may need help.”

These standups keep the team in sync and surface blockers early so they can be addressed quickly. They’re not about micromanaging or showing off. They’re about visibility and support.

📉 What’s a Sprint Burndown Chart?

You might hear your team mention a “burndown chart.” No, this isn’t about things going down in flames (hopefully).

A Sprint Burndown Chart is a graph that shows how much work is left in the sprint – day by day.

• The y-axis is the amount of work remaining (often measured in story points or tasks)

• The x-axis is the number of days left in the sprint

The line should ideally trend downward as work gets completed – hence “burning down.” If it flattens out or slopes up, that’s a red flag that the team might be stuck, behind schedule, or not updating the board.

Think of it as a visual heartbeat of the sprint. You can learn more via a practical example in this video.

🖥️ Step 4: Sprint Review – Show What You’ve Built

At the end of the sprint, the team holds a Sprint Review (also called a “demo”). This is where you show what was actually built during the sprint.

• The Developers demo working features – live, not just screenshots

• The Product Owner reviews whether the Sprint Goal was achieved

• Stakeholders may ask questions, give feedback, or suggest tweaks

This meeting isn’t just for show – it’s a feedback loop. It helps the team validate that what they built is useful, usable, and meets expectations. If changes are needed, those get added to the backlog for future sprints.

🔍 Step 5: Sprint Retrospective – Look Back to Move Forward

Once the review is done, the team shifts focus from what they built to how they worked together.

Enter the Sprint Retrospective – a meeting to reflect on the process, not the product.

The team discusses:

• ✅ What went well

• ❌ What didn’t go so well

• 🔁 What could be improved next time

This isn’t about pointing fingers. It’s about learning, adapting, and continuously improving how the team collaborates.

The Scrum Master often facilitates this meeting and helps turn feedback into action items for the next sprint. For example:

“We underestimated testing time. Next sprint, let’s budget for QA earlier.”

The best teams take retros seriously. Why? Because even if your code is perfect, your process needs tuning too – and small process changes often lead to big gains.

♻️ Scrum Is a Loop

Here’s the rhythm:

1. Plan the sprint

2. Check in daily

3. Build and demo the product

4. Reflect and improve

Then do it all over again – with slightly better coordination and slightly more trust each time.

It’s not about being fast. It’s about being intentional, consistent, and collaborative.

Example Sprint

Let’s say, for example, that your team does 4-week sprints. (Keep in mind that Sprints can differ by team, nature of product, release cycles, and so on.)

Here’s the rough beat:

Scrum works in loops. Every 2-4 weeks (depending on your cadence and sprint cycle), your team should have working, demo-able software to show for it – even if it’s small.

And no, it’s not about “speed.” It’s about consistency, communication, and collaboration.

Who attends the Ceremonies:

Now lets dive deeper and understand practically how each of these ceremonies work:

Standups: Where You Talk Like a Human, Not a Robot

So how does the team actually stay connected day to day? That’s where standups come in.

Every morning, your team meets briefly – usually on Zoom or in a circle – and you answer 3 questions:

1. What did I work on yesterday?

2. What will I work on today?

3. What’s blocking me? Any impediments?

Example:

"Yesterday I cleaned up the signup validation logic. Today I’m working on the email verification flow. I’m stuck on SendGrid config – might need help setting up credentials."

It’s not about impressing anyone. It’s about keeping everyone in sync. Some days you’ll say, “I spent the whole day debugging a CSS bug that turned out to be a semicolon.” That’s okay.

How does it work?

The Scrum Master gathers everyone in a huddle room, the PO and Dev Team included, and opens the the Standup. They are the facilitator of the ceremony. Everyone gets a chance to answer the 3 questions above (usually about 2-5 minutes each). It’s not a full report – it’s quick. When one person is done, they pass it on to someone else.

This ensures there is team cohesion and transparency.

Here is a video example of a standup.

Sprint Planning

The goal of the planning meeting is to answer the questions “What are we going to work on, and how are we going to do it?” It is critical for the team to have a shared goal and a shared commitment to this goal before beginning this ceremony.

Participants should:

• Measure growth

• Sync with the Scrum Master

• Sync with the Product Owner

Sprint planning happens just before the sprint starts, and usually lasts for an hour or two. In this meeting, the team goes over a collection of user stories and discuss, plan, measure, and prioritize. This is where they decide what is going to be in scope for their upcoming sprint cycle.

The Product Owner will have a prioritized view of things in the backlog. They work with the team on each object or customer experience. Together, as a group they go through and make calculations, deciding to what they can commit.

What’s a User Story and Why Does It Sound Like a Children’s Book?

So you might be wondering: how do you know what to work on? What to build? So much work, so little time? Thats where user stories come in.

In Scrum, teams don’t just write vague tasks like “code the login.” Instead, they write user stories – short, human-centered feature descriptions that describe what the user needs, why they need it, and what success looks like.

Here’s an example:

As a user, I want to be able to reset my password, so I can access my account if I forget it.

User stories are the scaffolding of teamwork. They’re written with empathy, not just efficiency. And each one comes with acceptance criteria – a checklist that clarifies what “done” actually means:

• A “Forgot Password” link is visible

• Clicking it shows a form

• An email gets sent with a reset link

Once a story is agreed upon, developers break it down into tasks, like “build form,” “hook into backend,” or “handle email validation.” It’s collaborative, not prescriptive. And user stories have priority so you know what’s the most important and what’s the least.

A helpful rule of thumb many teams use is the Gherkin-style "Given–When–Then" format:

• Given some initial context

• When an event occurs

• Then a specific outcome should happen

This ensures that everyone – devs, testers, and product owners – shares the same understanding of behavior and expectations.

Here is a great video example thats outlines how to draft effective and powerful user stories.

What Counts as “Done”? Definition of Done and Why It’s Important

Now you might be wondering – how do I know when a task is done and can be closed out?

The Definition of Done is a type of documentation in the form of a team agreement. The Definition of Done identifies the conditions that need to be achieved in order for the product to be considered done (as in potentially shippable).

This is how we know that we "did the thing right". Meaning, we built the correct level of quality into the product. The Definition of Done is not the same as the acceptance criteria, which are written by the product owner to help us know we did the "right thing".

Every team has a Definition of Done – it’s not just “I pushed code.” It could mean:

• Code is written

• Reviewed by a peer

• Merged into main

• Tested on staging

• Possibly deployed

This clarity keeps teams honest and accountable. No “it works on my machine” energy here. The DoD sets a quality bar. It prevents ambiguity, rework, and “it works on my machine” moments. When every card on the board passes the same finish line, teams move faster – and trust each other more.

Everyone should know what done is in a team. Either its Done as per DoD standards or its not.

Here is a beautiful video highlighting the impotence of DoD.

Demos, Retros, and Saying the Hard Things

Once you’ve built the product, then comes demos (showcasing your work) and retros (analysis as a team on what when well and what areas to improve on).

In the retro, everyone’s encouraged to speak up:

• What went well?

• What didn’t?

• What should we try next time?

Example:

“We missed a lot of stories because we didn’t account for testing time. Maybe we buffer next sprint with fewer tasks.”

The goal is not to blame – it’s to improve. Over time, this feedback loop becomes gold. The Scrum Master usually facilitates, collects feedback (via tools like Parabol, Miro, or sticky notes), and helps turn insights into actionable experiments for the next sprint.

Over time, retros become the heartbeat of team evolution.

Here is a video highlighting the importance of a Retro and Sprint Review.

🧠 Why Retrospection Matters More Than You Think

The Sprint Retrospective is more than just another meeting. It’s a mirror for your team – a safe, structured space to pause, reflect, and improve together.

You discuss:

✅ what went well

❌ what did not go well

🔁 what could we do better next time

Great teams don't just deliver great software, they continually deliver better ways of working.

This is why many experienced Scrum practitioners consider the retro to be the most important event in Scrum. Code is deployed once, but process improvements grow exponentially, sprint after sprint.

Tools You Might Encounter

Scrum doesn’t require software, but real-world teams use a variety of tools:

• Jira – Tracks sprints, issues, velocity

• Trello – Simple board, good for small teams

• Slack – Where standups often happen if async

• Notion / Confluence – Docs, retros, notes

• GitHub Projects – Lightweight planning for devs

Don’t worry if you’re not fluent in these yet. They’re tools – you’ll learn them on the job.

If You’re Preparing for a Job, Here’s What You Can Do

• ✍️ Practice writing user stories from your side projects

• 🧪 Run a mini-sprint: Plan your weekend project, set goals, and “review” it at the end

• 🤝 Contribute to an open-source project that uses Scrum or Agile workflows

• 🧾 Write about what you learned – maybe as a tutorial (hint hint)

Final Thoughts

So to recap, Scrum is a simple yet powerful way for teams to work together, stay organized, and deliver results quickly. It runs in short cycles called sprints, where the team plans what to do, checks in daily, shows their progress at the end, and reflects on how to improve.

The four key ceremonies – Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective – help keep everyone aligned and focused. With clear roles and regular feedback, Scrum makes it easier to handle changes, solve problems early, and continuously get better as a team.

But scrum isn’t a magic spell. It’s just a way for humans to build complex things – together – without falling apart.

You don’t need to be a Scrum Master. You don’t need a certification. But if you understand how sprints work, what’s expected of you, and how to show up to meetings with clarity and candor, you’re 10 steps ahead of most.

Scrum helps teams talk, plan, build, and learn. And now? You can too.

If you liked this, please do share. You never know who it might help out.

Until then…keep learning, unlearning, and relearning!!!

We just published a course on the freeCodeCamp.org YouTube channel that will teach you all about the top 10 most frequently asked iOS interview questions, complete with sample answers and code demonstrations. Presented by Richard Topchii, this mock interview format course features Daniel as the interviewer and covers everything from foundational concepts to nuanced language features in Swift.

The course kicks off with an overview and a discussion of why these specific questions were chosen, followed by a deep dive into essential iOS concepts like the View Controller life cycle, and the differences between structs and classes, which is a crucial topic for understanding memory management and data handling in Swift. You’ll also learn the distinctions between .frame and .bounds in UIViews, an area where developers are often tested for their understanding of layout behavior.

Beyond the fundamentals, the course explores more advanced topics such as Protocol-Oriented Programming, MVC architecture, and important Swift keywords like lazy, weak, unowned, and @escaping. These are often tricky areas that interviewers use to assess a candidate's depth of knowledge and real-world coding experience. Plus, with real coding questions on the defer statement and GCD / DispatchQueue, you'll get to see how to write performant and safe concurrent code.

By the end of the video, you’ll also get a summary and feedback section that ties all the concepts together, helping reinforce what you've learned. Watch the full course on the freeCodeCamp.org YouTube channel (1-hour watch).

The NeetCode 150 is an invaluable resource—a curated list of the most essential LeetCode problems that cover key algorithmic patterns and topics frequently tested in interviews.

We just published a course on the freeCodeCamp.org YouTube channel, created by @DestinationFAANG, that dives deep into the NeetCode 150. This course provides a comprehensive walkthrough of these problems, offering detailed explanations, practical solutions, and tips for tackling each challenge effectively.

What’s in the Course?

The course spans over 38 hours of in-depth content, meticulously covering the NeetCode 150 problems. Each problem is explained step-by-step, ensuring that even beginners can follow along. Here's what you can expect:

• Key Topics and Patterns: Problems are grouped by topics such as arrays, strings, linked lists, binary trees, dynamic programming, and graph algorithms. This structured approach helps you build a comprehensive understanding of the key concepts.

• Detailed Solutions: Every problem includes a clear explanation of the logic, coding implementation (in Java), and optimization techniques to solve it efficiently.

• Real-World Relevance: These problems are selected based on their frequency in actual tech interviews, ensuring that your preparation is targeted and practical.

Course Highlights

• Introduction and Foundations: The course begins with simpler problems like "Contains Duplicate" and "Valid Anagram" to establish a strong base.

• Advanced Concepts: As you progress, you’ll encounter more challenging problems like "Trapping Rain Water," "Word Search II," and "Binary Tree Maximum Path Sum."

• Dynamic Programming: Learn to tackle problems like "Longest Increasing Subsequence" and "Coin Change," which are essential for mastering this fundamental topic.

• Graphs and Trees: Deep dive into graph algorithms with problems like "Course Schedule," "Alien Dictionary," and "Network Delay Time," as well as tree-based challenges like "Binary Tree Level Order Traversal."

• Practical Coding Tips: The course emphasizes clean, efficient coding practices that are crucial for interview success.

Why Watch This Course?

Whether you’re a beginner looking to break into the tech industry or an experienced developer refining your skills, this course is designed to meet your needs. It’s free, accessible, and offers high-quality guidance on solving some of the most critical technical interview problems.

Watch it now on freeCodeCamp.org’s YouTube channel (38-hour watch).

This is John's first-ever podcast interview, and the first time he's told his story. Interviewing him was an absolute honor.

We talk about:

• How John delivered pizzas to save enough money to buy his first computer in the 90s. "I was tired of being a broke kid."

• John's first career in the US military, where he worked as a translator in South Korea

• How John crammed Computer Science for 8 months and taught himself enough theory and coding skills to get a job in big tech, then published Coding Interview University on GitHub

• What it's like to work as a senior developer at a big tech company, and what you can expect the journey to be like

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

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

You can watch the interview on YouTube:

Or you can listen to the podcast in Apple Podcasts, Spotify, or your favorite podcast app. Be sure to follow the freeCodeCamp Podcast there so you'll get new episodes each Friday.

Links we talk about during our conversation:

• Coding Interview University: https://github.com/jwasham/coding-interview-university

• The Starup Next Door, John's blog: https://startupnextdoor.com/

• The Talent Code, the book John recommends: https://www.amazon.com/Talent-Code-Greatness-Born-Grown/dp/055380684X

• Follow John on LinkedIn: https://www.linkedin.com/in/johnawasham/

David Goggins is an ultramarathon runner, a public speaker, a retired navy SEAL, and the author of the book 'Can't Hurt Me: Master Your Mind and Defy the Odds'. He's one of my role models because of his physical strength and mental resilience.

You might say: "Wait a second! We get it. This person is obviously the epitome of success. But he has non-technical skills. So why is he relevant to JavaScript coding interviews?"

Well, if you're ready, let's explore this together.

Rocky Balboa As a Mentor

In response to a question, David says, 'The Rocky Movie changed my life." In that pep talk, he refers to this scene (min 1.30-1.42) where the fictional character, Rocky - despite being beaten up badly by his opponent in the final boxing round - refuses to give up no matter what.

David describes that particular moment as the time when Rocky - initially depicted as an underdog by the screenwriter - overcomes all the odds and strikes awe in his rival.

Illustration Source

Let's admit it. Being a good programmer is not that easy. And especially if you are at the beginning of your career, technical job interviews can be seriously daunting. In short, it might be nice to reach David's (and Rocky's) mindset.

With that kind of drive and confidence, you're much less likely to consider giving up regardless of the types of challenges you face in your wonderful yet difficult journey of getting a developer job.

Why Coding Interviews Are Difficult

During coding interviews, you are expected to fix coding problems with some theoretical knowledge. But the caveat is you must do that in real time, which sometimes scares new developers off.

There are several types of coding interviews. But the most challenging one is probably a whiteboard interview. In these types of interviews, you have to code in front of a future employer / a senior software developer.

[Illustration by HackerRank](https://www.hackerrank.com/blog/virtual-whiteboarding-for-system-design-interviews/"><nr-sentence class="nr-s20" id="nr-s20" page="0)

These interviews can be extra stressful because you are typically not allowed to have a computer to google any unknown concepts or to get some code snippets from the internet. You are only given a marker to solve the question on a whiteboard as the name suggests.

Do Interviews Reflect What You'll Do in Your Job?

Not necessarily. So why are they holding these scary coding interviews? Well, the reason is to test your problem solving skills in general. At times, finding the correct answer may not even be that important.

What matters is how you reach that conclusion / solution and which algorithms you prefer to use along the way. In other words, your ability to function well under stress is being tested by tech companies.

_[Image Source](https://www.reddit.com/r/ProgrammerHumor/comments/l6wnvt/interview_vsjob/"><nr-sentence class="nr-s30" id="nr-s30" page="0)

Let's face it. You'll come across lots of stressful situations in your future job, and how you deal with certain issues is especially crucial. Therefore, your future employer naturally wants to witness firsthand whether you are the right fit for the job.

What is the Purpose of This Tutorial?

In this post, I'll walk you through some popular JavaScript interview concepts through examples. I'll also do my best to show you what recruiters / interviewers might actually be looking for in a candidate while they code in front of them.

To simply put, we'll examine some models and try to solve the related puzzles together.

By the end of this tutorial, you'll hopefully have an idea about a number of important array methods. But most importantly, you'll unlock how to approach some coding challenges in the best way possible.

What Exactly is the Memory Palace Method?

Before we start, just be aware that in the sample data down below, I've used some late celebrities' names intentionally so that all those details can be catchy in the long run.

An ancient technique called the Memory Palace clearly says that the weirder the details, the easier it is to remember them – and a made-up story / creating context is even more effective.

If you try to visualise the related situation vividly and associate the given programming concepts with some bizarre details in your mind, you might feel less stressed and confused when you see a similar problem next time. This is because it might be easier for you to create specific links and as such remember things easily. This is how our brains work.

Well, even the fictional figure 'Sherlock Holmes', the smartest guy on the planet, benefits from this method when solving complicated crimes – so why shouldn't we?

[Illustration by Savanahcat](https://www.deviantart.com/savanahcat/art/Mind-Palace-387601041"><nr-sentence class="nr-s43" id="nr-s43" page="0)

How to Approach Coding Problems

In our imaginary interview, you'll see that four extraordinary musicians from the past are listed as passengers on a flight. We have their food choices and the number of connecting flights they need to take after their incredible performances on stage in different parts of the world.

Let's say just for the sake of argument our phenomenal figures (Freddie Mercury, Amy Winehouse, Kurt Cobain, and Michael Jackson) are about to fly from different destinations to Los Angeles just to be able to dine out together at a swanky restaurant, as they enjoy each other's company so much.

After all, this is our own private memory palace, so we can absolutely do whatever we want to do in our minds. Remember unusual details will stick better. That's why I'm trying to add more to spice things up.

This method explicitly suggests describing every single detail with some vivid adjectives so that you can associate them with the things you plan to learn in the long run.

Scientists say short term memory and long term memory function very differently. To put it simply, we need a way to put all those core concepts (not necessarily the syntax) about programming in our long term memory. That's why it can be nice to benefit from the memory palace method in our journey.

[Image Source](https://www.nme.com/news/music/producer-goes-viral-for-mixing-nirvana-and-michael-jackson-songs-with-drill-beats-2747204"><nr-sentence class="nr-s56" id="nr-s56" page="0)

Plus, I feel like you get to picture this unusual scenario with a smile on your face. Well, wouldn't it be great if these awesome souls could have seen that they are now helping us / the programming community as the guests of a freeCodeCamp article?

Sample Interview Questions

Let's get back to the real life now though. Remember you're still in the interview and as you see below, three questions in a row are waiting for you.

// Main Question: Get the passengers' names using the data provided 
// Bonus Part (a)- Return vegetarians/vegans
// Bonus Part (b)- Sort passengers by the number of connected flights in descending order

The Data

To solve the puzzles, you're expected to use the data inside the following array of objects in practical ways.

You'll certainly need to come up with the right algorithms and try to find the most effective solution that can satisfy the interviewer.

const passengers = [
  {
    id: 1,
    passengerName: "Freddie Mercury",
    isVegetarianOrVegan: false,
    connectedFlights: 2,
  },
  {
    id: 2,
    passengerName: "Amy Winehouse",
    isVegetarianOrVegan: true,
    connectedFlights: 4,
  },
    {
    id: 3,
    passengerName: "Kurt Cobain",
    isVegetarianOrVegan: true,
    connectedFlights: 3,
  },
     {
    id: 3,
    passengerName: "Michael Jackson",
    isVegetarianOrVegan: true,
    connectedFlights: 1,
  },
];

The above questions are in fact not that hard. But, how we'll handle them is a great opportunity to compare alternative solutions for a single problem. At the end of the day, quality is what counts for recruiters / interviewers.

Interview Question 1: How to Get Passengers' Names

Let's get the passengers' names as requested. The first solution is through a 'for loop' method. So we first need to use an empty array to push the passengers' names right inside it at the end of the loop.

Below, [i] represents the current passenger and we simply loop through the 'passengers' array to access the names of the passengers. Then, we need to lock them up in our empty array / passengerNames.

const passengerNames = [];
for (let i = 0; i < passengers.length; i++) {
    passengerNames.push(passengers[i].passengerName)
}
console.log("passengers", passengerNames);

RESULT - using 'for loop'

Alright, we solved the puzzle, but is it enough? Or might the interviewers expect you to come up with a better solution?

Alternative Solution #1:

We can reach the desired result by using the 'forEach' function as well. This solution is even a bit better than the previous one because there is no index expression in this one.

const passengerNames = [];
passengers.forEach((passenger) => {
    passengerNames.push(passenger.passengerName);
})

RESULT - using 'forEach'

To benefit from 'forEach', we need a callback function. With this arrangement, we are able to reach every passenger in the list. However, just like in the previous solution, we first need an empty array to push the items / passengers' names.

Even though the result is the same, this piece of code is shorter. Writing neater codes is what is – in fact – expected from you.

In other words, not only the solution matters, but also how you reach it is being evaluated by the recruiters. For this reason, it is a good idea to plan your action rather than writing the first idea in your mind on the whiteboard.

Alternative Solution 2:

Here comes the best solution. We can also utilise the 'map' function to tackle the same problem. Let's see how.

const passengerNames = passengers.map((passenger) => passenger.passengerName);

RESULT - using 'map'

The map function also loops through the array and returns a new array for every item in the list. With this set-up, we simply return a single element, not an object.

The result will again be the same in the console, but your code will even be better than the first and second one because this time, we don't need to create an empty array before the actual task.

Here is the food for thought on this topic. Those who say 'less is more' have a point when it comes to writing codes.

Interview Question 2: How to Get Vegetarian/Vegan Singers

Let's now take a look at the next challenge. The new task asks us to obtain only the vegetarian / vegan singers from the passengers' list by also keeping the first argument in the main question section.

How to Solve With a 'For Loop'

Again, we can use the same old 'for loop' for this one as well. All we need to do is to check whether there are any vegetarian / vegan singers in our passenger list through an 'if' statement inside our existing function.

const passengerNames = [];
for (let i = 0; i < passengers.length; i++) {
    if(passengers[i].isVegetarianOrVegan) {
    passengerNames.push(passengers[i].passengerName)
    }
}
console.log(passengerNames);

RESULT - using 'for loop'

We do that with the isVegetarianOrVegan property in our object. Basically, what we say is this: if the relevant statement is true (if there are any vegan / vegetarian passengers in the list), just push those items into our new array. The result will give us three singers' names as those are listed as 'vegetarian or vegan' in the data part.

How to Solve with 'forEach'

As a matter of fact, the 'forEach' function handles the problem similarly. But once again, it has too many lines of codes as you see below, so it isn't the ideal version.

const passengerNames = [];
passengers.forEach((passenger) => {
      if (passenger.isVegetarianOrVegan)
        passengerNames.push(passenger.passengerName);
});

console.log(passengerNames);

RESULT / 'forEach'

How to Solve with 'Filter' & 'Map'

To come up with the best option, this time, we will use two different methods. The 'filter' and the 'map' functions will – in a way – collaborate to create better logic when solving the given problem. Let's examine the following code snippet closely now.

const passengerNames = passengers.filter((passenger) => passenger.isVegetarianOrVegan).map((passenger) => passenger.passengerName);

console.log(passengerNames);

RESULT / 'filter' + 'map'

With the filter method, we only get the vegetarian / vegan passengers from our array in the first place. If it finds some non-vegetarian / vegan passengers (like our beloved 'Freddie'), it will get rid of them automatically.

Briefly, the first part of the equation, the 'filter' method will simply work through 'yes' or 'no' model.

Then, the 'map' function will come in, eventually giving us a brand new array showing the vegetarian / vegan passengers only.

This final solution will prove your future employer that you genuinely know what you're doing and you are really taking the right steps to be a hotshot developer.

Interview Question #3: How to Sort Passengers by Connecting Flights

The last section asks us to sort the list of our super cool passengers by the number of the connecting flights they'll take to eventually reach LA. Let's see who has more and as such, will be pretty exhausted.

Spoiler alert! Amy with four connecting flights in total might be a bit sleepy in the get-together at that fancy restaurant. But there is no doubt that she will somehow rock where ever she goes.

Image Source

Anyway, what we need for this task is to know how the 'sort' function operates.

Primarily, it compares items one by one and returns something as a result. In our case, it will be the number of connected flights. But how does it make that comparison? What is the logic behind that?

_[Source Code: MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/GlobalObjects/Array/sort"><nr-sentence class="nr-s149" id="nr-s149" page="0)

The above lines of code are pretty clear in general. Thanks to the 'sort' function, we list those months in alphabetical order.

Well, here comes the big question. How does the code / system know that 'a' is the first letter of the alphabet and as such, the list starts with the 'd' letter (December)?

The reason is that the 'sort function' lists things in ascending order by default. But can't we change this setting? Perhaps, we need to list items in descending order. Of course, we can.

Let's see how. To achieve what we want, we may utilise 'a' and 'b' letters as parameters leading to different directions.

_[Source Code: MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/GlobalObjects/Array/sort"><nr-sentence class="nr-s160" id="nr-s160" page="0)

Simultaneously, we can benefit from the assistance of three numbers: -1,+1, 0 as seen above. When sorting items in descending or ascending order or finding the equal values, they can be quite handy.

Tricky Bit of the 'Sort' Function

In the following example, the list is sorted in ascending order. Why is it like that? Here is the reason. When we return those 'a' and 'b' parameters, we use this order: 'a - b' . That gives us ascending values by default.

_[Source Code: MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/GlobalObjects/Array/sort"><nr-sentence class="nr-s169" id="nr-s169" page="0)

However, if we swap them and say 'b - a', the list will be seen in descending order this time. That's the tricky bit when it comes to the 'sort' function.

In the above example, the first version (regular function) and the second one (arrow function) are in essence the same, but just be aware that arrow functions came with ES6.

Although arrow functions help developers to write less code, you cannot use them everywhere. (Read this to find out when to use them.)

Testing Our New Knowledge

Shall we now analyse the situation of our passengers through our new perspective? We know that the last task asks us to sort the number of flights in descending order. But the following set-up does the opposite.

It can only give us the list in ascending order. Why? It's simply because of the pre-defined order (passenger1.connectedFlights - passenger2.connectedFlights) as in the case of a - b example.

 const numberOfFlights = passengers.sort(
  (passenger1, passenger2) =>
    passenger1.connectedFlights -  passenger2.connectedFlights 
); 
console.log(numberOfFlights);

Once we swap the order (passenger2.connectedFlights - passenger1.connectedFlights) as you see in the following code snippet, our problem will be solved and the list will come in descending order.

 const numberOfFlights = passengers.sort(
  (passenger1, passenger2) =>
    passenger2.connectedFlights -  passenger1.connectedFlights 
); 
console.log(numberOfFlights);

RESULT - Descending Order by the Number of Connected Flights / Michael is the luckiest :-)

Can We Also Use 'for loop' or 'forEach'?

Well, yes and no. Both would be low-level solutions for this question.

We should keep in mind that the sort function mutates an array. This is a kind of side effect which changes the original array and that might be a problem if we use 'for loop' or 'forEach' as a solution.

There are of course ways to avoid mutation in the sort function, but in our example, it will lead to more lines of codes, which is not practical at all.

Wrapping Up

We've started the article with David Goggins, the symbol of resilience and grit, so let's end it with his inspiring presence and ideas.

If you happen to read this modern day hero's book or listen to one of those famous podcast episodes (For example, this one) where he was a guest speaker, you'll immediately understand that he wasn't born that way. Rather, his secret lies in the fact that he never gives up, against all odds.

Coding interviews are tough, but if you keep going after your goals by visualising the scene of success in your mind over and over again, it will - sooner or later - be yours.

Image Source

Many thanks for reading this post. If you've liked this article, one of the best ways to support me is to share it. Should you have any questions or comments, you can always contact me via LinkedIn. I'll be more than happy to help you out with your queries.

Happy coding!

“Knowledge is power.” – Francis Bacon

We just published a course on the freeCodeCamp.org YouTube channel that will teach you about graph algorithms and how to use them to solve coding challenges.

Alvin Zablan created this course. Alvin's dynamic programming course is one of the most popular courses on the freeCodeCamp channel, and now he's back to teach you about graph algorithms.

Here are the topics and algorithms covered in this course:

• graph basics
• depth first and breadth first traversal
• has path
• undirected path
• connected components count
• largest component
• shortest path
• island count
• minimum island

Watch the full course below or on the freeCodeCamp.org YouTube channel (2-hour watch).

Transcript

(autogenerated)

This course will help you learn what you need to implement graph algorithms and use them to solve coding challenges.

Alvin's dynamic programming course is one of the most popular courses on our channel.

And now he's back to teach you graph algorithms.

Hey, programmers, I'm Alvin from Structy.

Welcome to our course on graphs.

And in particular, this is going to be about graphs for your technical interviews.

Of course, graphs are a very common topic when it comes to those technical interviews.

And in particular, what I want to emphasize throughout this course, is the handful of patterns that come up time and time again, on those technical interviews.

in just about two and a half hours, I'm going to give you all the tools you need to basically cover I'd say about 80% of all graph problems.

And so what I have in store for this course, well, I think the key to victory for your data structures and algorithms, and especially your graphs is to visualize things, right.

So we're going to do is trace through a lot of different algorithms, and be sure to understand them at a high level.

And that means going through different animations here, I think graphs have a pretty bad rap for being a difficult topic.

Because to a beginner, you can have very, very different narratives around a problem, and not really understand.

They're all really based on a graph premise.

So we're going to realize that a bunch of different things can be understood as graphs.

So when it comes to the prerequisites of this course, I'm going to assume that you know nothing about graphs.

But you do know how to code, right, so I'm going to have the expectation that you understand some recursion.

So as you work through the course, and learn about different graph patterns, we're going to use those patterns to solve some very classic interview problems about graphs, right.

And I'm going to give you plenty of opportunity to practice these patterns in different problems that we will be ready whenever you have them on a technical interview.

What I love about the topic of graphs is just using a handful of different algorithms, you can cover the majority of graph problems, right.

For every graph problem that we cover, we're going to split it up into two sections, section one is going to be about the approach for the video.

So we're going to go over the strategy and overall theory, and be sure to sketch out a nice meaningful picture.

We're also going to talk about the complexity of the algorithm in the approach video.

Following every approach, we're also going to implement the code of course, I'm going to be writing all of my code in JavaScript, you'll be able to follow along in any language that you like.

So that means occasionally I'll be switching to my code editor where you of course can follow along.

We're also going to be sure provide links in description as well as links on screen.

That way you can formerly you read the prompts for every problem, as well as look at the different test cases.

Alright, I think that's enough introduction.

For now, let's hop right into the course.

Alright, programmers.

So let's jump right into the course, I want to start by giving you some background about your graphs, we're going to go over the graph basics that you need to start attacking problems in a technical interview.

So first off, what is a graph? A graph is really just a collection of nodes and edges.

So with respect to nodes, you can visualize them as typically just some circles with some data inside of them.

So I'll put some letter values in my nodes over here.

And when we refer to edges, that would be just any connections between nodes.

So for example, if there was a connection between A and C, it would look something like this, right? What I can formally say is there's an edge between A and C, I can create many edges between any nodes I want within this graph.

Another word you might hear out in the wild when it comes to describing nodes, as you might hear the word vertex being used, right, they're really the same thing.

In this course, I'll stick to the word node.

And an edge is just a connection between a pair of nodes.

And that's really all a graph is at a high level, where things get interesting is how we can use this graph framework to actually solve a problem, right.

So if you think of these nodes as just things and the edges as relationships, a graph is grid describing the relationship between things.

For example, we can say that the nodes here are cities and edges would be roads connecting cities are in a similar way, maybe our nodes here are courses, and then the edges represent prerequisites.

And so in the future, we're going to use graphs as a way to illustrate and frame some narrative problem.

Let's talk about this graph.

In particular, here, I really have drawn a directed graph.

And that's because I have some arrowheads along the edges.

That would be a comparison to an undirected graph.

So here, I have really the same structure, except I don't have any arrowheads on the edges here.

And that means that there is no directionality to it right.

If I look at the directed graph, let's say I was at the node A, well, then I can travel to B or C, let's say I move to C.

However, once I'm at C, I cannot travel to a, I can only travel to E, right? That's because I have to obey the direction of the arrow heads here.

By take a look at my undirected graph, let's say I was currently situated at the scene over here, that I do have the option of traveling to either a or E, right? So if I traveled to a, that's all good, I can even travel back to C.

So think of as an undirected graph as a two way street.

For now we'll just continue on with our directed version.

Let me also introduce some useful terminology we can use when talking about the nodes in our graph.

If I was currently situated at this a node, I can refer to B and C as neighbor nodes.

Alright, so a neighbor node is really any know that's accessible through an edge, of course, obeying the direction of the edge.

In other words, if I was currently situated at the sea node, that I only have one neighbor of E, right, if I'm at the sea, you know, then I won't consider a neighbor.

Awesome.

When you visualize graph algorithms, you should really sketch a picture that looks just like this, right literally drop nodes as circles and arrows as your edges here.

However, when it comes to how we implement this algorithm in some code, we're gonna have to represent it in a more programmatic way.

Right? So in my brain, I think of this image of like nodes and arrows between them.

However, in my program, I'm going to use typically an adjacency list, it's probably our preferred way to represent and graph information, right.

So depending on the programming language of choice we're going to use typically, we would use some hash map data structure to represent an adjacency list.

Really, we're looking forward to using some constant time, I'll look up data structure that has a key value pair mapping, right.

So if you're in JavaScript, they'll be an object, if you're in Python, they'll be a dictionary.

If you're in a language like Java, or C, you'll be using an unordered map.

Looking at this hash map, I have drawn or this adjacency list, the keys of this adjacency list are going to be every node in my graph, right, so I just have all of the node values A through F laid out as the keys.

However, if you look at the corresponding values, the values are actually going to be an array, right? So if I look at this very first entry, it says that I have a node of a and then in the array of populated all of the neighbors have a that is a has two neighbors have BNC.

That's why I have this correspondence within my adjacency list.

That holds true for every entry within my adjacency lists.

So for example, let's say look at the entry for e.

So I go to the spot and make j c list where the key is E, it only has a one outgoing edge to be.

That's why the array for he only has be inside of it.

One thing to also note is even if a node has no neighbors, it should still appear as a key within my adjacency list.

For example, if you look at the D, node D has no outgoing edges.

That's why its neighbor array is empty.

However, it should still at least appear as a key within my adjacency lists, right, that way, you can still know that the D node exists.

So at the start of the course, will usually be taking in adjacency list as the information to represent a graph, right.

But as we sketch through things on the whiteboard, we should be visualizing them using a nice picture like this.

Awesome.

So let's actually jump into our first pair of algorithms.

To me, the must know algorithm for a graph is really going to be to do some sort of traversal on it.

Why don't we start by talking about a depth first traversal, something you may have heard of before, right, now we're going to talk about the depth first traversal algorithm that operates on a graph.

So let's start by understanding at a high level what order a depth first traversal would give you.

So let's say I had some starting node, and I'm gonna choose a as my starting node, right, so I'm gonna color it here in yellow.

If I was following a depth first traversal.

Now that I've, you know, chosen as my starting point, I can either hit B or C.

Next, I'm just gonna commit to using B.

So let's say I had the sequence so far have a comma b.

And at this point, if I was truly following a depth first traversal, I must go deeper to the D node.

In other words, I don't go to the C node yet.

Cool, that would be a true depth first traversal, right.

At this point, now that I've bottomed out at D, D is a dead end, right? I can't travel to F from D, because that would be disobeying the arrowhead.

And so now I can move to that other neighbor of C.

And from here, the algorithm would continue, right, I go from C to E, and then e to B.

And technically, I would have to double traverse some nodes like B and D over here.

So overall, in this yellow coloring, I have colored the full region that a depth first traversal would explore starting at a notice that if you started at a it would be impossible to reach F.

And that's kind of normal, right? That's kind of why we use these traversal algorithms that can tell you whether or not you can travel between some nodes.

And we'll see that literal problem later on.

Right? So you're probably wondering, you know, exactly how do we implement this, but for now, I just want to stay focused on the order that we got, right.

So just regarding our depth first traversal, we remember the first three iterations of the algorithm, we hit the sequence of a B, D, right, that's indicative of a depth first traversal.

Now let's compare that to the breadth first Marion.

So I'm going to lay down the same exact graph, we're also going to start a traversal at the a node, but this time follow a breadth first order.

So I have a first and let's say, you know, I chose B as my next node when it comes to breadth first traversal.

It doesn't matter like which, you know, initial neighbor you choose, so I'm just gonna choose B.

But now that I've chosen B, if I was following a true breadth first traversal, I must hit c next, right.

And that's the main difference between our depth first and breadth first reversals for the same graph, my depth first would start a B, D, whereas my breadth first would start a, b, c.

And so you're probably wondering, is there any importance between this nuance right? When would I prefer depth first over breadth first, or vice versa? Either a depth first or breadth first traversal would explore the same exact nodes within a graph.

However, it would explore them in a different order, right? And this is more obvious to see when we have a larger graph with way more edges.

And so let's look at how he depth first traversal explores again, but this time on a much larger graph, let's take a look at this one.

So I'm going to choose some random node as a starting point, let's say I chose this node in yellow, that was doing a depth first traversal, what I'm going to do is, you know, pick a direction and travel in that same direction as far as possible before switching directions.

So let's say I move to the right, at this point, I would have to continue moving toward the right, until I can't move to the right any longer, at which point, I have to choose some new directions, let's say it was downward.

I'll keep doing that until I can't move downward anymore.

And so I'd have to move to the left now, now I'd keep chasing this single path in a very deep direction.

So that's behavior indicative of a depth first traversal, right, you're exploring one direction as far as possible before switching directions.

Let's compare that to a breadth first traversal.

So let's say start at the same node in pink, if I was following a breadth first traversal, it would look something like this.

From the starting point, I would explore all of the immediate neighbors of this node, kind of in a circle like this.

Now I just keep applying that behavior.

So as you notice about the breadth first traversal, is it'll tend to explore you know, all directions evenly, right, instead of just favoring One Direction all the way through.

That's really the only difference between a depth first and breadth first traversal.

Later on the course, I'll bring up explicit problems where you might prefer one over the other.

All right, but for now, what I want to do is give you all the background you need.

So you can actually build this algorithm will kind of talk about things at a high level, consider this the pseudocode, then, of course, we'll express it in some JavaScript code later on.

So when it comes to actually implementing in code, these two algorithms, the key is to understand that a depth first traversal uses a stack, and a breadth first traversal uses a queue, recall that a stack is something where you add to the top and remove from the top as well, or is it Q is something where you add to the back and remove from the front, and it gives you two very different orderings.

That's really the only difference between these two algorithms.

So let's start by tracing through our depth first traversal, of course, using a stack, so I'm going to use a slightly different graph.

And to visualize my stack, I'm going to use this bar to represent the bottom of my stack, obviously, for me, at least I think of a stack as some vertical data structure.

Cool.

So let's say I just arbitrarily chose a as my starting node to perform my depth first traversal, right, in the long run, just want to print out all different node values within this graph.

So what I'm gonna do is I'm gonna take my starting node of a, and I'm just gonna immediately initialize it onto my stack.

So right now as the only thing on my stack, it's also at the top of my stack.

And now I can enter the flow of the main algorithm here, because I have a stack, what I can only do is remove the top of my stack.

So that means I pop off a from the stack, and consider the a node, my current node being looked at, right? At this point, let's say I print out a to my console.

And from here, what I want to do is consider A's neighbors, right.

So if I look at the C node, what I should do is just push c to the stack, then also push B to the stack, right.

And it doesn't matter like in which order you push these neighbors.

If I want it to hit B first, then I'm going to push them second, right? Awesome.

That would end like my first iteration of this depth first traversal.

Cool.

So at this point, I can look at my stack, and my stack still has some data on it.

So I should do is again, pop the top of my stack.

So I'm going to pop and be off my stack.

And that becomes my current, I'm also going to print it out.

At this point, I look at B's neighbors, B has one neighbor of D and so I push d to the top of the stack.

Notice that because I have a stack D ends up on top of the C, right.

And so now when I get to another iteration, when I pop the top of my stack, I look at the D node as my current, right, and I can print out D.

And this feels good because so far, my print order would be a BD, notice that I kind of pursued that single path deeply following a BD.

But I have to look at DS neighbors, I can take f and just push f to the top of my stack.

next iteration, my stack is still on empty.

So I should do is pop the top F is now my current, I can print out F, but f has no neighbors.

So F isn't going to push anything else to the top of the stack.

Right? At this point, I get to this next pass, and I pop the top of my stack.

And that means C is now my current, I can print out CS value.

And then I can look at Sue's neighbors.

And I just push e to the top of my stack.

On this last iteration, I popped up on my stack, he is now my current I print out he since he has no neighbors, I don't push anything else to the top of my stack.

And at this point, I've reached the state where my stack is empty.

And that means my algorithm is done right that means you explored as far as possible within your graph.

Notice that it might not necessarily be the case that you're able to hit every node of the graph.

And this particular example it was possible though, awesome.

So let's redo that trace using Our breadth first algorithm, which means we just adjust things slightly.

And we use a queue order.

Remember that a queue is a first in first out data structure, meaning things enter to the back, and then they leave from the front.

And so let's say I use this arrow to represent the directionality of my queue, right.

And I start the algorithm in the same way for my breadth first traversal.

Let's say I want it to begin at node A.

So I just initialize my queue with a cool, so I start by removing the front of my queue.

So a becomes my current node, I can print out a as well.

And now I consider A's neighbors, right.

So I consider B and C.

If I wanted to travel to B before C, then I should push B to my queue first, right, so I add B to the back of my queue, right.

And I should also add c to the back of my queue, right.

And that would actually end my first iteration.

So now I look at my queue still has some stuff on it.

So I removed the front of my queue, that means B becomes my current.

Of course, I print out B.

Now I consider B's neighbors.

So I just look at the D node, and I push d to the back of the queue, since D enters through the back and ends up behind the C, and that's really important behavior.

next iteration, I removed the front of my queue.

So my current is now see, right, I can print out see, and then look at sees neighbors of just E and I add e to the back of the queue, which means that in the order of my queue, he ends up behind the my next iteration, I removed D from the queue, and I print out the edits neighbor of F to the back of my queue.

next iteration, I removed e from the front of my queue, print it out.

Since he has no neighbors, he is not going to add anything else to the back of the queue.

And of course, finally, f leaves the front of my queue, I print out F, F has no neighbors, at which point now my queue is totally empty.

And since our queue is empty, that would be the end of our algorithm.

Alright, and that's all there is to our depth first and breadth first algorithms, they're going to be the nice baseline code that we use to solve many different graph problems.

I think that's enough theory.

For now, what I want to do is now switch to my code editor, where you can actually implement these in JavaScript, hey, programmers, here I am in my editor, what I want to do is now show you how to implement those depth first and breadth first algorithms.

So we'll start with the depth first.

And my goal is really just to build a function that will print out all of my values in the graph, according to a depth first traversal, right, we're going to define this function depth first print, making an arrow function in JavaScript, it's going to take in the graph, which is going to be given as a nice adjacency list.

And this is actually the same graph.

Now last example we traced out, I'm also going to need to specify some starting node here, I'll call it a source node, we're going to begin the traversal.

Starting at that node.

Cool.

And so we know inherent to a depth first traversal is going to be a stack.

So I'll show you how to implement this iteratively, which means you need an explicit stack.

For me in JavaScript, that's as simple as just using a JavaScript array, right? I'll make it empty at the start.

And I can use this array as a stack, if I just commit to using operations that manipulate the same end of the array.

In other words, if I just use push and pop, that will always manipulate the end of the array, right? removing and adding to the end of that array.

What I want to actually be sure to do is I want to initialize the stack with my starting node, that is with my source node.

Remember that like a node here is really just designated by some character.

Cool.

And when it comes to designing like the main loop for the algorithm here, do you want to keep running the algorithm while the stack is not empty? In other words, wall stack dot length is bigger than zero, that I have to keep running.

That's very reminiscent to what we expressed on the whiteboard.

So when it comes to performing like a single iteration of this depth first, what I want to do is remove the top of my stack.

So if I do stack dot pop, that will remove the last item of an array, in this case like the top of my stack, and also return it to me.

So I'm going to save that to a variable, I'll call it my current.

And so this point would actually be a great opportunity to just print out that current.

So I'll console dot log current, right? So looking at, you know, this example over here, since I initialize a stack to contain just the source note of a, on the very first iteration, this while loop, I would of course, pop out a, then I would print it out, right.

And from that point, what I want to do is consider A's neighbors of B and C.

So if I want to look at like the array associated with a, I can just key into my graph, right, cuz my graph is an object right now.

So if I say graph, square bracket, current, right, if current is a, that means graph, square bracket current would give me back this array.

I want to iterate through every node or every neighbor in that array.

So I'm going to nest a loop here.

And I say for let neighbor of that array.

So if you're familiar in JavaScript, if you just use a for of loop, they'll iterate an order through an array.

So now I'm hitting a neighbor as B and neighbors see.

What I want to do with those neighbors is simply Push them to the top of my stack.

So that will just be stacked up, push and push this neighbor.

Awesome, I'm going to be sure to push every single neighbor that has.

So sometimes I'll have two neighbors.

Other times I'll have one neighbor, or even no neighbors.

That's really all there is to implementing a nice baseline depth first print.

Something that I do want to point out, my favorite way to implement this algorithm is to consider like processing your node, when it leaves the stack, not when it enters the stack.

In other words, I usually write like my print statement, right after something is popped.

And the thing that I pop is exactly what I print.

Right.

So let's go ahead and give this a run, see what we get.

It looks like in my terminal, I got the order of AC e b df, which you'll notice is slightly different from what I expected from over here.

However, this would be also a valid depth first traversal, we have to bear in mind is you know, depending on like the arbitrary order of values within the same neighbor's array, you could tend a different direction at first, right? Most important thing I look for when it comes to verifying a depth first is to make sure that I you know, chase the same direction before switching directions, right.

So since I started out with a C, so I go a and then to a C over here, the next move would be going to E and that's exactly what happened in my code, right.

And then once I hit E is actually a dead end.

So then I can go on to my other lateral neighbor like B, right.

And so I can contrive the same order expected here, if I just flipped this right.

And so I put c followed by B.

I'll give that around.

They're both valid.

depth first traversals.

See what we got now.

Cool, now I get the exact order of A, B, D, F, C.

And really think about why that is, right.

So let's say that I just popped out a from my stack.

So I printed out a that's nothing fancy, right.

And then from there, I start iterating through the array that's associated with a right, so on the first iteration, I iterate through C, right? If I push C on the stack, let's say this is the bottom my stack, by pushing on the stack, it's right here.

Then followed by that I pushed B on the stack.

Now B is on top.

Since B is on top, I know like the next top level iteration, this while loop, I would remove B and that's going to be the next note I visit.

And so they're really both depth for sure Russell's.

Nice.

So two things to note, you're definitely going to use a stack to implement depth reversal.

And you can use the stack in a few different ways.

Right? So here I'm using like an explicit like array as a stack.

And I'm implementing this using some iterative code, right.

So using a few loops, right, what you can also do is implement depth first recursively, because I know any recursion uses the underlying call stack.

So let me show you how to implement that as well.

And when it comes to, you know, having all these different tools in your arsenal, I would definitely practice both the iterative and recursive flavors.

We'll see that later on in this course.

So let's say I wanted to solve the same problem.

But now recursively, it's actually going to be less code.

So I'm going to have the same sort of arguments, I'm going to have the graph which is the adjacency list as well as a source node, consider like the source node as like your current location.

So if I'm at some node, maybe the first thing I should do is just print out myself, right, print out this node, so I'll do is console dot log, this source node.

And that feels good just from the get because when we actually do a top level call to this recursive function, they're passing in a as the source node.

So I do want to begin a as a first note in my print, and then from there, I need to look at AES neighbors.

Well, if you want to look at as neighbors like before, just key into the graph, adjacency list using that node, right, and this would give me an array of CNB.

Now I just iterate through that array.

So I'll say for let neighbor of that array.

And at this point, what I want to do is now do the recursion, right, so I make a recursive call on each of these neighbors.

So for me, that means just called depth first print, you give the same graph, right, the graph object doesn't change, but you should change like the source node.

Now you want to pass in that neighbor as the source node.

And you're going to make a recursive call for every neighbor in that array.

And this would actually be all we need.

Let's go ahead and just run this version.

divider run over here.

Looks like now we get the order AC E, B, D, F.

And that's really again, another type of depth first print, right, not exactly this order, because this time we chased c first, right, we went a C, I want to get exactly this ordering and my recursion, then I would have to put in B first, really same sort of pattern.

Now let's get that into the run.

Good AB de FC.

One thing I want to bring up about this recursive first is it has no explicit base case, meaning there's no obvious like, if statement that just like returns like you'd typically see in most recursion.

That's because in this problem I have an implicit base case when a node like he is a dead end.

All right, let's say my current source coming in is he, well, then when I iterate in this for loop, I'm iterating through this empty array, I mean to have zero iterations.

If you have zero iterations, then you never make a recursive call.

Right? That's the same thing as having a base case, right? A base case is really just a scenario where we don't have a recursive call.

So that's how this code still works.

Alright, so now you know how to implement depth first in two ways, right, iterated and recursively.

And they both use definitely a stack.

Let me now show you how to implement your breadth first, right as well comment out some of this code.

Now we'll do a nice breath first, give myself some room over here.

So for a breadth first, we want to solve the swan iteratively.

And it's really only possible iteratively, right.

So I know a breadth first traversal demands a queue, if you try to like implement a breadth first traversal using some recursion, and under the hood, there's some stack data structure, that's going to fight against the queue order that you want, right? So for breadth first traversal, you're always typically going to be writing some iterative code.

So some loops, right? Let me define this, I'll say breadth first print, take in the full graph, adjacency list, as well as the source node, I want to initialize my queue.

With that source note, again, the queue here is just going to be an array in JavaScript.

So I'll say const q equals an array that begins with just the source node.

Awesome.

And I'm going to use this queue by just committing to two specific methods on my arrays in JavaScript.

So if I use array dot shift that removes the first element of an array.

If I do array dot push that adds to the last position of an Array.

And using those two methods in combination would give me a nice cue, right, add to one end and remove from the other end.

So like before, we're gonna have a while loop, we're gonna iterate while our queue is not empty.

And so while queue dot length is bigger than zero, nice.

And same thing as our iterative, you know, at first, you want to start by just removing the front of your queue.

So I'll say q dot shift, that will remove the first element as well as return it to me.

So I can save in a variable, I like to call it current, just like the whiteboard, right? And from there, maybe I'll print it out.

So console dot log, this current node.

And from here, just consider your neighbors, right.

So if I key into my graph, using this current node, that gives me an array of its neighbors, I want to loop through each of those neighbors.

So I can say four will say let neighbor of that array.

And for that neighbor, I want to add them to the back of my queue.

So for me, that would mean simply q dot push, I'm going to go ahead and push that neighbor.

Awesome.

So I remove from the front, and I add to the back.

So that looks pretty good.

Let's go ahead and give it a run.

And actually, before I do that, I'm going to change the order of this, put the CNB.

Again, doesn't really matter the relative order for neighbors, I just want this exact output, and we'll talk about why that is right.

Give that a run.

So I get ACB EDF just like I expected ACB EDF, right.

So let's say you're on the first iteration of this breadth first print, I know that I would have just removed a because I initialized a on the queue, right? So my current is a and I print out a and then from there, I start iterating through this array, right.

So on the first iteration, I have C, that means I put c into my queue, right? And then afterwards, I put B, if you put C and then B, that means C is at the front of the queue, which is why on the second iteration, I have C first, right? So that's how you can manipulate potentially the lateral order of a breadth first print.

Awesome.

That's all there is to this traversal algorithm, what I really want emphasizes, especially if you look at the apples to apples iterative code, you compare depth first or breadth first, it's almost identical code.

You're really just changing how you access items in your array, right? You either pop or push or you shift and push harder than that the whole like structure of this code is identical, right? All right.

So that's our introduction on depth first and breadth first for our graphs.

In the next section, we're going to start to solve a problem, right, which will be really fun.

I'm just utilizing this code as our baseline tool.

And then that section also promised that start doing the analysis for bego of these algorithms.

So let's jump back to that whiteboard.

Hey, programmers, welcome back, right, and let's go over the approach for this has path problem.

So in this problem, we're gonna take in an adjacency list representing a graph for this problem, and really all graph problems, you definitely want to visualize this one with a picture.

And so what we'll do is we'll interpret each key of this adjacency list as representing a distinct node.

And if I look at any particular list, I can see that this f node should point to G and I.

And they do tell us in this problem that I have a directed graph.

So I'm going to draw arrowheads on these edges here.

So F points to G, as well as f points tie.

And I'll create similar edges based on the information in the given graph.

So we end up with an image like this, until they tell us that this is a directed graph that explains the arrowheads, but they also tell us that this graph is a cyclic.

So if you're unfamiliar, a cyclic just means No cycles, that kind of begs the question, what is a cycle in a graph.

So a cycle would be a some path through nodes, where I can end up where I want started.

In other words, if I started at the a node over here that I can go to B, then from there, I can go to C, then back to a, and so on and so forth.

So if I did a traversal, on the Sigma graph, I would get an infinite loop.

And what they're saying is, our graph input is guaranteed to be directed.

So it has arrowheads, but also a cyclic, so we don't have to consider any infinite cycles here.

That being said, In this problem, we also want to take in not only the graph information, but also a source and destination node, we want to do is return true or false indicating whether or not we can travel from the source node to the destination node.

In other words, is there a path that exists between those two nodes? For this problem, you can use either a depth first or breadth first search to actually solve the problem here, I'll trace through in this approach video, just the depth first search.

But in the walkthrough, I'll be sure to code it up both ways.

So let's say started at my source node, I know that if I was doing a depth first traversal, I can either choose the IRG, let's say happen to choose to G next.

Now I have no choice, right? If I'm doing truly a depth first, I should go deeper to the H.

So then I hit this H.

And as I traverse through these different nodes, I need to ask myself if my current node is equal to my destination.

So far, that hasn't been true.

At this point, I bottomed out with my h node, I can't travel any deeper.

So now I can move laterally to a node like I, at this point from I can either move to a K or a G, let's say by luck, I just happen to go to the G, this would actually bring me down a path I've explored previously, which we can optimize later on, but wouldn't be too much of a big deal.

Eventually, if I continued this depth first search through the graph, I would end up at a node that matches my destination, at which point I can return true signifying that there must be some path from F to k, just doing a depth first search.

And as we do this depth first search, it's really important that you obey the directions of your arrows.

So I should never try to travel upstream.

So that was a scenario where we were able to find a path from source of destination.

That's why we return true.

Let's reset and say that now, I should return false.

Alright, so let's say my source was J.

So I start at J.

And I'm trying to get to my destination of F.

If I start a depth first traversal, here, sorry, my j node traveled to the AI node.

At this point, I can hit either the G, okay, let's say I happen to hit the k, this point of bottom now.

So now I can move to the G.

And then from there to the H.

And at this point, there's actually nowhere else I can go, right.

So if I finish my traversal through the graph, using either a depth first or breadth first and I never hit my destination, then I can just return false, right? It must be the case that there is no such path from my source to my destination.

When it comes to implementing the depth first and breadth first reversals on this graph, it's going to be exactly what we're used to, you can either use a stack and solve it recursively.

Or you can do it iteratively.

And use a queue in which case you'd be doing the breadth first traversal.

We talked about the complexity of this, let's say that n is the number of nodes of our graph, a common thing that you can also do with these graph problems is define e as the number of edges here and edges refers to a connection between two nodes, basically just the arrows.

So if we use these two terms of number nodes and number edges, we would have a time complexity of our V o of the number of edges as because we would have to travel through every single edge of our graph.

Here, the space complexity would be based on the number of nodes, right? If I solved it, recursively, or even iteratively, with some sort of a depth first stack, then the worst case, I would have to have every single node on the stack, right? Likewise, if I saw the eternity with a breadth first I would have every single node on the queue.

So that's just one way we can define the terms for analyzing the time and space of this graph.

Typically, for graph problems, another acceptable way to analyze the time and space of your algorithm is to just use a single variable and just define n as the number of nodes.

That's because if you say n is the number of nodes, then we can also say that n squared would be the number of edges, or that big O.

It's about the worst case.

So let's imagine the worst case graph.

Let's say I just had these nodes of ABC.

Well, if I wanted to create as many edges as possible, how would I just create a single edge? Well, an edge is just a connection between two nodes.

So you could just really draw an edge for every pair of nodes in your graph, something like this.

And that's why we can say that n squared is the number of edges of any particular graph.

And so if you just wanted to use n to define the complexity here, then you could say that your time is going to be O of n squared, and your space complexity would still be O of n.

Do know that these are both two valid ways for defining the complexity for a very typical graph problems.

That being said, I think this is pretty straightforward.

Let's hop into the walkthrough video while we're actually implement both a depth first and breadth first solution for these.

I'll see you there.

Hey, programmers, Alvin here, right now.

Let's go over Ah, JavaScript solution for this has path problem.

And so we'll jump right in, we're gonna start by solving this one using a depth first traversal, which I know requires some underlying stack data structure, I'll just implement that using recursion.

So I can leverage the call stack to get my ordering.

And so I'm gonna solve this recursively, I'm gonna consider my source argument as like my current position during the traversal.

And so I can have a base case in check.

All right, if my source is equal to my destination, that I must have found the thing I'm looking for.

So just return true.

This base case signifies that I found my destination.

So there must exist a path.

And so I return true, always paying attention to the type that they want us to return for this function.

Let's say it's not true, well, they need to keep looking.

So what I should do is consider my current node, which is source, consider its neighbors.

If I key into my adjacency list, I know that this is going to be an object.

So I key into it using my source, that would give me an array of all of its neighbors.

So for example, let's say it was staring at this one, if my current source was F, and I say graph square bracket, F, I would get back an array of gi.

So now I want to look through the neighbors, right? So I can see over here is turned us into a loop and say for that neighbor of those neighbors, I want to traverse to them, which means I call recursively.

Right call has path, keep your graph the same, but update your current position.

Now I'm going to be situated at the neighbor.

And the destination stays the same, right, always have the same goal to get to solving this one recursively.

So think about what type of this is going to return, I know it's going to give back Boolean, right, it's going to tell me whether or not there is some path between my neighbor and the destination, right.

So if there's some connecting point, or some connecting path between my neighbor and the destination, then I know that there must be some path from my source to the destination, because your source is definitely next to your neighbor, right.

So there would be a path between all of us.

And so what I'll do is, check if this recursive call returns true, I'll make it explicit here, maybe it's clear.

And so if there is some path through my neighbor to the destination, then I can return true, just pass that true upward.

Because once I find a path, you can just exit out and return that shoe all the way back to the top level of color.

But let's say that this call returned false, that means that there is no path through my neighbor to the destination.

But it couldn't be the case that some other neighbor is actually going to work out.

And so what I don't want to do is just say like else return false, you should be able to immediately catch that code like this as suspect because there's no point of having a for loop then right? If in either case, you're always going to return, then you're never going to have a second iteration of this for loop, right? So if I don't find a path through my neighbor, so if this call returns false, then that's okay.

Just continue on to the next iteration, and search through your other neighbor.

that begs the question, Where should we return false, needs to be after the for loop? So only after I searched through all of my neighbors, and I never find a winning path? Should I return false, and that'd be our nice depth first traversal.

Let's give that a test run.

Awesome.

There we have it.

One thing to bear in mind here, we are leveraging the assumptions in the problem, right, they tell us straight up that the graph is going to be given is a sick like, so there are no cycles.

So that's why in our code, we didn't really worry about getting trapped in an infinite loop.

In our upcoming problems, we'll have harder grass to actually deal with that sick case.

But for now, this is a good baseline solution.

While we're here, let's also do a reference solution, which you know, by now should be iterated, right, there's no way to do like a breadth first recursively.

And so I need to create my own queue.

So I can create a queue, kind of in a pinch, I always just use an array in JavaScript, I'm gonna initialize that queue with my source on it.

So I'm gonna refer to like source and destination, they're really nodes.

But in the context of like our problem, they're really just given us strings, but they represent nodes, right? So think about the information they represent.

I'm going to iterate while my queue is not empty.

So while q dot length is bigger than zero, should be familiar code, very similar to our tree algorithms.

And I start a single iteration of reference by removing the front of my queue.

So I can say q dot shift some of the front, I can call that my current node that I'm traversing through.

And now that something has left the queue, typically here is where I check, I can check.

All right, if a thing I just visited, if that is my destination, then I can just return true, right, I found the thing I'm looking for.

So there must be a path that connects my original source and my destination.

Nice.

But let's say this was not true.

Well, then I need to consider its neighbors.

So like before, look at the neighbors just key into your graph using the source like it's a graph, square bracket source.

That gives me an array of all of the neighbors, all the neighbor nodes.

That's what I want to do here is iterate through every neighbor Over there.

And then I can just add them into my queue.

So q dot push that single neighbor, and do be sure to implement your true breadth first.

So you need to make things leave from one end of your queue, and you add to the other end.

So this codes looking good.

So you should realize how similar This is to our old like binary tree breadth first, except now we have to account for the fact that we could have like a dynamic amount of neighbors here, not just dot left and dot, right.

So I'm just iterating through all those neighbors adding them, I need to wait to return false.

And you guessed it, the move is after you finish this entire while loop, if your cube becomes empty, then you must have explored as far as you could.

And if you never return true, and now you can return false, because it must be the case that there is no path between the original source and your target.

So let's give this a test run will have a very similar time and space complexity.

But this would be the code for all of my iterative fans.

So here I'm getting a little error.

Let's see what we did wrong here.

So it looks like I timed out here.

Let's see bug this one together, I had to guess that means I did something wrong getting trapped in an infinite loop.

This condition looks okay, right q dot length greater than zero.

And so here it is, must be the case that I'm not correctly iterating through the neighbors here, I just wrote source.

Instead, I need to say current, because now I'm doing this iteratively, right.

So whatever node has just left my queue, I consider that nodes neighbors and add them to be visited next through my queue.

So let's give that a test run.

honest mistake there.

Cool.

And there's our breadth first solution for this has path problem.

So what I want you to do is practice both the depth first and the breadth first, like you expect, we're going to do a lot of graph problems coming up.

And depending on you know what the problem is asking sometimes will prefer one type of algorithm over the other.

So it's really important that you practice both of these algorithms.

Now, all the problems are relatively easy.

So practice this, give it a shot on your own.

And I'll catch you in the next problem.

See you there.

Hey, programmers, Alvin here, right.

Now let's go over the approach for this undirected path problem.

So we'll jump right in.

In this problem, we're going to be given an edge list for a undirected graph.

So if I are familiar with the terminology here, really what we're saying is every pair and this edge list represents a connection between two nodes.

For example, if I look at the first edge, and the list, I see i comma j, that means that there's a edge or connection between i and j.

And since this is an undirected graph, not only can I directly travel from i to j, but I can of course, move from j to i.

So it really represents a connection in both directions.

And so as we start to attack, this problem we'll want to do is actually convert this edulis into a more favorable format, like an adjacency list.

That's because typically, when we perform our traversal algorithms, they work best on an adjacency list form.

So let's start by doing that conversion here.

And I'll actually be pretty easy to code up.

So I want to basically generate a graph where I have nodes as keys, I want them to point to a an array of their neighbors.

For example, if I wanted to convert the first edge into an adjacency list form, what I can do is create keys for i and j.

Now that I is a neighbor of J, and also j is a neighbor of I, so I'm going to populate those neighbors respectively.

Now just follow this process for another edge.

So if I look at the edge, k comma i, I need to create a new key for K.

And I'm going to populate that with I and then for the existing key of I, I just add k into that collection.

So do bear in mind, the most important thing about this conversion is because we know that the graph is going to be undirected, whenever you put a connection within your graph, make sure that you have the inverse connection.

So if I have an edge from k to AI, they also need to have information for it.

Okay.

And this process would just continue for the entire list of edges.

And by the end of this conversion, we'll end up with an adjacency list just like this.

And now we're ready to perform our main algorithm.

When we go through the code walkthrough for this, I'll show you in depth how you can actually create this adjacency list.

And so when we want to actually come up with a traversal algorithm to solve a graph problem, it really helps if you actually visualize the shape of your graph.

So actually want to visualize this in terms of nodes and edges.

That means a bunch of circles and lines between them.

If you drew out a nice picture for this graph information, you would end up with a diagram like so.

And so we'll go through the rest of this approach video just referencing this diagram.

Something important I want to bring up at this point is for this graph, a very common case we'll have to handle is what if your graph has a cycle.

And that's especially true for your undirected graphs.

And so just for the purposes of this approach video, I'm going to add an additional edge just so we can talk about an explicit cycle.

So I'm going to add one new edge from k to J.

Cool.

The reason is now there's a nice big cycle of length three highlighting in red right now.

And this cycle is important to watch out for because if we don't do any special handling Then we may get trapped in an infinite traversal.

So imagine I started at this keynote, and next I moved to J, then I would move to i, and then back to k, and then back to J, and then I, and so on.

So now it gives me a cycle, we'll have to guard against that.

And so I can have a cycle of three nodes here, right, and you can really have a cycle of basically almost any size, as long as it's more than one.

So for example, if I took a look down here, notice that my graph actually contains technically like two separate islands, but we would consider them as just one giant graph, right? So I've got the small island of O and N, they actually form a trivial cycle, right? If I started traversal, at o.

From there, I can move to n.

And because I know that the edge between o and n is bi directional writes an undirected graph, that means I can travel back to O, and then back to n.

And this would give me cyclic behavior.

So have to watch out for all types of cycles in this problem.

So in the context of this problem, not only are we given a graph, we're also going to take in a two nodes.

So let's step through an example where I want to return true or false, is there a path between I and L.

So I'm going to mark those in my graph Israel.

So I'm going to start at the notify.

And to solve this one, you can use any type of traversal.

So either depth first or breadth first, I'll step through explicitly the depth first traversal.

Right.

Now, in order to avoid any infinite traversals, I want to mark my nodes as visited as I travel through them.

So not only do I situate myself at this source note of I, but I'm gonna mark it as visited.

And you can implement this like marking a visited pattern.

And a few different ways.

When we code this up later on, we're probably going to use a set to represent what we have visited.

But for now, I'll just check them off in my diagram.

And so in my diagram, if you see a checkmark next to a node, that means that I already have visited it.

So since I'm at this node of I want to move to its neighbors, so I'm gonna move to the neighbor of J.

And I'll also be sure to check it off as visited.

At this point, I can move to one of Jays neighbors, let's say I move to k.

And I'm also going to mark it as visited.

Now then Matt K, I can move to a few different neighbors, I could either move to I LRM.

Let's say by chance I chose I, I once I get to this, I know, I'm immediately going to be able to see that, oh, I visited this node previously.

So what I should do is not travel through it again.

Instead, I should go back to the K, right, because this eye node is already visited.

And that's where I actually avoid the infinite loop.

So instead, I moved to some of Kay's other neighbors, let's say I chose the L.

At this point, I would mark it as visited.

If I do a quick check, I can see that this note I'm at L is also my destination node.

So I must have just found a path between my source and the destination.

So at this point, if I find my destination, I can just return true, which was a pattern we spoke about in a previous problem, the only additional criteria we need is to mark nodes as visited.

That way, we don't get trapped in an infinite loop.

And that's only going to be needed if we have cycles in our graph, which if they don't give us any assumptions we should always guard against.

So let's take a look at another example.

Let's say I had a source of K.

And my destination was Oh, just looking visually in the graph, you can already see that there's no way to get from k to O, because they're disconnected, right, they're on separate islands both step through the algorithm regardless, so I'm going to start at K gonna mark it as visited, I'm going to visit some of Ks neighbors.

So I can move to i, then I can move to J.

And then at this point, I would move back to K and really make sure they don't explore any of Ks visited neighbors, so I don't move back to I right, instead, I should move to an unvisited neighbor, like l market is visited, then I only have one other node to visit, which would be this m node.

And at this point, I've actually exhausted this full graph region, right, there's nowhere else I can go.

And once I finished my traversal, if I never find my destination node, then I can just return false, right? It must be the case that there is no path that exists from my source node to the destination node.

That's really all there is to this algorithm.

Let's talk about the complexity.

If we say that n is a number of nodes, let's also define that he is a number of edges.

Like we said previously, this is something typically acceptable to do for our graph problems.

I know that the time complexity is going to be roughly of the number of edges.

And my space complexity is going to be O of n that is the number of nodes.

I think it's worth stepping through, you know what this complexity actually means, you know, big O refers to the worst case.

So let's think about a worst case graph that we can have.

And there are a few different graphs that you can kind of design and think of, I'll just show you one example.

So let's say I was given a graph like this, right? Notice that although z is kind of on its own island, all of these nodes that is a three as well as a C note.

They're all members of the same graph.

So let's say I wanted to figure out is there a path between A and z.

So if I did my traversal algorithm from here, I'll start at a then I move to B, and then to C, and then to D, and then to E.

At this point, I've covered all of the edges in the graph.

Remember that the edges are the arrowheads here, because I have to travel through every edge of this graph.

That's why we said the time complexity in the worst case is going to be o of E, right o of the number of edges.

and here we can say the space complexity is O of n.

Because if you're doing this with either a depth first stack, or a breadth first queue, in the worst case, you would have to add everything you visited, or that is all of the nodes onto your stack or queue.

That's why we say for regular graph traversal algorithms, we have a time complexity of o v, and a space complexity of O of n.

All right, I think we have the approach for this algorithm down pat.

At this point, I want to join me in the walkthrough videos, where we can actually see how to implement these visited patterns in some code.

I'll see you there.

Hey, programmers, Alan here, right.

Now let's go over a JavaScript solution for this undirected path problem.

So we'll jump right in, just like we said, in the approach video, there's going to be a two parter.

First, we're going to convert our edge list into an adjacency list.

That way, it's easier to do a classic traversal through it.

So I'm going to pretend I had a helper function here.

That gives me back an adjacency list.

I'll call it graph.

And I'm going to call this helper function, we'll say build graph.

And if I pass it, just all of my edges, I want it to do that conversion for me.

So let's work on that helper function right now.

And then we'll jump back to undirected path.

So I'll create my build graph function, just going to take in the edges, right.

And I know I want my adjacency list to be in the form of a plain old JavaScript object.

So create that graph object here.

And I'm going to return it by the end just like this.

And what I want to do is fill up this graph with information from the edges.

So I'm going to iterate through every edge.

So for let edge of edges, so iterating, through every single edge, I know a single edge would be a pair.

So I'm just gonna de structure out of that, maybe just my two node identifiers, we'll call them a and b, from the edge.

Nice.

What I want to do is now initialize these nodes as keys of this graph object.

So a would be something like this, I note or this k node, right.

So what I'll do is check if A is in my graph, I think really clean up this code, we better if I check if it's not in the graph.

So if the a node is not in the graph, then what I can do is initialize it in the graph.

So use it as a key and assign it to be an empty array.

And I'll do the same for B over here.

Right, so I'm initializing A and B in the graph if they don't exist, and once I do that, then I can safely just add neighbors into their their edges, right? So I can say, the graph square bracket a dot push B.

So now I'm saying that right, B should be a neighbor of a, but I know that this is an undirected graph, right? So that should be symmetric.

In other words, then make sure you push a into the neighbors of B.

So it's really important that you notice that this is an undirected graph.

So your adjacency list needs to be symmetric in that way.

So if a is in B's neighbors, B should also be an A's neighbors.

So that's looking pretty good.

Let's go ahead and see how that graph looks just with a little little side test here.

So I must steal maybe this snippet, get that full snippet here, I could just run it manually love to make sure I can test these little helper functions before I use them.

So we'll give this a run, we should just see the adjacency list form of these edges here.

See how it looks.

So that looks pretty good.

So I'm seeing that all right, I is connected to J and K.

Right? And that looks correct based on these edges.

Awesome.

And I'm also want to make sure that it's symmetric, right.

So if i and j are over here that I should have JNI over here as well, right, it should be a two way street.

Alright, now let's work in our real algorithm here, which would be some sort of traversal.

Now that you have a nice adjacency list, you can do either a breadth first or a depth first traversal.

I'm going to implement I think, a depth first.

Typically for me, it's just easier to raise push if I do it recursively.

And so I'm going to pretend I had a function called has path, it's going to take in my graph now.

And also a start node and an end node.

So I want to find a path from node A to node B, of course, I'm going to assume that this function returns a Boolean.

But of course, I have to write that function for myself.

So stay organized in our code, we'll say has path.

I'm going to take in the graph as well as node A and node B.

And I think a better name for these arguments as I'm doing this recursively.

Let's call this one source and this one destination.

So over time, we're going to call recursively and update this source node.

And that should be a familiar pattern to some other problems resolved.

Recently.

So think about my base case.

All right, I know that I've has successfully found a path when my source is equal to my destination node, if that's the case in return true, because I just found a path.

Otherwise, I have to keep looking.

So I should be able to look through the neighbors of my source node.

So I could say graph square brackets source, right? Remember that any point through this recursion source represents my current position.

If I say graph, square bracket source, let's say source was I, I'd be accessing all of ies neighbors, right? So I want to do is really iterates for let neighbor and, or rather have graph of source.

So if sources I on the first iteration neighbor would be j, second iteration neighbor might be K.

And for each of my neighbors, I want to travel to them.

So call has path, you can keep your graph argument the same needs to change your source though now you're situated at your neighbor, and your destination is fixed, or you're always trying to get to the same exact node.

I'm gonna think about what type this returns I know this is going to tell me Boolean, right? True or false? Is there some path from my neighbor to the destination, I'm going to check.

All right, if that call, returns true, I'll be explicit here, then I've just found a path.

So just return that true, right, pass it all the way back up.

And kind of the logic that we form here is, I know that by definition, source and neighbor are definitely connected.

So there's definitely a path between them.

They're connected by a direct edge.

So if my neighbor has a path to the destination, then I know, then the source also has a path to the destination.

Awesome.

And so after this for loop is done running, let's say we never find that any of our neighbors make a winning path, then means I finished this for loop without ever returning true, which means that I can return false right must be the case that this source node does not have some path to destination.

So I think we can go ahead and give this code a test run.

If you watch the approach video, you'll notice that there's something important missing from this code.

But we'll just run it and show you how to fish here.

So here I'm getting an error edges is not defined what I do horribly wrong, line 34 months ago, line 34 over here.

So got to take out this call, don't need that anymore.

That's on me.

Let's get that test run.

So that was not the error I was expecting.

I am expecting some sort of an infinite loop, though.

Perfect, I'm getting maximum call stack size exceeded.

So I got like an infinite recursion really.

And that's going to occur because we didn't account for the case where we have cycles in our graph, right, we need to avoid that.

Because if I have a cycle in my graph, I'm never going to hit any of these base cases, I'm just gonna keep traveling around in a circle.

And if that's unclear, make sure you watch the approach video, right.

And so like we said, the move here is to add some sort of data that shows where you've been previously.

Typically, the way we do this for our graph problems is to track some visited set.

So when I make my top level call to this house path, I know that that is the actual function that does that traversal, I'm going to pass along a new argument here.

And I'll make it a new JavaScript set.

So if you're unfamiliar with sets, and JavaScript, they're really just a collection of items.

And what's really great about a set is in o of one time, I can add something into the set.

And I can also check for something within the set is going to be very, very quick for our traversal.

I don't want to use something slow like an array, because to do a lookup or a check within an array, that would actually be O of n time, or it's for a set, it's o of one.

So I'm going to make a new argument here to receive a column visited.

What I want to do is all right check if my source node is already in the visited set to do that in JavaScript I can check visited out has.

So if the source node is inside of the visited set, then I could return false here, right, there's no reason to travel through this node anymore.

Because if it's an visited then I must have traveled at previously.

And this is how I can avoid an infinite recursion can also move this line downward if I wanted to.

And let's say that I make it through this if statement.

So that means that all right, this node source has not been visited.

But I'm visiting it right now.

So I need to do visit a dot add source.

So this expression checks if source is in visited, and this expression adds source to the visited set.

I want to change a few other details here.

Make sure that you pass along the same visited set through all of your recursive calls over here.

Because you want this visited set to be like global for the entire traversal right I need to know exactly where I've been in the past.

And once we have that in place, that should be everything we need to prevent any any cycles from giving us infinite recursion here.

Let's give it a test run.

Awesome.

There's a solution for our undirected path problem.

So important things to take away here do consider this problem, a two parter right? phase one is really straightforward, just converting an edge list into an adjacency list, which is actually an important skill to practice.

Because when it comes to, you know, some problems you'll face in the wild, they are all going to be basically graph problems.

But sometimes they'll give you the graph and like a different format, and you can always convert into a format that you're comfortable with.

And from there, we have a really core pattern of just doing a traversal through a graph, but also guarding against infinite loops, right.

And to do that, we just use some sort of a visited set.

Hey, programmers, welcome back right now want to go over the approach for this connected components count problem.

So in this problem we want to do is take an adjacency list representing an undirected graph.

As always, with any graph problem, you want to start by visualizing the actual graph.

And so if you took a picture of this information, it would end up looking like a graph with this structure.

The first thing we should notice about this visual graph is that a has multiple connected components.

So for example, I can look at this component in pink spanning just the one and two nodes, I can look at another component spanning the four or 5678 nodes.

And finally, a third component just covering the three node.

And that's why we say that your result for your function here should be three, right? Because there are three different connected components.

So let's come up with an algorithm we can use to count the components, we know that a general counting algorithm is going to use some variable, and we'll initialize that count variable to zero.

And the trick here is to use a combination of both some standard graph traversal code, maybe a depth first as well as some iterative code.

So I'll do along the left hand side is just list out all of my different nodes.

And what I'll do is start by iterating, through every node of this list.

And what I'm going to do is when I'm currently at some note of this iterative list, I'm going to start a traversal at that node.

So right now starting at the node of one, I begin, let's say a depth first traversal, you can really implement this pattern using either a depth first or breadth first.

So let's say I start at the one node over here.

What I should do now is continue this traversal as far as possible, that's the key to victory here.

So from this one node, I can move to a neighbor of two.

And of course, as I travel through these nodes, I want to make sure that I mark things as visited, so I can avoid loops.

And marking things as visited will also ensure that we don't double count any components here.

Once I hit that to note, I've actually completed this full component, there's nowhere else I can explore.

So at this point, I should increment my count by one.

So whenever I complete a new traversal on some region of the graph, I need to increment my count.

At this point, I now fall back to my iterative code on the left hand side, and I iterate through the next node.

So I now look at node number two.

If I take a look at node number two, I see that I already have it marked as visited.

So that means I don't need to start a traversal at that node.

So effectively skip the two and keep the count the same.

next iteration I have a three, three is unvisited right now.

So I should begin a new traversal starting at this three node, which means I just mark it as visited.

And since this three is a singleton node, right, it's not connected to anyone, I would actually complete their traversal, just on the three node.

At this point, I've completed a traversal.

So I increment my count by one.

So now I have a total count of two, I fall back to my iterative code.

So I moved from the three node to the four node.

And I see that this four node is unvisited, which again means I must begin a traversal from this four node.

And I'm going to expand this traversal.

Starting at four as far as I can, before I go back to my iterative code, right, so I'm going to explore the six, explore this five, explore the seven, and finally explore this eight.

At this point, I've completed a traversal.

So I can increment my count up to three.

And then I have to continue and fall back to my iterative code.

So look at the five node, I see that the five note is already marked as visited, so I don't start traversal.

And I see that the six node, same thing don't need to start traversal seven note already visited, eight nodes already visited.

At this point, I would be done with the entire algorithm.

And there's my final count of three.

So a few interesting mechanics here, right, you're going to need to definitely implement some code or some function that does a traversal through some component as far as possible, then you also need some iterative code just to potentially begin a traversal at every single starting point.

And what you want to do is be sure to mark nodes as visited as you traverse them, because only when you marked a new node as visited and complete that traversal should you increment your count.

You're probably wondering the exact details of how we implement this in some code, but don't worry, you'll realize that it's really just a spin off of our previous graph algorithms in the walkthrough video, but for now, we see that n is a number of nodes And he has a number of edges like usual, we know that this is really just traversing through the entire graph.

So we can say the time complexity is just o v, and the space complexity is O of n, right, depending on whether you do a breadth first or depth first, you're going to use that space, then in terms of your stack or cube.

And we can also consider using the space within our set if you use a set to mark your nodes as visited, but overall, it still will lead to a linear time and linear space solution.

Alright, I think I'm ready to code this one up.

I'll see you in the walkthrough video.

Hey, programmers, Alvin here, right, now let's go over a JavaScript solution for this connected components count problem.

And so we'll implement exactly the strategy we spoke about in the approach video.

So make sure you watch that first, we know that this is going to require really two different mechanisms are going to need our interactive code just to hop to different connected components.

And we also need some traversal code to just explore some single component as far as possible.

And so what I'll do here is let me start with the iterative code.

So I need to begin a traversal at every potential node.

So I can say for let node of my graph really say in my graph here, because for this problem we're given looks like JavaScript objects.

So if I say for let node in graph that would give me each of these keys like 015, and so on.

And so for every node of the graph, what I want to do is begin a traversal.

So we're going to assume I have a function here, I'll call it explore.

I'm gonna pass in, of course, the graph, as well as that node.

And what I want that function to do is do like a, we'll say, a depth first traversal, from that node as far as possible, right, so probably going to need to add more logic into this main function.

But for now, I think it's about time to actually flesh out explore.

So I'll choose to do this explore method recursively.

So we'll define explore, it's going to take in a graph, as well as my current node, I'll just call it current, right.

And then from there, I want to solve this one, using a depth first.

So recursion is fine.

And not much to do here, but really go through my neighbors want to iterate through every neighbor of this node.

So I can say like neighbor of graph of current, I recall that graph would be an adjacency list.

So if current is spread this out.

So if current was a node like eight, then on the first iteration neighbor would be zero, next iteration neighbor would be five.

So here, I'm just going through all the neighbors of my current node, I just need to not traverse to them.

So I can call explore, pass along the same graph, that doesn't change.

But now my new current node would be that neighbor, just like that, and this will perform the baseline of just the kind of depth first traversal.

But we need to also mark things as visited, like we said, in the approach video, that's a really important a part of the solution.

And I want this like visited set to be global for my entire traversal.

So I'm gonna have to create it, maybe my main function over here.

So I can create my constant visited, make it a JavaScript set, because JavaScript sets off for me O of one lookup, and o of one addition, I can pass this visited set my reference until all of these calls over here.

So I know I'm gonna receive visited over here now.

Now I want to actually start using visited.

So a few things to note, right, I definitely want to use visited to prevent cycles, right? That's one of the main reasons we always had visited to our graph traversals.

So some familiar code here.

If I've already visited this node, so if visited, has this current node, then nothing much to do here, maybe just return false.

Later on, we'll see.

The really cool trick we use here by returning false, right, actually serves two purposes.

return false because this might be a cycle.

And then I need to make sure that I pass as visited set along over here as well.

Nice.

And let's say that we have a current node that is not visited.

So this statement is false.

Well, then, it seems to be that we're visiting this node right now.

So now we should add it into the visited set.

Nice.

And then beyond that, we need to make sure that our explorer function is consistent in its type, right? So I'm going to have my explorer function do is it's going to return true whenever it explores like a new node return true.

So if you take a look at this code, for my function to hit this line 17 return true, then it must be the case that it has already finished exploring all of its neighbors, right, because I know that this for loop does the job of exploring all of the neighbors, right? So only after all of those neighbor calls returned.

Will I return true? And that must mean that I've explored this component as far as possible.

Right? And that seems good to go.

And what I can do is now in my main function, when I call explore it, now it's going to give me boolean data, right? If it's exploring a new island, or a new component, it's going to return true.

So I can check.

All right, if explorer returns true, then that's a new component.

So I can probably increment some count here, I should have created.

So I'll say 11, counts equals zero, I'm going to increment that count, when I find a new component and plus equals one by the end, I should of course, return that counts.

And what you'll notice is, for scenarios where we, let's say iterate into a node that we already explored, when I make this call, I know that that call is going to return false, because if something's already explored, it would have been added to visited.

So that's why I'm using some Boolean return values for this recursive function.

So that code is looking pretty good.

I think at this point, we might be ready to test this one, let's give it a shot here.

So some pretty tricky codes, not very long.

And this is a really core pattern here.

Looks like I'm getting an error, we have something wrong here.

So looks like the answer should have been two, but I gave back seven.

So I'm counting way too high.

So what I'll do to debug This one is really just maybe print out my visited.

So this is a very common mistake in JavaScript want to bring in, I think this example, I could test it manually.

What I want to be sure to do is maybe at every iteration of, let's say this this for loop, I console dot log with visited associate visited changes every time.

And I'll run this manually by just hitting run.

And let's see what we get here.

So a few things to note, it looks like some of our keys, or some of our items of the set are strings or the zeros a string.

And other times they're actually numbers, notice that they're missing quotes, that has to do with, you know, kind of just JavaScript objects, technically, keys of a JavaScript object are going to be always converted as strings, although the data within these arrays over here is going to be number.

And sets can actually store both types.

And so if you have like two different types, it's not gonna be able to figure out like that those really represent the same node.

For example, looking at this visited set over here, I have like the number one, as well as the string of one, which is no good.

So let's just convert them all to maybe strings.

So I'll check visited if it has the string version of my current node.

So I'll just do the conversion for me.

And likewise, I want to add the string version of the current node over here.

That way, I have very consistent types.

So let's run that manually, again, should just see all of our strings now.

Awesome.

And I think we can run all the test cases.

So that's a really important thing to watch out for in JavaScript.

And JavaScript is pretty unique in that regard.

It just automatically converts all of your keys into strings.

Awesome.

All right, programmers, it's all I got for this connected components count problem, what you want to do is really practice this problem.

It's actually a very, very common interview question.

And there are many variations of this problem that we're going to do in the future.

Hey, programmers, Alvin here, right? Now I want to go over an approach we can use for this largest component problem.

So in this problem, we're going to take in a graph, just like we've been doing as of late.

And the first thing you should probably do is think of this graph as a picture.

So hopefully, you drew it out.

So you can really understand what this is asking.

Our graph information is already given as an adjacency list.

So it's pretty easy to draw out.

So since I have a graph like this, the first thing I should notice is it could contain multiple components, right.

So here, I kind of see two separate islands, two separate components.

And I want to consider the sizes of each respective component.

So if I look at my first component, spanning the nodes, 015, and eight, I know that they have a size of four, they're the four represents the number of nodes within that component.

So I'm really interested in a number of nodes have a component, not necessarily the number of edges.

If I look at the other component that spans the nodes, two, three, and four, that definitely has a node group of three.

And this problem really cares about the largest component, so I should just return four, because it's the largest component size.

So when it comes to what this question is asking, you do have some familiar patterns if you've been following these problems in order and of course, I always recommend that you do these problems in order.

So how can we go about solving this one? Well, I know I'm gonna need some sort of iterative code that way I can travel and hop to different components or different islands, I can probably do some depth first traversal variation that also finds the size of a connected component.

So let's step through how this algorithm might run.

On the side.

I'm going to list out my nodes to represent how I'm going to do the iterations to be In a traversal at every node as my starting point, so I'm going to start at node zero.

And since node zero is unvisited right, now, I'm going to begin a brand new traversal, starting at node zero.

And I'm going to mark my nodes as visited as I go, because like usual for our undirected graphs, you want to watch out and prevent any cycles that you may get trapped in.

And I know that this depth first traversal, is going to explore this full region as far as possible.

And by the power of recursion, it'll be pretty easy to implement some pattern that can count every node as we traverse through it.

So I'm going to treat each of these nodes as just being a single note, of course.

And eventually, those ones are going to return to my top level call, in which case, I can add them all up, getting me a grand total of four.

If this feels very hand wavy, and you're wondering, like how the heck are we going to code up that pattern, don't worry, it's actually a pattern we've seen before.

And so I'll cover that in detail in the code.

Just know for now, it's actually not a big deal to get the count of nodes, right.

So now that I know that the size of this component is four, what I should do is I guess store it as my current largest island or component I've seen so far, because it's the first component that I've considered.

At this point, I should fall back to my intuitive code.

So I look at the node of one, what I should notice is this node one is already checked off, it's already visited.

So there's no reason to start another traversal from this node, because if it's visited, that means I have already explored the component that node one is a member of, so I can basically skip it, go on to node two in my iteration, since node two is unvisited, I should begin a new traversal.

Over here, I know that this depth first traversal is going to explore that component as far as possible, it's going to go ahead and count all of those nodes as one.

And eventually some of those counts together, giving me a count of three.

And so this next component has a size of three, I need to compare that three against my current largest four, obviously, the four is bigger, so the four gets to stay as the largest.

When I fall back to my iterative code, I get to my note of three threes already visited, so no reason to start anew.

traversal, four is already visited, so nothing to do, five is visited.

And of course, eight is visited as well.

At this point, we're done looking at every single node within our graph, and we must have explored every single component, so we can just return the final value that we have stored in that largest variable.

Awesome.

When it comes to the complexity of this algorithm, it's pretty straightforward.

It's basically exactly all of the algorithms we've seen so far, we see that n is the number of nodes and e is a number of edges, we know that the time complexity is going to be roughly o of the number of edges really just exploring through the entire graph, we can also see that the space complexity is also going to be linear, really just O of n.

Because through all of this, we're probably going to be storing all of our nodes in a set right to track visited.

And depending on how you implement your traversal algorithm, whether you use depth first or breadth first, you're also going to use a linear amount of space through your stack or your queue.

So overall, we're looking at a very efficient, linear solution.

And so with that, I think I'm ready to code this one up.

What I want you to do though, first is possibly give this one a shot on your own first cluster, really just utilizing some code that we've seen in the past.

So give it a go on your own.

If you get stuck, you can find me in the walkthrough video.

I'll see you there.

Hey, programmers, Alvin here, right now let's go over a JavaScript solution for this largest component problem.

So this problem is going to be really just a spin off of our last problem.

So we'll hop right into it.

And as always, make sure you watch the approach video first.

And we'll start by building our code that will help us start a traversal on disconnected islands here, right? This is connected components, we should say.

And so I'll start my iterating through every node of the graph, that means I just iterate through the keys of my input object here.

Because remember, we're given this graph as already an adjacency list.

So I can say for let node in the graph.

So I'll give me the nodes like 015, and so on.

And what I'll do is I'm going to start a traversal here, right? So we're going to pretend I had a function, I'll call it explore size.

And if I give it the graph information, as well as the node that I want to traverse through, hopefully, it actually does a traversal through that entire connected component, right.

And what I'm going to assume is, let me assume that this function actually returns the size of that entire component.

So that would be a number right, representing the number of nodes in that component.

And so if I have that should receive it here, call it size.

And I know I need some like max value logic for this entire for loop.

So I'm going to create longest, initialize it to zero.

And then from there, I can check.

All right, if the size of the component I just found, if it's bigger than the longest, then I can replace the longest simply longest equals size, that after the for loop, I would just read Turn the longest course I need to write this explore size function.

So I'll implement this as a type of depth first.

So I'm going to make it recursive, as for size, taking the graph, as well as our current node.

And a few things I should watch out for here, they tell us that we have an undirected graph.

And so we need to make sure that we avoid any cycles.

So we're also set up here is some classic structure, I'm going to use a visited set, we're going to use a set because it gives me O of one lookup and o of one insertion.

So now that I have my visited set, I can pass it along, as I start the traversals.

And now let's work on a base case, as well do to get going is check if I visited this node already.

So if the visited set already has this current node that I need to return, basically avoid a recursive call.

But I also want a consistent type here, right, so I'm assuming that this function gives back a number representing the size at some point in my traversal.

If I get to a node that has already been visited, that means I counted it already.

And so I'll treat it as zero right now, because I don't want to double count my nodes, right otherwise would be inaccurate here.

And now beyond that, what I can do is maybe create a variable here, I'll call it size, I'm going to set that equal to one to represent the current node I'm on right now, right? If this condition is not true, then it's the first time I'm seeing this node, so I need to count it.

And we'll also be sure to do is add it to visited that way I don't get into a cycle into the node later on.

Nice.

And at this point, I need to make my recursive call on the neighbors of this node.

So like we usually do could say for let neighbor of graph of node.

So remember your shape of data here.

So if node was a key, like five, when I say, Neighbor of graph node, that would iterate through the neighbors a five, zero, and then eight, and so on.

And so here, I make my recursive calls, I'm gonna call the same function explore sighs, pass along the same graph.

But now you're situated at your neighbor, and you can provide the same visited set.

And here's where I do my recursive leap of faith, right, I'm going to assume that this explore size function is working.

So if it was working, what would it give back, it would give me back a number representing the size of that graph, right beginning at my neighbor.

So whatever number I get back here, I just want to increment my size by that, right.

And that would accumulate a basically a count of all of the nodes in this fully connected component.

And after I'm done exploring my neighbors, I would have explored the entire component fully.

So I can just return my final answer, which would just be the size over here, really important thing you need to do is make sure if you follow this kind of strategy, you start your size equal to one, and you add to it over time, because this one represents the current node that I'm at, I know that every call is going to count its own node.

So over time, this will actually accumulate everything I need.

So feels pretty good, have our nice visited logic.

And we already wrote our main function here.

Notice how we're splitting up this code in a nice little helper function here, I think it's the best way to express this, it's very similar to some previous problems that we've done.

Right, I think at this point, let's go ahead and give this a shot.

See, what we get, should be able to put it through a few different test cases.

Nice.

And there, we have the largest component to problem.

So a few things, I want to draw your eye to remember that for your graph problems, or you have disconnected components, you're going to need not only your traversal code, but some just iterative mechanism, usually just a loop to make sure you can hop to different components, right? Because if you only had your regular like traversal function, by definition, there is no edge between separate components.

So you would never be able to explore the full graph.

Otherwise, alright, programmers practices, and I'll catch you in the next one.

Hey, programmers, Alvin here, right.

Now let's go over an approach we can use for the shortest path problem.

So here we have another graph problem, and your graph is going to be given as an edge list.

So the first thing we should probably do is, of course, visualize this graph.

And in the context of your code, it probably would be best if you convert it into an adjacency list.

Since we've seen that pattern a few times in some recent problems.

I'll leave that part to you.

But we're going to end up with a graph that looks like this.

And in this problem, we're also going to be given a two nodes here, let's say W and z, what I want to do is return the smallest path between these two nodes.

And here I have two obvious paths, right? One way I can get from W to z would be to go through x and y.

And there I can see that that path length would be three.

Do note here that we're going to consider the path link as the number of edges within the path.

So not the number of nodes, right? So that means how do I calculate three here? What's really just three lines, right, three edges.

That's one way to get from WC another obvious way to get from W to z would be to go through VI, which case, I would only need to use two edges.

So that path line is of course two.

And this problem, what I want to do is return the smallest possible path length.

So I should return the final answer of two here.

So we know that this problem is going to require us to do a graph pathfinding algorithm.

The question is, which one should we take, we either can choose, of course, a depth first traversal, or a breadth first traversal, I'll cut to the chase here.

And both of them would actually give you a strategy that works, meaning you can solve this with either a depth first or a breadth first strategy.

But maybe one of these algorithms would be better than the other.

So let's consider the possibilities.

So let's say I had some large graph, well think abstractly right now.

So kind of just looking at an abstract example.

And let's say I was stepping through some depth first traversal.

Let me say I have my starting node in yellow, and I'll have my target node in blue.

So what I want to do is, again, figure out what's the minimum path distance between these two nodes, obviously, you know, just in the long run, you should get an answer like two here, right, because two is definitely the shortest path between these two nodes.

If we did a depth first traversal, I know that depth first would force me to look in one direction as far as possible, until I have to switch directions, right.

So for my starting on yellow, let's say we move to the right, that'd be one edge and move to the right again, two edges move to the right, again, three edges.

At this point, I can't move right anymore.

So let's say you move downward, so at 456 have to switch directions, again, seven, eight.

And at this point, we kind of already see that this is going to end up possibly getting to the blue target node.

But that wouldn't be the shortest path.

Something unfortunate here is although my star and nodes are really close together, a depth first traversal could be unlucky in that it may search in a totally wrong direction, and snake all the way through the graph until it eventually finds my target node, at which point I definitely don't have the shortest path.

So I think a breadth first traversal is going to be more useful here.

So let's say start at my green node, still my same starting point.

And if I did a breadth first traversal, I know that breadth first means I'm going to explore all the directions very evenly.

So it would look like this.

So I would explore all nodes one edge away from my starting point.

And then from there, I would begin to explore all nodes two edges away from my starting point.

And at some point, I'm going to hit my target node.

And if it's the first time I'm seeing my target node, then by definition, I must have just found the shortest path, right, the shortest path would just be two.

So that's my high level argument for why a breadth first search is going to be more useful, in my opinion, for this problem, let's step through this process a little more algorithmically.

So let's say I had my original graph.

And if I'm gonna do a breadth first traversal, I know that I have to use a queue right no matter what a queue is what gives you that breadth first order.

And what I'll do is eyes the items of my queue, I'm going to store not only the nodes, but also the distance from my starting point, that means I'm going to initialize my starting note on the queue along with the distance of zero.

And that represents the fact that all right, that note of W is zero edges away from the starting point, because it itself is the starting point.

So at any point in time, the items of my queue are always going to be pairs, right of node comma distance.

So now we're going to begin our general algorithm, I'm going to keep iterating.

While my queue is not empty, a single iteration of breathless would remove the front end of my queue, and I'll label it as my current node.

At this point, I should check Alright, is my current node of W, the thing I'm looking for? It's not, so I need to explore W's neighbors.

So I can look at the x node.

And I know I need to add it into my queue.

But when I add it into my queue, I want to make sure I tag it with a distance.

So if my current node has this zero, I know that a neighbor of this node would have distance one, so I just increment the current distance by one.

So onto my queue, I put an item that says x comma one.

And I have a similar scenario for this V node.

It's also a neighbor of W.

And so I put v comma one on my queue as well.

At this point, I can go to my next iteration, or move the front of my queue.

So I look at the x.

And then I look at X's neighbors do bear in mind that because I have an undirected graph here, x really has two neighbors, right, it has w as a neighbor, as well as y.

So something you should already know is I need to track visited.

In other words, when x is going to consider its neighbors, it should really only care about the Y, right, I don't want X to put w back on the queue, because then I would get an infinite cycle.

So I'm just gonna look at the Y over here.

I'm going to add it to my queue.

Because I know my current note of X has a distance of one y must have a distance of two always just incrementing the distance by one.

Cool.

And then I carry on with this algorithm.

I removed the front of my queue now, which would be the V note.

And at this point, I can consider V's neighbors, and I do See that one of its neighbors is actually the Xena, that's the only unvisited neighbor, I'm going to be sure to add z into my queue and tag it with a distance of two, right, because if my v has distance one, its neighbor would have a distance of one grader.

At this point, you can already see how this algorithm is going to work out.

Eventually, this z nodes going to leave the queue, and that would actually be my target node.

So since I've added a node into the queue that matches my target, I know I have my final answer.

The two here does represent the number of edges we took in that logical path.

And I would, of course, just return that too.

So for the most part, this algorithm just sounds like a classic breadth first traversal.

Using a queue on a graph, the only interesting bit is now we're also going to track the current distance.

You know, when it comes to counting the length of a path, you need some counting mechanism.

And so if you begin your queue with your starting node with a distance of zero, every time something leaves a cube, and adds its neighbors, it should increment that distance by one.

And like you already guessed, this algorithm is pretty efficient, because we don't have to traverse through the graph more than one.

So we'll see that this has a linear complexity.

Alright, I think I have everything I need to code up this one, I'm sure you're wondering about these implementation details.

So what you want to do is possibly give this implementation a shot on your own.

And if you need some help, you can find me in those walkthrough videos.

See you there.

Hey, programmers, Alan here, right.

Now let's go over a JavaScript solution for the shortest path problem.

So we'll jump right in, hopefully, you watch the approach video.

And so we'll start by converting our edge list input into something more useful for our traversal like an adjacency list, we're going to write a very classic function.

When I call it build graph, like you expect it takes in the edges.

And I want it to return an adjacency list.

For me, that means a JavaScript object, I'll call it graph, by the end of this function, this will help I'm going to return the graph and some common code, I'm going to iterate through every pair, right, basically every edge, I'll say, for left edge of edges.

As I'm iterating, through every edge, when I want to do is unpack that edge into its component nodes, I'll call it a and b.

And now I can start formatting my adjacency list.

So I know I want the keys of this graph to be obviously the nodes, I want the values to be an array of the neighbors of that node.

So what I'll do is, it's the first time encountering a node, I'll check.

Alright, if this a node if it's not in the graph yet as a key, then I should create it for the first time.

So use it as a key and initialize its value to an empty array, basically, at the start is going to have no neighbors.

Likewise for B.

And then, at this point, I know that A and B now definitely exist as keys within the graph.

And so I just want to add those neighbors.

So if I have an edge, like w comma x, I know x is a neighbor of w, and w is a neighbor of x.

So simply put in say, graph a dot push B, and then just the inverse of that should be good to go.

Cool.

So that should give us our graph.

Let's go ahead and use that in our main function now.

So we'll just say graph equals build graph on the edges.

And what we want to do now is actually work in our breadth first logic, like we said from the approach video.

So a few things I'm going to do, I'm going to definitely set up my queue, we said that the key to victory here was to not only store the node in your queue, but for every like frame inside of your queue also store its distance from node A.

So I'll just use like a pair of things.

So the elements of my queue are going to be always a pair.

And I'll throw on the initial node A, and also the number zero, because at the start, right, this node A is zero edges away from itself.

So that's good to go.

And over time, I'm going to be incrementing.

This number, it seems nice.

And so let's keep on keepin on here.

All right, a while loop, classic condition would be all right, while your queue is not empty, then I shall remove something from the queue.

So always remove from the front if you want to follow a true breadth first order.

So I can do do dot shift.

And that will give me back an array or give me back one of these sub arrays here.

I know it's always going to be a pair so I can just unpack.

And I'll just say alright, grab the current node as well as the distance.

Nice.

I'm going to check the node here that I just removed from the queue.

If that node is node B, that I must have just found a path and I know the distance in that path, I can just return it.

But if this condition is not true, then I need to keep searching through my graph.

Since that means I need to add this nodes neighbors to the back of the queue.

So I'm going to iterate remember that we have adjacency lists the entire time.

So I'm going to say, for, let's say, Neighbor of graph of node.

So get all the neighbors of this node.

And what I'll do is just add those neighbors into my queue.

So q dot push, neighbor, try to remember what the form of our graph is over here.

Maybe as a quick little spot check, make sure on the same page, let me just console dot log, the adjacency lists, let's say we took this example manually, just paste it down below.

And I'll just give it nice little manual runs, I'm not running the test cases quite yet.

So we converted this edge list into this adjacency list, right.

And when we say no to something like W, when we say graph, square bracket, no, that would give us this array, co authored sorters, iterating, through all the neighbors of this node and adding them to the queue, one thing we should watch out for is when we push things back onto the queue, we want to maintain the same format.

So I actually still want to maintain pairs.

So I'll make the first element of the pair, the neighboring node on the second element needs to be the distance.

And since it's a neighbor, its distance would be plus one over here.

So that's how I'm growing and counting the distance.

So let's give this a test run.

There are a few things we need to work on still, though.

But we'll pass a few of these examples, at least until we timeout on a particular example.

One thing this code is missing is any cycle prevention, right? I know that it's going to be a very common scenario, because I have an undirected graph, right.

And so what I'll be sure to do is maintain a visited set, sort of pattern that you're used to, we're just gonna implemented for our iterative, breathless right now.

So start out with a set.

And when you do this iteratively, the move would be to make sure that if something is added to the queue, it should also be marked as visited.

So if I initialize my queue with node A, then I also want to initialize my visited set with node A, just like so.

So if you're unfamiliar with the set constructor in JavaScript, if you want to initialize it with some values, you actually have to pass in an array containing those values.

So the values of my visited set are just going to be the nodes write the node IDs.

Cool.

And then I want to work that logic into my while loop.

And so whenever I'm about to add something into the queue, that is, I'm going to add a neighbor into the queue, first check if that neighbor is not visited yet, so only if not visited has neighbor.

Right, so only if this neighbor has not yet been visited, then I should add it to my queue.

And if I'm about to add it to the queue, like we just said anything that interest, the queue should immediately be marked as visited.

So here I'll say visited, add, the neighbor net should avoid adding any particular node more than once into the queue, avoiding any cycles.

Awesome.

So that feels pretty good.

Let's give that a test run.

Now.

We hope to not timeout at least, all that same example, we're actually returning undefined where we expect negative one.

So if you look at the actual prompt, they tell us that, alright, if you can't find a path between A and B, then you should return negative one.

Let's look at an example or test 04.

And you kind of drew it out, you would see that there would be no such path that connects B to G.

The reason we're returning undefined right now is we're gonna finish our traversal mean, meaning our queue is going to empty out.

And then we're just going to hit the end of this function.

And if I don't hit a return line by default in JavaScript, I'm going to get undefined.

So we know if we finish the while loop, and we never found node B, then we can just return negative one, that must mean that there is no such path that connects a to b.

So let's give this a test run.

Now.

This should be our final version of our shortest path algorithm.

Awesome.

So be sure to practice this algorithm before you move on.

And do make sure that you understand the choice of breadth first here over depth first, for most of your basic just graph problems that require you to calculate a shortest path path meaning just the number of edges.

Typically, you'll find breadth first easiest way to calculate that hey programmers, Alvin here, right now let's go over to the approach for this island count problem.

So in this problem, we're going to be given a 2d array representing a grid of land and waters here we have l characters representing land, and W characters representing water.

Let's try to visualize this.

In this problem we want to do is return a number representing the number of islands on the grid.

We're going to consider an island as a vertical or horizontal connected region of land.

So in this particular example, we should return four.

Because there are four different islands, we can label them as such, this is going to be any type of problems for us.

And we should really think about it as if we have a graph, I'm going to refer to these style problems as a grid graph.

And so although we're not given any explicit like nodes and edges, I can still think about positions of this graph as nodes.

So for example, let's consider the indices here.

So I have my row indices along the left hand side, and my column indices along the top.

And I can designate any position of this grid using a pair of row and column.

So for example, if I looked at position three comma four, that would be this position over here.

And what I should do is mentally think about a position as if it's a node.

And if I met some node, I do have some potential neighbors.

given any position of the spread, I have at most four neighbors in the up down left and right directions.

given any position of the grid, it's really easy to determine what our potential neighbors are, it's really just a matter of adding or subtracting one from either the row or the column.

Let's generalize this formula.

So let's say I was at some position, we'll call it our see, if I want it to go upward, that would mean you decrement, the row by one, keep the column the same.

If you went down, that would mean increasing the row by one, if you went to the right, that would be increasing the column by one.

And if you want to go left, then you should just decrease the column by one, do bear in mind that the top left position of our grid is going to be 00.

And that's why we have this type of arithmetic rule.

So now that we're starting to frame this grid problem, as if it's a graph, we can use some common patterns, I know that this problem is really asked me to count the number of connected components or the number of islands on this grid.

So I'm going to need some iterative code, probably some nested loops to just iterate through every potential Island and start some traversal at that island.

So when it comes to our iterative code, we just want nested loops to iterate through every row column.

That means the iterations should look something like this, just moving left to right.

until we finish around which case we can go to the next row.

Let's actually iron out the main logic that we need in our algorithm.

So let's say we start or nested loops from the very beginning, what I do is check my current position, what I want to do is check if my current position is land right now it's water, so I can just continue.

On the next iteration, I do have some land position.

And since I'm on a piece of land, right now, what I want to do is explore this land region as far as possible, probably using some depth first traversal.

And do bear in mind, like most of our undirected graph problems, we're going to need to be sure to mark things as visited, so we don't get trapped in any infinite cycles.

So for example, if I started a traversal, at this position, I can go downward.

But I can also go upward from here.

And I can bounce back between the two going up and down, giving me an infinite cycle.

So we know how to fix this using all of our graph mechanics, right, just use a visited set.

So if I do a depth first traversal, starting at this position, I know I'm going to mark off all of these land pieces as visited.

And what I also want to do is make sure that I increments accounts, representing the fact that I've just explored some new island fully.

So right now, my count zero, since I just finished exploring something now my count is one.

And at this point, I can fall back to my iterative code to scan for another island.

So I move to the right, it's water.

So continue, water continue.

Now I have another island.

And again, I just do some depth first traversal through it.

And of course I increment my count.

This pattern will follow right? Eventually, when I hit the new row, I could be at a land position.

But I should also make sure that this land position is unexplored, right.

So since I'm at position one, comma zero, and this land has already been explored, I don't need to begin a depth first traversal.

And I also don't need to begin a traversal here.

And this continues, avoiding starting a traversal.

Wherever I have a visited piece of land, we know eventually, we're going to hit a new island like this one, where I have a piece of land that is unvisited.

So at that point, that's my criteria for starting a new depth first traversal, I explore this region, increment my count, and continue business as usual until I hit this final island that is unvisited.

And so I visit it and increment my count.

And by the end of my iterations, I should have my final count of four.

So that logic is actually pretty straightforward, just a variation of our classic connected component, counting logic, except now we're adjusting the criteria we use for looking at neighbors, right, our neighbors are actually going to just be either above downward to the left or to the right of our current position.

We talked about the complexity of this algorithm, we should consider the size of the input and the fact that it has two dimensions, right? So if I say that R is a number of rows, and C is a number of columns, well and the iterative codes pretty straightforward, I know that's going to give me r times C iterations.

And if I also consider any potential in depth first traversal I do starting at some land.

In the worst case, I could have one Giant Island, which is also going to be our time to see.

So the overall complexity, it's just going to be our time See, the space complexity for very similar reason is our time see, because imagine that we mark all of these positions as visited, that probably means we'd have to add them to some set.

Right, so we have our time see different positions.

And by the end, I could add each and every one of them into my set, the space complexity of our time.

See also includes any traversal related data structures like stacks, or queues, depending on how you implement this one.

So overall, this is going to be a very efficient solution to solve this one, what you should do is probably give it a shot on your own first, if you get stuck, you can find me in the walkthrough videos.

I'll see you there.

Hey, programmers, Alvin here, right now, let's go over a JavaScript walkthrough for this island count problem.

So as always, make sure you watch the approach video first.

And we'll jump right in.

So we know that this is really just a spin off of our kind of graph connected components problems, except now we have a grid graph, right? I can still think about like this grid as if it's a graph, because if I think about any particular position of this grid, I know I have some neighboring positions that I can travel through mainly, my four neighbors Up, down, left and right for me, let me start my laying down some iterative code that can begin a traversal at every node or every position of this grid.

That way, I can start considering different islands, right.

So I'm going to use just a for loop for this, I'm going to iterate through every possible row column combinations every position.

So I'll say R equals zero, iterate up to the length of the grid, so grid dot length to our plus equals one, and do something very similar for my columns nested inside, right? Watch out for some details here though, looking at the examples, we can't actually assume that we're always get a square shaped grid square meaning like as if the number of rows was the same as the number of columns, because sometimes I'll have like an asymmetric grid occasionally, right? If I look at this very first one, it looks like the width is going to be five here, but the height is six.

So separately for the columns, I want to reference the column lines over here.

So we're gonna say grid, zero length.

Nice.

And so at this point, I have some row composition, I want to begin a traversal, let's say a depth first traversal at that position.

So here's where I invoke some like helper function, that will make it a little bit, I'll call it explore.

And what's going to do is, of course, taking the grid information, as well as the row column I want to traverse through nice.

And at this point, I think we'll actually hop to building this this helper function, then we probably need to fill out some more logic within our main driver function here.

So let's bake this explore helper function.

So taking the grid and your row column, and something I should also consider is because I know that this is really a type of graph problem, right? I want to prevent infinite cycles, right? So consider this, let's say I was somewhere in the middle of my traversal, let's say I was at this piece of land, I know that this piece of land is going to travel through its right neighbor.

And it could be the case that this piece of land now travels its left neighbor, so I go left and then right and then left and right.

Now it gives me an infinite loop, right.

So whenever you have this notion of like undirected graph or undirected connections, then always guard with a visited set.

We've seen this pattern before.

So maybe up top globally, for the entire traversal, I'll create a visited set.

So in JavaScript, just a new set, you're probably wondering, you know, what am I going to make the members of this set? Well, I need to designate positions, right? Think about it as if positions are like the nodes in this grid in this graph, right.

And so what I'll do is pass along this visit set, so I can accept it as an org over here.

And when it comes to using your visited set, what you want to do is make sure you combine your row and column because together they designate your actual position.

I think this is actually worth going through specifically more of like a language thing in JavaScript, compared to other programming languages.

So quick aside over here, let me get myself some more room might be a while.

Because if you're unfamiliar with sets, and you don't kind of know, their nuances, might actually hit you in the butt later on.

So let's say I had a set so I'll create an offset.

So can you set and let's say I added I don't know, like an array containing a row column position.

So I'm gonna say is, alright, maybe I had position, I don't know, one comma three.

And I added that into my set.

So I do s dot add that position.

This is actually a common gotcha in JavaScript.

If you put any like reference types, like an array or like an object into your set, it's actually going to check for reference equality when you check for existence later on.

In other words, now I can't really do console dot log s dot has one three, because this array literal is technically a different array in memory.

So I wish I could get like true back in this scenario, but I'm not going to get a true.

So we'll just run that manually see what we get.

So like, we say, we're gonna get a false here, which is not so good.

So instead, your Fix would be to actually convert this into some string data.

So instead, maybe write as if you had one comma three, because strings are primitive types, and I would actually be able to store that string.

So whenever I say the string literal, this would actually give me a match now, so I should get a nice true here.

Awesome.

So we'll want to use that pattern to our advantage.

And so maybe I'll start by creating some position variable, that's going to be like the string of FIDE a version of our position.

So just take my row, maybe add a comma, and also put the column here.

Nice.

And the reason I want to comma separate is, I need to have different bounds for my row and column.

In other words, imagine I had a row of let's say, 12.

And I had a column of four.

If I turn that into a key, or a position, that would give me position as looks like 12, comma for another scenario, let's say I had row one, and then column 24, that would give me a position of this right? one comma 24.

Right, it's really important that you put a comma to separate your row and column positions, because imagine, I didn't put the comma, then it would have a collision here, I have two totally distinct positions, right? 12, four, and 124.

And if I don't put a comma, they look like they have the same position key.

So that's why I need to comma separate them.

Common gotcha there.

But now that I have this position, I can use it to my advantage in this visited set.

So if I've already visited this position, so if my visited has this position, then I should exit, right, I need to return something.

And I want this explorer function do something similar, like we've done in our old component problems, I want it to return a Boolean indicating whether or not this is a new island that I'm exploring.

So if it's visited already, that's definitely not new, right.

So just return false, meaning it's not a new island.

If I make it past this if statement, in other words, if position is not in visited, that I need to mark it as visited right now, second, do visited, add this position.

So now I have my core like cycle prevention logic.

Beyond that, I have a few other scenarios, we know that in our traversal, we're going to look at our different like neighbors.

And so what I want to do is make sure that I'm in bounds here.

So I'm going to check, like to split this up into variables, I'll say, one, a boolean variable called row in bounds.

And I'll do is just check if zero is less than or equal to the row.

And that row is strictly less than will say, the length of my grid.

So I'm just checking to see if my opposition is in bounds here, I do a quick check, I need to be inclusive with zero because zero is a totally valid index, right? I need to be exclusive with the length because imagine I had a grid with length five, it's last valid index is four.

So I need to be strictly less than here.

And I'll write a similar variable for my column in bounds, just like this.

And at this point, I can write a nice semantic if statement check, all right, if your row is not in bounds, or your column is not in bounds, then exit, right? So return like before I can return false, right? Because I should not consider like an invalid position and a balanced position as an island, right? So that's looking good.

Final base case I need though is, what if my current position is water, right? I only want to do my traversal through land.

And so I'll add another statement for that.

So up here, I can check.

All right, if my grid at row column, if it's equal to water, then also return false.

No reason to count it, it's really important that you put this in bounds check before you index into your grid, right? Because imagine that your row and column were out of bounds.

If you write line 15 like this, immediately, you're going to get an out of bounds error.

So start with your guard to check if you're in bounds if you want it to because most of these conditionals they all return false have the same consequence.

You can probably or them together.

Typically I like to keep them separate.

That way I always remember to write them typically for like your grid graph problems.

This is very canonical code.

Alright, so if I make it past all of these base cases, and I have the recursive case, so I must be at an unvisited piece of land.

And when I want to do is do my depth first traversal, right.

So here's where I explore my neighbors and I have four neighbors.

If I wanted to go above that I decrement, my row by one, keep the column the same, pass along the same visited, because remember, we have like the array indices here.

So this is row zero, this is row one.

So we'll lower row numbers mean upward, in the same way, lower column numbers mean to the left.

So this is up, this is down by do just minus one over here, that would be to the left, then plus one on the column would be to the right.

Cool, and I can keep this code very flat as it is something that I'm a huge proponent of when you write recursion, for the most part, I always try to make sure that I don't look before I leap.

In other words, just from this logic alone, it couldn't be the case that row minus one is out of bounds.

But that's okay.

Because if it's out of bounds, when I evaluate this call, it's going to immediately be caught by this base case, right.

And if I express my logic like this, if I don't look, before I leave, if I just leap and then catch myself with the base case, you don't have to write repetitive code.

In other words, some people write code like this, where it's like, Alright, if row minus one inbounds kind of using pseudocode.

Here, they would have to write row plus one inbounds.

And you would have to write a guarding if statement around every recursive call, instead, just write one base case.

And you can catch all of these different out of bounds, right.

So that's why I prefer it this way.

And so I know that by the time I return out of these recursive calls, I'm back at this segment of my code.

And what I can do is return true because I must be finished with that traversal.

And the reason I'm returning true is true symbolizes that I've just finished exploring a brand new island, so I need to count it.

Nice.

It's also consistent with the data type, I have Boolean for this explore function.

So for the most part, this looks like really just a spin off of our previous like graph, depth first code.

And now I want to use that boolean data in my main function here.

So here's where I can actually count my islands.

So guess I really need some logic here that says initialize some counts equal to zero.

And whenever you find a new island, increment that count.

So if I just have found a new island, we're going to get back true from this this call, right? Because remember that I'm beginning a traversal, starting at this row column position.

So if it gives me back true, then I can totally increment my count by one.

Notice that whenever I begin a traversal on a position I've seen before, it would have been added to visited before.

So I would return via this if statement on line 21, I return false.

If I return false, then I don't double count that island.

So I do need a combination of both iterative code to potentially leap to different islands.

But I can use a visited set to prevent myself from double counting any particular Island.

So this is looking pretty good.

Let's not forget to of course, return our counts at the end.

Let's give this a run.

This will probably be the first in a series of these like grid graph problems.

Really try to understand how we can think about still a grid as if it's a graph, right? We just have different rules for how we look at our neighbors.

Right? Now, a node is really a position and its neighbors are its four neighbors Up, down, left and right.

Alright programmers, I want you to practice this pattern because we're going to see it in the next few problems.

I'll leave it to you see in the next one.

Hey, programmers outlane here, right now let's go over an approach for this minimum Island problem.

So we're going to be given here a grid containing a water inland really just some characters inside of our grid.

So of course, as always, let's visualize this.

And what I want to do in this problem is return a number representing the minimum Island size, we're going to consider an island, a connected region of vertical or horizontally connected pieces of land.

So for this particular input, our answer should be to looking at our grid, I have three separate islands.

And they all have different sizes, right? sizes, a four, two and five, I just choose the smallest of the islands.

So that would be the two over here.

So how can I actually come up with a strategy for this one, you should already know that this is just a spin off of our previous a grid graph problem, where instead of doing just a count of the number of islands, now I want to find the sizes of islands.

I know to actually look at different islands, I'm gonna need some nested code, but I'm also gonna need some depth first traversal code to explore a single Island.

So overall, this should be a pretty classic strategy for us.

So let's say we start attacking this we know we're going to begin our nested loops in the top left corner And if our current position is water, then we actually don't need to do anything.

next iteration, I have some land.

At this point, I could begin on my depth first traversal.

And I know that I should be marking things as visited to avoid any infinite loops, right.

So by the time this traversal completes, I'm going to mark all of these guys as visited.

But I also wanted to determine the size of this entire island region.

So every time I get a position that is land, I should treat it as one.

And then when it comes to how I implement on my traversal, I can just gather up these ones, right, just add them all up.

So that would look something like this.

And for my top level call for that traversal, I should get an island size of four.

And so if that kind of traversal algorithm, especially how we compute the size of the island, is pretty hand wavy, don't worry that when we actually go through the code walkthrough, it's just a matter of some recursion, and some recursion we've actually seen before in past problems of the course.

But any case, now that I have this island size of four, it's actually the first island that I've seen.

And so I'm going to consider it the mid size so far.

But I need to keep looking in case something is smaller.

So move to the right.

So if it's water, I do nothing, water again, do nothing.

Now I have another islands, I begin my traversal market these as visited.

And when I find the size of this island, of course, it's going to give me two, I compare that to to my current mid size two is smaller, so I store two as the mid size so far.

And we just continue business as usual.

Note that when we get to a piece of land, we really want to make sure that it's land, but also a piece of unvisited land.

So right now on that piece of land, but it's visited, so I should not wear I don't need to start traversal here.

Likewise, for this position.

Eventually, I'm going to hit some new unvisited land, in which case I should begin my traversal at Explorer, this region, and I want to count up all of these pieces of land.

And I should realize that the final size of this island would be five, I can compare that five against my current min, five is bigger, so the size of two gets to stay.

And I can just end up returning the minimum size by the end of this algorithm, basically representing this island of size two, the complexity of this algorithm is straightforward, we should say that the size of our input is r times C, because we have our rows and C columns, in which case a time complexity is simply our time C, right, we have to iterate through every row column within the grid.

And even when we begin a traversal, in the worst case, we could have an island that spans the entire grid, in which case it would also be our C.

Right.

So overall, our full complexities are time c space complexities are time C as well.

And do know that this is technically a linear solution in the size of the grid, right because the grid itself is exactly r times C positions.

So with that, I think we're ready to code this one up and try it on your own first.

And if you get stuck, I'll catch you in the walkthrough videos.

See you there.

Hey, programmers, Alvin here, right now let's go over a JavaScript walkthrough for this minimum Island problem.

So we'll jump right in, make sure you watch the approach video.

As always, this is just a nice spin off of our classic island hopping logic.

But for a grid graph, right.

And so let's start with the iterative code that can help us begin a traversal.

Starting at every different position of our grids, that just means some nested loops.

So start by iterating through all of the rows and columns.

So r equals zero, go up to while r is less than length of the grid, also do our plus equals one and very similar loop for my column.

But do make sure that you reference your inner column line because you could have like a rectangular shaped grid over here.

And what I want to do now is begin a traversal starting at every row column.

So I'm going to assume I have a helper function here that does that traversal, I'm going to call it explore size.

That's because in the long run, I'm interested in the size of that island, right, so like a number representing how big or how many positions that island spans.

So I'm going to pass along the grid information as well as the position.

And I know when it comes to all of these like undirected graph, traversals should probably guard against your loops.

And I have some foresight here.

So I'm going to pass along a nice visited set, which I can maintain globally for the entire traversal because there's only a good reason to explore a position once right.

So I'll create const visited gonna make it my neighs JavaScript set.

And a few reasons for that.

Well, for one JavaScript set, gives me O of one lookup, but also o of one insertion.

So it's going to be a really quick data structure to use.

And from there, we probably have to add some more logic over here to actually do something with the size but for now, I think I'm going to switch gears and actually take a look at building this helper function, right.

So I think the best way to build this traversal is to use is a deaf purse, typically just my go to for problem like this, it's going to take in I know the grid, the row in the column and also visited, I need some a base case is very classic base cases, I'm going to start by checking if this row column position is inbounds.

So my favorite pattern for that is to split up in some variables just makes it easier to read and debug.

So I'm going to say is my row inbounds and just make that like a boolean variable.

So I'll check if, let's say, zero is less than or equal to the row, I need to say and right, and that row should be strictly less than the grid length.

So this Boolean would only be true if it's in bounds, right? And something very similar for my column bounds should be between zero and grid zero length.

Nice just like this, I believe.

And then I can write a nice if statement using both clauses.

So I can say, all right, if let's say your row is not in balance, or your column is not in balance, then you're definitely at a bound.

So you should probably use some base case here, right? So we're all choose to return here is zero, because I want to keep a consistent number, right consistent return type.

That is, I know that this function has a kind of goal of returning the size of the explored islands sizes a number.

So even in my base case, I need to make sure I return some type of number, returning zero to represent that, hey, if this is out of bounds, it's not going to contribute anything into the count of the size, right, which is good to go.

I need some other base case here.

What if my position is inbounds.

But what if it's actually water, I don't want to count that as well.

I only want to count islands.

So land right.

So quick fix, what I'll do is add a new base case, I can check if my grid at row column, if it's equal to the water character.

So a capital W can also return zero.

If you want it to, you can also maybe merge these into like a single if statement, just write a bunch of ORS, I kind of like them separate because it's just easy for me to remember what each of them does write a final conditional have here is alright, if I make it past both of these base cases, it might be the case that this position is land, but it's land I've already visited.

So here's why I work in my visited logic, I'm going to represent a position, like we said in the last episode as really just a string.

So I can put it as the members of my visited set.

So I'm going to say position to have to be the row plus a comma plus the column.

So just representing the position, that's because I can't add like an array into a visited set, and then look it up later.

And so if visited has the position, then it's a duplicate position that I've explored.

So return zero.

Otherwise, it's not been visited yet.

So I must be visiting it right now.

So I can add it.

Nice.

So I have my base cases laid down.

Now I'll need my actual recursive code.

So I'll explore my four neighbors.

By now you should be familiar with this pattern.

So go upwards, a row minus one column pass on the same visited.

So I'm going to explore my up down left right neighbors respectively.

And I do my recursively buffet theory, right.

So what type do I expect back from these calls, they're going to give me back a number representing the size of the island that my neighbor is a part of.

But if my neighbor is part of some larger Island, then I am too because we're connected right to our neighbors.

And so I want to create the grand total of all of these return values.

So I'm going to create some size variable, let's say let size, I'm going to initialize it to one over here, it's going to be one and not zero, because the one represents my current position, my row column.

And whatever these calls return, whatever number I'm just going to increment my size by that number, like so.

Then finally, I can return our total size over here.

So that will do my depth first traversal, because it's recursive, but we'll also tally up the size of this island region.

Cool.

So now that I have a working explore size helper, let's use it in our main function here.

So I'm going to get back a number from this call.

I'll call it my respective size.

And what's great about this logic is if I have a Island or position I've already seen before, and I encounter it again in this this for loop, then I would just return early because I would hit this base case, right? If something has already been visited, just automatically return zero, because I've already considered it, no reason to consider it again.

But now I need my minimization logic, right, I want the size of the smallest Island.

And they tell us in the problem that we can totally assume that your grid contains at least one island.

So I think a great default value here is to use positive infinity so I can set some will say min size variable To be positive infinity, JavaScript, if I make it positive infinity, I know when I encounter any like valid Island size, it's going to be less than infinity.

And it should replace it.

So now I can do some min logic here and check.

All right, if the size of this island is less than the minimum size I have seen so far, then just replace that min size with that island.

Then after I'm done with all of these traversals potential reversals, I'll return my mid size.

So some classic patterns here.

There's one nuance that we're not considering how to run the code, and we can debug it together.

So it looks like we failed example.

00.

So the very first example we expected to answer to, we accidentally gave back zero.

If you look at that first example, it's pretty obvious that Yeah, the minimum size is two representing this island over here.

The reason we're giving back zero is according to our code.

Let's see we're on like the very first iteration, I'm going to respond it, I know that row is going to be zero column is going to be zero, that means my position would be this w over here.

When I make the recursive call, and I pass along position 00, I know that it's going to immediately return zero because that position is water.

And I'm going to check Alright, is that zero, less than infinity it is, so I'm going to replace min size with zero.

But if I think about it, zero doesn't even represent a real Island.

If an island has a size of zero, then it's not an island at all, it was a piece of water, right? And so I want to add some additional logic here to only actually look at nonzero quantities.

So only do the comparison if that size is also valid.

So size should be greater than zero, of course.

And we'll want to add these together.

So let's try that again.

Just a little, little detail over there that we need.

Awesome.

And there we have a solution for this minimum Island problem.

So we've seen this pattern a few times now, right or classic island hopping logic.

So when you think about islands are like connected components of a graph, this should be your first kind of go to algorithm.

Alright programmers.

So that wraps up our course on graphs.

I hope you learned a ton during the course.

I definitely had a blast making it Be sure to head to Shruti dotnet, where you can continue to practice more graph problems, as well as explore any other data structure algorithm topics.

I'll see you there.

We released a full course on the freeCodeCamp.org YouTube channel that will teach you how to solve backtracking problems.

Lynn Zheng teaches this course. She is a software engineer at salesforce and an excellent teacher.

You will learn general principles and also learn to solve two LeetCode hard problems in this crash course.

Watch the full course below or on the freeCodeCamp.org YouTube channel (1-hour watch).

Transcript

(autogenerated)

Lynne is a software engineer at Salesforce and an excellent teacher.

In this course, you will teach you how to solve backtracking problems, which are common in coding interviews and challenges.

Hi, everyone.

I'm Leanne.

I'm a software engineer, hobbyist game developer and a recent graduate from the University of Chicago.

Welcome to this course on solving backtracking problems.

Whether you're new to coda interviews, or already have experience with backtracking problems, this is the crash course for you.

We will learn about an all purpose template that helps you solve any kind of backtracking problems, and we will apply the template to the ko problems, like the eight queens problem, or does Sudoku solver problem.

This is exactly the template that I use for my coding problems when I'm developing algorithms for my games, or even once in my research on a non convex optimization problem.

I hope you're excited and let's dive right into this versatile template.

You can find this template in my GitHub just links to in the video description below.

Let's start with some keywords and concepts in backtracking problems that will help us understand the template better.

The first keyword sticked.

Essentially, a backtracking problem is asking you to find a valid state.

Take the N queens example that we will solve later in this video.

An example of a state is just arbitrarily placing n queens on an n by n board.

For example, here we are placing four queens on a four by four board.

On the contrary, an example of a valid state requires that the queens are placed in a fashion that they cannot attack each other.

If you aren't familiar with the rules of chess, don't worry.

The myths of queens are pretty straightforward.

A Queen can move horizontally, vertically, or diagonally.

Therefore, for replacement of the N queens to be valid, they can't stand on the same row, the same column or the two diagonals.

So how do we construct a valid state like this? Well, we build up from previous states.

Suppose we're starting from a blank and by an board where no queen is present, we can put our first Queen arbitrarily, wherever we want.

Let's say we put it here.

Then where can we place a second query, you can see now our choices are limited.

Or in background terminology, our candidate states are limited.

Because we placed the first Queen here, this entire column, this entire row, and the two diagonals are not available for new queens.

Let's say we just put the second Queen here where it's available.

Next, we try to see where we can fit in the third queen.

Our candidates are now more limited because we put the second Queen here, this column, this row and this diagonal is not available.

So our third Queen can only go here.

Finally it let's place the fourth queen.

Because this third queen is here, it blocks this diagonal and this row and this column, leaving our fourth queen to set here.

Great.

Now is this global layout a valid solution such that no Queen can attack each other? Well, we've already seen in our checks.

So like this, we have found a valid solution to this end Queen problem.

As a counter example, consider if we placed the first two queens like this.

Now, all these cells marked in red are all available, and we only have one left for the third Queen and know where to place the fourth queen.

This means that the success of state searches fails to lead to a valid solution.

And this is pretty much it about states, identifying candidates to build the next state and validating a final solution.

Now let's look at how these procedures are defined in our template.

There are four functions in our template.

The first three, as well as state candidates, search our helper functions.

The last and most important one, so is the entry point to our program.

The sole function is indeed the one that a little problem is asking you to write.

It is responsible for returning the valid solutions.

Let's look at a helper functions one by one.

This valid state this function takes a state and returns a Boolean.

It validates whether a state can be used as a final solution in our queens problem State is a validated solution.

If all n queens are placed on a board, and none of them can attack each other, get candidates.

This function finds a list of candidates that can be used to construct the next state search.

This is a recursive function.

It caused the previous two helper functions and checks if the state is a valid solution to our backtracking problem.

If it is, it records the solution by making a deep copy of this state.

Note that we do need a deep copy self a shallow copy, because we will continue to modify the state as our search goes.

But we need a static snapshot of the valid state here.

This line of return is commented out, because depending on the nature of the problem, we might need to find all valid solutions or just one.

If we only need one, we can return as soon as we have find it.

Otherwise, we continue on until we exhaust all the possible search states.

Continue down here.

If the state isn't yet a valid solution, we find candidates to build the next state.

Recall that candidates return a list of candidates.

For each one, we add the candidate to the state.

In a quiz problem.

For instance, suppose our state only contains the position of the first queen.

Here we add a candidate position for the second point.

Now we'll take this modified state and recurse on it by calling the search method on this modified state.

If the modified state is valid, the solution is recorded.

Like here, otherwise, the search function fetches candidates for this modified state and recurse.

Further, eventually, for some state, there is no more possible candidate.

Think about the example where we cannot place a fourth going anywhere, because all the spaces have been occupied.

After returning from the recursive search, we restored a modified state to the original by removing the candidate from the state.

Again, the Queens example, we undo the placement of the second query.

And now we only have the first query as well.

So it starts with an empty list of solution and an empty state.

It costs search on a state and this list of empty solution.

Search will eventually fill up this list of empty solutions, and then return the list of solutions.

And remember, this is the function that the code problem is asking us to write.

We're using this template keeping might not this is only a template.

So your helper functions, as well as state get candidates, they might taking additional parameters.

Search might also return a Boolean indicating whether a solution has been found and returned early if there is one and only one valid global solution, like in a Sudoku problem that we will eventually see.

This concludes our brief introduction to the template.

Next, let's solve the Queens problem hands on in the code.

Here we are only code number 51 the N queens problem which is Alico heart problem.

Let's first read the problem statement, given an integer, and we want to return all the distinct solution to the n queens puzzle, and we may return to answer in any order.

And lico has a specific format for us to represent the board.

For four crease example, these are the two valid solutions.

And here with the notes, not the first square on the first row is not occupied, the second square is occupied by a queen, the third one is not occupied, the fourth one is not occupied.

And on the second row, the first three squares aren't occupied, and the last one is occupied by Queen, so on and so forth.

And in the case where n is one, the Queen can only be on a single grid.

So that's the solution.

Before jumping to the code, let's first think about how we may represent this problem.

Logically.

We might be tempted to represent this board data structure as a 2d array, but it's actually a little bit waste of space do so.

Since no queens can be on the same row or the same column, we may just keep a one day list that tracks the Queen's position in each row.

Concretely, for this example here on the left, well the first row, the queen is in the second cell, so the first index is one.

For the second row, the index is three, since the queen is in the fourth cell, and this here is zero.

This here is two, following the same logic.

For the example on the right, the first index is two, the second index is zero, the third one is three, and the last one, one, because the third cell, the first cell, the fourth cell, and the second cell.

So this is the way that we represent each state as a 1d list.

For this backtracking problem.

Now I'm going to grab my template and put it into the code.

I'm going to move the surf method on top.

As already mentioned, the surf method is basically the one that the code is asking us to write.

So for the soap and Queens problem, we'll just be adapting the soap function to solutions is initially an empty list, because we may return all the valid solution in any order, then my starting state is just an empty list because we haven't placed any of the Queens into the board just yet.

Now we call self dot search on this date, given it all a list of solutions to append to and the parameter n for the N queens.

After the search is complete, we return to solutions.

Let's go ahead and remove this part.

Great.

Now we will write that as well as state function, it will take as parameter self, state and add for state to be valid, it needs to put all n queens onto the board.

So if the length of the state is n, then we know we have already put all n queens onto the board.

As for the condition where no queens can attack each other, we will handle it in the get candidate function.

Essentially, we will only return candidates that meant all valid scores that won't be attracted by the previously placed queens self state.

Great.

So here we are constructing candidates based on the state that were given.

If there's no state, meaning that we're starting from a blank board, we may place the first query anywhere we want.

So if not state, we return all the possible indices.

If the state is not empty, we find the next position in this state to populate position as the length of the state.

If we already placed the first Queen, we want to place the second query.

So candidates initially start from all the indices and then we prompt down candidates that aren't valid.

I'm using a set because it's better than walking through a list and set guarantees uniqueness.

Alright, prone down candidates that place the Queen into attacks.

So for row column enumerate state with discard the discard of column index if it's occupied so candidates that this part recall that our state is recording the column index for each row.

Now we discuss the diagonals.

So this test is the distance between the position and a row index.

Because we're trying to put a queen in the second row, now that we have already filled in the first row, we want it in the place that cannot be attacked by the first Queen diagonally.

So this one is out of the question.

And this is column plus distance.

This one is also out of the question and column minus distance.

And at the very end, we return candidates.

Now let's define our recursive search function is your take states solution solutions, and we just adapt the template.

So if self.is valid state state, and we just add it to the solutions, and return.

Otherwise, if we come down here, for candidates, a salt candidates state, and we recurse.

Because our state is in list and no longer is set, we do append candidate, and then call self dot search, state solutions, and it and then to restore the modified state back to our original repop the last entry.

Great.

So this here is the only thing that we need to take care of, because lico wants us to output strings.

And here we have is a list of column indices.

So let's define some additional helper functions here.

State to string state, we expect the output to be just like here.

So here's how we convert our list of indices.

To this output stray specified lightly code, total return is just a list for I am state because one means that the queen is in the second cell and the other cells are empty, we just append the strings for the empty cells as well as a string for the Queen's code cat knows together to get the return value.

string is this dot meaning the empty square times i plus the Queen's position was the remaining empty cells.

And rats straight.

were returned direct.

And here is self solution at Penn State copy.

We do state string and string is produced by self dot script to string sticked.

Great.

Let's now run the example code to see how we did.

Alright, cool.

Looks like our output is accepted.

Let's submit and see whether we can pass all the test cases Great, you can see that our runtime is better than almost 70% of the submissions and also some memory usage is better than 7% of the other submissions.

We are definitely using some memory because of the recursion, but that's totally okay for backtracking problems.

Next, we'll solve another lico heart problem called the Sudoku solver problem.

We're now only co problem 37 the Sudoku solver problem, which is a hard problem.

If you don't already know what a Sudoku puzzle is, you can read the description.

So a Sudoku solution must satisfy all the following rules.

Each of the digits one to nine must occur exactly once in each row.

And each column.

Also a nine of the three by three sub boxes of the grid, and liko use the dot character to indicate empty cells.

So for example, here, the code wants us to write a program that fills out this Sudoku puzzle.

In a valid way, the board is represented as a 2d array of strings, some maybe numbers, some empty cells, and lico wants us to solve the problem and modify the board in place.

The constraints are not because it's a Sudoku problem, the shape is nine by nine.

And each cell is either a digit string or the empty string.

And it's guaranteed that the input board has only one solution.

So we may return early.

If we find only one solution.

Let me copy paste my template and jump into the problem.

Alright, so again, we adopt the soak function like this, because it asked us not to return anything and just modify the port in place, I think we'll just need to do socket search board.

And then we get rid of this little function.

I'm going to have to define some constants here.

So the shape is nine by nine.

Grid length is three by three, if we're trying to validate the sub boxes, and empty is represented as this dot here.

And all the digit strings are like false.

So screen number four number in range.

One shape, plus one.

So this gives us the strain from one to nine.

And I'm going to wrap it in a set, because the order is not important.

And I know I'm going to need this when I'm traversing the Great.

Great.

So let's start by writing that is valid state function.

So it should take self and the board and check if the board is a valid solution.

So let's validate all the rows first.

For row a, I'm going to just define some helper function later down.

So let's do first soft get rows, which returns each row of the board one by one.

If, if my row is equivalent to all the digits, that it's a valid row.

Otherwise it's an invalid row and tire board is not valid.

If not set row is equal to soft digit.

return false validate.

Similarly we validate the columns calls return false.

Or Lastly, we'll validate the sub boxes.

For grid, grid, or.

And if all the rows are validated, all the columns are validated and all the grids are validated without causing this false return already, we return true meaning that the board is not a valid solution.

Now let's write to get candidates.

So self board a row and the column I'm using a row and the column because for a cell, I want to know which row and which column it is all to determine what digits have already be used, and what are left for us to use as a next state.

So used digits is a set of digit.

And I'm going to remove used remove digits used by the same row.

So used digits dot update self dot get row, this is another helper function that I will define later down digits used by that same column.

So used update self dot get column four, and the column removed digits used by the same by that by the three by three sub box budgets, update get graded roll column.

So we need to identify for an arbitrary sell which grid is on board roll call.

And lastly, because we might have already used empty string, here, when we are doing the updates, we subtract those from our use digits.

Empty is the constant that were defined for the empty string.

And candidates are just whatever that's left for us to use.

So that all useless and that concludes our get candidates function.

Now, we are moving on to do search.

Because we only have one single solution, we don't need it the list of solutions here.

So, so forth.

We have Isabel at stage.

So if self.is valid state board we return true solution.

Otherwise, we find the next empty spot and take a guess.

So for row index row enumerate or four column index, the actual element enumerate row.

If the element is the empty string, so soft, that empty for if this is empty, find can dates to construct an X ray.

Next fate candidate a self dot get candidates board.

Now that we have the row index and column index, we pass those a, we modify the board in place as the problem instructed us to do.

So.

candidate, remember that candidate is just one of the digit string.

And because here our search returns a Boolean, if one of the search actually finishes, that means that the board has been modified in place, and our problem is solved.

So it's solved is now equal to self dot search.

And just to add some comments here, we recurse on the MADI side.

If so, if so, now we just return to meaning that the entire search has completed.

Otherwise, we all do the wrong guess.

And start anew.

So we make this entry back into the empty screen that it was.

And down here we have exhausted all the candidates.

But no solves the problem.

We return false because this is an invalid succession of searches.

And if no empty spot in the first place that will just return.

Now we can get rid of this boilerplate code from our template.

Now the structure is pretty much clear.

And all I need to do is to fill a those helper functions.

helper functions for retrieving rows, columns and groups.

So here are my helper functions for retrieving rows, columns and grids.

This is pretty straightforward because our board is just a 2d array.

And to retrieve the cape row, column, or grid at our center row and column indices, we are basically just doing some really smart indices and sometimes relying on the power of either tools.

I will post my complete code on my GitHub link to in the description so you can digest those helper functions on your own.

Now let's run the code and see what we get.

Great, our output is accepted that submit and test it against all the test cases.

Awesome.

With this template, we still to lico hard problems.

To recap a backtracking problem is all about finding valid states.

To so far valid state, we identify candidates that satisfy the problem constraint and use them to build upon our current state.

Once a modified state is valid, we added as a final solution.

Now that we have sub two problems hands off, let's take another look at our template.

Recall that we have these four functions, as well as state is a helper function with a Boolean return value that validates whether a given state is final solution.

Get candidates is another helper function returning a list of candidates satisfying the problem constraint based on our current state.

Search is a recursive function or cost the two helper functions as well as state and get candidates and recurse on itself.

Lastly, solve is the function another lico problem is asking you to write it does nothing fancy other than initializing an empty list of solutions.

And then to state and colleagues search on them.

For more practice problems on backtracking, go to leak co.com and intacs search for backtracking.

This filters out a list of questions that all shares a backtracking idea.

You see, we already solved Sudoku solver, and n queens.

If you're looking for a medium hard problem, I recommend the subsets problem.

This is about finding all possible subsets or power sets often given an integer array.

It is pretty easy to identify a backtracking problem when we are asked to find all possible solutions and may return a solution in any order.

As you can see, in my submission details, I soaked the subsets problem using the exact template.

As you go through more and more legal problems, and test how much you understand about the template, you will be better prepared to identify a backtracking problem once you encounter one in your coding interviews.

This concludes our video and the only Crash Course you ever need for solving backtracking problems on your coding interviews.

For more content like this, please subscribe to my YouTube channel links down below.

I also post form project tutorials at my game development demos on my channel.

My latest tutorial is about building a discord AI chat bot with the personality of your favorite character using entirely cloud based technologies and I'm sure you will enjoy it.

Thanks for watching and best of luck preparing for coding interviews.

Technical interviews are one of the most stressful parts of landing a job in tech.

You don't know what questions the interviewer is going to ask. What if you have no idea how to solve the problem in front of you? What if you freeze up and look like you don't know what you're doing?

Many aspiring programmers work themselves up into a frenzy as they try to memorize every coding interview question. You and I both know this approach is unsustainable. I'm here to tell you there's an easier way.

I recently sat down with my friend Michelle, who's a senior software engineer at Stitch Fix (a recently IPO'd company). She shared the kinds of qualities she looks for in developers that she interviews.

Honestly, the qualities might surprise you. I promise they don't include memorizing coding interview questions and solutions.

The rest of this article will unpack the qualities Michelle looks for in developer candidates. I'll translate each of these qualities into key interview behaviors. Then I'll tell you how you can implement them in your own interviews. Let's get started.

Qualities you should have going into the coding interview

When I sat down with Michelle, a part of me imagined I was getting a secret code to cracking the coding interview. I thought I'd hear the ultimate algorithm to solving every problem out there.

While we know a universal algorithm doesn't exist, she did share something even better: how to create a mental a framework for interviewing.

Success is not about memorizing every problem and solution. Rather, it's about learning how to solve problems.

As a developer, there won't be a cookie-cutter LeetCode type of answer. This is where mental frameworks are incredibly helpful. They create just enough problem solving certainty to overcome a seemingly ambiguous problem.

Here are Michelle's key components to building a killer mindset framework for your coding interview.

Be curious

One of Michelle's biggest tips for developer candidates is to be curious. Clarify the problem and ask questions. Share any thoughts you have on the problem you're facing. Interviewers aren't just looking for the right solution. They want to see how you think.

The best way you can show how you think is by asking questions. Let's say an interviewer asks you to check if a string contains any digits. You should clarify the question in your own words, something like:

"So I need to find a way to verify if a set of characters contains any numbers?"

When you say this you're giving interviewers insight into your logic. You're also showing them you're interested in the problem.

And don't be afraid to ask follow-up questions. Using the same example above, here are a few questions you can ask:

"Do the numbers I'm looking for contain decimals?"

"Do I need to sort the characters in any way before checking them?"

Be open to suggestions

One thing that is easy to forget is that interviewers want you to succeed. Most interviewers want to provide real-time feedback and suggestions to candidates. But candidates often take a non-verbal, siloed approach to the coding interview.

One way you can be more open to suggestions is by engaging your interviewer. Verbalize your logic and take them along your problem solving journey.

We'll use the same problem as above. Here are a few ways you can verbalize your logic from the get-go:

"So I'll need to establish a way to separate characters from numbers, right?"

"I'm thinking about iterating through the set of characters from end to end."

"I want a programmatic way to iterate through characters, but stop at numbers."

The more insight you can provide, the more your interviewer will feel inclined to help.

Work collaboratively

This goes hand in hand with the above. The idea that a developer works siloed and alone is a myth. You have version control and project management tools that require collaboration.

You should verbalize your approach, ask great questions, and loop your interviewer in. You'll arrive at the solution much more quickly. But you'll also show your interviewer you can effectively collaborate with other developers.

Here are a few ways you can loop your interviewer in:

"Would a for loop be too simple/complex for this solution?"

"How important is it to establish if there are floats or not?"

"Is there any type of solution you have in mind?"

Be willing to just go for it

Finally, Michelle suggested that developer candidates should just go for it. Meaning, go for the success you want to see.

One of the most common occurrences for candidates is that they freeze up. While this is understandable, no one wins in this situation. You can't show how incredible you are and the interviewer can't help you. Here's what Michelle said to "just go for it":

Even if you have to pseudocode your implementation, that’s better than being too nervous to try. Putting something on the board/coderpad will invite discussion, a chance to share your thoughts, and an opportunity to learn.

Don’t be afraid to fail! It just means you’re one step closer to succeeding. :)

"Just go for it" can mean a lot of things. That said, here are a few examples of what that can look like:

• Write pseudocode on the whiteboard, paper, or coderpad
• Note exactly where you are stuck in your logic
• Verbalize the solution you wish you could come up with

Use the Mindset Framework to Ace Your Coding Interview!

Coding interviews can be scary and there's always the fear that you'll freeze up. Part of this fear stems from not knowing which questions will show up.

The great thing is that you no longer have to memorize coding questions and solutions. Instead, build a mindset framework with the key interview behaviors you read about today.

You want to be curious and open to suggestions. You should work in collaboration with your interviewer. Be willing to go for the success you want to see. Happy interviewing!

If you want to see more of this type of content, subscribe to my newsletter at Course to Hire. I'll help you learn how to code and break into tech. Feel free to add me on LinkedIn as well.

P.S. – if you're interested in connecting with Michelle, ping me on Course to Hire or LinkedIn and I can make the intro.

If you are a new grad looking for an internship or full-time position at a top-tier tech company, this article is for you.

If you know someone who’s currently in the process of looking for a new developer job, send them this article.

I summarize some of the top mistakes I see as a career coach, and as someone who’s been on both sides of the metaphorical interviewing “table”.

These tips have helped me land job offers from Microsoft, Amazon, and Twitter – all without an Ivy League degree.

Avoiding these mistakes is critical because, if you are making any of these mistakes today, chances are your resume is not getting picked up by the right people.

Even worse, you’re not getting the opportunity that you deserve.

If you prefer to watch this article instead, I made a whole video about it here:

Mistake 1: Too much fluff, not enough stuff

Many first-time candidates spend too much time on their resume!

What I mean specifically is that they focus mainly on the formatting, the color, the fonts, and the layout of the resume.

They’re so focused on the formatting of the resume that they can’t see the forest for the trees. They don’t realize that their resume lacks the right content for the jobs they want.

Why’s that important, you ask? In today’s market, trying to be a software engineer is a highly competitive industry. There were 26 million developers by the end of 2019, and we're expecting to have 27.7 million developers by 2023, according to this article.

And it makes sense why many people covet jobs in the software engineering industry: they often boast a  high 6-figure salary, amazing health benefits, unlimited PTO, free snacks and food, among other perks.

In a competitive, red-hot market, the thing you need to do to stand out is to focus on the actual content of your resume. What that means specifically is to pick up “meaty” or interesting projects that will hone your technical chops and beef up your portfolio.

Here’s an example of a web crawler that I built to help me apply to companies and also beef up my resume.

Strong technical skills/experience makes you a much stronger and attractive candidate. Many fresh grads try to pad up their resume with non-tech related experience like social clubs.

I don’t think those are unnecessary. Non-tech related experiences are valuable insights into your character. But if you’re trying to apply as a software engineer, what’s most important here is the technical content.

Companies want to see your technical skills, whether you can write code, and if you can deliver a given assignment and get stuff done.

Mistake 2: Tutorial Hogs

The second most common mistake I see is that many people spend too much time on tutorials with no clear goals in mind.

They’re the typical Coursera/EdX/ warriors who sign up for every Android, Swift, JavaScript, React course available and work through them diligently.

They know every syntax of every programming language out there. They can chat religiously about MVC vs MVVC. They know what’s “in” and what’s “out”.

But the truth is usually not so rosy — about a few weeks into one course, they give up.

They have learned the syntax of the language and how to set up the framework. But they haven’t actually built anything substantial using the knowledge that they have gained.

Now that is a problem because what happens is that you have a lot of “fringe” knowledge (things that few people know a lot about). But you are not able to take that knowledge and apply it.

In the industry there’s something that we call “applied intelligence.” Can you apply your knowledge to a new domain? Can you take your knowledge about Python, for example, and use that to automate your finances via a Python script?

If you can do so, then you’re presenting yourself as a holistic, technical-oriented problem solver. And that’s what a lot of companies are looking for.

Mistake 3: Missing the forest for the trees

Why limit your job search to only San Francisco or Seattle? Or even the US for that matter?

Most people make the mistake of applying only to the companies that they’ve heard of, like Google, Facebook, or Twitter.

But the problem is this: there are only a handful of top companies in the industry with even fewer job opportunities.

The truth is you have a very limited set of openings, with a lot of competition from the large pool of applicants all over the world. The chances of getting an interview or even landing a job become extremely thin for the average person.

My recommendation is to expand your horizons and search beyond just the companies you’ve heard of.

Instead of just focusing on those top tech companies, open up your eyes and look across startups, midsize companies, and non-tech companies because those are the best opportunities right now.

Starting somewhere small and building your experience along the way is a great way to bootstrap your career. It doesn’t really matter how much you get paid initially or what the title of the position really is, because once you get your foot in the door, you can learn and improve yourself to prepare for the job you want.

That’s exactly what I did when I graduated from college — I didn’t have any job lined up. I then wrote a script that helped me apply to different companies, and finally a startup took a gamble on me and gave me a job. You can read more about my story here, and how I finally landed at Twitter.

Mistake 4: Right Credentials, Wrong Job

My best analogy for this: would you buy a shovel to build a door? Most likely no, so why would you apply as a machine learning specialist if you are a front-end engineer?

This baffles me as I’ve seen many great resumes come through the door for the wrong positions. Most of my friends have seen this happen as well. And the unfortunate truth is that, most companies will throw your resume in the trash if it’s not the right fit.

Some of my friends shyly confided in me that they’re hoping that the HR department would slot their resume in the right hands somehow.

I’m sorry, but they won’t.

If you’re a software engineer and you’re trying to apply for a machine-learning positioned, ideally your resume should have some relevant experience related to machine learning. Either you should have taken some internship projects or have some machine learning related experience at your current job.

My personal recommendation in this case is to:

1. Figure out what skill sets you have and how your skill sets match up with the position
2. Get a friend to review your resume with you and see where the gaps are

If you don’t have a friend (sad but OK), then ping me here — I can’t promise I’ll find you a friend, but I can help review your resume.

Keep refining your résumé. And keep applying.

If you found this article useful, join my newsletter where I write monthly about software engineering, technical interviews, and technologies here. Follow me on Twitter.

I've answered most of these questions over the years. But there's an entire period of my life that I've never talked about before.

Mostly because I don't want any kids reading this to think: "I should drop out of school" or "I should run away from home and live on the streets." Please don't do these things.

The reason I'm sharing this now is to show you that I have made mistakes.

You don't have to let anger or nihilism consume you, like I almost did. While there is still life, there is still potential.

So, yes – I dropped out of high school.

Yes – things got so bad I spent a year sleeping in my car, in Walmart parking lots around Oklahoma City.

Yes – I managed to turn my life around – getting a GED while working at Taco Bell, and getting a degree from a commuter school.

Yes – I ultimately worked as a reporter, moved to China for several years, and became a school director, managing 25 employees.

And yes – all of this happened within the same decade.

The longest, hardest decade of my life.

Software Engineering Daily host Jeff Meyerson interviewed me at length about my past. In our 2-hour conversation, we explored the years leading up to me learning to code and building the first version of freeCodeCamp.

I've embedded the podcast below, along with the entire transcript. But first, here's the part where I describe this period of my life.

Punctuated Equilibrium

I think every kid growing up in Oklahoma City in the 1990s can relate to how devastating the terrorist attack was. Not just for the families of all the people who died, but for everyone who felt the rumble of the explosion as it tore through the city.

For me, it was an end of innocence.

Here's how I described the event during Jeff's interview:

The day my childhood ended was April 19th, 1995. I was in Oklahoma City, 9:02 AM. I was in my science class and suddenly all the beakers started rattling and all the tables started rattling. And I'd never been in an earthquake before, but we just assumed it was an earthquake.

All the students, the teacher, everybody looked around and looked at one another. We saw the room shaking and we didn't know what happened. A few minutes later we found out what had happened.

There was building in downtown Oklahoma City and a terrorist had parked a truck in front of it filled with fertilizer. And he detonated it and killed 168 people, including 19 little babies that were in a nursery on the ground floor.

So that for me was a huge jolt. I went from just being what I would describe as a pretty typical middle-class kid in middle America - to starting the question reality, and how we got to this point where something like this wasn't stopped.

Then watching the ensuing chaos, watching how people around me reacted. I had a classmate who lost her dad. That experience really woke me up. From then on, I couldn't really look at reality the same way.

My grades and my family situation at home quickly deteriorated.

After years of unhappiness, I made a series of dramatic decisions.

My dad was a strict disciplinarian, and we would always fight. One day when I was a sophomore in high school, I got sick of fighting with him. My grandma had just died and I had inherited her 1986 white Ford Taurus sedan. I grabbed all my stuff and threw it in the car and I just drove off.

I spent the next year of my life just living in my car. Staying in Walmart parking lots overnight where there was light.

At first, I kept going to high school. But one day I was in the cafeteria and I saw a man from my church who had been a huge inspiration to me. He always volunteered to lead Sunday school, and I was really good friends with his kid.

He had a college degree and he’d worked for decades. But I saw him in the cafeteria with a hairnet on, serving food. And he had been reduced to doing that to be able to provide for his family.

And at that moment, I just – within that instant, I just kind of became disillusioned with school and I just decided to drop out.

So I was living in my car, and I just started going to the library every day where it was warm and just rotating through all the different libraries around Oklahoma City. Reading books and just thinking a lot. Then pulling up in the Walmart parking lot and going to sleep.

Life as a high school dropout living in my car was hard. The gravity of the situation hit me fast.

My savings from those summers of mowing lawns evaporated. I had no useful skills. I had burned most of my bridges.

I could no longer ignore my problems and try to live inside books or inside my own head.

I needed to figure out how to make ends meet so I could survive.

Eventually I needed money to buy food and stuff. So I got a job at Taco Bell. My manager was this burly guy named Duke who had a very prominent Confederate flag tattoo on his arm that his uniform didn’t cover.

Whenever business was slow, I'd just run to the backroom, I’d build a burrito real quick and eat it. And I'd just kind of contemplate my life and where things were going and what I was going to do. I really had no idea, but I decided that I probably did need to probably go to school if I didn't want to end up like Duke here.

So I took the GED and I enrolled in the cheapest state university I could. And I traded my Taco Bell job for working at different newspapers around town while I was studying liberal arts.

I would just run around with my steno pad and interview people in different positions of power. There were a bunch of rich homeschoolers around the city and I would just go over and teach them. So that was my first experience with teaching.

Those first few years of working as a reporter helped me ask better questions, and better understand how the world worked.

The dean of the Liberal Arts department took me under his wing. He told me about his invite-only weekly seminar with international students from around the world.

Learning about life in other countries - straight from the people themselves - really opened my eyes.

The world was so much bigger than Oklahoma City.

By the time I graduated, I already knew where the big change was happening. It was the early 2000's and there was only one destination that an ambitious person would seek out, and that was China.

China was undergoing a historic state of hyper growth where 300 million plus people were going from subsistence farming to middle-class service sector-type jobs. I wanted to understand that.

So I found an international graduate program where I could go and study with a bunch of Chinese. I got on a plane and I flew to Tianjin.

I didn't know anybody there. I was the only westerner on a campus of 20,000 people. I had a bunch of Korean international trade students who shared a room with me, and I set to work learning Chinese and learning as much as I could about China."

After 4 years of studying and working as a teacher in China, my wife - a classmate of mine - got her US visa. We moved back to Oklahoma City.

I was 26. I was the youngest school director in the school system, and I was just learning about how to run a school and how to...

Jeff: How do you get there? How do you get that job? How do you get the job as the youngest school director in a school system?

Me: Well, when I immediately came back from China, I worked at a convenience store and I was trying to find any job I could that was focused on an international education.

I found this one school that was an intensive English program on a university campus, and I just did everything within my power to get that job. I learned everything I could about the people who worked there. I learned everything I could about the history of the organization, and I just went in there like a walking, talking encyclopedia, and against all odds, I managed to get that job

I remember I interviewed for like six hours on three different occasions, because the director was – she was skeptical that I would be able to do it, because I didn't have any real managerial experience.

The teaching experience I did have was mostly teaching homeschoolers and teaching engineers from Brazil in China. I would teach them how to use English, because there were just huge swaths of people moving to China to be able to participate in the big economic boom that China was experiencing.

So I was teaching all these expats how to speak English and I was teaching Chinese how to speaking English, and so my teaching experience was fairly limited. I didn't have a master’s degree in education or in teaching English as a second language or anything like that. So I really just had to offset all that by just interviewing extremely well and being extremely knowledgeable.

So this is where I learned how to manage people. I was not only managing teachers - I was also managing other administrators. I was managing home stays. Basically, people who open up their homes to welcome students from abroad.

We had a lot of students from China, Japan, from Korea, from Saudi Arabia, from Brazil, and from Europe, and I had to work directly with those parents and iron out a lot of the problems. I had to work with agencies who wanted to place students in the U.S. I had to work with the U.S. government and the immigration department and just do an incredible amount of paperwork and basically keep this school running.

I went from managing zero people to managing 25 people overnight when I get this job.

It was a crazy decade. And what I've shared with you here is just a few minutes of the podcast interview. Jeff and I talked about a lot of other things, too. Including where freeCodeCamp is heading in 2020.

You can listen to the full interview here (140 minute listen):

Or you can hear it on Software Engineering Daily's website (with options to open it in various podcast players).

I want to thank Jeff for inviting me back onto his podcast, and for his thoughtful questions. At this point, he's interviewed nearly 1,000 developers on his show. I strongly encourage you to subscribe.

Here is the full transcript of the interview.

Jeff: freeCodeCamp was started five years ago with the goal of providing free coding education to anyone on the internet. freeCodeCamp has become the best place to begin learning how to write software.

There are many other places that a software engineer should visit on their educational journey, but freeCodeCamp is the best place to start, because it is free and there are no advertisements.

For most people learning to code, the price of that education is very important, because they’re learning to code to build a new career. Many people are learning to code because they don't have any money.

It's also important that a new programmer learns from an unbiased source of information, because an ad-supported environment will educate the new programmer towards products that they might not need.

freeCodeCamp has not been easy to build. Building freeCodeCamp has required expertise in software engineering, business, media and community development.

The donation-based business model of freeCodeCamp doesn't collect very much money. Why would somebody build a nonprofit when they could spend their time building a highly-profitable software company?

Quincy Larson is the founder of freeCodeCamp, and he joins the show for a special episode about his back story and the journey to building the best place on the Internet for a new programmer to begin.

This was an enjoyable episode for me, because I am friends with Quincy. I’ve spent a lot of time with him, but I actually knew nothing about his background.

If you think about it, it's pretty interesting that somebody would start a nonprofit with his collection of skills. So why would somebody do that? Well, the answer is in this interview, because he has a very distinctive background with a lot of ups and downs.

Learning about Quincy’s story help me understand in much greater detail why he built freeCodeCamp and the related media properties of freeCodeCamp. They have a very popular YouTube channel, a popular podcast, and I recommend checking out those resources.

Thanks to Quincy for coming on the show, and I hope you enjoy this interview with him.

[00:04:05] Jeff: Quincy Larson, welcome back to Software Engineering Daily.

[00:04:08] Quincy: Thanks, Jeff. It’s an honor and I think it’s been about four and a half years since I’ve been on Software Engineering Daily.

[00:04:14] Quincy: Well, it’s been a while since you were on to only talk about that. We had some random shows. You were on with Haseeb. We talked net neutrality a little bit.

We had some random discussions, but we haven't talked about your magnum opus in a while, which is freeCodeCamp, except for when you come to San Francisco, or when you're in San Francisco living here, and we go on runs, or we talk at length in certain contexts, having tacos or whatever, about what you're building.

One of the reasons I think that you and I tend to get along well and always have a lot to talk about is that both you and I are building organizations that don't fit within many conventional rubrics.

There are these kinds of organizations that are only enabled by the dynamics of the Internet, the emergent dynamics of the Internet, and both of us are working on platforms that essentially create and disseminate information about the Internet. I think those two things are closely intertwined, because we are excited about the Internet and its potential, and that's what fuels a lot of the passion behind both of our projects.

So freeCodeCamp, for people who are unaware is gigantic. It helps tons of people. As you said, we did a show four years ago where we talked about the basic rubric of freeCodeCamp, but we’ll obviously get into the architecture of it and the vision for in a lot more detail in this show. We’re going to do a long-form discursive conversation.

To lay the groundwork for that, one thing I want to understand is, is freeCodeCamp a business or a philanthropic endeavor?

[00:06:16] Quincy: freeCodeCamp is a 501(c)(3) donor-supported, tax-exempt nonprofit. So it's a public charity. The same designation that the Red Cross, Doctors Without Borders, that a lot of these other big, multinational, nongovernment organizations have. So I would qualify it as a charity.

[00:06:38] Jeff: There are charities that are wildly profitable. There are very few of them, like Mozilla, for example. Would you rather freeCodeCamp be a donation-based platform, à la Wikipedia, or something more like Mozilla, where it's a nonprofit, but happens to be profitable?

[00:07:01] Quincy: Mozilla is a really interesting case, and from what I understand, it's almost a nonprofit that swallowed a much, much larger for-profit enterprise, like Firefox. I think Yahoo was giving Mozilla hundreds of millions of dollars a year to use Yahoo search as their default browser instead of Google, for example.

Mozilla is interesting because they’re so large because they’re almost a hedge against the more monopolistic tendencies of Google. So I don't know that Mozilla is a model that can be easily replicated by other nonprofits.

[00:07:39] Jeff: When you decided to build freeCodeCamp, you’re doing something without much precedent, but you were very confident that it would work. Where did you derive that confidence from?

[00:07:55] Quincy: Well, I wasn't super confident initially when I launched freeCodeCamp. But after people stuck around...

So the brief history of freeCodeCamp, and I can go much farther into my personal history later, which I think is relevant. I have never really talked about it before. But this is the fifth anniversary of freeCodeCamp. I think that it's as good a time as any for me to explore that.

But just to answer your question real quick. After people started sticking around freeCodeCamp and after they started progressing through their curriculum and then going out and getting developer jobs. Then in my mind this became a proven model. Because people were able to, without spending any money, without even quitting their jobs or doing anything dramatically different than what they were already doing, just spending an hour a day coding on their own, they were able to transition careers.

Once we saw a whole lot of people doing that, then it became clear that this was a repeatable model and that we could scale it.

[00:08:51] Jeff: Describe how your perspective shifted as you started to gain some significant traction with freeCodeCamp.

[00:09:02] Quincy: Well, we immediately knew that we could help a lot more people than we were if we continued to scale things up. We could've kept it small. And there's lots less risk in just keeping it small.

It's the equivalent of hand assembling things by Ph.D.'s in a clean room type environment.

Or we could go way out there and just try to help people who traditionally were not able to easily transition to the tech.

So initially, most of the people were here in America. Most of them were already college-educated, middle-class people.

And gradually we've just tried to make freeCodeCamp more and more accessible to people outside of the U.S. and people who didn't necessarily have strong traditional foundational education that we would consider in the U.S. like going to a good public university, for example.

A lot of countries don't have public universities on the order of what we have in the U.S. A lot of people don't have access to even a secondary education that’s on par with what we have in the U.S.

So we have people who’ve now gone through freeCodeCamp who grew up in the slums in Delhi or grew up in the slums of São Paulo and didn't have much education at all, but were able to use freeCodeCamp and learn enough that they could go out and get a job as a developer.

So that was a big jump that we took, and there was no real precedent for this to work. And even when it started working, you have to ask, “Are these isolated instances of extremely motivated individuals who just haven't had enough opportunity, or is this something that really can be generalizable to the point where freeCodeCamp can become kind of a "curriculum of last resort" for people regardless of their social economic background where they can potentially get a really lucrative job and provide for their families, and by extension, inject productivity and economic activity into their local communities?

[00:11:11] Jeff: You define yourself as a teacher. At its base, the idea of it teacher throughout history is a very esteemed role. It's a role that in order to be effective requires leadership, and leadership is complex, and difficult, and testing. There's a sense that the esteemed elements of the teacher in the United States for the last few generations has decayed a bit.

I think it has something to do with the increasingly mechanized process, the increasingly corporatized process of the public school system. I'm sure you have some thoughts on this. But what's at the core of your desire, the aspirant desire for Quincy Larson to identify as a teacher?

[00:12:25] Quincy: Well, teaching has a long tradition. Confucius was a teacher, right? You can go all the way back to ancient civilizations, and you can see teachers playing a role – Socrates.

This is a tradition that is carried on through the generations, and the role of teacher has become more and more refined in modern times. And usually teachers are fitting into some sort of big school system. Whether that's at the university level or whether that's at a primary school. It's a pretty diffused role.

I would describe Carl Sagan as a teacher. I would describe Bob Ross as a teacher.

The actual definition of teaching is somewhat malleable. So I continue to use the title teacher, since I worked as a teacher for about a decade before I started freeCodeCamp. I continue to use that title because I think that teaching people through instructional design at scale is also a form of teaching.

[00:13:32] Jeff: Tell me about the decade of time you spent as a teacher.

[00:13:36] Quincy: Well, I will probably have to go even farther back to really tell you about how I got into teaching, because it's pretty complicated.

[00:13:47] Jeff: We’ve got nothing, but time.

[00:13:48] Quincy: All right. Let’s go way back. So I'm going to go way back to my childhood, if that's okay, and I'll bring you up to speed, because teaching was just one progression, one step toward ultimately what led me to create freeCodeCamp.

The day my childhood ended was April 19th, 1995. I was in Oklahoma City, 9:02 AM. I was in my science class and suddenly all the beakers started rattling and all the tables started rattling. And I'd never been in an earthquake before, but we just assumed it was an earthquake.

All the students, teacher, everybody looked around and look at one another. We saw the room shaking and we didn't know what happened. A few minutes later we found out what had happened.

There was building in downtown Oklahoma City and a terrorist had parked a truck in front of it filled with fertilizer. And he detonated it and killed 168 people, including 19 little babies that were in a nursery on the ground floor.

So that for me was a huge jolt. I went from just being what I would describe as a pretty typical middle-class kid in middle America to starting the question reality, and how we got to this point where something like this wasn't stopped.

Then watching the ensuing chaos, watching how people around me reacted. I had a classmate, she lost her dad. Just that experience really woke me up. From then on, I couldn't really look at reality the same way.

My dad was a strict disciplinarian, and we would always fight. One day when I was a sophomore in high school, I got sick of fighting with him. My grandma had just died and I had inherited her 1986 white Ford Taurus sedan. I grabbed all my stuff and threw it in the car and I just drove off.

I spent the next year of my life just living in my car. Staying in Walmart parking lots overnight where there was light.

At first, I kept going to high school. But one day I was in the cafeteria and a man from my church who had been a huge inspiration to me. He always volunteered to lead Sunday school, and I was really good friends with his kid.

He had a college degree and he’d worked for decades. I saw him in the cafeteria with a hairnet on serving food, and he basically been reduced to doing that to be able to provide for his family. At that moment, I just – within that instant, I just kind of became disillusioned with school and I just decided to drop out.

So I was living in my car, and I just started going to the library every day where it was warm and just rotating through all the different libraries around Oklahoma City. Reading books and just thinking a lot. Then pulling up in the Walmart parking lot and going to sleep.

And eventually I needed money to buy food and stuff. So I got a job at Taco Bell. My manager was this burly guy named Duke who had a very prominent Confederate flag tattoo on his arm that his uniform didn’t cover.

Whenever business was slow, I just run to the backroom, I’d build a burrito real quick and just eat it and just kind of contemplate my life and where things were going and what I was going to do. I really had no idea, but I decided that I probably did need to probably go to school if I didn't want to end up like Duke here.

So I took the GED and I enrolled in the cheapest state university I could, and I traded my Taco Bell job for working at different newspapers around town while I was studying liberal arts. I would just run around with my steno pad and interview people in different positions of power. There were a bunch of rich homeschoolers around the city and I would just go over and teach them. So that was my first experience with teaching.

[00:17:53] Jeff: Wait. Sorry. Why are you interviewing people?

[00:17:55] Quincy: As a journalist. Basically, I worked for a bunch of different local newspapers. So I’d interview hospital administrators. I’d interview people with the city government. I'd get to talk to all kinds of people, and that was really what gave me a glimpse into how organizations worked and power structures.

[00:18:11] Jeff: And laid the groundwork for your future work as a podcaster.

[00:18:15] Quincy: Exactly, yeah. That interviewing experience was really important, and the more I talk to people –

[00:18:22] Jeff: It’s a great skill, right? Like it’s super flexible.

[00:18:25] Quincy: Yeah. You can use it to – If you have a steno pad or a press pass, you can go in and talk to anybody and ask them questions and really get to the core of why they're doing what they're doing and how these different structures work. That was really instrumental for me. I really came into my own interviewing people and learning more about them and learning how these systems worked.

[00:18:48] Jeff: Not to take you out of your flow a little bit, but what was your mindset like in the early formative days of this adventure? Because I think when I – Not to take the spotlight off you, but like when I think about my kind of – I went through a lot of like random odd jobs.

I’ve started so many random projects that have gone nowhere, and I think our audience, probably, there're a lot of people who are kind of going through this semi-random walk right now where they feel like maybe they're in a position where they know what they don't want. But they’re in the transition from knowing what they don't want to building positive habits and iterating towards what they do want.

I find that that can be psychologically difficult, but also a psychologically bolstering experience. So I'm kind of wondering where your head was at as you were making your way through the library and Taco Bell and getting your GED and going to a cheap college.

[00:20:04] Quincy: Well, for me, things were just so chaotic. The way I viewed the world was there was this appearance of order. But if we drill a little deeper, maybe can see the chaos underneath it.

Why do these structures exist? Increasingly, I started to see why our organizations were all structured around hierarchy where there’s almost always one person at the top and then several layers beneath them. And people show up at the office at a certain time and they do a very specific task and they have deadlines and everything is measured in a certain way.

Everybody's compensation is usually within one order of magnitude of the others, unless you get to these really large corporations where you have executives way at the top that make several orders of magnitude more than the other people.

But I started to think about why. There was a reason why these kind of emergent properties had taken hold. So it was enlightening. I mean, it was really – I felt like I was uncovering some important stuff, especially when I was grilling these different administrators and asking them a lot of questions, learning about how they think.

Why were things the way they were? The more you ask questions, the more questions reveal themselves. It was just this unending onion that I was peeling away layer to layer.

[00:21:32] Jeff: It gets bigger as you peel it.

[00:21:34] Quincy: Yeah. I don't think that there is like some big conspiracy or anything. I think it's just a whole bunch of people that are operating in this system that miraculously works as well as it does. But it’s probably not anywhere near as effective as it could be.

That was the thing – I guess if I had to describe my experience, it was absolutely invigorating. It was just this euphoria of discovery, like, “That’s how that works. That’s why things are the way they are.” But at the same time, it was very disappointing that 200,000 years in human history and we've got a bunch of people sitting in suits at desks sipping coffee and shifting papers around.

[00:22:18] Jeff: Well, to take this further, contrast the invigoration of your active learning process to the stagnation of the traditional education system that you grew so disillusioned with.

[00:22:34] Quincy: Well, I can totally see why education is the way it is. I mean, through years of just teaching and interacting with students, interacting with teachers, interacting with administrators, I started to understand that things were the way they were because they were good enough and I kind of came to see a lot of education as childcare essentially. It's the government’s way of essentially relieving parents of their kids for the day so the parents can go and work.

Kids do learn stuff, but it's very suboptimal. I mean, summer break, you basically wipe out months of learning over the course of the summer break. Why do we have still have summer break? Having eight classes a day where they’re each 50 minutes long and kids spend almost as much time transitioning from one class to the next as they do actually sitting down and learning. There are all these things that reveal themselves.

The incredible cost associated with both private and public education. The average student in America, I think we spend like $10,000 to $12,000 per student per year for education.

And this isn’t just like government inefficiency or anything like that, because private schools are much the same. The costs are pretty similar. It’s just that they've shifted to the parents and away from taxpayers to where people are paying directly.

So that, and then when you get to the university level, costs are even higher. For some reason, we now have one administrator for every professor. Just the administrative creep and all these things, like how do you explain the growing bureaucracy? I think a lot of it comes back to human nature. I don't have any particularly satisfying answers for you. I can just say that it works the way it works because nobody has forced through a step change yet.

But I think that such changes are probably inevitable, and I don't delude myself to thinking that I personally can have an impact on this system that is everywhere. Every country in the world pretty much has a similar education system, and has similar higher education system.

[00:24:45] Jeff: Well, you are painting the contours of freeCodeCamp in a whole lot more resolute light through telling your history here. I’m starting to understand a little bit more about where you're coming from here. At this point, you're in this transitory state where you're doing interviews as a journalist. You’re going to school. Let's continue down memory lane here.

[00:25:23] Quincy: Yeah. So I graduated, and by the time I graduated, I already knew where the big change was happening. It was the early 2000's and there was only one destination that an ambitious person would seek out, and that was China.

China was undergoing a historic state of hyper growth where 300 million plus people were going from subsistence farming to middle-class service sector-type jobs. I wanted to understand that.

So I found an international graduate program, essentially, where I could go and study with a bunch of Chinese. I got on a plane and I flew to Tianjin.

I didn't know anybody there. I was the only Westerner on a campus of 20,000 people. I had a bunch of Korean international trade students who shared a room with me, and I set to work learning Chinese and learning as much as I could about China.

I met my wife there. She was one of my classmates in one of my classes in grad school, and I spent the next two years of my life just learning about China and learning about business through the eyes of China. Learning about the history, learning about the people, and of course spending a huge amount of time just learning both Mandarin and Cantonese, because my wife is Cantonese. We spent a lot of time in the South.

So that was the next period of my life, and it was an exciting time to be alive.

I was absolutely in the right place at the right moment to learn an incredible deal, and that will probably remain the most invigorating and exhilarating part of my life.

Then I came back from China and I started working as a teacher and a school director here in the U.S. after my wife had been granted a visa. Eventually, she was able to become a U.S. citizen. Then I was running schools here in the U.S. and in China.

[00:27:26] Jeff: You were how old?

[00:27:28] Quincy: I was 26. I was the youngest school director in the school system, and I was just learning about how to run a school now and how to –

[00:27:38] Jeff: How do you get there? How do you get that job? How do you get the job as the youngest school director in a school system?

[00:27:43] Quincy: Well, when I immediately came back from China, I worked at a convenience store and I was trying to find any job I could that was focused on an international education. I found this one school that was an intensive English program on a university campus, and I just did everything within my power to get that job. I learned everything I could about the people who worked there. I learned everything I could about the history of the organization, and I just went in there like a walking, talking encyclopedia, and against all odds, I managed to get that job.

I remember I interviewed for like six hours on three different occasions, because the director was – she was skeptical that I would be able to do it, because I didn't have any real managerial experience. The teaching experience I had was mostly teaching homeschoolers and teaching engineers from Brazil in China. I would teach them how to use English, because there were just huge swaths of people moving to China to be able to participate in the big economic boom that China was experiencing.

So I was teaching all these expats how to speak English and I was teaching Chinese how to speaking English, and so my teaching experience was fairly limited. I didn't have a master’s degree in education or in teaching English as a second language or anything like that. So I really just had to offset all that by just interviewing extremely well and being extremely knowledgeable. That was a big step, because before that, that was my first step actually into a managerial position.

If you think about what I do today with freeCodeCamp, it's mostly managing teams of volunteers, and then we have a small team of seven people, including myself, who work full-time on freeCodeCamp.

So this is where I learned how to manage people. I was not only managing teachers - I was also managing other administrators. I was managing home stays. Basically, people who open up their homes to welcome students from abroad.

We had a lot of students from China, Japan, from Korea, from Saudi Arabia, from Brazil, and from Europe, and I'd have to work directly with those parents and iron out a lot of the problems. I'd have to work with agencies who wanted to place students in the U.S. I had to work with the U.S. government and the immigration department and just do an incredible amount of paperwork and basically keep this school running.

I went from managing zero people to managing 25 people overnight when I get this job.

[00:30:25] Jeff: This is this is also around the time when you started to get serious about technology, right?

[00:30:30] Quincy: So after a few years of running schools in the U.S. and China, I was in a situation where I noticed that my teachers were spending a whole lot of time chained to their desk doing menial back-office tasks, like grade reports, like immigration reports, like attendance reports, things that could be automated if I learned some basic things.

So I just Googled around. I learned some Visual Basic. I learned some different tools for programmatically clicking through government visa forms and things like that, and I essentially told my staff, “Hey, I'll take it from here,” and they were able to spend all their time with the students, and the students were so happy, because that's what they came over here for, to learn English and to spend a lot of time with Americans and get ready to integrate so they could go to their graduate programs.

So that was the time that I learned very basic programming and scripting. From there, I saw how powerful it was and I started thinking, “Wow! I could build an entire system that helps schools run more efficiently.”

Then a thought occurred to me, “Well, maybe I should just learn how to program properly and then I'll be in an even better position to build this tool.”

So I spent nine months just going to hackathons, hanging out at hackerspaces and coding and doing everything I could - working through tons of textbooks, working through free online courses that were coming out of MIT and Stanford, and just every weekend, a different hackathon. I did dozens of hackathons that year, and then I was able to get an entry-level developer job.

When I worked as a developer, that's when the real learning started. And I started learning more and more about working in teams, about using version control, about software engineering principles, about the dynamics of creating software and maintaining software during deployments. Fighting with weird bugs and things like that, and that was the foundry where my developer chops were forged.

After that, I still wanted to help other people. I wanted to build the school management tool, but then I realized, “Well, if I can just help other people do what I did and learn to code, then they can go out and they can build school management tools, and they can build a whole lot of other tools that progress things and move things forward, and create new industries.”

So that's when I decided, “Well, I’m going to learn how to code. Then I’m going to teach other people how to code.” So I started building different projects around technology education, and eventually after several failed projects, I built the MVP for freeCodeCamp over the course of a long weekend. I pushed it live. I started tweeting about it, and people started showing up and using it.

That was a really amazing experience, because that was the first I had ever actually built something from nothing that people cared about, after years and years of building projects that I just couldn't get people to care about.

[00:33:29] Jeff: So I think that a big part of what makes freeCodeCamp successful and what will make it continue to grow is there is an aspirational vision to it, and I don't quite know how big that vision is. My sense is that it is big and grows every year, but it's possible that even when you are getting this thing off the ground, you had a vision for what freeCodeCamp could be that is more titanic than what has come to fruition today.

So before we start like diving into freeCodeCamp in gratuitous detail, I'd really like you to pull together the different threads of your unique experience and describe how those came together into the vision for what you are trying to do with freeCodeCamp. I really want to understand the vision and where you are trying to get to with freeCodeCamp.

[00:34:46] Quincy: That’s interesting question. So I would say some of the threads that come from my experience, first of all, questioning why things are the way they are. That was something that I learned pretty early on, and that informed freeCodeCamp, because I was able to ask a lot of questions like why do people meet in-person for school? Why do people have this set timeline? Why is school structured to where there is a beginning and an end? Why is there so much reading and some much lecturing in education versus just sitting down and doing it?

Then I started to realize, Well, a lot of the reasons for these things are rooted in convention. A lot of them are motivational, because if you're in a building with a whole bunch of other people sitting next to you, there is extrinsic pressure to perform. If you’re just on your laptop after a long day’s work, there’s not the same pressure for you to actually do the work.

So that informed a lot of freeCodeCamp, just understanding the limits of interactive, online, self-paced learning and understanding the motivational challenges that go along with it.

[00:36:00] Jeff: The MVP of freeCodeCamp, it was a certain way of learning to code, and I believe it has advanced quite significantly since then. I'm trying to remember what the first version was. Can you describe how freeCodeCamp has advanced since its MVP that you built?

[00:36:27] Quincy: Sure. For the benefit of listeners, when I say MVP I mean minimum viable product - essentially the first version of freeCodeCamp. So, initially, what I built over the course of that weekend was a curriculum where you could progress through. You could sign in and you could mark things done, essentially. Once you marked all of the things done, then you were done and you got this certification for freeCodeCamp.

So the curriculum was mostly external resources, like go take Stanford's computer science 101 class. Here's a link to it, and just work through the classes and then come back and check that you've done this once you finish it. We did the same thing with a lot of other different free online learning resource that were interactive. That was the first version. Important to that first version was I also set up a HipChat room. HipChat is chat room tool, and we would talk in there.

When people joined that chat room, I would be hanging out there and my goal was to motivate people and keep them progressing through there. So I talked to them. I’d say, “Hey, tell me a little about yourself. What inspired you to learn to code?” Leading questions that would waken within them that critical thing, like, “Hey, I should sit down and do this. I could transition into tech.”

So a lot of the early days when we were just trying to inspire people, and two great things happened. First, people would also see what I was doing and they would do the same thing - they'd be right there alongside me welcoming people to the community and asking them questions, and helping them when they got stuck or had any kind questions, or had any moments of crisis of confidence so that they could reassure them.

So that chat room was absolutely instrumental, and people helping me with this process was instrumental. Then people started getting jobs, and that was the tipping point.

Once people started getting jobs, this became a proven thing. This was no longer a toy curriculum that people did merely for self-improvement. It was an actual tool that they could use for economic development for their own personal career gain.

Once they started doing that, people would get a job and talk about how it helped them get a job, and people started contributing to freeCodeCamp.

We slowly replaced the curriculum of external resources with our own homegrown open source BSD-licensed curriculum. The BSD-3 is one of the most permissive open source license alongside the MIT license. We used Creative Commons share like the BY-SA. It’s one of the most permissive Creative Commons license on all the curriculum.

So we were all working on these things together and building up this giant curriculum that, in my opinion, was initially inferior to a lot of the external resources that were taught by university professors, but quickly came to be of comparable quality.

The freeCodeCamp curriculum had one huge advantage - it wasn't some professor talking at you through a video. The entire time, you were in a code editor coding and you had this test suite. And whenever you thought your code was ready, you just hit control+enter or click the button and it ran all the tests and told you whether your code was indeed ready.

You just got into this flow state where you’re progressing from exercise to exercise and learning experientially as you’re building up projects.

So that was a huge breakthrough in terms of motivation, was we sensed that a lot of the problems with traditional learning were just a really loose feedback loop. You sit in a class all semester and take notes and study those notes and then your evaluation criteria comes at the very end when you take the final, and you find out what score you got. It's hard to think of more coarse feedback than that.

But that's what traditional education generally has to offer. Yeah, maybe there are some quizzes along the way.

But interactive exercises were – You’re not waiting weeks or months for feedback. You're waiting a few milliseconds, because this entire platform runs right in your browser. It’s not even sending data back to a server. It’s just running the code right in your browser against a test, and within a few, often, microseconds, you’re getting a feedback.

There’re a near zero millisecond delay - it doesn't even hit the server. So it's about as tight a feedback loop as you can get, and that just really got sticky and people started implementing more and more challenges and the curriculum grew and grew from there.

[00:42:37] Jeff: So I remember this time when you and I met for the first time in person. I think it was at a Berkeley taco place, or I think you had a burrito, because apparently your Taco Bell days locked you into burrito mode. I think I remember actually a Quora answer where you also mentioned that much of your daily routine is built around microwave burritos.

So burritos run deep in Quincy Larson's life. But I remember talking to you at this Berkeley burrito place, and it might've been 9 months or 10 months into Software Engineering Daily and you were I guess probably a year and a half into freeCodeCamp.

So we were at kind of like similar junctures where we could feel a sense of traction, and I think you were listening to my show a fair bit around that time, because back then there were just really many software engineering podcasts and people in the states of voluminous isolation, such as yourself and myself, listen to a lot of podcasts, and you are really going down the rabbit hole of understanding software. So I think you are power listener around that time.

So we were having conversations about our respective project/businesses/Internet byproducts, Software Engineering Daily and freeCodeCamp respectively. I feel like both of us at the time were really unsure of what exactly it was we’re trying to get to.

I mean, even back then I think I was like, “Yeah, I mean I kind of hope all sell to O'Reilly, or like maybe start like five other podcasts and be like a twit kind of thing.” I guess those are still like possibilities or something.

But, I don’t know. It just felt early relative to where I think we both are at today where we have a little more confidence, a little more vision, a little more faith that the momentum or the inertia of our platforms will continue to sustain. I mean, I'm still paranoid. You strike me as somebody who's still paranoid about things just falling down.

But I guess I’d like to go back to that time. Because I remember you talking kind of like, “Yeah.” I mean, kind of worried about Treehouse or – What were the other ones around that time? Codecademy, Pluralsight, kind of these other education competitors. I think the market has borne out that online education about coding is just bigger than anybody expected. It's big enough to sustain all these different verticals. Each of them have different competitive differentiators.

But I guess I would like to go back to that time and understand how your vision for the defensibility of the business, or not business, philanthropic endeavor, the finances. Take me back to the early days and give me a bit more refined understanding for how the structure of freeCodeCampus is a sustainable, defensible entity was maturing in the early days?

[00:46:06] Quincy: So early on, I was confident that this would be something that anybody could just come and replicate. Technically, it is. I mean, you can still build freeCodeCamp today. But one thing that we had that was really propelling us was this huge community of people who had either graduated from freeCodeCamp who are now working in developer roles or contributors who maybe had done that, but that were still contributing to the community itself.

So freeCodeCamp as an open source software project. Nothing terribly special about that. I think it's very well-built. I think the pedagogy that we baked into it is very astute and it works. It works remarkably well considering that you spend zero money and that you can do it at your convenience over the course of years.

We have people who spend three or four years. I regularly see tweets from people said they started in 2016 and they just finished the final certification in 2019.

So the actual curriculum and the actual platform, nothing that exciting about it. But the community, that is what is really exciting, and it's difficult to build a community like freeCodeCamp has built up over the years, because it takes an incredible amount of hard work, and freeCodeCamp is not some corporate subsidiary. It is not something that’s just bankrolled by a billionaire. It is a community of like-minded people who have similar career goals and similar passions who came together and started building together and built this tool up over the course of the last five years.

So that community itself is by far the most important aspect of freeCodeCamp and the thing that I think other people would have trouble replicating. I say that because it took an incredible amount of work. I spent the past five years helping people answering hundreds of emails a day, going to different study groups around the world and talking to people and trying to cultivate as much leadership as possible as you can within a primarily volunteer-driven organization.

So I would say that I'm not the best developer in the world. I’m probably not the best on the spot like go up and give a lecture style teacher in the world. What I think I am really good at and what I’ve worked really hard to become good at is leading a community and understanding the needs of the people in that community, understanding how we can help those people and how we can help those people help other people.

[00:48:48] Jeff: What's been the most difficult part of building freeCodeCamp so far?

[00:48:54] Quincy: The most difficult part is absolutely just keeping things running in terms of money. I am profoundly, profoundly bad at asking for donations, at asking for help. And it has really shown, because a couple of weeks ago we had an outage. One of our API servers went down for two days and we did a root cause analysis, as we always do whenever there's some sort of outage. We did this postmortem.

At the end, the only conclusion we could draw, the real finger was pointed back to me and the fact that we are running this organization on a shoestring.

freeCodeCamp is currently I think in the top 1,600 websites on earth. We’re bigger than TechCrunch. All these online learning platforms you mentioned earlier, Udacity, Treehouse, Code Academy, we’re significantly bigger than all those in terms of usage, people using freeCodeCamp.

So how are we able to do all this with a budget of $373,000 in 2019? How are we able to deliver 1.1 billion minutes of instruction that’s equal to 2,000 years of people learning this year? We're not able to do it as well as we should be able to, because we had to cut a lot of corners. Everything has to be done as inexpensively as possible.

So we concluded at the end of that root cause analysis that we probably could have just spent 30 bucks a month on monitoring software that could have detected the specific type of outage and we could have just fixed it and it would've been two days of downtime. There wouldn’t have been this big investigation. But when you're broke, a lot of times the check engine light comes on and you don't have the resources to pull over and have some mechanic look at it, right? That’s precisely how freeCodeCamp has been operating, and that needs to change.

So that has been absolutely my biggest flaw as a leader, and the biggest problem with freeCodeCamp is that I am terrible at fundraising and I need to get better at it. I would say that, sure, I could just hire some corporate fundraising person to go out and get a bunch of donations and foundations to support us. But we are a grassroots organization. We have more than 5,000 people in the community who every month donate to freeCodeCamp. They donate 5 books a month or 10 bucks a month or 35 bucks a month. We want more of that.

We have more than 40,000 people who've gone through freeCodeCamp that are now working at tech companies. A lot of them are at Apple, or Google, or Amazon, or Microsoft. Some of these big companies with big salaries. I need to figure out a way to remind those people gently like, “Hey, if you can support us, we can help a lot more people here.”

[00:51:48] Jeff: You need an alumni association.

[00:51:50] Quincy: So we have a LinkedIn alumni Association with like 60,000+ people in it. I'm just really bad about admitting that we need money, and I'm bad about asking – I’m bashful about asking for money. That’s one thing I’m working on. That's the biggest bottleneck right now.

[00:52:07] Jeff: These universities are falling apart at the seams. Maybe you can pick up some alumni booster who’s recently laid off. Those alumni associations are always hawking the most ridiculous, like, “Oh! You got a bumper sticker for $150 donation.” Like, “Wow! Okay. That's a great deal. I get to say I was a freeCodeCamp alum if I make $150 donation.” You need somebody like that to give these absurd donation.

I don’t know. Speaking more frankly. I mean, you have people like Swicks who has given $10,000 to freeCodeCamp, and he's fairly new to software development. He’s still making his way into building a career for himself. But he already sees so much value in freeCodeCamp that he's willing to give back. So presumably there will be more people like this, especially as you get like people who make their way into entrepreneurship.

[00:53:15] Quincy: Yeah, I guess we only need like one Bill Gates or one Jeff Bezos to go through freeCodeCamp to potentially be able to support the organization. That said, I mean, Shawn Wang, Swicks, he gave a $10,000 gift to freeCodeCamp a couple of days ago and he tweeted about it last week. He tweeted with this #payitbackwards, and he wrote this nice article about his reasoning for donating to freeCodeCamp, and I encourage everybody to check that out and to just search for the #payitbackwards. The holiday gifts giving season is ramping up and I’m going to go into full fundraising mode and try to get as many small donations as possible from different alumni. But, that's absolutely something that I'm going to do.

I totally see what you mean about grabbing some person from a university, but it's a very different situation.

[00:54:11] Jeff: I was kind of joking. I mean, that wouldn't be good for your brand.

[00:54:13] Quincy: So freeCodeCamp so for, every single person we brought on the team, all seven people who work full-time for freeCodeCamp came up through freeCodeCamp. I've never had to do a job interview for freeCodeCamp, because I've already known exactly who in the community is contributing the most. Whom can we give some additional resources to? Whom can we pay not to work full-time on freeCodeCamp, but to be able to devote themselves full-time to contribute to freeCodeCamp. Those are the people we’ve hired. So if I were able to identify somebody within the freeCodeCamp community who can help me with that, yeah, maybe that’d work.

One issue is because we’re running so lean, where we have maybe a of couple months for the payroll in the bank at any given time. It's hard to take a risk of bringing on somebody to do this role. So I'm trying to learn how to do all these stuff myself from reading a lot of books about it. I've been studying the meta-of fundraising and trying to understand how it all works. Reading all the books about nonprofits, and we’re in kind of a unique situation, like whenever we try to get somebody to sponsor freeCodeCamp, they treat us like we’re some sort of hackathon, or whenever we’re trying to get –

[00:55:23] Jeff: You mean when you try to get a corporation to sponsor you?

[00:55:25] Quincy: Yeah. Whenever we’re trying to get, for example, credits to use, like in-kind donation from a company. A lot of times they’re like, “Oh, is this a hackathon? What is this? What is freeCodeCamp? What’s something like freeCodeCamp?” I have to go on this long explanation of what freeCodeCamp is and why it is the way it is.

There's a lot about freeCodeCamp that sounds unbelievable. I consider that somebody who's inside freeCodeCamp, it seems weird that there is this organization that millions and millions of people use that tens of thousands of people have gotten jobs as a result of using so far, and that the entire thing runs off of the equivalent of like one Silicon Valley engineer’s annual salary.

[00:56:10] Jeff: This is why I actually led off the show with the analogies that failed to do it justice. You’re an aberration. You're not Wikipedia. You're not Mozilla. You’re not Craigslist. You are your own beautiful aberration.

[00:56:29] Quincy: So a lot of this was just communication challenges. How do we communicate what freeCodeCamp is? How do we communicate the scale? So one thing I did this year when I was preparing for our donation raising run was try to figure out how I can boil freeCodeCamp’s sheer capital efficiency, if you will, down to a concrete number.

So I took that 1.1 billion minutes and I divided it by our $373,000 budget, and I came up with 50 hours of instruction provided for every $1 donated.

So this is convenient way, because when people give us $5 dollars a month we can save, “You’re paying for 250 hours of instruction every time you donate. That's enough for a classroom full of people essentially to be able learn to code for free just from your meager donation. If you give more money, it's equal to an entire village.”

So that's kind of my thinking in terms of how I'm planning to go into the holiday season encouraging people to donate, is just quantifying the direct benefit of their donations.

[00:57:43] Jeff: Okay. The $373,000 budget, that's the rough annual budget, right?

[00:57:50] Quincy: That is our exact budget for 2019.

[00:57:54] Jeff: For 2019, like thus far or projected to be the totality?

[00:57:59] Quincy: Almost all of our costs are fixed. So I can project that with pretty good certainty. That's how much it will cost to run freeCodeCamp for the remaining two months, plus the 10 months we’ve already gone through.

[00:58:12] Jeff: The big cost, are they developers or servers?

[00:58:14] Quincy: Both. But in any software organization, people are usually the main cost. We do spend several thousand dollars a month on servers.

[00:58:24] Jeff: I mean, that seems like – The servers at least, it seems like you could just get a company to sponsor you. But then it might almost be like not worth it to deal with the overhang of like are you advertising Azure or like are you in bed with Amazon or something like that.

[00:58:46] Quincy: That's been our philosophy. We’re happy to use in-kind sponsors. Amazon gives nonprofits a certain amount of money every month, or every year. We’re able to get like I think a thousand dollars, maybe $2,000 credit from Amazon, and we use that in one month just on the emails.

I send 2.5 million emails a week for our mailing list. So that very rapidly becomes thousand dollars a month just on sending emails. Using Amazon SES, which is the cheapest email service known to man. It's like you can send 10,000 emails for a dollar. So we quickly burn through all those credits.

Microsoft Azure gives us pretty generous credit as a nonprofit. We burn through that. Even with all those credits, we’re probably going to need to figure out some – We use a lot of other tools. For example, Algolia gives us search, and that means we don't have to run an Elasticsearch server. Algolia is in many ways faster than Elasticsearch and it’s certainly easier to configure.

We’ve got all these in-kind sponsors who help us. I think they help most nonprofits, but it's a big help to us. So I don't want to diminish those in-kind sponsorships, but we don't want to be taking huge checks from large companies for precisely the reason you just said. We don't want to be "freeCodeCamp brought to you by Google."

[01:00:06] Jeff: This is one of the things that like I think one reason I like talking to you is because whereas you are totally uncompromising in your kind of non-conflict of interest relative to corporate sponsors,

I’m very much the opposite. I’m all about sponsored content. My show is riddled with ads. But I guess I I'm at least like transparent about it. Transparent to the degree that like I kind of can be without impacting the quality of the show. But like I feel that in my own behavior at certain times, can I really talk bad about company X when company X is a sponsor? I think it speaks to your long-term vision that you’re uncompromising there.

[01:01:04] Quincy: What you’re working with is a very different model. When you're a donor supported nonprofit – I mean, imagine that you're somebody who's giving to John Hopkins University and you’re like a doctor or a lawyer and you’re like really proud of your $10,000 donation that you just gave to John Hopkins. Then Michael Bloomberg swoops in and gives a $1 billion donation and its 4 or 5 orders of magnitude larger than your donation that to you was a big amount of money. I could just imagine it being really deflating, like saying like, “Oh! Well, should I even bother giving to John Hopkins anymore? I mean, look. They just got all that Michael Bloomberg money.”

So with freeCodeCamp, I'd like to avoid a situation where people feel like their donations don't make a big difference. What’s the point of giving to freeCodeCamp if Bill and Melinda Gates are already giving them plenty of money? For me, personally, I want to give my money when I donate to causes that genuinely need it, where it's going to make a huge impact. I'm not directly practicing effective altruism. I know Haseeb and a lot of people whom you’ve had on the show are practicing – It’s effective altruism.

[01:02:15] Jeff: Effective altruism. Yeah.

[01:02:16] Quincy: That's where you give some percentage of your salary to a nonprofit and you've made a commitment to you're going to distribute, and there are all these organizations that rank charities by their efficiency. freeCodeCamp, we have a platinum transparency rating on GuideStar.org, I think.

But there's like a great organization called Donors Choose, and that's what Haseeb and a lot of other effective altruism people use. That organization basically ranks charities for their efficacy and helps you maximize the amount of impact that each dollar you give is going to have.

Unfortunately, because freeCodeCamp is so new, we don't have the seven years of tax returns necessary to be able to qualify to be on those lists. So that's one thing that eventually will come and save us, I think is because I am comfortable that we’ll be able to make it on those lists.

I'm confident that, as you said you said, we’re going to start having a lot more alumni who are in a position where they can donate a lot of money. freeCodeCamp will eventually be able to have a lot of resources that we can use, like the Red Cross, and like Doctors Without Borders and a lot of these other nonprofits that are doing tons of work and are able to employ a lot of people toward the cause that they've gone after.

So I’m confident freeCodeCamp will get there. It’s just the kind of rocky intermediary period where everything is held together with duct tape that I'm worried about. Now freeCodeCamp, we could in theory lay everybody off. I could lay myself off. I could just go get a job somewhere and pay for the servers, and I do think that me working somewhere, I could probably afford to keep paying the servers and keep freeCodeCamp on life support. Absolute worst case scenario.

So I'm no longer worried that freeCodeCamp will just blink from existence. That's not going to happen. The real question is how much potential to do good in this world are we foregoing by being so undercapitalized. That's what keeps me up at night, the miss-potential.

[01:04:14] Jeff: We won’t go much further on this. But if Bill and Melinda Gates were like, “You know what, Quincy? 2 million bucks a year. You got it.” Would you accept?

[01:04:25] Quincy: I’m not sure. I can't definitively say like we would reject that out of hand because there's the possibility that a lot of our donors would be like, “Oh! You should accept that.”

But if it meant that accepting that money was going to cause our small grassroots donations to go down dramatically, I’d probably turn it down. Because in the long-run, it's a much more robust strategy for an organization like freeCodeCamp to have tens of thousands of stakeholders who are donating every year than to have one or two large foundations that control its destiny.

[01:04:55] Jeff: How has the market for coding education products changed since you started freeCodeCamp?

[01:05:03] Quincy: I think that more and more people have realized that you can get a good job if you learn to code. Things haven't changed enough though. I'm surprised at how little things have changed. If you look at the number of computer science majors in the United States, it hasn't gone up dramatically. It’s gone up a little bit, but not in line with what you would expect.

I am thrilled that there are so many coding boot camps out there that are helping people in their communities learn to code. I'm surprised that there aren’t more. I'm surprised that so many of them have gone out of business, because so many jobs out there are still unfilled that will require coding. Something like 60% of all STEM jobs require programing.

I have plenty of friends who are doing like PhDs in different fields, science, genomics, all these things, and they use programming almost exclusively. That's what they do. They take the datasets and they write scripts to parse those data reliably where they create pipelines to be able to parse data. Anybody who's working with data needs to know how to program, and yet things move so slowly.

That's one thing that’s totally taking me by surprise, is when I started freeCodeCamp, I was so sure that like the government was going to drop tons of money on programming education, or all the money that Google and all these other companies was dropping into education – Facebook, that this was going to make a huge difference and then suddenly there wouldn't be such a huge crunch for developers that they wouldn't be so scarce. That would be good. I think would be great if there could be a million more developers in America, or two or three more million.

[01:06:43] Jeff: There's got to be many more though. I think it's just the indexes aren't capturing it, right?

[01:06:48] Quincy: I'm not sure. I mean, there are definitely more developers. But you have to understand. I’m so caught up in the meta. I'm on Twitter seeing people posting that they just got a new job. This is kind of the tip of the iceberg. There are so many people out there that – And that's the crazy thing when you start thinking about macroeconomics and you start thinking about how there are billions of people around the world working and there millions of people just in the United States working cash registers and retail, things like that.

You start to think about all these people and then you think about the very, very, very tiny proportion of people who know how to code and how these people that know how to code could completely append these industries and make things dramatically more efficient and unlock so much economic potential, and yet it's not happening anywhere near as fast as we want it to.

[01:07:37] Jeff: What do you understand today about coding education that you didn't know at the beginning of freeCodeCamp?

[01:07:43] Quincy: I would say that it’s something that I dramatically underestimated was just the motivational aspect of it. Programming is not intrinsically a hard technical thing. I think there are probably a lot of subjects that are a lot harder to wrap your head around than how to create some basic algorithms and data structures, right?

[01:08:03] Jeff: That is for sure, man.

[01:08:05] Quincy: And yet, it is a very frustrating field to go into, because the entire time you're sitting there with some compiler or with some interpreter telling you you're wrong, you’re wrong, you’re wrong, you’re wrong. You’re getting error messages. You’re getting field tests. Things are not working. You're going and reading stack overflow discussions from 10 years ago and trying to get unstuck constantly. So it takes a lot of grit to learn to code and it takes a lot of grid to stick with it and not just to go out and farm goats or whatever a year or two into your career.

For me, programming is very much a motivational challenge more than anything, and that much has really been driven home as I’ve seen people scrub out of the field so to speak not because they couldn't do it, but because they didn't want to keep doing it. They were like, “Oh! Please give me – Oh! There’s a management job. I don’t have to code anymore. Let me jump to that,” right? So that's one of things we've been working very hard on, is how can we keep people inspired. We’ve got a section on the freeCodeCamp form called You Can Do This, and people when they feel the depth of their frustration, the depths of their despair, they can go there and people cheer them on.

I think all the meet up groups in different cities and all of the different study groups and all these organizations, like Women Who Code like Hack Club. They’re keeping people motivated and pushing forward through the despair and keeping them progressing with their skills so they can gradually acclimate to the strain of being a developer. There's no rule that says you have to eventually quit programming and you have to move into some managerial role, right? There are plenty of people out there who love programming and they've been doing it for decades. So how can we keep people motivated and keep people interested in technology and keep them from burning out?

[01:10:00] Jeff: I could not agree more with what you are saying here. The time when I first crossed paths with you on the Internet was when I was on Quora a lot. Part of the reason I was spending so much time on Quora was because I was really having a lot of trouble in my computer science education in college. I think one of the reasons I was having so much trouble is that conventional University computer science education is not built to inspire. It’s kind of built to reinforce this frustration and this ivory tower sensibility of, “Look, the compiler is telling you you're wrong, because you do not belong here, and you are an idiot.”

I felt this reinforced in the mannerisms of many of my professors, like, “Look, if you can't cut it, if you can't write the unit tests, if you can't get your projects done in two weeks, maybe you should drop out. Maybe this major isn’t for you. Maybe you should go to MIS. Maybe you should go back to business school. Maybe you should get out of here.” They really would take this attitude that like, “Maybe you should take a step down.”

That's not the attitude that an educator should take. The educator should basically take, “Look, what do we need to do to reshape your mind so that you can actually succeed in this field, because it's really not that hard.” Yeah, I mean there was something about Quora. There was something about just Internet culture. The Internet culture has the elements of inspiration that you need – I mean, Seth Godin, somebody who I’m a fan of. I found his podcast around that same time and he's all about basically like give the middle finger to these people who tell you that this is not something that's doable. It is going to take grit, but it's actually not going to take much more than that.

[01:12:06] Quincy: What you described with the university experience that you went through, that’s an unfortunate reality in a lot of universities today. Here in the U.S. and also oversees, there’s this kind of elitism. I'm not sure exactly why it is. It could be just rooted in the fact that university professors are fighting so hard for such scarce positions in academia.

[01:12:29] Jeff: And the math and physics lineage of computer science.

[01:12:33] Quincy: Yeah. But the reality on the ground, it couldn't be more different from that scarcity that those arbiters are trying to reinforce. The reality is there are incredible opportunities, and this is something not just with software engineering, but I think with medicine. Medicine has this almost kind of ritualistic hazing process they put all the physicians through, and medical school is brutal, and [inaudible 01:13:53] is brutal.

[01:13:54] Jeff: I don’t know if I’ve told you this, but I was premed until I took organic chemistry. There was this semester I took organic chemistry. I was like, “Okay. All right. Fine. I got vetted I'm out. Peace.” I would do the exact same thing. Yeah, the weeding processing. Sorry. I’m sorry. Not to take my seat at the couch.

[01:14:13] Quincy: It is really unfortunate that as of late 2018, so much of education is still like this. It’s still some – Almost always a man who has gone, walk through the snow uphill both ways and wants to see to it that you do it too. What does this affect? Well, if you want to look at why the profession is so homogenous, it's because people who can't visualize themselves can't find people who look like them or come from backgrounds like them in the profession. They don't even have that glimmer of hope that you or I might have seeing some guy who looks like our dad, for example, who's in the field and saying, “Well, we can do that too.” They don't even have that.

So there's even less to help empower through this process of weeding. So, yeah. I'm optimistic that if anything, freeCodeCamp can present competition to the University computer science programs and force them to become more inclusive and quit hazing people. freeCodeCamp can essentially, by increasing the quality of what's available for free, force everybody else to up their game .If nothing else, I will be very proud of that contribution to education that we raise the floor.

[01:15:38] Jeff: Do you see a continuation from the education of computer science fundamentals, software engineering best practices, security data science, et cetera, these things? Do you see a continuation from those into perhaps lessons about entrepreneurship? Do you want freeCodeCamp to be a place where you can go full stack from learning to code to building a software company?

[01:16:16] Quincy: So here's my thinking on this, and I realize that this may be contrary to a lot of popular opinion and a lot of wishful thinking about entrepreneurial. I think that before you can be a successful entrepreneur, you should go out and you should work for other people and you should manage other people within an existing organization. Otherwise, you're going to be somewhat naïve and you’re going to have to make a whole lot of mistakes on your own dollar or on your investor’s dollar, and a lot of people are going to suffer from those mistakes who would be somewhat insulated from them if they were in one of these organizations.

So I spent about six years running schools, and that managerial experience was absolutely essential. freeCodeCamp would not exist if I were some fresh college grad who was trying to create a project like this. I think there’s a reason why the median age of a successful entrepreneur is usually in their 40s or 50s, because they've been around. They've worked with an existing system. They understand not only how things are, but why things are the way they are. Thus, they are able to think within those constraints and make slight tweaks to those permutations and make their organization successful.

The key to success is not in bucking convention. It's in knowing which aspects of convention to keep in place in which aspects to discard, that selectivity. So the idea of freeCodeCamp becoming kind of like learn to code and become an entrepreneur I think is probably beyond the scope of freeCodeCamp, because I don't know the that's necessarily possible to do reliably. I do think that people should go out and get jobs. I think that is one thing the freelance, and that's a great way to get a job, but you really should work at a company with a team of software engineers alongside you and a product manager and stakeholders and customers and all those things so you can better understand the entire software development process.

I guess maybe if I’m a little more bearish on entrepreneurialism, it's just I'm cautious. I've seen people go out and destroy their life savings. I’ve seen people go out and destroy their reputations by taking too many risks to quickly. So life is long. Human lifespan ideally should be increasing. I'm almost 40 and I'm hoping to live a hundred, and I’m going to keep learning along this entire process, but I would encourage people who relatively early in their careers to keep working and learn on the side and keep learning as much as they can on somebody else's dime before they go out there and they try to do a risky experiment, because entrepreneurship is one – I think the definition of entrepreneurship is somebody who bears risk and you have to be ready to bear that risk. You have to have savings. You have to have a plan B if things go south. All those things will set you up for success more than just taking an online course and trying to throw yourself into entrepreneurialism, in my opinion.

[01:19:31] Jeff: I want talk about software architecture and software engineering, because you had this – As you said, this post about how what went wrong with freeCodeCamp servers. You also had this recent post about freeCodeCamp at five years. Your software architecture has gotten pretty complicated. You've got a lot going on. You've got serious engineering challenges because you are at scale. I mean, what are you? The 1700th most popular site according to Alexa rankings? Something like that?

[01:20:10] Quincy: I had to look it up, but we are currently 1589th as a recording.

[01:20:18] Jeff: That is indicative of a ton of traffic. The reason there's a ton of traffic is because you have a lot of content. You have a lot of curriculum. I'd like to talk – We don't talk in gratuitous detail about how the curriculum works today, because I think probably a lot of the people listening are students of freeCodeCamp, or people who have seen it before. But let's just talk through like the contours of freeCodeCamp at a high-level, like freeCodeCamp as a product, and the product surface area. Then we can dig into some of the interesting architectural problems that you deal with with a product that is at this scale, at this throughput, and with the small of a budget. So you have all these interesting cost tradeoffs to make as well. So let’s first just talk about the product surface area.

[01:21:13] Quincy: Sure. So freeCodeCamp is really three different core applications. There's the curriculum and portfolios. That's one of the pillars, and that is all custom code for the most part. That's when we say the platform. That’s generally what we’re talking about. We also have freeCodeCamp.org/news, which is our publication, and we publish several articles a day there often in-depth explanatory journalism, biotechnology. Then we have the freeCodeCamp forum, and that's the third pillar of freeCodeCamp.

Now, all three of those run on separate servers. The freeCodeCamp forum is powered by Discourse, which is a really cool self-hosted open source forum tool created by the founder of Stack Overflow, Jeff Atwood and his team. That's very well-maintained, and you can get your own instance of discourse running really easily if you want to. You can just deploy it to the cloud and it will live on its own server in a Docker container, and there you go. Same thing with freeCodeCamp.org/news. That is running on Ghost, which is another self-hosted open source project that just released version 3 of their tool. It's like the WordPress, but it doesn't have a lot of the baggage that comes with WordPress. WordPress is excellent, but it does have some vulnerabilities and it does have a very complicated plug-in system, and WordPress is trying to do a lot of things, whereas Ghost is just trying to be a publication tool.

So we have maybe 7,000 articles on freeCodeCamp.org/news at this point, and we have hundreds of thousands of posts on freeCodeCamp.org/forum. So those are those two. Now, if you want, I can drill into what powers the freeCodeCamp platform, the core curriculum.

[01:23:17] Jeff: Please do.

[01:23:18] Quincy: Yeah. So we are running React on the frontend. We’re running node as the backend. We’re running a tool called Loopback, which is an API tool. It essentially turns your entire app into an API where all the routes can fetch JSON as well as HTML. It's something that’s already baked into tools like Ruby on Rails. With Ruby on Rails, you could take any URL and you can just put .json at the end of it and get a JSON representation of the data and that route. So Loopback does a lot of stuff.

We use MongoDB for our database and we have a managed cluster that’s MLab, and we’re working on moving that over to MongoDB's new Atlas tool. MLab was acquired by MongoDB recently. So they're kind of sunsetting MLab, I think. So we’re in the process of moving everything over. But it's good to have a big sharded system, because we have a lot of data. We've got millions of records, and each of those records has millions of challenge completions and a whole lot of other data that they’ve added to their portfolio.

The portfolios themselves, we’re working on growing them and making them a lot richer in terms of just having a lot more data. You can submit a whole lot of different projects you’ve built from outside of the freeCodeCamp curriculum as well. If you built your own JavaScript game, for example, you could submit that. Turning that more into kind of like a LinkedIn light for developers. So we’re working on that.

The platform itself in terms of the curriculum is a Gatsby app, and you hit that URL, freeCodeCamp.org/learn, and the entire curriculum loads and it stays in your browser, all of it, like thousands of challenges. Then when you complete challenges, it will post those to the server. If you disconnect from the server for some reason, you can keep completing challenges. Then when you reconnect, it will push all that to freeCodeCamp servers. So we’re very close to having it be fully offline functional app, like a progressive web app in that regard. It's not quite there, but we may be just a few months away from that. We’ve been tinkering toward that for the past year.

[01:25:42] Jeff: That is sick. I mean, well the offline functionality, that something that developing countries – I mean, that's a necessary – To have a buttery experience, you need that kind of offline functionality.

[01:25:56] Quincy: What you just said about people in developing countries, freeCodeCamp is founded on a single principle, and that is access. That doesn't just mean accessibility in terms of blind people being of able to use freeCodeCamp. People with motor skill impairments being able to use freeCodeCamp. All those people can use freeCodeCamp. We’ve got a 100 Lighthouse score for accessibility, and we take that into consideration with everything we do.

But also people who have frequently interrupted power, frequently interrupted Internet access. So not only are we trying to build the PWA that addresses all those concerns and not only do we make our data as small as possible so the entire freeCodeCamp curriculum fits in a footprint of just a few megabytes. But we’re also working on eventually getting an android app on, and maybe even an iOS app. Because so many people in India, so many people in Nigeria, other countries where a ton of people use freeCodeCamp, Pakistan, Kenya, places like that, we want to make sure that they are able to use it on their own devices, and people don’t necessarily have laptops.

So we recently just completely overhauled the mobile freeCodeCamp experience, the mobile web version, to make it easier, put everything in a tab so you can move between your code, your tests and your HTML preview your console output. We’re also working to make it to where it runs natively so that you can just download a freeCodeCamp app from the App Store and you’re good. Then when you have Internet connectivity, it pushes all your stuff up and you can still claim the certifications and everything. But we’re moving more and more of that into freeCodeCamp.

For example, right now, most of the projects are built on CodePen, which is awesome. We'd like to make it where all those can be built right on freeCodeCamp so you don't need to go to an external website in order to build your projects. We’re also working with some code that Mozilla has just put out to be able to run Python in the browser too. So we’re going to be teaching data science concepts with Python and we’re going to be teaching TensorFlow, NumPy, Keras, a lot of these libraries in Python as part of our core curriculum.

[01:28:02] Jeff: I think the entirety of the backend architecture is too complex to portray to people over a podcast unfortunately, but it is an interesting backend, and I encourage people to check out your articles, your recent articles about it on freeCodeCamp News. But just to give him a little bit a context for the kinds of problems that you need to work through, can you tell me a particularly difficult engineering problem – I mean not the one that you outlined in your recent post, because you kind of laid that out in gratuitous detail, or maybe if there's details that you didn’t layout. We could go further into that. But I just like to know a particular scalability bottleneck or some kind of difficult backend engineering challenge that is emblematic of the kinds of software engineering problems that freeCodeCamp encounters.

[01:29:00] Quincy: I would say we have of those backend-specific challenges from scale and from the way we’re architectured and things like that. But perhaps more interesting would be the overlap between instructional design and engineering that we've had to navigate. So we very early on decided that we wanted everything to run client-side, like all the tests run client-side. That’s to minimize the amount of latency. It’s also to just minimize variability and things like that. So it's been a real challenge to get a lot of these subjects taught in a fully-interactive client-side tested way.

So some of the early things we had to struggle with, for example, is how are we going to teach, for example, Rest APIs and specifically how are we going to teach Ajax and things like that interactively in the browser. So those are things where we've almost had to tailor the instruction to the medium and the constraints of the medium. So that has been an ongoing challenge, and we’ve just had breakthroughs over the years as to how we could test different things in that. How we could –

So one of the big breakthroughs recently was – I think about a year and a half ago, we decided that the test suites, the projects originally, you didn't have test suites associated with them. You just have to build it and then we would manually review it and other people give you feedback on your projects. But there wasn’t that tight feedback loop of like, “Oh, this project doesn't – This project does exactly what it's supposed to do and it looks the way it does.”

So what we did was we created the this API endpoint you can hit and you can download a test suite right into your project wherever you’re building it. Whether you’re building it locally on your local computer, whether you’re building it on a CodePen, whether you're building it on just like a GitHub pages app that you’re deploying in Netlify or something like that. You can load this test suite and you can run it right against your code. So whenever you submit the URL, you're also certifying that it passes all of these tests. So there’ll be maybe like 15 or 20 different tests in a test suite for these different projects.

freeCodeCamp, if you all don't know, is essentially all projects. We have lessons right now. We’re getting rid of those lessons and we’re replacing them with practice projects where you learn JavaScript by building a role-playing game, for example. You build a fully-functional role-playing game where you’re going like fight a dragon, get a sword, build up your health points and stuff like that. But you build that line by line with JavaScript. That's how you’ll learn JavaScript, is building a role-playing game.

[01:31:39] Jeff: I mean, unless you want to drill deeper into that engineering problem, I kind of want to jump on what you just said, the idea of building a role-playing game rather than having these specific lessons.

[01:31:51] Quincy: Yeah. We always wanted to have fully project oriented learning, and to some extent, the existing freeCodeCamp curriculum, like when you build the first HTML app, you’re building up kind of like a can photo app. But it’s still a series of discrete lessons, right? The new curriculum that we’re building, we’re calling it version 7 of the freeCodeCamp curriculum, is totally projects. So instead of having a series of discrete lessons, instead you’ll just have a giant code editor that will take up almost the entire screen and its Visual Studio code. We’re Monaco, which is the browser version of Visual Studio code.

[01:32:29] Jeff: Oh, sick!

[01:32:30] Quincy: Yeah. So you get all the syntax highlighting. You get all the tab completion, all those functionality, right? You don't have the full IDE experience, but you can pull some of that in. Anyway, what it’s going to be is there’s just going to be a giant code editor and we’re going to split the code editor open and there will be a test inside of that right above where you need to change the code or type a line of code. Them you pass that and, boom! The code editor closes up and then a new rift forms below on the next line, and there's a test. Everything is taught through a series of tests that you have to get past.

So you’ll get hundreds of tests passing. Through the process, you’ll build up this sophisticated application. There’ll be a lot more repetition than there is currently. That's one of the big complaints about the freeCodeCamp curriculum, is that we hit a whole bunch of topics in rapid succession and we don't necessarily revisit them as much until you get to the certification projects. Well, we’re going to try to engineer a lot of repetition in there to help – Even though recall is not nearly as important with software development as recognition is, and in certain fields, recall is everything. That's why the entire U.S education system is basically based around retention, right? You remember all these facts so you can pass this test. With software engineering, everything is only a Google search away.

But we’re still – Because that's how people are trained in pretty much every education system on earth, they’re trained that you have to retain things and you shouldn't – There's a discomfort associated with having a vague remembrance of something, but not having like concrete that you can recall. So we’re almost – It's a concession to how people are or meeting people where they are, as supposed to where I our pure teacher’s minds where they should go. But we are going to incorporate more repetition for that very reason to make people feel comfortable, because that's one of the most common reasons people give when they quit freeCodeCamp. It’s like, “Oh, I didn’t feel like I was learning anything. I didn’t feel like I was retaining anything. I did all these stuff and at the end of the day I couldn't remember the exact syntax of how you make a Boolean declaration in JavaScript or something like that,” right?

So there's going to be a lot more repetition, but you're going to build through a series of just discrete tests every single step, a single test that you have to get passing. Boom! You move on to the next one, and you're going to get into this flow state where every 30 or 40 seconds you’re going to get test passing and you’re moving forward, and hopefully like one sitting you're going to build out an application. So you’ll build – Right now, the entire freeCodeCamp curriculum is 30 projects. By the time we’re done with this version update, it's going to be closer to 100 projects that you’ll build.

[SPONSOR MESSAGE]

[01:35:22] Jeff: Feature flagging makes it easy for your team to quickly change the way that your product works, and CloudBees Rollout lets you manage feature flags easily. When you have a solution to manage feature flags at scale, you’re empowered to continuously and intelligently rollout changes as soon as they are code complete on any platform, even mobile. You can decouple development from code release for a real-time change control. You can rollback only the changes that you don’t want, or keep them around.

You can toggle features. You can use multi-varied flags for A-B testing and you can remove misbehaving features with a kill switch. All of these is part of the feature flag platform that is CloudBeess Rollout.

Visit softwareengineeringdaily.com/cloudbees and try a free 14-day trial and experience how CloudBees Rollout can help you with every release. Visit softwareengineeringdaily.com/cloudbees to get a free trial. Cloudbees Rollout is trusted by large users, such as Zendesk and Jet.com. Try it out today at softwareengineeringdaily.com/cloudbees.

[INTERVIEW CONTINUED]

[01:36:46] Jeff: It's interesting that the move from having – Like I can imagine the initial lesson plan for freeCodeCamping, like, “Okay. First you do Hello World. Then you figure out how to parse JSON. Then you figure out a two string method or something.” The kind of like boring boilerplate stuff. I think what I'm hearing is you’re finding that the boring boilerplate material can be exhaust. That can be a side effect of starting with something that is exciting and fun to do, and perhaps adding a little bit of repetition, a little bit of a slower pace, but focusing completely on the project orientation, because that is more fun and that the motivation is so important there, and you will be able to get the boring boilerplate stuff just as an additive outcome from the project-centric focus. Am I understanding that correctly?

[01:38:06] Quincy: Exactly. My economics teacher when I was in grad school, he sat me down during one of our office hour session and he grabbed a book off his shelf and he started just – He laid it on the desk and he started flipping through it and there was just a bunch of equations. He said, “This is my economics PhD. This hundred-page book has all the equations that we use for my economics PhD. I spent six years after undergraduate learning this stuff, and it all fits in a 100-page book.”

But that is just the raw facts, right? That completely disregards the human element of how we grapple with learning, how we retain, how we internalize those lessons, right? People don’t sit down and start memorizing equations. That’s not how humans work. That's how computers work. Computers are very good at retaining facts perfectly. Humans don’t work that way. Humans learn through experiences. So a lot of our journey with freeCodeCamp toward watching how millions of people interact, watching who decided to keep going, who makes it at the end. What powers them through? What kind of projects they build? How their projects are different from people who stop halfway through? All that has been kind of crystallized in this pure project-oriented orientation the we’re taking now with the big update to the freeCodeCamp curriculum coming in 2020.

[01:39:38] Jeff: Do you try to like test it? Do you throw it at new users in kind of a slow onboarding fashion, or do you have enough faith that this is the direction to move towards such that you don't feel like you need to kind of do an AB testing and gradual shift of the curriculum?

[01:39:59] Quincy: AB testing is really good for something, right? It’s really good for determining like what color of a button is going to get people to convert in your shopping cart, right? It’s less good for something where you’re trying to walk somebody through a very complex experience.

I have no doubt that when people say there's more of an art than a science to something. They don't yet know the sites of it. I have no doubt that there is probably some very good way to AB test and to arrive at a totally optimal solution, but I do doubt that we’ll be able to do that in a time effective manner. So to some extent, yeah, we’re just throwing this together, our best guess, and then we’re going to put it up and there we’re to see how people react with it. We have really granular data. We know exactly how many seconds on average people spend on a specific challenge within the freeCodeCamp curriculum. That's how we've identified a lot of the bottlenecks.

My philosophy has been people shouldn't spend more than two minutes on a given lesson and they should be able to figure out how to do it from the instructions and from the test messages, and they should be able to progress. So we find those outliers and we’re able to go in and tweak the wording or maybe break it out into several lessons in order to make it easier for people to get through.

With these with these new projects, we’ll be able to do the same thin. We’ll be able to identify which tests out of the 200 or 300 tests associated with building this project is the stumbling block and smooth that out. As far as rolling out all the projects at once, a lot of it is not so much a teaching issue as it is a communicating issue. How do you communicate to the millions of people who are using the freeCodeCamp curriculum that, “Hey! This is changing. You’re not going to have individualists lessons.” Now you’re going to build projects,” and trying to do that in a piecemeal fashion where you’re like communicating to one person, “Okay. These lessons went away, but now we’ve got this project.” It’s just a lot easier in our experience to rip the proverbial Band-Aid off than it is to slowly inch it off.”

That’s been our approach, is generally we observe. We figure out what we think the next step is and then we work really hard and then we ship that next step. It is to, some extent, in conflict with like Agile software methodologies and a lot of other findings that I think work really well for other types of products. But for our curriculum, it's better to proceed in bounds than baby steps.

[01:42:29] Jeff: The people who are writing the code for freeCodeCamp, what's the balance or the portion of time spent and difficult problem solved between – Because it's open source. What's the distribution between people who are paid employees versus open source philanthropic contributors?

[01:42:59] Quincy: freeCodeCamp’s team is seven people. I can go and list them real quick for your benefit. So that’s me. I work full-time. Beau Carnes. He runs our YouTube channel. He does a lot of instructional design. He's been working as a teacher for the past five years.

[01:43:13] Jeff: By the way, instructional design, you mean developing and creating curriculums?

[01:43:16] Quincy: Yes. Instructional design is basically teaching at scale. That's how I define it. Baking the teaching into the materials. He’s an experienced classroom teacher. He was teaching middle school for the past five years and he had worked as a software engineer for a while as well. He'd been contributing to freeCodeCamp for years, and then we were able to bring him on full-time.

Then Mrugesh Mohapatra. He’s in Pune, India, and he is doing a lot of our major architectural decisions. He has worked at a bunch of different multinationals in India and has a traditional software engineering background, but he’d been contributing to freeCodeCamp for like three years before he came on.

Ahmed Abdolsaheb is based in Turkey. He is a designer and a developer, and he had also been working with the freeCodeCamp curriculum and contributing to freeCodeCamp for years before we brought him on. He does a lot of the design work. You will notice that freeCodeCamp has a fresh coat of paint when you go there. We have redone the design style guide and we’ve adapted a cell I’d to call Command Line Chic, which is heavily modeled after kind of almost retro competing aesthetics with contemporary accessibility sensibilities. So he does that.

So that almost rounds up our development team, but we also have Kris Koishigawa who's in South Korea, and he is a developer who work as an English teacher in Korea for the past six years. He contributing to the freeCodeCamp cocaine curriculum extensively, especially the interview practice preparation sections, writing test for like the Project Euler problems and Rosetta Code problems and things like that. He did that for a few years and now he's working full time with freeCodeCamp.

Kris and Beau are primarily focused now on curriculum development. Again, both of them have strong teaching backgrounds and both of them are able to contribute to the codebase, but that's primarily what they're doing. Then not working so much on the codebase, but working on the content side of things. Abbey, Abigail Rennemeyer. She’s out in Portland and she is the primary editor for the freeCodeCamp publication, freeCodeCamp.org/news. She edits virtually every article that gets published there, thousands of articles a year. She also writes and she runs the podcast, and she also runs all of our social media.

Then Miya Liu is based in Hangzhou and in Chengdu in China, and she runs the freeCodeCamp Chinese community. The freeCodeCamp Chinese community is almost kind of like a parallel freeCodeCamp. We have hundreds and thousands of people who use freeCodeCamp over there, and we have tons of major communities and major cities where people get together and come together. So that’s a big part of freeCodeCamp is what Miya is doing over in China. So that rounds up the entire team.

Now, in addition to them, we have dozens of monthly active code contributors who are contributing code directly to the freeCodeCamp platform. Some of them are also making incremental tweaks to the curriculum. Then we have a ton of contributors who are contributing to the publication. We have contributors who are contributing to freeCodeCamp’s YouTube channel. freeCodeCamp’s YouTube channel is now the biggest programming channel on YouTube, other than the New Boston, which kind of shut down four years ago. It still has more subscribers than we do, but freeCodeCamp YouTube channel has kind of taken on a life of its own and its getting like 500 million minutes of watch time a year.

[01:47:03] Jeff: So managing the open source project though, is there a much open source contribution? Because like there are a lot open source projects where like MongoDB, for example, like most of the contributions to MongoDB as I understand our from the company. There’s nothing wrong with that. Open source is kind of like – It’s just like a side feature of a lot of software products. It’s a gesture? Open sourcing your software is a gesture, but it's not necessarily like open sourcing your software means you’re Linux or Bitcoin and there's going to be like this tidal wave of people who are friendly contributors just dropping in and solving bugs that take them hours to dig through lines of code.

It's more like maybe you have somebody like maintaining the SSL library that's holding the Internet together, of you have like a person and a half that are keeping those libraries together. But it's really not like this avalanche of people that are just generously contributing. So it sounds to me like you're more like the kind of the MongoDB school of things where it’s like –

[01:48:19] Quincy: I would argue that we are much more the opposite. Most of the contributions do come from the community. A lot of the big work is done internally just because there's less communication overhead and we can be more –

[01:48:35] Jeff: It’s like big, heavy re-platforming work. The stuff that really takes like the deep work.

[01:48:40] Quincy: Yeah. Then we do occasionally have open source contributors who do significant deep work too. Just to give you some numbers, since I pulled it while you’re talking. Just in the past week, October 22nd through the 29th, we've had 66 proposed pull requests. We merged 27 of them. Most of those have come from outside of the freeCodeCamp full-time staff. Same thing with lots of issues. There have been a total of 1,458 additions and 624 deletions to the codebase in the past week. If I look at the contributions, I can see that only about eight of those were from people working full-time out of the 30 commits pushed so far this week.

[01:49:24] Jeff: Okay. Interesting. One thing, as you're talking about all these different areas of the freeCodeCamp brand, you got not just the full curriculum that is an amazing product of its own. You’re a media company. You've developed both a deep vertical expertise and teaching people to code, and a horizontal expansion that has been so well-executed that you have basically the biggest programming channel on YouTube. You have super active forums and content and chat rooms. I think your Slack channel was – I think you broke Slack, right? You literally like break the Slack free plan or something.

[01:50:16] Quincy: So we discovered a limitation within their infrastructure, that they can only have a certain number of people, and it was undocumented limitation. We hit it, and we had to quickly switch from their platform to Gitter, which didn't have that limitation. We still use Gitter. We still have contributors there, but we've shifted a lot of it over to the forum now.

The forum is great, because for every one person who's logged in, like writing answers to other people's question, there are 19 or 20 people who are just jumping in and from Google who are reading that exchange and benefiting from it.

[01:50:50] Jeff: That is sick.

[01:50:51] Quincy: Yeah, it's great. We’re helping a lot of – When you go to the freeCodeCamp forum and you hang out there and you help answer people's questions, or when you ask a question, you're not just helping yourself. You’re not just helping that person whom you're talking to. You’re helping dozens of people. In some cases, some of these forum threads have had hundreds of thousands of views.

Yeah, you never know what problem that you're experiencing personally could be something that a whole lot of people are experiencing. By having that exchange right out there in the open in a way that’s really easily indexed by Google, we are able to help a lot of people indirectly that way.

[01:51:25] Jeff: Let me ask you a question, because we both come from Quora. We both have deep affinity for Quora, and I feel almost like a debt of gratitude to Quora. That's how much I love that platform. But I almost wish that the software to build Quora was open source. I wish that so many things and that platform could just be like subset it out into their own products and turned into like highly verticalized things, because now the product is kind of – It’s sprawling, and I wish it was more – I don’t know. I wish it was like the old days, which is what everybody says about every Internet product that they used to love.

Wouldn't it be cool if you had your own like – Instead of – Discourse sounds great. But it would be better if it was Quora, right?

[01:52:22] Quincy: It's not really a fair comparison, because the guy who founded Quora, Adam D'Angelo, he is the closest thing to a software engineering genius that I know of before he created Quora and took hundreds of millions of dollars of his own money and funded it. He was the CTO at Facebook, and he just had so many incredible insights that I think we’re missing from Stack Overflow, and is certainly missing from Yahoo Answers and other sites that he was competing with. That platform is just remarkably well-built and well-thought out and it works amazing.

So I have nothing but good things to say about the way Quora is built. I think it would be a very tall order for a team even with the head of Stack Overflow helming it to create something as refined as Quora. That said, the spirit of Quora, which is asking and answering questions and all that, that can work on any platform if you have the community of thoughtful people who are willing to turn around and show their expertise and their insights with one another.

So the tools themselves – You could give Quora, like you could take the existing codebase and give that to kind of a community that's marginally active and they wouldn’t necessarily be able to do that much with it. But you can give PHPBB or some really old form tool to a vibrant community of people who are really passionate about something and they would build up a huge, huge ecosystem of questions and answers and people helping one another and come up with these great forum admins and forum moderators and all that stuff. That stuff would just organically bloom.

So if anything, if freeCodeCamp has succeeded, I would say like the forum, the reason it’s succeeding is because we have that community, we have these super passionate moderators and people who genuinely love helping other people that have come at it. That's why Quora has been such a huge success too, and that's why you and I were out there, because we both felt a big affinity for one another and for other people who were interested in software engineering and we enjoyed answering their questions there.

[01:54:35] Jeff: Do you ever feel like the sprawl of things that you are doing with freeCodeCamp, does it ever feel like some of it is a distraction? Maybe if you're time and dollars and focus was reallocated exclusively to the curriculum, you would be having measurably better output?

[01:55:00] Quincy: So there are diminishing returns to what you can get from focusing on different areas. I would argue that the publication and the forum and the curriculum, they are complementary to one another and they buttress one another. The publication is a way of keeping people engaged when they don't have a keyboard handy. They are just eating lunch and they just need to be able to swipe through something and read something on their phone. They're not ready to dive into a deep in-depth coding session.

The forum is there to help people who encounter problems or have questions while they're working through the curriculum. On every page of the critical, there’s a button that you can press that opens up a pre-populated form post with the current state of your code and everything in it and it makes it very easy to ask a question. So they complement one another.

Now, things that don't necessarily complement one another that we've pursued nonetheless, I would argue, would be Code Radio. freeCodeCamp has a radio station, an Internet radio station. If you go to coderadio.freeCodeCamp.org, you can listen to 24/7 music. That came out of an experiment I did on YouTube where I decided like, “Hey, let's create music that we'd like to listen to while we’re coding.”

We had this music producer from Los Angeles named Lawrence Yeo and he decided to help curate a big-play list of thousand – I think 1500-ish tracks of hip-hop beats, and we put those together and it was really successful. We’d have tons of people watching on YouTube.

Now, there was some anime clip, and one of the songs it was like a, “Haya,” or something from anime, some Japanese company that had – It was a media holding company. They probably just bought some random anime series back in the 80s and were like using their blanket copyright detection tool. They flagged it and YouTube immediately shut down the channel.

So we get to move it. So we’ve moved it over. We found a really awesome open source Internet radio tool called AzuraCast, and we were able to within about 48 hours get the music back up. So that's something that like we don't need a radio station, right? Coding community doesn't need its own hip-hop beats radio station, but it's really nice and it didn't take that much work. It's not a whole lot of maintenance work. We’re getting ready to launch a classical version where we just play orchestral music. So people can just put on their headphones and listen to some Bach or some Vivaldi.

We’re going to have a lot of people listening to that too, but that's one of the things that people use a lot. At any given time, we might have 200, 300 people concurrently listening to Code Radio. So it's something that doesn't take a whole lot of effort, but it’s used by a lot of people. So when we see opportunities like that, yeah, we can do that. I don't think is a huge distraction.

Elon musk runs Tesla and he runs SpaceX and he runs Solar City and he runs like the whole Hyperloop thing, right? It's difficult to see the synergies in all those, but he might be able to rattle off some synergies. What I think we’re doing is dramatically more conservative than what he is doing. Not that that’s necessarily the best example, but –

[01:58:17] Jeff: Yeah, I think you forgot the brain company. Yeah, I think you forgot the brain company and the tunnel company. There's a lot of stuff. I actually think this is one way in which the strong narrative of the financing of software companies has maybe been to the detriment of software innovation in some ways.

I’m generally a big fan of the financing and the capital structures that have enabled software companies to flourish, but one thing that I think might be a little bit outdated is the notion of rigid focus even on company – Even in companies that are like super early, like I get it, that like relentless focus can be really good for developing that first product market fit and whatnot.

But I also think that like this one thing I loved about Amazon, was it was just like you want to start some half-baked Amazon product, like go do it. You’re there. You’ve got access to these resources. You’ve got access to people with like crazy ideas. You want to go start like a grocery thing, or like some weird storage unit products. You can probably marshal the resources if you put your mind to it.

I think like if you're in your position when you're running freeCodeCamp, again, if you're trying to be inspirational, one way to be inspirational is like cultivate a sense of like we say yes to things. Should freeCodeCamp have a radio station? Why not? It doesn't cost us anything. Ting the community likes it. It makes people feel good. Yeah, why not? Then when you have that attitude of just like saying yes to kind of random stuff, you open the door to innovation, because people start to feel comfortable like, “Okay. I can express my creative ideas. Many of my creative ideas do not have a financial outcome.” They do not have an outcome of helping people learn to code faster, but we've got this quirky community. Yeah, why not spend do you know .001% of the budget or the time budget just making things a little bit more musical?

[02:00:37] Quincy: Yeah, and we think other experiments too because precisely of what you said. It makes the community seem more fun and more adventurous. You’re just taking low stakes bets. I mean, worst-case scenario with the Internet radio station would've been a few hours of time. Maybe dozens of hours, or hundreds of hours spent in the wrong direction. But that kind of experimentation can lead to big successes. I'd say Code Radio has been up a big success. It’s been a thousand fold return on initial effort in terms of people benefiting from it. If you took the time that’s been spent on Code Radio versus the time people spent enjoying the jolts of Code Radio.

Programmer playing cards is another thing that we did. So we went through – And I'm a big history buff, and I love learning the technology history especially. I went through and came up with a list of all a bunch of people who I thought were really inspiring programmers and we printed these playing cards. So every playing card has a different famous developer from history. I mean, aside from [inaudible 02:01:43], all the people are from the 20th century. Some of them were born in the 20th century and became famous in the 21st century. For example, like DHH, the creator Ruby on Rails, or Satoshi Nakamoto, people like that.

But it’s a great way for you to be playing cards, playing poker, playing whatever traditional card-based game you want to play. While you're sitting there waiting for someone to decide if they want to call your bluff, you can be reading the accomplishments of, for example, Linus Torvalds, or some of the more contemporary developers. So it's just a little thing that we did that we thought would be fun and we were able to do it and it was profitable in the sense that I think we spent several thousand dollar doing the design work and getting the cards printed and it paid for itself.

Now, wasn't like some huge smash profit center for freeCodeCamp, but it was a cool thing to do for the community and a lot of people took pictures and we go to events and people have programmer playing cards, and it's a cool thing. It’s a cool instructional tool. So freeCodeCamp doesn't shy from doing those things even though we’re fairly limited with resources. If we think that it's a small bet that has a large potential payoff.

[02:02:59] Jeff: You have a family and you run an extremely successful web platform with very few full-time staff that you can delegate stuff to. You get a shoestring budget. I don't want this to turn into a lifestyle advice podcast. But I do know that there are an increasing number of people who work in a similar fashion to you. I think I am one of them. I don't have a family, but I run my own weird business, that I have one person I work with full-time, Erika, and it's awesome to have some teamwork.

But, generally, it's kind of a lonely – I don’t want to say lonely, but there’s like Indie Hackers and there's like advice books and stuff, but this kind of business is weird and there's a growing number of people who are managing this kind of business, or working it, even just working as a contractor these days, like an online digital nomad contractor juggling two different jobs and then working on your own side projects. It's a very 21st-century existence.

Give me some subtle tips about how to manage this kind of work.

[02:04:23] Quincy: Well, I spent a lot of time talking to people through my computer, mostly through email, sometimes through Google Hangouts calls. I do a few of those every day. I don't really see many people in-person. I have friends that I talk to periodically, but it's rare that I meet up with them, like maybe once a month would be like, “Hey, I’m going to hang out with friend and we’re going to play a board game together or we’re going to go to the gym together,” right? Most of it is pretty solitary, but that's good for me, because I just like to read and I like to just go for runs and think.

A big chunk of my life is just me sitting there and thinking or me walking with my kid on my shoulders walking down the street, taking them to the parker or taking my daughter to school in the morning. It just gives me a nice rhythm to life to think, and I've got a very regimented routine. I always wake up the exact same time. I always go to sleep at the same time. I generally eat just a few meals over and over. So there's not a lot of variety, but that monotony that I built up, that routine, provides a very nice framework for me to explore individual things that I’m interested in without the distraction of having to make a lot of decisions throughout the day. I wear almost exactly the same clothes every day.

Just those little pieces of routine keep me on board. As soon as I have to get on the plane and fly somewhere, it is extremely disruptive. Probably more for me than for a lot of people, because I don't have that family. I don't have that routine to a whole new place. But that’s just me personally. I really enjoy it. I enjoy, “Okay. I've got this block of time at the end of the day. Do I want to watch an episode of The Expanse, or do I want to go for a long walk and listen to this audiobook? Do I just want to spend it –

[02:06:18] Jeff: Audiobook?

[02:06:18] Quincy: Yeah, or podcasts. That's one thing that I do to keep myself company, is I listen to a huge volume of audiobooks. Every day I listen to like The Economist podcast. I listen to the New York Times podcasts, the Washington Post Podcasts, like all the daily news podcasts just to keep on top of the world events and things like that. Then I listen to, for example, your podcast. I listen to you probably several times a week. I listen to Indie Hackers. I listen the freeCodeCamp Podcast, which increasingly is hosted by Abby. I’ll listen to my episodes too just to see how I performed on them and kind of evaluate how good I wasn't of asking questions, things like that.

But I just take a ton of information in my information diet. I don't have any apps on my phone. I just use my browser. I use like Firefox Quantum, or Firefox – It’s the one that isn't completely privacy-focused and I can just – I just spend a lot of time like Wikipedia, or I spend a lot of time like just Googling different things.

[02:07:16] Jeff: Wait. So you don’t have Audible or a podcast app on your phone?

[02:07:20] Quincy: So I have the built-in apps that came with the iPhone. So I do have the podcast. I just use the stock Apple podcasts app.

[02:07:26] Jeff: And for audiobooks?

[02:07:28] Quincy: For audiobooks I use Libby, which is like the library system.

[02:07:32] Jeff: Really?

[02:07:34] Quincy: Depending on which city you live, you may be able to use one of many different library apps, and basically you just check out the virtual good, if you will. There's like this for scarcity, this artificial scarcity. But like I have a whole bunch of audiobooks that I have on hold. So as soon as somebody else returns them, I can listen to them, right? But it’s clean, because I try to save money. That's one thing that we didn’t really get into, but the reason why freeCodeCamp able to grow as much as it did despite the fact that it took us two years to get tax-exempt status. Almost three years. It took us a whole lot of time before we could actually start asking for donations, things like that. I spent more than $150,000 of my own money keeping freeCodeCamp afloat during the first few years.

The reason I even had that money to begin with was because my wife and I are like compulsive savers and we were saving to buy a house, and it’s just pretty much every decision is made to minimize the amount of money. That's just a holder for me spending a lot of time overseas in China. I saw how frugally people are living, and I thought like, “Wow! That $60 that I was going to spend on my videogame, that somebody's – That's how they survive for the entire month.”

I met tons of people who were living off of $5, $10 a day and interacting with them and they were going to school. I met people who were going to go work at the state-owned enterprise, government banks and stuff like that and they were just carrying their thermos filled with tea and eating there home- prepared buns for lunch and just being extremely economical. I took a lot of inspiration in that. So I just try to save as much money as possible.

One of my favorite restaurants – This is going to make me sound like a crazy person, but I just go to Sam's Club, and they've got this hotdog-drink combination for like $1.50. Then I’ll get like a pretzel, and my entire lunch is like $2.50. I could sit down. They’ve got good Wi-Fi and I could just eat a hotdog and eat a pretzel and drink a diet drink and work. It costs almost nothing, right? Those little opportunities to save money, those do matter when you’re working as a teacher and you’re trying to accumulate enough money to buy a house, or as it turns out, finance an NGO.

[02:09:50] Jeff: Man, there’s a lot a lot in there that we could dig into further. I really wish you were in town so we could go running more often. I miss running with you. Like you, much of my mental processing and like preparation for shows really occurs when I'm like running outside, because you’re running outside and you’re seeing people, and you're seeing restaurants, and you’re seeing the world develop. You’re feeling the temperature changes. You're feeling the passage of time.

Every year, you feel technology, like calcifying it, some kind of essence in that passage of time. You feel the technology. You see more people on your runs interacting with technology in different ways, “Oh! There’s more people with AirPods, and look at how that – Look at how my dad uses a smartphone.” I love running as a daily routine of interacting with the world, of engaging with my surroundings. I jot down a lot of notes when I'm running, and it's all the better when I'm running with somebody else.

I actually started doing this. Maybe we could do this sometime, this thing called virtual runs. A term I coined, where basically like you just put on Bluetooth headphones and put your smartphone in a fanny pack, pack unless you're like a cool person with a smartwatch who doesn't need a fanny pack for their smartphone. But you can just run with like headphones in and you can have a virtual run, and it's like you're running with Quincy Larson, but you're just talking to him, and perhaps he's running, or perhaps he's washing dishes. This is what will supplant the podcast, is my theory, the virtual run, the interactive podcast. Anyway, I really miss hanging out with you, man, but we never did that often, but it was fun.

[02:11:47] Quincy: Yeah, now that I have kids, I never hang out with anybody very often other than my kids. Having kids is a pretty major life change.

[02:11:55] Jeff: Totally fair. Totally fair. Not trying to guilt trip you or anything. Just we had some great – I mean, we haven't even gotten to get into politics in this conversation.

[02:12:06] Quincy: Probably for the better.

[02:12:08] Jeff: Probably for the better. Okay, just one or two questions. How's the world going to change with broadly accessible online coding education?

[02:12:20] Quincy: First of all, I'm optimistic that it will mean fewer people going into debt to pay for their college education. I would not encourage anyone to go into debt even to attend like a fairly prestigious university. I’d really encourage them to go to Community College. If they have the resources, sure, go to a really solid-state school right off the bat. But see if you can save some money by going to Community College and transfer in to a better, like a bigger state school. See if you can figure out ways where you can be working while you're going to school, doing like an internship.

A lot of software development internships pay really well. You can potentially pay for your rent and your school with a good internship. So I'm optimistic that freeCodeCamp can provide a way that people can set themselves up to get these internships while they’re still in school. I'm also optimistic that a lot of fewer people will need to quit their job in order to transition into a new field. Certainly, more technical fields, like software engineering.

So on a whole, I think it will save people a lot of money and it will also give more flexibility, and that's what it's all about at the end of the day, is saving people from having to make a bunch of lifestyle compromises in order to be able to go ahead and be gainfully employed.

[02:13:33] Jeff: Describe the software engineering media landscape as you see it.

[02:13:38] Quincy: Sure. There are some awesome technical journals that are inaccessible for a lot of people. They just assume you know a whole lot of stuff. If you're tenacious, you can read them and you could just constantly open up Wikipedia or you can open up your dictionary or whatever tool and look up terms as they come out of the text at you while you're trying to read these papers. There are also a lot of great blogs that discuss a lot of technological developments. There are open platforms where pretty much anybody can publish articles, like dev.to, and Hash Note, and Hacker Noon.

Then there are tech publications, some of which are now paywalled increasingly, like I was looking at Wired Magazine and a bunch of other ones yesterday and I noticed that most of them have up a paywall at some point. Maybe they’ll let you see a few articles and then you’re hitting a paywall. So those are becoming less open, which is unfortunate, but I can understand that it costs a lot of money to have a newsroom and run those.

Then there is freeCodeCamp, which is kind of a hybrid between a traditional tech publication and a blog, and we edit everything that gets published on our publication. We are very selective about whom we let be an author. Generally, 1 in 15 people who apply will get authorship. Then they’ll be able to write articles and we edit those articles and we publicize those through our social media and also through my email blasts and LinkedIn groups, or our LinkedIn alumni association, a lot of places.

So it's common for people to publish articles and get tens of thousands of views on them. Not every article does that well, but a lot of them do. If you spend a lot of time writing an article, we’re going to heavily publicize it. Not just right after it gets published, but we continue to publicize things for months and years after they’ve been published if they’re still relevant and if they’re kind of more explanatory journalism that explains fundamental concepts.

Just to backup. I would say there are open platforms where anybody can publish anything about technology. There are technical blogs run by individuals. There are publications, like Wired, The Verge. Then there are sites like freeCodeCamp that are publications.

[02:16:07] Jeff: Last question. If you weren’t working on freeCodeCamp, what would you be building?

[02:16:14] Quincy: I'm not sure. It will probably just be another technology education tool. There's a possibility that I’d be doing English language education. I think English language education is vital and it's a market that is relatively inefficient in my humble opinion. It's a massive market. freeCodeCamp may very well eventually teach English, which sounds like a huge departure from what we do. But I think it goes hand-in-hand with helping people get 21st century jobs.

English is now the language of business. It's the language of science, and increasingly it's kind of becoming the language of culture. Now, there are certainly a lot of other languages that are used in culture, Japanese animation and Korean in pop music and things like that. But I think that English is still kind of the standout. If you wanted to make a movie or if you wanted to make an album or if you wanted to write a book and have a wide audience, English would be the natural choice. So I would probably – If I wasn't doing technology education, create some sort of project to run English language education.

[02:17:22] Jeff: Quincy, any closing thoughts about what you'd like the listeners to hear?

[02:17:27] Quincy: Well, I said earlier that I'm really bad about getting people to donate to freeCodeCam. So my closing statement would be if you’re listening to this and if you've gotten some value out of freeCodeCamp over the years and if you’ve listened this far into this interview, thanks for listening to me, and in Jeff's excellent questions. I would encourage you to consider donating to freeCodeCamp. You can set up a $5 dollar a month recurring donation, and that is hugely valuable to us, because it gives us the ability the project what are our budget is going to be.

Monthly recurring donations are by far the best. But if you just want to give a large lump sum, like Shawn Wang did or some of these other graduates from freeCodeCamp have been doing, we would welcome that too. You can use the @payitbackwards, and a lot of people will see that, and I’ll almost certainly re-tweet it as well.

So we would very much appreciate your support. freeCodeCamp can efficiently deploy three or four times as much capital as we have currently. I am confident that we could continue to be just as effective delivering 50 hours or more learning to people around the world per dollar. We can continue to scale up. We’re still very early days.

[02:18:35] Jeff: Quincy Larson, thank you so much for your generous expansive time.

[02:18:42] Quincy: Thank you so much for coming up with these thoughtful questions, Jeff. It’s been great talking to you.

By understanding these, you will be better-prepared for your upcoming technical interviews.

What is an inner join in SQL?

This is the default type of join if no join is specified. It returns all rows in which there is at least one match in both tables.

SELECT * FROM A x JOIN B y ON y.aId = x.Id

What is a left join in SQL?

A left join returns all rows from the left table, and the matched rows from the right table. Rows in the left table will be returned even if there was no match in the right table. The rows from the left table with no match in the right table will have null for right table values.

SELECT * FROM A x LEFT JOIN B y ON y.aId = x.Id

What is a right join in SQL?

A right join returns all rows from the right table, and the matched rows from the left table. Opposite of a left join, this will return all rows from the right table even where there is no match in the left table. Rows in the right table that have no match in the left table will have null values for left table columns.

SELECT * FROM A x RIGHT JOIN B y ON y.aId = x.Id

What is a full join in SQL?

A full join returns all rows for which there is a match in either of the tables. So if there are rows in the left table that do not have matches in the right table, those will be included. As well as if there are rows in the right table that do not have matches in the left table, those will be included.

SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID=Orders.CustomerID
ORDER BY Customers.CustomerName

What is the result of the following command?

  DROP VIEW view_name

Here it’ll be an error because we can’t perform a DML operation on a view.

Can we perform a rollback after using ALTER command?

No, because ALTER is a DDL command and Oracle server performs an automatic COMMIT when the DDL statements are executed.

Which is the only constraint that enforces rules at column level?

NOT NULL is the only constraint that works at the column level.

What are the pseudocolumns in SQL? Give some examples?

A pseudocolumn is a function which returns a system generated value. The reason it is known as so because a pseudocolumn is an Oracle assigned value used in the same context as an Oracle database column but not stored on disk.

    ROWNUM, ROWID, USER, CURRVAL, NEXTVAL etc.

Create a user my723acct with password kmd26pt. Use the user data and temporary data tablespaces provided by PO8 and provide to this user 10M of storage space in user data and 5M of storage space in temporary_data.

    CREATE USER my723acct IDENTIFIED BY kmd26pt
    DEFAULT TABLESPACE user_data
    TEMPORARY TABLESPACE temporary_data
    QUOTA 10M on user_data QUOTA 5M on temporary_data

Create the role role tables and_views.

    CREATE ROLE role_tables_and_views

Grant to the role of the previous question the privileges to connect to the database and the privileges to create tables and views.

The privilege to connect to the database is CREATE SESSION The privilege to create table is CREATE TABLE The privilege to create view is CREATE VIEW

    GRANT Create session, create table, create view TO role_tables_and_views

Grant the previous role in the question to the users anny and rita

    GRANT role_tables_and_views TO anny, rita

Create a user my723acct with password kmd26pt. Use the user data and temporary data tablespaces provided by PO8 and provide to this user 10M of storage space in user data and 5M of storage space in temporary_data.

    CREATE USER my723acct IDENTIFIED BY kmd26pt
    DEFAULT TABLESPACE user_data
    TEMPORARY TABLESPACE temporary_data
    QUOTA 10M on user_data QUOTA 5M on temporary_data

Create the role role tables and_views.

    CREATE ROLE role_tables_and_views

Grant to the role of the previous question the privileges to connect to the database and the privileges to create tables and views.

The privilege to connect to the database is CREATE SESSION The privilege to create table is CREATE TABLE The privilege to create view is CREATE VIEW

    GRANT Create session, create table, create view TO role_tables_and_views

Grant the previous role in the question to the users anny and rita.

    GRANT role_tables_and_views TO anny, rita

Write a command to change the password of the user rita from abcd to dfgh.

    ALTER USER rita IDENTIFIED BY dfgh

The users rita and anny do not have SELECT privileges on the table INVENTORY that was created by SCOTT. Write a command to allow SCOTT to grant the users SELECT priviliges on these tables.

    GRANT select ON inventory TO rita, anny

User rita has been transferred and no longer needs the privilege that was granted to her through the role role tables and_views. Write a command to remove her from her previous given privileges except that she still could connect to the database.

    REVOKE select ON scott.inventory FROM rita
    REVOKE create table, create view FROM rita

The user rita who was transferred is now moving to another company. Since the objects that she created is of no longer use, write a commmand to remove this user and all her objects.

Here CASCADE option is necessary to remove all the objects of the user in the database.

   DROP USER rita CASCADE

### User rita has been transferred and no longer needs the privilege that was granted to her through the role role_tables_and_views. Write a command to remove her from her previous given priviliges except that she still could connect to the database.
``` sql    
    REVOKE select ON scott.inventory FROM rita
    REVOKE create table, create view FROM rita

The user rita who was transferred is now moving to another company. Since the objects that she created is of no longer use, write a commmand to remove this user and all her objects.

Here CASCADE option is necessary to remove all the objects of the user in the database.

   DROP USER rita CASCADE

Write SQL query to find the nth highest salary from table.

   SELECT TOP 1 Salary
   FROM (
      SELECT DISTINCT TOP N Salary
      FROM Employee
      ORDER BY Salary DESC
      )
    ORDER BY Salary ASC

This guide will cover basic SQL syntax as a refresher and then list some common SQL interview questions. The answers for all questions are given and you can use this information to study for your programming interview.

Basic SQL Syntax Example

SQL is an international standard (ISO), but you will find some differences between implementations. This guide uses MySQL as an example because it's the most popular implementation of SQL.

How to use a specific database

Here is the SQL command used to select the database containing the tables for your SQL statements:

USE fcc_sql_guides_database;

SELECT and FROM clauses

Use SELECT to determine which columns of the data you want to show in the results. There are also options you can use to show data that is not a table column.

The following example shows two columns selected from the “student” table, and two calculated columns. The first of the calculated columns is a meaningless number, and the other is the system date.

SELECT studentID, FullName, 3+2 AS five, now() AS currentDate FROM student;

WHERE clause

The WHERE clause specifies a condition while getting data. The WHERE clause is used to limit the number of rows returned. It's often used in a SELECT statement but can also be used in other statements such as UPDATE and DELETE.

Here is the basic syntax of the WHERE clause:

SELECT column1, column2
FROM table_name
WHERE [condition]

The condition in a WHERE clause can include logical operators like >, <, =, LIKE, NOT, AND, OR.

Here is an example of a SQL statment using the WHERE clause. It specifies that if any of the students have certain SAT scores (1000, 1400), they will not be presented:

SELECT studentID, FullName, sat_score, recordUpdated
FROM student
WHERE (studentID BETWEEN 1 AND 5
    OR studentID = 8
    OR FullName LIKE '%Maximo%')
    AND sat_score NOT IN (1000, 1400);

ORDER BY (ASC, DESC)

ORDER BY gives us a way to sort the result set by one or more of the items in the SELECT section.

Here is the same list as above, but sorted by the student's Full Name. The default sort order is ascending (ASC), but to sort in the opposite order (descending) you use DESC, as in the example below:

SELECT studentID, FullName, sat_score
FROM student
WHERE (studentID BETWEEN 1 AND 5
    OR studentID = 8
    OR FullName LIKE '%Maximo%')
    AND sat_score NOT IN (1000, 1400)
ORDER BY FullName DESC;

GROUP BY and HAVING

GROUP BY gives us a way to combine rows and aggregate data. The HAVING clause is like the above WHERE clause, except that it acts on the grouped data.

The SQL statement below answers the question: “Which candidates received the largest number of contributions (ordered by count (*)) in 2016, but only those who had more than 80 contributions?”

Ordering this data set in a descending (DESC) order places the candidates with the largest number of contributions at the top of the list.

SELECT Candidate, Election_year, SUM(Total_$), COUNT(*)
FROM combined_party_data
WHERE Election_year = 2016
GROUP BY Candidate, Election_year
HAVING count(*) > 80
ORDER BY count(*) DESC;

Common SQL Interview Questions

What is an inner join in SQL?

This is the default type of join if no join is specified. It returns all rows in which there is at least one match in both tables.

SELECT * FROM A x JOIN B y ON y.aId = x.Id

What is a left join in SQL?

A left join returns all rows from the left table, and the matched rows from the right table. Rows in the left table will be returned even if there was no match in the right table. The rows from the left table with no match in the right table will have null for right table values.

SELECT * FROM A x LEFT JOIN B y ON y.aId = x.Id

What is a right join in SQL?

A right join returns all rows from the right table, and the matched rows from the left table. Opposite of a left join, this will return all rows from the right table even where there is no match in the left table. Rows in the right table that have no match in the left table will have null values for left table columns.

SELECT * FROM A x RIGHT JOIN B y ON y.aId = x.Id

What is a full join or full outer join in SQL?

A full outer join and a full join are the same thing. The full outer join or full join returns all rows from both tables, matching up the rows wherever a match can be made and placing NULLs in the places where no matching row exists.

SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID=Orders.CustomerID
ORDER BY Customers.CustomerName

What is the result of the following command?

DROP VIEW view_name

This will result in an error because you can’t perform a DML operation on a view. A DML operation is any operation that manipulates the data such as DROP, INSERT, UPDATE, and DELETE.

Can we perform a rollback after using ALTER command?

No, because ALTER is a DDL command and Oracle server performs an automatic COMMIT when the DDL statements are executed. DDL statements define data structures such as CREATE table and ALTER table.

Which is the only constraint that enforces rules at column level?

NOT NULL is the only constraint that works at the column level.

What are the pseudocolumns in SQL? Give some examples?

A pseudocolumn behaves like a column, but is not actually stored in the table because it is all generated values. The values of a pseudocolumn can be selected but they cannot be inserted, updated, or deleted.

ROWNUM, ROWID, USER, CURRVAL, NEXTVAL etc.

Create a user "my723acct" with password "kmd26pt". Use the "user_data" and temporary data tablespaces provided by PO8 and provide to this user 10M of storage space in "user_data" and 5M of storage space in "temporary_data".

CREATE USER my723acct IDENTIFIED BY kmd26pt
DEFAULT TABLESPACE user_data
TEMPORARY TABLESPACE temporary_data
QUOTA 10M on user_data QUOTA 5M on temporary_data

Create the role _role_tables_andviews.

CREATE ROLE role_tables_and_views

Grant to the role of the previous question the privileges to connect to the database and the privileges to create tables and views.

The privilege to connect to the database is CREATE SESSION The privilege to create table is CREATE TABLE The privilege to create view is CREATE VIEW

    GRANT CREATE SESSION, CREATE TABLE, CREATE VIEW TO role_tables_and_views

Grant the previous role in the question to the users anny and rita.

    GRANT role_tables_and_views TO anny, rita

Write a command to change the password of the user rita from "abcd" to "dfgh"

    ALTER USER rita IDENTIFIED BY dfgh

The users rita and anny do not have SELECT privileges on the table INVENTORY that was created by scott. Write a command to allow scott to grant the users SELECT privileges on theses tables.

    GRANT select ON inventory TO rita, anny

User rita has been transferred and no longer needs the privilege that was granted to her through the role _role_tables_andviews. Write a command to remove her from her previously given privileges. She should still be able to connect to the database.

REVOKE select ON scott.inventory FROM rita
REVOKE create table, create view FROM rita

The user rita who was transferred is now moving to another company. Since the objects she created are no longer used, write a command to remove this user and all her objects.

The CASCADE option is necessary to remove all the objects of the user in the database.

DROP USER rita CASCADE

Write an SQL query to find the nth highest "Salary" from the "Employee" table.

   SELECT TOP 1 Salary
   FROM (
      SELECT DISTINCT TOP N Salary
      FROM Employee
      ORDER BY Salary DESC
      )
    ORDER BY Salary ASC

Conclusion

If you think you can answer all these questions, you may be ready for your interview. Good luck!