跪拜 Guibai
← Back to the summary

Full-Stack Interviews in the AI Era Now Test Architecture, Not API Memorization

Full-Stack Interview Guide in the AI Era: From Memorizing Trivia to Discussing Architecture

Foreword: What is this book for?

If your current situation is:

Then this book is written for you.

In the past, interviews tested "can you write it." Now they test "do you understand why." AI has demolished the barrier to writing code, so the interviewer's attention naturally shifts upward—from "how to implement" to "how to design," "how to optimize," and "how to handle failure."

This book won't teach you to memorize APIs (AI can do that anyway). Instead, it helps you build an expression framework for interviews. Every chapter includes "Say This in an Interview" script templates you can use immediately.

Chapter 1: Interviews Have Changed, So Must You

1.1 Before They Tested "How to Write," Now They Test "Why"

Old interview:

Interviewer: "Write a Promise by hand." You: Recite code, write then/catch chains.

New interview:

Interviewer: "Your page has 1000 async requests returning simultaneously. Before the Promises finish processing, you get a memory overflow. How do you troubleshoot?" You: …

What's the difference? Before they tested memory. Now they test your problem-solving thought process.

AI can generate Promise source code in a second, but it doesn't know which part of your business scenario will break. The interviewer wants you to articulate: "Why does the problem happen here? How many solutions exist? What are the trade-offs of each?"

Say this in an interview:

"When encountering a memory overflow, I first check the Chrome Performance panel to capture a Heap Snapshot and determine whether closures are holding references or Promises are piling up. If Promises are piling up, I'd consider using p-limit for concurrency control, or splitting large tasks into Worker threads."

1.2 How to Talk About "I Used AI" in an Interview

Don't hide it. Using AI assistance in interviews is normal now, but the key is how you frame it.

If You Say This Effect
"AI wrote this code, I didn't look at it closely" ❌ Instant rejection
"I had AI generate a basic version, then I did three things: added input validation, added exception handling, and changed O(n²) to O(n)" ✅ Bonus points

Core logic: AI is your intern; you are the code reviewer. The interviewer wants to see whether you have the ability to review AI-generated code.

Say this in an interview:

"My current workflow is: first use AI to generate skeleton code, then focus on checking three areas—boundary conditions (like empty arrays, extremely large numbers), security (like SQL injection, XSS), and performance bottlenecks (like N+1 queries). This is the most efficient approach and avoids pitfalls."

Chapter 2: Frontend Interviews—Don't Just Talk About 'How to Draw a Page'

2.1 JS Fundamentals: Interviewers Love to Dig Deep Here

2.1.1 Closures: Don't Recite the Definition, Explain the 'Pitfalls'

Stop saying this:

"A closure is when a function returns a function, and the inner function accesses outer variables."

Say this instead:

"The essence of a closure is that the scope chain hasn't been released. For example, if I bind click events inside a for loop and use var, all clicks will pop up the same value. The solution is to use let for block scope, or wrap it in an IIFE."

High-frequency exam topic: Closure traps in React Hooks

// Trap: When you click the button, count is always 0
function Counter() {
  const [count, setCount] = useState(0);
  
  useEffect(() => {
    const timer = setInterval(() => {
      console.log(count); // Always prints 0!
    }, 1000);
    return () => clearInterval(timer);
  }, []); // Empty dependency array, closure captured the old count
}

How to solve it? Use useRef to store the latest value, or put count in the dependency array.

Say this in an interview:

"The closure problem in React Hooks is essentially a mismatch between the dependency array and the render timing. My habit is: use ESLint's react-hooks/exhaustive-deps rule for automatic checking, and in complex scenarios, use useRef as a 'time capsule' to ensure I always get the latest value."

2.1.2 Event Loop: The Plain Language Version

One-sentence version: JS is single-threaded, so tasks must queue up. Macro-tasks (setTimeout) register first, micro-tasks (Promise.then) cut in line, and the page only renders after all micro-tasks are cleared.

Interviewers love to ask: "Why does the page freeze?"

Say this in an interview:

