Technical Depth & Areas of Specialization Questions

Every strong candidate has one or more areas of technical depth that go beyond generalist knowledge. Discuss the area(s) where you have the most depth: how you identify it (a subsystem, technology, domain, or class of problem you gravitate toward), a concrete project or accomplishment that demonstrates that depth, how you actively keep that expertise current (reading, communities, side projects, postmortems), and how that depth changes the way you make trade-offs or collaborate with generalists on your team. Areas of specialization are highly individual and role-dependent (examples span distributed systems reliability, accessibility and design systems, security architecture, data pipelines, performance optimization, mobile platforms) - the interviewer should probe the candidate's own stated specialization rather than assume a fixed domain.

HardTechnical

23 practiced

Design an automated linting and pre-commit policy to enforce accessibility, semantic HTML, and consistent usage of design tokens across a large codebase. Specify which tools you'd use (ESLint plugins, stylelint, pre-commit hooks), example rules, which checks run locally vs in CI, and a rollout strategy to reduce friction for teams with legacy code.

Sample Answer

Situation: We need an automated policy that enforces accessibility, semantic HTML, and design-token consistency across a large, partly legacy JS/React codebase without blocking teams.

Solution overview (tools)- ESLint + plugins: eslint-plugin-jsx-a11y, eslint-plugin-react, eslint-plugin-react-hooks, eslint-plugin-html-validate (or @html-validate for HTML files).- StyleLint + plugins: stylelint, stylelint-order, stylelint-declaration-block-no-ignored-properties, stylelint-config-standard, stylelint-custom-properties for token checks.- Design tokens: style-dictionary for token canonicalization; stylelint with custom-properties-allowed-list pointing to generated tokens.- Pre-commit: Husky + lint-staged (fast local), optionally pre-commit framework for polyglot repos.- CI: GitHub Actions / GitLab CI to run full checks, html-validate, axe-cli accessibility audits, snapshot diffing.

Example rules (snippets)- ESLint (.eslintrc.js){ "plugins":["jsx-a11y","react"], "extends":["plugin:jsx-a11y/recommended","plugin:react/recommended"], "rules":{ "jsx-a11y/alt-text":"error", "jsx-a11y/anchor-is-valid":["error",{ "components":["Link"], "specialLink":["to"] }], "react/forbid-dom-props":["warn"] }}- stylelint (stylelint.config.js){ "extends":["stylelint-config-standard"], "rules":{ "order/properties-alphabetical-order": null, "color-named":"never", "custom-property-pattern":"^--(token|color|spacing)-[a-z0-9-]+$", "property-no-unknown":[true, { "ignoreProperties": ["composes"] }], "scale-unlimited/declaration-strict-value":[["color","font-size"], {"ignoreKeywords":["currentColor"], "variables":["/^--token-/"]}] }}

Checks local vs CI- Local (pre-commit, fast): eslint --fix on staged files via lint-staged, stylelint --fix on staged CSS/SC, simple axe-core/axe-core-runner smoke tests for single components if available. Auto-fixable rules run locally to minimize friction.- CI (PR gates, slower): full eslint run, stylelint full repo, html-validate across templates, axe-cli/Pa11y a11y scans on built app, design-token consistency verification (compare used tokens vs style-dictionary output), bundle size and snapshot checks. CI enforces "no new violations" rule.

Rollout strategy for legacy code1. Define policy baseline: categorize rules into Critical (a11y/security/semantic) vs Best-practice (naming, ordering).2. Phase 1 — Protect new work: enable all rules in "error" for new/modified files only. Implement lint-staged + GitHub Action that only fails when a rule is violated in changed lines/paths (use eslint --format=json + filter by git diff).3. Phase 2 — Autofix sweep: run automated codemods (jscodeshift for React semantics, stylelint autofix) and style-dictionary migration scripts in a mass PR per package. Provide reviewers with before/after diffs.4. Phase 3 — Gradual remediation: add backlog tickets for legacy remediation; set targets per sprint/team. For critical a11y issues, create a remediation T-shirt sizing and require fixes within SLA.5. Exceptions & allowlist: maintain an exceptions manifest (file-based) with expiration/owner. Use rule severity toggles for specific folders.6. Developer ergonomics: provide VS Code settings, pre-commit hook templates, a CLI checker (npm run check-accessibility) and a migration playbook with codemod scripts and examples.7. Metrics & enforcement: expose dashboards (Lint/CI pass rates, a11y issue counts). After 3-6 months, tighten gating from changed-files-only to whole-file for modified packages.

Why this works- Auto-fix locally reduces friction.- CI enforces full guarantees preventing regressions.- Phased rollout + codemods balance immediate safety with realistic remediation timelines.- Design-token enforcement via style-dictionary + stylelint prevents token drift and ensures runtime parity.

EasyTechnical

31 practiced

Explain the difference between 'perceived performance' and 'actual performance'. Provide three UI techniques to improve perceived performance (e.g., skeleton screens, optimistic updates, progressive rendering), explain when to use each technique, and describe one potential pitfall per technique.

MediumTechnical

19 practiced

Case study: A mobile app onboarding flow loses 40% of users on the second screen. Propose a prioritized set of hypotheses explaining the drop-off (e.g., friction in form fields, permission prompt, confusing CTA), design experiments to validate them, instrumentation to collect required metrics, sample-size guidance, and suggested design changes to test.

Sample Answer

