And yet the applications go out, and nothing comes back.

This is one of the most frustrating experiences in tech. You're genuinely learning, genuinely putting in the time, and you have nothing to show for it in terms of results. You start to wonder if the market is too competitive, if you need one more certification, or if there's some hidden door everyone else found that you're missing.

The truth is simpler and more actionable than any of that: hiring managers can't see your YouTube watch history. They can see your GitHub. Most beginners optimize for learning. Hired candidates optimize for proof.

In this guide, you'll get an honest breakdown of the nine factors hiring managers actually evaluate when they look at a junior cloud or DevOps candidate and a concrete 90-day plan to address each one. By the end, you'll know exactly where you stand and exactly what to do next.

Table of Contents

• The Three Patterns That Keep Beginners Stuck

  • Pattern 1: The Tutorial Loop

  • Pattern 2: The Theory-Practice Gap

  • Pattern 3: Silent Learning

• What Hiring Managers Are Actually Evaluating

• Factor 1: Proof of Work (The Non-Negotiable)

  • The Three Projects That Cover Everything

• Factor 2: System-Level Thinking

• Factor 3: Software Engineering Fundamentals

• Factor 4: Communication Skills

• Factor 5: Consistency Over Intensity

• Factor 6: Networking and Visibility

• Factor 7: Ownership Mindset

• Factor 8: Business Awareness

• Factor 9: Learning Agility

• Your 90-Day Action Plan

• Honest Self-Assessment: Where Do You Stand?

• Conclusion

• References and Recommended Resources

The Three Patterns That Keep Beginners Stuck

Pattern 1: The Tutorial Loop

Week 1: You watch eight hours of Docker content. Week 2: You start an AWS course and get 70% through. Week 3: A Kubernetes series looks interesting, so you start that instead. Week 4: You open LinkedIn and wonder why you're not getting callbacks.

Watching tutorials feels like progress. It's comfortable, passive, and has no failure state. Nothing breaks. Nothing goes wrong.

The problem is that it produces nothing a hiring manager can evaluate. Courses and certifications tell an employer what you've been exposed to. Your GitHub tells them what you can actually do.

Pattern 2: The Theory-Practice Gap

You can explain CI/CD fluently. You've read the Kubernetes documentation. You understand the conceptual difference between a container and a virtual machine.

But you've never taken a simple application, containerized it, connected it to a pipeline, and deployed it to a cloud server with a real URL that someone can visit.

In an interview, "I understand how it works" and "I have built this and here is the link" are not equivalent answers. Hiring managers hear the first version from hundreds of candidates. The second version gets callbacks.

Pattern 3: Silent Learning

This one is perhaps the most painful pattern because the learning is real. You're putting in the work every day but nobody knows. No GitHub activity. No LinkedIn posts. No community presence. Just cold applications sent from job boards to ATS systems that filter you out before a human ever sees your name.

The hard truth: people get hired through people. A hiring manager who has seen your LinkedIn post about a problem you solved is significantly more likely to give your résumé serious attention than a stranger who applied through a portal.

What Hiring Managers Are Actually Evaluating

I've grouped the nine factors that follow into three buckets: Mindset, Execution, and Visibility. The order matters: mindset shapes how you execute, and execution is what powers visibility.

Let's go through each one.

Factor 1: Proof of Work (The Non-Negotiable)

If there's one thing to take from this entire article, it's this: no portfolio means no serious consideration. The most technically capable candidate in the applicant pool is invisible without proof of work.

This isn't about impressing anyone with complexity. It's about demonstrating that you can take a system from zero to deployed, documented, and working.

Here's the checklist every portfolio project should meet before you consider it done:

• It's deployed: there's a real URL you can share, not "it works on my machine"

• It has a CI/CD pipeline: code changes are automatically tested and deployed

• Infrastructure is defined as code: not manually clicked together in the AWS console

• It has monitoring and alerting: you know when it breaks before users tell you

• It's documented: a README explains what it does, how to run it, and how it works

• It's on GitHub publicly: with real commit history showing iterative work

If your project meets all six criteria, you have proof of work. If it meets four of six, you have a project in progress. Finish it before you start applying.

The Three Projects That Cover Everything

You don't need ten projects. You need two to three projects that together demonstrate the full range of DevOps skills.

Project 1 : The Full-Stack Deploy Pipeline

This is the foundational DevOps project every beginner should build first.

Take any simple web application – a Python Flask app, a Node.js API, or even a static site. Containerize it with Docker. Write a CI/CD pipeline that runs tests, builds the Docker image, and deploys to a cloud server automatically on every push to the main branch. You can also set up Nginx as a reverse proxy and add an uptime monitor (UptimeRobot has a free tier).

Tools: GitHub Actions, Docker, AWS EC2 or Render.com, Nginx.

Why it matters to a hiring manager: it proves you can automate a full deployment workflow end-to-end. The hiring manager can visit your URL, see it running, and inspect your pipeline history.

This single project puts you ahead of most applicants who only have course completion screenshots.

Project 2: Infrastructure as Code with Terraform

Write Terraform code that provisions a complete environment: a VPC, public and private subnets, an EC2 instance with properly scoped security group rules, and an S3 bucket for remote state. Destroy it and recreate it from scratch to prove the code actually works. Add a GitHub Actions workflow that runs terraform plan on pull requests and terraform apply on merge to main.

Tools: Terraform, AWS (or Azure/GCP), GitHub Actions.

Why it matters: Infrastructure as Code with Terraform is a required skill at almost every company running cloud infrastructure. Showing you can write, version-control, and automate Terraform demonstrates a core professional competency.

Project 3: Monitoring and Observability Stack

Deploy a monitoring stack using Docker Compose: Prometheus scraping metrics from your application and the host, Grafana dashboards showing CPU, memory, request rates, and error rates, and Alertmanager configured to send alerts to Slack or email when thresholds are crossed. Connect this to your Project 1 application so the pipeline deploys and the monitoring watches it.

Tools: Prometheus, Grafana, Alertmanager, Node Exporter, Docker Compose.

Why it matters: most beginner portfolios have zero observability work. This project immediately signals that you understand production engineering, not just deployment. Any senior DevOps engineer or SRE reviewing your application will notice it and it will set you apart.

Factor 2: System-Level Thinking

This is the mindset that separates a DevOps engineer from someone who just knows a collection of tools. System-level thinking means you can see the whole picture, not just the part you happen to be working on at any given moment.

Here's the mental test hiring managers are running throughout your interview: can you trace a user request from the moment they click a button to the moment they see a response, and explain what happens at every layer in between?

Here's the full journey of a web request, the map of modern infrastructure every DevOps engineer needs to understand:

Why does this matter in an interview? Consider two candidates answering the question: "Tell me about a time something broke in production."

Candidate A: "The website was down."

Candidate B: "The load balancer health checks were failing because the app containers were running out of memory due to a memory leak introduced in the previous deploy. We identified it via memory metrics in Grafana, rolled back, and added a memory limit to the container spec."

Same incident. Completely different answer. System-level thinking is what makes the difference.

Factor 3: Software Engineering Fundamentals

Many beginners rush to learn Kubernetes and Terraform before mastering the foundations that make those tools make sense. This creates a knowledge structure that looks impressive but has no solid base underneath it.

Here are the fundamentals that actually matter and what to do if you have a gap in any of them:

1. Linux and the Command Line

DevOps tools run on Linux. CI/CD jobs run in Linux containers. SSH is the front door to every server. If the terminal makes you uncomfortable, you're not ready for a production environment. This is not a preference, it's a prerequisite.

Start with daily Linux practice. The Linux Foundation's free introductory materials are a solid starting point. And here's a solid freeCodeCamp course on Linux basics.

2. Networking Fundamentals

DNS, TCP/IP, HTTP/HTTPS, load balancing, firewalls, VPCs, subnets these concepts appear in every cloud architecture. Without them, Terraform and Kubernetes are magic boxes. Study the request flow in Factor 2 above until you can draw it from memory without looking.

Here's a computer networking fundamentals course to get you started.

3. Scripting: Bash and Python

CI/CD pipelines are scripts. Automation is scripting. If you cannot write a Bash script that reads a config file, calls an API, and handles errors gracefully your automation ceiling is very low. Fix this by writing one small, useful script every week. Solve real problems with code.

Here's a helpful tutorial on shell scripting in Linux for beginners.

4. Git and Version Control

Not just git commit and git push. Branching strategies, pull requests, merge conflicts, rebasing, and tagging releases are all standard practice in professional DevOps teams. Use Git for everything including your personal learning notes. Practice branching workflows intentionally.

Here's a full book on all the Git basics (and some more advanced topics, too) you need to know.

5. Docker and Containers

Docker is the universal packaging format for modern software. Understanding layers, multi-stage builds, volumes, networking, and container security is the floor not the ceiling. Every project you build should be containerized. Write your Dockerfiles by hand instead of copying them.

Here's a course on Docker and Kubernetes to get you started,

Factor 4: Communication Skills

Technical skills set your ceiling. Communication skills determine how fast you reach it. This is the most consistently underestimated factor among beginner DevOps candidates.

Two candidates with identical technical ability will have very different career outcomes based on how clearly they communicate. Here's what that looks like in practice:

Architecture explanation: Can you describe how your project works to someone who has never seen it? Can you draw the architecture on a whiteboard and walk someone through your design decisions and the trade-offs you made?

Trade-off articulation: "I chose X over Y because..." is one of the most powerful phrases in a technical interview. It shows you understand that every decision has pros and cons and you made a conscious, reasoned choice rather than just copying a tutorial.

Written documentation: A README is your project's cover letter. A well-written README with clear setup instructions, an architecture diagram, and documented decisions demonstrates engineering maturity that most beginners don't show.

Here's a quick test: open your most recent project on GitHub and read the README as if you're a hiring manager seeing it for the first time. Does it answer these questions?

• What does this project do, and why did you build it?

• What does the architecture look like?

• How do I run this locally, and how do I deploy it?

• What decisions did you make, and why?

• What would you improve if you continued working on it?

If you answered "no" to more than two of those rewrite the README before applying anywhere. This single action will meaningfully improve your response rate.

Interview communication: Hiring managers assess communication throughout the entire interview not just your answers. Thinking out loud, structuring your responses, and admitting uncertainty honestly are all evaluated.

Factor 5: Consistency Over Intensity

Hiring managers are pattern recognition machines. They look at your GitHub contribution graph, your LinkedIn activity, and your learning trajectory and form an impression before reading a single word on your résumé.

A binge-learning approach, 10-hour weekends followed by weeks of nothing produces a GitHub graph that tells the wrong story. Thirty minutes of focused daily practice for six months beats a monthly 10-hour binge. At the six-month mark, the daily practitioner has 90 hours of focused work. The binge learner has 60 with significantly worse retention.

Here's how to build consistency in practice:

• Pick a time slot in your day that you will protect. Thirty minutes is enough to make progress.

• Define a four-week learning sprint with a specific goal, not "learn Terraform" but "build and deploy a VPC with Terraform and write the README."

• Keep a private learning journal: date, what you studied, what you built, what confused you.

• When the sprint ends, evaluate what you built and plan the next one.

What to avoid: declaring publicly on LinkedIn that you're "grinding DevOps full time" and then disappearing for six weeks. The absence is noticed. Only commit publicly to what you will actually sustain.

Factor 6: Networking and Visibility

This is the factor most beginners resist most, and the one that makes the biggest practical difference in time-to-hire.

Most DevOps jobs are filled through people referrals, community connections, LinkedIn conversations. A warm introduction from someone who has seen your work outweighs fifty cold applications every time.

Here are three ways to build visibility without it feeling performative:

Community Engagement

Join communities where DevOps engineers actually talk: AWS User Groups, local DevOps meetups, DevOps Discord servers, Reddit communities like r/devops and r/kubernetes. You don't need to be the expert. Ask specific questions, answer what you genuinely know, and show up consistently. After three to six months, people will recognize your name.

LinkedIn Content

Post once per week about something you learned, built, or got stuck on. Not marketing – documentation. A post that says "This week I configured Prometheus alerting for a Docker Compose stack. Here's what tripped me up and how I solved it" attracts recruiters, leads to conversations, and builds a searchable record of your growth over time.

Asking Good Questions in Public

When you get stuck and figure it out, write it up. Post the solution in the same community where you asked the question. Answer someone else's version of the same question later. You position yourself as a helpful, engaged learner, exactly who hiring managers want to hire.

Here's a concrete three-month visibility sprint to follow:

By month three, recruiters searching for "DevOps" in your location will encounter your activity. Some of the best entry-level DevOps opportunities come from exactly this kind of low-pressure visibility.

Factor 7: Ownership Mindset

This factor is less about personality type and more about observable behavior. Hiring managers are looking for evidence that you finish what you start not just that you start things.

Here's what the contrast looks like:

Ownership mindset has three components. First, finish things: a complete, simple project is worth ten times more than ten incomplete complex ones. Second, take responsibility without blame when something breaks: ownership means identifying the cause, fixing it, and adding monitoring so it doesn't happen again. Third, self-direct your learning you don't wait for someone to tell you what to learn next. You see a gap, identify how to close it, and close it. This is what "junior who can work independently" actually means in job descriptions.

Factor 8: Business Awareness

Technical skill gets you in the door. Business awareness keeps you there and accelerates your career.

The core question hiring managers are testing is: can you connect your technical decisions to cost, uptime, and user impact? Infrastructure decisions are business decisions. Cloud costs are typically the second-largest engineering expense at most companies after salaries. A misconfigured auto-scaling group or a forgotten large EC2 instance can burn thousands of dollars overnight.

Here are a few benchmark questions worth being able to answer comfortably:

• If your company has a 99.9% SLA, how many minutes of downtime per month is that? (About 43 minutes.)

• If you move workloads from on-demand EC2 instances to Reserved Instances, what's the approximate cost saving? (Around 40–60%.)

• If your CI/CD pipeline takes 45 minutes per build and you run 20 builds per day, how much developer wait time does that represent weekly?

Most junior candidates can't answer these fluently in an interview. Candidates who can stand out immediately not because the questions are hard, but because so few people bother to connect infrastructure and business.

The simple habit to build: whenever you describe a technical decision in your project documentation or in an interview, add the business dimension. "I configured auto-scaling" becomes "I configured auto-scaling to handle traffic spikes, which eliminated the cost of over-provisioning and reduced our estimated monthly cloud spend by approximately $X."

Factor 9: Learning Agility

Everyone claims to be a fast learner. It's the most overused phrase in technology job applications. Here's how to make it actually mean something.

Saying "I'm a fast learner" in an interview is table stakes. The question is whether you can prove it. Proof sounds like this: "I had never used GitHub Actions before. I needed a CI/CD pipeline for a project I was building. In 48 hours, I had a working pipeline that runs tests, builds a Docker image, and deploys to AWS."

What makes that credible: it names a specific tool, a specific timeframe, and a specific outcome. There is a GitHub repository with a commit history and a working pipeline that a hiring manager can actually look at.

Learning agility is not about knowing many tools shallowly. It's about picking up new tools quickly because you deeply understand the underlying concepts. Tool names change every few years. Concepts networking, automation, observability, reliability do not.

To build a concrete track record of learning agility: once a month, pick one tool you haven't used. Follow its quick-start guide. Build something small. Document what was difficult. Post about it. This is your learning agility portfolio visible, dated, and specific.

