AI 时代的工程师面试，可能要换一种看法

这篇是和 AI 闲聊后整理出来的一段想法。原始表达比较散，后来请 AI 帮忙顺了一下。

最近一直在想一个问题：AI 已经能写代码、改代码、补测试、整理文档了，那工程师面试是不是也该换一种问法了？

过去很多面试，其实是在看一个人会不会写某种代码。

• 会不会 Java
• 会不会 Python
• 会不会 React
• 会不会算法题
• 会不会背一些框架和八股

这些当然不是完全没用。一个人如果完全没有基础，很多问题还是走不下去。

但在 AI 已经参与开发的情况下，只看这些东西，好像越来越不够了。因为很多“写出来”的部分，AI 都可以帮忙完成。真正难判断的，反而变成了另外两件事：

• 这个人能不能让 AI 做出一个可控的系统。
• 这个人能不能解释这个系统为什么这样做。

也就是说，未来面试里最重要的可能不是“你能不能现场写出这段代码”，而是：

你能不能让 AI 写出你自己也能解释、能维护、能负责的系统。

传统面试哪里不够了

传统面试有一个隐含前提：

写代码本身，可以代表工程师能力。

这个前提以前大体成立。因为代码主要靠人写，一个人能不能把需求拆开、把逻辑写顺、把 bug 调出来，基本都能从写代码里看出来。

但现在有了 AI，这件事变复杂了。

很多人都可以让 AI 写一个 CRUD 页面，让 AI 生成接口，让 AI 补测试，让 AI 改报错。只看最后的代码，很难知道里面有多少是候选人真正理解的，有多少只是 AI 生成后勉强跑起来的。

所以面试如果还停留在“会不会某个语法”“能不能现场写一段函数”，就很容易看偏。

我觉得更应该看的，是候选人和 AI 一起工作时，能不能把事情收住。

比如：

• 需求是怎么拆的。
• 模块边界是怎么定的。
• 数据从哪里来，到哪里去。
• 状态如何流转。
• 异常情况怎么处理。
• 哪些地方交给 AI，哪些地方必须自己判断。
• AI 生成的代码如何确认没有跑偏。

这些东西，比单纯问“你会不会写某段代码”更接近真实工作。

第一件事：看他怎么和 AI 协作

如果以后让我面试工程师，我可能会先问一个很普通的问题：

你平时怎么让 AI 协助你开发？能不能讲一下流程？

这个问题听起来很简单，但其实很能看出差别。

如果回答只是：

• 我让 AI 写代码。
• 我让 AI 修 bug。
• 我让 AI 生成注释。
• 我让 AI 写测试。

那说明他可能只是把 AI 当成一个更快的代码生成器。

这当然也有价值，但还不够。真正做过一段时间 AI 协作开发的人，通常会讲得更具体：

• 先让 AI 帮忙梳理需求，但自己确认边界。
• 先定接口和数据结构，再让 AI 补实现。
• 对复杂流程先画状态，再生成代码。
• 每次只让 AI 改一个范围，不让它顺手改太多。
• 让 AI 写测试，但自己确认测试覆盖的是不是关键风险。
• 出问题时，不只让 AI 猜 bug，而是让它沿着调用链查。
• 代码跑通以后，还要回头整理命名、结构和文档。

这些细节说明一件事：他不是在“等 AI 变魔法”，而是在把 AI 放进一个工程流程里。

AI 协作能力，可能会变成未来工程师很重要的一部分。

不是会不会 prompt，而是能不能把一个模糊需求，逐步变成可验证、可解释、可维护的东西。

第二件事：看他能不能解释系统

另一个我觉得非常有效的问题是：

跑一下你做过的系统，然后讲解一下。

这比单纯看简历、看代码片段、问知识点更直接。

因为一个人是不是真的理解系统，讲一遍基本就能看出来。

他应该能说清楚：

• 为什么这样拆模块。
• 为什么这里要有这个状态。
• 数据从哪个入口进来。
• 哪些地方会写数据库。
• 哪些地方只是读取。
• 异常路径怎么走。
• 失败以后能不能恢复。
• 这个设计当时牺牲了什么。

这些问题不一定要回答得很漂亮，但应该有因果关系。