"The page freezes because the main thread is occupied by a long task, and the rendering frame doesn't get a chance to execute. For example, if I calculate the Fibonacci sequence on the main thread, the UI becomes unresponsive. There are two solutions: one is to break the calculation into small chunks and use requestIdleCallback to execute them during idle time; the other is to offload it directly to a Web Worker, leaving the main thread responsible only for UI updates."

Memory aid: Macro-task → Micro-task → Render, one loop goes through three stages.

2.2 React/Vue: Frameworks Aren't Tools, They're Design Philosophies

2.2.1 Virtual DOM: What the Interviewer Wants to Hear is 'Trade-offs'

Classic question: "Since AI can manipulate the DOM directly, why do we still need the Virtual DOM?"

Say this in an interview:

"The Virtual DOM isn't about achieving the absolute best performance; it's about developer experience and maintainability. Direct DOM manipulation is indeed faster on simple pages, but it quickly becomes chaotic as state grows. The Virtual DOM acts as a 'buffer' layer between data and the real DOM, allowing me to write declaratively (just caring about what the state is, not how to change the DOM), while the Diff algorithm compresses the complexity from O(n³) down to O(n)."

Bonus points: Mention cross-platform.

"Moreover, the Virtual DOM isn't tied to the browser. React Native and Mini Programs can all use the same logic, which is something imperative DOM manipulation can't do."

2.2.2 State Management: How to Choose?

Interviewer asks: "For a new project, would you choose Redux or Zustand?"

Say this in an interview:

"It depends on the team size and business complexity. For a small project, Zustand has less code, good TypeScript support, and is quick to pick up. For a large backend system with multiple collaborators, Redux's DevTools and time-travel debugging are more advantageous. Actually, in the AI era, the cost of writing Redux boilerplate is already very low, but the core of the selection is whether the mental model matches the business—for example, for high-frequency cross-component communication, Jotai's atomic approach is more flexible."

Pitfall to avoid: Don't just say "I use Redux" right off the bat; it makes you look like you just memorized buzzwords.

2.3 Performance Optimization: Use Data, Not Superstition

Interviewer asks: "The page loads slowly, how do you optimize it?"

Wrong answer: "I do code splitting, lazy loading, image compression…" (Too generic, sounds memorized)

Correct answer:

"First, run a baseline with Lighthouse to see which specific metric is poor. If FCP is slow, check if server-side rendering or critical CSS inlining isn't done well. If LCP is slow, check if the largest element is an image, and switch to WebP + CDN + preloading. If CLS layout is jittery, check if images lack width/height or if font loading is causing reflows. After optimizing, run it again and compare the data."

Interview golden phrase:

"Performance optimization isn't superstition; it's measurement. Optimizing without data is like driving blindfolded."

AI-assisted bonus points:

"I also have AI analyze the Webpack bundle to check for duplicate dependencies or libraries where Tree Shaking didn't take effect. Sometimes a full import of lodash alone can add dozens of KB."

Chapter 3: Backend Interviews—Stability is the Top Priority

3.1 Language Choice: No Best, Only Most Suitable

Interviewer asks: "Why did you use Node.js for the backend?"

Scenario Recommended Language Reason
I/O-intensive (API gateway, chat room) Node.js Event loop handles concurrent connections with low overhead
High-concurrency middleware, microservices Go Goroutines are user-space threads, scheduling is extremely fast
Enterprise complex business, big data Java JVM ecosystem is mature, GC optimization is well-established

Say this in an interview:

"I chose Node.js because the team has a frontend background, so the tech stack is unified and development efficiency is high. But I know its weakness—single-threaded CPU-intensive tasks (like image processing, complex calculations) will block the event loop. So I offload these tasks, either using child processes or directly handing them to a Go service, with Node only handling I/O scheduling."

3.2 Databases: Indexes, Transactions, Locks—The Three Axes

3.2.1 Indexes: B+ Tree is a Must-Know Question

Interviewer asks: "Why does MySQL use B+ Tree instead of Hash?"

Say this in an interview:

"Hash indexes are indeed fast for single-record lookups, but they can't do range queries (like WHERE age > 18). All data in a B+ Tree is stored in leaf nodes, and the leaves are linked together with pointers into a sorted linked list. During range queries, the disk can read sequentially, which is very efficient. This is determined by disk I/O characteristics—sequential reads are an order of magnitude faster than random reads."

Memory trick: B+ Tree = a library's catalog cabinet. The leaf nodes are the books on the shelves, arranged in order. Finding a series of books (range query) is especially fast.

3.2.2 Transaction Isolation Levels: Remember with 'Buying a Ticket'

Isolation Level Problem Real-life Analogy
Read Uncommitted Dirty Read Seeing someone else's unpaid order
Read Committed Non-repeatable Read Refreshing the page, the price changed
Repeatable Read Phantom Read (InnoDB has solved this) Checking balance is 100, but it becomes 80 when deducting
Serializable No problems, but slow Queuing to buy tickets, one by one

Say this in an interview:

"For e-commerce inventory deduction, you must use at least Repeatable Read level, combined with row locks. If you only use Read Committed, overselling can occur—A and B both read stock=1 simultaneously, both place orders successfully, and the result becomes -1. The solution is to add WHERE stock > 0 during the UPDATE, using the database row lock as an optimistic lock safety net."

3.2.3 Redis: Data Structures ARE Application Scenarios

Don't just recite "String, List, Hash"; connect them to scenarios:

Data Structure Classic Scenario Key Commands
String Distributed locks, caching SETNX key value EX 10
ZSet Leaderboards, delayed queues ZADD, ZREVRANGE
BitMap Check-in statistics (extremely memory-efficient) SETBIT, BITCOUNT
HyperLogLog UV statistics (allows error) PFADD, PFCOUNT

The Three Cache Brothers (Must-Know):

  1. Cache Penetration (Querying non-existent data, directly hitting the DB)

    • Solution: Bloom filter, or cache a null value (with a short expiration time)

  2. Cache Breakdown (A hot key suddenly expires, massive requests hit the DB)

    • Solution: Mutex lock, allowing only one thread to rebuild the cache

  3. Cache Avalanche (A large number of keys expire simultaneously, DB instantly explodes)

    • Solution: Add a random offset to expiration times, or never expire + proactive updates

Say this in an interview:

"A Bloom filter can block 99% of invalid requests, but it has a false positive rate (it might judge something non-existent as existing), so a secondary check is needed afterward. If the business has zero tolerance for false positives, I'd directly cache a null value with a 30-second expiration to prevent malicious attacks."

3.3 Distributed Systems: CAP is a Talking Point, Not a Truth

Interviewer asks: "Tell me about the CAP theorem?"

Say this in an interview:

"CAP states that when a network partition occurs, you can only guarantee either consistency or availability. But in actual engineering, we rarely make a binary choice; instead, we make a trade-off. For example, e-commerce orders use CP (money can't be wrong), while product listings use AP (brief inconsistency is okay, as long as the user can still browse). Most systems pursue eventual consistency, for instance, by using a message queue to synchronize data asynchronously."

Distributed Locks (High Frequency):

"For distributed locks with Redis, you can't simply use SETNX, because if the service crashes without releasing the lock, it's a deadlock. The correct approach is to use SET key value NX EX 10 (an atomic command), and then add a watchdog thread to renew the lock if the business hasn't finished executing. A more rigorous solution is RedLock, which acquires locks on multiple Redis nodes simultaneously to prevent single-node failures."

Message Queues (Interviewers Love to Ask About Reliability):

"Messages cannot be lost; all three ends must confirm: the producer waits for a Broker ACK after sending; the Broker persists the message (like Kafka's multi-replica); the consumer ACKs after processing. If consumption fails, it goes to a dead-letter queue for manual or automatic retry."

Chapter 4: System Design—The Final Boss of Full-Stack Interviews

4.1 URL Shortener System: A Classic Among Classics

Interviewer: "Design a URL shortening service, like bit.ly."

Step 1: Clarify Requirements First (Show Your Rigor)