Your 90-Day Action Plan

Here is a concrete, sequential plan that takes you from where you are now to your first DevOps interview-ready state.

Month 1: Build Your Foundation

Focus entirely on Project 1 from the Proof of Work section. Build it completely. Deploy it. Get the live URL. Don't start Project 2 until Project 1 meets all six checklist criteria.

Alongside the build: 30 minutes of Linux and Bash scripting practice daily. This isn't optional, it's the foundation everything else runs on.

Month 2: Expand Your Execution and Start Your Visibility

Begin Project 2 (Terraform IaC). Write your first LinkedIn post, it doesn't need to be polished, it needs to be specific. Join one community and introduce yourself.

Month 3: Complete the Portfolio and Document Everything

Finish all three projects to full checklist standard. Polish every README. Add architecture diagrams. Optimize your GitHub profile, pin your three best repos, write a profile README that describes who you are and what you build, and add links to your live project URLs.

Month 4 Onward: Apply with Strategy

Don't start applying before month four. Apply with real proof of work in hand. Target five to ten quality applications per week rather than spraying a hundred. Include your GitHub and your best project's live URL in every application. For roles at companies where you have a community connection, reach out to that person before applying.

Track every application in a spreadsheet: company, role, date applied, status, outcome, notes. After thirty applications, you'll have enough data to see what's working and what isn't.

Here's the full 90-day breakdown:

Honest Self-Assessment: Where Do You Stand?

Go through each statement below. Be completely honest: this is for you, not anyone else.

Count your "no" answers. Each one is a specific, actionable gap, not a vague sense of being behind. That's the difference between this self-assessment and the anxious feeling of "I'm not ready yet." You're not behind. You just have a prioritized list of what to build next.

Conclusion

Here's what you know now that most beginners still don't:

The gap between you and a DevOps job isn't a gap in certifications, a gap in courses completed, or a gap in the number of tools you've heard about. It's a gap in proof of work, visibility, and the consistency with which you execute.

Hiring managers aren't looking for someone who has watched everything. They're looking for someone who has built something, documented it, deployed it, monitored it, and can clearly explain every decision they made along the way.

The path isn't secret. It's just work. Build two to three complete projects that meet the full checklist. Document everything. Show up consistently in communities and on LinkedIn. Apply with strategy. Iterate based on feedback.

If you want a production-grade reference to support your DevOps journey complete with real Terraform modules, CI/CD workflow templates, infrastructure runbooks, and platform engineering patterns used in real startup environments The Startup DevOps Field Guide was built for exactly this stage of your career.

The information gap between you and your first DevOps role is smaller than you think. The execution gap is where the work is. Start today.

References and Recommended Resources

• roadmap.sh/devops: The community-maintained DevOps learning roadmap. Use this to sequence what you learn next and avoid random jumps between topics.

• DORA State of DevOps Report: Free annual report on what DevOps practices actually improve software delivery performance. Gives you the vocabulary hiring managers speak.

• Linux Foundation - Introduction to Linux: Free introductory Linux course. If the terminal still makes you nervous, start here.

• The Phoenix Project: A business novel about DevOps transformation. Teaches core concepts through story. Gives you vocabulary for business-aware conversations.

• ExplainShell.com: Paste any command you find online and see exactly what every part does. Use this constantly while building your projects.

• GitHub - How to Write a Good README: Official GitHub guidance on repository documentation.

• Prometheus Documentation: Official docs for the monitoring tool used in Project 3.

• Terraform Getting Started - AWS: Official step-by-step guide for Project 2.

• GitHub Actions Documentation: Complete reference for building CI/CD pipelines in Project 1.

• freeCodeCamp - Learn Linux for Beginners: Comprehensive Linux guide available on freeCodeCamp.

Open source is something I found confusing and scary when I first started coding. I heard the term many times, but didn’t clearly understand what it meant, how it worked, or why developers thought it was important.

In this handbook, I will give you a clear and easy introduction to open source, not just what it is, but how it operates and how it connects directly to your career growth.

We'll talk about what open source really means, look at how projects function, and cover the roles of communities and maintainers. We'll also talk about the good and bad parts, and how contributing builds your skills, visibility, and career.

First, I will explain the core concept for each topic. Then, we'll look at real-world examples. This will help you see how open source fits into the real world. It will show you how to use it to grow your career.

By the end of this guide, you will be ready to make your first real contribution and start building your public portfolio.

Let’s get started.

Table of Contents

• What is Open Source?

• How Open Source Actually Works

• The Role of Maintainers, Contributors, and Communities

• Common Misconceptions About Open Source

• The Downsides of Open Source (An Honest Perspective)

• Why Open Source Matters for Developers

• Skills You Develop Beyond Coding

• Proof of Work vs. Resume Claims

• Collaboration, Communication, and Professional Visibility

• How Open Source Connects to Jobs, Referrals, and Remote Work

• What You Really Need Before Contributing

• Choosing the Right Projects and Tech Stack

• Types of Contributions (Code, Documentation, Design, and More)

• Practical Demonstration: From Forking to Creating a Pull Request

• Working With Maintainers and Handling Feedback

• Learning in Public

• Blogging and Documenting Your Work

• Building a Personal Brand Through Open Source

• Open Source Programs, Internships, and Opportunities

• It Is Never Too Late to Start

• Conclusion — Your Next Steps

What is Open Source?

At its heart, open source is about community. It is a way to build software. The "source code" is the actual logic that makes an app work. In open source, projects share this code publicly—anyone in the world can view, study, and change it.

The Open Core

Companies keep most normal software "closed" or proprietary. So only the company that owns the product can see the code.

But open source is different. It lets you look at the code. So, you aren't just a user, but you can also become a potential helper.

Global Collaboration

Open source lets anyone in the world change projects or software. Your location or background doesn't matter. If you can improve the code, you can contribute.

Companies today publicly share their code on platforms like GitHub or GitLab. This global transparency means:

• Anyone can suggest a new feature.

• Anyone can find and fix a bug.

• Anyone can help improve the documentation.

The Managed Process

You might wonder, "If anyone can change the code, won't the software break?" This is where maintainers come in.

Anyone can propose a change. However, the core team of maintainers review every single contribution. They act as the "gatekeepers" and ensure that only safe, high-quality code enters the project.

Public Code = Career Growth

You develop these projects in public. Because of this, open source creates a permanent, verified portfolio for you. GitHub or GitLab signs every contribution with your name.

With this, a recruiter doesn't have to take your word for it. They can see exactly how you write code and solve problems. They can see how you talk to a global team. In open source, your public code becomes the engine of your professional growth.

The Reality Check

Open source isn't just a "free" version of software. It is a living product. A global team builds it together in public. When you contribute, you aren't just writing code, you are joining a worldwide conversation.

How Open Source Actually Works

Open source might seem like magic. However, it follows a very logical workflow. Most of this happens on platforms like GitHub or GitLab. GitHub acts as the central meeting place for developers. Here is the life cycle of a contribution:

Forking: Making Your Own Copy

Imagine seeing a great recipe in a cookbook. You want to try adding a new spice to it, but you wouldn't write directly in the original book. Instead, you'd photocopy the page.

In open source, we call this "forking". It's a process of creating a personal copy of the project’s code under your own GitHub account.

Cloning: Bringing It to Your Machine

Now that you have your "photocopy" on GitHub. You need to move it onto your local computer. This lets you actually work on it. We call this step "cloning".

The Branch: Keeping Things Organized

Before you start typing, you have to create a branch. Think of this as a safe workspace. It lets you work on a feature or fix. It keeps you from messing up the original code.

Committing: Saving Your Progress

You might write code. You might fix a typo in the guide. When you are done, you "save" your work using a "commit". Every commit needs a message. For example, you can write, "Fixed a typo in the README." This tells others exactly what you changed and why.

The Pull Request (PR): Asking for a Review

This is the most important part! Once your changes are ready, you send a "pull request".

You send this back to the original project. You are basically saying, "Hey, I've made these improvements to your recipe. Would you like to pull them into the main cookbook?"

The Review and Merge

The maintainers will look at your PR. They might ask you to change a few things or fix a small bug. Once they approve the quality, they merge your work. Your code officially joins the project and others can use it!

Why This Workflow Shapes Your Career

This process isn't just about code, it's about collaboration.

When a recruiter sees your pull requests, they see three things. A normal resume cannot show these things:

• Version Control Mastery: You clearly know how to use Git and GitHub in a professional way.

• Communication Skills: They can see how you handle feedback. They see how you explain your logic to others.

• Professional Persistence: They see you follow a task from start to finish.

The Role of Maintainers, Contributors, and Communities

Code builds open source. However, people drive it. To do well in this space, you need to understand three main roles. These roles keep a project alive.

The Maintainers (Your Guides and Gatekeepers)

Maintainers are the backbone of any open-source project. They are experienced developers. They manage the project, and also help you move forward in your journey.

You might solve an issue and open a PR. However, the project does not merge your code automatically. The team performs a careful review process, and your code must match the project's quality standards and pass tests.

Maintainers handle all of this review. They give feedback, ask for changes. and finally, they approve your work.

The Contributors (That Is You!)

Contributors are the engine of innovation. You do not need permission to become a contributor. You find a problem and offer a solution. Contributors write code and fix bugs.

They design interfaces. They also improve guides. Every maintainer started exactly where you are today.

The Communities (The Welcoming Committee)

You might feel scared to share your code publicly. But the reality is very supportive. There are many open-source communities that actively welcome newcomers. They want to help you succeed.

These communities usually live on Discord, Slack, or GitHub Discussions. They provide a safe space. You can ask questions there. You can ask for help when your code breaks. And you can learn from more experienced developers.

Common Misconceptions About Open Source

Before you make your first contribution, we need to clear up a few myths.

Many beginners delay their open-source journey for months because of false ideas. Let’s break the most common myths right now.

Myth 1: Open Source Is Only for Experienced Developers

• The Reality: This is entirely wrong. You do not need to be a senior engineer to contribute. Many repositories offer easy tasks. They often tag these with labels like good first issue.

• The Secret: Open source is not just about writing code. You have huge opportunities for non-code contributions. For example, you can fix a project's documentation. Good documentation acts as the lifeline of any project. Maintainers love beginners who help improve it.

Myth 2: You Have to Understand the Entire Codebase Before You Can Fix Anything

• The Reality: Massive projects can have hundreds of thousands of lines of code. Nobody understands all of it. Not even the core team! You only need to understand the tiny section where your bug lives. Think of it like fixing a leaky sink in a mansion. You don't need to memorize the blueprints for the entire house. You just need to understand the kitchen.

Myth 3: Maintainers Are Harsh and Will Mock a Beginner's Code

• The Reality: Beginners often fear getting fear for writing "bad" code. In reality, maintainers are just regular people. They feel incredibly grateful for free help. As long as you remain respectful and read their CONTRIBUTING.md guidelines, they will act as patient mentors. They want you to succeed.

Myth 4: Open Source Doesn't Pay, So It's a Waste of Time

• The Reality: You might not get a direct paycheck for submitting a pull request. However, the return on investment is massive. Your public portfolio leads directly to full-time job offers. There are also paid programs. Programs like Google Summer of Code or Outreachy actually pay beginners to contribute.

The Downsides of Open Source (An Honest Perspective)

Open source is a great way to build your career. But it is not perfect. If you think everything will be fast and easy, you might get upset. Here is an honest look at the real problems you will face.

Long Wait Times (Tired Maintainers)

Most maintainers work on these projects for free. When a project gets popular, they get too many updates to look at. They work very hard just to keep up.

• The Downside: You might send in great code. But it could take weeks for a maintainer to look at it. You must learn to be patient. Do not feel bad if they remain quiet.

Strict Rules for Adding Code

Big projects set strict rules for adding code. It is rarely as easy as clicking a "Save" button.

• The Downside: Big projects run strict tests automatically. The system might reject your code many times because of a missing comma. This can happen before a human even sees it.

Inactive Projects

There are millions of projects on GitHub. Not all of them are active.

• The Downside: Beginners often spend hours fixing a bug. Then they find out the creator has not updated the project in two years. This teaches a hard lesson. Always check if a project is still active before you start working.

High Competition for Easy Tasks

Many projects mark easy tasks for beginners. But you are not the only one looking for them.

• The Downside: Many people try to grab a good first issue label in minutes. It can be sad to feel like you are always too late. You will need to learn how to claim tasks quickly. You can also find smaller projects to make your first change.

Why Open Source Matters for Developers

Open source offers many great benefits. It is not just about writing free code. It is about building your future. Here is why spending time in open source is a great move.

Real-World Skills for Free

You do not need to pay for an expensive course to learn software development. Open source gives you hands-on coding skills. You learn how big projects work, how teams work together, and how to write clean code.

A Low-Risk Way to Test the Waters

How do you know if you actually like a certain job? Open source is the perfect place for self-exploration.

• It is a low-risk way to see if a tech stack fits you.

• You can try being a full-stack developer or a technical writer for a few weeks. You do not have to quit a job. If you do not like it, you can just try a different project!

Global Networking and Mentorship

Open source connects you to the whole world. You can build a network with smart people. You can get free guidance from some of the best developers on the planet. As you grow, these connections can even lead to speaking at tech conferences.

Your Public "Proof of Work"

A normal resume just tells people what you can do. Open source actually shows them.

• Your GitHub profile acts as your "Proof of Work."

• Companies trust your skills when they see your code merged into a real project.

Jobs and Internships

Open source is a direct path to getting hired. You might be a student looking for an internship, or a professional looking for a remote job. Companies actively look for open-source contributors. It shows you know how to work well with a team.

Skills You Develop Beyond Coding

When you contribute to open source, you learn more than just code. You learn how to be a professional. Hiring managers look for these exact skills.

Clear Communication and Writing

In open source, you work with people you have never met. You cannot tap them on the shoulder to explain an idea.

You have to write it down.

• You learn how to explain a problem clearly.

• You learn how to write good technical guides.

• You learn how to talk to people across different time zones.

Testing and Finding Bugs

The team must approve your code before adding it. Open source teaches you how to think like a software tester. You learn how to find hidden bugs, write tests for your code, and make sure your changes do not break the app.

Seeing the Big Picture

Big projects let you see how everything connects. You start to understand how the front-end talks to the back-end. This helps you grow into a full-stack developer. You see how the whole system works together.

Taking Feedback (and Giving It)

A maintainer will tell you what is wrong with your code. This teaches you how to take feedback without getting upset. You also learn how to review other people's work respectfully.

Managing Your Own Time

No one is forcing you to contribute. You have to set your own schedule. This teaches you how to manage your time from home. Companies love this. It shows you can be trusted to work remotely.

Proof of Work vs. Resume Claims

A normal resume lists the tools you know. You might type, "I know React." But anyone can type words on a page. A hiring manager doesn't know if your skills are actually good.

Open source changes the game. It gives you Proof of Work.

Showing Instead of Telling

Open source lets you show your tech stack. Every time you change a project, you open a pull request (PR). This PR is public.

A company gets to see the real you. They do not have to guess. They look at your PR and see:

• Exactly how you format your code.

• How you fix problems and bugs.

• How you talk to maintainers.

The Ultimate Job Application

Your merged pull requests are your public portfolio. A resume is just a claim. A merged PR is real proof. It proves your skills are ready for the real world.

Collaboration, Communication, and Professional Visibility

