钛媒体APP

wrote a column ·

Programmers have been reciting rigid interview scripts for a decade—now DeepSeek has rendered them obsolete

(This article was authored by Alphabet AI and published by TMT Post with permission.)

By Alphabet AI

After Li Bojie claimed that a DeepSeek interviewer accused him of cheating while writing code, many programmers took to online forums stating they had undergone two extremely rigorous coding interviews when applying to DeepSeek.

A video blogger who identifies himself as a former Alibaba technical expert, with the handle 'Jun Ge Programmer,' posted a video stating that DeepSeek indeed conducts two rounds of coding interviews and added that DeepSeek interviewers focus almost exclusively on coding-related questions throughout, with standard interviews lasting as long as 70 minutes.

For over a decade, programmer interviews have evolved into a well-established test-taking playbook: memorizing questions, practicing problem sets, and sharing interview experiences—a full-service pipeline ranging from cheap PDFs priced at just a few dollars to premium 'guaranteed-pass internal referral' packages costing tens of thousands. With enough preparation time, landing a job at a major tech firm wasn’t unlikely.

But DeepSeek’s interview process has completely dismantled all these tactics.

They don’t ask what you’ve memorized, and they don’t test you on the problems you’ve practiced. The questions they pose are ones you simply can’t answer unless you’ve actually tackled real-world coding challenges online.

This reveals one clear principle: DeepSeek adheres to 'code is justice.'

Jun Ge Programmer noted that the interviewer turned on their camera, got straight to the point, allowed only a 30- to 40-second self-introduction, and immediately began grilling him with follow-up questions about the projects listed on his resume.

DeepSeek’s interviewers asked Jun Ge Programmer numerous questions—each one precisely the kind that only developers with frontline, real-world experience would have encountered.

I’ll pick a few representative questions and break down DeepSeek’s hiring approach for you.

"Do you use a message window or a token window for conversation memory, and why did you choose this approach in production?"

Large language models themselves have no memory—you could chat with it for twenty rounds, and it won’t automatically remember what was said in the first round. To make it 'remember' prior conversation history, you need to feed the historical messages back into it.

A message window stores the most recent N messages by count and feeds all of them back; a token window stores content based on token length, preserving everything within a specified token limit and truncating anything beyond that.

It sounds simple, but which one you choose in production depends on your specific use case. If you’re building a customer service chatbot where conversations involve many short turns, a message window is sufficient. However, if you're analyzing long documents or entire codebases, each turn can be extremely lengthy, making a token window more effective.

There’s no single correct answer to this question—the interviewer wants to hear your reasoning behind your choice and what would happen if you made the wrong one.

"How do you define session expiration policies when persisting data in Redis?"

User conversations with the AI are stored in Redis, but Redis costs money—so capacity is limited, and you can’t store sessions indefinitely. How long should they last? Should inactive sessions be cleared after half an hour of silence, or retained for seven days? What if a user returns unexpectedly and finds their previous conversation gone—how does that affect user experience? These are real-world production issues you never consider when writing a demo.

This question has a well-known anecdote behind it. There’s a famously humorous story in programmer circles about a developer or sysadmin who added a cron job to periodically clean up disk space by clearing logs every month on the 30th at midnight.

But February doesn’t have a 30th, so the logs weren’t cleaned that month—and then one day in March, the disk filled up completely due to excessive log accumulation.

"Have you ever encountered concurrent session conflicts?"

This is also a very common scenario. You’re halfway through a conversation with DeepSeek on your mobile app, then you get to the office and continue chatting on the web version of DeepSeek using your computer.

Both devices are logged into the same account and sending messages into the same conversation thread. On your phone, you’ve just sent 'Help me revise this piece of code,' while your computer is already reading the previous conversation history.

Since both sides are writing session states to Redis, could they overwrite each other? Will the message you last sent from your phone be visible on the computer? If a user sends messages simultaneously from both ends, how do you reconcile the context? Could dirty reads occur?

"Long-term memory is stored in a vector database. As memories accumulate, retrieval becomes less precise—how do you optimize this?"

This is one of the most technically demanding questions. A vector database stores text converted into numerical embeddings and retrieves the most relevant memories based on mathematical similarity. When you first launch it with a few thousand memories, retrieval is highly accurate. But once you accumulate hundreds of thousands of entries, noisy or irrelevant memories start interfering, and the truly relevant one might end up buried far down the results list.

