EasyTechnical

44 practiced

How would you create a six-week learning plan to bring a junior frontend engineer up to speed on web accessibility (WCAG basics, semantic HTML, ARIA, keyboard navigation, screen-reader testing)? Provide weekly activities, hands-on tasks, automated tools to integrate, checkpoints for assessment, and how you'd incorporate accessibility into code reviews.

Sample Answer

**Overview** Six-week ramp plan to make a junior frontend engineer confident in WCAG basics, semantic HTML, ARIA, keyboard navigation, and screen-reader testing.

**Week 1 — Foundations (WCAG + semantics)** - Read WCAG 2.1 A/AA summary and MDN on semantic HTML. - Hands-on: Convert a non-semantic sample page to semantic tags (header, nav, main, article, button). - Tool: Axe browser extension for baseline audits. - Checkpoint: Quiz + PR showing before/after semantic changes.

**Week 2 — Keyboard & focus management** - Learn tabindex, focus-visible, skip links. - Task: Make a modal and custom dropdown keyboard-accessible. - Tool: Lighthouse keyboard checks. - Checkpoint: Demo keyboard walkthrough recorded + checklist.

**Week 3 — ARIA fundamentals** - Study ARIA roles, properties, and when NOT to use ARIA. - Task: Add appropriate ARIA to complex widgets (tabs, combobox). - Tool: ARIA-Validators, WAVE. - Checkpoint: Code review session focused on ARIA choices.

**Week 4 — Screen-reader testing** - Intro to NVDA/VoiceOver basics. - Task: Test previously built widgets with a screen reader and document issues. - Checkpoint: Pair testing with mentor and remediation plan.

**Week 5 — Integration into framework & automated tests** - Learn accessibility patterns in React/Vue (semantic components, focus management). - Task: Add jest-axe or @testing-library/jest-dom accessibility assertions to component tests. - Tool: CI integration of Axe CI. - Checkpoint: Passing a11y tests in CI for a sample feature branch.

**Week 6 — Review, polish, and process** - Conduct an audit of a small app, fix findings, and present learnings. - Task: Write an “accessibility checklist” for the team and a PR template snippet. - Checkpoint: Final assessment: live demo, written checklist, and merged PR with accessibility fixes.

**Code review practices (ongoing)** - Use a checklist: semantics, keyboard, ARIA rationale, color contrast, focus styles, automated test status. - Require screenshot/screencast for keyboard & screen-reader verification on substantive UI changes. - Label PRs with a11y impact and block merge until core checklist passes.

This plan balances reading, hands-on builds, automated tooling, and human testing to create durable accessibility habits.

HardTechnical

41 practiced

You identify a recurring category of bugs introduced by a cohort of junior engineers. Diagnose likely root causes across process, onboarding, and tooling, and propose a multiprong remediation plan that includes focused training modules, CI/automated checks, updated code-review guidelines, and mentor-led shadowing. Provide estimated timelines and quantify expected impact where possible.

Sample Answer

**Situation & quick diagnosis**Recurring bugs from a junior cohort (front-end) often stem from: incomplete onboarding, unclear code standards, gaps in framework/state-pattern knowledge (React hooks, async state), weak CSS/scoping habits, lack of automated guards, and limited mentor feedback loops.

**Root causes (process, onboarding, tooling)**- Onboarding: no focused frontend checklist (accessibility, responsive, cross‑browser).- Process: permissive PR acceptance, inconsistent code reviews.- Tooling: missing linting/typed checks, no visual regression or CI browser tests.

**Remediation plan (multi-prong)**

1) Focused training modules (2–4 weeks)- Week 1: React state patterns, hooks, async flows (2 sessions).- Week 2: CSS architecture (BEM/CSS Modules), specificity, responsive patterns.- Week 3: Accessibility & cross‑browser testing.- Deliverables: short quizzes + paired coding kata.- Impact: expect ~30–50% fewer semantic/state bugs within 2 months.

2) CI / automated checks (1–3 weeks)- Enforce ESLint + Prettier + TypeScript strictness.- Add Jest unit tests for common patterns, Cypress E2E + Percy visual regression for key pages.- Fail PR on accessibility score drop (axe).- Impact: catch ~40–60% of regressions before review.

3) Updated code-review guidelines (1 week to roll-out)- PR checklist: tests, accessibility, responsive screenshots, performance budget.- Require at least one senior reviewer for non-trivial state/UI changes.- Use templated comments for recurring issues.

4) Mentor-led shadowing (ongoing)- 1:2 mentor pairing for 4 weeks per junior, daily 30min review/office hours.- Weekly demo where juniors present fixes to solidify learning.- Impact: reduce rework cycles by ~25% and speed ramp-up by ~3–6 weeks.

**Measurement & timeline**- 0–4 weeks: onboarding + linting + review guidelines.- 4–8 weeks: CI tests + training modules + start shadowing.- 8–16 weeks: evaluate metrics: bug recurrence (target −50%), PR rework time (target −30%), mean time to resolve UI bugs (target −40%).

**Risks & trade-offs**Short-term slower velocity due to training/reviews; long-term quality and velocity improvement.

EasyTechnical

38 practiced

