Get that job at Grab

Note: I do not speak for my employer, Grab. These thoughts and opinions are solely my own.

Ten years ago I published a blog post titled, “Get that job at Google”. My basic motivation was that I wanted people starting their technical interviews with the right expectations, and more importantly, bringing their best game.

And everyone got mad. Which is at least sort of funny, given that the first three pages are about how everyone gets mad when you talk about interviewing, so I had all these disclaimers. But no luck. The very next day, some guy posted an angry retort called “Why I would never hire Steve Yegge”, in which he argues — as far as I can tell — that it’s OK not to understand the work of computer scientists as long as you can spell their names correctly. Cue twilight zone music.

And somehow his post still shows up on the front page of search results for me. Not that I care! Haha, no. It’s been ten years, so water under the bridge, right? I totally don’t care that it still shows up after ten goddamn years. Don’t care. This is me, not caring.

Whatever. My old post seems to have aged pretty well, since Google recruiters still send it out to prospective candidates today. They are of course ignoring the elephant in the room, which is that the elephant has in fact left the room and is now happily employed at Grab. But the advice I gave is still useful for getting a programming job anywhere, so I won’t fault ’em for it.

Over the years I’ve received hundreds of thank-you emails from both candidates and Google engineers, all claiming that my post was ultimately how they wound up getting a job at Google. Or even if they didn’t get the job, they said they were much better prepared than they’d have otherwise been. Assuming there isn’t an undue amount of selection bias here, I think we can safely say my post was helpful, and remains so to this day. Don’t listen to those naysayers!

But… how is my old post still relevant 10 years later? Don’t technologies change? They do! I think the main reason is that I focused on timeless concepts that could be thought of as the ABCs of computer science. Nothing complicated; it’s all stuff that’s been around for 40 years or more, and can all be learned in well under a year. These concepts are some of the key building blocks for good engineers. They are, in part, how you stay out of trouble when dealing with large scale.

All I really said, in the end, was: “Learn a little computer science.” Just a little.

It helps.

Should I get a job at Grab?

Yeah, um… so let’s talk about that.

The thing is, you should definitely go get a job somewhere. Somewhere other than where you work now. Well, unless you already work at a unicorn, but we’ll get to that in a bit.

I talk to a lot of people who are comfy as kittens in their current job. They all say things like “Oh, nobody could ever pay me as much as my comp at my current company”, or “Hey, just a few more years and I finally might be able to get that promotion”, or even “I’m kind of miserable and unhappy, but also too comfortable to get off my butt and move somewhere.”

People at Amazon think this, people at Google think this, people at Facebook think this. I’ve even heard Microsoft folks saying it. Everyone’s saying the same things. Including very senior people who have 15 or 20 years invested in their current employer.

But I’m here to tell you that you’re all wrong. Wrong, wrong, way wrong. Because something very strange is going on in the industry. It started maybe a couple years ago, and escalated a lot around a year ago, and then went completely crazy about six months ago.

What happened is this: Global demand for software engineers has completely outstripped supply. There has always been a strong demand, and being a software engineer is always a great way to have a great job for life. But recently the demand has gone straight to crazy-town.

I think it might be happening because we missed a market correction sometime in the past five years. The market was supposed to take a big dive, and all the startups would fold, and the talent market would be flooded with engineers looking to get back into secure big companies. But that never happened. Is it going to happen? Sure, eventually. But it could be a couple years. Maybe more than a couple.

So there’s a glut of investor money, and it’s creating a glut of startups, including some very big ones, and they’re gobbling up all the engineers left on the planet. And now it’s a fight.

Compensation packages have gone through the roof. However great you think your comp is, you should probably get out and talk to some recruiters, because someone out there is going to beat it significantly. The company that beats it may or may not be your cup of tea, but you should at least be aware of your market value.

Also, the age-old thing about getting promoted by jumping jobs has really heated up lately. Senior engineers and engineering leaders are in crazy high demand, because every startup needs them. So if you’ve worked at a big company like Microsoft or Facebook or whatever, your skills are way more valuable on the open market than they are at your company. For instance, Facebook engineers already know how to handle data security. OK, well, bad example. How about: Google and Microsoft and Amazon engineers already know how to build scalable systems. Better? But startups don’t have that expertise. They need you.

It’s gotten so bad that the big Chinese companies are all hiring in Seattle now. They’ve run out of engineers in Beijing, so now Huawei, Tencent, Baidu, Alibaba, all the big guys are here recruiting in Seattle, if you happen to know how to speak Chinese. It speaks to a global talent shortage, plain and simple.