Approach: treat this as a funnel problem—generate prioritized hypotheses, design quick/cheap validations, instrument to observe true behavior, then run A/B or qualitative tests to iterate.

Prioritized hypotheses (highest to lowest):1. Form friction: too many fields or keyboard issues causing abandonment.2. Permission prompt (location/notifications) appears unexpectedly and scares users.3. Confusing CTA or unclear benefit on screen 2 (UX copy/visuals not motivating).4. Slow load / animation jank on transition causing perceived crash.5. Unexpected required signup vs. optional exploration.

Experiments to validate:- Quick analytics check + heatmaps/session replay to confirm where people drop or rage-tap.- A/B test 1 (Form simplification): reduce fields, use progressive profiling; measure conversion to screen 3.- A/B test 2 (Permission timing): defer permission to later or show contextual explainer before prompt.- A/B test 3 (CTA copy/visual): test clear benefit-focused copy + primary color emphasis vs. baseline.- Performance test: instrument load times and run a variant with optimized assets/removed heavy animation.

Instrumentation & metrics:- Funnel events: screen_view:onboard_1, screen_view:onboard_2, interaction:field_focus, field_blur, submit_attempt, permission_prompt_shown, permission_response, tap:cta.- UX metrics: drop-off rate between screens, time_on_screen2, fields_completed_rate, error_rate per field, permission_accept_rate, cold start time, frame-render-times.- Qualitative: session recordings, user feedback prompt after abandonment.

Sample-size guidance:- Use baseline conversion p0 = current conversion from screen2→screen3. For a detectable absolute uplift d (e.g., 5%), sample per variant ≈ (Zα/2√(2p0(1−p0)) + Zβ√(p0(1−p0)+ (p0+d)(1−p0−d)))^2 / d^2. Practically, for p0≈0.6 and d=0.05, ~6–8k users per variant for 80% power, α=0.05. If traffic is limited, prioritize high-impact quick qualitative tests first.

Suggested design changes to test (in order):1. Reduce required fields to minimum; replace text inputs with smart defaults and social/email auto-fill.2. Move permission prompts after core value delivered; add short contextual explainer with benefits and screenshot.3. Clarify CTA: benefit-led copy (“Get personalized recommendations”) and strong primary button; remove competing secondary CTAs.4. Improve perceived performance: skeleton screens, reduce animation length to <200ms.5. Offer “Continue as guest” or skip option to lower commitment.

Outcome & next steps:- Run analytics + session replay to pick top hypothesis; run parallel small A/Bs where traffic allows; iterate on winning variant and measure downstream retention/activation to ensure change improves long-term value, not just immediate conversion.

EasyTechnical

23 practiced

Explain what accessibility (a11y) means for web applications and list the common accessibility issues you would prioritize when building reusable UI components. In your answer, describe how these issues affect real users (e.g., screen reader, keyboard-only, low-vision), how you would test for them (manual and automated), and which assistive technologies you would validate against.

MediumTechnical

17 practiced

An A/B test shows your redesigned CTA increases clicks but conversions do not improve. How would you investigate this discrepancy? List quantitative and qualitative steps (funnel analysis, micro-conversions, session recordings, technical instrumentation), potential UX issues to inspect, and how to prioritize fixes.

Sample Answer

Start with a hypothesis-driven investigation: the CTA change increased click intent but something downstream blocks conversion. Split work into quantitative then qualitative, iterate with instrumentation.

Quantitative steps- Funnel analysis: count users at each step pre/post. Example SQL:

sql

SELECT step, COUNT(DISTINCT user_id) FROM events
WHERE event_time BETWEEN '2025-01-01' AND '2025-02-01'
AND variant IN ('control','treatment')
GROUP BY variant, step;

- Track micro-conversions (click → form open → field interactions → submit → payment) and conversion rates between each step.- Segment by device, browser, geo, user cohort, traffic source, and time-of-day to find where drop-off spikes.- Check instrumentation/analytics integrity: duplicate events, missing event firing, A/B assignment leakage, sampling biases.- Examine conversion lag: maybe conversions occur later—compare cumulative conversion curves.

Qualitative steps- Session recordings and heatmaps on treatment users who clicked but didn’t convert.- User surveys / short intercept: “What stopped you?” for clicked-but-not-converted.- Usability tests on representative flows for friction points.

Potential UX/technical issues to inspect- Expectation mismatch: CTA copy promises something different than the landing flow.- Broken or slow downstream flow: JS errors, form validation issues, 3rd-party failures, mobile layout bugs.- Poor affordance after click (no clear next step), hidden form fields, too many steps.- Tracking bugs: click counted but redirect failed before conversion event fires.- Performance regressions: increased latency leading to abandonment.

Prioritization of fixes- Triage by impact × effort and risk. First fix high-impact, low-effort items: tracking bugs, JS errors, missing events, critical layout issues.- Next: medium effort UX fixes (copy alignment, reduce form fields), A/B test iteratively.- Low-priority: larger redesigns needing research.- Validate each fix with quick experiments or telemetry to ensure conversion lift.

Communicate findings with PM/design, propose actionable experiments (e.g., align CTA copy, fix instrumentation, streamline form) and measure micro-conversion improvements before full rollout.

Unlock Full Question Bank

Get access to hundreds of Technical Depth & Areas of Specialization interview questions and detailed answers.

Join thousands of developers preparing for their dream job.