This is a problem frequently encountered by DeepSeek’s top-paying users. Two weeks ago, you told it, 'I work in Java, mainly on payment systems.' Today, you ask, 'Help me write a retry mechanism.'

Ideally, DeepSeek should remember that you’re a Java developer and generate code in Java for you.

But if you’ve had hundreds of rounds of conversation with it—discussing everything from daily life to Python—when you next ask DeepSeek for code, it’s quite likely to output Python instead.

Notice the pattern? All these issues share one common characteristic:They all come from real-world production experience—none can pass by simply reciting answers.

Programmer Jun recalled that during an interview, the interviewer asked him about a specific point regarding troubleshooting a production issue. His answer was vague, prompting the interviewer to follow up with three consecutive questions, drilling down until he specified exactly which logic was changed and by what percentage performance improved.

Programmer Jun stated that if you’ve only built a demo using LangChain and haven’t navigated the pitfalls of live production projects, you 'absolutely won’t last more than twenty minutes.'

In his video, Programmer Jun mentioned an incident, saying that ‘eight-part essays’ are completely useless.

What is an ‘eight-part essay’?

The ‘eight-part essay’ originally referred to a rigid literary format used in imperial civil service exams during the Ming and Qing dynasties. It consisted of eight prescribed sections, followed a fixed structure, and drew topics exclusively from the Four Books and Five Classics. Original thought wasn’t required—success depended solely on conforming to the correct format.

In the past, programmer interviews relied heavily on rote memorization of standard questions, which is why the industry jokingly refers to interview prep as studying ‘eight-part essays.’

Examples include how HashMap works, the JVM memory model, and the differences between synchronized and volatile. As these questions appeared repeatedly, some people compiled them into collections known as ‘Programmer Interview Bibles,’ which hold a status in tech circles comparable to graduate entrance exam prediction guides.

A search online for ‘Java interview eight-part essays’ yields thousands of articles uniformly labeled ‘Must-know for big tech interviews’ or ‘Memorize this and land your offer.’ Platforms like Nowcoder and CSDN even feature dedicated ‘Emergency Eight-Part Essay Memorization’ columns, ranked by company popularity and highlighting which questions are most likely to appear in big tech interviews.

Some coding bootcamps not only train students to improve their programming skills but also offer specialized courses on interview techniques. On major Chinese social media platforms, accounts posing as software engineers frequently sell various interview guides.

An interview lasts only an hour, so the interviewer needs to quickly assess a candidate’s skill level. The easiest way is to ask questions with standard answers. If you can recite them, it shows you’ve prepared—and if you’ve prepared, it shows you care. Whether you can actually do the job well is something they’ll figure out after you’re hired.

This has created an unspoken industry chain: some people compile standardized interview answers (‘dogma’), others memorize them, and interviewers know full well that candidates are just reciting them.

Even more surreal is the practice of 'interview experience sharing'—candidates post interview questions online after their interviews, allowing future applicants to memorize the answers in advance for the same role, resulting in everyone giving identical responses to the same set of questions.

Insiders call this phenomenon 'building rockets in interviews, tightening screws on the job.'

Against this backdrop, Jun Ge’s description of DeepSeek’s interview process clearly stands out as remarkably different.

Another unwritten rule in the programming community is that only junior developers are asked to write code during interviews.

Any programmer, regardless of their academic GPA, can only do one thing when first entering the industry: plug ready-made code into existing frameworks.

However, once you’ve accumulated enough experience, you’ll start understanding the underlying implementation logic and be able to modify or optimize the code yourself when facing real business challenges.

Later in your career, your focus shifts toward higher-level concerns such as overall system architecture, concurrency handling, and debugging production issues.

The more senior the talent, the less likely they are to be interviewed on coding.

DeepSeek doesn’t see it that way—regardless of whether you’re a fresh graduate or a ‘Genius Youth’ from Huawei, the first two interview rounds are purely coding-focused.

This is what we call 'code is justice.'

The benefits of this approach are straightforward.

First, the screening mechanism is extremely fair. You either can write the code or you can’t—there’s no way to get through by polishing your resume. Especially for programmers who aren’t strong in social skills, this actually becomes the most welcoming hiring method: all you need to do is write good code; nothing else matters.

