Commandos, Infantry, and Police

I recently stumbled upon a metaphor for three types of engineers: commandos, infantry, and police.

Commandos lead the development of new products in risky ventures. They’re the most creative and visionary of the three types.

Imagine a dedicated hacker who gets v1.0 up and running in his garage. That’s a commando. He and his startup might be called disorganized, but that’s because they dislike bureaucracy and need to move fast. Once they finish, the prototype is great for early adopters and is ready to be taken to the next level.

Infantry are the tsunami of people that follow the commandos. Once the commandos have built a prototype, the infantry take it to scale. They flesh things out, productionize the code, and make it workable for mainstream users.

Naturally, this requires a larger amount of rules and processes, but infantry are generally okay with some bureaucracy. And the potential rewards are smaller for infantry than for commandos, but it’s also far less risky.

Finally, the Police arrive. The police aren’t soldiers like the commandos and infantry. In fact, they want to maintain order, not disrupt it.

The Police are the engineers that work best on established products at established companies. They make incremental improvements, polish the infrastructure, and ensure the product continues to serve users. There’s plenty of bureaucracy, and the police don’t respond to changes in the market as fast, but that’s okay for them–the product is relatively stable.

Every project needs commandos, infantry, and police during its lifetime. My question is: which type describes you and your project?

Posted in Software | Tagged , , , , | Leave a comment

Four Things Successful Software Interview Candidates Do

I’ve conducted many software interviews at Google. I’ve seen a few great candidates–and plenty of not-so-great ones. Whether you’re interviewing for an internship or a full-time software engineering position, these four habits will impress your interviewer.

In other words, this is what I’ve seen from the other side of the table.

1. Ask questions to clarify the problem

In the real world, problems are ambiguous. Some interview questions are deliberately murky to test how you deal with uncertainty. The solution? Ask questions to clarify the problem.

2. Listen to the interviewer

Interviewers typically don’t intend to roast you over a fire. If the interviewer suggests a change to your algorithm, they often are trying to guide you towards a correct solution.

3. Take care of edge cases

Edge cases matter. In one interview, the candidate didn’t write the base case of a recursive function. He knew it, and it was trivial, but he didn’t add it to the whiteboard. After I asked the candidate to put it up there, he rapidly progressed through the rest of the solution.

4. Step through your code

After writing a function, step through your code with an example to sanity check your logic. This helps catch bugs and shows the interviewer that your algorithm is correct. Interviewers are people, too, and if you’ve written the solution differently than the interviewer usually sees it, it’ll take them extra brainpower to determine if your code is correct.

Bonus: After the Interview

After the interview, you have the opportunity to ask the interviewer questions. This doesn’t have an effect on your scores, but I love to answer questions besides the standard “What do you work on?” and “What do you like about Google?” This is your time! Use it to get a feel if the company is right for you or not.

Also, I usually write interview reports on the same day as I conduct them. If you were to send me a thank-you email, I would already have submitted your scores.

So if you want people like me to recommend you to be hired, be amazing in the interview. Ask clarifying questions. Listen to your interviewer. Take care of edge cases. And step through your code. Do these four things, and you’ll be that much closer to landing your next software job.

Posted in Software | Tagged , , , , , , | Leave a comment

The Best Part About Working at Google

Every once in awhile, people ask me how I like working at Google. “It’s pretty cool,” I say. But there’s more to tell if you want to dig deeper. Here’s a peek behind the curtain, where you can see both the good and the bad.

What do you like about it?

First of all, I’m surrounded by extremely talented people every day. It’s like having Superman at the desk next to you, and he can teach you how to gain laser vision. I’m constantly learning from my teammates and I genuinely like working with them. It’s good to be with people who want more than just a paycheck.

There’s tons of good software infrastructure. Engineers at Google have built countless tools to make development easy. Imagine you’re building a house. Need a wall? Already done. Want to add a faucet? Ready to install. And if you need some extra electricity, supporting teams are usually happy to construct additional pylons.

Perks. LOTS of perks. These range from massages to team trips to places such as Disneyland, Tahoe, Las Vegas, and Hawaii. My personal favorite perk is the free food. These days, the steak and lobster have been replaced by kale and quinoa, but it’s still tasty, healthy, and one less thing to worry about.

What could be improved?

Focus on the user. My first project was building an online video gallery where people could download images. Sounds interesting, but it was as helpful as a megaphone during a zombie apocalypse. So much time and talent went into developing a service that no one wanted, and it could have been avoided by doing user testing before development.

Setup is tough. Since Google has a lot of in-house tools, the learning curve is steeper than a warped wall. Some teams are bogged down with legacy systems, human bureaucracy, and resource constraints. And even though mobile is important to Google, the infrastructure for iOS apps is a bit behind Android. (It would be weird if it was the other way around.)

Promotion by bragging. To be promoted, you have to write a packet the size of a small novel and hope it wins over a random committee of people you’ve never met. To be fair, it’s not all bad. Your promotion is not dependent on how much your manager likes you. The bad part is that the financial incentive encourages teams to build messaging apps that look good on paper, whether they help the user or not.