如果一个系统是自己真正做过、真正调过、真正踩过坑的，讲的时候通常会有一种很具体的感觉。哪里绕，哪里脆，哪里以后要重构，自己心里会有数。

反过来，如果只是让 AI 生成了很多代码，然后自己没有真正吃进去，讲解时就会很容易散。

不是某个 API 名字忘了的问题，而是整条链路说不清楚。

面试可以变成两个动作

所以我觉得 AI 时代的工程师面试，至少可以加入两个动作。

第一个动作，是问 AI 协作流程：

你怎么把 AI 放进开发流程里？

这里看的不是他说了多少工具名，而是有没有工程节奏。比如如何拆需求、如何限制范围、如何验证结果、如何处理 AI 跑偏。

第二个动作，是让他跑系统并讲解：

打开一个你做过的东西，从入口开始讲到数据落点。

这里看的不是界面多漂亮，也不是代码量多大，而是他能不能解释系统的结构、边界、状态和风险。

这两个动作合在一起，大概能看出很多东西：

• 他是不是只会让 AI 输出代码。
• 他有没有自己的判断。
• 他能不能控制复杂度。
• 他能不能解释自己交付的东西。
• 他知不知道哪些地方不能完全交给 AI。

“会写代码”还重要吗

我不觉得写代码不重要。

基础能力还是重要的。完全不懂代码的人，很难判断 AI 写出来的东西有没有问题，也很难在系统变复杂以后守住边界。

只是“会写代码”可能不再是唯一中心。

以前工程师的价值，更多体现在亲手把代码写出来。以后可能会更多体现在：

• 把需求拆成 AI 能处理的小块。
• 把 AI 的输出放回系统里检查。
• 发现 AI 没有意识到的边界。
• 对最终结果负责。
• 在复杂度开始膨胀时及时收住。

换句话说，工程师还是工程师，只是手里的工具变了。

AI 可以写很多代码，但它不能替你承担系统后果。系统最后跑不跑得稳，边界清不清楚，出了问题能不能解释，还是人的责任。

结语

如果只看“写代码”，AI 确实让很多传统面试题变得没那么有区分度。

但如果看“能不能解释系统”，工程师之间的差别反而会更明显。

因为 AI 可以帮忙生成实现，却很难替一个人建立真正的系统理解。

所以未来的工程师面试，可能不应该只问：

你会不会写这段代码？

而应该多问：

你是怎么让 AI 参与进来的？

以及：

这个系统为什么是这样？

这篇文章只是我个人的观察和记录，不是为了给面试定标准。只是觉得 AI 时代来了以后，工程师真正要被看的地方，可能正在慢慢换位置。

日本語版

この文章は、AI と雑談したあとに考えを整理したものです。もとの表現はかなり散らかっていたので、あとから AI に流れを整えてもらいました。

最近ずっと考えていることがあります。AI がコードを書き、修正し、テストを補い、ドキュメントまで整理できるようになった今、エンジニアの面接も少し見方を変える必要があるのではないか、ということです。

これまでの面接では、多くの場合、その人が特定のコードを書けるかどうかを見ていました。

• Java が書けるか。
• Python が書けるか。
• React が使えるか。
• アルゴリズム問題を解けるか。
• フレームワークや定番知識を覚えているか。

もちろん、これらが不要になったわけではありません。基礎がまったくなければ、進められない問題は今でも多いです。

ただ、AI が開発に入ってくると、それだけでは判断しにくくなります。なぜなら、コードを書く部分の多くは AI が手伝えるからです。むしろ見えにくくなるのは、別の二つのことです。

• その人は、AI に制御可能なシステムを作らせることができるのか。
• その人は、そのシステムがなぜそうなっているのかを説明できるのか。

つまり、これからの面接で重要になるのは、「その場でコードを書けるか」だけではなく、次のようなことかもしれません。

AI に、自分自身が説明でき、保守でき、責任を持てるシステムを書かせることができるか。

従来の面接で足りなくなるところ

従来の面接には、暗黙の前提がありました。

コードを書くことは、エンジニアの能力を表している。

以前は、これはかなり成り立っていました。コードは主に人が書いていたので、要求を分解できるか、ロジックを組めるか、バグを追えるかは、コードを書く過程である程度見えました。