"Let me first confirm a few numbers: What's the approximate DAU? What's the read-to-write ratio? How long is the short link valid?"

Assumptions: 10 million DAU, read:write = 100:1, short links are permanent.

Step 2: Back-of-the-Envelope Calculation (Show Your Engineering Mindset)

Step 3: Choose a Solution

Solution Principle Pros Cons
Hash Method Compute MurmurHash of long URL, convert to Base62 Simple, stateless Potential collisions, irreversible
ID Generator Snowflake generates unique ID, convert to Base62 No collisions, trend-increasing Long/short URL binding is rigid, IDs can be predicted

Say this in an interview:

"For small to medium scale, hashing + a database unique index as a safety net is sufficient and simple to implement. For large scale (like Twitter), use a Snowflake ID generator, converting the 64-bit ID to a 7-character Base62 short code. On the read path, use a CDN to cache hot links, Nginx for rate limiting, and a Bloom filter to block invalid short codes from cache penetration."

Architecture Diagram Script:

"Write path: API → ID Generator → MySQL (Master) → Sync to Redis. Read path: CDN → Nginx → API → Redis → MySQL (only query DB on cache miss)."

4.2 Instant Messaging System: Like WeChat

Core Challenges: Massive persistent connections + ordered messages + no message loss

Connection Layer:

"Use WebSocket for keep-alive, with a 30-second heartbeat interval. The gateway layer uses Go or Netty; a single machine can handle hundreds of thousands of connections. When a user comes online, map their userId and gateway address in Redis for message routing."

Message Storage: Write Diffusion vs. Read Diffusion

Solution Suitable For Principle
Write Diffusion Small groups (<500 people) Send one message, write it into each member's inbox
Read Diffusion Large groups, public accounts Write only one message to the group message table; members fetch it on demand

Say this in an interview:

"WeChat uses write diffusion for 1-on-1 chats and groups under 500 people for fast reads; for 2000-person large groups and Moments, it uses read diffusion to reduce write pressure. The message table is sharded by user_id to ensure one person's messages land on the same machine."

Message Reliability:

"Messages are delivered at least once. The client generates a unique msgId when sending, and the server deduplicates. The receiver sends an ACK upon receipt; if no ACK is received, it retries. Message state machine: Sending → Delivered → Read."

Chapter 5: AI-Native Development—New Exam Topics, Don't Panic

5.1 RAG: Giving AI a 'Reference Library'

Interviewer asks: "How do you make an AI answer questions based on our company's internal documents?"

Say this in an interview:

"This is RAG (Retrieval-Augmented Generation). The process is: first, split the documents into small chunks (e.g., 512 characters each), use an Embedding model (like OpenAI's text-embedding-ada-002) to convert them into vectors, and store them in a vector database (like Milvus). When a user asks a question, vectorize the question first, search the database for the Top 5 most similar document chunks, stuff this content into the Prompt, and then let the AI answer."

Solving Hallucination:

"AI talks nonsense because it's making things up. My approach is: in the answer, force the AI to cite its sources, like 'According to Chapter 3 of the Employee Handbook…'. If the retrieved documents have low relevance, just answer 'Cannot confirm based on available information,' and don't fabricate."

Long Text Processing:

"If a document is super long (like a 100-page PDF), stuffing it directly will exceed the token limit. I use a Map-Reduce strategy: first, have the AI summarize each page into one sentence (Map), then aggregate all summaries into a final answer (Reduce)."

5.2 Agent: AI Doesn't Just Chat, It Can Do Work

Interviewer asks: "Design an Agent that automatically fixes bugs."

Say this in an interview:

"The core is to use the LLM as the 'brain' that orchestrates a toolchain. The process: 1) Read the CI error log and have the AI analyze the root cause; 2) AI calls a code search tool (like ripgrep) to locate the file; 3) AI generates a fix patch; 4) Automatically run the test suite; 5) If the tests fail, feed the error log back to the AI and iterate. You can use a framework like LangChain to string the process together, but the core isn't the framework—it's the feedback loop. The Agent must be able to adjust its next action based on the execution result."

