A production bug
Reported by a user, reproduced from a vague description, fixed without breaking three other things.
Engineering Experience ProgramStop building tutorial projects.
Stop building tutorial projects.
Start working like an engineer.
Barmaj is a supervised engineering experience. You pick up real tickets on a codebase you did not write, refine and estimate them with your squad, open pull requests, and have them reviewed by senior engineers.
For developers who can already code. Applications are reviewed by a person.
The gap
You learned React. You built projects.
Nobody taught you how software teams actually work.
Every rejection email says the same thing in different words: we were looking for someone with more experience. The gap is not knowledge. It is everything that surrounds writing the code.
Tutorial world
Real engineering
The requirements are complete and unambiguous.
The ticket is ambiguous, and asking the right question is the job.
You start from an empty folder.
You start in a codebase somebody else wrote, with its own conventions.
You are the only person who will ever read the code.
A senior engineer reads every line and asks why you did it that way.
It works on your machine, so it is done.
It is done when it is reviewed, tested, merged and did not break anything.
You decide what to build and when.
Work comes from a backlog, gets refined, estimated and committed to a sprint.
Nobody disagrees with you.
Someone disagrees with your approach, and you have to make the case.
The engineering experience
One loop, run properly, over and over
This is not a syllabus. It is the loop a professional team runs every sprint, and you run it from the inside.
- 01
Backlog
Real work, written as tickets — bugs, features, debt.
- 02
Refinement
Read it, question it, find what the ticket does not say.
- 03
Planning poker
Estimate independently. Nobody sees a number before the reveal.
- 04
Sprint
A committed scope with a start and an end.
- 05
Development
A branch on your own fork of a codebase you did not write.
- 06
Pull request
Described well enough that a reviewer can start immediately.
- 07
Code review
A senior engineer responds within one business day.
- 08
Merge
It ships when it is right, not when you are finished.
- 09
Feedback
What you did well, what to change, and why.
- 10
Skill evidence
An attributed record, linked to the work that proves it.
Then it starts again, with a harder ticket.
How it works
Ten steps, and the last one is the point
Most of this is unremarkable to anyone who has worked on a team. That is exactly why it is worth doing before your first role rather than during it.
- 01
Apply
Tell us where you are and what you have built. A person reads it.
- 02
Get assessed
A short technical exercise, so squads start at a comparable level.
- 03
Join your squad
A small engineering environment with a mentor and a real backlog.
- 04
Pick up real work
A ticket from the backlog. Ambiguous, like every real ticket.
- 05
Refine and estimate
Question the ticket with your squad before writing any code.
- 06
Build
On a branch, in a codebase with conventions you have to respect.
- 07
Open a pull request
Written so a reviewer can start without asking you anything.
- 08
Get reviewed
A senior engineer responds within one business day.
- 09
Ship
Address the feedback, get it merged, and see it land.
- 10
Build your evidence
Every merge adds to a record of how you actually work.
Not tutorial projects
The work you have never been given
No blank folders. No finished specifications. No projects that exist only to be finished.
A legacy refactor
Code that works and nobody wants to touch. Change it without changing behaviour.
A feature request
Written by someone who is not an engineer, and missing the three details that matter.
A performance problem
Something got slow. Measure before you optimise, and prove it got faster.
Testing debt
A module with no tests and a history of regressions. Decide what is worth covering.
An architecture decision
Two reasonable options. Pick one, write down why, and defend it in review.
An incident simulation
Something is broken now. Diagnose under time pressure and communicate while you do.
Technical debt
A shortcut somebody took, and the argument about whether now is the time to pay it back.
Reviewing someone else
Reading code you did not write and finding the useful thing to say about it.
#128 · feature/retry-timeoutAdd retry to the payment client
Illustration of review style- Blocking
What happens if the provider times out here? Right now the caller gets a resolved promise and no data, which is indistinguishable from an empty result.
- Suggestion
The retry logic and the parsing are doing two jobs in one function. Splitting them would let you test the retry without a fixture.
- Nit
Naming — `data2` will not mean anything to you in six months.
First response within one business day. Every comment says whether it blocks.
Mentorship & code review
Senior attention on your actual work
This is the part you cannot get from a tutorial, a course, or an AI assistant that agrees with you. Someone experienced reads what you wrote and tells you what they think.
- Code review
- Line by line, on every pull request, with the reasoning attached.
- Architecture feedback
- Whether your design fits the system or fights it.
- Engineering feedback
- How you work, not only what you produced.
- Decision guidance
- How experienced engineers choose between two reasonable options.
Engineering growth
Your growth, backed by evidence from your actual work
Not a quiz score and not a certificate. Every claim about how you work points at the pull request that shows it, and a mentor can explain it to you in one sentence.
- No leaderboard, and no ranking against other members.
- No commit counts, no lines of code, no pull request totals.
- A level moves only when two different reviewers have seen it.
- You can read the evidence behind every level, and disagree with it.
Growth profile
Illustration — not a real member- TestingStrong
Added failure-path coverage nobody asked for, twice
- Requirement interpretationStrong
Asked what happens on timeout before building
- Code qualityDeveloping
Factoring improved across three consecutive PRs
- ArchitectureDeveloping
Chose the simpler option and wrote down why
- CommunicationConsistent
PR descriptions a reviewer can start from cold
- Response to feedbackStrong
Argued a point on the merits and changed the design
Packages
One programme, three levels of attention
What differs is how much senior time you get, not how much of the product you are allowed to touch.
Community
A squad, the backlog, refinement and planning poker. Peer review only.
$49 / month
- ✓A barmaj.dev email address
Mentored Engineer
RecommendedEverything in Community, plus senior review on every pull request within one business day.
EGP 750 / month
- ✓A barmaj.dev email address
Career Accelerator
Everything in Mentored Engineer, with same-day mentor review and monthly one-to-ones.
$249 / month
- ✓Same-business-day review
- ✓Monthly 1:1 mentorship
- ✓A barmaj.dev email address
Who Barmaj is for
You can already code. That was never the problem.
Barmaj is for developers who have the skills and none of the context. If you are still learning to write a for-loop, this is not the right time — come back when you have built something you were proud of.
✓A good fit
- You have built real things, alone, and they work.
- You keep getting told you need more experience.
- You have never had your code reviewed by someone senior.
- You have never sat in a refinement or estimated a ticket.
- You are self-taught, or a graduate without team experience.
- You are changing careers into engineering and can already build.
✕Not a fit — yet
- You are looking for a course that teaches you a language.
- You want someone to build a portfolio for you.
- You are expecting a role at a company at the end of it.
- You want a certificate rather than the work behind one.
- You cannot commit meaningful hours each week.
- You are under 18.
Barmaj is an engineering experience program. It is not a course, and taking part is not a role at a company. What you leave with is a record of how you work, and the experience of having worked that way.
What we will and will not claim
No testimonials yet, because there are no members yet
Barmaj is new. Rather than borrow credibility we have not earned, here is exactly what we commit to — and you can hold us to it.
A human response within one business day
Measured from the moment a pull request is ready for a person, in business hours. When reviewer capacity runs out we pause taking new members rather than let turnaround slip.
Every claim about you is explainable
If a mentor cannot explain a piece of evidence to you in one sentence, it does not get written down.
No ranking members against each other
No leaderboards, no commit counts, no lines of code. Those numbers reward the wrong behaviour and we do not collect them as scores.
Your work stays yours, on your own GitHub
Contributions happen on your account, so what you build is visible and verifiable without taking our word for anything.
When members finish their first projects we will publish what actually happened, including the parts that did not work — with their permission, and anonymised where they ask for it.
You don’t need another tutorial.
You need experience.
Applications are read by a person, and places are limited by how many pull requests we can review properly each week.
Apply to Barmaj