しかし AI がある今、この前提は少し複雑になっています。

多くの人が、AI に CRUD 画面を書かせ、API を作らせ、テストを補わせ、エラーを直させることができます。最後に出てきたコードだけを見ても、候補者がどこまで本当に理解しているのか、どこまでが AI に生成させて何とか動かしただけなのかは分かりにくいです。

だから面接が「この文法を知っていますか」「この関数をその場で書けますか」だけに留まると、見たいものから少しずれてしまう気がします。

むしろ見たいのは、その人が AI と一緒に作業するとき、物事をきちんと収められるかどうかです。

たとえば、こういうことです。

• 要求をどう分けたのか。
• モジュールの境界をどう決めたのか。
• データはどこから来て、どこへ行くのか。
• 状態はどう変化するのか。
• 例外や失敗はどう扱うのか。
• どこを AI に任せ、どこを自分で判断するのか。
• AI が生成したコードがずれていないか、どう確認するのか。

こうした点のほうが、単に「このコードを書けるか」を聞くより、実際の仕事に近いと思います。

一つ目は、AI とどう協働しているかを見ること

もしこれから自分がエンジニアを面接するなら、まずこう聞くかもしれません。

普段、AI をどう開発に使っていますか。流れを説明できますか。

簡単な質問に見えますが、実はかなり差が出ます。

答えがただ、

• AI にコードを書かせています。
• AI にバグを直させています。
• AI にコメントを書かせています。
• AI にテストを書かせています。

だけで終わるなら、その人は AI を速いコード生成器として使っているだけかもしれません。

それにも価値はあります。ただ、それだけでは足りません。実際に AI と開発を続けてきた人は、もう少し具体的に話すことが多いです。

• まず AI に要求を整理させるが、境界は自分で確認する。
• 先にインターフェースとデータ構造を決めてから、実装を補わせる。
• 複雑な処理は、先に状態の流れを整理してからコードにする。
• 一度に AI に触らせる範囲を小さくする。
• AI にテストを書かせるが、重要なリスクを見ているかは自分で確認する。
• 問題が起きたとき、AI に推測させるだけでなく、呼び出し経路をたどらせる。
• 動いたあとで、命名、構造、ドキュメントを見直す。

こういう細部があると、その人は AI に魔法を期待しているのではなく、AI を工程の中に置いているのだと分かります。

AI との協働能力は、これからのエンジニアにとってかなり重要になると思います。

それは、うまいプロンプトを書けるかどうかではありません。曖昧な要求を、検証でき、説明でき、保守できるものに変えていけるかどうかです。

二つ目は、システムを説明できるかを見ること

もう一つ、とても有効だと思う質問があります。

自分が作ったシステムを動かして、説明してもらえますか。

これは、履歴書やコード片を見るよりも直接的です。

その人が本当にシステムを理解しているかどうかは、一度説明してもらうとかなり見えてきます。

説明できるべきなのは、たとえばこういうことです。

• なぜこのようにモジュールを分けたのか。
• なぜここにこの状態があるのか。
• データはどの入口から入るのか。
• どこでデータベースに書き込むのか。
• どこは読み取りだけなのか。
• 異常系はどう流れるのか。
• 失敗したあとに回復できるのか。
• この設計で何を犠牲にしたのか。

答えが完璧である必要はありません。ただ、因果関係はあるはずです。

本当に自分で作り、動かし、問題にぶつかったシステムなら、説明には具体性が出ます。どこが複雑で、どこが弱く、どこをいつか直したいのか、自分なりに分かっているはずです。

逆に、AI に多くのコードを生成させただけで、自分の中に取り込めていない場合、説明は散らかりやすいです。

問題は API 名を一つ忘れることではありません。入口から出口までの流れを説明できないことです。

面接は二つの動作にできる

だから、AI 時代のエンジニア面接には、少なくとも二つの動作を入れてもよいと思います。

一つ目は、AI との協働プロセスを聞くことです。

AI をどう開発プロセスに入れていますか。

ここで見るのは、ツール名をいくつ知っているかではありません。要求をどう分けるか、範囲をどう制限するか、結果をどう検証するか、AI がずれたときにどう戻すかです。

