记一次找工作Notes from a Job Hunt

I spent two weeks switching jobs, so here I am writing down some of the experience and reflections accumulated along the way. It can’t really claim to be a universal summary; call it a little sharing of one person’s experience. In two parts:

1. Preparation

2. Interviews and everything else

3. Preparation: leaving a hole here for now, and writing up the interviews first, since those are easiest to forget

4. Interviews. The first company I interviewed with was Jinri Toutiao.

The first round at Toutiao was fairly standard: it basically started from whatever points on my resume interested the interviewer, then moved on to the problems, or say the expectations, you would meet within the responsibilities of the target role. This is quite a sound way to interview; both execution ability and methodology can be read off the candidate’s performance.

That said, since the recap of and questions about past experience come first, a well-prepared past experience can easily leave the interviewer with a good impression and color the judgments that follow. Back to the interview itself: since the role I was interviewing for leaned toward the recommendation logic for content users find interesting, there was a lot of testing on the logic side.

Summing it up now: if you insist on calling it technique, this whole broad class of questions can be answered by classification. The key is to work out one clear axis of classification, then classify along it, mutually exclusively, and you’re done. The second-round interviewer was Toutiao’s product director, every bit as nice as the first-round guy. Content-wise it was again some simple questions on my resume plus data assumptions in simulated scenarios. While I was walking back through my earlier data expectations, the interviewer kept changing the simulated environment and asking for the new data expectations. Excellent! Which also exposed how insufficiently sensitive I am to data. Personally I think, from the interviewer’s side, simulating a brand-new environment for the candidate to answer in, or simply letting the candidate expound on past projects, can both land you inside a circle the candidate has already drawn. Questions like these, grounded in the candidate’s existing projects but introducing variables those projects never had, are what truly test how strong someone’s methodology and execution are. Kudos again. That’s about it for the core content; next, my shortcomings in interview ‘presentation.’ For this part let me optimize the presentation of the post as well and just list the conclusions point by point.

• Get the interviewer’s key point first, then answer - you do need to know what they’re actually asking, right
• Put your line of thinking up front - ramble on and on and you’ll lose your own thread, and the interviewer may well get bored too
• Control the pacing of your presentation - don’t be long-winded, but don’t say too little either

That’s about it for Jinri Toutiao, and the next day I arrived at 360…------the 360 interview was originally for the search department, but by some twist of fate, the project experience the interviewer asked about was all monetization-related, and in answering I kept assuming the context was a monetization context, so I got transferred over to the Mobile Guard department and began a monetization-flavored… new round of interviews. Truth is, what you get asked has an enormous amount to do with your target role (well, obviously =。=); after all, both sides walk in with a purpose. The questions may all be grounded in your project experience, yet they can still differ a great deal. Back to 360: my interviews there consisted of one technical round and one HR round. Looking back, 360 is actually the one with the least to summarize; the technical round was simply questions about all kinds of data, plus a read on some basic product sense. I won’t expand on it here. The HR round asked rather more, touching on project experience, product outlook and so on; no technique to it either, I told it all straight and that was that. For readability let me do a summary anyway..

• No fudging your grasp of the data - for a project you ran yourself, you should at least know retention and conversion, and the data expectations set before the project began~
• Don’t lie - this one is pure padding.. honestly, in the HR round I did think about quoting the salary of the offer I already had a bit higher, but on reflection, it didn’t fit my values =。=

Then on day three I came to the oh-so-fancy Wangjing SOHO to interview at Momo----you could say Momo and I had a bit of fate between us. I had applied to Momo through an internal referral, and they had also seen my resume on Lagou. In the end, the reason they contacted me was, of all things, that an HR person took a liking to my resume on a job site and reached out.. And Wangjing SOHO really is fancy.. walking over, I felt exactly like a country bumpkin coming into the big city.. if I remember, I’ll add pictures later.. Moving on: Momo had the shortest wait; the interviewer appeared barely two minutes after I arrived. She was also one of the only two women interviewers in this whole round of job hunting. I’ve actually long wanted to work out whether there are broadly general differences between male and female PMs in methodology and product sense, and what they might be, but.. I’ve met too few women PMs, and at levels far too uneven. Back to business: Momo’s interview was completely different in style from the previous two. The entire interview left my resume behind. I can think of two reasons: for one thing, my project experience has nothing to do with social products, so asking about it wouldn’t effectively probe my understanding of and methodology for social; for another, what Momo does really is something almost nobody on the market has done, so testing in a hypothetical setting is actually more effective. As for the format, Momo’s interview basically opened with some routine questions, then watched as we talked, found the points the interviewer was interested in or the candidate kept bringing up, and expanded into discussion from there. Personally I think this beats starting purely from the resume: the candidate cannot prepare in advance as thoroughly as for project-experience questions, so individual ability shows through more distinctly. It also makes it easier to steer into the areas the interviewer cares about, the ones relevant to the target role. As for the interview itself, Momo’s was mostly a test of methodology, with relatively little inspection of concrete implementation and execution. A few days have passed and I’ve forgotten many of the questions, so here, in chronological order, are a few I still remember and answered pretty shabbily.

• What problems exist in the feeds of today’s SNS and IM apps?

