I went into internship season with a comfortable story about myself: a good school, a big-name internship, and two years of supposed improvement. I assumed an internship would be easy to get. Then I ran into wall after wall.
The lesson was not subtle. My biggest mistake was starting with too much confidence and too little preparation. Compared with what most companies were asking, my knowledge had serious holes. I needed to face that and fill them.
Results
- NetEase Games, R&D engineer: one HR phone screen, two technical rounds, rejected.
- Tencent, Weibo R&D engineer: one written test, one technical round, rejected.
- Baidu, crawler R&D engineer: two technical rounds, rejected.
- Baidu, Infrastructure Department, R&D engineer: two technical rounds, offer.
- Maxthon, browser kernel R&D engineer: two technical rounds, one HR round, offer.
- Amazon, SDE: one HR phone screen, two technical rounds, offer.
- Sohu and Sogou, R&D engineer: passed the written test, then did not bother going to interviews.
- Renren, data mining engineer: three and a half rounds, offer.
Before getting into the stories, here is the useful part.
Preparing for the search
Where the leads came from
In Beijing, the fresh-graduate board on the BBS was enough for most of what I needed. The aggregated posts across the BBS were especially useful because many were referral opportunities. They were more reliable and faster than the big company publicity campaigns. After dinner I would go through everything new that day and apply to whatever looked interesting. If my resume got through, I usually heard about an interview within two days.
Reviewing
The usual version of this section is a long book list. I will only recommend books I actually read. Recommending a pile of books I have never opened feels dishonest.
Computer Systems: A Programmer's Perspective
This is the book people describe as worth its weight in gold. Most of what I know about operating systems came from it, and it touches many areas of computer science at just the right depth for written tests and interviews. It is a big book. If you have not read it yet, start now. You will not regret it.
Introduction to Algorithms
Recommending this one feels a little dishonest, because my impression of it is not that good. It is too academic and often hard to understand. I am not sure why it has been put on such a pedestal. My advice is to use it as an algorithm dictionary: read the ideas, do not force yourself through every proof and derivation. The advantage is that when you read interview notes, most algorithm names will at least look familiar.
Introduction to Algorithms: A Creative Approach
This was an unexpected good book. Unlike most algorithm books, it is not a dictionary. It teaches a general method for designing algorithms from scratch, mainly through induction. After reading it, dynamic programming problems felt almost easy, and other problems at least had a workable direction. I had never done algorithm competitions, and before this book LeetCode was painful. After it, a few problems felt boring. If your algorithm foundation is weak, read it carefully.
LeetCode OJ
Many strong people have already recommended it. It is a place to practice writing code, the problems are representative, and each one gives test cases so you can see where you went wrong. I suggest going through Introduction to Algorithms: A Creative Approach first. LeetCode will be much easier afterward.
My background
No competition experience. No papers. I had done testing at Baidu, which turned out to be something nobody cared about. I had built a browser project, which most companies either did not care about or could not understand. Maxthon was the exception. I also had a blog. It helped, but it also dug a pit for me, as I will explain later. My interests were broad, and several interviewers acknowledged that. I could respond to almost any topic for a sentence or two, but I had no specialty that could survive three follow-up questions.
The interviews
NetEase Games
NetEase Games was demanding. In Beijing it recruited only from Peking University and Tsinghua, and the job was in Hangzhou or Guangzhou. The first phone screen asked a few personality questions, then I was called to a hotel for interviews. First there was a data-structure programming problem. Nobody should have failed it. After that, neither technical round asked me to write code again.
They asked a lot about C++ implementation details: iterators, references, dynamic_cast. Those are not things you learn from a C++ syntax book. I thought the focus was too obscure. There were also standard questions such as the difference between threads and processes, and between TCP and UDP. The algorithm questions only required ideas, not code. Unfortunately, I had not read Introduction to Algorithms: A Creative Approach yet, so I only knew how to use binary search. I bluffed my way through with binary search. One problem could have been solved easily with induction, I realize now.
My project was mostly beyond them, so they kept asking about my blog. Some posts were so old that I could not remember the details. There were also Python questions, which turned out to be a trap. Overall, NetEase Games felt full of traps: small corners, odd questions, things designed to make you fall. I probably fell into one.
What helped: C++ Primer and Inside the C++ Object Model. NetEase Games expected a surprisingly high level of C++. I thought the first book would cover every C++ question, but after the interview I had to dig out the second. It explains C++ memory layout and implementation, but there is no fixed standard, different compilers differ, and the book has its own problems. Do experiments while reading and verify what it says.
The pay was strong: an internship could pay 10k RMB a month. Naturally, the requirements were higher too. Games are a broad field, and there is a shortage of technical people, so you can learn rare things there. But making games did not fit my values. I felt uncomfortable thinking about it. The social value of games is hard to judge, and the direction games push people is hard to control. Still, the pay was tempting, and the city was one I liked.
Tencent
I really wanted Tencent at first. I imagined collecting internships at the three big internet companies and summoning the dragon. In the end I lost early because of my own temper.
The written test was basic. I heard it was similar to the previous year's, but I had not looked at that one. The early questions were easy. Later there was a compilation and linking question; I did not understand the idea of preprocessing. There was a TCP connection-state question, and I had forgotten all the states. There was also an encryption question I was not clear about. For the bonus questions, the first algorithm probably needed divide and conquer, and the second tested something about DHT. The scope was broad but nothing was especially hard.
During the interview, something went wrong and I was made to wait more than an hour. I lost my temper and blew up at the interviewer. I criticized the opening questions as low quality. The consequences were predictable. It was not that the Tencent interviewer lacked grace; I was just too petty.
The position was in Weibo. I felt that Tencent Weibo had many users but a lot of them were inflated, and it could no longer compete with Sina Weibo. On the other hand, Tencent had WeChat as its mobile internet ticket, so its attention to Weibo might decline. Weibo's future position looked awkward. If I could have gone to WeChat, there might have been many opportunities.
Baidu
I still have affection for Baidu. I spent a decent amount of time there. The process was as efficient as ever: I sent my resume on day one, got a confirmation call on day two, and interviewed on day three.
Because I had written that I knew Python and my blog contained regular expressions, I was asked a lookaround regex question. Knowing regex is a double-edged sword: they ask advanced matching right away. I wrote an algorithm as usual, then answered some Python questions. My brain short-circuited and I wrote an extremely simple program in a bizarre way.
After that, the interviewer introduced the department. It felt like crawling pages that other people did not want crawled, which was not very ethical, but there were still many challenges. The second interviewer spent more than half an hour discussing how to design a crawler system. One moment it was Weibo, then forums, then blogs. I barely held on with some search-engine knowledge I still remembered. Then came a pile of anti-cheat questions, many open-ended, and I could not handle them. Baidu has a consistent style: keep asking until you do not know the answer. Finally I wrote a transpose algorithm for a linked list or array, and it ended. Maybe my background did not match. Although I thought I did okay, I was rejected.
What helped: Search Engines: Information Retrieval in Practice. It is the only search-engine book I have read, and it explains the principles and ideas clearly. If you are interested, look for material specifically on crawler design. I also remember Google published a series of methods for anti-spam and link farms; search for how those anti-cheat methods work.
In recent years Baidu seems to have slipped from its leading position among the three big internet companies. Tencent used WeChat to revolutionize itself and got its mobile internet ticket. Alibaba transformed into a platform, accumulated a lot of technical depth, and its financial business matured. Baidu has had fewer revolutionary products, and its prospects have dimmed. I believe it will not decline forever and will produce something breakthrough. Also, Baidu Research seems to be working on fashionable deep learning, which should produce high-quality work.
Maxthon
Before Chrome appeared, I used Maxthon, so I had some attachment to it. After all the rejections, I had become more humble. If Maxthon had been my first interview, I probably would have gone without preparing.
There was an algorithm problem, though it barely counted as an algorithm: a program with many lines, just to check coding ability. Then my browser project finally became useful. For the first time, a company understood it. For the first time, what I said got a reaction. After that we wandered across many topics. My resume mentioned compilers, and someone finally asked about them, though I could not remember much. We talked about functional programming, problems with mainstream browsers, and the Dart language I had heard about at a GDG meetup. We covered a lot of technical ground. Fortunately, my knowledge net was wide enough to catch one or two sentences and introduce a fresh topic.
Probably few people had a project that matched so well, and the conversation was enjoyable. Maxthon became the first offer I received.
Browser technology is relatively niche. I have not seen many books on it. I recently found two good articles: How Browsers Work and an introduction to browser rendering principles by Zuo'er Haozi. For deeper material, you probably have to debug code yourself; you can look at my VS2008 build of QtWebKit.
Maxthon has prospects. When the EU sanctioned IE for unfair competition, Maxthon was among the browser choices offered. In China it is a company that genuinely studies browsers, and according to HR it has many revenue paths. The problem may be that the field is too specialized and the technical barrier is high. A new person cannot get up to speed without one or two months of learning. If you are devoted to browsers, I would recommend Maxthon.
Amazon
I applied to Amazon mostly on a whim. In North America it is also a hard company to enter. The phone interview asked me to introduce my project in English. I stumbled through a few stiff sentences and somehow passed. Because they knew I was going to discuss an offer with Maxthon on the third day, they scheduled my interview for the next day.
The office was incredibly far away. By the time I got there I was exhausted. Both interviewers were mature types, completely different in style from the people at the previous companies. My browser project came up again, and this time the interviewers were actually interested and asked follow-up questions.
The algorithm problems were well suited to induction. One dynamic programming problem was easy. For another, I used induction for a while, proposed a mathematical solution, and proved it with induction on the spot. In the end, with the interviewer's hint, I found a more intuitive method.
After that I do not remember much. I know we discussed Kindle, why Java IDEs had not moved to IDEA, and some gossip about Chen Hao. We also debated whether software engineering is too abstract. Overall, these were the most gracious interviewers I met. They encouraged and guided me, and at least I felt relaxed and comfortable during the interview.
At Amazon I would have to use Java and Ruby, neither of which I had used much. Fortunately, I no longer had the language religion I had a few years earlier. Apart from thinking Kindle was useful and knowing Chen Hao had worked at Amazon, I did not know much about the company. I hoped to learn things I did not know before.
What helped: practice spoken English. Mine was terrible.
Renren
I applied to Renren data mining because I had been following machine learning and had become interested in data analysis. It turned out that companies really value research background when hiring interns. In the first two rounds, the interviewers saw that I had no data-mining background and went straight to algorithms. I wrote until I was dizzy. Most were problems I had seen on LeetCode, so it was fine. Only one interviewer briefly asked how to write Hadoop MapReduce, and even then only the basics: inverted index and word count.
In the third round, the interviewer talked for a bit and then suddenly asked whether I preferred typing commands on the backend or building systems on the frontend. It was a hint that without a background I should not join their department. I said fine, I like building systems, and thought I would leave quickly. Then he found someone who did frontend systems to interview me. That person was clearly just handling it casually, asked a few very simple questions, and that was it. Somehow I still passed.
Since I had never done data mining, I have no specific book recommendations. But Coursera's machine learning course is genuinely good; take a look if you are interested. The research on that side dealt with sad things: why users churn, under what conditions churned users come back. It sounded depressing. Renren is still a student social network, and it has many problems breaking into the white-collar world.
For anyone who read this far, one more article I liked recently: ABC: Always Be Coding. The translation is here. In short: read, practice, think.