If that doesn’t convince you, this might: They have run out of engineers in India. How the hell do you run out of engineers in India?! When that happens — which by the way, it never has before — you know something big is going down. But my buddies in India are telling me that many people are jumping jobs there every six months because salaries are escalating so rapidly. Everyone is of course leaving a trail of destruction in their wake — half-finished code, empty seats, legacy mess. But like I said. It’s crazy town.

Comp packages — by which I mean, salary plus stock plus bonuses — have become so large that some of the big brand-name employers are now hovering in the bottom quartile of the compensation curve. Facebook is up at the top, but working there comes with the significant downside that you have to work at Facebook, so people are turning to saner alternatives and getting compensated almost as well. And others, notably Google, are now just coasting on their reputations.

So please: If you’ve been with your company for, say, seven or more years, please just go look around. It won’t hurt, and it may be just the boost your career needed.

With that context in mind, should you come work at Grab? Well, we’re a unicorn going on a decacorn, and we’re on track to become the main financial services provider in all of Southeast Asia, we’re driving a new “industrial revolution” there that will create a new middle class and raise the region’s GDP, among many other things. We have a nifty Seattle office and a nifty Bellevue office, so you can’t even complain about the commute. Grab has an ever-expanding business model that sets us apart from many single-product companies, and makes us look more like Amazon did in the early days. We have a neat culture and cool tech and we will actually value your vast experience, unlike (probably) the behemoth you’re a part of today.

Even if Grab can’t necessarily match the skyrocketing comp packages of some of the other companies, you’ve gotta look at the big picture. I’ve tried to hint at it, but you need to read between the lines. Grab is a one-of-a-kind opportunity, in my opinion. If you’re not convinced, look again.

But hey, even if you don’t come to Grab, at least go somewhere! You don’t really want to rot away for another 20 years hoping for that gold watch, do you?

OK, good. We’ve established that you’re gonna go look around. Good on you. Let’s talk about how to rock those interviews, which you probably haven’t worried about in like 10 years.

The interviewing problem

The Get that job at Google post is still good advice. All of it. I especially recommend the Skiena book for interview prep. But in the 10 years since I wrote that post, I’ve learned that I left some stuff out. So let’s add to the list!

Some of the stuff I am about to share with you applies to getting a job anywhere. Not just Grab, not just Google. I mean getting a job anywhere, doing literally anything. It’s a life skill.

But first we need a little background. Just a little, I promise.

Note that I’m going to be talking mostly about interviewers, not interviewees here, because I think it’s an important part of interview prep to know how interviewers think! You can’t be a good food critic unless you know how the kitchen works.

So. A few years ago the famous programmer Zed Shaw posted an objectively neutral opinion piece titled “Programmers Need To Learn Statistics Or I Will Kill Them All”. Mind you, statistics is a broad field, and I have often wondered whether I’d make the cut or be forced into the thunderdome with Zed. I feel like there must be some sort of unwritten rule that you should never fight someone named Zed, since it’s a Mad Max sort of name. Which then makes me wonder how I should balance my time between statistics and self-defense. It’s a gamble.

On the whole, I feel Zed might have been a tad over-zealous. But I agree with the general sentiment that programmers should learn statistics, because it’s sexy as hell these days. Data is the new oil, and most programmers are the Beverly Hillbillies when it comes to managing it. So learn some statistics! It helps. But there’s this… prerequisite… which we’ll get to in a bit.

Diving deeper into interviewing styles

By way of even more background, I’ve spent a lot of my career digging into the problem of how to conduct the most effective technical interviews possible. Because it’s not easy. If an interviewer tells you it’s easy, then they’re doing it wrong. Interviewing someone is like trying to decide whether to marry them after a 1-hour date. It’s not possible to get it consistently right. This is why companies get super conservative and reject a bunch of probably-qualified people.

But that’s lame, isn’t it? So I think a lot about this problem.

To give you an idea of how committed I am, my friend Todd Stumpf and I once did a trip to Cancun to write the Two Dogs book. It was to be titled Conducting Technical Interviews, and it was of course going to be published by O’Reilly, and we were going to lobby for the animal on the cover to be two dogs, with one dog sniffing the other one’s butt. This was of course the greatest idea in the history of mankind. I mean it could be subtle, with one dog just sort of standing behind the other dog… you get the idea. We wound up drinking heavily and Todd tried to get me eaten by a crocodile on the golf course, and we didn’t get anything written at all, but this adventure should help you understand my level of sheer iron-willed dedication to this topic.

