HR chatted with me first and explained the process: roughly three technical rounds, and at the end an HRBP round for behavioral questions.
The first video round was coding. A few pleasantries, then 10 minutes of the standard memorized-theory questions, then coding: 146 and 460. They didn't make me run it.
I passed, and they scheduled the other two video rounds, one with the technical lead and one with the lead of a sibling team. The technical lead dug into my resume and asked what your team does, why you need so many people, and to give an example showing why you need that many people... After I talked for ages he felt your team's business was simple. He couldn't see the complexity. (After all that rambling, what I actually wanted to say was that we care more about work-life balance, different teams split the work differently, and you work one hour a day and spend the rest scrolling Douyin.) Then he asked about Kafka: under concurrency, how do you guarantee idempotency? After I gave my approach, he asked what happens if another message is being processed, writes to the database, and finds the data already exists. I said it would throw a duplication exception. The interviewer said that doesn't sound right, shouldn't it return the existing data, why throw an exception? I said this is our backend business logic, and if we returned the data, it would get processed further downstream, which we don't need, so just throwing an exception is enough. He kept pushing: isn't that wrong, wouldn't the offset never move? I said if we throw a data-already-exists exception we just wrap it in a try/catch, then ack and commit the offset, so it doesn't stop the offset from moving. His understanding (or what he expected) was that when the same message is processed by multiple threads at once, they should all return the same result. But our architecture isn't like that. We don't need to return data to a client, we only need downstream processing to continue. If another thread has already processed the message and written to the database successfully, the remaining threads processing the same message detect the duplicate (at write time) and just throw an exception. Then he followed up: if there is also an async write to another database, how do you keep the two databases in sync? I said either put both database operations in one transaction, committing and rolling back together, or asynchronously send a message and continue processing later. He asked what if sending the message fails. I said if sending the message fails, the whole business logic fails and the message gets reprocessed (which is actually what we do). Then I added that we generally wouldn't have one write that must be strongly in sync done synchronously and the other handled asynchronously. And then it ended.
There was supposed to be one more coding round, but the interviewer said he had no time, so I guess they found someone. HR has also gone silent.
Overall my feeling is that interviewers at Chinese-owned companies are really cold. He had me introduce myself right off the bat, and he didn't introduce himself at all. They do emphasize simple, efficient communication, but it also shows an excessive obsession with being correct, especially with open-ended questions in an interview. It reminded me of that chilling feeling of being blamed at work when you don't meet a perfect expectation.
Discussion
Loading comments…