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, most of it on your GitHub profile and one README.
Today is about making those ninety seconds work. It is a different skill from building, and it is worth learning on purpose.
1. Your GitHub Profile
Definition
Your GitHub profile is the page at github.com/your-username. For a junior developer it is the portfolio: the first place an employer looks for evidence that you can build.
Real-Life Example
A shop window. A passer-by decides in seconds whether to go in, from the four things on display, not from the storeroom behind them.
Types: What to Fix
- Pin your four best repositories. Not your practice files. Twenty repositories named test, test2 and js-practice tell a visitor nothing.
- A description and a live link on every pinned repository. One plain line in the description field at the top.
- A README with a screenshot on every pinned repository, in the shape from Day 18.
- 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.
The Commit History Is Read, Though Not How You Think
Nobody counts green squares. They look for commits spread across days, because that shows sustained work, and for messages that say something. git log --oneline shows each commit on one line, the way a reviewer skims it.
Five lines, and a stranger can see how the project was built and that you fix your own bugs. Twelve commits called "update" on one afternoon tell a story too, and not a good one.
Picture the shop window: four good things, clearly labelled, and the storeroom door shut.
2. Describing a Project
Definition
A CV line for a project says what you built, how you built it, and what it achieved. The difference between a line that gets skipped and one that gets read is entirely specificity.
Real-Life Example
"Good cook" on a chef's application is skipped. "Ran the grill station for a 120-seat restaurant, cut ticket times from 18 to 11 minutes" gets an interview.
| Weak | Strong |
|---|---|
| Built a to-do app with JavaScript | Built a task manager in vanilla JavaScript with create, edit, delete, filtering and search, persisting 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 with a branch-and-pull-request workflow; owned the API layer and reviewed twelve pull requests |
| Made it accessible | Rebuilt the interface for keyboard-only use with managed focus and live regions, taking Lighthouse accessibility from 68 to 100 |
Each strong version names what, how, and what changed. The numbers matter: "68 to 100" is checkable, and checkable claims are the ones people believe.
"Built a full-stack application" for a localStorage project falls apart at 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.
Picture the chef's two applications side by side. Only one of them has a number you could phone the restaurant and check.
3. Writing About Your Work
Definition
A write-up is a short post about one real thing you built or fixed. For a junior developer it does more than another certificate, because it is evidence you can explain things, which is most of the job.
Real-Life Example
A mechanic who can tell you what was wrong with your car and why is trusted more than one who just hands back the keys, even if both fixed it.
A post like that is stronger when the bug is shown, not just described. Here is the race it talks about. wait(ms) returns a promise that settles after that many milliseconds (Day 7), standing in for a slow network. The search for "lago" is made slower on purpose, the way a real server sometimes is.
The fix from the post: remember the latest query, and throw away any answer that is not for it.
- 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.
Picture the mechanic who explains: the same repair, and a customer who comes back.
4. The Questions You Will Be Asked
Definition
A junior technical interview checks that you understand the tools you used, not that you have memorised definitions. The strongest answer is short, correct, and ends with how you use it. Stronger still is one you have seen with your own eyes, so each answer below comes with its proof.
Real-Life Example
A driving test examiner does not ask you to recite the highway code. They ask why you checked the mirror, and they believe you because they watched you do it.
What is the difference between let and const?
Both are block-scoped. const cannot be re-assigned, 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 draws the page from. JavaScript changes the tree, not the file, which is why a refresh undoes everything: the tree is rebuilt from the file again.
What is a Promise?
An object standing for 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 and await are 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 tells a wrong URL from an auth problem from a shape I assumed. CORS shows 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 find which child was involved. 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 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 honestly and specifically. "I don't" is not believed. "For everything" ends the interview. Something like: I use it to explain errors, for boilerplate, and as a reviewer: I paste my own code and ask it to attack it. I do not use it to decide 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, the same standard I apply to code I copied from anywhere else. That works because it shows a process, and every part of it is something you did this month.
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 is worth more than any list of questions, including this one.
Picture the driving examiner: they believe the answer because they watched you check the mirror. Run the proof once and the answer is yours.
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 | A 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 four CV lines for your four projects, in the strong style above.
- Write one post about a real bug you hit this month, with the code that shows it.
- Record yourself for two minutes demoing your best project, then 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. Then run each proof and check yourself.
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: every hesitation marks a question you cannot answer yet. On AI, describe your process, because a process is what they are testing for.
Final Scenario
An interviewer asks what fetch does with a 404. You say it resolves, that you check response.ok, and that you know because you watched the catch block not run.
Then they ask about AI, and you describe the reviewer prompt, the MDN check and the rule you follow, each with an example from a project they can open while you talk.
You are not the most experienced person they will see this week. You may be the one who can show their working.
Tomorrow, Day 20: a client brief, a team, and everything you have learned in one build.