Junior Accelerator Sprint Plan
Junior Accelerator
Sprint Plan
A two-week guided sprint to ship your first real project with senior engineering support.
| Participant | [Your Name] |
| Sprint Lead | O.J. (Learn with O.J.) |
| Duration | 2 weeks (Monday to Friday x 2) |
| Start Date | The Monday after booking is confirmed |
| Time Zones | Sprint Lead: EST (US) · Participant: GMT/BST (UK) · 5-hour difference |
Getting Started
After your payment is confirmed, here's what happens next. I'll handle the setup so you can focus on getting ready to build.
Step 1: Connect
We connect on LinkedIn (if we haven't already) and I send you this sprint plan document. Read through it before we do anything else so you know what to expect.
Step 2: Share Your GitHub
Send me your GitHub username or a link to your profile. If you don't have a GitHub account yet, create one before we start. You'll need it for everything we do in this sprint.
Important: Your project repo will live in your GitHub account, not mine. This is your work and it needs to show up on your profile. You'll create the repo and add me as a collaborator so I can review your code and set up the project board.
Step 3: Schedule the Calls
We figure out a time window that works across our time zones (EST and GMT/BST, 5 hours apart). I'll create two Google Meet calendar invites:
- Kickoff / Sprint Planning (30 minutes, Day 1 of the sprint)
- Wrap-up / Sprint Retro (30 minutes, final day of the sprint)
Step 4: Set Up Your Repo
Before the kickoff call, you need to:
- Create a new public repository on your GitHub account (we'll name it during the kickoff call or you can use a placeholder name and rename it later)
- Add me as a collaborator: Go to your repo > Settings > Collaborators > Add people and enter my GitHub username (I'll share it with you after payment)
- Send me the repo link so I can confirm access and set up the project board after our kickoff call
Don't worry if any of this is new to you. I'll walk you through it if you need help. The point is to learn by doing.
What You Get
The Junior Accelerator is a structured two-week sprint designed to simulate the experience of working on a real engineering team with senior support. You'll define a project, break it into manageable work, build it, get feedback on your code and your thinking, and ship something real to GitHub.
| Component | Details |
|---|---|
| Kickoff Call | 30-minute Google Meet call on Day 1. We define your project scope together, break it into tickets, and create a plan of attack. You leave this call knowing exactly what to build and where to start. |
| Async Check-ins | LinkedIn DMs throughout the sprint. Ask questions, flag blockers, share progress. I respond within 24 hours and sooner during our established availability window. |
| Code Review | 1-2 asynchronous code reviews on your actual code. Real feedback on your approach, your thinking, your decisions. Not just "this works" but "here's how to think about this differently." |
| Pair Programming (if needed) | If you hit a particularly tough blocker, we can do a live pair programming session (up to 30 minutes) to work through it together. This is also an opportunity to learn debugging techniques and how to use a debugger effectively. |
| Wrap-up Call | 30-minute Google Meet call on the final day. We review what you shipped, clean up the README together, and draft a LinkedIn post about what you built and what you learned. |
What You Walk Away With
- A finished project on GitHub with clean code and a professional README
- A LinkedIn post about what you built and what you learned (content for your profile)
- The experience of working through a real build cycle with senior engineering support
- Practice communicating about your work the way engineers do on real teams
Sprint Structure
Week 1: Build
| Day | Focus |
|---|---|
| Monday | Kickoff call. Define the project, break it into pieces, assign the first ticket to yourself. Start building. |
| Tue - Thu | Heads-down building. Async check-ins as needed. Focus on completing your first ticket and moving to the next one. Ping me when you're stuck, not when you're uncomfortable. |
| Friday | End-of-week check-in (async). Share where you are, what's done, what's blocking you. I'll do the first code review over the weekend or early next week. |
Week 2: Ship
| Day | Focus |
|---|---|
| Monday | Review code review feedback. Address comments and continue building. If there's a tough blocker, this is a good time for a pair programming session. |
| Tue - Thu | Finish building. Write your README. Push to GitHub. Second code review if needed. |
| Friday | Wrap-up call. Review the shipped project together. Finalize README. Draft your LinkedIn post. Retro: what went well, what was hard, what you'd do differently. |
Communication Expectations
This section matters. How you communicate on a team is just as important as the code you write. Think of this sprint as practice for how you'll work with senior engineers on your future team.
When to reach out
- You've been stuck on something for more than 30 minutes and have already tried at least 2-3 approaches
- You're unsure whether you're heading in the right direction on a ticket
- You've finished a ticket and want to know what to pick up next
How to ask a good question
When you message me with a question, include three things:
- What you're trying to do (the goal, not just the error)
- What you've already tried (so I'm not suggesting things you've already done)
- What you think the answer might be (even if you're wrong, this shows me how you're thinking)
What I expect from you
- Push through the discomfort before reaching out. Being stuck is part of the learning and I need you to sit with it a little before asking for help.
- Be honest about where you are. If you're behind, tell me. If something doesn't make sense, say so. I'd rather know early than find out on the wrap-up call.
- Show up and do the work. I'm investing my time in this pilot because I believe you can do it. Meet me halfway.
Response times
- Async messages (LinkedIn DMs): I'll respond within 24 hours and faster during our agreed availability window
- Code reviews: Within 48 hours of submission
- Calls are scheduled in advance via Google Meet link (provided after booking)
The One Rule
Ship something. It doesn't have to be perfect. It has to be finished.
What Makes a Project "Real"
The difference between a tutorial project and a real project isn't complexity. It's decisions. In a tutorial, every decision is made for you. On a real team, you're handed a problem and you figure out the approach, make tradeoffs, defend your choices, and live with the consequences. The project we choose for this sprint has to pass that bar.
Every project selected for the Junior Accelerator must meet all seven of these criteria:
| # | Criteria | What This Means |
|---|---|---|
| 1 | Solves a real problem | The project exists because someone has a problem, not because a tutorial told you to build it. There's a clear answer to "who would use this and why?" that isn't "me, to learn React." |
| 2 | Requires real decisions | The participant chose the stack, the architecture, and the approach. They can explain what they considered, what they rejected, and what tradeoffs they made. A tutorial tells you to use Express. A real project requires you to decide whether Express is the right choice and defend it. |
| 3 | Has at least one surprise | Something came up during building that required a pivot, a scope adjustment, or a new approach. Real projects have surprises. If everything went exactly according to plan, it was probably a tutorial with extra steps. |
| 4 | Code reviewed by a senior | The code has been reviewed by a senior engineer and revised based on that feedback. This is visible proof that someone with experience evaluated the work and the junior responded to real engineering feedback. That's team experience. |
| 5 | README tells a story | The README includes a problem statement, the approach taken, key decisions and tradeoffs, lessons learned, and what they'd do differently. This is the difference between "I completed an assignment" and "I shipped a project." Hiring managers read READMEs before they read code. |
| 6 | Built under real constraints | A deadline, a defined scope, a set of deliverables tracked on a project board. Not "I'll add features forever." The two-week sprint and the ticket structure make it visible that there was a plan and it was executed. |
| 7 | Work was collaborative | The participant communicated about the work throughout: check-ins, questions asked, blockers flagged, feedback received and addressed. The project didn't happen in isolation. It happened in collaboration with a senior engineer, the same way it would on a real team. |
How We Track the Work
We use GitHub Issues and a GitHub Project board to track the sprint. This is the same kind of workflow you'll use on a real engineering team, just scaled down to one person and one project.
How it works
- I'll set up the GitHub Project board and create the issues (tickets) based on what we define together in the kickoff call
- Each ticket has a clear description of what needs to be built and what "done" looks like for that piece
- You move tickets across the board as you work: To Do, In Progress, In Review, and Done
- When you make a commit, reference the issue number in your commit message (e.g., "Add login form #2") so the work is linked to the ticket
- I'll walk you through all of this during the kickoff call so don't worry if it's new to you
Why this matters: When a hiring manager clicks into your GitHub and sees a project board with issues, commits linked to tickets, and a clear done column, that's a much stronger signal than just a repo with code in it. It shows you know how to work on a team, not just how to write code.
The code review and PR workflow
Code review happens through pull requests (PRs). This is how every professional engineering team reviews code and it's how we'll do it here:
- Create a branch for each ticket you're working on. Name it something descriptive like feature/3-add-login-form or fix/5-dashboard-layout
- Do your work on the branch and commit as you go. Reference the issue number in your commit messages (e.g., "Add login form layout #2")
- Open a pull request against main when you're ready for review. In the PR description, explain what you built and any decisions you made
- Tag me for review and I'll leave comments on the code. Some will be suggestions, some will be questions about your thinking, some will be things to fix
- Address the feedback by pushing new commits to the same branch. Reply to my comments so I can see your reasoning
- Merge when approved and move the ticket to Done on the project board
This workflow leaves a visible trail of feedback and iteration on your GitHub. Anyone looking at the repo can see that a senior engineer reviewed the code, left real feedback, and the junior addressed it. That's proof of team experience that no tutorial can replicate.
If you haven't worked with branches and pull requests before, don't worry. I'll walk you through it on the kickoff call and the first time you open a PR I'll guide you through the process.
Project Details
This section will be completed together during the kickoff call.
Project Name
[To be defined on kickoff call]
Problem It Solves
[To be defined on kickoff call]
Tech Stack
[To be defined on kickoff call]
Sprint Tickets
| # | Ticket Description | Status | Notes |
|---|---|---|---|
| 1 | [To be defined] | Not started | |
| 2 | [To be defined] | Not started | |
| 3 | [To be defined] | Not started | |
| 4 | [To be defined] | Not started |
Definition of Done
- Code is pushed to a public GitHub repository
- README explains what the project does, how to run it, your design decisions, and what you learned
- The project works (it doesn't have to be perfect but it has to run)
- LinkedIn post is drafted and ready to publish
Learn with O.J. · learnwithoj.com A working engineer helping other engineers level up.