二つ目は、作ったシステムを動かして説明してもらうことです。

自分が作ったものを開いて、入口からデータの到達点まで説明してください。

ここで見るのは、画面がきれいかどうかでも、コード量が多いかどうかでもありません。その人がシステムの構造、境界、状態、リスクを説明できるかどうかです。

この二つを合わせると、かなり多くのことが見えてきます。

• ただ AI にコードを出させているだけなのか。
• 自分の判断があるのか。
• 複雑さを制御できるのか。
• 自分が納品したものを説明できるのか。
• どこを AI に完全には任せられないか分かっているのか。

「コードを書けること」はまだ重要か

私は、コードを書く力が不要になるとは思っていません。

基礎能力は今でも重要です。コードがまったく分からなければ、AI が出したものに問題があるかどうか判断できませんし、システムが複雑になったときに境界を守ることも難しいです。

ただ、「コードを書けること」だけが中心ではなくなるかもしれません。

以前のエンジニアの価値は、自分の手でコードを書くところにより強く表れていました。これからは、次のようなところにより表れるのかもしれません。

• 要求を AI が扱える小さな単位に分ける。
• AI の出力をシステムの中に戻して確認する。
• AI が気づいていない境界を見つける。
• 最終的な結果に責任を持つ。
• 複雑さが膨らみ始めたときに止める。

言い換えると、エンジニアはこれからもエンジニアです。ただ、手に持つ道具が変わっただけです。

AI は多くのコードを書けますが、システムの結果に責任を持つことはできません。最後に安定して動くのか、境界が明確なのか、問題が起きたときに説明できるのか。それはやはり人の責任です。

終わりに

「コードを書くこと」だけを見るなら、AI によって従来の面接問題の区別力は少し下がっていると思います。

でも「システムを説明できるか」を見るなら、エンジニアの差はむしろ見えやすくなるかもしれません。

AI は実装を助けることはできます。しかし、その人自身のシステム理解を代わりに作ることは難しいです。

だからこれからのエンジニア面接では、

このコードを書けますか。

だけではなく、

AI をどう参加させましたか。

そして、

このシステムはなぜこうなっていますか。

も聞いたほうがよいのかもしれません。

これはあくまで個人的な観察と記録です。面接の基準を決めたいわけではありません。ただ、AI の時代になって、エンジニアを見る場所が少しずつ変わってきている気がしています。

English Version

This article came from a casual conversation with AI. My original thoughts were scattered, so I later asked AI to help organize the flow.

Lately I have been thinking about one question: now that AI can write code, edit code, add tests, and organize documentation, should engineering interviews also change a little?

Many traditional interviews are really trying to see whether someone can write a certain kind of code.

• Can they write Java?
• Can they write Python?
• Can they use React?
• Can they solve algorithm problems?
• Can they recite framework knowledge and common interview answers?

These things are not useless. If someone has no foundation at all, many problems still cannot move forward.

But once AI becomes part of development, these questions are no longer enough. Many of the parts that used to mean "writing code" can now be helped by AI. What becomes harder to judge are two other things:

• Can this person make AI produce a controllable system?
• Can this person explain why the system is built this way?

In other words, the important question in future interviews may not be only "Can you write this code on the spot?" It may be:

Can you make AI write a system that you can explain, maintain, and take responsibility for?

Where traditional interviews start to fall short

Traditional interviews have an implied assumption:

Writing code represents engineering ability.

In the past, this was mostly true. Since humans wrote most of the code, you could often see whether someone could break down requirements, organize logic, and debug problems through the act of writing code.

But with AI, this becomes more complicated.

Many people can ask AI to write a CRUD page, generate an API, add tests, or fix an error. If we only look at the final code, it is hard to know how much the candidate truly understands and how much was simply generated by AI and made to run somehow.

So if an interview still stays at "Do you know this syntax?" or "Can you write this function right now?", it may miss the more important part.

What I would rather look at is whether the candidate can keep things under control while working with AI.

For example:

• How were the requirements broken down?
• How were the module boundaries decided?
• Where does the data come from, and where does it go?
• How does state change?
• How are errors handled?
• Which parts are given to AI, and which parts must be judged by the person?
• How do they check whether AI-generated code has gone off track?

