How to Write a Tech Resume that Lands an Interview

A decent example – 10 seconds to impress – Olympic medals – SEO

Sometimes the best way to get an interview is to simply have a good resume. Here’s how to write a tech resume that lands an interview.

You can get mad about how the resume process is stupid. You could be the smartest person ever, and the recruiter will throw your resume into the recycling bin. So I think it’s better to edit your resume than get mad.

By the way, if you’re in sales, HR, or any non-tech function, you will probably hate my controversial thoughts about Microsoft Office.

Example Resume

This is a version of a resume I used in 2014 when looking for an internship. I also got an interview with Google using it.

Internship Resume 2014

It’s not perfect, but it was good enough. I cringe a little on the inside when reading certain parts. But it worked.


The person reading your resume will spend less than 10 seconds glancing over it.

10 seconds.

How much can you convey in 10 seconds? They’ve got a huge stack of resumes to go through, and anything that doesn’t convey how cool you are is hurting your chances.

Structure your resume like this:

  • Put your most important items at the top.
  • Use bullet points.
  • Make key items visible with bold text.
  • Keep the resume to one page.
  • Use an easy-to-read font. (If you have to ask, the answer is no.)

Also, you probably don’t need a cover letter. Focus on making your resume stand out.

Grab Their Attention and Pound it Into Submission

When I look at resumes, the things that impress me the most are software related: internships, programming jobs, and side projects.

I don’t care about your time volunteering at a football camp last summer.

I don’t care if you were a financial analyst at a major bank.

I don’t care if you won an olympic medal in Microsoft Office.

Software work experience and personal projects take center stage. If you’re a student or new grad, you can put your education first.


“I don’t know what Python is, but I’m super good with money. And spreadsheets.”

What if you don’t have software work experience? Create some personal projects. School projects count too, if they’re interesting enough to talk about. Plenty of in-class programming projects show that you know how to code.

What if you don’t have any personal projects? Create some!

If you whine, “But I don’t have time to develop a project!” then sorry, I can’t help you. Everyone has to start somewhere.

Controversial Thoughts About Microsoft Office

Unfortunately, HR personnel sometimes attach this line to software engineering jobs:

“Experience using Microsoft Office”

Have you ever met a programmer who could use Vim but not MS Word? Personally, I’m only interested in working at real tech companies, so this can be a useful heuristic on how cool a company actually is.


Many companies (especially large ones) use programs to screen resumes based on keywords. You need to do “SEO” for your resume and include important terms in it. The keywords will vary based on what kind of position you’re looking for. For instance, if you’re applying to be an Android developer, you could include “Java”, “mobile”, “app”, and names of major Android frameworks.

And this should go without saying: don’t lie. It would be a violation of integrity to write about how you’ve worked on Android apps if you haven’t.

More Information

There are plenty more sources on the Internet for how to write software resumes. If you’re looking for an internship, check out The CS Internship Guide. That author is super smart, too!

If you’ve structured your resume well, caught the reader’s attention, and optimized your resume with key terms, you’ll be much closer to landing an interview. Good luck!

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

This Mindset Will Make or Break Your Next Project

Ollie and Patrick

Ollie and Patrick were twin brothers. They lived normal lives in the same town they grew up in. On their birthday, Ollie noticed that he and his twin brother were gaining weight.

“You two look just fine!” remarked their friend, Samantha. “I’ve never seen you more healthy.” But both Ollie and Patrick knew they struggled to run a mile. They both had tried to get back into shape last year, but their enthusiasm fizzled out after a few months.

Ollie resolved to hit the gym again.

“I can lose weight this time,” Ollie thought. “It will be tough, and I might not make much progress, but I have to try.” Ollie knew that it was impractical for him to run ten miles every day, but he could commit to attending a twice-a-week fitness class with Samantha.


A different mindset surrounded Patrick.

“I really want to lose weight, but there’s nothing I can do,” sighed Patrick. He opened another soda. “The only way I could get in shape is if I spent three hours at the gym every day and ate nothing but celery. I’m just too lazy.”

A few months later, the twin brothers met up again. Ollie lost ten pounds. Patrick created a larger impression on his couch.

Though the two brothers shared their genetics and environment, Ollie believed he could improve himself, and Patrick thought things could never change. Ollie kept his realistic, optimist mindset and achieved a successful career and a nice family. As long as Patrick kept his pessimist mindset, trouble surrounded every one of his goals.

Realistic Optimists

Shawn Achor describes optimists as people who believe their behavior matters. Pessimists, in contrast, are those who think they can’t improve, even if they try.

Optimism is not about sugarcoating reality. If you don’t have a clear view of the real world, others can tell you’re delusional.

An optimist is the kind of person who would attempt a new project despite the difficulty. They would realistically investigate solutions, work with others, and see how far they could move. A pessimist would believe “it’s impossible” before the project even starts.

If you and your teammates can see both the good and the bad in your environment, and believe you can find solutions, your project is more likely to succeed. If you’re surrounded by pessimists, your project is doomed to fail.

Know your behavior can make a difference.

Posted in Psychology | Tagged , , , | 1 Comment

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