How to Build in Public and Get Noticed by Tech Recruiters
You don't have to wait until you land a tech job before you start showing what you can do.
One way to build visible proof of your skills is to build in public.
Build in public simply means working on a project openly and sharing parts of the journey — what you're learning, what you're building, what went wrong, what you changed and what you eventually created.
For someone trying to enter tech, this can turn an empty CV into a visible trail of work.
Your goal isn't to post every single thing you do.
The goal is to make it easier for a recruiter or hiring manager to see what you can do, how you think and what you've actually built.
What Does "Build in Public" Mean?
Imagine you're learning data analytics.
Instead of spending three months learning privately and only mentioning "SQL and Power BI" on your CV, you could build a small project and document the process.
For example:
Week 1:
"I’m learning SQL, so I'm analysing a small Nigerian e-commerce dataset."
Week 2:
"I cleaned 5,000 rows and found three interesting patterns."
Week 3:
"I struggled with JOINs today. Here's what finally made them click."
Week 4:
"I finished my dashboard. Here's what the data showed."
You have now created more than a certificate.
You've created a public record of your work.
Step 1: Pick One Tech Skill
Don't try to build in public around everything you're learning.
Choose one primary skill.
Examples:
Front-end development
Backend development
Data analytics
UI/UX design
Cybersecurity
Product management
Cloud computing
AI automation
Digital marketing
Technical writing
If you're learning several things, choose one as your main public project.
For example:
"I'm documenting my journey from beginner to junior data analyst."
That is much clearer than:
"I'm learning tech."
Step 2: Choose a Small Project
Your first project shouldn't take six months.
Start with something you can finish in 1–4 weeks.
Examples:
Data analyst
Build a dashboard analysing:
Sales
Customer behaviour
Social media performance
E-commerce orders
Public transport data
Sports statistics
Software developer
Build:
A to-do app
Expense tracker
Weather app
Portfolio website
Simple booking system
API-powered application
Cybersecurity learner
Build:
A home lab
Security checklist
Phishing-awareness project
Log-analysis exercise
Vulnerability assessment of a deliberately vulnerable lab
UI/UX designer
Create:
Mobile banking redesign
Food delivery app concept
Fintech dashboard
E-commerce checkout redesign
The project doesn't have to be revolutionary.
It needs to demonstrate your ability to solve a problem.
Step 3: Define the Problem Before Building
Don't start with:
"I want to build an app."
Start with:
"What problem am I trying to solve?"
Write down:
Problem: What is difficult or inefficient?
User: Who experiences the problem?
Solution: What are you building?
Tools: What technologies will you use?
Success: How will you know the project works?
For example:
Problem: Small businesses struggle to track daily expenses.
Solution: A simple expense-tracking dashboard.
Tools: Excel, SQL and Power BI.
Goal: Allow users to see spending by category and month.
Now you have a project with a purpose.
Step 4: Choose Where You Will Build in Public
You don't need to be everywhere.
Choose one primary platform and one place where people can inspect your actual work.
Useful for sharing:
Progress updates
Lessons
Project explanations
Career milestones
Industry observations
X
Useful for:
Short updates
Technical conversations
Networking
Developer communities
Sharing quick lessons
GitHub
Useful for showing actual technical work.
GitHub profiles can display your repositories, contribution activity, pinned projects and a profile README. GitHub specifically recommends using the profile to showcase work to hiring managers.
Personal portfolio
Use it as the central place where your best projects live.
A simple structure works:
Home → About → Projects → Skills → Contact
Step 5: Create a Public Build Log
You don't need to make every post sound impressive.
Document what is actually happening.
Use a simple format:
Day/Week X — What I'm building
What I worked on:
...
What I learned:
...
What went wrong:
...
What I'm doing next:
...
For example:
Week 2 of my data analytics project
Today I cleaned the customer dataset and discovered that several dates were formatted differently.
I initially tried to fix everything manually, which was a mistake.
I used a consistent date format instead and documented the cleaning process.
Next: I'll start analysing customer retention.
That is much more interesting than:
"Day 14 of learning data analytics. Keep going!"
Step 6: Show the Process, Not Just the Final Result
One of the biggest mistakes beginners make is posting only:
"I built this!"
Show the journey.
Post:
The problem
↓
Your first attempt
↓
The mistake
↓
What you learned
↓
The improvement
↓
The final project
This gives people evidence of your problem-solving process.
And it gives you more content without having to constantly invent new topics.
Step 7: Share Things You Actually Learned
You don't have to pretend to be an expert.
If you're a beginner, say you're learning.
For example:
"I finally understood SQL JOINs today. Here's the explanation that made it click for me."
Or:
"Three things I learned while building my first Power BI dashboard."
This approach can help other beginners while also demonstrating your understanding.
Teach what you know. Document what you're learning.
Step 8: Make Your Posts Useful
A build-in-public post should ideally give the reader something.
Instead of:
"I learned Python today."
Try:
"I learned how Python lists differ from tuples today. Here's the simple explanation I wish I'd had when I started."
Or:
"I analysed 10,000 sales records and found three patterns. Here's what surprised me."
Useful posts give people a reason to stop scrolling.
Step 9: Don't Fake Your Progress
This is extremely important.
Don't:
❌ Claim expertise you don't have
❌ Pretend a tutorial project was a client project
❌ Invent users or customers
❌ Invent project results
❌ Copy another person's project and present it as yours
❌ Use AI-generated code you don't understand
❌ Fake testimonials
If you followed a tutorial, say so.
If you modified the tutorial, explain what you changed.
If you used AI, explain how you used it and verify the result.
The point of building in public is to create credible evidence, not an impressive-looking fiction.
Step 10: Make Your GitHub Recruiter-Friendly
If you're pursuing a technical role, your GitHub profile should support the story you're telling publicly.
GitHub recommends creating a professional bio, profile README and showcasing your strongest projects. It also recommends pinning relevant projects so hiring managers can find them quickly.
For each important repository, include a useful README.
Explain:
What is this project?
What problem does it solve?
What technologies did you use?
What did you personally build?
How can someone run it?
What did you learn?
What would you improve next?
GitHub says a README is often the first thing visitors see when they open a repository and recommends using it to explain what the project does, why it's useful and how to get started.
Step 11: Pin Your Best Projects
Don't make a recruiter dig through 40 repositories.
Put your strongest work where it can be found quickly.
GitHub allows you to pin up to six public repositories or gists on your profile.
Choose projects that demonstrate different abilities.
For example:
Project 1: Data analysis
Project 2: Dashboard
Project 3: SQL project
Project 4: Real-world application
Project 5: Open-source contribution
Project 6: Personal project
Quality matters more than filling every available slot.
Step 12: Connect With People in Your Target Industry
Building in public isn't just about posting.
It's also about participating.
Find:
Recruiters
Hiring managers
Developers
Data analysts
Designers
Founders
Tech communities
Engineers working in companies you admire
Don't immediately send:
"Please give me a job."
Instead, contribute to conversations.
Comment on useful posts.
Ask thoughtful questions.
Share what you're building.
Congratulate people on genuine achievements.
Over time, your name becomes associated with the work you're publicly sharing.
Step 13: Make Your LinkedIn Profile Match Your Projects
If you're building publicly as a data analyst, your LinkedIn profile shouldn't still say:
"Student looking for opportunities."
Make your professional direction clear.
For example:
Aspiring Data Analyst | SQL | Excel | Power BI | Building Data Projects in Public
Your About section can explain what you're learning and what type of opportunities you're looking for.
Then connect your LinkedIn profile to your GitHub and portfolio.
Your online presence should tell one consistent story.
Step 14: Use a Simple Posting Schedule
You don't need to post five times every day.
Try:
Monday — Progress
What I worked on this week.
Wednesday — Lesson
Something I learned or struggled with.
Friday — Project
A feature, insight or result from the project.
Sunday — Reflection
What worked, what didn't and what comes next.
That's four useful posts a week.
If you cannot maintain four, post twice.
Consistency matters more than flooding people's feeds.
Step 15: Use This 30-Day Build-in-Public Challenge
Week 1 — Start
Day 1: Introduce yourself and your goal.
Day 2: Explain what you're learning.
Day 3: Choose your project.
Day 4: Explain the problem.
Day 5: Show your tools.
Day 6: Share your first attempt.
Day 7: Share what you learned.
Week 2 — Build
Day 8: Show progress.
Day 9: Explain a concept.
Day 10: Share a problem you encountered.
Day 11: Show how you solved it.
Day 12: Share a small result.
Day 13: Ask your audience a relevant question.
Day 14: Weekly progress recap.
Week 3 — Improve
Day 15: Show the current version.
Day 16: Explain something you changed.
Day 17: Share a mistake.
Day 18: Share a lesson from the mistake.
Day 19: Show another feature.
Day 20: Ask for feedback.
Day 21: Weekly recap.
Week 4 — Launch
Day 22: Explain what you're improving.
Day 23: Show the final features.
Day 24: Share your biggest lesson.
Day 25: Document testing.
Day 26: Publish your project.
Day 27: Share your GitHub/portfolio.
Day 28: Explain the project from beginning to end.
Day 29: Share what you would build next.
Day 30: Publish your full project retrospective.
At the end of the month, you don't just have 30 posts.
You have a documented project journey.
WHAT SHOULD YOU POST?
Here are 15 easy build-in-public post ideas:
"Why I decided to learn data analytics."
"My first day learning SQL."
"The first thing I struggled with."
"A concept I finally understand."
"The mistake I made today."
"How I fixed the problem."
"Three things I learned this week."
"My first dashboard."
"What I would do differently."
"Here's what I'm building."
"A feature I just added."
"The most confusing part of this project."
"What surprised me in the data."
"My final project."
"What I learned from building it."
THE RECRUITER-FRIENDLY PROJECT FORMULA
For every project, aim to have:
Problem
↓
Research
↓
Solution
↓
Tools
↓
Process
↓
Challenges
↓
Result
↓
Lessons
↓
Demo
↓
GitHub/Portfolio
This gives a recruiter something concrete to evaluate.
GitHub itself describes its profile as a way to showcase your work and contributions, and its resume guidance specifically recommends highlighting your strongest projects and making them easy for hiring managers to understand.
WHAT IF NOBODY NOTICES YOUR FIRST POSTS?
Keep building.
Your first few posts may get very little attention.
That's normal.
Don't judge the strategy by likes alone.
Track things such as:
Profile views
Relevant connections
GitHub visitors
Repository stars
Project feedback
Portfolio visits
Recruiter messages
Interviews
Collaboration opportunities
The real objective isn't to become famous.
It's to create enough public proof of your ability that when someone discovers you, there is something worth exploring.
THE SIMPLE FORMULA
You can remember build in public as:
LEARN → BUILD → DOCUMENT → SHARE → CONNECT → IMPROVE
Do that repeatedly.
Eventually, instead of telling recruiters:
"I'm passionate about technology."
you can show them:
"Here's what I've built, here's how I built it, here's what went wrong, here's what I learned and here's the result."
That is the real value of building in public.