Full-Stack Engineer

Ability to structure a decision under uncertainty: identifying the conditions, explicit trade-offs, consulting the affected people, validating afterwards with data. Bonus: the candidate mentions changing their mind along the way or documenting the decision for the future. Anyone who describes an obvious decision in hindsight rarely weighed it seriously.

A structured debugging method: reproduction, logs, instrumentation, hypotheses validated by experiment. Honesty about duration (a real production bug is rarely done in under 30 minutes). Bonus: the candidate names the root cause and the systemic fix, not just the hotfix. Answers like I restarted the service with no diagnosis point to weak investigative ability.

Technical humility and an ability to learn. Bonus: the candidate names what they would do differently from the start today. Anyone who never really had to refactor their own code is lying or never kept code in production over time.

Ability to flag a technical weakness without blocking: a factual comment in the PR (here is the risk, here is my suggested fix), an offer to help solve it, escalation to the tech lead if the PR is merged despite the comment. Anyone who lets it slide because the profile is senior shows a lack of technical courage.

Clarifying the need before negotiating the timeline (perhaps the feature can ship in two phases or be simplified). Offering options: an MVP in one week plus V2 in two weeks, an explicit scope cut, additional resources. Answers like I can do it in a week if I work the weekend are a warning flag (a signal of poor self-management).

Diagnosis first: no attempt to fix everything at once. Prioritization by risk and impact (typically: monitoring first to see, then tests in critical zones, then deployment automation). Alignment with the team and tech lead before each move. Anyone who dives straight into a full rebuild shows a lack of pragmatism.

Clarification before proposing (expected volume, latency requirements, supported devices, persistence of unread notifications). A coherent architecture: push (WebSocket or Server-Sent Events) vs. pull (polling), persistence (a notification DB), idempotency, an email fallback. Bonus: acknowledging the zones of uncertainty (I'd build a POC before committing between WebSocket and SSE). Anyone who jumps straight into code without clarifying shows a design weakness.

A structured method: (1) temporarily raise the log level on the affected endpoints, (2) correlate with metrics (latency, payload size, source), (3) identify a pattern (time of day, request type, a specific user), (4) order the hypotheses (DB timeout, race condition, memory). Anyone who jumps straight to it's probably the DB without investigating has a bias.

Measure before optimizing: DevTools, Lighthouse, a server profiler. Identify the bottleneck (rendering, DB queries, payload, CDN). Prioritize by effort times impact. Answers like I add caching with no diagnosis point to premature optimization. Bonus: recognizing that 8 seconds in production usually points to a systemic problem (N+1 queries, a huge payload), not a local optimization.

Understanding of the test pyramid (many unit tests, fewer integration tests, few E2E). Distinguishing coverage from value (90 % coverage on trivial code weighs less than 60 % on critical business logic). Bonus: the candidate cites a case where a test prevented a real regression. Anyone who simply answers 100 % coverage with no distinction shows weak judgment.

DB transaction: atomicity and isolation are managed by the DB (ACID), limited to the transaction's duration. Application lock: coordination between processes or instances via Redis, ZooKeeper or similar; useful when coordination goes beyond a single DB (microservices, a task queue). Deadlock risk in both. Anyone who cannot separate the two mechanisms builds race conditions into production.

A stepwise approach: (1) map the critical components and recurring patterns, (2) first extract hooks and business logic (high leverage, low risk), (3) split large components along functional boundaries, not technical schemas, (4) introduce a state manager only where props drilling actually hurts (Context or Zustand at an SMB, Redux at higher volume). Anyone who wants to switch everything to React Server Components right away shows a lack of pragmatism.

Openness: the ability to separate the code from personal ego. Bonus: the candidate cites a case where a review actually made them rethink. Anyone who describes explaining their logic to the reviewer instead of listening shows a coachability weakness; at an SMB with a small tech team that is a hard knock-out signal.

An active mentoring posture: pair programming, educational reviews (not just ok merge), documenting decisions, sharing good practices. Anyone who says I help when I'm asked with nothing more concrete shows a passive posture. At an SMB with a small tech team, the ability to pass on knowledge is decisive for the team's sustainability.

A partnership posture: constructive challenging on the basis of feasibility or complexity, alternative proposals. Bonus: the candidate cites a case where they accepted the original brief after discussion (no systematic opposition). Anyone who describes PMs or designers as they don't understand the tech shows a teamwork weakness.