Open source is about collaboration. Anyone in the world can join a project. You must learn how to work well with others. Here is how to grow as a team player.

Helping Others Is a Contribution

Many beginners think they only add value when they write code. This is not true. Helping other developers is a huge part of open source.

• Take time to help someone else.

• Answer questions in Discord or Slack channels.

• Helping a new person fix an error shows you are a team player.

Learning "Asynchronous" Communication

Open source is a global community. The person you are working with might live across the world. You will use asynchronous communication. This means you will not get an answer right away. You might send a message while the maintainer is sleeping.

They will reply hours later. You have to write very clear messages. This gives them all the details they need.

Soft Skills and Respecting Maintainers

Your "soft skills" matter just as much as your coding skills. You must always show complete respect.

• Most project maintainers do not get paid. They do this work for free.

• They give you their free time to review your work.

• Do not get angry if a maintainer asks you to change your code. Make the changes and thank them.

Building Professional Visibility

People notice when you help others and write good code. You do all of this work in public.

• Your GitHub profile records these good habits.

• It is real proof of your character.

• Companies see a kind, helpful professional who works well on a global team.

How Open Source Connects to Jobs, Referrals, and Remote Work

Many people use open source as a bridge to get a tech job. Here is exactly how free code connects to a paid career.

The Direct Path to Hiring

Big companies build and use open-source tools. When they need to hire, they do not just look at resumes. They look at the people already fixing their code on GitHub.

You are proving you can do the job! Recruiters often send messages saying, "We love your free work. Would you like to come work for us full-time?"

Earning Real Job Referrals

Getting a job is often about who you know. You code next to senior developers in open source. These developers will remember your name if you do good work. Later, you can ask them for a referral. This puts your name at the very top of the hiring list.

Proving You Are Ready for Remote Work

Working from home is a dream for many developers. Companies want to be sure they can trust you.

Open source is exactly like remote work. You prove that you can:

• Manage your own time.

• Talk clearly through text across different time zones.

• Use tools like Git and GitHub.

• Solve hard problems from your own desk.

Hiring managers know you are trained for a remote job. They can trust you from day one.

What You Really Need Before Contributing

You need a few basic things before you make your first change. You do not need to be an expert. You just need simple tools and the right mindset.

A GitHub Account

Almost all work happens on GitHub. Create a free account. This will be your public profile.

Basic Knowledge of Git

Git is the tool developers use to save code. You only need to learn the basics:

• How to copy a project (clone).

• How to save your changes (commit).

• How to send changes to GitHub (push).

• How to ask maintainers to look at your work (pull request).

One Core Skill (Code or Writing)

You do not need to know ten programming languages. You just need one core skill.

• Know basic HTML and CSS? You can fix how a website looks.

• Know basic Python or JavaScript? You can fix small bugs.

• Don't know how to code? You can be a technical writer. You can help fix documentation.

A Code Editor

You need a place to type code. Download a free editor like VS Code. It is very easy to use.

Patience and Willingness to Read

This is the most important tool. You must read the project's rules before you ask a question.

Read the README.md and CONTRIBUTING.md files carefully. They tell you exactly how to set up the project.

Choosing the Right Projects and Tech Stack

Finding your first project can feel hard. There are so many choices. But it is easy if you know where to look.

How to Find the Right Project

You can use a few simple tricks to find projects that want help:

• Search GitHub: Look for very active projects. Check for a good first issue label. This means the project welcomes beginners.

• Use Google: Search for "Top open source projects for beginners."

• Visit the GSoC Website: Go to the Google Summer of Code website. It has a huge list of groups. You can filter the list to find exact coding languages.

Choosing Your Tech Stack

A "tech stack" is the group of tools used to build software. You can choose from many areas:

• Web Development: Building websites (HTML, CSS, JavaScript, React).

• Mobile Development: Building phone apps (Swift, Kotlin, Flutter).

• AI and Machine Learning: Working with smart data (Python).

• Cloud and DevOps: Helping software run on the internet (Docker, AWS).

• Web3: Working with blockchain technology.

Pick What Fits You

Select a path based on the skills you already have. Look for a web project if you are learning web development. Open source is the best place to practice the skills you want to use in a future job.

Types of Contributions (Code, Documentation, Design, and More)

Open source needs all kinds of skills to survive. Think of a project like building a house. You need builders, painters, and instruction writers. Here are the different ways you can contribute:

Code Contributions (The Builders)

If you know how to code, you can help build the software.

• Fixing Bugs: Find a small error and fix it.

• Adding Features: Write new code to do something new.

• Writing Tests: Write bits of code to check if the software works.

Documentation (The Teachers)

Every good project needs instructions. You do not need to know how to code to do this!

• Writing Guides: Write simple steps on how to use the project.

• Fixing Typos: Read the README.md file and fix spelling mistakes.

• Translating: Translate guides into another language.

Design and Art (The Painters)

Software needs to look good and be easy to use.

• Making Logos: Create a cool logo or icon.

• Improving Design (UI/UX): Make menus easier to click.

• Creating Pictures: Draw diagrams to explain how things work.

Community and Support (The Helpers)

A project is nothing without its people.

• Answering Questions: Go to Discord and help beginners.

• Organizing Events: Help plan online meetings.

• Testing: Use the software and report any problems.

Practical Demonstration: From Forking to Creating a Pull Request

Now it is time to put everything together. We are going to walk through the exact steps to make a change on GitHub.

Step 1: Fork the Project

Go to the GitHub page of the project you want to help. Click the Fork button in the top right corner. This makes a complete copy of the project. It puts it in your own GitHub account, so cannot break the original one!

Step 2: Clone It to Your Computer

Now, download that code to your own computer.

1. Go to your new copied project.

2. Click the green Code button and copy the web link.

3. Open your computer's terminal. Type: git clone [paste your link here]

Step 3: Create a New Branch

You must create a safe workspace before you change files. This is called a "branch." Type this command: git checkout -b <branch_name>.

Step 4: Make Your Changes

Open the project folder in VS Code. Find the file you want to fix. Make your change and save the file.

Step 5: Save (Commit) Your Work

Tell Git you are done making changes. Type these two commands:

1. git add .

2. git commit -m "Fixed a spelling mistake in the README."

Step 6: Push the Code Back to GitHub

Send your changes back up to your GitHub account. Type this command: git push origin <branch_name>.

Step 7: Create the Pull Request (PR)

Go back to your GitHub page. Click the big green Compare & pull request button. Write a nice note to the project maintainers. Click Create pull request.

Congratulations! You sent your first open-source contribution!

Working With Maintainers and Handling Feedback

Your job is not done yet. Now, you get to work with the maintainers. This is how you handle the review process.

The Waiting Game

You have to wait after you send a PR. Remember, maintainers are busy people working for free.

• Do not leave angry comments.

• Do not tag them every day.

• Be patient. It might take a week for a reply.

It Is About the Code, Not You

Maintainers will leave comments. They might say, "Please change this word," or "Your code breaks this rule." Do not feel bad! The maintainer is not saying you are a bad coder. They want you to succeed.

How to Make the Changes

Do not close your PR if they ask for a change! It is easy to update it.

• Make the changes in your code editor.

• Save the file.

• Type git add . and git commit -m "Fixed the feedback."

• Type git push origin <branch_name>.

Your Pull Request on GitHub will update all by itself!

Say Thank You

Good manners go a long way. Always say thank you when a maintainer reviews your code. When everything looks good, they will click Merge. Your work is now permanent!

Learning in Public

"Learning in public" means sharing your progress with the world. Doing this acts as real proof of your skills.

It opens up many new chances for your career.

The Bigger Impact of Asking Questions

Ask your questions publicly in a forum or a channel. Asking in public creates a bigger impact:

• You get answers from the whole community.

• Another beginner can search and find your public conversation later.

• You are actually helping others solve their problems!

Building Trust and Proof of Work

People start to trust you when you share what you learn. Your public posts act as proof of work. This can easily lead to a job offer or internship.

Where to Share Your Journey

You just need to talk about what you learned today. Here are ways to do it:

• Short Updates: Write short posts on X (Twitter) or LinkedIn about a new tool you tried.

• Longer Articles: Write full articles on platforms like Hashnode, Dev.to, or Medium.

Blogging and Documenting Your Work

Writing about your open-source work is very important. You help others learn. You also leave a clear record of your skills.

Short Posts vs. Long Articles

You can share your work in two ways:

• Short Posts: Use LinkedIn to share quick wins. Write, "Today I fixed my first bug!"

• Long Blogs: Write step-by-step guides on Hashnode, Medium, or dev.to.

• Write for freeCodeCamp: You can even apply to write articles directly for freeCodeCamp!

Do Not Wait to Be Perfect

Do not wait for your blog to be perfect. Just hit publish. You will improve your skills naturally. Make each new blog a little bit better than the last one.

How to Learn Technical Writing

There are great free tools to help you learn. Check out the Showwcase YouTube channel. They have plenty of videos for beginners.

A Path to New Jobs

Writing about your code can lead to new career choices. You build a public portfolio. This can lead to job offers in technical writing. Companies love developers who can explain tech simply!

Building a Personal Brand Through Open Source

A personal brand is simply what people think of when they see your name online. Open source builds this brand for you naturally.

Your Living Portfolio

You build a living, public portfolio when you share your journey.

• Every pull request is part of your portfolio.

• Every blog post is part of your portfolio.

• Every time you help a new person, it becomes public record.

It Happens Automatically

You do not have to try hard to build a brand. It happens automatically.

You naturally build your brand as an "Open Source Contributor." People will know you as someone who is helpful and smart.

Let Your Work Do the Talking

Your code, writing, and kindness do the talking for you. Hiring managers will see a trusted, active member of the global tech community.

Open Source Programs, Internships, and Opportunities

Open source is not only volunteer work. There are amazing programs that will actually pay you to learn and write code.

Google Summer of Code (GSoC)

Google runs this program every year.

• How It Works: You suggest a project. Google pays you real money to write code over the summer and you get a mentor to guide you.

Outreachy

Outreachy provides paid remote internships.

• How It Works: You can apply to do design work, marketing, or write guides. You work from home and get paid.

Major League Hacking (MLH) Fellowship

The MLH Fellowship is like a remote internship.

• How It Works: A professional mentor guides your team. You get paid and help major open-source projects.

Open Source Design (For UI/UX and Art)

This community connects designers with open-source projects.

• How It Works: Projects ask for help making logos or doing user research. Some of these are paid jobs.

The Good Docs Project (For Writers)

This community focuses on improving open-source instructions.

• How It Works: You practice writing guides. You get feedback from expert writers. You build a public writing portfolio.

LFX Mentorship (Linux Foundation)

The Linux Foundation runs a great mentorship program.

• How It Works: You can learn about technical writing or community management. Many of these tracks pay you while you learn.

Paid Tutorial Programs (Freelance Writing)

Cloud hosting companies need clear guides on how to set up open-source software.

• How It Works: Companies will pay you to write step-by-step guides. This is a great way to earn a part-time income.

It Is Never Too Late to Start

Many people worry that they missed their chance. This is completely false. Your age never matters in open source.

The Code Does Not Care How Old You Are

Nobody asks for your age. The community only cares about one thing: Does your work help the project? You will be welcomed if you help the community.

Consistency Is the Real Secret

You do not need to be the fastest coder. The only thing that matters is that you start and stay consistent.

• Doing one small thing every week is best.

• Keep showing up in the community.

• These small steps will build a massive portfolio.

Your Past Experience Is a Superpower

You have a big advantage if you are starting later in life. You already know how to manage your time and work on a team. Do not wait for the perfect time. The perfect time is right now.

Conclusion — Your Next Steps

You made it to the end of this handbook! You now know what open source is. You know how it works and how it can change your career.

You don't need to be an expert coder to start. You just need to try. You also need to be willing to learn in public.

Reading this guide was your first step. Now it is time to take real action. Here is a simple checklist for this week:

Your Action Plan

1. Set Up Your Tools: Make a free GitHub account and download VS Code.

2. Find Your First Project: Search for a project that welcomes beginners. Look for the good first issue label.

3. Say Hello: Join the project's Discord or Slack. Tell them you want to help.

4. Try Technical Writing: Pick an open-source tool. Figure out how to set it up. Write a simple guide about it.

5. Share Your Start: Write a short post online to say you are starting your open-source journey.

Open source is a massive world. But it is a friendly one. Every great developer started exactly where you are right now. Do not wait for the perfect moment. Make your first contribution today. Start building your future!

In 2021, I got my first developer job by sending one direct email and then doing a single live call. That was enough.

Later the same year, I found my second job in about three weeks through LinkedIn. At that point, I mostly knew CSS. No serious JavaScript, no strong portfolio, no polished personal brand. And I was offered a Senior Front End Web Developer position at US-based company.

Then things changed. After COVID, a lot of developers moved to remote work. Local job markets turned global almost overnight. Instead of competing with a handful of people nearby, you were suddenly up against hundreds of developers from everywhere.

By 2023, I had real experience. I’d worked at two companies – one in Europe and one in the US. I knew JavaScript, had a proper frontend portfolio, and a personal website. Finding a job should’ve been easier. Instead, I spent 18 months struggling to land a role that actually fit me. The competition was simply on another level.

Now, in 2026, it’s even tougher. AI tools have made it easier to apply, build, and present yourself, which also means companies are flooded with candidates. Things like a decent CV or a basic project don’t stand out anymore. A lot of common advice still sounds good, but it doesn’t work the way it used to.

This guide is based on what actually helped me. I’ll walk through the full process – from preparation to interviews to offers – and explain what matters today, and where most developers lose time without realizing it.

I’ve prepared for you a Dev Job Application Toolkit. By my calculation it can save you 40-60 hours.

This toolkit includes:

• CV and cover letter templates

• Eight interview checklists

• List of top 50 remote-first companies

• Job application tracker spreadsheet

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

Table of Contents

• 1. Mindset & Strategy (Before You Start Applying)

  • Choosing a clear position

  • Deciding on the work format

  • Picking the right company type

  • Understanding the product you’ll work on

  • Real story from my experience

  • Creating a job search plan

• 2. Skill Readiness and Gap Analysis

  • Real story from my experience

• 3. Portfolio Preparation (Critical Stage)

• 4. CV / Resume Preparation

  • Header: make it obvious who you are

  • Summary: your short positioning statement

  • Work experience: results over responsibilities

  • Optional sections (only if relevant)

  • Length and customization

  • Format and tools

• 5. Cover Letter

  • What a cover letter is (and isn’t)

  • Step 1: Research before writing anything

  • Step 2: Header and greeting

  • Step 3: Strong, short introduction

  • Step 4: The body — tell a clear story

  • Step 5: Adjust for your role level

  • Step 6: Closing + call to action

  • Step 7: Formatting and final checks

• 6. LinkedIn (Turn Your Profile Into a Recruiter Magnet)

  • Step 1: Get the Basics Right

  • Step 2: LinkedIn SEO (So Recruiters Can Find You)

  • Step 3: Treat Your Profile Like a Landing Page

  • Step 4: Show Proof (This Is Huge for Developers)

  • Step 5: Get More Visible

• 7. Job Search & Application Strategy

  • 1. Job Boards (Fast but Competitive)

  • 2. Company Career Pages (Often Overlooked)

  • 3. Startups, Agencies & Communities (Hidden Gold)

  • Application Strategies (Choose Wisely)

  • Track Everything (Very Important)