The Best Part

Though I enjoy the free coffee and complain about the product definition (or lack thereof), there’s one last thing that leads the pack.

It’s not the self-driving cars.

It’s not the culture of openness.

It’s not the comfortable chairs, adjustable standing desks, or natural light sources.

The best part is that every day is an opportunity to learn and feel satisfied with what I’ve created.

Maybe it’s geeky that I like programming. Maybe I’m weird because I’d rather be at work than browse social media for eight hours a day. And maybe my job will change, or I won’t like software development in ten years. But for now, it feels good to develop new skills and see the things I’ve made impact people around the world.

And that’s the best part about working at Google.

Posted in Software | Tagged , , , , | 5 Comments

Making it Easy

A gym’s locker room had two towel bins. The gray bin was close to the lockers. The black bin was twenty feet away, around the corner, and not very visible to tired athletes.

The management want to keep the locker room clean, so they put a sign on each bin that said, “Please use other bins when this one is full.” Unfortunately, everyone piled their dirty towels on the floor around the gray bin. The black bin was simply harder to reach.


The management eventually moved the black bin next to the gray one. Both bins sat close to the lockers, easy to reach, and everyone put their dirty towels in a bin. Problem solved.

When developing software, we can encourage particular actions by making them easy. Humans often take the path of least resistance, so we as designers and developers should make that path the good one. Every decision requires mental effort, after all.

For example, Twitter wants users to “follow” other users, so they made a prominent “follow” button on every users’ profile. There’s no email confirmation barrier. Just the tap of a button. Easy.

Defaults are another powerful way to encourage behavior. Practically every website puts new users on its mailing list (though they can opt-out). If customers had to actively ask to join a mailing list, there would be far fewer shoppers receiving cookie dough promotions. In this way, defaults can be used for good and bad.

In short, put the towels bins where they’re easy to reach.

Make things easy.

Posted in Software | Tagged , , , | Leave a comment

How to Network Better than 80% of People

Have you gone to a networking event where you know no one, and felt like you didn’t get much out of it? I’m not the world’s best at these events, but I’ve witnessed how a few minutes of preparation can get you 80% of the way there.

If you’re networking for an internship, the environment will be different than what this article suggests. These tips apply more to informal networking events like Campfire at Tech Ranch than talking to recruiters at a career fair.


Rehearse Your Introduction

At a networking event, the first question you will often be asked is, “What do you do?”

Practice what you’re going to say and you will be a mile ahead of everyone who didn’t. I’ve seen too many people unable to clearly and concisely state what they do.

Some will say, “Hi, I’m Bob. I’m a software engineer at a startup working on, uh, an Android app that counts how many breaths you take per minute, and…”

NO ONE CARES! Be concise and tell them why you’re building that app.

“Hi, I’m Bob. I’m developing an app that helps optimize the performance of NFL football teams.”

I can guarantee that you’ll introduce yourself to people outside your field, so make your intro clear enough so that anyone without a computer science background can understand.

Approach Strangers

Imagine you’re at the networking event alone. You scan the room, looking for someone to talk to, and see lots of groups of 3 and 4. You feel nervous about approaching a group in the middle of a conversation, so you reach for your phone so you can look busy.

STOP! Keep your phone in your pocket! Walk up to a group of people and join their conversation. Or, approach someone who is all by themselves. Anyone standing alone at a networking event will be relieved to have someone to talk to.

Make the Conversation About Them

This part applies to pretty much all conversations, not just at networking events.

Everyone loves to talk about themselves. Rather than blathering about your billion-dollar startup idea, ask other people questions. If you can engage others by allowing them to speak, you’ll get much better results than anyone who monopolizes the conversation.

Good questions allow for more than a yes-or-no answer, such as, “What brought you here?” or “What’s it like working at <XYZ>?” And if your conversation partner reveals something you can help them with, even better.


Let Others Know What You’re Looking For

Imagine you talk to a man named Bob for a few minutes. You talk about your jobs, the best restaurants in the city, and other normal things. As he leaves, Bob gives you his business card. The next day, you look at his card and wonder how you could help each other.

Maybe Bob was could have built a partnership with your company, but neither of you said anything about it. Whether you’re networking for a job, venture capital, or someone in a specific industry, you need to ask in one way or another!

It’s perfectly fine to include your ask in your introduction, as you end the conversation, or even in a follow-up email.

Test and Iterate

This is the least important for any individual day, but it’ll help in the long-term.

Rehearse multiple introductions and conversation questions and see what works. Saying “I’m an engineer on a robotics project” could get drastically different responses than “I develop software for industrial robots.” You’ll know if your statement is good or bad within three tests.

Personally, I’ve had great success when I’ve used the test-and-iterate model in my own conversations.

The Easy 80%

These simple things will get you 80% through any networking event. If you spend 15 minutes of preparation, you’ll be better off than the majority of “randos.” Rehearse your introduction, approach strangers, talk about them, and tell them what you need. And to go farther, test and iterate.

Posted in Software | Tagged , , | 4 Comments