Why pre-screen junior web developers before the technical exercise
Junior applications look identical: the same three languages, the same portfolio site, the same weather app. The differences that matter are invisible on paper. Can they read an error message and act on it? Do they push back when a reviewer is wrong, and change their mind when the reviewer is right? Junior hiring is mostly a bet on how fast someone learns, and a short screen gets at that far better than another list of frameworks.
What actually matters when screening Junior Web Developer candidates
- 01
Technical proficiency
Check fluency in HTML, CSS and modern JavaScript: ask about flexbox versus grid choices, fetch and async handling, and any React, Vue or Tailwind work they wrote themselves.
- 02
Systems and trade-offs
Probe how they structured a site or app: component breakdown, state handling, responsive breakpoints, image optimisation, and why they chose Next.js, WordPress or plain static hosting.
- 03
Evidence and rigour
Test debugging habits: browser DevTools use, console and network tab investigation, Lighthouse or accessibility audit scores, and how they verified a fix beyond it looking right.
- 04
Collaboration and communication
Look for Git discipline and teamwork: branch and pull request habits, code review comments they received and acted on, and handovers to designers or backend developers.
Pre-screening questions to ask Junior Web Developer candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Code they wrote
4 questions01What coding languages are you familiar with? Which ones are you still learning?
Listen forAn honest split between what they use confidently and what they are learning, rather than everything claimed at the same level.
Long language lists with nothing marked as still learning, or claims that do not match the projects described.
02Tell me about your favourite development project so far and what it was like from start to finish.
Listen forTheir own decisions described, including something they would build differently now and what part came from a tutorial.
A project described with no decisions of their own, or starter code presented as their work.
03Can you describe your experience with responsive design?
Listen forLayout worked out from the content rather than fixed breakpoints copied in, with a specific layout that gave them trouble.
Responsive design equated to installing a framework, or no experience testing on an actual small screen.
04What is your approach to structuring your CSS and JavaScript?
Listen forA consistent convention they can justify, with awareness of what happens to it as a project grows past a few files.
No structure beyond one file, or a convention named with no reason for choosing it.
Finding a bug
4 questions05What is your process for testing and finding bugs in an application?
Listen forA method that narrows the problem down, with the browser tools or logging they actually use to locate it.
Testing described as clicking around, or changing code until the symptom disappears without knowing why.
06Do you have experience with version control systems such as Git?
Listen forBranching and commits used as a working habit, with a case where version control saved them from losing work.
Git used only to push to one branch, or no experience resolving a conflict with another person's changes.
07How comfortable are you with debugging and optimising CSS and JavaScript?
Listen forA specific bug they diagnosed, with the tools used and the point at which their first theory turned out to be wrong.
Debugging described generally with no example, or problems solved by rewriting the section from scratch.
08Can you discuss your familiarity with API design and consumption?
Listen forWorking with a real API including errors, loading states and what they did when a response was not what they expected.
Only ever handled the successful response, or no awareness that a request can fail or time out.
Taking correction
2 questions09Tell me about a time when you got stuck while coding. How did you work your way through the problem?
Listen forThe error read and a theory formed before searching, with a clear point at which they asked someone for help.
Searching until something worked with no understanding of the fix, or never asking anyone for help.
10Describe a time when you dealt with negative feedback.
Listen forA review they disagreed with and how it resolved, including a case where they changed their mind after hearing the reason.
Feedback accepted without understanding it, or a defensive account where the reviewer was simply wrong.
Explaining it simply
2 questions11Explain JavaScript to me in a way that an inexperienced person could understand.
Listen forA plain explanation that stays accurate, pitched at what the listener needs rather than reciting a definition.
Explanation that leans on jargon, or a simplification that is actually wrong about what the language does.
12Do you like working as part of a team while coding, and what makes a team work well?
Listen forA specific view drawn from a real team, including something they found difficult about working with other people's code.
Teamwork answered in generalities, or a preference for working alone with no collaborative experience at all.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Technical proficiency
35%5Explains their own code line by line, names framework versions used, and distinguishes what they built from tutorial or template scaffolding.
Systems and trade-offs
25%5Weighs page load, maintainability and deadline against each other, and can name a shortcut they took plus its cost.
Evidence and rigour
25%5Describes reproducing a specific bug, isolating it in DevTools, and citing before and after Lighthouse, axe or cross browser results.
Collaboration and communication
15%5Cites real pull request feedback that changed their code, writes clear commit messages, and asks designers questions before building ambiguous mockups.
Junior applications look identical on paper, and the thing that separates them is how they behave when the code does not work. A one-way video screen asks.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for a junior developer take?
Ten minutes across eight to ten questions, answered async. Enough to hear which parts of their projects they actually wrote, how they debug, and how they respond to a review that disagrees with them.
Should the screen replace a coding exercise?
No, it sits before one. The screen removes applicants who cannot describe their own code, which is a large proportion of a junior pool, so the exercise is only spent on people who will get something out of it.
Evaluating answers
What is the strongest signal when screening a junior developer?
How they describe getting stuck. Juniors who will grow describe reading the error, forming a theory and testing it. Anyone whose answer is that they searched until something worked has not learned to debug yet.
How do I judge project claims from a bootcamp portfolio?
Ask which part they wrote and which came from the tutorial. Honest answers separate the two without prompting. A project described entirely in the first person, with no starter code acknowledged, usually is not one.
Go deeper on this role
Sanat has been hiring since 2012 and watching the recruitment industry change up close ever since, and turned that screening process into Hirevire's video screening platform. LinkedIn