My answer was that in feeds built from content people create, one problem is the lack of classification based on user behavior, e.g. if you’re close with so-and-so, surface his updates first, that kind of thing. This answer actually walked into a trap: on one hand it didn’t consider users’ real needs and scenarios, on the other it didn’t consider implementation cost. It also exposed the fact that I don’t use social apps much.. really, this problem is no problem at all.. for content created by people, letting users sort it by person themselves is the cheapest, simplest, most effective way, isn’t it?

• What are the ways a social app can monetize? Which one or several are the most efficient, and intrude least on user experience?

The approach is simply to first enumerate the monetization methods by category, then discuss them one by one. Explicit monetization woven into the product itself is necessarily the quickest, since it is shown directly to users. Implicit monetization tends not to have much to do with the product itself, e.g. the app distribution Momo now inserts into its feed of updates etc.

• When it comes to giving gifts, who is more careful: strangers, or people who know each other well?

This question laid bare my ignorance of human relationships. My take was that with strangers, well, if they don’t like the gift they don’t like it, whereas with people you know the effects linger, so you’d be more careful there. That I answered it this way clearly means I had lost sight of the purpose of gift-giving. The purpose of a gift is to advance a relationship, and from the advancement you hope for, you then choose the gift along the dimensions of money and type. Of course gift-giving between strangers is the more careful case.. I’ll add other questions as they come back to me.. This was the interview I gained the most from.. it flat-out opened the door to the world of social for me.. I’ll skip over the HR round and such; finally, thanks to Sister Na for the coffee (though she probably won’t even see this. Then on day four I arrived at the final stop, Meituan-----the first two Meituan rounds honestly had no particular highlights. Fairly routine. But both interviewers were interesting. The first-round uncle, you could tell at a glance, was kind and even-tempered, and obviously the type who takes his work supremely seriously. The intent behind his questions was fairly plain too: a few routine questions on product sense and execution method. Walking out, the feeling was ‘working with him would probably be a real pleasure.’ The second-round… sir, now, that felt a bit like a stress interview.. the questions came fast, and I couldn’t figure out what he was actually after with them.. I steadied my rhythm, and toward the end felt rather in the spirit of ‘be as strong as you like, the breeze still strokes the hillside,’ hahahaha… Maybe because it was day four of interviews, the first two rounds felt like nothing, as if the offer were mine for the taking. And so I came face to face with the final BOSS.. The big boss’s technique was actually the same school as Momo’s, expanding from things I myself had said. Since in round two I had mentioned loving to try out all kinds of apps, we started from apps. Then it cut to the target position, enterprise collaboration tools. Evernote came up first, so from Evernote we expanded into a discussion of data research methods. Concretely: how to research the user composition of a product. Still the same old line of thinking: classify exclusively, then summarize by class. Looking back now, answering that way really only answers the ‘what’ and never gets into the ‘how’; only half an answer. My first summary went like this: classify first, into online methods and offline methods.

• Online - for 1 to n, sample by asking directly or lean on Wenjuanxing or survey monkey; for 1 to 1, go straight to an internet research firm such as iResearch;
• Offline - executed much like online

I was told this answer wasn’t enough. Anyone can classify. Mm.. true. We kept discussing: to get more specific, you need a more specific scenario. (At the time I felt I had been discussing a real problem inside an unreal scenario, so naturally no conclusion could come of it. Later I realized I had simply talked myself into a tangle.) Add constraints and a concrete goal: no funding, and find the share of internet-industry users within Evernote. Classify again; I chose to run a small offline sample survey and then compute the ratio. I was told there were two problems: the sample too small, the efficiency too low. I thought about it; true enough. By this point the thread was actually already clear: the concrete problems had been pointed out, and all that remained was to solve them. Looking back, I had fallen into traps of my own making.. For one, I kept wanting to do things with one systematic method, and when that method failed, to tear it all down and start over. In real work that simply isn’t executable; time cost is not something you can wave away in a sentence the way you can in an interview. For another, my thinking was boxed into doing it 1 to n; it never occurred to me that 1 to 1 could also be done for free. That is another blind spot of mine: I keep converting the interviewer’s words into an added constraint (this time, silently turning ‘no funding’ into ‘no third-party research firms allowed’), when the actual implementation had nothing to do with that at all =。=! The answer I gave then was to move the whole offline setup onto the internet, method unchanged. At the end the BOSS summed it up, two problems. 1, the method I picked was too inefficient 2, I never proposed a way to verify the data Concretely, it’s really simple.. look up the Baidu Index and then validate the final figure from several angles, done.. and yes, that really is all it was.. I won’t repeat what was summarized earlier; just two additions here: for one, when the thing you’re doing already has a 1, start from the 1; it’s far faster than going 0 to 1. For another, producing a number is not our end goal; producing an accurate number is..---After that we mused on life a bit, and the conversation came to an end.---One last summing-up, then, two points

• Methodology matters; put it up front for the interviewer to see
• Implementation matters just as much; when you imagine an implementation, think hard about feasibility, and don’t argue yourself into thin air

---I suppose that counts as finished.. there are still several holes in the earlier content, and the readability of this piece has plenty of room to improve. I’ll fill things in slowly later (though odds are it’ll be abandoned halfway again