Tech Interviews in China, circa 2022

2023/02/26

I recently moved to China with my family and went through the process of looking for a new job in an unfamiliar and highly competitive market. I invested a significant amount of effort and time into the interviews, which made for an interesting experience. In this post, I’ll write about how I prepared for the interviews, the experience itself, and some thoughts around the process.

Quirks of Tech Interviews in China

Interview Format and Content

Tech interviews in China have a lot in common with their US counterparts, but also many quirks. One example is what I’d call “acquired knowledge” questions, or pop quizzes. Topics range from programming language mechanics, to computer science fundamentals, to details of widely used production systems. For example, according to online forums, questions around Java’s implementation of hash maps, TCP 3-way handshake, Redis data structures, MySQL locking rules are fairly popular.

Another difference is that interviewers probe into past project experiences at length. Interviews usually start with a self introduction, and then we’d start talking about past projects. Although this also happens in US interviews, they are not done to nearly the same extent. Sometimes an entire interview would be spent talking about project experiences and going into technical details about them. I imagine this is useful to assess the technical depth of candidates and filter out candidates that exaggerate their involvement in projects on their resume. On the flip side, a lot of professional experiences can be confidential, so candidates may not be able to freely talk about their most impressive accomplishments.

After the technical sessions, there is usually an HR round. This consists of a senior HR employee asking the candidate behavioral questions, inquiring about the candidate’s expectations for the position, answering the candidate’s questions about the company, etc. I’d say this is more about finding red flags around culture fit than anything else. Compensation negotiation happens later. Culture fit rounds happen in the US too, but in my experience they are usually conducted by engineers.

There is an optional final round with a VP-level manager. This round tends to only happen for experienced hires. At this point in the process, the candidate is very likely to receive an offer, so I’d surmise this round is more about culture fit, up-leveling, selling the position to the candidate, etc. Frankly I didn’t always know what the interviewers were looking for in these interviews.

Interview Process

There are also many “administrative” differences during the interview process. Note I relied on head hunters a lot, so this may not be representative of all job seekers.

Both job seekers and employers use popular job-hunting apps a lot - I personally relied on 脉脉. Unlike the US, there isn’t a monopoly of such apps. Every app has its own niche. Some have the most comprehensive positions. Some specialize in foreign companies. Some have the best social features. Etc.

When it comes to learning more about positions and arranging for interviews, there is frequently a headhunter serving as the intermediary between me and the company’s HR contact. Communication was primarily handled via WeChat and phone calls, including interview scheduling. Emails are only sent as a formal invitation after verbal confirmation via other channels. I appreciated the extra person in the loop to keep me updated on the job market and help me negotiate offers. On the flip side, occasionally the extra person can be a hurdle to communication if they are not on top of everything. The amount of headhunters offering the same position to you can also be an annoyance.

Interviews are scheduled one at a time, unlike in the US where you are typically brought on site for 3-4 consecutive interviews after 1-2 initial phone screens. This prolongs the interview process quite a lot. To make matters worse, there was a pandemic outbreak in China when I interviewed, and I was also based in the US so interviews had to be conducted at early morning or night time. The overall process took more than two months at some of the companies I interviewed for.

There tends to be a lot of rigidity in choosing candidates with the exact right set of job-related skills. Candidates would be categorized into “C++ developers”, “Java developers”, “database developers”, etc and then matched to available positions through resume screening. The categories are not mutually exclusive, but the implication is that without experience using the exact technology stack an employer uses, you resume is unlikely to get picked. Furthermore, even some of the technical interviewers also preferred candidates with relevant experience in very specific technologies. This may be an indication that the market favors employers siginificantly, because candidates fitting any specific profile can be found cost-effectively.

Lastly, a lot of companies expect employees to work extra hours. Some companies would write requirements like “must thrive under stress and persevere through difficulties” in their job description, which is basically code for 996. I found this to be a little funny (and sad), and also a direct reflection of the cultural differences between the job markets. My impression is that US tech employers are generally allergic to “stress” and would prefer to keep you far away from it.

Preparation

I had around 1.5 months of semi-free time to prepare for the interviews. I divided the preparation into 3 broad categories: LeetCode-style coding, acquired knowledge, system design.

Coding Questions

For coding rounds, I completed 2-3 LeetCode questions a day for a month, mostly following one of the “LeetCode 75” lists which are nicely organized by topic. I also tried out some LeetCode virtual contests, where you are asked to complete 4 questions in 1.5 hours. The time limit was difficult to beat, and apparently there was rampant cheating, and by December it seemed ChatGPT would undermine the competitive aspect of it. So, I’d only recommend doing the virtual contests at your own pace.

For better or worse, I found that practicing LeetCode is still the single most useful thing one can do to improve their chances at an offer. Below are some useful things I’d forgotten about and re-learned during this exercise:

If you find LeetCode boring, trying the problems in a new programming language can be more fun. I did some of them in Rust to keep things interesting.

Acquired Knowledge

While the idea of acquired knowledge questions in interviews was initially off-putting, the experience of preparing for them was frankly quite enjoyable. I got to learn about some popular systems that I never had a chance to work with professionally. The way I did this was to compile a list of topics to review, and to treat each as a literature review exercise.