Describe a detailed onboarding plan for a new junior frontend developer joining a React + TypeScript team. Include first-day and first-week checklists (access, local build, routes), 30/60/90 day learning milestones, suggested starter tickets, pairing schedule, and how you'd validate that onboarding is effective (metrics or signals).

Sample Answer

**Overview**A structured 90-day plan that combines access, hands-on tickets, pairing, and measurable signals so a junior React + TypeScript developer becomes productive and confident.

**First day checklist**- Access: GitHub, CI, Jira, Slack, Figma, dev VPN, npm registry tokens.- Local build: clone repo, install, run dev server, run tests.- Routes: open app, identify top-level routes, confirm HMR works.- Quick wins: run lint, format, and a smoke E2E test.- Introductions: team, buddy, product owner, engineering norms doc.

**First week checklist**- Read arch docs: component library, state management, API layer, routing.- Complete dev workflow: branch -> PR -> code review -> merge.- Pair 1:1 with buddy daily 30–60m.- Small PR: fix typo in docs, adjust a CSS spacing, add TS type to small util.

**30 / 60 / 90 day milestones**- 30d: confidently run build/tests, deliver 1–2 small features/bugfixes, understand routing and key components.- 60d: own a medium feature (forms, validation, API integration), introduce types across a module, handle reviews independently.- 90d: lead end-to-end feature, propose one improvement (performance/accessibility), mentor newer hires.

**Suggested starter tickets**- Add a typed prop to a simple component.- Fix a failing unit test.- Implement route-based lazy loading for one route.- Build a small settings panel using design tokens.

**Pairing schedule**- Week1: daily pairing with buddy (30–60m).- Weeks2–4: 2–3 sessions/week, mix of driver/navigator.- Month2–3: weekly architecture pair, rotating reviewers for exposure.

**Validate effectiveness (metrics & signals)**- Quantitative: time to first green PR, number of review-requested iterations, build/test pass rates, ticket cycle time.- Qualitative: buddy feedback, self-assessed confidence, peer review quality, number of independent merges.- Target signals: first green PR within 2 weeks, independent medium ticket completion by 60d, positive 1:1 feedback at 30/60/90.

This plan balances ramping technical skills, ownership, and measurable outcomes while keeping close mentorship.

MediumTechnical

46 practiced

You're asked to implement a lightweight mentorship program at a small company with four frontend engineers. Draft a practical plan covering pairing rotations, mentor training, a shared knowledge base, reasonable time allocation per week for mentoring, and 3 KPIs to measure program success over six months. Emphasize low overhead and quick wins.

Sample Answer

**Approach (one-liner)** I’d build a 3-month rolling, low-overhead mentorship program: lightweight pairing rotations, short mentor training, a living knowledge base in the repo, modest weekly time allocation, and three measurable KPIs for six months.

**Pairing rotations (practical, low overhead)** - Team of 4 → form 2 simultaneous pairs each week. - Rotate weekly on a 3-week cycle so each engineer pairs with every other at least once every 3 weeks. Example schedule: Week A: (A+B, C+D); Week B: (A+C, B+D); Week C: (A+D, B+C). - Session format: two 90-min blocks per week (focused work + 30-min retrospective), total ~3 hours/engineer/week when paired.

**Mentor training (light & actionable)** - 1-hour kickoff workshop: mentoring principles, feedback rubric, pair session checklist (goals, role-switching, follow-ups). - 30-min monthly sync to share quick tips and unblock issues. - Provide a one-page “mentor cheat-sheet” in KB with example prompts for code review, accessibility checks, and performance tips relevant to frontend.

**Shared knowledge base (low-friction)** - Single markdown folder in the code repo (docs/mentorship) with templates: session notes, troubleshooting recipes (e.g., common React perf fixes, accessibility checklist, CSS patterns), onboarding checklist for components. - PR-based edits so updates are reviewed and versioned. - Quick wins: start with 8 pages (component ownership map, testing how-tos, performance checklist, common bugs + fixes).

**Time allocation (reasonable)** - Pairing: ~3 hours/week per engineer (two 90-min sessions). - Mentor admin/training: 15–30 mins/week average (one 1-hr kickoff + monthly 30-min). - KB contributions: 30–60 mins/month. Total ≈ 3.5–4 hours/week (~10–12% of time) — small but consistent.

**3 KPIs to measure success over 6 months (with targets)** 1. Pairing adherence: % of scheduled pairing sessions completed — target ≥ 85% by month 2. 2. Cycle time for small frontend tickets (PR opened → merged): reduce median by 25% in 6 months. 3. KB activity: at least 12 meaningful KB commits/pages and average 4 views per page/month; qualitative pulse survey score for mentorship satisfaction ≥ 4/5 after 3 months.

Why this works for a frontend team - Focuses on hands-on, contextual learning (pairing on components, accessibility, performance). - Uses repo docs and PRs (familiar workflow) — minimal new tooling. - Quick wins: templates, one-hour training, and visible schedule produce immediate momentum.

EasyTechnical

78 practiced

Design a productive pair-programming session aimed at teaching DOM debugging and browser devtools to a junior engineer. Include session objectives, timebox, driver/navigator roles, a specific sample bug to reproduce and fix, and follow-up exercises to reinforce learning after the session.

Mentoring and Growing Engineers Questions

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Unlock Full Question Bank