• 8. Technical Interview Preparation

  • Step 1: Strong Technical Foundation

  • Step 2: Pre-Interview Strategy (Once Interview Is Scheduled)

  • Step 3: How to Act During the Technical Interview

  • Step 4: Closing the Interview Strong

• 9. HR and Behavioral Interview

  • Step 1: Pre-Interview Research (Do Your Homework)

  • Step 2: Use the STAR Method (Always)

  • Step 3: Common HR Questions (How to Answer)

  • Step 4: Teamwork, Conflict & Feedback

  • Step 5: Closing the Interview + Salary Questions

  • Step 6: After the Interview (Don’t Skip This)

• 9. Salary Negotiation and Job Offers

  • 1. When You Receive an Offer: Pause First

  • 2. Look at Total Compensation (Not Just Salary)

  • 3. Salary Negotiation Rules (Very Important)

  • 4. Advanced Negotiation Tips (Most Devs Skip This)

  • 5. Final Step: Close Everything Properly

• Conclusion

1. Mindset & Strategy (Before You Start Applying)

Before you apply anywhere, you need to decide what you actually want. This sounds obvious, but it’s one of the most skipped steps – especially by junior developers. I know this because I skipped it myself.

When you have little or no experience, it’s tempting to think: I’ll apply everywhere and take whatever I get. That approach feels safe, but it’s risky. You can easily end up in a role you don’t enjoy, working on things you don’t care about, and burning out much faster than you expect. A bad first or second job can slow you down more than having no job for a bit longer.

This stage is about setting boundaries before desperation sets in.

Choosing a clear position

First, be honest about the role you’re targeting. UI/UX, frontend, backend, full-stack, mobile – these are not just labels. Companies hire for specific problems, and they want people who are focused, not “a jack of all trades“.

If you present yourself as a generalist without real depth, recruiters don’t see flexibility. Instead, they see risk. Being specific increases your chances, especially for junior and mid-level roles.

Deciding on the work format

Next, decide how you want to work: remote, on-site, or hybrid.

This matters more than people admit. I personally dislike office work, so remote roles are my only option. That decision alone filters out a huge number of jobs – and that’s a good thing. You should make the same call based on how you work best, not on what sounds impressive.

Picking the right company type

Company type affects your daily life more than the tech stack.

Startups, agencies, and large enterprises all work differently. Startups move fast and expect long hours. Enterprises are more structured and predictable. Agencies juggle multiple clients and deadlines. None is inherently better than the others, but one will fit you better than the others.

Understanding the product you’ll work on

Finally, think about what kind of product you want to build.

Some roles mean jumping between projects. Others mean working on one large product for years. Some outsource companies throw dozens of small, unrelated tasks at you. These are very different work styles.

Real story from my experience

I once interviewed for a role where the team lead casually mentioned they build Shopify plugins. I immediately knew it wasn’t for me. I’m interested in web applications, not plugins – and no salary would’ve changed that. I applied anyway because I was desperate, which was a mistake.

Defining your criteria early saves you from this.

Practical checkpoint: if you can’t clearly describe the role, work format, company type, and product you want, you’re not ready to apply yet.

Creating a job search plan

Once you know your direction, turn the job search into something structured. Without a plan, it becomes emotional and inconsistent.

A search plan is just a set of rules you follow regardless of mood.

Plan weekly, then break it into daily goals. For example: apply six days a week, with a target of 90 applications per week. That’s 15 per day.

At first, these numbers are guesses. That’s normal. After a week or two, you’ll see what’s realistic. Maybe 15 quality applications is too much, and 6–8 is sustainable. That’s not failure, that’s data. Adjust and keep going.

Remember: the goal isn’t to hit an impressive number. It’s to stay consistent without burning out.

The second part of the plan is tracking. Use something simple, like a spreadsheet. For each application, note the date, the company, and the current status: sent, rejected, HR interview, technical interview, offer.

This gives you two benefits. First, you don’t lose track of where you’ve applied. Second, over time, you start seeing patterns. You can tell how many applications turn into interviews, where things usually break down, and what might need fixing – your CV, your targeting, or your interview prep.

You can download my free job application tracker spreadsheet here.

Practical checkpoint: if you can’t say how many applications you send per day or where they usually fail, you’re guessing – not managing – your job search.

2. Skill Readiness and Gap Analysis

Before you send your first application, you need to make sure your skills actually line up with what companies are hiring for right now. This stage is about facing reality – not in a negative way, but in a useful one. You’re trying to match your current level to the level the market expects for the role you want.

A good place to start is job descriptions. Pick a few major job boards and scan real openings for your target position. What matters is volume and focus. Look at 10, 20, or even 30 listings for the same role, not random ones. Specificity is critical here.

As you read through them, patterns start to show up. The same technologies appear again and again. At this stage, using AI to summarize requirements can save time, as long as you’re still doing the thinking. The goal is to spot common ground faster, not to outsource judgment.

What you’re looking for is a simple structure.

First, identify the core skills. These are non-negotiable. For a frontend role, that’s usually JavaScript, a framework like React, and a styling solution such as Tailwind. If you’re weak in one of these, that’s a real blocker, not something to “fix later.”

Next, identify two or three nice-to-have skills. These depend on the role and the company type. Agencies often value things like Framer Motion for polished UI work. Product companies may care more about performance or accessibility. These skills won’t always block you, but they can separate you from similar candidates.

Finally, choose at least one adjacent skill. Something that isn’t your main focus but is expected in any professional setup. Git is the most common example. Missing these often leads to quiet rejections – no feedback, just silence.

Once you have this list, it’s time for an honest audit. Don’t rely on passive learning or gut feeling. Test yourself. Use flashcards for concrete concepts (you can this tool for flashcards: 99cards.dev). Answer open-ended questions without notes. Build a small, focused project that forces you to use the skill without guidance.

The outcome of this stage should be clear. You’ll know where you’re solid, where you’re shaky, and where you’re not ready at all. From there, the job is simple: strengthen weak spots until you’re roughly at market level for your target role.

Real story from my experience

I once saw an attractive front-end web developer/web designer position that required Tailwind CSS for styling. In application company required to list two websites with Tailwind CSS in use. At that moment I had none. And I couldn’t apply. Pity.

Practical checkpoint: if you can’t clearly name your core skills, nice-to-haves, and weakest areas, you’re guessing where you stand – and the market won’t guess in your favor.

3. Portfolio Preparation (Critical Stage)

Your portfolio is simply a list of projects you’ve completed. But where and how you present that list matters a lot more than most developers think.