Mostly I think about how to conduct more efficient interviews. I’d love to just completely overhaul the process and spend days with every candidate. But it’s not practical. So really the problem comes down to: How do you get the best possible signal from a 1-hour interview?

Broadly speaking, there are two interview styles: depth-first and breadth-first. In depth-first you ask a really hard question that takes pretty much the whole hour, and the candidate sweats and shakes a lot and sometimes cries a little, and at the end you have a definitive picture as to whether the candidate can solve, under intense pressure, that exact question and nothing else.

Although that style is popular and may even have certain merits, I personally prefer breadth-first, in which you probe the candidate on a lot of topics, looking for weaknesses. That way the interview outcome is less random. With depth-first, they’re either going to get it, or not — most likely not, because you’ve asked the same question so many times that your expectations have crept up over the years. Whereas with breadth-first, you’ll quickly pass through all the stuff they know well, and stop only on the things where they say something weird. Then you probe deeper. I believe this gives you a more complete picture of the candidate and their overall abilities. Although of course someone on the loop should ask a meaty coding question.

When you probe people breadth-first, you almost always find some huge gap in their knowledge. And then you have to decide what to do about it!

When to allow mulligans

My friend Ken Fishkin has a saying about interviews: “Everyone gets one mulligan.” Meaning, every candidate is allowed to make one grave error, a mistake so bad that you wonder if hiring them might also be a grave error. But as long as it’s only one problem area, and everything else is fine, then Ken and I both generally let it slide.

Here’s the thing, though: in any interview, some knowledge and skills must be non-negotiable. That’s just common sense. For instance, if you’re hiring a juggler, then obviously they have to be able to juggle. You can’t give them a mulligan on juggling.

OK then, Mr. Smarty Pants, I can hear you asking, what skills are non-negotiable?

Ah, now there’s the rub. The answer to that question is highly contentious. For simplicity, let’s ignore opinions from anyone who is out there interviewing for jobs, because of course they’re going to argue that everything they don’t know is 100% negotiable, like Mr. “I would never hire Steve Yegge”. Instead let’s focus on what interviewers think.

Do you have to know how a hashtable works? How to implement one? How to analyze their performance? How to come up with a non-terrible hashing function? Personally I think so. It’s one of the most important tools in a programmer’s toolkit, and I am of the opinion that if you don’t know how they work, then you’ll have no idea how to understand or debug why they are failing, if their performance degrades. But I also recognize that opinions on this matter differ somewhat, so it’s not a showstopper if you don’t know it. It’s just a big red flag. If a candidate is otherwise fantastic, and that was essentially the only hole, then I’d recommend a hire, and tell them to go read up on hash tables.

But there are some things that must be non-negotiable: You should never get a free pass for them. Every programmer has to be able to write a loop, for instance. I don’t think there’s anyone who would argue that you can just “slide by” without knowing when and how to write a loop in some language or other.

I’ve decided over the years that being a good interviewer is like trying to be a good detective — you need to look for clues, and follow up on them, and construct a complete picture of the tragic crime scene which comprises the candidate’s abilities.

Am I being too harsh?

Interviewers often calibrate with each other, asking, “Am I being too harsh?” This is good practice. As an interviewer, you should be checking with others periodically to see if your interviews are being overly critical of candidates.

As a good example, Ken came by the other day and asked about bit twiddling. He and I are rapidly approaching Old Fogey-hood, and we’ve realized that things that were once required knowledge are now ancient history — punch cards, for example. No argument there. But what about bits? Both of us used to ask candidates, as a matter of standard procedure, how to manipulate bits in a byte, using their favorite programming language.

Lest you think we were being unfair, this also used to be a popular question at Microsoft, where interviewers used to ask you to write a program to count the number of bits in a byte (or a word, whatever). Solving this requires some knowledge of the standard bitwise operations such as masking and shifting. Back when everyone was writing in C, knowing this stuff was actually very important. But over the years it has waned in importance, which makes me and Ken sad. We’ve decided recently that bit twiddling, as fundamental as it seems to us, has gone the way of punch cards and dodo birds. It’s like asking people to write in cursive. It’s a dying art.

Being a good interviewer means continually calibrating yourself, to make sure you’re still asking relevant questions.

The Steve Buscemi Test