While reviewing, I discovered there had been rapid development in intermediate-level online learning materials for developers in the Chinese market, driven by commercial learning platforms like 极客时间 and 掘金. These platforms offer high-quality, in-depth courses on technical topics like programming languages and specific commercial systems. There is an emphasis on practice over theory, which I haven’t found to be true in similar platforms in the US. For example, a typical online course in the US on databases teach a lot of general database theory but does not focus on any particular system, while an equivalent online course in China talks about implementation details of MySQL, which I imagine will be more valuable on the job. Of course, both approaches have their pros and cons, but I’ve found intermediate-level learning materials for specific systems lacking on the English-speaking Internet.

I’ll enumerate the topics I reviewed below. Note my interests are mostly in networking and databases, so there is a bias toward these topics.

I also made (digital) flash cards with known interview questions with the help of NeuraCache. Ultimately they didn’t prove too useful, but I didn’t mind the spaced repetition exercise. Relatedly, I highly recommend memorizing “latency numbers every programmer should know” with this type of exercise, which has been useful for me in day-to-day work.

System Design

To prepare for system design rounds, I read the System Design Interview book, watched some YouTube system design videos, reviewed Designing Data-Intensive Applications, and read some whitepapers from Amazon Builders’ library.

This is a popular interview format for experienced engineers in the US, but it seems less popular in China, so I didn’t end up spending too much time here. That said, I’d happily vote for this format over talking about past project experiences or acquired knowledge questions. If there were more time, I’d probably read the Google SRE book and the second volume of Alex Xu’s System Design Interview book, too.

Interviewing

The actual interview experience only matched some of my expectations during the preparation phase. Here is how that went.

Coding Questions

This part of the preparation paid off the most. I had to complete a coding question in virtually every interview session. Even for interviews with lots of project experience / acquired knowledge questions, the interviewer would still ask a coding question. They’d either prolong the interview so you can finish coding or simply expect you to finish it in less time. There was one employer that only asked me to describe an algorithm for the question given, instead of writing down the code.

Employers asked questions of widely varying difficulty. This is mostly a function of what type of candidates companies like to hire. I’d estimate the majority asked LeetCode mediums - including the equivalent of FAANGs in China. There were some cases where I was almost sure the interviewer deliberately chose an easier problem and wanted me to pass. In contrast, some employers like to ask hard coding questions, and they tend to get a reputation among headhunters / recruiters. I got the impression that these companies end up with candidates with some experience in programming contests. Also, the companies that ask hard coding questions tend to put a lot of emphasis on these rounds, and less weight on projects / acquired knowledge, etc.

In the distant past, I also participated in programming contests, so I’m not opposed to this style of interviews. I will say that I’ve never found the competitive aspect of it appealing. The problem solving aspect can be fun and occasionally useful on the job.

Acquired Knowledge

I was a little disappointed that the majority of my preparation in this category went to waste. I interviewed for infrastructure-related roles - primarily in networking and occasionally databases. Interviewers generally only asked questions in their domain: a database person would not ask you about the details of TCP, a networking person would not ask you about transactions, etc. Nobody even mentioned Redis or Kafka to me. This situation might vary as you go up the stack, as someone building the backend of a complex website may be expected to know, at some level of detail, all of the underlying building blocks.

I did get asked about networking and C++ relatively frequently, because these were areas where the interviewer and I shared some experience. However, if the interviewer comes in with a preconceived set of questions, it’s likely I won’t be able to answer all of them. The aforementioned preparations tend to be sufficient for me to answer the first step of some question, but falls short when followed up with a deeper one. The conversation tends to develop better if they ask about what I’ve worked on and dig into the details, but this requires that the interviewer participates in the conversation more actively.

A couple companies liked to pop-quiz candidates on C++. One perhaps interesting observation is that day-to-day coding and reading things like Effective C++ does not prepare you for these types of questions, because they probe candidates about rarely used combinations of language features, some of which are against the best practices of modern C++.

The networking questions were, OTOH, more pleasant. One interviewer asked me about the mechanisms of TCP packet retransmission and congestion control. Another asked about how to speed up an HTTP server. I talked about network load balancing a lot, which led to some high-level questions about kernel bypass, and occasionally data center network architecture.

System Design

Perhaps also unexpectedly, out of all the companies I interviewed at, only two had a system design round, and these are either US companies or domestic ones with a lot of US influence. System design questions require a lot of engagement from the interviewer to supply requirements, answer ad-hoc questions, hint at missing considerations, probe into unexpected designs, etc. I found the back-and-forth conversation makes the interview experience a lot nicer.

Epilogue

The market in China is tough at the moment. Several companies had great feedback for me, but couldn’t finalize on an offer due to hiring slowdowns mid-way through the process. The vast majority of companies required working overtime to some extent, including some US-based companies operating in China. Compensation varied greatly, ranging from roughly 35% to 75% of my US income. I ended up picking a company with a good culture and work-life balance. I won’t disclose the specifics here, but it’s not difficult to look up if you’re interested.

I hope my experience will be useful to others in a similar boat or are just curious about the market in China. Feel free to reach out if you’d like to know more.