5.3 Vector Databases: Several Dimensions for Selection

Say this in an interview:

"Selection depends on three metrics: recall rate (how accurate the search is), QPS (can it handle the concurrency), and latency (how long the user has to wait). For indexing algorithms, HNSW is suitable for small datasets with high recall, while IVF is suitable for large datasets with high throughput. In practice, you also need to consider hybrid queries—for example, vector similarity + tag filtering (only search documents from the last 7 days)."

Chapter 6: Interview Soft Skills—Beyond Tech, Equally Important

6.1 Be Honest, But Tactical

What if you're asked about using AI assistance during a written test?

Say this in an interview:

"I used AI to generate an initial version for this problem, but I focused on doing three things: first, I checked boundary conditions (like empty input, very large arrays); second, I changed the AI's recursion to iteration to prevent stack overflow; third, I added unit tests to cover exception branches. I see AI as a tool; the key is the human's review and safety net."

Core: Be neither arrogant nor humble; demonstrate engineering discipline.

6.2 'Why' is Worth More Than 'How'

Every 'why' from an interviewer is a free point.

Question Bad Answer Good Answer
Why use PostgreSQL? "Because I'm familiar with it" "Because the business has complex queries and transaction needs. PG's MVCC and JSONB support are more flexible than MySQL's. If we need geospatial queries later, the PostGIS plugin can also be directly extended."
Why use microservices? "Because it's popular" "Because the team has 20 people, and code conflicts in the monolith are severe. But I also know the cost of microservices—operational complexity, distributed transactions. If the team were under 5 people, I'd firmly stick with a monolith."
Why use WebSocket? "Because it's real-time" "Because the server push frequency is high (once per second), and polling would waste too many resources. If the frequency were low (e.g., once every 5 minutes), HTTP polling would be simpler and more fault-tolerant."

Formula: Tech selection = Business scenario + Team size + Cost awareness.

6.3 Asked "AI is so powerful, how do you stay competitive?"

Say this in an interview:

"I divide my capabilities into two layers: the bottom layer is principles and architectural thinking, like distributed consistency, database indexes, and network protocols. AI can only assist in understanding these; decisions still rely on humans. The top layer is engineering implementation, like specific APIs and boilerplate code, which I hand over to AI for efficiency. My energy allocation is 70% studying principles and 30% using AI for implementation. This way, I can both define problems and validate results, rather than being a human code generator."

6.4 One-Week Pre-Interview Checklist

Day Task
Day 7 Map out the architecture diagram of your own project; be able to draw it and clearly explain the data flow
Day 5 Review common algorithms (Easy and Medium from the Top 150)
Day 3 Prepare 3 "My proudest technical decision" stories using the STAR method
Day 1 Research the company's products and business, design a related small system for practice
Interview Day Bring pen and paper. When you get a design question, draw first, then explain. Don't just talk dryly.

6.5 How to Save the Situation When You Hit a Question You Don't Know

Don't just say "I don't know." Use "I haven't done this, but I can reason it out":

"I haven't actually encountered this specific scenario, but I can analyze it from a certain angle. For example, the high-concurrency deduction you mentioned is similar to e-commerce inventory deduction; the core is ensuring atomicity. I might first consider a database optimistic lock. If the QPS is too high, then I'd consider Redis pre-deduction + asynchronous write-back to the database…"

What the interviewer wants to see isn't whether you know the answer, but whether you have a problem-solving framework.

Conclusion: You Don't Need to Remember All the Answers

There are no standard answers in this book, only thinking frameworks.

The essence of an interview is a conversation. The interviewer isn't looking for a "human search engine," but a teammate who can clarify their thoughts, make trade-offs, and handle risks when encountering a problem.

In the AI era, remember this:

Knowing that 'a problem exists' is more important than knowing 'what the answer is.' Knowing 'how to find the answer' is more important than 'memorizing the answer.'

Go to your interview. Bring your thought process, not your anxiety. Good luck.

Comments

Top 1 from juejin.cn, machine-translated. The original thread is authoritative.

廾匸22

👍