Finally! With all that Important Background Material firmly in your noggin, I’m ready to tell you that extra thingy that you should probably know before you should go out interviewing. Not just at Google or Grab, but anywhere. I’m not yet certain whether it’s 100% non-negotiable — the jury is still out, since many of my colleagues (at various companies) are giving me different answers. You be the judge!

See, last week I had an interview with a guy from a big-name company, a company that I will carefully avoid naming here. And this guy was pretty solid, well-rounded, checked all the boxes. Except one. The surprise box.

I don’t know how to put this, exactly, but… he didn’t know how to count.

Back in my day, when dinosaurs roamed the earth (read: IBM), knowing how to count was the way we talked about knowing combinatorics and probability theory. It really is all about counting, in mildly fancy ways, and if someone didn’t know the n-choose-k formula then we’d say they didn’t know how to count. Heck, I almost didn’t get hired at Google in 2005 because I failed a counting question. I was lucky they gave me a second round.

But combinatorics is not what I’m talking about here. No.

Another common meaning for knowing how to count refers to being able to count in numeral systems other than base 10. The human race has decided to count in base 10 because we have ten fingers, not making this up, and the computer race has decided to count in base 2 because they only have one finger, not making that up either. It’s extremely useful for computer programmers to be able to know how to count in base 2, so sometimes we’ll ask candidates to do it, and they never know how because Java, and it saddens us.

But that’s not what I’m talking about here either. No!

What I mean is the guy literally didn’t know how to count. In base 10. On his fingers.

To be clear, like most interviewers, I don’t begin interviews by asking the candidate to start counting. You tend to take certain things for granted.

But this candidate had started to worry me during the interview, because I was asking him the estimate the size of a data structure to see if it would fit in memory. And he figured out how many bytes it would be, roughly — but then he couldn’t tell me how many megabytes that was. He waved his hands and doodled random numbers on the board until I finally asked him, “Hey man, how many bytes are in a megabyte?” He said: “Well, a kilobyte is 1000, so… I dunno, 100k?” We danced around some more and I finally asked him point-blank to write the number 1 million on the board, and he painstakingly wrote a 1 with nine zeros after it. He started with six, and I should have stopped him there, but he was on a roll. That’s when we moved to the “Any questions for me?” part of the interview.

Here’s the crazy thing though: He was the second guy that week who didn’t know how to count. It was on the same question, my very own elephant, and the second guy had arrived at a figure of 90 million bytes, which was a reasonable estimate — but then he told me that 90 million bytes was around a terabyte. I asked him to double-check that figure, so he went up and started counting zeros, muttering letters under his breath, and then told me with 100% confidence that no, it was actually a petabyte.

You can’t make this stuff up!

This kind of makes me wonder how many people I’ve hired who secretly don’t know how to count. It’s like that guy a few weeks back who was a schoolteacher for 17 years and didn’t know how to read. I guess if you don’t know how to multiply 65*100 you can… Google it?

You may think that I just need to be more culturally sensitive, since not all countries count by thousands. That’s true — but we don’t learn to count in base-2 as children, and we need to know how to do it for computing. Counting using the key numbers for computing — megabytes, gigabytes, terabytes and so on — is absolutely essential to our jobs.

My wife says maybe they were just nervous. That may be. I like to think I’m pretty nice in interviews, but I guess if people are thinking in the back of their mind that I might blog them out to the universe, it might affect their performance. But I sort of feel like making a mistake that’s off by eight orders of magnitude is hard to attribute entirely to nerves. If I ask you what you had for lunch, and you tell me that you’re a little nervous but you’re pretty sure you ate a hundred million sandwiches, then I think we probably have different definitions of “nervous”.

It also makes me wonder how I’m supposed to prep people like this for interviews. Should I tell them to go watch a few episodes of Sesame Street? What is the most polite way to deliver the message here?

What I want to tell them, inspired by Zed Shaw, is Mr. Pink’s line from Reservoir Dogs: “And as for this non-college bullshit I got two words for that: Learn to fucking type count.”

Am I being too harsh?

It’s a wrap!

And that concludes our second edition of my long-running publication “Get That Job”, brought to you this decade (again) by the letter ‘G’. It’s exactly the same as Get that job at Google except I added Sesame Street. Oh, and a little statistics, so you don’t have to fight Zed.

Once again, feel free to send me your resume, if you’re a software engineer interested in Grab and you know how to count and stuff. It’s my name with a dot in the middle, at grab.com.

This post is dedicated to my late father, Stephen A. Yegge. Love you, Dad.