In my experience, the best place for a portfolio is a personal website (here is mine: https://ilyasseisov.com/). It gives you full control. You decide the structure, the wording, the tone, and the visuals.

Some developers prefer a very minimal setup. Others go for something more visual, with motion and modern UI. Both approaches are fine. What matters is that the site reflects how you think and what you care about building.

On that website, you should showcase only your best work. Not everything you’ve ever built. One, two, or at most three projects is enough. These should represent what you can do right now, not what you could do a year ago. More projects don’t make you look better – they usually make it harder for someone to see your strengths.

Choosing the right projects is where many people go wrong. Your portfolio projects should be directly related to the role you want.

When I was focusing on building modern, animated websites, I showed projects with strong visuals, animations, and micro-interactions. When I shifted toward SaaS and web applications, I replaced those with real app-style projects. The portfolio should follow your direction, not your history.

Avoid tutorial clones. Even well-made ones. Recruiters see them immediately, and they don’t tell much about how you think or make decisions. Personal or slightly imperfect projects are usually far more interesting than something copied step by step from a course.

For each project, a simple case-study structure works best. Explain what the project is, why it exists, and how you approached it. Show the final result with a live link, so people can actually use it. Code access is optional. Sometimes you don’t want to make everything public, and that’s fine. If a recruiter asks, you can always give access privately to a small group.

Here is example of my case study page: ilyasseisov.com/projects/99films/

Practical checkpoint: if your portfolio doesn’t clearly show what kind of work you want to be hired for, it’s not helping you – no matter how polished it looks.

4. CV / Resume Preparation

Your CV is not a biography. It’s a filtering document. Its job is to help a recruiter understand, in under a minute, who you are, what role you fit, and whether it’s worth moving you forward. Structure and clarity matter more than clever wording.

Header: make it obvious who you are

At the very top, include your full name, your role, and your main technologies. Be specific.
For example: Frontend Web Developer (React, Next JS).

This saves time for recruiters and helps with automated filtering. I also include my email address, and sometimes – in smaller, low-opacity text – my years of experience (for example, 10+ years). It’s a quick signal, not a headline.

Summary: your short positioning statement

Think of the summary as an elevator pitch with context. This is where you explain what you do well and what kind of problems you’re best at solving. Keep it focused. Avoid vague statements like “passionate developer” or “team player.” Say what you build and where you add value.

Work experience: results over responsibilities

This is the most important section.

For each role, include the company name, time period, and position. If it helps, add a link to the company’s website.

When describing your work, focus on accomplishments, not duties. What did you change? What improved because of your work? Metrics matter here.

For example:

Redesigned and coded the UI of a 20+ page web application, resulting in a 16.7% increase in user engagement and a 21.4% reduction in page load time. Worked closely with backend and QA teams. Designed in Figma, implemented with Tailwind CSS and React.

This tells a much clearer story than listing tasks.

Optional sections (only if relevant)

You don’t need to include everything — only what supports your candidacy.

• Education: useful if it’s related (computer science, software engineering, and so on)

• Personal projects: include only if they align with the role you’re applying for

• Interests or hobbies: optional, but can create a human connection if they’re meaningful

• Languages: valuable in a global job market

If a section doesn’t strengthen your position, leave it out.

Length and customization

A rough rule: around one page per 10 years of experience.

More important than length is relevance. Ideally, you should have a solid base version of your CV, then slightly adjust it for specific roles. This small effort often leads to a much higher response rate.

Format and tools

Don’t add a photo. It doesn’t help, and in many cases, it hurts.

Always send your CV as a PDF. This avoids layout issues and font problems.
For tools, I prefer Figma because it gives full control over layout and visuals. If that feels like overkill, Google Docs works just fine.

Create a first version, then iterate over time. Add new skills, remove outdated ones. This is normal. My current CV is version six – and it took years to get there.

Before sending your CV, run it through an ATS checker. Many companies use automated systems before a human ever sees your résumé. If the machine can’t read it properly, it won’t matter how good the content is.

You can check out my proven CV template here. It's free to download.

Practical checkpoint: if a recruiter can’t understand your role, level, and strengths in 30–60 seconds, your CV needs simplification – not more detail.

5. Cover Letter

A cover letter is short, focused, and very intentional. It’s not a repeat of your CV – it’s your chance to explain why you’re a great fit for this specific role and this specific company.

What a cover letter is (and isn’t)

A web developer cover letter should be 200–300 words max. Its main goal is to connect your skills and experience to the company’s needs in a more personal way than a résumé can.

Think of it as a bridge between:

• what you can do (CV)

• and why they should care

Step 1: Research before writing anything

Never write a generic cover letter.

Before you start:

• Read the job description carefully

• Look up the company, their product, and their values

• Try to find the recruiter or hiring manager’s name (LinkedIn helps a lot)

Then:

• Pick one strong “crowning achievement” – a project or result that clearly shows your value

Step 2: Header and greeting

Keep it clean and professional.

Header should include:

• Full name

• Email + phone

• Location (city, country/state)

• Link to your portfolio or personal website (very important for devs)

Greeting:

• Use “Dear [Name]” or “Dear [Team Name] Team”

• Avoid “To whom it may concern” — it feels lazy and generic

Step 3: Strong, short introduction

Your intro should be 2 sentences max.

Include the exact role you’re applying for and a quick hook – why this company or product caught your attention.

Example ideas:

• A product they built

• A mission you align with

• A tech stack you’re excited about

Step 4: The body — tell a clear story

This is the core of your cover letter.

Focus on technical skills (HTML, CSS, JavaScript, React, Node.js, and so on) and real impact, not just tools.

Use numbers whenever possible:

• “Improved performance by 30%”

• “Reduced load time by 2 seconds”

A great structure here is: Problem → Solution → Impact

Also don’t forget that soft skills matter: communication, problem-solving, teamwork are important. Companies hire people, not just code writers.

Step 5: Adjust for your role level

What you emphasize depends on your profile:

• Front-end → UI, UX, responsiveness, animations, browser support

• Back-end → APIs, databases, scalability, performance

• Full-stack → end-to-end ownership, deployment, architecture

• Entry-level / junior → personal projects, bootcamps, learning speed, motivation

If you lack experience, that’s okay. Show potential and direction.

Step 6: Closing + call to action

Wrap it up confidently. Reconfirm your interest in the role, briefly restate the value you bring, and add a soft CTA like being open to an interview or discussion.

End with:

• “Sincerely” or “Best regards”

• Your name

Step 7: Formatting and final checks

Details matter here.

• Use the same font as your CV

• Stick to clean, modern fonts (Plus Jakarta Sans, Inter, DM Sans, etc.)

• Keep margins simple and spacing readable

• Always send as a PDF

• Proofread carefully – mistakes here hurt more than missing skills

Practical checkpoint: If your cover letter could be sent to 10 different companies without changes, it’s not good enough.

You can check out my cover letter template here. You can have it for free.

6. LinkedIn (Turn Your Profile Into a Recruiter Magnet)

LinkedIn shouldn’t be just an online CV. For a web developer, it should work like a high-converting landing page that brings recruiters to you, even while you sleep.

Below is a practical, step-by-step approach, from fixing the basics to getting real inbound opportunities.

Step 1: Get the Basics Right

Before optimizing content, make sure your profile looks clean and professional.

• Turn off profile update notifications: Go to Settings & Privacy and disable updates before editing. No one needs to see you fixing typos.

• Create a custom LinkedIn URL: Use something like linkedin.com/in/yourname-dev. It helps with SEO, looks cleaner on your CV, and improves response rates.

• Profile photo matters a lot: Use a clear, recent headshot. Face should take ~60% of the frame, clean background, friendly expression.

• Add a custom banner: Don’t leave the gray default. Use Canva to add something simple: your tech stack, role, or personal brand.

Step 2: LinkedIn SEO (So Recruiters Can Find You)

If you’re not optimized for keywords, you’re basically invisible.

Pick your target role – for example, Frontend Developer, React Engineer, Full-Stack Developer

Then repeat that keyword in 4 places:

• Headline

• About section

• Job titles

• Experience descriptions

Then make sure you write a strong headline (this is very important). Here's the formula:
[Role] + [Main Tech] + [Value]

Example:
Full-Stack Developer | React, Next.js | Building scalable web apps for startups

Step 3: Treat Your Profile Like a Landing Page

Once someone clicks your profile, you need to convert that visit.

About section = your story

Write like a human, not a robot. Explain why you code, what problems you solve, your experience level, and your core stack

Experience = impact, not duties

Don’t list responsibilities. Show results with numbers.

❌ “Built dashboards”
✅ “Built a React dashboard that reduced load time by 30% for 5,000 users”

Skills section matters more than you think

Add at least 5 relevant skills (JavaScript, React, Git, TypeScript, and so on). Profiles with multiple skills get way more profile views and connections.

Step 4: Show Proof (This Is Huge for Developers)

Words are good – but proof is better. Here's how you can show proof:

Use the Featured section

Add your portfolio website, a linke to your GitHub profile, and live projects or demos.

Ask for recommendations

These can be really helpful, and some companies require them. You can reach out to tech leads, managers you've worked with, or clients (among others).

Recommendations add massive trust.

Pro tip: offer to write one in return.

Step 5: Get More Visible

This is how you go from “searching” to being approached.

Post occasionally

You don’t need to be an influencer. But post something once a month could invite some people to see your page.

Network with intention

Networking is a skill. Follow devs and tech creators, engage with posts (comments > likes), and connect with engineers inside companies you like.

Turn on “Open to Work”

You can make it visible only to recruiters. This is a strong signal that you’re ready for interviews.

Practical checkpoint: If your LinkedIn profile still looks like a copied résumé, you’re leaving opportunities on the table. Treat it like a product page – clear message, strong proof, and easy next step.

And here's a tips: Make sure all information you list at your LinkedIn profile is true. Especially your full name and location. Sometimes LinkedIn admins may ask you to verify it with your real ID.

7. Job Search & Application Strategy

Up to this point, everything you’ve done was preparation. Now you’re ready for the real game: finding jobs and applying the smart way.

Let's start with where to find Developer Jobs.

There isn’t just one correct source. The best strategy is to combine several.

1. Job Boards (Fast but Competitive)

There are two main types of job boards:

Open Job Boards

Examples: LinkedIn, Indeed.

• ✅ You can apply immediately

• ❌ Competition is extremely high

• ❌ Many applications never get seen

These are good for volume, but don’t expect miracles.

Vetted Platforms

Examples: Turing.com, similar invite-only platforms

How it usually works:

1. Application review

2. Automated tests or questionnaires

3. Timed live task (90–120 minutes)

• ❌ Takes time and effort upfront

• ✅ Much lower competition afterward

• ✅ Higher chance of real interviews

If you pass, you enter a smaller talent pool, which is a big advantage.

2. Company Career Pages (Often Overlooked)

Many companies hire directly through their own websites. Big companies often have dedicated career pages. These may have fewer applicants compared to job boards, and they're usually more serious about hiring.

If you already like a company, check their site first.

3. Startups, Agencies & Communities (Hidden Gold)

This is where many developers get jobs without competing with hundreds of applicants.

Agencies

Find them on award sites, directories, or portfolios.

• Visit their websites

• Collect emails

• Send direct, personalized messages

Startups

Use platforms like Product Hunt.

• Find early-stage startups

• Reach out directly via email or LinkedIn

Telegram Groups (Very Underrated)

Many dev job groups exist but aren’t publicized much.

• Jobs are posted directly by founders or managers

• You can DM the person first, ask if you’re a fit

• Attach CV + portfolio

• If they say yes, then apply

This alone can save you weeks of wasted applications.

Here is a list top 50 remote first companies. These establishments always in search of great talent.

Application Strategies (Choose Wisely)

There are three main approaches.

1. Mass Application (Spray & Pray)

• Easy Apply, Easy Apply, Easy Apply

• 20–30 applications per hour

Reality check:

• ❌ Massive competition

• ❌ Very low response rate

Good for filling numbers – not great for quality.

2. Sniper Application (High-Conversion)

This is the most effective method.

How it works:

• Pick a specific company and role

• Research:

  • Product

  • Team

  • Tech stack

• Customize:

  • CV

  • Cover letter

• Try to:

  • Talk to employees

  • Ask for a referral

• ❌ Slower (1–2 applications/day)

• ✅ Much higher response rate

• ✅ Often leads directly to interviews

If you want fewer rejections and better offers, this is it.

3. Networking (Warm Opportunities)

This is the most natural and underrated approach, and there are a couple ways of going about it.

You can focus on offline experience, like:

• Local meetups

• Developer groups

• Tech events

When people know you personally, jobs often come to you.

You can also try online methods, like:

• Discord communities

• Reddit

• Twitter / LinkedIn tech circles

You can share that you’re job hunting, DM people directly and get referrals without formal applications.

This is warm outreach, not cold applying.

Track Everything (Very Important)

Just like mentioned earlier:

• Set weekly & daily application goals

• Adjust them to your real pace

Make sure you track the date, company, and status (sent, rejected, interview, offer). A simple spreadsheet is more than enough.

Practical checkpoint: Don’t rely on just one channel. Combine job boards + direct outreach + networking, track your efforts, and focus more on quality than pure volume.

There is a very useful job application tracker I use when applying to jobs. It helps you to see the entire picture of your progress. You can download it here.

8. Technical Interview Preparation

The technical interview is not a normal conversation — it’s closer to an exam + live performance. You’re not just talking about your skills; you’re expected to prove them in real time.

Step 1: Strong Technical Foundation

1. Master One Programming Language

Pick one main language (JavaScript, Python, Java, C++, and so on) and know it really well.

• Syntax should be automatic

• You shouldn’t struggle with basics during interviews

• This lets you focus on problem-solving, not syntax

2. Data Structures & Algorithms (Must-Have)

You should clearly understand:

• Arrays & strings

• Hash tables

• Stacks & queues

• Linked lists

• Trees & graphs

• Heaps

Important: don’t just know how, know why. For example: why a hash table gives average O(1) lookup time.

3. Real Side Projects

Have projects that match the level of the job you want, that are built from scratch, that use real logic, not tutorial clones, and be ready to walk through architecture, decisions, and trade-offs.

This often shifts the interview from grilling to conversation.

Step 2: Pre-Interview Strategy (Once Interview Is Scheduled)

Now it’s about targeted prep.

Résumé Deep-Dive

Be ready to explain everything on your CV.

• Every framework

• Every project

• Every tool

If you listed it, you must defend it.

Behavioral Answers (STAR Method)

Use STAR:

• Situation

• Task

• Action (most important – what you did)

• Result

Use it for bugs you fixed, conflicts in teams, technical challenges, and failures and lessons learned.

Step 3: How to Act During the Technical Interview

This part matters as much as the solution itself.

1. Read & Rephrase

Read the task and repeat it in your own words. This shows clarity and avoids misunderstandings.

2. Clarify Everything

Ask about:

• Input format

• Output format

• Constraints

• Edge cases

Good engineers never assume.

3. Think Out Loud

Before coding, explain your approach, start with a brute-force solution, then optimize it. Interviewers care about how you think, not just the final answer.

4. Code Like a Professional

While coding, speak your thoughts, use clear variable names, and teat it like pair programming, not an interrogation

5. Test Your Code

When finished, walk through the code step by step, use example inputs, and try to catch bugs yourself. Debugging your own code is a huge positive signal.

6. Explain Complexity

Always finish with time complexity and space complexity.

Short, clear, confident.

Step 4: Closing the Interview Strong

Ask Smart Questions

When you're wrapping up, make sure you ask smart questions to show your genuine interest and thoughtfulness.

Ask about:

• Tech stack

• Architecture

• Development process

• Team collaboration

Avoid salary or benefits here – that’s for HR.

Send a Follow-Up

Within 24 hours, thank them and show appreciation.

If you realized you made a mistake, you can briefly explain the correct approach – this shows growth mindset.

Learn From Every Interview

Even failed interviews are data. After each one, ask yourself:

• Where did I get stuck?

• What topic do I need to improve?

Practical checkpoint: You don’t pass technical interviews by luck. You pass them by deep fundamentals, structured thinking, and practice.

9. HR and Behavioral Interview

The HR / behavioral interview is not just a formality. Very often, this round decides whether you move forward or not.
Unlike technical interviews, this one is about who you are, how you communicate, and whether the team can work with you long-term.

Step 1: Pre-Interview Research (Do Your Homework)

Before the interview, go deeper than your CV.

Research the company

Learn about their mission and values, their product or service, and any recent news, releases, or updates involving them.

This helps you sound intentional, not generic.

Study the job description

Make sure you highlight your soft skills and responsibilities, and then prepare 2–3 real examples that match those requirements.

Build a story bank

Prepare 8–10 short stories from your experience that demonstrate:

• Solving a problem

• Working in a team

• Handling conflict

• Taking ownership

These stories are your proof. Much better than buzzwords.

Step 2: Use the STAR Method (Always)

Remember the STAR method we talked about above? Use it here, too.

Also, think out loud. HR wants to hear how you reason, not just the final answer.

And practice explaining technical things without jargon. HR people are usually non-technical.

Step 3: Common HR Questions (How to Answer)

“Tell me about yourself”

Keep it to ~2 minutes.

Focus on your current role or level, your main tech stack (for example, JavaScript, React, SQL), and where you want to grow next.

Skip personal life unless asked.

Strengths

Pick role-relevant strengths here and back each one with a quick example.

Example:

“I’m strong at ownership. In my last role, I took responsibility for…”

Weaknesses

This is a tough one. So be honest, but smart. Show self-awareness + improvement, and avoid clichés like “I’m a perfectionist”.

Good structure:

• Real weakness

• What you’re doing to improve it

Step 4: Teamwork, Conflict & Feedback

Web development is teamwork-heavy, so expect these.

• Conflicts

  • Don’t blame others

  • Focus on communication and resolution

  • Show maturity and accountability

• Code reviews & feedback

  • Treat feedback as growth

  • Show you don’t take criticism personally

• Mistakes

  • Admit them

  • Explain how you fixed the issue

  • Share what you learned

This signals professionalism and emotional intelligence.

Step 5: Closing the Interview + Salary Questions

Always ask questions

Good examples:

• What does success look like in the first 3 months?

• How does the team collaborate?

• What do you personally enjoy about working here?

Saying “I have no questions” is a bad signal.

Salary expectations

If possible, avoid giving a number too early.

If pushed, give a range, not a single number. And make sure you base it on market research. Also, say it’s negotiable. All this keeps leverage on your side.

Step 6: After the Interview (Don’t Skip This)

Similar strategies here:

• Send a thank-you email within 24 hours

• Thank them for their time

• Reconfirm your interest

Simple, polite, professional.

Practical checkpoint: Technical skills get you noticed. Behavior, communication, and attitude get you hired.

Tip: Before EVERY interview even a first one I always contact HR or recruiter and ask what should I prepare for the interview round. Surprisingly, almost every time I get specific directions.

I always use interview checklist when I prepare for one. It helps you remember all critical points. You can download it here.

9. Salary Negotiation and Job Offers

Congrats — getting an offer means you already won half the battle. Now comes the part where many developers make costly mistakes: accepting too fast or negotiating poorly.

Let’s break this down step by step.

1. When You Receive an Offer: Pause First

When you hear “We’d like to make you an offer”:

• Say thank you

• Show excitement

• Do NOT accept immediately

This is very important.

What to say instead:

• Ask for the offer in writing

• Request 24–48 hours (sometimes up to a week) to review it

This is completely normal and professional. The pause helps you move from emotions to logic.

2. Look at Total Compensation (Not Just Salary)

Many developers only look at base salary, but that’s a mistake.

Check the full package for things like:

• Base salary

• Health insurance (medical, dental, vision)

• Retirement plans (401k, matching, vesting period)

• Equity (stock options / RSUs)

• Bonuses (sign-on or performance)

• Remote / hybrid flexibility

• Equipment budget

• Learning budget

Sometimes a lower salary + great benefits is actually the better deal.

3. Salary Negotiation Rules (Very Important)

Rule #1: Don’t Give the First Number

If possible, avoid saying a salary number first.

Why? Because employers will anchor low, and you lose leverage immediately.

If asked early, say something like:

“Right now I’m focused on finding a strong mutual fit. I’m open to a fair market offer once we’re aligned.”

If You MUST Give a Number

Give a range, not a single number. Your ideal salary should be at the lower end of that range

4. Advanced Negotiation Tips (Most Devs Skip This)

Negotiation Is Expected

About 80%+ of companies expect negotiation. It doesn’t make you difficult – it makes you look confident.

Use Other Offers (If You Have Them)

If you have another offer, be honest and respectful about it.

Example:

“You’re my top choice, but I have another offer that’s slightly higher. Is there room to adjust?”

Negotiate Non-Money Items

If salary is capped, try asking instead for extra vacation days, a sign-on bonus, a learning budget, or a faster salary review (after 6 months).

Managers often have more flexibility here.

5. Final Step: Close Everything Properly

Before accepting:

• Get everything in writing

• Read the contract carefully

• Check:

  • Job title

  • Salary & bonuses

  • Notice period

  • Non-compete clauses

In many countries, verbal acceptance can be legally binding. Don't say “yes” unless you are 100% sure.

If you reject an offer:

• Be polite

• Thank them

• Keep the relationship open

You never know when paths cross again.

Practical checkpoint: Your first offer sets the baseline for your future career. Take your time, stay professional, and don’t be afraid to negotiate.

Real story: In 2021 I received a very nice job offer. I liked it. The CEO said: “Here is the salary range: A to B. What would you like?“. I said let’s go with middle point. I always prefer win-win situations.

Conclusion

Getting a web developer job today is not about luck – it’s about strategy, preparation, and consistency. The market has changed. Competition is higher, expectations are clearer, and companies are more selective than ever. But the good news is that developers who approach the process the right way still get hired, again and again.

In this guide, you’ve seen the full journey: defining your direction, preparing your skills, building a strong portfolio, crafting a clear CV and cover letter, optimizing LinkedIn, applying smart, preparing for technical and HR interviews, and finally negotiating your offer with confidence. Each stage matters, and skipping even one can significantly lower your chances.

Remember: job searching itself is a skill. The more intentional you are, the better your results will be. Track your progress, learn from rejections, improve weak spots, and don’t rush the process. One strong offer is worth more than a hundred rushed applications.

Most importantly, don’t underestimate your value. If you’ve put in the work, you deserve a role that fits your skills, goals, and lifestyle.

I wish you the best of luck on your journey. Stay consistent, stay confident, and go get that job 🚀

p.s. if you still haven’t you can get Dev Job Application Toolkit here: 99cards.dev/toolkit

We talk about:

• Tips for busy parents who want to learn new skills.

• How AI tools are no substitute for your own critical thinking and problem solving skills.

• How even though it's getting easier every day to learn programming for free, people are so distracted, and for many it feels harder and harder to sit down and do it.

Support for this podcast is provided by a grant from AlgoMonster. AlgoMonster is a platform that teaches data structure and algorithm patterns in a structured sequence, so you can approach technical interview questions more systematically. Their curriculum covers patterns like sliding window, two-pointers, graph search, and dynamic programming, helping you learn each pattern once and apply it to solve many problems. Start a structured interview prep routine at https://algo.monster/freecodecamp

Support also comes from the 10,338 kind folks who donate to our charity each month. Join them and support our mission at https://donate.freecodecamp.org

Get a freeCodeCamp t-shirt for $20 with free shipping anywhere in the US: https://shop.freecodecamp.org

Watch the podcast on the freeCodeCamp.org YouTube channel or listen on your favorite podcast app.

Links from our discussion:

• Article about AI and product management (which includes some blunt takes from Quincy): https://thenewstack.io/for-devs-a-fix-for-ai-complexity-is-hiding-in-plain-sight/

• Andrea's weekly newsletter: https://mainbranch.beehiiv.com/

• Learn How to Learn course by Dr. Barbara Oakley: https://www.classcentral.com/course/learning-how-to-learn-2161

Community news section:

1. freeCodeCamp just published this beginner-friendly back-end development course. You'll learn how to build your own web servers and APIs using Node.js, Express, and MongoDB. freeCodeCamp's website and mobile apps are built using these tools, which make up the popular MERN stack. You'll also get some exposure to database architecture, security principles, testing best practices, and more. (2 hour YouTube course): https://www.freecodecamp.org/news/intro-to-backend-web-development-nodejs-express-mongodb/

2. freeCodeCamp also published a comprehensive Blender and Three.js course where you'll build your own 3D portfolio piece: a render of an adorable home office. If you're interested in 3D rendering and computer graphics, this is the course for you. You'll learn key concepts like Quad Topology, Raycasting, OrbitControls, and more. By the end of the course, your 3D model will be live on the web so you can share it with your friends. (9 hour YouTube course): https://www.freecodecamp.org/news/create-a-cute-room-portfolio-with-threejs-blender-javascript/

3. freeCodeCamp also published a handbook on using Docker with Node.js. You'll learn how to set up Docker and Docker Compose. You'll also learn fundamental concepts like Volumes, Images, and Containers. This is an excellent resource for you to read through and code along with. Bookmark it for future reference. (full length handbook): https://www.freecodecamp.org/news/how-to-use-to-docker-with-nodejs-handbook/

4. Level up your JavaScript implementation skills with this new freeCodeCamp course on Clean Code. You'll learn how to detect “code smells” and refactor your JavaScript accordingly. You'll also learn how to use ESLint and Prettier to automate some of the more error-prone aspects of shipping code. (1 hour watch): https://www.freecodecamp.org/news/level-up-your-javascript-detect-smells-and-write-clean-code/

5. Classic text adventure games Zork I, II, and III are now open source with an MIT license. Microsoft has published their full source code on GitHub: https://github.com/historicalsource/zork1

6. Today's song of the week is 1985 classic "Something About You" by Level 42. I love the slap bass, the vocal harmony, the falsetto, and the huge synth sounds. It's impossible to listen to this song and still be in a bad mood: https://www.youtube.com/watch?v=zpdQQoc-gkk

Then I came across the term Creative Technologist and realized, "Oh, so that's what I've been doing."
Even though my tech career path isn't totally defined yet (the tech world is constantly evolving), I've discovered a niche where my skills naturally fit together: merging code, culture, and creativity.

That is what being a creative technologist entails. If you've ever wondered if you could combine technical talents with creativity, this article will explain what the role is, what skills are required, and why it's becoming more important than ever.

Table of Contents

• What Does a Creative Technologist Do?

• Key Skills Every Creative Technologist Needs (with Examples)

• How Is This Different From UX?

• Why Creative Technologists Matter More Than Ever

• Conclusion

What Does a Creative Technologist Do?

A creative technologist is someone who combines technical knowledge with creative intuition to turn ideas into usable digital experiences. Think of a creative technologist as a bridge builder, someone who links storytelling, design, and technology to enable innovation.

Some people jokingly label them "jacks of all trades." In actuality, they are more like translators, ensuring that creativity and code communicate well.

Key Skills Every Creative Technologist Needs (with Examples)

Unlike traditional roles, a creative technologist’s skill set is hybrid and exploratory. Here are some of the most important skills, with examples from my own journey:

Technical Know-How

A creative technologist must have enough technical knowledge to work across multiple mediums. This is not about knowing every programming language, but about being able to choose the best tool for the job. It's the toolset that enables experimenting.

• Web development (HTML, CSS, JavaScript, or frameworks like React and Django)

• Mobile app development (Flutter, React Native, or Swift/Kotlin basics)

• Design and prototyping tools (Figma, Canva, or Adobe Suite)

• Low-code/no-code platforms (WordPress, Wix, Webflow, or Bubble)

Example:** In my own projects, I’ve switched between Python/Django for custom builds and WordPress/Wix for quick websites. Having that range of technical fluency means I can adapt to different project needs without being stuck in one medium.

Creative Prototyping

This is the process of immediately turning ideas into real experiments, rather than waiting for a finished product. It's less about the tool and more about the mindset: hacking, sketching, and testing to discover what's feasible.

Example:** For my undergraduate project, I built a prototype African literature e-book reader using Python and Django. It wasn’t just code, it was an experiment in accessibility and cultural preservation.

Cultural and Contextual Thinking

Identifying points of intersection between technology and culture, as well as asking how products serve human needs beyond functionality.

Example: On my Substack blogs (The Pop Radar and Story & Scene), I wrote about how pop culture sparks tech innovations, like Jennifer Lopez’s dress influencing the creation of Google Images.

Translating Between Worlds

Acting as a bridge between highly technical teams (developers) and highly creative teams (designers, writers, marketers).

Example: I worked with startups where I turned business ideas into creative assets, like building branded websites with Wix and WordPress, while also shaping their visual storytelling through graphics and video.

Storytelling and Experimentation with Technology

Creative technologists use tools, from design and video to AI, AR, and Web3, to communicate ideas in fresh ways and to explore how new technologies can expand the creative process.

Example: I’ve collaborated with AI tools like ChatGPT and DALL·E in content production. I used them for research, brainstorming ideas, and shaping the plot for a social media brand identity ad. I’ve also created humorous explainers on Web3 that broke down intimidating tech concepts using cultural analogies. In both cases, technology became a way to experiment, simplify, and tell better stories.

If you’re wondering how to start building these skills, you don’t need a formal education. Many creative technologists begin by experimenting on their own, taking online courses, prototyping small projects, writing about culture and tech, or contributing to open-source work. What matters most is curiosity and a willingness to explore where creativity and technology overlap.

How Is This Different From UX?

It’s a fair question because creative technologists and UX designers often work side by side. But the focus is slightly different:

• UX/UI designers are concerned about usability and aesthetics. Their main job is to ensure that a product is user-friendly, accessible, and visually appealing. They conduct user research, generate wireframes, design interfaces, and test how real users interact with a product.

• Creative technologists sit at the intersection of creativity and technology. Instead of simply improving an app's flow, they tackle bigger questions: What could this product be? How does it connect with culture? What new technology or mediums could make this experience more interesting?

  They experiment, prototype, and occasionally even code to make ideas a reality.

Think of it this way:

• A UX designer might redesign a fintech app to make it easier to use.

• A creative technologist might question why everything in the Nigerian tech ecosystem is fintech, then prototype an app that connects new homeowners with nearby handymen, plumbers, electricians, and other essential services.

By paying attention to cultural and everyday needs, creative technologists can spark innovation in areas that are often overlooked. While UX is a defined role with clear processes, creative technologist is an umbrella role that blends design, code, experimentation, and cultural insight.

Why Creative Technologists Matter More Than Ever

So why is this hybrid role even necessary? The tech world is rapidly evolving. With AI automating many repetitive coding and design activities, the future belongs to those who can bridge the gap across disciplines.

To put it simply, a creative technologist is someone who can translate abstract creative thoughts into practical products, understands the culture in which technology exists, and can construct or prototype when necessary. In a world where roles are increasingly multidisciplinary, this blend of skills isn’t optional, it’s essential. Designers may concentrate on interfaces, developers on backend logic, and writers on narrative. However, the creative technologist sits at the intersection, ensuring that all of these pieces come together to build something innovative and human-centered.

Because the role is fluid, there isn’t a standard “creative technologist salary.” Pay varies depending on the core job, such as design, development, or innovation strategy. Someone in an agency, for example, may be paid like a UX designer, whereas in a huge tech business, they may be compensated more like a product developer or innovation lead.

Conclusion

“Creative technologist” isn’t a rigid job title. It’s an umbrella term for anyone combining creativity and technology in meaningful ways. Whether through coding, design, research, or storytelling, the value lies in bridging gaps, asking new questions, and building solutions that resonate with people.

As someone who has successfully transitioned to a Staff Engineer role, I want to share my insights and experiences to help you on this journey.

In this article, I’ll address key questions you might have, like:

• What is a Staff Engineer and how does the role differ from a Senior Engineer?

• What do you need to become a Staff Engineer?

• How do you know you’re ready?

• Who do you talk to for guidance?

I’ll also share my personal story and a structured six-month plan to help you achieve your goals. Let’s dive in!

If you’d also like to watch this as a video, check this out:

Here’s what we’ll cover:

1. My Path to Becoming a Staff Engineer

2. What is a Staff Engineer?

3. Story Time: Building Font Selection in Slack

4. The Key Differences between Staff Engineers and Senior Engineers

   • Staff Engineer vs Manager Role

5. Why You Might Not Be Promoted Yet

6. How to Become a Staff Engineer

7. Evaluation Criteria

8. How to Build Your Staff Engineer Portfolio

9. The Promotion Process

10. A Six-Month Plan to Get Promoted

11. Wrapping Up

My Path to Becoming a Staff Engineer

Over the last decade, I’ve worked at companies like PayPal and Slack, progressing from a Junior web developer to a Staff Engineer. Here’s a quick timeline:

• Junior Web Developer at Telus Communications in 2013

• Web Developer at Pix System in 2017

• Software Engineer 2 at PayPal in 2018

  • Promoted to Senior Software Engineer in 2019 and later Staff Engineer in 2021.

• Lead Member of Technical Staff at Slack in 2022

  • Worked for three years before transitioning to full-time content creation.

One key lesson I’ve learned: It’s not just about what you do – it’s about who knows what you do.

What is a Staff Engineer?

A Staff Engineer is a technical leader who drives their team’s effectiveness. You’re judged not only by the features you deliver but also by how you enable and grow your team. It’s not just about code anymore. Staff engineering is a blend of technical expertise, leadership, and mentorship.

The Four Pillars of Staff Engineering:

1. Technical excellence: Staff Engineers build scalable systems, evaluate technologies, and make critical technical decisions while managing technical debt.

2. Organizational impact: They solve problems that extend beyond their team, acting as the communication link between various stakeholders.

3. Mentorship and team development: Staff Engineers grow their team by helping others succeed, onboarding new members, and leveling up their colleagues.

4. Project leadership: They ensure projects are delivered on time, breaking down complex problems into manageable pieces while leading cross-functional initiatives.

Story Time: Building Font Selection in Slack

As a Staff Engineer, I’ve had the privilege to work on some truly exciting projects. Not only have these opportunities helped me grow my technical expertise, but they’ve also taught me critical interpersonal skills – like team coordination, estimation, overcoming imposter syndrome, managing burnout, and effective delegation. These are essential qualities for any engineer looking to advance their career.

One standout project was the Font Selection feature in Slack. On the Appearance tab in Slack’s Preferences, users can now select a font – let’s say, Comic Sans – and instantly see the change reflected everywhere in the application.

This project was a classic example of a greenfield initiative: it had never been done before in Slack. That meant navigating technical debt, considering migrations to new systems, and sometimes deprecating outdated components. It also required collaboration with teams across the organization, because the blast radius of a feature like this was huge. The work impacted not just one area, but the entire user experience.

Being a technical leader on such a project was both challenging and rewarding. It stretched my skills and reinforced the importance of cross-functional teamwork and technical vision in delivering high-impact features.

The Key Differences between Staff Engineers and Senior Engineers

Senior Engineers are excellent executors who can take complex requirements and turn them into working software. They solve technical problems efficiently and mentor junior developers on their team.

Staff Engineers are strategic thinkers who identify what problems need to be solved in the first place. They look across the entire organization to find opportunities for impact and then create projects to address them.

Senior Engineers are typically assigned projects by their manager or team lead and work on priorities set by their leadership. They excel at executing defined work and solving complex problems within their domain.

Staff Engineers, however, operate on a bigger scale beyond their team. They proactively look for improvements in the engineering organization and code architecture. Rather than waiting for direction, they chart out a plan to improve the codebase – figuring out performance optimizations, analyzing customer feedback, enhancing developer productivity, reducing technical debt.

When Staff Engineers identify these improvement areas, they don’t just raise tickets or file requests. They take ownership of crafting solutions by defining a project scope, writing a tech spec, outlining deliverables and creating architectural designs. This shift from reactive to proactive work represents one of the key transitions in moving from senior to staff level.

Think of it this way: Senior Engineers are given projects, Staff Engineers make projects.

Staff Engineering isn't about being a better individual contributor. It's about multiplying the effectiveness of everyone around you and growing others.

Staff Engineer vs Manager Role

While Staff Engineers interview new candidates, mentor engineers, provide feedback, and chart out technical direction, their role significantly differs from a Manager-level position in most companies. Although some responsibilities overlap, there are key distinctions between these two career tracks.

Staff Engineers do not:

1. Participate in the hiring and firing decisions.

2. Have input in promotion process beyond providing feedback for the employee

3. Have direct reports

4. Hold formal management authority

The fundamental distinction:

• Staff Engineer: Technical leader who influences through expertise and mentorship

• Manager: Combines HR, technical, and project leadership with formal authority

In most organizations, Staff Engineering and Management represent two distinct career advancement paths, allowing technical professionals to grow in seniority and impact without transitioning into people management roles.

Why You Might Not Be Promoted Yet

Here are five common reasons holding people back:

Waiting to Be Told You’re Ready

Many people fall into the trap of waiting for their manager to tap them on the shoulder and say, "You're ready for promotion." This passive approach can keep you stuck for years. The reality is that nobody will come to you to hand you anything. Promotion committees don't promote people based on potential – they promote based on evidence of current performance at the next level.

Fix: Start performing like a Staff Engineer today. Take ownership of cross-team initiatives, mentor junior developers, and drive technical decisions. Share your accomplishments with the broader team.

When you act like a Staff Engineer consistently for 6-12 months and everyone knows how well you are performing, the promotion becomes a formality rather than a leap of faith.

Action Item: Identify one area where you can begin operating at Staff level this month. Whether it's leading a technical design review or mentoring a junior engineer, start demonstrating the behaviors you want to be recognized for. Share status updates on a regular cadence – daily or weekly depending on the team and project, and share challenges encountered and solutions developed. This will get you not only noticed, but also help to create a balance of self-promotion and knowledge sharing.

Believe in yourself – don’t wait for external validation.

Imposter Syndrome

That voice in your head saying "I'm not smart enough" or "I don't know enough" is imposter syndrome. Everyone feels like an imposter at some point. But successful people take action DESPITE feeling like an imposter.

If you let imposter syndrome dictate your actions or prevent you from taking action, you'll hold yourself back from achieving great things. The people you look up to online have also faced imposter syndrome. Most successful people encounter it weekly, if not daily. The difference is that they learn to set it aside and create a plan to move forward.

The Fix: Reframe your mindset. Instead of thinking "I don't know X," think "I don't know X yet." Focus on your growth trajectory, not your current knowledge gaps. Remember, you were hired for your potential, not because you already knew everything.

Action Item: Keep a "brag document" where you document your accomplishments weekly. When imposter syndrome strikes, review this evidence of your capabilities and impact. Over time, you'll notice that you overcame things that felt hard or impossible in the moment.

You can do hard things!

I made a detailed video highlighting strategies to overcome imposter syndrome. You can check it out here:

Waiting to Become a Deep Technical Expert

Many engineers think they need to know everything about every technology before they can get promoted. This "I must be perfect" thinking will hurt your career. Staff Engineers don't need to know everything. The most important skills you need to know is how to find answers and help others solve hard problems.

The Fix: Learn a little about many things instead of learning everything about one thing. A Staff Engineer who knows some things about databases, systems, and websites will be able to perform and help more effectively than someone who only knows one thing really well. You'll learn more when you work on big projects as a Staff Engineer.

Action Item: Pick 2-3 tech areas that you don't know much about but your company uses, or pick a new tech stack. Spend 30 minutes each week learning about each one. Focus on how they work with the systems you already know.

If you don’t believe in yourself, why should others?

Avoiding Politics

Many engineers think that talking about their accomplishments is "playing politics" and they don't do it. This will ruin their career. Telling people about your wins isn't boastful bragging – it’s necessary. Your boss and the promotion committee can't help you if they don't know what you did.

The Fix: Reframe self-advocacy as data sharing. You're providing factual information about your impact to help leadership make informed decisions. Create a monthly update template that includes: projects completed, problems solved, metrics improved, and people mentored. You are sharing facts, not making up stories.

Action Item: Start a bi-weekly email to your manager highlighting your key contributions. Include specific metrics when possible: "Reduced API response time by 40%, impacting 10,000 daily users" rather than "Improved API performance."

If you don’t toot your own horn, who will?

Struggling with Networking

Internal networking feels awkward to many engineers, but it's crucial for Senior-level and Staff-level promotion. Staff Engineers need to influence across the organization, which requires relationships with people beyond their immediate team.

The Fix: Approach networking as building genuine professional relationships rather than transactional interactions. Start with curiosity about others' work. Ask questions like "What are the biggest technical challenges your team is facing?" or "What would make your team more effective?"

Action Item: Set a goal to have one coffee chat monthly with someone outside your immediate team. Focus on learning about their challenges and how your expertise might help. Share what you are working on and what goals you have in mind. These relationships often lead to collaboration opportunities that demonstrate your Staff-level impact.

How to Become a Staff Engineer

Every company's promotion process is different, but here are some general steps that work at most places:

1. Evaluate Yourself

Create a requirements document using your company's engineering ladder (or a publicly available template like the Block Engineering Career Ladder). Go through each requirement honestly and mark them as either "Achieving" or "Needs Work."

How to do it well:

• Be brutally honest with yourself. It's better to underestimate than overestimate your current level

• If something feels unclear, ask for examples of each requirement from your manager or other Staff Engineers

• Use concrete evidence from your work and links to PRs, not just your feelings about your abilities

• Update this document every 1-2 months to track your progress

Common mistake: Being too generous with your self-assessment. If you're not 100% confident you're "Achieving" something, mark it as "Needs Work."

2. Discuss Gaps with Your Manager

First, schedule a one-on-one meeting with your manager to review your evaluation. Work together to identify specific projects that can help you grow in areas where you need improvement. This meeting can feel painful, but it is extremely helpful in level setting. Request feedback on your assessment to see if they agree or disagree.

After evaluation with manager:

• Have 2-3 specific areas you want to focus on

• Ask about upcoming projects that could help you develop these skills

• Plan out a process for achieving those goals.

What to ask:

• "What projects in the next 6 months could help me develop [specific skill]?"

• "Who are the Staff Engineers I should learn from?"

• "What does success look like for someone at my level trying to get promoted?"

Follow-up: Send a summary email after the meeting with your agreed-upon focus areas and next steps.

3. Build a Support Squad

Promotion committees want to hear from multiple people about your impact. Your manager's opinion alone isn't enough. So it’s a good idea to build a support squad for yourself. These are people other than your manager, such as mentors, mentees, leadership folks or inspiring colleagues, who can vouch for your skills and impact during promotion discussions. These are essentially your “sponsors”.

Who to include:

• A skip-level manager (your manager’s manager) who can speak to your organizational impact

• Engineers who have worked with you on cross-team projects

• Engineers you've mentored who can talk about your leadership and teaching skills

• Staff Engineers from other teams who can validate your technical decisions

How to build these relationships:

• Volunteer for cross-team projects and initiatives

• Offer to help other teams with technical challenges in your area of expertise

• Attend company tech talks and ask thoughtful questions

• Share your knowledge through internal presentations or documentation

These relationships should be genuine, not transactional. Focus on offering value first.

4. Perform Like a Staff Engineer

Promotion committees promote people who are already performing at the next level, not those who might be able to perform at that level. Start acting as a Staff Engineer now. Deliver impactful projects, mentor others, and take ownership of technical decisions.

How to get started:

• Pick one area where you can start demonstrating Staff-level impact this month

• Volunteer for the next cross-team project or technical initiative

• Ask your manager if you can lead the technical design for an upcoming feature

• Start mentoring a junior engineer and document your impact on their growth

• Share knowledge through documentation, presentations, and code reviews

• Identify and address technical debt that impacts multiple teams

• Evaluate new technologies and make recommendations

Evaluation Criteria

To transition to Staff Engineer, you need to demonstrate consistent excellence across multiple dimensions. It helps to understand the evaluation criteria and take on projects that showcase the following -

Deep Technical Expertise

You’re expected to:

• Write detailed technical specs for others to follow.

• Define shared standards (e.g., caching layers, API contracts).

• Improve system-wide architecture across teams (e.g., microservices communication that lowers latency by 40%).

Examples of projects that exhibit these skills:

1. Architecting scalable, fault-tolerant systems (e.g., disaster recovery for payment processing).

2. Redesigning systems like user login to support 50M+ daily users with 99.99% uptime.

Problem Solving & Innovation

You’re expected to:

• Build reusable tools or frameworks widely adopted by others.

• Lead new tech adoption (e.g., Kubernetes, chaos engineering).

• Set engineering-wide standards through your innovations.

Examples of projects that exhibit these skills:

• Fixing infinity mirroring problem in video recording software. (I did this and filed my first patent!)

• Solving memory leaks or production crashes.

• Creating innovative solutions that reduce cost or improve performance

Technology Leadership

You improve the team's quality standards and lead technical decisions, such as by-

1. Making thoughtful buid-vs-buy decisions

2. Reducing technical debt

3. Establishing best practices and ensure team follows them

4. Leading tech migrations while ensuring 0 downtime.

5. Giving helpful, educational code review feedback

6. Setting team-wide coding, testing, and review standards

7. Creating templates, guides, and documentation that improve efficiency.

Mentoring Engineers

You help other engineers grow by:

• Guiding junior/mid-level engineers through complex systems.

• Reviewing designs and code thoughtfully.

• Teaching system design, architecture, and debugging skills.

You might:

• Create learning plans (e.g., 6-month onboarding curriculum).

• Host workshops (e.g., debugging production, distributed systems).

• Help others think like system designers.

• Help other engineers get promoted.

How to Build Your Staff Engineer Portfolio

Think of your portfolio as your promotion story. It should represent your accomplishments over the past 12–18 months, backed by clear proof. You’re not just showing what you’ve built – you’re showing how you think, how you lead, and the impact you’ve made.

What to Include

Your portfolio should be 10-15 pages that tell a compelling story about your technical leadership. Here’s what makes a strong Staff Engineer portfolio:

• Executive summary: One-page overview highlighting your most significant contributions

• Technical leadership projects: 3-4 major initiatives presented as detailed case studies

• Metrics dashboard: Quantified impact across performance, cost savings, and adoption rates

• Peer testimonials: External validation from engineers across different teams

• Growth trajectory: A 12–18 month view of how your scope and influence have grown.

How to Structure Each Case Study

Each case study should follow a structured format that tells a complete story. First, you’ll want to discuss the problem statement: what was broken? Who was affected? Why did it matter?

Then cover the technical approach you took. You can discuss the high-level architecture, key decisions, and trade-offs you considered. After this, you can discuss how you implemented everything – the timeline, how you coordinated your team, and any technical challenges you faced.

Finally, you’ll share your results and discuss the business and technical impact with before-after metrics. It’s also a good idea to share any lessons learned and talk about what you'd do differently and how it contributed to your growth.

The Promotion Process

Most companies use a committee-based approach where your manager advocates for your promotion using a comprehensive packet of evidence. The committee asks one simple question: Do we know this person and do we trust their credibility?

Your manager submits a promotion packet to the committee and you are evaluated against everyone else who is up for promotion. To help your manager put your best foot forward in front of the committee, I recommend that you build a promotion packet with your manager. This packet includes a few key components.

1. Career Plan & Engineering Ladder Evaluation

This is the same document that you have hopefully been working on with your manager for a while. This document maps your current performance against your company's engineering ladder criteria. This isn't just a self-assessment – it's a strategic document with concrete evidence for each competency level.

Key elements to include:

• Line-by-line evaluation against ladder criteria

• Specific examples and proof points for each skill area

• Clear demonstration of "Achieving" performance across all relevant categories

• Identification of any gaps and plans to address them

2. Portfolio & Proof of Accomplishments

Make sure your portfolio explains not just what you accomplished but the impact you made along with proofs. It should include:

1. Code examples and design documents

2. Finished projects and improvements you made

3. Feedback from users and coworkers

4. Comments from code reviews and awards you got

3. Brag Document

We’ve talked about this a bit already, but this detailed log serves as your professional highlight reel, demonstrating both quantitative metrics and qualitative growth over your review period.

Quantitative metrics to track:

• Pull requests created and reviewed

• Features delivered and timeline performance

• Code review discussions

• Bug fix rates and system improvements

• Performance optimizations achieved

Qualitative accomplishments to document:

• Technical leadership moments

• Cross-functional collaboration successes

• Mentoring and knowledge sharing contributions

• Innovation and creative solutions implemented

Growth documentation:

• New technologies learned and applied

• Leadership opportunities taken

• Feedback incorporation and skill development

4. Testimonials

Get recommendations from teammates, other departments, people you helped, and customers. Ask them to give specific examples.

Your packet should be organized, based on facts, and show how you've grown. Make it simple for the committee to see your value and for your manager to speak up for you.

A Six-Month Plan to Get Promoted

Here’s a structured approach to help you navigate your promotion:

Month 1: Evaluate Yourself

Review your company’s engineering ladder and assess your gaps. If they don't have one, use a publicly available career ladder.

Month 2: Create a Plan

Discuss your evaluation with your manager. Identify projects to address your gaps.

Month 3: Work on Impactful Projects

Start networking with your skip-level manager and other stakeholders.

Month 4: Gather Proof

Document your work, seek feedback, and build evidence of your contributions.

Month 5: Review Progress

Update your career doc and review it with your manager.

Month 6+: Keep Going

The process may take longer than six months, but persistence and structure will help you get there. Don’t worry if it does take longer – that doesn’t mean you’re not qualified or won’t make it. Keep working at it.

Wrapping Up

Promotion isn’t always about skills – it’s also about timing and organizational factors. If you’re feeling burnt out or unsure about continuing in tech, it’s okay to pause or reconsider your path.

Take charge of your career. Advocate for yourself and share your accomplishments. And if you need personalized guidance, book a one-on-one session coaching session with me to create a personalized plan for you: https://topmate.io/shrutikapoor08.

If you enjoyed this article, share it with someone you know and spread the love.

Connect with Me:

• YouTube: https://www.youtube.com/@shrutikapoor08

• Sign up for articles like this: http://bit.ly/shruti-newsletter

• Discord: bit.ly/shruti-discord

• Twitter: @shrutikapoor08

• Instagram: https://www.instagram.com/itsshrutikapoor/

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

After one of her kids got diagnosed with autism, she left her career for 3 years to be a full-time mom. She then re-entered the workforce and now teaches other moms how to do the same through a charity called Tech-Moms. She recently won a teacher of the year award and was a top 5 finalist in a data visualization competition.

We talk about:

• How Alyson taught herself programming while working as an accountant

• How she transitioned to data analyst and ultimately data engineer

• Tips for preparing for a break from work to take care of your family or address burnout

• How to re-enter with the workforce with gusto

Support for this podcast comes from the 11,384 kind folks who support freeCodeCamp through a monthly donation. You can join these chill human beings and help our charity's mission by going to donate.freecodecamp.org

You can watch the podcast on YouTube:

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:

• Alyson's new analytics consultancy: https://alysonla.com/

• The charity Alyson teaches at: https://www.tech-moms.org/

• Tech-Mom's Data class: https://github.com/Tech-Moms/data-analytics-course

• The petition site Alyson mentioned: https://playground-petition-portal-9cfaeecf.vercel.app/

• Alyson's Drake fan page: https://alysonla.github.io/drizzydrakefanpage/

• Alyson's matching game: https://alysonla.github.io/hubber-memory-game/

• Alyson substack: https://alysonsaiplayground.substack.com/

• The data visualization app Alyson that was a finalist in the recent competition: https://pixar-scroll-tale.lovable.app/

He dropped out of college but eventually worked as an engineer at IBM and has gone on to roles at many other companies, doing everything from software architecture to management. He runs CodeTV, a Bravo-style reality TV channel for developers.

We talk about:

• Jason's winding path into development from building websites for bands

• Teaching yourself programming by chasing your curiosity

• How in-person events gives you tacit knowledge that makes you a better engineer

• How a having broad range of skills ultimately helps you build better projects

Thanks to the 11,384 kind folks who support freeCodeCamp through a monthly donation. You can join these chill human beings and help our charity's mission by going to donate.freecodecamp.org

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:

• CodeTV: https://codetv.dev/

• The CodeTV YouTube channel: https://www.youtube.com/channel/UCnty0z0pNRDgnuoirYXnC5A

• Jason's website: https://jason.energy/

Jesse has created tons of tutorials over the years on YouTube and on freeCodeCamp. We talk about his coding journey, how the field has changed over the few years, and how hype has distorted peoples' perception of getting into code.

We talk about:

• Growing up in a one stop light town

• Teaching himself to code for free using freeCodeCamp

• How he created YouTube tutorials to inspire his kids, then got quite good at it

• How Jesse's early interest in Web3 lead him to needing to "dig himself out of the grave" of being "the NFT tutorial guy"

Support also comes from the 11,384 kind folks who support freeCodeCamp through a monthly donation. Join these kind folks and help our mission by going to 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:

• Jesse's tutorials on freeCodeCamp: https://www.freecodecamp.org/news/author/codeSTACKr/

• Jesse's course on how to set up and configure the VS Code editor: https://www.youtube.com/watch?v=fJEbVCrEMSE

We talk about his experience getting laid off as a dev, and how we prepared for his mid-career job search.

We talk about:

• How Caleb got laid off and went about landing his next developer job

• How most people sleep on networking and recruiters, but shouldn't

• Why Caleb is so serious about teaching system design concepts

• How Caleb pairs his deep focus with broad extracurricular learning through podcasts and white papers

Support comes from the 11,343 kind folks who support freeCodeCamp through a monthly donation. Join these kind folks and help our mission by going to 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:

• Caleb's course on Database Design: https://www.freecodecamp.org/news/database-design-full-course-43233664125b/

• Caleb's system design lecture playlist: https://www.youtube.com/watch?v=0e7yQ43bUtg&list=PL_c9BZzLwBRLSs6x50D5WIH76VCUxJs9E

• Caleb on LinkedIn: https://www.linkedin.com/in/calebcurry/

James grew up in Memphis. He was an athlete who played violin, and knew nothing about computer science but chose it as his college major. Since then, he's not only worked as a dev at Microsoft, FedEx and many tech startups. And he's given more than 100 talks at conferences about technical topics.

Support for this podcast comes from a grant from Wix Studio. Wix Studio provides developers tools to rapidly build websites with everything out-of-the-box, then extend, replace, and break boundaries with code. Learn more at https://wixstudio.com.

Support also comes from the 11,043 kind folks who support freeCodeCamp through a monthly donation. Join these kind folks and help our mission by going to https://www.freecodecamp.org/donate

We talk about:

• How coding a Harry Potter Trivia app launched James' developer career

• Getting laid off then getting back onto the bike

• How to go about getting a first developer job

• How to make a name for yourself through conference talks and creating tutorials

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:

James's website: https://www.jamesqquick.com/

Jevon's Paradox: https://en.wikipedia.org/wiki/Jevons_paradox

He's worked at Google and Microsoft. He runs the CS Dojo channel where he shares his insights on software development, AI, and developer career progressions.

We talk about:

• Emerging AI tools and how developers are adopting them

• The role of interest rates in developer hiring

• Japan's developer work culture VS the US

• How not to burn out

Can you guess what song I'm playing in the intro?

Also, I want to thank the 10,993 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:

• YK's freeCodeCamp article on the resume he used to get a job at Google: https://www.freecodecamp.org/news/heres-the-resume-i-used-to-get-a-job-at-google-as-a-software-engineer-26516526f29a/

• YK's freeCodeCamp article about leaving his job at Google to focus on entrepreneurship: https://www.freecodecamp.org/news/why-i-left-my-100-000-job-at-google-60b5cf4ebefe/

• YK's popular CS Dojo YouTube channel: https://www.youtube.com/c/CSDojo

• YK on Twitter: https://x.com/ykdojo

AGI refers to a type of artificial intelligence that has the ability to understand, learn, and apply knowledge across a wide range of tasks at a level comparable to, or even beyond, human intelligence.

Unlike narrow AI, which excels at specific tasks (like image recognition or playing chess), AGI would be able to perform any cognitive task that a human can, adapt to new situations, and improve its capabilities over time without human intervention.

The emergence of AGI would fundamentally change how we think about and interact with technology. For engineers, it means preparing for a world where intelligent systems can perform tasks autonomously, requiring new skills and approaches to software development.

Here are some key areas of work you can focus on now to help prepare you for the AGI era.

1. Mastering Machine Learning and Deep Learning

Engineers with expertise in these fields will be at the forefront of AGI development. Machine learning and deep learning are the building blocks of AGI, as they enable systems to learn from data, identify patterns, and make decisions.

To prepare for AGI, you need to go beyond the basics of supervised learning and explore more advanced areas like reinforcement learning, where agents learn by interacting with their environment, and unsupervised learning, which allows systems to find hidden patterns in data without explicit guidance. Neural networks, particularly deep neural networks, will play a critical role in enabling AGI to generalize across tasks.

Why should you learn these skills? AGI will require systems that can adapt and improve autonomously. Mastering these skills will help you understand how to create models that can handle complex, unstructured data and make decisions in real-time, which is essential for AGI.

How to prepare

• Take courses: Consider taking advanced courses on platforms like freeCodeCamp, Coursera, edX, or Udacity that focus on reinforcement learning, neural networks, and deep learning.

• Build projects: Build your own machine learning models and experiment with different types of data. Participating in Kaggle competitions can also help you hone your skills.

• Job titles to watch: Machine Learning Engineer, AI Research Scientist.

2. Software Engineering with a Focus on AI Integration

Traditional software engineering roles will evolve to integrate AI components seamlessly. This means developing frameworks that allow AGI to be incorporated into existing systems or creating entirely new systems designed around AGI capabilities.

What does this look like? Engineers might develop APIs that allow AGI to communicate with other software, create microservices that enable modular AGI deployment, or design platforms that facilitate continuous learning for AGI systems.

For example, integrating AGI into a customer service platform could involve building an interface where AGI handles complex queries while human agents focus on more nuanced tasks.

How to prepare

• Study: Learn how to design and implement AI components in software through courses and hands-on experience. Understanding cloud-based AI services like AWS SageMaker or Google AI Platform will also be beneficial.

• Practice: Work on projects where you integrate AI models into existing applications, such as adding a chatbot to a web service or incorporating predictive analytics into a mobile app.

• Job titles to watch: Full Stack Developer with AI specialization, AI Software Engineer.

3. Navigating Ethics and AI Governance

As AGI could pose significant ethical and governance challenges, roles focusing on the ethical implications, policy-making, and regulatory compliance will be crucial. This includes ensuring AGI systems operate within legal and ethical frameworks. Public as well as private sector experience will be valuable.

Key ethical concerns include issues like accuracy, accountability, and transparency. You can benefit from developing skills in critical thinking and understanding how to interpret data and statistics. These skills can be helpful when collaborating with policymakers.

How to learn

• Read up: Explore literature on how policy is formed at the institutional and governmental level.

• Take courses: Consider taking courses on statistics and ethics to grow a deeper understanding of model results. Here's one on the ethics of AI and ML for starters.

• Job titles to watch: AI Ethics Analyst, Policy Advisor for AI, Compliance Officer for AI Systems.

4. Evolving Human-Computer Interaction (HCI)

HCI will quickly transform into Human-AI Interaction Design. As AGI systems become more prevalent, they will need to interact with humans in intuitive and seamless ways. Companies will need interfaces where humans can interact with AGI systems effectively, built by engineers who understand cognitive psychology and UX/UI design for AI systems.

Engineers will need to design interfaces where AGI can explain its decisions, ask for clarification when needed, and understand human emotions and context.

For example, AGI in healthcare might need to provide doctors with explanations of its diagnoses while considering the doctor's expertise and the patient's emotions. Building skills in designing intuitive interfaces and interactions between humans and intelligent systems will help you to be highly successful in AGI integration.

How to prepare

• Take courses: Study HCI and UX design with a focus on AI systems. Platforms like Interaction Design Foundation and Coursera offer relevant courses.

• Build projects: Experiment with designing user interfaces for AI-powered applications. This could include developing conversational agents or creating dashboards that visualize AI decision-making processes.

• Job titles to watch: Interaction Designer for AI, User Experience Researcher for AI Systems.

5. Enhancing Autonomous Systems and Robotics

If AGI leads to more autonomous robots, engineers who can design, build, and program robots with AGI capabilities will be in demand. This includes understanding how AGI can enhance robotic functionality.

AGI has the potential to revolutionize autonomous systems and robotics by enabling machines to learn and adapt in real-time. This could lead to more advanced self-driving cars, drones, and robots that can perform complex tasks without human intervention.

AGI could allow robots to understand and navigate unstructured environments, learn from experience, and collaborate with humans more effectively. For example, an AGI-powered robot could assist in disaster relief by autonomously adapting to changing conditions and coordinating with human teams.

Working on autonomous systems, whether in robotics, self-driving vehicles, or drones, can provide practical experience with highly independent systems. These skills will be transferrable to managing and optimizing AGI-based autonomous agents.

How to prepare

• Take courses: Take robotics courses that cover autonomous systems, computer vision, and AI integration.

• Build projects: Work on robotics projects, such as building an autonomous vehicle or programming a robot to perform complex tasks.

• Job titles to watch: Robotics Engineer, Automation Specialist.

6. Pioneering Hardware Development for AGI

We'll need engineers working on specialized hardware that can support AGI. Technologies like neuromorphic computing chips or quantum computing might be necessary for the computational power AGI would require.

Neuromorphic computing involves designing chips that replicate the structure and function of the human brain's neurons and synapses. These chips could enable more efficient and powerful AI systems by processing information in ways that are closer to how the human brain works. Also, quantum computing could provide the processing power needed for AGI's complex calculations.

How to prepare

• Study: Learn about neuromorphic computing and quantum computing through specialized courses and research papers. Staying updated with developments from companies like IBM and Intel, which are working on neuromorphic chips, can also be helpful.

• Build projects: Experiment with hardware design, such as working with FPGAs (Field Programmable Gate Arrays) or exploring quantum computing platforms like IBM Q.

• Job titles to watch: Hardware Engineer for AI, Quantum Computing Engineer.

7. Securing the Future: Cybersecurity for AGI

AGI systems will introduce new security challenges. Engineers with expertise in cybersecurity will be in high demand to protect AGI systems from national security threats, ensure data privacy, and secure AI-driven decision-making processes against manipulation. There are also concerns about data privacy, as AGI systems will likely handle sensitive information across various domains.

How to prepare

• Take courses: Take cybersecurity courses focused on AI and machine learning security. Platforms like freeCodeCamp, Cybrary, and Coursera offer relevant courses. Here's a handbook that has some helpful insights, too.

• Practice: Engage in cybersecurity challenges, such as Capture the Flag (CTF) competitions, to develop hands-on skills in securing computing systems.

• Job titles to watch: AI Security Specialist, Cybersecurity Analyst for AI.

8. Data Engineering: Fueling AGI with Information

Handling large-scale data systems will be critical for AGI, as it will require vast amounts of data to learn and operate effectively. Data engineers will play a crucial role in building and maintaining the infrastructure that feeds AGI with the information it needs.

Data engineers will need expertise in big data technologies, such as Hadoop and Spark, and real-time data processing systems, like Apache Kafka. They will also need to ensure data quality and integrity, as AGI systems will rely heavily on accurate and comprehensive data to function effectively.

How will data engineers work with AGI systems? Data engineers will design data pipelines that can handle the immense scale of data AGI requires. This includes everything from data ingestion, storage, processing, and ensuring that the data is of high quality and usable for AGI models. They'll also need to implement systems for continuous data updates, enabling AGI to learn and adapt in real-time.

How to prepare

• Take courses: Take courses on big data technologies, data pipeline architecture, and real-time data processing. Platforms like freeCodeCamp, Udemy, and Coursera offer courses on tools like Apache Kafka, Spark, and Hadoop.

• Projects: Work on projects that involve large-scale data processing and pipeline development. Contributing to open-source big data projects can also be a great way to gain experience.

• Job titles to watch: Data Engineer, Big Data Architect.

9. Building Infrastructure for AGI

AGI will require robust and scalable infrastructure on a never-before-seen scale. Engineers with experience in cloud computing, distributed systems, and infrastructure as code (IaC) will be crucial in building the systems that support AGI.

AGI systems will likely operate on a global scale, requiring vast amounts of computational power and data storage. Engineers will need to design cloud-based infrastructure that can scale dynamically, handle high volumes of data, and ensure low latency for real-time processing. They will also need to consider the security and reliability of these systems.

How to prepare

• Take courses: Study cloud computing platforms like AWS, Google Cloud, or Microsoft Azure. Learning about distributed systems and IaC tools like Terraform and Ansible will also be beneficial.

• Obtain certifications: Earning certifications in cloud architecture (like the AWS Certified Solutions Architect) can help solidify your knowledge. freeCodeCamp has many free courses to help you study for AWS certs – like this one.

• Build projects: Work on setting up and managing cloud infrastructure for applications, experimenting with scalability and load balancing.

• Job titles to watch: Cloud Infrastructure Engineer, Systems Architect for AI.

10. Cross-Disciplinary Collaboration in the AGI Era

Working in roles that involve cross-disciplinary collaboration, such as roles in research or innovation labs, can provide engineers with the ability to think broadly and integrate knowledge from various fields. Knowledge in other fields can give you the ability to engineer products that help people in a niche you care about.

Combining skills from fields such as biology (for bioinformatics or synthetic biology with AGI) and psychology (for understanding human-AI interaction) will be vital in the AGI era. Engineers who can think broadly and collaborate across disciplines will be better equipped to tackle complex problems that require diverse perspectives. For instance, combining AGI with neuroscience could advance brain-computer interfaces.

How to prepare

• Networking: Engage with professionals from different fields by attending interdisciplinary conferences and joining relevant online communities.

• Take courses: Take courses or workshops in complementary fields, such as biology, psychology, or environmental science, to broaden your understanding. Here's a course on bioinformatics if you're curious.

• Build projects: Collaborate on interdisciplinary projects, such as developing AI models that incorporate insights from other domains.

• Job titles to watch: Bioinformatics Engineer, Environmental Data Scientist.

11. Education and Training for an AGI-Ready Workforce

As AGI transforms industries, there will be a growing need for educational programs that teach engineers how to work with AGI systems.

Education and training programs should cover a range of topics, from yet-undeveloped AGI techniques, safety protocols, policy-making, to interdisciplinary collaboration. Preparation for creating or leading education in AGI means becoming a continuous learner yourself. Also, training should emphasize lifelong learning, as AGI technology will continue to evolve rapidly.

How to prepare

• Create content: If you're an educator, consider developing courses or workshops focused on AGI-related topics. Collaborate with industry experts to ensure the content is relevant and up-to-date.

• Enroll in programs: Participate in advanced AI or AGI training programs, either through universities or industry-led initiatives. Stay updated with emerging trends by attending seminars and conferences.

• Job titles to watch: AI Curriculum Developer, Training Specialist for AI Technologies.

12. Shaping Regulations in an AGI-Driven World

Engineers working on regulatory technology (RegTech) will gain insight into compliance and governance, which will be critical as AGI evolves within legal frameworks. Understanding how to navigate and shape regulations will be vital.

Regulations could cover areas such as data privacy, transparency, accountability, and the use of AGI in various industries. Engineers working in this field will need to collaborate with policymakers, legal experts, and industry leaders to develop guidelines that balance innovation with responsibility.

How to prepare

• Study: Stay informed about current AI regulations and legal frameworks. If you're interested, consider pursuing a certification or degree in law or public policy with a focus on AI governance.

• Networking: Join industry groups like IEEE or think tanks that focus on AI policy and ethics. Engaging in discussions with policymakers can provide valuable insights into the regulatory landscape.

• Job titles to watch: Regulatory Engineer, Compliance Specialist for AI.

13. Research and Development (R&D) in AGI-related Areas

Finally, engineers who are involved in cutting-edge research in AGI, cognitive computing, or advanced AI labs will be directly contributing to and understanding the frontiers of AGI technology, giving them a head start in a world where AGI is a reality. These roles offer the opportunity to shape the future of AGI and explore new possibilities in artificial intelligence.

Get involved in R&D by joining research institutions, universities, or tech companies that focus on AGI development. Contributing to open-source AI projects or publishing papers on AGI-related topics can also help you establish yourself in the field.

How to prepare

• Research: Stay updated with the latest advancements in AGI by reading academic papers, attending conferences, and following thought leaders in the field.

• Collaborate: Work with academic or industry researchers on AGI projects. Participating in hackathons or research competitions can also provide hands-on experience.

• Job titles to watch: AGI Research Scientist, Cognitive Computing Engineer.

Future Job Titles

The transition to an AGI world will likely see a blend of these roles, where engineers might need to be polymaths, understanding not just one but multiple areas of technology and science. It's important to grow your technical skills, but also practice adaptability and continuous learning.

Be on the lookout for roles that might not directly mention AGI but are foundational in AI, machine learning, and related technologies. As you choose your next role, think ahead to how you can tailor your focus and future-proof your work for the AGI era.

Actionable steps

• Learn continuously: Make lifelong learning a priority by regularly updating your skills and knowledge through courses, certifications, and hands-on projects.

• Network: Build relationships with professionals in various fields to stay informed about emerging trends and opportunities.

• Adapt: Stay flexible and open to new challenges, as the AGI era will require engineers to adapt to rapidly changing technologies and environments.

Be on the lookout for roles that might not directly mention AGI but are foundational in AI, machine learning, and related technologies. As you choose your next role, think ahead to how you can tailor your focus and future-proof your work for the AGI era.