binary semaphore
Learn.
stuck on a paper? sit with someone who has been there
Not a course, and not another playlist you will not finish. One person, one hour, on the exact thing that stopped making sense. You say which paper and where it broke, and we start there.
Bring the assignment, the lab sheet, the past paper, or the error you cannot get past.
You might be here because of
Which one are you?
the backlog
“I never really got it in second year”
You have papers you did not clear
The semester moved on without you and every new topic sits on top of the one you missed. We go back and find the actual floor, then build up from there. It is usually one idea, not twenty.
placement season
“I can write it, but I freeze when they ask”
You can do the work, not the interview
Writing code and explaining code are different skills, and only one of them gets tested in a room. We practise saying it out loud, on your own projects, until the answer is yours.
the agent wrote it
“it works, I just cannot explain any of it”
You shipped it with AI and there is nothing behind it
The assignment runs. Then the examiner asks why you used a hash map and the page is blank. We take your own code apart together until you can defend every decision in it, including the ones you did not make.
One question, taken apart
Someone asked us this
I built a chatbot over my college notes for my final year project. It answers confidently and it is wrong. Is the model bad?
Your question never meets your notes
Both get turned into embeddings first: long lists of numbers positioned so that similar meanings sit near each other. What gets compared is the numbers, not the words.
Closest is not the same as correct
Retrieval hands back the chunk that sits nearest your question in that space. Nearest usually means worded alike. The chunk that actually answers you can be further away, and it loses.
The model answers from what it was handed
It never sees the rest of your notes. It writes a fluent answer from the wrong three paragraphs, and fluency is not a signal of anything.
So it is almost never the model. It is your chunking or your retrieval, and you can find out which in ten minutes by printing what got retrieved before you blame anything else. That printout is what we would open first.
How it works
1
Tell us where it broke
Which paper, and the point it stopped making sense. One line is enough. You do not have to explain it well, that is the job.
2
We reply, and we talk
A call, one to one. No slides. We work the actual question, on the actual problem in front of you.
3
You keep the notes
What we worked through, written down, so when you meet it again you are not starting from nothing.
Ten questions, out loud
Not multiple choice. Say the answer aloud, properly, the way you would to an examiner. Tick it only if you actually could. Nothing here is sent anywhere.
0 of 10.The ones you left blank are the session.
What this is
It is
- One person, on a call, working your actual question
- Your paper, your lab sheet, your error, not a generic example
- Notes afterwards, so it survives the call
- Saying "I still do not get it" as many times as it takes
It is not
- A course with a syllabus and a completion certificate
- A recorded playlist you will not finish
- Someone reading slides at you
- Doing your assignment for you
AI, underneath
Not prompt tips
Everyone will teach you what to type. Almost nobody will tell you what happens after you press enter, which is the part that decides whether you can debug it, defend it, or trust it.
01
Your question
Split into tokens. Pieces of words, not words.
02
Retrieval
If there are documents, the nearest few get pulled in. This is where most projects break.
03
Context
Everything the model can see at once. It is not memory. Close the chat and it is gone.
04
The answer
Predicted a token at a time from what it was given. Confidence is not a signal.
embedding
Text turned into a long list of numbers, arranged so that things meaning similar things end up near each other.
context window
How much the model can hold in view at once. Not a database, not memory, and it forgets completely.
MCP
A protocol. Your tool exposes functions the model is allowed to call, and describes them in a way it can read. The rest is plumbing.
agent
A loop. Pick a tool, look at the result, pick again, stop when done. That is the whole trick.
What it cannot do is know whether it is right. That part is still yours, and it is the part a viva asks about.
We are not teaching this from a blog post. We built inode, a knowledge base in Go with a real retrieval pipeline, pgvector, on-device models, and an MCP server that editors query directly. The notebooks come out of building it.
See inodeThe kind of question we sit with
Not invented for this page. These are lifted straight out of our own Question Bank, which is one of the notebooks below.
If disk is the bottleneck, why is Postgres fast?
Postgres
We have 20 worker threads and P99 is climbing. Where do I start?
Scaling and Performance
How much memory does a streaming upload actually use?
Object Storage
Three injection contexts, the character that breaks each, and the one structural fix they share.
Backend Security
What we can actually sit with
Not a syllabus, and nothing has to be taken in order. Point at the branch that is giving you trouble.
core java
- objects, properly
- collections
- memory and the GC
- threads
databases
- SQL that runs
- indexes
- transactions
- postgres
systems
- operating systems
- networks
- caching
- scale
- javascriptroadmap
- the language
- async, honestly
- the browser
- node
ai
- what an LLM does
- embeddings and retrieval
- MCP
- agents
The notebooks
10 of them, 493 sections, 867 pages
Long-form manuals on backend and systems work, built to be printed and written on. The contents pages are open to everyone. Sign in and the rest opens too.
Study Notebook 00
Question Bank
- 1. Opening
- 2. Framing the problem
- 3. Ingestion, getting the bytes in
97 sections, 179 pages
System Design Notebook 01
Large-Scale Data Ingestion
- The whole system on one page
- 1. The problem, stated properly
- 2. Clarifying questions that buy you the design
35 sections, 68 pages
System Design Notebook 02
Object Storage
- The whole picture on one page
- 1. The requirement, and the intuitive answer
- 2. Failure 1: the file does not fit
54 sections, 86 pages
Study Notebook 04
Postgres
- The schema on one page
- 1. Persistence, and where data lives
- 2. What a text file cannot do
50 sections, 71 pages
Study Notebook 05
Backend Security
- The whole book in one question
- 1. Assumptions are the vulnerability
- 2. Your application speaks several languages
35 sections, 55 pages
Study Notebook 06
Scaling and Performance
- 1. "Slow" is not a bug report
- 2. Latency is a distribution, not a number
- 3. Why P99 is your most valuable customers
46 sections, 100 pages
System Design Notebook 07
Real-Time Backends
- The whole picture on one page
- 1. The requirement: two people, one board
- 2. The shape of every request you have written so far
49 sections, 90 pages
System Design Notebook 08
REST API Design
- The whole picture on one page
- 1. The requirement: an interface two strangers agree on
- 2. 1990 to 1993: the web outgrows its inventor
55 sections, 99 pages
System Design Notebook 09
Design Principles
- The whole picture on one page
- 1. The requirement: a change that should have been small
- 2. Cohesion and coupling: the older, better words
25 sections, 42 pages
System Design Notebook 10
Caching
- The whole picture on one page
- 1. The requirement: the query that runs a million times
- 2. What a cache actually is
47 sections, 77 pages
What an hour is
- where
- A call, one to one. Screens shared both ways, so we are looking at the same thing.
- what we open
- Your code, your lab sheet, your past paper, and whichever notebook covers it.
- what you keep
- The notes from the hour, written up, so it survives the call.
- what we never do
- Type the assignment for you. We will sit there while you do, and argue about it.
Before you ask
Do I need to know something first?
No. Turning up knowing nothing about the topic is the ordinary case, not the embarrassing one.
What if I cannot even explain the problem?
Then working out what the question is becomes the first half of the hour. Bring the error message and we start there.
Is this only backend?
No. Core papers, JavaScript, and the AI topics above. The notebooks lean backend because that is what is written down so far.
Will you do my assignment?
No. You will do it, with someone next to you who has done it before.
One hour was not enough.
Then book another. There is no package to finish and nothing expires.
Where do the notebooks come from?
Most expand a lecture series by Sriniously on YouTube, credited on every notebook, and are free to read. The AI ones are written by us.
The blank page is the hard part.
Pick a time you are free
One slot, one paper. You will be asked which paper and where it stopped making sense, so the hour starts with the actual question.
Rather just write it out?
Rather just ask first?
Ask in the Discordshahid@binarysemaphore.com