Front-End Developer Skill Matrix
Builds the browser side of web products: semantic markup, styling, JavaScript/TypeScript, a component framework, and the performance, quality, tooling, security and AI-assisted practices around them.
Free for teams of up to 5 people. No credit card required.
One growth tree. Three clear positions.
This matrix connects 33 knowledge areas to clear expectations for Junior, Middle and Senior positions. 301 practical exercises show how that growth can be demonstrated.
A practical framework from expectations to evidence
The knowledge areas define the skills required for this role. Position requirements show the proficiency expected at each career step, and the exercises provide concrete ways to practise and demonstrate those skills.
- 33
- Knowledge areas
- 301
- Practical exercises
- 2
- Skill groups
- 01
Junior
Expected proficiency mapped across 29 of 33 knowledge areas.
- 02
Middle
Expected proficiency mapped across 33 of 33 knowledge areas.
- 03
Senior
Expected proficiency mapped across 33 of 33 knowledge areas.
Explore every knowledge area
Technical Skills
01HTML & semantics
Writing valid, semantic HTML that gives content real structure and meaning (landmarks, headings, forms, tables and media) so browsers, assistive tech and search engines understand it.
TargetNovice
HTML & semantics
Writing valid, semantic HTML that gives content real structure and meaning (landmarks, headings, forms, tables and media) so browsers, assistive tech and search engines understand it.
Audit your own recent markup against MDN's document-structure guide
Read MDN's 'Structuring documents,' developer.mozilla.org/en-US/docs/Learn_web_development/Core/Structuring_content/Structuring_documents, paying attention to what each layout element is for and when a div or span is the right fallback. Then open a page or component you wrote recently on a real or test project (in your team's framework, React, Vue, Angular or similar, looking at the rendered HTML in DevTools, not the component source) and list every place where the element choice is off: a div or span doing the job of a button, link, list, heading or landmark, a heading level picked for its size rather than its place in the outline, or a section with no heading. For each item, name the element you should have used and the reason in one sentence, quoting the article where it applies. Evidence: a link to the file or commit you audited plus your table of current element, correct element and reason, reviewed by your mentor.
Mark up a content page with correct landmarks and outline, then pass review
Take a well-scoped ticket on a real or test project that builds a content page or view (for example an article, product detail or help page with site navigation, a sidebar and a footer) in your team's framework, and write the markup yourself: landmarks (the page regions screen readers let users jump between: one main, plus header, nav, aside and footer) used for their actual purpose, a heading outline (the headings in page order, h1 to h6) with no skipped levels, lists for anything that is a list, and buttons versus links chosen by whether the control acts or navigates. Before asking for review, run the rendered page through the W3C Nu HTML Checker (validator.w3.org/nu) and fix every error. Open a PR and ask your reviewer to look specifically at element choices. Evidence: the PR link, a screenshot or paste of the clean validator result, the heading outline (from DevTools or a browser extension), and a short note listing each element choice the reviewer questioned and what you changed.
Build a well-structured form for a real sign-up or settings ticket
On a real or test project, build a form of moderate size (sign-up, profile settings, contact or checkout address) in your team's framework, working from a design and a ticket. Get the structure right without help: a real form element with a meaningful action and method, the most specific input type for each field (email, tel, number, date, url and so on), name attributes that match what the server expects, radio and checkbox groups wrapped in fieldset with a legend, autocomplete attributes on personal-data fields (e.g. autocomplete="email" or "postal-code", so the browser can fill them in), and button type set explicitly (submit versus button). Validate the rendered HTML with the W3C Nu HTML Checker and fix every error before review. Evidence: the PR link, the validator result, and a short note naming one structural choice your reviewer corrected and why their version is better.
02CSS
Styling interfaces with CSS: the cascade, specificity and inheritance, CSS architecture (BEM, modules, utility-first), custom properties, web fonts and theming, kept maintainable as a codebase grows.
TargetNovice
CSS
Styling interfaces with CSS: the cascade, specificity and inheritance, CSS architecture (BEM, modules, utility-first), custom properties, web fonts and theming, kept maintainable as a codebase grows.
Explain a real specificity conflict from your own codebase
Read web.dev's Learn CSS module on specificity, web.dev/learn/css/specificity, then find a style in your real or test project that did not apply the way you expected (a hover colour, a margin overridden by a parent rule, a library style winning over yours). Write down the competing selectors, score each one, and name the cascade step that decided the winner (origin, specificity or order of appearance). Then fix it by adjusting the selector or its position in the project's CSS approach, without adding !important, an id selector or an extra wrapper class just to win. If you got stuck, note who helped and what you learned from them. Evidence: a short note with the competing selectors, their specificity scores and the deciding cascade step, plus a link to the commit with the fix.
Style a component from a design in the project's CSS approach
Take a well-scoped ticket from your real or test project: one component with a design (a card, a form field with its error state, a navigation item with hover, focus and active states). Style it in your team's framework (React, Vue, Angular or similar) using the project's existing CSS approach, whether that is BEM, CSS Modules, a utility-first setup or something else, and reuse the existing custom properties for colour, spacing and type and the project's loaded web fonts instead of hard-coding values. Match the design at the states it shows, and get it through normal code review. When you hit a cascade, inheritance or specificity problem you cannot solve in reasonable time, ask for help and record what the cause turned out to be. Evidence: a link to the merged PR with before/after screenshots or a preview link, the reviewer's comments and how you addressed them, and a two-to-three sentence note on any cascade or specificity issue you asked about and its cause.
Load a web font with a sensible fallback stack
On a well-scoped ticket in your real or test project, add a web font the design calls for (a heading or body typeface) or replace a font that is currently loaded without care. Following web.dev's 'Best practices for fonts', web.dev/articles/font-best-practices, declare it with @font-face using a WOFF2 file (the compressed font format all current browsers support) and only the weights and styles the design actually uses, set a font-display value (it decides what the browser shows while the font downloads; use swap or optional) and be able to say why you chose it, and write a font-family stack that falls back to a similar-looking system font and then a generic family (for example sans-serif). Check the fallback works: block the font file in your browser's dev tools network panel or throttle the connection and confirm the text is readable at once and does not jump badly when the web font arrives. Get it through normal code review, asking for help if the font does not apply or the fallback looks very different. Evidence: a link to the merged PR showing the @font-face rule, the font-display value and the full font-family stack, a screenshot of the page with the web font blocked next to one with it loaded, and a two-to-three sentence note on why you chose that font-display value and fallback font, plus the reviewer's comments.
03Responsive layout
Building layouts that adapt to any screen and input (Flexbox and Grid, fluid type, media and container queries, responsive images) with progressive enhancement for uneven browser support.
TargetNovice
Responsive layout
Building layouts that adapt to any screen and input (Flexbox and Grid, fluid type, media and container queries, responsive images) with progressive enhancement for uneven browser support.
Choose Flexbox or Grid for each region of a real screen
Read MDN's 'Relationship of grid layout to other layout methods', developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_layout/Relationship_of_grid_layout_with_other_layout_methods, and pull out the questions it gives for deciding between the two. Then take one screen from a real or test project in your team's framework (React, Vue, Angular or similar), such as a product listing or account settings page, and break it into its regions (header bar, filter row, card list, form, footer). For each region, say whether you would lay it out with Flexbox or Grid, using the article's reasoning in your own words, and note one region where the existing code uses the other method and whether you would change it. Evidence: a short table (region, current method, your choice, one-sentence reason) linked to the screen's source file, reviewed with your mentor.
Build a single screen that works from 320px phone to wide desktop
On a real or test project in your team's framework (React, Vue, Angular or similar), pick up a well-scoped ticket for one screen, for example a pricing page, a search results list or a sign-up form, and build its layout yourself with Flexbox and/or Grid, mobile-first (write the phone layout first, then add rules for wider screens). It must hold up at 320px, 768px, 1024px and 1440px wide with no horizontal scrolling, no overlapping or clipped text, and tap targets that stay usable on a phone; use relative units (rem, %, fr) and wrapping (flex-wrap, or grid's repeat(auto-fit, minmax(...))) before reaching for extra media queries. Check it in your browser's device mode and on one real phone. If you hit an unusual layout or a browser quirk you can't solve, ask for help and write down what it was and how it was fixed. Evidence: the PR or preview link, screenshots at the four widths plus the real phone, and a short note listing each media query you added and why, and the one place you needed help.
04JavaScript
The JavaScript language and its browser runtime: types, scope and closures, async code and the event loop, modules, the DOM and events, regular expressions, and Web APIs like storage and workers.
TargetNovice
JavaScript
The JavaScript language and its browser runtime: types, scope and closures, async code and the event loop, modules, the DOM and events, regular expressions, and Web APIs like storage and workers.
Learn scope, closures, this and equality, then find each in your code
Read MDN's 'Closures' guide, developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Closures, its 'Equality comparisons and sameness' page, developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Equality_comparisons_and_sameness, and its reference on 'this', developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this. Then find one real example of each in your project's code: a function that uses a variable from an outer scope (a closure, e.g. an event handler or a debounce helper), a place where `this` matters or would break if the function were passed around as a callback, and a comparison where `==` versus `===` or a truthy check could give a different answer (e.g. for `0`, `''` or `null`). Also note how that file imports and exports code (ES modules). For each, write 1-2 sentences on what the code does and what would go wrong if it were written differently, and fix one real problem if you find one. Evidence: the code links or snippets with your notes, and the PR if you fixed something.
Build a filterable list that fetches its data with async/await
On a real or test project, take a well-scoped ticket (or write one with your mentor) for a small feature built with plain JavaScript or inside your team's framework (React, Vue, Angular or similar): fetch a list from an API with async/await, render it, and let the user filter it with a text input and one other control. Handle the loading, empty and error states, including a failed request and a non-OK HTTP status, and transform the response data (map, filter, sort) before rendering rather than inside the markup. Attach the input listener once and update only what changed. Use one simple regular expression on the filter input, for example to extract a prefix such as "tag:css" or a number like "#42" from the query, or to reject characters the filter should not accept, and list five sample inputs with what your regex matches or rejects for each. Open a PR and get it reviewed. Where you got stuck on an async or structure problem, note what you tried before asking for help and what you learned from the answer. Evidence: the PR or preview link, a short note listing the states you handled, your regex with its sample inputs and results, and the reviewer's comments with how you resolved each one.
Handle clicks on a dynamic list with one delegated listener
In a real or test project, find (or add) a list whose items are added and removed at runtime, such as a to-do list, cart or comment thread, with actions on each item (delete, toggle, edit). Implement those actions with a single delegated event listener (one listener on the list container that handles clicks for every item inside it) instead of one listener per item, identify the target item with data attributes, and make sure newly added items work without extra wiring. Keep keyboard use working (buttons, not clickable divs). Ask your reviewer to check the change. Evidence: the PR or commit link plus a short note explaining why delegation fits this list, how you find the clicked item, and one thing the reviewer asked you to change.
Explain the order your own async code runs in
Read MDN's 'How to use promises', developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Async_JS/Promises, which covers promise chains, async/await and error handling with fetch. Then pick one async function from your own feature code (for example the fetch from your list feature) and write it out twice: once with .then()/.catch() chains and once with async/await and try/catch. Add console.log markers, predict the order they will print in, run it, and compare with your prediction. Evidence: a gist or branch with both versions, your predicted and actual log order, and three or four sentences on where an error would be caught in each version.
05TypeScript
Using TypeScript's type system to make front-end code safer and easier to change: typing components, APIs and data, generics and utility types, strict mode, and types other developers can rely on.
TargetNovice
TypeScript
Using TypeScript's type system to make front-end code safer and easier to change: typing components, APIs and data, generics and utility types, strict mode, and types other developers can rely on.
Map the annotations in one real file to everyday types
Read the 'Everyday Types' chapter of the TypeScript Handbook, www.typescriptlang.org/docs/handbook/2/everyday-types.html, then open one component or module you have recently touched in your team's TypeScript codebase (real or test project). Find five typing constructs in it (for example a union, an optional property, a type alias or interface, a literal type, an `as` assertion or a `!` non-null assertion) and, for each, write two or three sentences: what the construct tells the compiler, and whether it is safe as written or hides a possible runtime error. Flag at least one assertion you would replace and say how. Evidence: a link to the file (commit or permalink) and your five annotated notes, with the flagged assertion marked.
Ship a well-scoped ticket with fully typed props and data
Pick a well-scoped ticket in an existing TypeScript codebase in your team's framework (React, Vue, Angular or similar), on a real or test project: a new component, a form field, or a small screen that reads data from an existing API call. Deliver it on your own: type the component's props or inputs, the data it receives and any event handlers, reusing the codebase's existing types instead of redeclaring them. The PR must pass the project's type check with no new `any`, `@ts-ignore` or `@ts-expect-error`. Where you got stuck on a generic or a complex type, ask a reviewer, and record the question and what you learned. Evidence: the PR link with a green type check, a short note listing which existing types you reused, and the question you asked about a generic or complex type plus the answer.
Fix three real compiler errors without escape hatches
Collect three type errors you actually hit in your team's codebase (from your own branch, the editor, or the type-check step in CI), ideally of different kinds: for example a possibly `undefined` value, a missing or misspelled property, and a function called with the wrong argument type. Fix each one properly, by narrowing, correcting the type, or fixing the calling code, not by adding `any`, an `as` cast, a `!` or a comment that silences the error such as `@ts-ignore`. For each, write one line in your own words on what the error message meant and why your fix is correct. If one of them needed help because it involved generics or a library's types, say what the reviewer showed you. Evidence: a commit or PR link per fix (or one PR with three commits) and your three one-line explanations.
06Component framework
Building UI with a component framework such as React, Vue or Angular (components, props, component-level state, lifecycle and the framework's own patterns) in whichever framework the team uses.
TargetNovice
Component framework
Building UI with a component framework such as React, Vue or Angular (components, props, component-level state, lifecycle and the framework's own patterns) in whichever framework the team uses.
Build a ticket's component by following the closest existing pattern
Pick a well-scoped ticket on a real or test project that needs one new component (a card, list item, filter panel, modal body or similar) in your team's framework (React, Vue, Angular or similar). Before writing code, find the existing component in the codebase that is closest to it and copy its conventions: file and folder layout, how props or inputs are declared and typed, how the component talks back to its parent (callbacks, emitted events or outputs), naming, styling approach and test setup. Keep state local to the component unless the ticket says otherwise. Cover the edge cases the design does not show: empty data, missing optional props, very long text, loading and error states if the data is async. Open a PR and ask your reviewer to check structure and edge cases. Evidence: the PR link, a short note naming the component you patterned on and what you copied from it, your list of edge cases with how each is handled, and the reviewer's comments with what you changed.
Explain your framework's component lifecycle from its official docs
Read the official page on component lifecycle for the framework your team uses: React react.dev/learn/synchronizing-with-effects , Vue vuejs.org/guide/essentials/lifecycle.html or Angular angular.dev/guide/components/lifecycle (if your team uses another framework, find its equivalent official page). Vue users should also read the 'Side Effect Cleanup' and 'Stopping a Watcher' sections of vuejs.org/guide/essentials/watchers.html , since the lifecycle page says little about teardown. Then write a one-page explainer in your own words: the order in which a component is created, rendered, updated and removed; where code that touches the DOM, starts a timer or subscribes to something should go; where its teardown goes and when that runs; and what makes setup run again when inputs or props change. Name one gotcha the page warns about (for example effects running twice in development in React, hooks having to be registered synchronously in Vue, or which hook first sees input values in Angular). Finally, pick one existing component in your codebase that has setup code and annotate it with a comment on each part saying when it runs. Evidence: the explainer, the link to the docs page you used, and the annotated component (a gist, branch or PR), reviewed by your mentor.
Add a side effect to a component and prove it cleans up
On a real or test project, build or extend a component that has to do something outside rendering: start a timer, listen to a window or document event, subscribe to a data source, or fetch data when it appears. Implement it with your framework's own mechanism (an effect with a cleanup function in React, lifecycle hooks or watchers in Vue, lifecycle hooks or DestroyRef in Angular, or the equivalent), reading the relevant page of your framework's official docs first. Make sure the setup runs when it should and is torn down when the component unmounts or its input changes. Prove it: mount and unmount the component several times (toggle it, navigate away and back) and show that listeners, timers or requests do not pile up, using DevTools, a log, or a test. Evidence: the PR link, the proof (screenshot, log or test), and a two or three sentence note on when your setup and cleanup run, reviewed by your mentor.
07State management
Managing state that outlives a single component, both shared app state and server-cache state (stores, query caches, sync, optimistic updates), and choosing the right home for each piece of state.
TargetNovice
State management
Managing state that outlives a single component, both shared app state and server-cache state (stores, query caches, sync, optimistic updates), and choosing the right home for each piece of state.
Map where the state in one feature of your app lives
Read the Redux FAQ page 'Organizing State' for its rules of thumb on what belongs in a shared store versus a component (the questions apply to any store, not only Redux): redux.js.org/faq/organizing-state. Examples use React; the idea applies in any framework. Then pick one feature you work on in your real or test project and list every piece of state it uses: where it lives today (component state, shared store, server-cache query, URL), which components read or change it, and whether the rules of thumb agree with its current home. Then name one piece of new shared state the feature is likely to need next (for example a new filter or a selection kept across pages), write where you think it should live and why, and take that question to your mentor or a senior teammate before anyone builds it. Evidence: the state map as a short table, your question about where the new state should live with your proposed answer, and the answer you got.
Deliver a ticket through the app's existing state patterns
Take a well-scoped ticket on a real or test project that reads and changes shared state, for example adding an item to a cart, marking a notification as read or changing a user preference. In your team's framework (React, Vue, Angular or similar), implement it on your own through the app's existing patterns: the store's actions and selectors (the functions that change the store and read from it), or the existing query and mutation hooks with their cache keys, rather than copying data into local state, passing it down through many layers of components (prop drilling) instead of reading it from the store, or starting a new one-off store. Make sure every place that shows the changed data updates. If the ticket seems to need new shared state, ask the reviewer where it should live before you add it, and follow the answer. Evidence: a link to the merged PR, a short note naming the existing pattern you used and every place the change shows up, and, if you asked where new state should live, the question and the answer you followed.
08Programming paradigms & design principles
Applying paradigms and design principles to units of code (object-oriented and functional programming, immutability, composition and SOLID) to keep code readable, testable and easy to change.
TargetNovice
Programming paradigms & design principles
Applying paradigms and design principles to units of code (object-oriented and functional programming, immutability, composition and SOLID) to keep code readable, testable and easy to change.
Spot impure functions and shared mutation in your own codebase
Read Chapter 3 of Professor Frisby's 'Mostly Adequate Guide to Functional Programming', mostly-adequate.gitbook.io/mostly-adequate-guide/ch03, and pull out its definition of a pure function and its list of side effects. Then look through a real or test project in your team's framework (React, Vue, Angular or similar), such as its utility, formatting or data-mapping files, and find three functions that are not pure: one that mutates its arguments (for example sorting or pushing onto an array it was passed), one that reads or writes shared state outside itself, and one that does more than one job. For each, name what makes it impure or unfocused in the chapter's terms and sketch the pure, single-purpose version. Evidence: a short note with links to the three functions, your diagnosis of each and the rewritten sketch, reviewed with your mentor.
Ship a small pure module and fix what the reviewer flags
On a real or test project in your team's framework (React, Vue, Angular or similar), pick up a well-scoped ticket that needs a small unit of logic, for example calculating a cart total with discounts and tax, grouping and sorting a list of orders for display, or validating a form's fields. Write it yourself as small single-purpose functions plus one small class (for example a value object or a formatter). If your codebase has no classes of its own, the class can be one you extend or implement from a library your project uses (e.g. a custom `Error` subclass or a class your framework expects). Keep both to the same rules: take inputs and return new values, with no mutation of arguments or shared module state, and side effects such as fetching or logging kept at the edges, outside the logic. Add unit tests for the functions. Open a PR and ask your reviewer to check specifically for mutation, hidden dependencies and functions doing too much, then fix every violation they point out. Evidence: the PR link with the review thread, the follow-up commits that address each comment, and a two-sentence note on the one fix you would not have spotted yourself.
09APIs & data fetching
Moving data between browser and servers (REST and GraphQL, JSON, error handling, retries, pagination, real-time channels) plus service workers, offline caching and PWA installability.
TargetNovice
APIs & data fetching
Moving data between browser and servers (REST and GraphQL, JSON, error handling, retries, pagination, real-time channels) plus service workers, offline caching and PWA installability.
Learn how HTTP and a page load work, then trace one in your app
Read MDN's 'An overview of HTTP', developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview, which explains requests and responses, methods, status codes, headers and cookies, and web.dev's 'How browsers work', web.dev/articles/howbrowserswork, for what happens between typing a URL and seeing the page (read the overview and the parsing and rendering parts). Then open your app with the browser's DevTools Network tab open and the cache disabled, and load one page. Pick the HTML document, one script or stylesheet and one API call, and for each write down the method, the status code, two headers that matter (e.g. Content-Type, Cache-Control, Set-Cookie or Authorization) and why they are there. Add 3-4 sentences on the order things loaded and which request held up the first paint. Evidence: a screenshot of the Network tab, your notes on the three requests, and the load-order summary.
Integrate a documented list and detail endpoint with every UI state
On a real or test project, take a well-scoped ticket to connect a list view and a detail view to a documented REST or GraphQL API (your team's own backend, or a public API with published docs) in your team's framework (React, Vue, Angular or similar). Read the docs or schema first and write down the fields you rely on. Show distinct loading, empty and error states, and tell apart a network failure, a 404 on the detail view, and a server error, with a way for the user to retry. If the endpoint needs auth, or the docs are unclear or wrong, ask for help and record the question you asked and the answer. Get the PR reviewed. Evidence: the PR or preview link, a screenshot of each state, your list of relied-on fields, and a short note on where you needed help and what the reviewer changed.
Submit a form to an API and show the server's validation errors
In a real or test project, wire up a create or edit form (profile, address, comment) that sends a POST, PUT or PATCH request, or a GraphQL mutation, to a documented endpoint. Send JSON in the shape the docs describe, disable double submission while the request is in flight, and when the server rejects the input (for example a 400 or 422 with field errors) show each error next to the right field instead of a generic message. Show a clear success state and keep the user's input if the request fails. Evidence: the PR or preview link, the request and response payloads for one success and one validation failure (copied from the Network panel with any personal data removed), and your reviewer's comments.
Audit your fetch calls for errors that fetch never throws
Read MDN's 'Using the Fetch API', developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch, especially the section on checking response status. Then go through the data-fetching code of a real or test project (or your own recent PRs) and list every call site. For each, note whether it checks the response status, what happens on a 404 or 500, what happens if the body is not valid JSON, and whether the user ever sees the failure. Fix at least one gap you find. Evidence: your call-site table, the commit or PR fixing one gap, and two or three sentences on the difference between a rejected promise and an error response.
10Animation & graphics
Adding motion and graphics to interfaces (CSS and JavaScript animation, SVG, Canvas basics) that stays smooth on real devices and respects users' reduced-motion preferences.
TargetNovice
Animation & graphics
Adding motion and graphics to interfaces (CSS and JavaScript animation, SVG, Canvas basics) that stays smooth on real devices and respects users' reduced-motion preferences.
Check an existing animation against web.dev's high-performance guide
Read web.dev's 'How to create high-performance CSS animations,' web.dev/articles/animations-guide, focusing on which properties stay on the compositor (the browser step that only moves already-painted layers, which is cheap) and how to spot layout and paint work in DevTools. Then pick one transition or animation in a real or test project (one you wrote, or one in your product's codebase) and record it in the DevTools Performance panel. Name the properties it animates, whether each one triggers layout, paint or only compositing, and rewrite it with transform and opacity if it does not already use them. Record it again after your change. Evidence: a link to the original code and your change, the two Performance recordings (or screenshots of them), and a short note explaining the difference, reviewed by your mentor.
Add transitions and a keyframe animation to a component, with reduced motion
On a well-scoped ticket in a real or test project, add motion to one component in your team's framework (React, Vue, Angular or similar): CSS transitions for its hover, focus and open or closed states (a dropdown, accordion, drawer or toast), and one keyframe animation (a loading spinner, skeleton shimmer or attention pulse). Animate transform and opacity where you can, keep durations short, and choose easing (the speed curve of the movement, such as ease-out for things entering the screen) on purpose. Add a prefers-reduced-motion: reduce rule that removes or softens the movement without hiding content or breaking the state change. Ask your mentor to review the smoothness and the reduced-motion behaviour before merging. Evidence: the PR link, a short screen recording with normal motion and with reduced motion turned on in your OS or DevTools, and a note on what your mentor suggested and what you changed.
Add a set of SVG icons that scale and follow the text colour
On a real or test project, add or replace at least four icons in a component or screen with SVG, using whatever approach your codebase already uses (inline SVG, a sprite file whose icons you reference with the <use> element, or icon components in your framework). Make sure each icon has a correct viewBox, scales cleanly from small to large sizes without blurring or clipping, inherits colour through currentColor so it follows hover and theme states, and has unnecessary editor metadata stripped (for example with SVGO, a tool that optimises SVG files). Add one simple CSS transition to an icon state, such as a chevron rotating when a panel opens, with a reduced-motion fallback. Evidence: the PR link, screenshots of the icons at two sizes and in two colour states, the before and after file size of one optimised icon, and your reviewer's comments.
11Design systems & design handoff
Building UI for others to reuse (shared component libraries with stable APIs, design tokens, documentation such as Storybook, and versioning) and implementing faithfully from design files like Figma.
TargetNovice
Design systems & design handoff
Building UI for others to reuse (shared component libraries with stable APIs, design tokens, documentation such as Storybook, and versioning) and implementing faithfully from design files like Figma.
Map a screen's hard-coded values to your design tokens
Read the sections on tokens, groups and aliases (references) in the W3C Design Tokens Community Group's 'Design Tokens Format Module', www.designtokens.org/tr/2025.10/format/, so you can tell a raw value (#1a73e8) from a primitive token (a named raw value, e.g. blue-600) and from a semantic token that aliases it by its role (e.g. color-action-primary). Then open one existing screen in a real or test project in your team's framework (React, Vue, Angular or similar) and find five styling values that are hard-coded (a hex colour, a pixel spacing, a font size, a radius, a shadow). For each, name the existing token it should use from your team's token set, whether that token is a primitive or a semantic alias, and flag any value that has no matching token instead of inventing one. Evidence: a short table (file and line, hard-coded value, correct token, primitive or semantic, or 'no token, flagged') reviewed with your mentor.
Build a screen from a design file using only the library, and flag mismatches
On a real or test project in your team's framework (React, Vue, Angular or similar) that has a shared component library and tokens, take a well-scoped ticket to build one screen from a design file (e.g. Figma), such as a settings page, an empty state or a checkout step. Build it yourself using only existing library components and tokens: no hard-coded colours or spacing, no one-off CSS overrides of library components, and no copies of a component tweaked to match. Use the design tool's inspect or developer mode to read spacing, variants and tokens rather than eyeballing. Wherever the design and the library disagree (a variant the library lacks, a spacing value with no token, a state not in the design), stop and raise it with the designer or the library owners instead of working around it. Evidence: the PR or preview link beside the design frame, and a mismatch log (what differed, who you raised it with, the answer and what you did), including at least one reply from a designer or library owner.
12Web performance
Measuring and improving how fast a site loads and responds (Core Web Vitals, loading strategy, code splitting, caching, profiling and performance budgets) on real devices and networks.
TargetNovice
Web performance
Measuring and improving how fast a site loads and responds (Core Web Vitals, loading strategy, code splitting, caching, profiling and performance budgets) on real devices and networks.
Measure a page and explain its Core Web Vitals
Read web.dev's 'Web Vitals', web.dev/articles/vitals, for what LCP, INP and CLS measure, their thresholds and the difference between lab and field data. Then measure one important page of your real or test project: run Lighthouse or the DevTools Performance panel with mobile throttling, and check field data in PageSpeed Insights if the site has enough traffic. For each metric, say whether it passes, which element or interaction drives it (the LCP element, the interaction behind INP, the elements that shift for CLS), and why lab and field numbers differ if they do. Evidence: the saved reports or screenshots and a short note explaining each metric's result in your own words.
Fix straightforward loading issues and re-measure
Using the measurements from a page of your real or test project, fix the straightforward issues on your own: images served far larger than displayed or in heavy formats, images without width and height that cause layout shift, below-the-fold images and iframes that load eagerly, and an LCP image that is lazy-loaded when it should not be. Keep the focus on what each fix saves in bytes and LCP time; setting up full responsive images with `srcset` and `sizes` is its own exercise in Responsive layout. Re-measure the same way as before (same device profile and throttling, at least three runs) and compare. List any deeper issue you found but did not fix, such as a large JavaScript bundle or a render-blocking font, and ask a senior teammate or mentor how they would approach it. Evidence: a link to the PR, a before/after table of LCP, CLS and page weight with the runs you took, and your note on the deeper issue with the guidance you got.
13Automated & cross-browser testing
Proving front-end code works with automated tests (unit, integration and end-to-end, coverage) run across browser engines and devices, so regressions are caught before users see them.
TargetNovice
Automated & cross-browser testing
Proving front-end code works with automated tests (unit, integration and end-to-end, coverage) run across browser engines and devices, so regressions are caught before users see them.
Ship your next feature PR with its own unit and component tests
On a real or test project, take the next feature or change you are building in your team's framework (React, Vue, Angular or similar) and include tests in the same PR without being asked. Follow the patterns already in the codebase: the same test runner, file layout, helpers and way of finding elements (for example by role or label text rather than by CSS class). Write unit tests for the logic (formatting, validation, data transforms) and component tests that render the component and check what the user sees and can do, including one error or empty state. When you hit a case where you are unsure what to test (a timer, a third-party widget, a network call), ask for help and note the answer. Evidence: the PR link with tests passing in CI, a short note naming the existing test you used as a pattern, and the tricky case you asked about with what you decided.
Pin a bug with a failing test before you fix it
In a real or test project, pick a bug assigned to you (or one you find). Before changing any production code, write a unit or component test that reproduces the bug and fails for the right reason. Commit it, then fix the bug and show the same test passing. Check that the test would still fail if the fix were reverted. Evidence: the PR link with separate commits for the failing test and the fix, the CI or local output showing red then green, and two or three sentences on why this test protects against the bug coming back.
Rewrite a test that checks implementation details
Read Kent C. Dodds' 'Testing Implementation Details', kentcdodds.com/blog/testing-implementation-details, which explains how tests coupled to internals break on refactors and miss real bugs. Examples use React; the idea applies in any framework. Then find two tests in a real or test codebase (your own if possible) that inspect internal state, private methods, CSS class names or component instance details. Rewrite one so it only uses what a user or caller can see, and refactor the code under test to show that the new test survives while the old one would have broken. Evidence: the before and after test code in a PR or branch, and a short note on what each version would miss or falsely flag, reviewed by your mentor.
14Code quality & code review
Keeping a codebase healthy (linting and formatting, complexity analysis, readable code) and reviewing others' changes, including AI-generated ones, so problems are caught and knowledge spreads.
TargetNovice
Code quality & code review
Keeping a codebase healthy (linting and formatting, complexity analysis, readable code) and reviewing others' changes, including AI-generated ones, so problems are caught and knowledge spreads.
Ship four PRs that pass lint and need few comments, and track the feedback
Over your next four pull requests on a real or test project, run the team's linter, formatter and type check locally before pushing, so CI passes on the first try, and do a self-review of the full diff before asking anyone to look (remove debug code, unclear names, dead code, missing tests). When comments arrive, handle each one yourself: fix it, or reply with a short reason if you disagree, and resolve the thread only once the reviewer is satisfied. Keep a simple log per PR: how many comments you got, what kind they were (bug, naming, structure, style, tests) and what you changed. At the end, pick the most common kind and add a line for it to your personal self-review checklist. Evidence: links to the four PRs with green lint and CI, your comment log, your self-review checklist, and a short note to your mentor on the trend you see.
Self-review a merged PR of yours against Google's reviewer checklist
Read Google's engineering practices page 'What to look for in a code review,' google.github.io/eng-practices/review/reviewer/looking-for.html. Then pick one of your own merged pull requests from a real or test project and review it as if a teammate had written it, going through each area the page lists. Write down everything you would now flag, which area it falls under, and whether the original reviewer caught it. Pick the two findings that matter most and say what you will do differently in your next PR. Evidence: a link to the PR, your written self-review organised by the page's areas, and your mentor's response to it.
Review two small PRs from peers with your mentor checking your comments
Ask to be added as a reviewer on two small pull requests from teammates on a real or test project (a bug fix, a copy change, a small component). For each one, check out or open the preview, confirm the change does what the ticket says, and leave comments: at least one question or suggestion if you find something and at least one note on something done well. Label minor points as nits (small, non-blocking suggestions such as a nicer name) so the author knows what is blocking. Before posting, show your draft comments to your mentor or a senior reviewer and adjust them based on their feedback. Evidence: links to both reviews, your draft comments next to what you actually posted, and one sentence on what the senior reviewer caught that you missed.
15Debugging & production monitoring
Finding and fixing bugs (with browser DevTools locally, and in production with error tracking, real-user monitoring and source maps) plus reproducing user-reported issues and rolling back safely.
TargetNovice
Debugging & production monitoring
Finding and fixing bugs (with browser DevTools locally, and in production with error tracking, real-user monitoring and source maps) plus reproducing user-reported issues and rolling back safely.
Replace console.log hunting with breakpoints on a real bug
Work through the Chrome DevTools tutorial 'Debug JavaScript', developer.chrome.com/docs/devtools/javascript, which covers line-of-code and event listener breakpoints, stepping, and the Scope and Watch panes (Firefox and Safari devtools have the same tools under similar names). Then apply it to a bug you meet in your real or test project: instead of adding console.log calls, pause at the right point with a breakpoint (a conditional or event listener breakpoint if it fits), step through, and watch the values until you see where they go wrong. Evidence: a short note with the bug, the breakpoint type you used and why, what the Scope or Watch pane showed at the moment it went wrong, and a link to the commit with the fix.
Reproduce and fix two reported bugs locally with DevTools
Take two small bug tickets from your real or test project's backlog, ideally one UI or logic bug and one where data from an API looks wrong. For each, first write exact reproduction steps (browser, data, clicks), then find the cause on your own with browser DevTools: the console for errors and warnings, breakpoints for the logic, and the Network panel for the request, payload, status code and timing. Fix it in your team's framework (React, Vue, Angular or similar), and add a regression test if the project has tests for that area. If a bug will not reproduce, write down everything you tried and ask a senior teammate before guessing at a fix. Evidence: links to both PRs, the reproduction steps and a two-to-three sentence root cause for each, and, if one would not reproduce, your notes on what you tried and the help you got.
16Version control
Using Git to work safely with others: commits, branches, pull requests, merging and rebasing, resolving conflicts, and keeping a history others can read.
TargetNovice
Version control
Using Git to work safely with others: commits, branches, pull requests, merging and rebasing, resolving conflicts, and keeping a history others can read.
Rewrite your own recent commit messages to a clear standard
Read cbeams' 'How to Write a Git Commit Message', cbea.ms/git-commit/, and note its rules and its test for a good subject line. Then take the last ten commits you authored on a real or test project in your team's framework (React, Vue, Angular or similar) and judge each against the article and your team's own convention if it has one (for example Conventional Commits or a ticket-number prefix). Pick the five weakest and rewrite each one (subject and, where the change needs it, a body that says why), without actually rewriting shared history. Evidence: a before/after list of the five messages with links to the original commits and one sentence per message on what you fixed, reviewed with your mentor.
Deliver a ticket end to end through the team's Git workflow
On a real or test project in your team's framework (React, Vue, Angular or similar), take a well-scoped ticket and deliver it through your team's Git workflow on your own: create a branch named to the team convention, make small commits that each do one thing, keep your branch up to date with the main branch, open a pull request with a clear description (what, why, how to test, screenshots for UI changes), and address review comments with follow-up commits. Resolve at least one simple merge conflict yourself; if none happens naturally, create one on a test branch by changing the same lines on two branches. If you need a rebase or get into a state you don't know how to recover from, ask for help and write down what happened and the command that fixed it. Evidence: the PR link with its commit list and review thread, the commit where you resolved the conflict with a note on how you chose what to keep, and your note on the one situation you needed help with.
17Package & dependency management
Managing a project's third-party code: package managers, lockfiles, semantic versioning, upgrades and deprecations, evaluating new dependencies, and monorepo workspaces.
TargetNovice
Package & dependency management
Managing a project's third-party code: package managers, lockfiles, semantic versioning, upgrades and deprecations, evaluating new dependencies, and monorepo workspaces.
Read your project's version ranges and what the lockfile pins
Read npm's 'About semantic versioning', docs.npmjs.com/about-semantic-versioning, and npm's 'package-lock.json', docs.npmjs.com/cli/configuring-npm/package-lock-json, on what a lockfile records and why it is committed; the range and lockfile rules apply whether your team uses npm, pnpm, Yarn or Bun. Then open the manifest of a project you work on (real or test project) and pick five dependencies with different range styles (caret such as ^2.1.0, tilde such as ~2.1.0, exact such as 2.1.0, or a wider range). For each, write which versions the range allows, which exact version the lockfile currently resolves, and what would change on a fresh install without the lockfile. Finish with two sentences on why the lockfile is committed and which install command your CI uses to respect it. Evidence: a link to the manifest and lockfile at that commit and your five-row table plus the two sentences, checked by a reviewer.
Update dependencies within their ranges and ship a clean lockfile
In your team's project (real or test), use its package manager to update outdated dependencies that stay within their minor and patch ranges, on your own branch. List what is outdated first, update, then run the build, type check and tests, and fix anything that breaks. Commit the manifest and lockfile together and confirm CI installs from the lockfile without changes (for example a frozen or clean install). If the lockfile conflicts with another branch, resolve it by regenerating it with the package manager, never by hand-editing. Evidence: the PR link with a green CI run, the outdated list before and after, and a short note explaining the lockfile diff (which packages moved and why).
Ask before adding a dependency or doing a major upgrade
The next time a task seems to need a new package or a major version bump in your team's project (or, if none comes up soon, on a real or test project pick a need you would otherwise solve with a package), stop and write a short request to your reviewer or tech lead before installing it. State what you need it for, the alternatives you considered (a package already in the project, a platform or framework API, a few lines of your own code), the package's latest release date, its approximate install or bundle size, and its license. For a major upgrade, link the changelog and name the breaking changes that touch your code. Evidence: your written request, the reply you got, and what you did as a result (the PR if approved, or the alternative you used).
18Build tooling & CI
The tools that turn source into a shipped site: bundlers, transpilers, dev servers, npm scripts and the command line, Node.js as a tooling runtime, and CI pipelines that build, test and deploy.
TargetNovice
Build tooling & CI
The tools that turn source into a shipped site: bundlers, transpilers, dev servers, npm scripts and the command line, Node.js as a tooling runtime, and CI pipelines that build, test and deploy.
Map your project's toolchain
Read MDN's 'Client-side tooling overview', developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Client-side_tools/Overview, which sorts front-end tools into categories by what they do. Then open the package.json and config files of a real or test project and map every tool you find (Node.js version, package manager, bundler, transpiler, dev server, linter, formatter, type checker, test runner, CI and deploy) to those categories. For each package.json script, write one line on what it runs and when you would use it. Evidence: your toolchain map and script list in a doc or the project README, with any gaps you could not explain marked as questions, reviewed by your mentor.
Set the project up from scratch using only the command line
On a real or test project, start from a clean clone on your machine and get it running using only the terminal: install the right Node.js version (with a version manager if the project pins one), install dependencies, start the dev server, run the production build and preview it locally, and run the lint, type-check and test scripts. Note every step where the README was wrong, missing or out of date, and anything you had to ask a teammate about, especially build config. Fix the README in a PR. Evidence: the README PR link, a short log of the commands you ran and the problems you hit, and the answers you got to your build-config questions.
Fix your own CI failures by reproducing them locally
Over your next few PRs on a real or test project, whenever CI goes red on lint, type or test checks, fix it yourself: read the failing job's log, find the exact command CI runs, reproduce the failure locally with that command, fix it, and push. Aim for at least three failures of different kinds (you can create one on purpose if needed). If a failure comes from build or pipeline config rather than your code, ask for help and note what you learned. Evidence: links to the failed and fixed CI runs, and for each a two-line note with the failing command, the root cause, and how you reproduced it locally.
19Web security
Protecting users and data in the browser: XSS, CSRF, CORS, Content Security Policy, safe auth flows and token handling, input validation, and supply-chain attacks through dependencies.
TargetNovice
Web security
Protecting users and data in the browser: XSS, CSRF, CORS, Content Security Policy, safe auth flows and token handling, input validation, and supply-chain attacks through dependencies.
Find and classify the raw-HTML sinks in your own codebase
Read OWASP's 'Cross Site Scripting Prevention Cheat Sheet,' cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html, focusing on framework escaping, unsafe sinks and URL handling. Then search a real or test project in your team's framework (React, Vue, Angular or similar) for every sink, a place where data is written into the page in a way that bypasses the framework's automatic escaping: raw-HTML bindings such as dangerouslySetInnerHTML, v-html or innerHTML bindings, direct innerHTML or insertAdjacentHTML calls, calls that run a string as code (eval, new Function, setTimeout with a string), and href or src values built from data a user or API can control. For each one, record where the data comes from and whether it is safe as written, sanitised, or unsafe, citing the cheat sheet. Where you are not sure, ask a senior teammate rather than guessing, and write down their answer. Work only on your own project or a local test app; never test against systems you do not own or have permission to test. Evidence: your list of sinks with a verdict and reason for each, the questions you asked and the answers, and a PR or issue for any unsafe case you found.
Deliver a user-input feature that follows your team's secure-coding rules
On a real or test project, take a well-scoped ticket that handles user or external input (a comment or profile form, a search box that reflects its query, rendering content from an API or URL parameters) and build it following your team's secure-coding rules on your own. Render user content only through the framework's normal escaping, or through the team's approved sanitiser if HTML is truly required. Validate the input in the client for usability while noting which checks the server must also enforce. Confirm no secrets end up in client code: check which environment variables your build exposes to the browser, then search the built bundle for API keys, tokens or internal URLs. Keep a short log of every moment you were unsure whether something was safe and what you did about it. Work only on your own project or a local test app; never test against systems you do not own or have permission to test. Evidence: the PR link, the result of your bundle search, a note on client versus server validation, and your unsure-moments log with the answers you got.
20Accessibility (front-end)
Building interfaces people with disabilities can use: semantic HTML, correct ARIA, keyboard and focus management, screen-reader testing, and meeting WCAG in code, not just in the design.
TargetNovice
Accessibility (front-end)
Building interfaces people with disabilities can use: semantic HTML, correct ARIA, keyboard and focus management, screen-reader testing, and meeting WCAG in code, not just in the design.
Check a component you built against the WAI developer tips
Read W3C WAI's 'Developing for Web Accessibility: Tips for Getting Started', www.w3.org/WAI/tips/developing/, focusing on the tips about labels, text alternatives and keyboard access. Then take one component you recently built in your real or test project (a form, a card with an image and a link, a navigation bar) and check it against those tips in the code and in the browser: does every control have a programmatic label (a label tied to it in code, e.g. `<label for>` or `aria-label`, so a screen reader announces it), does every image have fitting alt text (empty for decorative ones), can you reach and use everything with the keyboard, and can you always see where focus is? Evidence: a short findings list for the component, each item marked pass or fail with the line of code involved, and a link to the commit fixing at least one failure.
Build an accessible form component and verify it by keyboard and tool
Take a well-scoped ticket on a real or test project that includes a form with at least one image or icon button, for example a sign-up, feedback or search form. Build it in your team's framework (React, Vue, Angular or similar) on your own so that every input has a visible, programmatically associated label, error messages are linked to their fields and announced, icon-only buttons have an accessible name, images have alt text that fits their purpose, and focus is clearly visible on every interactive element (no bare outline: none). Verify it by using the whole form with the keyboard only, and with an automated checker (e.g. axe DevTools, Lighthouse or your team's tool), then fix what they find. If you need a complex widget (a date picker, custom select) or want to know how it sounds in a screen reader, ask a senior teammate for help and record what you learned. Evidence: a link to the PR, the automated report before and after your fixes, a short note on your keyboard walkthrough, and any help you asked for.
21SEO
Making a site discoverable by search engines (crawlability, metadata, structured data, sitemaps and canonical URLs) and understanding how front-end choices affect indexing.
TargetNovice
SEO
Making a site discoverable by search engines (crawlability, metadata, structured data, sitemaps and canonical URLs) and understanding how front-end choices affect indexing.
Audit and rewrite the page titles of five real pages
Read Google Search Central's 'Influencing your title links in search results', developers.google.com/search/docs/appearance/title-link, and note its best practices for the title element. Then take five different pages of a real or test site built in your team's framework (React, Vue, Angular or similar), such as the home page, a listing page, two detail pages and a static page like pricing or about, and record the title each one actually renders (check the rendered page, not just the source template). Judge each against the guidance (distinct per page, descriptive, concise, no boilerplate repeated across pages, no keyword stuffing) and write a better title where it falls short. Evidence: a table (URL, current title, verdict with the guideline it breaks, proposed title) reviewed with your mentor.
Add titles, meta descriptions and social-preview tags to page templates
On a real or test site built in your team's framework (React, Vue, Angular or similar), take a well-scoped ticket to add or fix metadata for at least three page templates, for example a listing page, a detail page generated from data, and a static page. Using your framework's usual way of managing the document head, give each page a unique title and meta description built from its content, and social-preview tags (Open Graph meta tags, which chat apps and social sites read to build a link preview: title, description, image and URL, plus the matching card tags) so a shared link shows a proper preview. Check the result with an SEO audit tool such as the Lighthouse SEO audit and with a social-preview checker or debugger, and fix what they report. Ask your mentor for guidance before touching structured data or anything that affects indexing (robots tags, noindex), and note what you learned. Evidence: the PR or preview link, the audit results before and after, screenshots of the rendered link previews, and a short note on the guidance you got.
22AI-assisted development
Using AI coding assistants and agents well: giving good context, breaking work down, verifying and reviewing their output, knowing when not to trust it, and managing security, privacy and licensing risk.
TargetNovice
AI-assisted development
Using AI coding assistants and agents well: giving good context, breaking work down, verifying and reviewing their output, knowing when not to trust it, and managing security, privacy and licensing risk.
Turn a practitioner's advice into your pre-commit checklist for AI code
Read Simon Willison's 'Here's how I use LLMs to help me write code', simonwillison.net/2025/Mar/11/using-llms-for-code/. Then take one piece of code an AI assistant recently produced for you in your team's project (real or test), whatever tool you use (an IDE assistant, a chat assistant or a coding agent). Write a short personal checklist of what you will do before committing AI output, drawn from the article and your own experience, and apply it to that piece of code: what you read line by line, what you ran, what you changed. Include at least one thing the checklist caught. Evidence: your checklist, a link to the code before and after your review (commit or PR), and a note on what the checklist caught.
Ship a well-scoped ticket with AI help, tested and disclosed
Pick a well-scoped ticket in your team's project, on a real or test codebase in your team's framework (React, Vue, Angular or similar): a component, a utility, a form, a bug fix. Use an AI assistant for part of it on your own, following your team's rules on what code and data may be shared with the tool (no secrets, credentials or customer data in prompts). Read and run everything it produced before committing, add or update tests that exercise the AI-written parts, and change anything you do not fully understand or agree with. In the PR description, tell reviewers which parts came from AI and how you checked them. Evidence: the PR link with the AI disclosure and passing tests, and a note listing what you changed in the AI output and why.
Soft Skills
01Communication
Clearly and effectively conveying information, setting expectations, and aligning with others in written and verbal form.
TargetNovice
Communication
Clearly and effectively conveying information, setting expectations, and aligning with others in written and verbal form.
Spot a missing BLUF and rewrite it
Read Wikipedia's article on the BLUF (bottom line up front) technique, en.wikipedia.org/wiki/BLUF_(communication), which explains the practice of opening a message with its key information, responding to the five Ws (who, what, where, when, why), before any narrative detail or supporting context. Take this draft status update: 'Hey team, just wanted to give an update on the onboarding redesign. We've been working on wireframes this week and met with two stakeholders. There were some questions about scope timing. Let me know if you have questions.' Identify what's missing per the BLUF technique, then rewrite its opening sentence as a proper BLUF. Evidence: your written note on what was missing plus the rewritten BLUF opening sentence.
Write a status update that needs zero follow-ups
Using the BLUF technique from the previous exercise, write a full status update (what's done, what's next, what's blocked) for a real or test project you're working on. Show it to a real reader who doesn't already know the details and ask them to tell you what's happening without asking you a single follow-up question. Evidence: the status update plus a note on whether your reader needed a follow-up question, and what it was if so.
02Collaboration
Working well with others: understanding different perspectives, managing shared priorities, and being a reliable team member.
TargetNovice
Collaboration
Working well with others: understanding different perspectives, managing shared priorities, and being a reliable team member.
Confirm what 'reliable help' means for this ask
Read Google's re:Work guide on team effectiveness, rework.withgoogle.com/intl/en/guides/understand-team-effectiveness, which names dependability (reliably completing quality work on time) as one of the five dynamics that separate effective teams. Pick one specific task a teammate has asked you for help with recently, or one you expect to be asked for soon, and write down exactly what 'reliably complete quality work on time' means for that ask: the concrete deliverable, the deadline, and how you'll confirm to the teammate that it's done. Evidence: your write-up naming the task, the deliverable, the deadline, and your confirmation plan.
Help a teammate and name their part in it
The next time a teammate asks you for help with a specific task (or, if none is pending, ask one to give you a real task to help with), do the work, then when it's shared with others (a demo, a doc, a status update, a message to the team), explicitly name your teammate's contribution alongside your own rather than presenting it as solo work. Evidence: the completed help plus a copy or screenshot of the moment you shared credit (the message, doc line, or demo note), showing both your names attached to the shared work.
03Planning / Time management
Managing your own time and, at higher levels, the team's: prioritizing work so it's delivered efficiently and predictably.
TargetNovice
Planning / Time management
Managing your own time and, at higher levels, the team's: prioritizing work so it's delivered efficiently and predictably.
Learn why context-switching breaks your task list
Read Psychology Today's 'The True Cost of Multi-Tasking,' www.psychologytoday.com/us/blog/brain-wise/201209/the-true-cost-of-multi-tasking, which argues that what feels like multitasking is actually rapid task-switching, and that switching quietly derails commitments you'd otherwise meet by costing up to 40% of your productive time. Then look at your own task list for the coming week and mark the one task you know you'd normally split across multiple sittings instead of finishing in one go, and write 2-3 sentences on the single block of time you'll protect for it instead. Evidence: your task list with the marked task, plus the 2-3 sentence plan for protecting a single block of time for it.
Apply the capture-and-clarify step of GTD to your own list
Read the official overview of the Getting Things Done method, gettingthingsdone.com/what-is-gtd/, focusing on the 'capture' and 'clarify' steps for turning loose commitments into a trustworthy task list. Then take every commitment currently living in your head, chat threads, or email for your individually-scoped work and capture them into one list, clarifying each into a single concrete next action rather than a vague reminder. Evidence: your captured list with each item rewritten as a concrete next action.
Run your own task list for a real work week and report what nearly slipped
For a real (or test) week of individually-scoped work, keep a single task list of your commitments, updating it daily as items get added or finished, and share the starting list with your mentor or reviewer so they know what you're committing to before the week begins. At the end of the week, identify the one commitment you nearly missed and write 2-3 sentences on what caused the near-miss and what you changed on your list to catch it in time. Evidence: your week's task list, the 2-3 sentence note on the near-missed commitment, and your mentor's confirmation they saw your starting list.
04Estimating (front-end)
Predicting the realistic effort to build and ship front-end work (sizing tickets, running spikes on unknowns, flagging risk) to inform sprint plans, roadmaps and commitments.
TargetNovice
Estimating (front-end)
Predicting the realistic effort to build and ship front-end work (sizing tickets, running spikes on unknowns, flagging risk) to inform sprint plans, roadmaps and commitments.
Build your reference scale from past front-end tickets
Read Mike Cohn's 'What Are Story Points?', www.mountaingoatsoftware.com/blog/what-are-story-points, which explains relative estimates in terms of amount of work, complexity and uncertainty. Then look through recently finished front-end tickets on a real or test project (your team's board, or your own past tasks) and pick three reference tickets: a small, a medium and a large one, in whatever unit your team uses (points, T-shirt sizes or days). For each, note what made it that size in front-end terms, for example number of UI states, responsive variants, new versus reused components, API readiness, and test effort. Evidence: your three reference tickets with links and sizing notes, checked by a senior or your mentor.
Estimate your own tickets in sprint planning and compare with actuals
In your next sprint planning (or a mock one on a test project with your mentor as the senior), estimate at least three well-defined front-end tickets assigned to you before hearing others' numbers. For each, write down what your estimate includes: UI states (loading, empty, error), responsive layouts, accessibility checks, tests, code review and fixes. Have a senior sanity-check each number and note where and why they disagreed. At the end of the sprint, record the actual effort and compare. Evidence: a table with each ticket link, your estimate and what it covered, the senior's comment, the actual effort, and two or three sentences on what you would include next time.
05Self-Direction
Motivating yourself to complete work effectively, on time, and without close supervision.
TargetNovice
Self-Direction
Motivating yourself to complete work effectively, on time, and without close supervision.
Read what makes check-ins land, then apply one habit
Read Culture Amp's guide to managing up, www.cultureamp.com/blog/managing-up-importance, which explains that keeping your manager informed in the right way, adapted to their preferred communication style and with issues flagged early rather than saved for a review, is something you actively manage, not something that just happens on its own. Pick one small task you're currently working on with light check-ins from your manager or lead, then pick one habit from the article you don't yet do consistently, and write 2-3 sentences on exactly how you'll change your next check-in on that task because of it. Evidence: your 2-3 sentence write-up naming the task, the habit, and the specific change you're making to your next check-in.
Log your check-ins on one assigned task and review the pattern with your manager
Pick one small task assigned to you and, for its full duration, keep a short log every time you check in with your manager or lead: the date, what you reported, and anything that came up. When the task is done, sit down with your manager and walk through the log together, asking them directly whether the check-in cadence and content felt right, or whether they ever had to chase you for an update instead of you offering one. Evidence: the check-in log covering the whole task, plus your manager's written or verbal reaction on whether the cadence worked and whether they ever had to ask rather than being told.
06Critical Thinking / Questioning (front-end)
Thinking a technical problem through before solving it: questioning requirements, weighing trade-offs and cost against value, and challenging the first workable answer, including one an AI suggests.
TargetNovice
Critical Thinking / Questioning (front-end)
Thinking a technical problem through before solving it: questioning requirements, weighing trade-offs and cost against value, and challenging the first workable answer, including one an AI suggests.
Learn to ask questions that surface what a ticket leaves out
Read Julia Evans's 'How to ask good questions', jvns.ca/blog/good-questions/, especially stating what you already know, asking specific questions that have a clear answer, and asking questions that bring out what the team assumes but never wrote down. Then take a front-end ticket you already finished on a real or test project and read it again as if you had not built it yet. List five questions you now wish you had asked the ticket owner before starting (e.g. what the list shows when there are no results, what happens when the request fails), and rewrite each one using the article's advice so the owner can answer it in a line, for example: 'I'm assuming an empty list shows a message and a button to clear the filters. Is that right?' Mark which answers would have changed what you built. Evidence: the ticket link, your five rewritten questions, and your mentor's comments on them.
Question an unclear ticket before you start building
For your next two front-end tickets on a real or test project, stop before writing code and list what the ticket does not say: empty, loading and error states, which browsers and screen sizes count, what happens on a slow or failed request, how it behaves for keyboard users, what data volume to expect, and what done looks like. Phrase them the way you practiced in the exercise above. Send the questions to the ticket owner (product manager, designer or lead), get answers, and note which ones changed what you built. Evidence: for each ticket, your list of questions, the answers you got (a linked comment thread is fine), and one or two sentences on what you would have built wrong without asking.
Name the trade-off between two ways to build it and check with a senior
Pick a ticket on a real or test project where you can see two workable ways to build it, for example adding a small library versus writing a helper, filtering data on the client versus asking the API to filter, a CSS-only solution versus JavaScript, or extending an existing component versus making a new one. Before choosing, write a short note: what each option costs (time, bundle size, maintenance, performance, accessibility risk) and what each gains, and which you lean towards. Then talk it through with a senior teammate or mentor, record where they agreed, what they questioned, and the final choice. Evidence: your trade-off note, a summary of the conversation with the senior's challenges and your answers, and a link to the PR with the option you built.
07Conflict management
Navigating and resolving workplace disagreement in a way that keeps the team functional and relationships intact.
TargetNovice
Conflict management
Navigating and resolving workplace disagreement in a way that keeps the team functional and relationships intact.
Learn what intellectual humility looks like in a disagreement
Read Greater Good Magazine's 'What Does Intellectual Humility Look Like?,' greatergood.berkeley.edu/article/item/what_does_intellectual_humility_look_like, which frames disagreement as healthy when handled with intellectual humility, being open to other people's views instead of contentious about them, and willing to reconsider your own position when shown new evidence. As you read, pull out one behavior the article names for sharing a differing opinion without it becoming contentious, and one behavior it names for updating your own view when shown new evidence. Evidence: the two behaviors you pulled out, each in your own words, with a one-line example of how you'd use it.
Document a real disagreement you handled
Recall a real disagreement you had in a work discussion recently (a design decision, a process choice, a scope call; use the most recent real one you can, or a realistic one if nothing comes to mind) and, with a mentor or reviewer available to read it, write a short account of what your differing opinion was, how you shared it respectfully, and whether any new information came up that changed your mind and how you responded to it. Evidence: the written account plus your reviewer's confirmation that the disagreement, as described, was shared respectfully and that any view change was genuine rather than just conflict avoidance.
Use this matrix with your team in Skiloope
Assign positions, track progress, attach evidence and validate skills in one shared workspace.
Get Started Free with SkiloopeFree up to 5 users · No credit card required