Second, the team’s baseline skill level is high. Passing the coding bar means everyone who joins operates above a certain competence threshold. Code reviews don’t require teaching basics, and technical discussions don’t need concept translation—you won’t run into absurd situations where a ‘senior engineer’ writes worse code than an intern.

However, DeepSeek itself fully understands that coding isn’t everything about a person. It simply places coding upfront—as a ticket to entry.

According to Jun Ge, a programmer, the third interview round doesn’t involve any coding or technical discussion at all—it’s entirely focused on judgment and perspective. For example: What’s your view on the Agent space? What’s its biggest bottleneck? If you were to build a product line from scratch, what would be your first step?

This once again proves that DeepSeek has been through the trenches and understands what the market environment is really like. So regardless of your background or seniority, you still need to know how to code.

Major tech companies have vastly different attitudes toward hiring.

Let’s start with ByteDance.

The standard interview process for AI algorithm roles at ByteDance consists of a written coding test, followed by three technical rounds and one HR round—five rounds in total.

The written test includes three LeetCode Medium-level problems. The first technical interview immediately dives into live coding, demanding both speed and code cleanliness—if you fail the coding task, you’re rejected outright. This round also deeply probes your project experience and includes one or two algorithm questions.

Starting from the second round, they ask about model architectures—for example, decoder-only structures, SFT/RLHF/DPO training paradigms, and the principles behind LoRA. They’ll drill down into mathematical fundamentals: if you mention RoPE (Rotary Position Embedding), the interviewer will keep pressing you until you derive the rotation matrix from first principles.

The third round is a cross-functional interview focusing on engineering systems—topics include DeepSpeed ZeRO’s parallelization strategies, the differences between DP and DDP, and estimating hardware utilization in multi-GPU training.

If you examine ByteDance’s interview questions closely, you’ll notice a key pattern: they’re all preparable in advance.

These knowledge points are fixed, with standard answers available online—you can memorize them and answer successfully. Even the engineering system questions in ByteDance’s third cross-functional round are essentially ‘advanced boilerplate’ in the large-model domain; anyone who’s reviewed Niuke interview experiences knows this well.

With ByteDance’s questions, if you spend three months grinding LeetCode and memorizing interview reports, you might just scrape through—the answers are standardized, and with enough practice, you’re bound to encounter repeat questions. As the saying goes, ‘Read a book a hundred times, and its meaning reveals itself.’

But with DeepSeek’s questions, if you haven’t worked on live production projects, you simply won’t be able to answer. You can’t prepare in advance for questions like ‘Which part of the logic did you change during your online incident troubleshooting, and by what percentage did performance improve?’ because those are based on your own firsthand experience—you can’t memorize someone else’s story.

Here’s an analogy: ByteDance is like taking a driver’s license exam—there’s Theory Test, Field Test, and Road Test, each with standardized procedures; once you’ve practiced enough, you pass. DeepSeek, on the other hand, tests how you handle real-world driving scenarios like being cut off, a blowout, or a rear-end collision.

Now let’s talk about Tencent.

Tencent’s AI algorithm role hiring process also includes a written test, followed by three rounds of technical interviews and an HR interview, with core positions adding a final interview with a director—up to five rounds in total. However, Tencent’s approach is completely different from ByteDance’s.

Tencent’s most distinctive feature is its hierarchical progression.

The first-round interviewer is typically a peer from the same team, assessing your understanding of foundational models—for example, BERT, LoRA, positional encoding—and includes one straightforward coding question.

The second-round interviewer is your prospective direct manager, who starts discussing low-level optimization and project alignment—for instance, fine-tuning experience, DeepSpeed, incremental pre-training, and integration with business use cases.

The third-round interviewer is your skip-level manager, evaluating system design capabilities and long-term potential. The HR interview focuses on values and career motivation. If there’s a final director-level interview, it centers on strategic thinking and long-term fit.

At Tencent, interviewers’ seniority increases with each round, and the evaluation criteria gradually shift from 'Can you do the job?' to 'Do you have potential?'

Among the three companies, coding carries the least weight at Tencent; for senior roles, both the difficulty and proportion of algorithm questions drop significantly.

The three companies have different hiring philosophies, each with its own strengths, and it would be overly simplistic to summarize their performance with a statement like, 'You review less code, so your development hasn't been good.' However, if you enjoy the entire process of programming and AI, DeepSeek is indeed a solid choice.

365 Views