跪拜 Guibai
← Back to the summary

A Frontend Interviewer Offered Me the Team Lead Role After Watching Me Optimize a 100k-Row Table with Claude in 5 Seconds

Last week I interviewed at a mid-sized SaaS company. The second round was with a frontend lead in his early forties.

After the pleasantries, he turned his laptop around and pushed it to the middle of the table:

"This is a real report page from our production system. 100,000 rows of data, and scrolling freezes it completely. Take a look and see how you'd optimize it. You can use any tool you want."

He said that last half-sentence very casually, and I didn't think much of it at the time.

Twenty minutes later, he put his coffee cup down on the table and asked me a question I had never anticipated in all my interview prep.

1. The Problem Itself: A Textbook Pitfall

The page code looked roughly like this (I've sanitized and rewritten it):

function ReportTable({ rows }: { rows: Row[] }) {
  // rows.length ≈ 100_000
  return (
    <table>
      <thead>...</thead>
      <tbody>
        {rows.map((row) => (
          <tr key={row.id}>
            <td>{row.name}</td>
            <td>{row.amount}</td>
            <td>{row.status}</td>
            <td>
              <Select options={statusOptions} value={row.status} />
            </td>
            <td>
              <DatePicker value={row.updatedAt} />
            </td>
          </tr>
        ))}
      </tbody>
    </table>
  );
}

Anyone with a year of React experience can spot the problems at a glance:

  1. Rendering 100,000 rows all at once → a 6–8 second white screen on first paint.
  2. Each row also mounts heavy components like <Select> and <DatePicker> with their own overlay layers.
  3. The key is fine, but diffing can't handle 400,000 DOM nodes.
  4. Hover and active states during scrolling push the browser over the edge.

In a textbook, there are three standard optimization paths:

I understood all three, but each one comes with details: do cells need to support editing? Are row heights uniform? Do you need multi-select? Can you tolerate a placeholder flash during scrolling?

To whiteboard all three and clearly explain the trade-offs — 20 minutes would be tight.

2. I Did Something That's an "Interview Taboo"

I looked up and asked:

"You said earlier I could use any tool, right?"

The interviewer nodded.

So I opened my own laptop, launched Claude Code, threw in this component along with the Row type and business constraints, and wrote a single line:

"React 18 + TS. 100,000-row table, 5 columns per row, two of which have Select and DatePicker. Product requirements: must be scrollable, must allow clicking a row to enter a detail view, and may need inline editing later. Give me three optimization approaches and explain which is most suitable under which interaction requirements."

About 4 seconds later, three approaches scrolled onto the screen.

Approach 1: Virtual Scrolling (@tanstack/react-virtual)

import { useVirtualizer } from '@tanstack/react-virtual';

function ReportTable({ rows }: { rows: Row[] }) {
  const parentRef = useRef<HTMLDivElement>(null);
  const rowVirtualizer = useVirtualizer({
    count: rows.length,
    getScrollElement: () => parentRef.current,
    estimateSize: () => 44,
    overscan: 10,
  });

  return (
    <div ref={parentRef} style={{ height: 600, overflow: 'auto' }}>
      <div style={{ height: rowVirtualizer.getTotalSize(), position: 'relative' }}>
        {rowVirtualizer.getVirtualItems().map((v) => {
          const row = rows[v.index];
          return (
            <div key={row.id} style={{
              position: 'absolute', top: 0, left: 0,
              transform: `translateY(${v.start}px)`,
              height: v.size, width: '100%',
            }}>
              {/* row cells */}
            </div>
          );
        })}
      </div>
    </div>
  );
}

Claude's comment read: "Most universal, most mature in the community. Works out of the box for uniform row heights, and inline editing is fine. The downside is that overlay components like Select/DatePicker get destroyed when scrolled out of the viewport, so their open state must be hoisted to an outer state."

Approach 2: Time-Sliced Progressive Rendering

function ReportTable({ rows }: { rows: Row[] }) {
  const [visibleCount, setVisibleCount] = useState(50);

  useEffect(() => {
    if (visibleCount >= rows.length) return;
    const id = requestIdleCallback(
      () => setVisibleCount((c) => Math.min(c + 200, rows.length)),
      { timeout: 100 }
    );
    return () => cancelIdleCallback(id);
  }, [visibleCount, rows.length]);

  return (
    <table>
      <tbody>
        {rows.slice(0, visibleCount).map((row) => (
          <tr key={row.id}>{/* cells */}</tr>
        ))}
      </tbody>
    </table>
  );
}

Claude noted: "Fastest first paint, simplest DOM structure, SEO-friendly. But scrolling to the bottom takes 10+ seconds to fully load, and users dragging the scrollbar will see gaps. Suitable for 'can't miss a row but don't need to see them all' reports — like a preview page before printing or exporting."

Approach 3: Semi-Canvas Rendering (AG Grid / Custom)

Claude directly recommended using a third-party library and gave two reasons:

"If the table will eventually need inline editing, multi-select, copy-paste, and column dragging — rolling your own will be a minefield. AG Grid's Community edition is free and sufficient. The downside is a 500KB+ bundle size and high cost to override its styles."

I turned my screen toward the interviewer. He didn't say anything, just leaned forward a bit in his seat.

3. What Really Made the Interviewer Pause Wasn't the AI's Answer

I continued:

"I'd lean toward Approach 1. Because you mentioned 'may need inline editing later' — a Canvas solution is too heavy to change, and the time-sliced approach causes reflows when an edit focus jumps out. Virtual scrolling just needs the overlay components' open state hoisted to the parent. Want to run a Performance check and see?"

I ran all three approaches in their test environment with Chrome DevTools' Performance panel open.

First paint dropped from 6.8 seconds to 320 milliseconds — 21 times faster.

The interviewer put down his coffee cup and asked me the first "unexpected" question:

"How did you determine that hoisting the overlay state to the parent was enough?"

I said:

"I didn't determine it directly. After Claude gave the approach, I followed up with another question — 'If a row's Select is open and the user scrolls that row out of the viewport, what happens?' It answered that the component would unmount and the overlay would simply disappear. So I added a line in Approach 1: lift openId to the parent component and render the overlay via a Portal. That way it won't close even when scrolled out."

The interviewer stared at me for two seconds and asked a second question:

"Do the other frontend developers on your team use AI like this?"

I answered honestly: no. Most colleagues either don't use it at all, or they directly Ctrl+C Ctrl+V the AI's answer and commit it.

He gave an "mm," and then came the third question — the one that kept me thinking the whole way after I left the meeting room:

"Our frontend team lead is transferring next month. Would you consider the position?"

4. What I Figured Out on the Subway

On the subway ride back, I kept wondering: what exactly did he see in me?

It wasn't virtual scrolling. I could have answered Approach 2 and Approach 3 just as well; any senior frontend developer could.

It wasn't AI. There were definitely people on their team with Claude or Cursor open.

After thinking it through, I arrived at three points, which I'm writing here for friends who are also job-hopping:

1. He was looking at information bandwidth, not answer speed

Traditional interviews test "how much knowledge you have stored in your head." But when everyone can invoke the same AI from their head, the evaluation shifts to "how good are the questions you can ask per unit of time."

The prompt I threw at Claude contained five key elements:

If I had only written "help me optimize this laggy table," Claude's answer would have been baseline.

What the interviewer actually saw was: this person's prompt contains five years of frontend experience.

2. He was looking at verification ability, not adoption ability

When presenting the approach, I said one sentence: "This came from Claude, but I verified it with the Performance panel."

The reason that sentence was key is that it draws a line between two types of people:

The latter type isn't common on teams. And that type of person is capable of leading a team.

3. He was looking at how you make AI work, not whether you can use AI

The image of a frontend team lead in his mind was probably something like:

"Someone who can use AI as an amplifier, whose output alone equals three people. And who knows when not to trust AI — for example, when overlays detach from the viewport, or when bundle size can't be sacrificed."

In demonstrating my problem-solving process, I had inadvertently revealed both of those points.

5. For Frontend Developers Still Preparing for Interviews

If you're also job-hopping, especially in the transition zone from mid-sized companies to large ones, here's some advice after what I've been through:

Bring your laptop if you can. More and more companies now allow using tools on the spot. Don't be afraid that the interviewer will think you rely on AI — what they care about is how you use it.

Practicing "asking questions" has a bigger payoff than practicing "writing by hand." Hand-writing a Promise, a deep clone, or an EventEmitter — AI can solve those in three seconds. But a prompt like "give me three approaches + compare applicable scenarios + combine data scale and interaction constraints" — that requires real practice.

Every time AI gives you an answer, force yourself to follow up with "what if X condition doesn't hold?" For example:

This is the only way to turn AI's ceiling into your floor.

Prepare a story about "how I use AI." Not theory — a specific, concrete collaboration process. The value of that story is far greater than memorizing the principles of React Fiber.

Epilogue

It's 2026. The way frontend developers are evaluated has changed.

The change isn't "do you know how to use AI," but "can you bring AI along and accomplish what one person alone cannot."

In those two seconds when the interviewer put down his coffee that day, I could almost hear what was going through his mind:

"Once this person joins, I can cut this quarter's schedule in half."

Being thought of that way is worth more than handwriting ten rote-memorized interview questions.