These questions are closer to real work than simply asking whether someone can write a piece of code.

First, look at how they collaborate with AI

If I were interviewing engineers in the future, I might begin with a very ordinary question:

How do you usually use AI in development? Can you explain your process?

It sounds simple, but it can reveal a lot.

If the answer is only:

• I ask AI to write code.
• I ask AI to fix bugs.
• I ask AI to generate comments.
• I ask AI to write tests.

then the person may be using AI mainly as a faster code generator.

That has value, but it is not enough. People who have really worked with AI for a while usually speak more concretely:

• They ask AI to help clarify requirements, but they confirm the boundaries themselves.
• They define interfaces and data structures first, then ask AI to fill in the implementation.
• For complex flows, they organize the state transitions before generating code.
• They limit the scope of each AI change.
• They ask AI to write tests, but they check whether the tests cover the important risks.
• When something breaks, they do not only ask AI to guess the bug; they make it trace the call path.
• After the code runs, they review naming, structure, and documentation.

These details show that the person is not waiting for AI to perform magic. They are putting AI inside an engineering process.

AI collaboration may become an important engineering ability.

It is not about writing clever prompts. It is about turning a vague requirement into something verifiable, explainable, and maintainable.

Second, see whether they can explain the system

Another question I think is very effective is:

Please run a system you built and explain it.

This is more direct than reading a resume, looking at a small code sample, or asking isolated knowledge questions.

Whether someone truly understands a system becomes much clearer once they explain it.

They should be able to explain things like:

• Why the modules are split this way.
• Why this state exists here.
• Which entry point the data comes from.
• Where the database is written.
• Which parts are read-only.
• How error paths flow.
• Whether the system can recover after failure.
• What tradeoffs this design made.

The answers do not need to be beautiful, but they should have cause and effect.

If someone really built, ran, debugged, and struggled with a system, their explanation usually becomes concrete. They know which parts are awkward, which parts are fragile, and which parts they may want to refactor later.

On the other hand, if they only let AI generate a lot of code without really absorbing it, the explanation tends to scatter.

The issue is not forgetting the name of an API. The issue is being unable to explain the chain from entry point to outcome.

Interviews can become two actions

So I think engineering interviews in the AI era can include at least two actions.

The first is to ask about the AI collaboration process:

How do you place AI inside your development process?

What matters here is not how many tool names they can mention. It is how they break down requirements, limit scope, verify results, and recover when AI goes off track.

The second is to ask them to run and explain a system:

Open something you built, and explain it from the entry point to where the data lands.

What matters here is not how polished the interface looks or how much code exists. It is whether the person can explain the structure, boundaries, state, and risks of the system.

Together, these two actions can reveal a lot:

• Are they only asking AI to output code?
• Do they have their own judgment?
• Can they control complexity?
• Can they explain what they delivered?
• Do they know which parts cannot be fully delegated to AI?

Is writing code still important?

I do not think writing code becomes unimportant.

Foundation still matters. If someone does not understand code at all, it is hard for them to judge whether AI output has problems. It is also hard to protect boundaries once the system becomes complicated.

But "being able to write code" may no longer be the only center.

In the past, an engineer's value was more strongly expressed by writing code with their own hands. In the future, it may be expressed more in things like:

• Breaking requirements into small pieces that AI can handle.
• Bringing AI output back into the system and checking it.
• Finding boundaries AI did not notice.
• Taking responsibility for the final result.
• Stopping complexity before it grows too far.

In other words, engineers are still engineers. The tool in their hands has changed.

AI can write a lot of code, but it cannot take responsibility for the consequences of a system. Whether the system runs steadily, whether the boundaries are clear, and whether problems can be explained are still human responsibilities.

Closing

If we only look at "writing code," AI does make many traditional interview questions less distinctive.

But if we look at "being able to explain a system," the differences between engineers may become even clearer.

AI can help generate implementation, but it is difficult for AI to replace a person's real system understanding.

So future engineering interviews may not only ask:

Can you write this code?

They may also need to ask:

How did you involve AI?

And:

Why is this system built this way?

This is only a personal observation and record. I am not trying to define a new interview standard. I just feel that, as the AI era arrives, the place where we should look at engineers may be slowly moving.