Webbo3 Level 2 · JavaScript Development · Day 19 of 20
Career and Professional Readiness
Turning four projects into something a stranger can assess in ninety seconds, and answering the questions you will actually be asked.
By the end of today you can
- Present a GitHub profile that reads as a developer's rather than a student's
- Describe a project on a CV in the language an employer recognises
- Write about your work without either boasting or apologising
- Answer the JavaScript questions that come up in nearly every junior interview
- Answer the AI question honestly and well, because you will be asked
You have four projects. Somebody deciding whether to interview you will spend about ninety seconds deciding, and most of that on your GitHub profile and one README. Today is about making those ninety seconds work, which is a different skill from building and is worth learning deliberately.
1. Your GitHub profile
- Pin your four best repositories. Not your practice files. Somebody arriving at twenty repositories named
test,test2andjs-practicelearns nothing. - Every pinned repository needs a description and a live link. The description field at the top: one line, plain English.
- Every pinned repository needs a README with a screenshot.
- Delete or archive the noise. An empty repository from week one is not evidence of anything.
- A profile README. Create a repository named exactly your username; its README appears on your profile. Three lines: what you build, what you are learning, how to reach you.
# Chidinma Okafor
Frontend developer in Lagos. I build things with vanilla JavaScript and I am
learning React.
**Recent work**
- [Job Tracker](https://chidinma.github.io/job-tracker) - flags applications that
have gone quiet. Vanilla JS, localStorage, accessibility score 100.
- [Resource Finder](https://github.com/pod-3/resource-finder) - team of five,
I built the API layer and the search.
Reach me: chidinma@example.comThe commit graph is read, and it is not read the way you think
Nobody is counting green squares. What they look for is whether commits are spread across days, because that shows sustained work, and whether the messages say anything. Twelve commits called "update" on one afternoon tells a story, and it is not a good one.
2. Describing a project
The difference between a line that gets skipped and one that gets read is entirely about specificity.
| Weak | Strong |
|---|---|
| Built a to-do app with JavaScript | Built a task manager in vanilla JavaScript with CRUD, filtering and search, persisting state to localStorage and rendering from a single source of truth |
| Used an API | Integrated a REST API with fetch, handling loading, error and empty states, and debounced search to cut requests from one per keystroke to one per pause |
| Worked in a team | Worked in a team of five using a branch-and-pull-request workflow; owned the API layer and reviewed twelve pull requests |
| Made it accessible | Rebuilt the interface for keyboard-only operation with managed focus and live regions, taking Lighthouse accessibility from 68 to 100 |
Each strong version names what you built, how, and what it achieved. The numbers matter: "68 to 100" is checkable, and checkable claims are the ones people believe.
Do not inflate. It fails in the room.
"Built a full-stack application" for a localStorage project falls apart in the first question, and everything else you said becomes suspect. Describing a frontend project precisely is more impressive than describing a backend project you did not build.
3. Writing about your work
A short post about something you built or fixed does more for a junior developer than another certificate. It is evidence you can explain things, which is most of the job.
The bug that taught me how JavaScript actually schedules work
My search box was showing results for the wrong query. Typing "lagos" gave
results for "lago". I assumed my filter was broken and spent an hour there.
It was not the filter. Every keystroke fired a request, they came back out of
order, and the last one to arrive won - which was often not the last one sent.
Two fixes. Debouncing so one search runs per pause instead of one per letter.
And ignoring any response that is not for the current query.
What I actually learned: "it works when I test it slowly" is not the same as
"it works". I had only ever typed one letter at a time.- A specific problem, not "10 JavaScript tips".
- What you first assumed, and why you were wrong. This is the part people remember.
- What you would do differently. It reads as judgement rather than as a tutorial.
4. The questions you will be asked
The classics, with the answers that land
What is the difference between `let` and `const`?
Both are block-scoped. const cannot be re-assigned after declaration, but it does not freeze the value: an object in a const can still have its properties changed. I default to const and switch to let only where I genuinely re-assign, because it tells the reader the name will not move.
What is the DOM?
A live tree of objects the browser builds from the HTML and renders the page from. JavaScript changes the tree rather than the file, which is why a refresh undoes everything: the tree is rebuilt from the file again.
What is a Promise?
An object representing a value that has not arrived yet. It is pending, then either fulfilled with a value or rejected with a reason, and it never goes back. async/await is syntax over the same thing, which is why an async function always returns a Promise.
What happens when you call `fetch()`?
It returns a Promise that resolves to a Response as soon as the headers arrive. The body has not been read yet, which is why response.json() is a second await. And it only rejects when the request could not be made at all: a 404 or a 500 resolves normally, so I check response.ok and throw myself.
What is the difference between `map` and `forEach`?
map returns a new array of the same length, one output per input. forEach returns undefined and exists for side effects. If I want a new list I use map; if I am just doing something with each item I use forEach.
How would you debug a broken API request?
Network tab first, because the Console cannot tell me whether the request even went out. Did it fire, what status came back, and what is actually in the Response tab. That distinguishes a wrong URL from an auth problem from a shape I assumed rather than checked. CORS shows up as a failed request with a specific console message and is not fixable from the frontend.
What is event delegation and why use it?
One listener on a parent, using event.target.closest() to work out which child was involved. It matters because rows added after the listener was attached still work, whereas a listener per button only covers the buttons that existed at the time.
How do you stop XSS?
Put user text in with textContent, never innerHTML. If the feature genuinely needs user HTML, use a maintained sanitiser rather than my own regular expression. And remember browser validation is only a courtesy: the server has to check too.
The one everybody now asks
How do you use AI when you code?
Answer it honestly and specifically. "I don't" is not believed. "For everything" ends the interview.
Something like: I use it for explaining errors, for boilerplate, and as a reviewer: I paste my own code and ask it to attack it. I do not use it to make decisions about what to build. I check any method I have not seen against MDN, because it invents plausible ones. And I do not commit anything I could not explain in a review, which is the same standard I would apply to code I copied from anywhere else.
That answer works because it shows a process, and because every part of it is something you actually did this month.
The preparation that actually works
Open each of your four projects and read the code aloud, saying what each block does. Every hesitation is a question you cannot answer yet. Twenty minutes per project, and it is worth more than any list of questions, including this one.
5. Where the work is
| Route | What to expect |
|---|---|
| Junior frontend roles | Rarely require a degree; do require evidence. Your four projects are the evidence |
| Agency and studio work | Different project every few weeks. Fast, and you learn quickly |
| Freelance | Small first. One finished job with a good review beats a certificate |
| Your own network | Somebody you know has a site with problems. Fix it, send a clean write-up, ask for a referral |
Do this now
- Clean your GitHub: pin four, describe them, archive the rest, add a profile README.
- Write the four CV lines for your four projects, in the strong style above.
- Write one post about a real bug you hit this month.
- Record yourself for two minutes demoing your best project. Watch it back. It is uncomfortable and it will change how you present on Day 20.
- Answer all nine questions above out loud, without reading the answers first.
Tick before you move on
- ☐ Four repositories pinned, each with a description, README and live link
- ☐ A profile README exists
- ☐ Four CV lines written that name what, how and what it achieved
- ☐ One written post published somewhere
- ☐ I answered all nine interview questions out loud from memory
Quick recap
Ninety seconds: profile, one README, one screenshot · Name what you built, how, and what changed, with checkable numbers · Do not inflate; a precise frontend project beats an invented full-stack one · Read your own code aloud: hesitation marks the question you cannot answer · On AI, describe your process, because a process is what they are testing for
Tomorrow, Day 20: a client brief, a team, and everything you have learned in one build.