Question 1

Given an array of integers, return the indices of the two numbers that add up to a target sum. You may assume exactly one solution exists.

Accepted Answer

Start with brute force O(n²) to show you understand the problem, then optimize. Use a hash map to store each number's index as you iterate — for each element, check if (target - element) exists in the map. Walk through an example. Code it cleanly, handle edge cases like duplicate values, and state the final time complexity O(n) and space complexity O(n). What interviewers look for: Can you independently optimize from brute force to an efficient solution? Do you communicate your reasoning before typing? Do you write clean, readable code without major bugs? This is a signal-to-noise check — interviewers want to see structured thinking, not just a memorized answer.

Question 2

Implement a function to validate whether a string of brackets — containing '(', ')', '{', '}', '[', ']' — is balanced.

Accepted Answer

Reach for a stack immediately and explain why: you need LIFO matching. Iterate characters: push opening brackets, and on a closing bracket check that the top of the stack is the matching opener. Return false if stack is non-empty at the end or a mismatch is found. Use a hash map for the bracket pairs to keep the code clean. State O(n) time and O(n) space. What interviewers look for: Comfort with stacks as a data structure. Clean implementation using the right tool — candidates who resort to nested conditionals without considering a stack raise flags. Interviewers also check that you handle empty strings and single-character inputs.

Question 3

Given the root of a binary tree, return its level-order traversal (values grouped by level).

Accepted Answer

Use BFS with a queue. At each step, record the queue's current size to know how many nodes belong to the current level, process exactly that many nodes, and collect their values before moving on. Push children as you go. Return a list of lists. Contrast with DFS to show you know the tradeoff. Time and space are both O(n). What interviewers look for: Comfort with trees and queues, and the key insight of using queue size to separate levels — that's the non-obvious step. Candidates who arrive at this naturally signal stronger fundamentals than those who need heavy hints.

Question 4

Explain the difference between controlled and uncontrolled components in React, and when you'd use each.

Accepted Answer

Controlled: form state lives in React state, every keystroke calls setState/useState, React is the source of truth. Uncontrolled: DOM manages its own state, accessed via refs. Use controlled when you need real-time validation, conditional rendering, or to sync with other state. Use uncontrolled for simple file inputs or when integrating with non-React code. Give a quick code sketch for each if asked. What interviewers look for: Whether you understand React's data-flow model at a conceptual level, not just syntax. Interviewers are checking if you've actually built forms and hit the friction points, not just read the docs.

Question 5

What happens in the browser between the moment you hit Enter on a URL and the page finishing rendering? Walk through as much detail as you can.

Accepted Answer

Structure your answer in clear phases: DNS resolution → TCP handshake → TLS handshake (HTTPS) → HTTP request/response → browser parses HTML and builds DOM → discovers CSS/JS/images → CSSOM construction → Render tree → Layout → Paint → Composite. Call out where JavaScript blocks parsing (why async/defer matter). Mention critical rendering path by name. What interviewers look for: Breadth of web fundamentals. New grads are not expected to know every detail, but a structured, layered answer with correct sequencing signals someone who will ramp quickly. Gaps in knowledge are fine; inability to structure an answer is not.

Question 6

Design a simple REST API for a to-do list application. What endpoints would you define, what would the data model look like, and what HTTP status codes matter?

Accepted Answer

Define resources: /todos (collection) and /todos/:id (item). Map CRUD to HTTP verbs: GET /todos (list), POST /todos (create), GET /todos/:id, PUT or PATCH /todos/:id (update), DELETE /todos/:id. Data model: id, title, completed (boolean), created_at. Status codes: 200 OK, 201 Created, 204 No Content, 400 Bad Request, 404 Not Found. Mention input validation and that you'd return consistent JSON error shapes. What interviewers look for: Whether you understand REST conventions beyond just 'it uses HTTP.' Correct use of verbs and status codes, resource naming (plural nouns, no verbs in path), and thinking about the contract between client and server — that's the signal.

Question 7

What is the difference between SQL and NoSQL databases? Given a simple use case like storing user profiles and their posts, which would you choose and why?

Accepted Answer

SQL: relational, schema-enforced, strong consistency, good for structured data with complex relationships, ACID transactions. NoSQL: flexible schema, horizontal scalability, various models (document, key-value, graph). For user profiles + posts: SQL is the right default — clear relationships (users → posts), you want joins, and you need referential integrity. Mention PostgreSQL specifically. Flag NoSQL (e.g., MongoDB) only if requirements push toward unstructured data or extreme write throughput. What interviewers look for: That you can make a reasoned choice rather than recite definitions. Can you weigh tradeoffs against actual requirements? New grads who say 'it depends' and then never commit to an answer score lower than those who pick one and defend it.

Question 8

What is an HTTP cookie vs. localStorage vs. sessionStorage? How would you decide where to store an authentication token?

Accepted Answer

Cookies: sent automatically with every HTTP request, can be HttpOnly (not accessible to JS, XSS-safe), can be Secure and SameSite. localStorage: persists across tabs and sessions, accessible to JS, vulnerable to XSS. sessionStorage: same as localStorage but cleared on tab close. For auth tokens: store JWTs in HttpOnly cookies — not localStorage — because XSS attacks can't steal HttpOnly cookies. Mention CSRF as the tradeoff and how SameSite mitigates it. What interviewers look for: Security awareness, not just API knowledge. Anyone can list the three options; the signal is knowing why HttpOnly cookies are the secure choice for auth and articulating the XSS threat clearly.

Question 9

A friend asks you to build a URL shortener (like bit.ly). Walk through the core components you'd need, the data model, and one tricky part.

Accepted Answer

Components: API server, database, optional cache (Redis). Endpoint: POST /shorten takes a long URL, returns a short code; GET /:code redirects. Data model: short_code (primary key), long_url, created_at. Short code generation: base62 encode a random ID or an auto-incrementing integer — discuss collision handling briefly. Tricky part: redirect performance — a read-heavy workload, so cache popular codes in Redis with a TTL. Return 301 vs 302 (301 is cached by browser, 302 always hits your server — useful for analytics). What interviewers look for: End-to-end thinking on a small, bounded system. Can you identify the read/write pattern, choose appropriate data structures, and call out one non-obvious detail (301 vs 302 is a great one)? New grads aren't expected to handle millions of QPS, but they should reason about the core flow without prompting.

Question 10

You push a change to the frontend and users report the page is blank. How do you debug it?

Accepted Answer

Start with the browser console — look for uncaught JS errors or network failures. Check the Network tab for failed requests (4xx/5xx). If it's a blank white screen in React, suspect an unhandled render error — check for missing ErrorBoundary. Look at recent changes in the diff. Check if the error is environment-specific (prod vs. dev build, env variables missing). Reproduce locally. Narrow from 'everything is broken' to 'this component throws on this input.' Fix, verify, then add a regression test or ErrorBoundary. What interviewers look for: Structured debugging instinct. Interviewers want to see that you move from observation to hypothesis to test, not that you randomly change things. Mentioning specific browser devtools panels (Console, Network) shows hands-on experience.

Question 11

Tell me about a technical project you're most proud of — what problem did it solve, what was hard, and what would you do differently?

Accepted Answer

Use a tight structure: context (what and why), the hard part (be specific — 'the API kept returning stale data because I didn't understand caching headers' is better than 'it was challenging'), what you did, the result, and the honest retrospective. The retrospective is where new grads differentiate — showing genuine reflection ('I'd write tests earlier' with a reason) signals maturity. Pick a project where you made real technical decisions, not just followed tutorials. What interviewers look for: Self-awareness and genuine ownership. Interviewers discount projects where the candidate only 'helped' or can't explain the technical decisions. They're looking for intellectual honesty in the retrospective — candidates who claim everything went perfectly are less credible than those who identify a real mistake and what they learned.

Question 12

Describe a time you were stuck on a technical problem for a long time. How did you get unstuck?

Accepted Answer

Pick a real example — a bug you chased for hours, a concept that wouldn't click. Walk through what you tried, how long you stayed stuck before asking for help, what resource or conversation unlocked it, and what you'd do faster next time. The key message: you have a process (read error carefully → isolate → search → rubber duck → ask), you don't let pride block you from asking, and you extract a reusable lesson. What interviewers look for: Resourcefulness and knowing when to ask for help — two of the most important new-grad traits. Red flags: never getting stuck (unrealistic), or getting stuck and giving up without a structured approach. Good signal: a specific story with a clear lesson about their own debugging or learning process.

New Grad Full-Stack Engineer Interview Questions

What to expect

12 questions, with how to answer them

1. Given an array of integers, return the indices of the two numbers that add up to a target sum. You may assume exactly one solution exists.

2. Implement a function to validate whether a string of brackets — containing '(', ')', '{', '}', '[', ']' — is balanced.

3. Given the root of a binary tree, return its level-order traversal (values grouped by level).

4. Explain the difference between controlled and uncontrolled components in React, and when you'd use each.

5. What happens in the browser between the moment you hit Enter on a URL and the page finishing rendering? Walk through as much detail as you can.

6. Design a simple REST API for a to-do list application. What endpoints would you define, what would the data model look like, and what HTTP status codes matter?

7. What is the difference between SQL and NoSQL databases? Given a simple use case like storing user profiles and their posts, which would you choose and why?

8. What is an HTTP cookie vs. localStorage vs. sessionStorage? How would you decide where to store an authentication token?

9. A friend asks you to build a URL shortener (like bit.ly). Walk through the core components you'd need, the data model, and one tricky part.

10. You push a change to the frontend and users report the page is blank. How do you debug it?

11. Tell me about a technical project you're most proud of — what problem did it solve, what was hard, and what would you do differently?

12. Describe a time you were stuck on a technical problem for a long time. How did you get unstuck?

Study tips