There were a lot of things I loved about Google Voice — being able to send online, having a history of all my texts, being able to send/receive SMS while traveling internationally (without crazy fees) — but ultimately, the fact that messages would disappear was unacceptable. Why would they disappear? Because Google Voice doesn’t support MMS. While I don’t need to send my friends a pic every time I see a cute puppy, I do want to know when my friends send me a pic. Or, at the very least, they should know that the message was dropped. Google Voice fails to report any error message on either side. Not okay.

This issue became particularly problematic with iOS’ new iMessage functionality which supports group chat. This works on the MMS protocol, so, again, messages would vanish. People thought I was just being rude and not responding.

So, after much debate, I switched off of Google Voice. Plus, I hated my Android and Google Voice doesn’t work as well on an iPhone.

I couldn’t find much online about what to expect when porting out of Google Voice, so I thought I’d write up my experience. [For simplicity, I'll call 610 my Google Voice number and 650 my Verizon number. Prior to porting, my 610 number forwarded to my 650 Verizon number.]

1. I unlocked my Google Voice (610) number at www.google.com/voice/unlock. Because I’d previously ported that number into Google Voice, I didn’t have to pay anything. Unlocking appeared to happen instantly.
2. [Monday @2 pm PST] I went into the Verizon store to explain what I needed to do. I already had an existing Verizon contract, so they would need to switch my contract to the 610 Google Voice number. The representative appeared to understand what Google Voice was, but wasn’t very clear on how to go about this.
3. The Verizon rep talked to a manager and various people and eventually learned that he needed to port the (610) Google Voice number as though it were a land line number. 
4. Their system requires an account number. This is your Google Voice number (610). Apparently, this failed the first time he tried it (possibly he typed in the wrong number), but worked the second time. I spent about an hour in the shop total.
5. The Verizon rep explain what I should expect. He said it would take 2 to 10 business days, during which time I might not receive SMSs. When I left the shop, nothing had changed. My old non-Google Voice Verizon number was still active. I continued to get calls and SMSs to my (610) Google Voice number. Google Voice showed the same “status” of just being unlocked. There was basically no sign that anything had changed. Verizon explained that, at some point in the next 10 days, my phone would be suddenly disconnected. At that point, I needed to call *226 to attach my 610 number to my Verizon iPhone. It could still take a while after that to complete the porting though. Of course, their “what to expect” explanation was based on land lines, not Google Voice.
6. [Wednesday @ 6:30 pm PST] My phone just disconnected with no notice. Unfortunately, I didn’t have the instructions with me right then, so I couldn’t re-connect my phone.
7. [Thursday @ 1:00 am PST] I call *226 to complete the porting. With a few minutes, I received an SMS to my 610 number that I’d missed while my number was disconnected. Everything seemed to work instantly.
8. [Thursday @1:30am PST] I need a local phone number for my apartment buzzer, so I set up a new Google Voice number to forward to my 610 number. Although some people report having difficulties doing this, I was able to have my new Google Voice number immediately start forwarding to my 610 number.

As far as I could tell, everything started working instantly. Others report it taking several days (or even weeks) to receive SMSs from all carriers.

If you decide to port your Google Voice number to Verizon, AT&T, or any other carrier, I’d recommend that you do the following:

1. Unlock your Google Voice number before going into the store.
2. Start this process on a Monday, or maybe Tuesday, as this process is measured in business days.
3. After the porting is theoretically complete, have people on each major carrier test sending you a message. If you are using an iPhone, you should probably select “test senders” who are not on iPhones. iPhones will use iMessage to SMS between each other when possible. It’s possible that iMessage is working when normal SMSs are not.

All in all though, it was a pretty fast, seamless process. (For what it’s worth, porting from AT&T to Google Voice resulted in about 2 – 5 days when I couldn’t receive any SMSs.)

I wanted to talk to you today about why I think technology is such a great field to enter. But, first, I think I need to tell you a bit about who I am and how I got here.

Geek^3

Fifteen years ago, when I was fourteen, my mother sat me down for a “chat.” She told me I had to take one programming class before I graduated high school.

Now, for some people, it’s surprising that it was my mother – and not, say, my father – who would require me to learn to code. But the truth is that I’m far from the first woman in my family to be “geeky.”

In fact, it started with my grandmother. My grandmother was the first woman at John Hopkins University in engineering. This was in the 1940s of course – a time when few women even went to college, let alone take something as “serious” as engineering.

My grandmother later transferred to Cornell with my grandfather, where they wouldn’t let women enroll in engineering. So instead, she did a math major, but decided to sit in on — and do the coursework for — my grandfather’s engineering courses. I can only imagine how well that went over with my grandfather’s buddies, to have his wife in their classes. And kicking their butts.

When she graduated, she and my grandfather started a successful engineering firm together – a company that they ran for the rest of their lives.

My grandmother lived in a world where the rules actually barred her from doing what she wanted – but she found a way to do it anyway. Her attitude was “rules be dammed. I’m going to do what I want.”

My grandmother must have set a good example, because three of her four daughters chose engineering majors. My mother, of course, was one of them.

I once asked my mom why she majored in electrical engineering. Her response: “Because it was the hardest.” Well, okay then.

By the late 1960s, when my mother was in college, the rules had slightly relaxed from my grandmother’s time – women were now actually permitted to major in engineering. Of course, that didn’t stop her professors from actively discouraging her from pursuing the sciences.

Her freshman year, her physics professor asked all the students who got As on the midterm to stay after class. My mother, one of the A students, listened as the professor explained why they should all strongly consider engineering. He explained that it was a difficult exam, and by getting an A, they have  demonstrated that they have quantitative skills and ambition to excel in such a rigorous field.

After his speech, the students got up to leave. The professor then pulled my mother aside: “Oh, Kathy, obviously I didn’t mean you…”

My mother went on to not only major in electrical engineering, but also to get her PhD in it – while working full time. She’s now launching her fourth medical device company.

So, you see, when my mother told me that I was required to take a programming class, there would be no whining about it being too hard, or there not being enough girls in it, or it being too nerdy or geeky or whatever. If my mother could do it, and her mother – not to mention my aunts too  – with actual real obstacles in the way, the least I could do was give it a shot.

I wasn’t too happy about the situation, but what choice did I have? So, I figured I’d take computer science my freshman year of high school and get it out of the way.

Becoming an Inventor

Unfortunately, then, something terrible happened: my mother was actually right about something. Which is weird, really, because when are parents ever right about anything? But, the sad truth was… I loved programming.

Programming was different than anything else I’d done before. I’ve always enjoy math and science, but this was more like… grown up legos.

I was the kind of little girl who, when she got a barbie, was like, “but what does it actually do?” I never really understood what other girls like about Barbies. I mean, rearranging Barbie’s limbs to make Mutant Barbie and then setting its hair on fire was fun and all, but then what do you do with it? Booooooooring.

I much preferred legos. I loved legos as a little kid. I loved how you could turn these tiny little bricks – that, really, were stupid and useless on their own – into houses, cars, stores, and so on. Programming was just like that. Building some really cool thing from these basic little parts.

Actually, programming was more like super-charged grown up legos, because you could do so much more with it. In my first two months of programming, I was already writing games – in fact, some of the same games I remember growing up. Except this time, I was writing the games. So they went by my rules.

And that’s what’s so remarkable about technology – it gives you the ability to create.

Most of my non-techie friends are in what I would call analytical roles. Some sit at their desks and analyze financial reports. Others analyze market data and make recommendations. That’s great – hey, the world needs those people too. But, interestingly, so many of them say, “darn, I wish I’d gotten an engineering degree.”

Because that’s what’s so empowering about technology. You’re not studying what’s already there, or analyzing a bunch of information. You’re not piling through mountains of numbers to make vague projections about the future. You’re actually creating something new. You are an inventor, and you can invent anything you want. You have immense power.

College Opportunities

So I stuck with Computer Science for the rest of high school, and throughout college. Now, I’ll be honest. It’s not always fun. Some aspects are less enjoyable than others, and there are great teachers and less than great teachers in every subject. Plus, it can be really challenging sometimes.

What got me through these courses – the reason that I stuck with it – is that I found a side of it that I loved. I loved the part where I was actually building software. And I knew, that if I stuck with it, I would not only love what I did, but I would get some incredible opportunities.

After my freshman year of college, I landed one of the prestigious Microsoft internships and got flown out to live in Seattle for the summer. While most of my non-CS friends were working at restaurants, I was building real experience. That was amazing.

Opportunities like this are so much more common in engineering because the US is severely lacking in sufficient technical talents. Companies are literally throwing everything they can to recruit talented engineers. Huge paychecks. Free gourmet lunches and dinners. Free soft drinks. Onsite massages. Flexible hours. Bring your dog to work (cats are rarely permitted – sorry cat lovers). It’s literally perk overload.

What can you do with an engineering / computer science degree? Anything and everything.

But the true benefits of pursuing computer science are not just money and glitzy perks. It’s about this simple fact: you can swim farther and faster when the tide is in your favor.

So I wanted to speak to you all to tell you all to pursue technology and engineering careers.

Not just because we need more females (but we do).

Not just because we need more people in the field (but we really, really do).

But also for you — because I truly believe that it’s one of the best investments in yourselves that you can make. The possibilities are endless.

When I graduated from school, I took a role as a Software Engineer for Google. Now, many people think, “well, of course that’s what you do with a computer science degree. You go write code for some big company.” But the truth is that there is no standard career path.

• Some of my classmates chose to join a start-up instead and build software all day.
• Some went to start-ups to design, but not actually build, the software.
• Some went into marketing roles because a CS degree is really, really valuable there.
• A lot of people went to take on a role called Program or Product Management, where they help figure out what kind of software people wanted.
• And then a bunch of my friends went to work for banks on wall street. They love CS majors there, even for non-coding roles, because it’s like a giant stamp of approval that you’re smart, quantitative, and can work hard.
• And still others went to launch their own businesses.
• One good friend of mine went to be an agent for stand-up comics in New York. And, yes, he was a computer science major too.
• A few went on to get their masters and PhD degrees, and are working towards becoming a professor or a researcher.
• Still others went on to become lawyers. In fact, some types of law require an engineering degree.

Many are still doing what they started off as – though much more senior – while others have switched careers. The fact is that it’s easy to switch careers and to move up quickly and to do anything you want when you have a skill that is desperately in demand.

For me, I graduated college and went to work at Google as a software engineer. A few years later, I sort of accidentally launched a company and I’m now some bizarre mix of an engineer, an author, and an entrepreneur.

And I can tell you, without a doubt, it would be a whole lot harder to be any of those things – let alone all of them, or be successful in all of them – without a technical degree. It just wouldn’t be possible.

As I said before, you can swim farther and faster when the tide is in your favor.

The Future

What I’m most excited for though is the future. My future. Your futures. Everyone’s future.

Technology is increasingly the backbone of the world. You connect with your friends through your iPhone. You record the events of your life in digital pictures and then you upload them to Facebook and Flickr. You can do almost all your research for school work online. You can decide that you want a song or book or movie and be reading or listening or watching within seconds. You might buy so much stuff online that you may forget that actual, physical stores exist.

But what’s happening today goes so, so far beyond that.

• Self-driving cars are being developed as we speak. This doesn’t just make your parents’ morning commute a little less stressful. It’ll also give freedom to disabled people who may currently depend on other people for getting around .
• Foreign language translation is not just about dodging learning French and Spanish in school. It also will connect people in non-English speaking countries, giving them access to critical agricultural and healthcare information.
• Video conferencing is helping grandparents watch their children grow up. It’s enabling soldiers to say hi to their children on their birthdays. But it’s also enabling patients in developing countries or rural areas to speak with a doctor.
• Robotic devices help Amazon ship your purchases to you cheaply and efficiently. But they also help find survivors after earthquakes and tsunamis.
• Even things as seemingly frivolous as YouTube, or Twitter, or Facebook is helping launch revolutions around the world. And even within the US, it’s enabling kids who are victims of gay bullying to connect with people who will support them and tell them hey, it gets better. This stuff is so, so important and technology is enabling it.

So technology is not just about making our lives easier and more convenient. It’s also about saving our lives. It’s about connecting with friends, family, and even strangers around the world. It’s about learning and growing. And sometimes, it’s just about making our lives a little less hard and a little more fun.

Where do we go from here?

In 1879, Thomas Edison invented the light bulb. That was a pretty cool thing at the time – light bulbs basically eliminated the need for candles. But to say that that – eliminating candles – was the entirety of his impact would be doing a great disservice to Mr. Edison. After all, I don’t think you can build a computer monitor with hundreds of mini-candles. So no light bulb means no computers, no smart phones, and virtually none of the technology we depend on today.

This is where we are with technology. With the internet, computers, and mobile devices, we’ve only just scratched at the surface of what we can do. This isn’t going away; in fact, the pace is accelerating. We can barely even guess at where things will go from here. We just know that it’s going to be really exciting.

Technology is a wave that’s moving very fast, and it’s growing in size. It stands to change everything in its path.

So get on board.

Gayle Laakmann McDowell is author of two books, Cracking the Coding Interview and The Google Resume: How to Prepare for a Career and Land a Job at Apple, Microsoft, Google, or any Top Tech Company. While Cracking the Coding Interview is a deep-dive into coding interviews, The Google Resume is a comprehensive book covering a person’s full career path. It starts from how someone should be thinking about college courses, majors, and other topics, up through resume, cover letters, interviews, offers, and graduate schools. It’s the perfect book to help guide yours or your child’s career. [Click here to purchase it on Amazon.com.]

What does Google ask Software Engineers?

The questions usually fall into a few categories:

• Data Structures and Algorithms: These questions can be very challenging, but typically do not rely on “advanced algorithms.” It’s very rare for an interviewer to ask you about Red/Black Tree. They could, of course, but tend not to because (1) it tests knowledge and memorization, which is not something they especially care about and (2) your interviewers, typically being at least a few years out of school, probably do not remember this knowledge.
• Coding: This may involve coding an algorithm that you just designed, or it may be to code a pretty straight-forward method. Remember that even simple problems can be tricky to code.
• Scalability: It’s very likely that at least one of your interviewers will ask you a question like “design a system to search a billion documents.” These questions do not require advanced knowledge in distributed systems; just good instincts. How would do this if there were just one computer involved? Now how do you scale that to many computers?
• Behavioral / Experience Questions: Almost all of your interviewers will probably ask you about some elements of your prior experience. You should be prepared to speak about anything from your resume.

Somehow, many candidates have gotten the impression that the interview process is some elaborate system, and if their process is different from their friend’s, it must be a reason for it.

The truth is so much more straightforward than that, and once you get, everything will make sense. Or that’s my hope, anyway.

Here’s how the process works at Google for software engineers. We’ll look at this from the interviewer’s side and from the recruiter’s side. Although this is technically just about Google and Software Engineering, the advice / structure is largely universal across tech companies.

What Your Interviewer is Doing

This is more or less how an interviewer becomes an interviewer:

1. Training: Your interviewer takes an interview training course to teach them how to interview. Actually, they’re really just told things like, “Don’t ask the candidate if they’re married,” and “Don’t ask where their accent is from.” In other words, don’t do anything that’s going to get the company sued.
2. Shadowing: Next, they “shadow” two interviews… you know, in case they didn’t get enough of Google interviews when they were a candidate (yep, your parents were once children themselves, and your interviewers were once candidates). This lets them see the process again, freshly, and chat with the “primary” interviewer about what they thought.
3. Instruction: Then… they’re thrown into a room and asked to interview a candidate. Where do their interview questions come from? Well, where would you come up with interview questions if you were in their shoes? You’d probably bring them from you own interview experience or find them online on sites like CareerCup.
4. Evaluation: Interviewers evaluate how well you did relative to other candidates. (This point is so important that I’m obnoxiously bolding and highlighting it. If there were a <BLINK> tag still, I’d use that.) There are two interesting parts of this statement. (1) It’s “how well,” not “% correct.” It’s a multifaceted, qualitative evaluation that takes into account how you solved the problem, how long it took you, how many mistakes you made, how much help you needed, and how optimal your solution was (note the “hows”, not the “ifs”). I’ve never once made a simple statement like, “the candidate got this question correct,” because that statement doesn’t make sense for anything other than simple factual questions. (2) Performance on a question is judged in comparison to other candidates on the same question. Taking 10 minutes to solve a question optimally may be great performance on one problem, but horrible performance on another. How do you know if you did well or not? You don’t.

Note that no one here has told them what to ask, or given them a list of potential questions, or asked them to focus on a particular topic.

In other words, they have about as much interviewing training / instruction when they’re getting started as any candidate does.

Think about this. There is no system. “Recent Google onsite interview questions” are no different from “old Google onsite questions,” or, for that matter, from old Amazon phone interview questions. When interviewers ask more or less whatever they want, there’s little consistency* across a company, interview type (phone vs. onsite), or timeline.

[* There are some differences, but most of these are minor. Phone interviews will generally focus slightly less on coding, though there is still coding.  Non-web based companies aren't likely to ask about scalability, unless it's relevant for their team. And some companies have a slight preference towards certain topics, such as Amazon's focus on object-oriented design. The differences between Microsoft, Amazon, Google, Yahoo, Facebook, and Apple are covered more in Cracking the Coding Interview, 5th Edition.]

What Your Recruiter is Doing

You might not know this, but your recruiter is a person too.

Ideally, your recruiter wants to usher you through the process efficiently. If you are going to get you an offer, they want to tell you as quickly as possible. If you’re not going to get an offer, they still want to tell you as quickly as possible.

But, that doesn’t always happen because stuff comes up - reorgs, vacations, general life / work busyness.

Next time you ask why your recruiter took a while to respond, ask yourself why you sometimes take a while to respond. More often than not, it’s just that stuff came up that has nothing to do with the other person.

—-

So with all of that as preamble, let’s see if we can answer some quick questions.

I made a mistake in coding. Am I going to get rejected?

See above. Do most other candidates make that mistake (or similar mistakes)? [FYI: on a medium difficulty or higher problem, very few people solve the problem “perfectly.”

I’m preparing for a Microsoft phone interview. What should I focus on?

See above. The fact that it’s a Microsoft interview, or that it’s a phone interview, is mostly irrelevant. Look at software engineering interview questions. If there are particularly points of knowledge you’re struggling with (e.g., you forgot how to traverse a binary tree), you should study those. You shouldn’t worry too much about who is giving the interview.

How long do I have to solve an interview question?

This is sort of like asking how long you have to solve a math problem. Arithmetic problems are solvable in seconds, basic calculus problems in minutes, and complex theory in hours, weeks, or even years.

For a specific interview problem, taking “too long” might indicate poor performance, but that amount of time varies significantly across problems.

When my buddy interviewed with Apple, he was asked to solve 3 questions in 30 minutes. I didn’t even finish one problem in that amount of time. Do I have any chance?

My imaginary 10 year old niece solved 5 math problems in only 10 minutes, while my math professor has been working on this other math problem for a year now. My imaginary niece, therefore, is smarter than my math teacher.

The above question makes about as much sense as this statement.

Unless you and your friend were asked the same interview questions, you really can’t conclude anything from your experiences.

My friend heard back from Google the day after his interview, but it’s been five days and I haven’t heard a word. Is this just Google’s way of rejecting me?

Nope. Doesn’t mean a thing.

I am an experienced candidate. Will I held to the same standards and asked the same kinds of questions?

More or less, yes. Depending on who you talk to, experience either helps you on standard coding / algorithm questions (since you’ve been coding for longer) or hurts you (since you’re further away from these academicy topics).

The slightly unfortunate reality is that interviewers tend to repeat their favorite questions across candidates, so, all else being equal, someone with 30 years or experience will probably be asked the same things as a recent graduate.

However, there will probably be somewhat higher expectations when it comes to behavioral / resume questions.

How long does Facebook take to respond after an interview?

See earlier section about recruiters. Asking how long they take to respond is like asking how long you take to respond to an email. The company may target responding within a week (which is a fairly standard amount of time), but delays can happen for all sorts of reasons.

—

I hope this little window into the interview process helps you next time you wonder why something happened the way it did. Mostly, it’s just people running around doing whatever they want. Yep – that’s it. There is no system.

Shameless plug (but, hey, lots of candidates swear by it): Just because there’s no grand, overall system doesn’t mean you can’t prep for your interviews. You can and you should. Check out Cracking the Coding Interview, 5th Edition: 150 Programming Questions and Solutions. Lots of advice, and none of the fluffy “be the best you can be!” stuff. Straight, to the point, and lots and lots of cool coding problems.

UPDATE 2: Raffle has completed! Thanks for playing

If you’ve ever wondered how to navigate the Amazon forest,

Or pondered how at a Google or Microsoft interview to do your best;

If you think that being at Apple means biting more than you can chew.

Then sit back, relax, and say, “Yahoo!”

For the fifth Edition of Cracking the Coding Interview,

Is on well on its way to being out, so, “Phew!”

Countless hours have been poured into the book,

The new version is much-improved, so pray, take a look.

One five zero problems and tons of useful advice,

On how to, in the technical hot seat, be like ice.

Folks, from the author of The Google Resume,

Comes another gem this Fall your way!

So if arrays have you feeling out of bounds,

And you’re pointedly null on how “linked list” sounds

If  your worst character is brought out by strings

And recursion, tears to your eyes, repeatedly brings.

If trees and graphs along with stacks and queues

Push you to the edge, make you pop, or perturb your views

And bit manipulations along with the byte-sized brain-teaser,

Have your brain locked up – like it’s in the freezer,

Then ladies and gents do pickup this hot paperback,

For it’s sure to thaw you and put you on the right study track!

Yep, that’s right. The long awaited Cracking the Coding Interview v5 is almost out. And we’re going to be giving out a limited number of free, signed copies to lucky readers.

Want to snag your copy? Enter here for your chance to win a copy.

What’s Changed?

To be succinct, a lot! This is not your “I want people to buy a new copy, so I’ll make a few quick changes and call it a new edition” sort of thing. This is a totally re-written, much expanded, new edition.

• Grown to 506 pages in v5, up from 308 pages in v4. (And no, I didn’t pull the ol’ college make-the-margins-bigger trick.) The images on the right are not to scale.
• Much expanded sections on resume design, interview prep, behavioral prep, mastering technical questions.
• More complete sections introducing each chapter.
• 24 new questions.
• Plus, many many additional / alternative / rewritten solutions.

The focus of the book is still Software Engineering interview prep. If you’re looking for a more general start-to-end guide to getting a job at a tech company, check out my second book: The Google Resume: How to Prepare for a Career and Land a Job at Apple, Microsoft, Google, or any Top Tech Company.

Enter here for a free, signed copy of Cracking the Coding Interview.

So how do you stand out in a stack of hundreds of resumes? Ideally, you don’t. Instead, you find more creative avenues in.

I wrote an article for CNBC offering suggestions on how candidates can land an interview with their dream company. Read it here.

After each candidate completed their interview, I’d ask them how they did. Then, I’d look up their actual performance. And guess what? There was no correlation. None. Zip. Zero. Zilch.

Why is it so hard to know how you did? The answer comes in how candidates try to judge themselves, which is typically one of two ways:

Method #1: “I know I did well / poorly because my interviewer was friendly / unfriendly.”

One guy I knew, Alex*, told me he was sure he bombed his interview because the interviewer seemed so unhappy with him. Later, he discovered that he would not only receive an offer, but he was the best candidate that the interviewer had ever seen.

What Alex didn’t know is that this interviewer was not what we’d call a “smiley happy” person. And that’s the problem with interpreting performance from a stranger’s attitude. You’re comparing them to what you’re used to, not to how the interviewer usually acts.

Additionally, a good interviewer should be friendly to anyone, even a poor performer.

Method #2: “I know I did well / poorly because of how slowly / quickly / correctly / incorrectly I solved a problem.”

Imagine a professor passes back a test and you see in big red ink the score “45.” Did you do well or poorly? You have no idea, of course, without knowing how the rest of the class did. The same goes for an interview. You can’t assess your performance on a question without knowing what’s “normal.”

Interviews are not evaluated on an absolute basis with respect to either speed or correctness. Struggling your way through one problem but eventually getting the right answer might indicate that you did extremely well, or poorly. It all depends on how other candidates did (which, of course, you don’t know).

Note: this only applies to “skill based” questions, like programming and algorithms. We’ll discuss behavioral questions later.

So how can you evaluate your performance?

As we’ve discussed, you can’t interpret much from the interviewer’s reactions. However, if you could gauge how difficult a question is, you might be able to guess at how you did. One way to do this is to ask a number of friends the same questions. If they solve it in half the time that you do, then you might be able to conclude that you did poorly.

What about behavioral questions?

Behavioral questions are a bit easier to evaluate performance for two reasons:

• Interviewer Attitude: The interviewer’s attitude is a bit more meaningful here, but you should look for changes in their attitude. If your interviewer gets more engaged during your responses, or less engaged, then that might be an indicator of performance.
• Response Quality: Unlike programming questions, behavioral questions don’t vary drastically in difficulty. Struggling to respond to several of them is an indicator of poor performance. You may recognize when you really bombed a question. But, even there, I would be cautious about making assumptions.

Remember this when you’re walking out of your next interview, or when a friend tells you they did horribly. Be cautiously optimistic, because you won’t know until you know.

Bloggers – always desperate for links and traffic – have capitalized on this, with scary articles about their “nightmare interview” and “crazy questions“.  Let’s just stop this right now, shall we?

Google’s interview process is really no different from its competitors. An engineer does a phone interview or two, where they’re asked standard coding and algorithms questions.  Sometimes they’re asked to code via Google Docs, because evaluating phone coding isn’t easy.  Then, if all goes well (it usually doesn’t – that’s just how it is at any company), the candidate is brought in for a full day of interviews.  Candidates are asked a mix of standard coding and algorithms, and are asked to code on the whiteboard.  Coding on the spot might seem surprising to those outside of the software industry, but it’s standard practice.  After the interview, Google’s process is a bit different from Microsoft and Amazon’s: a candidate’s feedback is submitted to a hiring committee of engineers who makes a hire / no hire recommendation.

(FYI: I served on Google’s hiring committee for 3 years, and interviewed 120+ candidates.)

IQ Tests? I’ve never seen these. Ever.

Brain teasers? Banned.  (Of course, everyone has a different definition of a brain teasers.)  If an interviewer were to ask a candidate a brain teaser, despite the policy, the hiring committee would likely disregard this interviewer’s feedback and send a note back telling the interviewer not to ask such silly questions.

That whole “Google cares about GPA even for people years out of college” thing?  I supposed I can’t speak for every hiring committee, but I never remember my hiring committee discussing the GPA of a professional candidate.  For that matter, we were never even given a candidate’s GPA unless he/she elected to put it on their resume.

Now, let’s look at the very widely circulated “15 Google Interview Questions that will make you feel stupid” list.  You want to believe these are real questions, given that Business Insider feels like such a reputable source.  Except that they didn’t get this list from a direct source.  They borrowed their questions from some blogger (I won’t link back here) who was posting fake questions.  Now, I don’t know that said blogger was intentionally lying – he probably borrowed them from someone else.  Whatever the original source is, these questions are fake. Fake fake fake.

How can you tell that they’re fake?  Because one of them is “Why are manhole covers round?”  This is an infamous Microsoft interview question that has since been so very, very banned at both companies .  I find it very hard to believe that a Google interviewer asked such a question.

As for some of the others – “Explain the significance of ‘dead beef’”, “A man pushed his car to a hotel and lost his fortune. What happened?”, etc – I’m also highly skeptical.  If one’s a lie, why on earth would we believe the rest?  Especially if they are clearly in the banned category.

So while I know that “oh my god – Google asks candidates to reverse a linked list?” doesn’t make for quite as good SEO-link baiting material, let’s stop scaring the candidates with silly stories. And that includes you too, Business Insider. Any Google interviewer could tell you that at least some, if not all, of these questions are fake.

Want to see real Google interview questions, Microsoft interview questions, and more?  Check CareerCup.

Wait, wait, you mean not everyone loves their job at Google? Shocking! A logical person might point out that what one person loves another person hates and thus, it is physically impossible to have a large company where everyone loves their job.

That being said, allow me to make a few points:
1) Former Googlers are not representative of Googlers.
Imagine if you set up a group for ex-New Yorkers, and then asked why they left New York. You’ll probably get an usual number of negative complaints. That doesn’t mean that most people hate New York.

Likewise, TechCrunch didn’t ask Googlers whether or not they liked their jobs – they took a thread from a list of former googlers. That is, people who didn’t love Google enough to stay, for whatever reason. So, you’re already starting with a list of people whose feelings towards the company skew usually negative.

2) The Email Thread is not representative of Former Googlers
People love complaining, particularly those who feel that they have been wronged in some way. If you start an email thread with the question “Why’d you leave Google,” you’re opening the floodgates for those who hated Google. People like me, who genuinely enjoyed their experience at Google, will stay silent. People like complaining more than praising.

3) TechCrunch was unethical in releasing the (first) names of the posters.
Though TechCrunch hid the last names of the posters, they released the first names. If your name is Bob or Mike, your secret might be safe. But, what if your name is “Gayle”, or one of the many ethnic or unusual names? Then they might as well have released your full name. Releasing people’s names added nothing to the article, but embarrassed – or potentially hurt the careers of – the posters.

4) Almost everyone at Google does like their job.
When I left Google, people were surprised. Everyone (or virtually everyone) likes it there. No one came to me and said “yeah, I want to leave too. I hate it here!” I did have several people admit to me that they were thinking about leaving as well. But, in every one of those cases, they said that they liked it, but wanted to go to a smaller company or to a different role.

5) Why I liked Google (and why I left)
I had a great team. I liked our project. I liked my manager. I was working on cool, interesting stuff.

Google is, in my opinion, the best place to be an engineer. Engineers are given more authority than I’ve seen at any other company. If you want to work on something new, there’s lots of other projects that you can easily switch to. You can work on your own personal pet project 20% of time. How many other companies let you do that?

For my 20% project, I got to teach two courses at University of Washington. It was an enormous time investment, but I loved teaching. I’ve kept in touch with many of my former students, and it’s amazing to see them to become fantastic engineers at Google, Microsoft and Amazon. I really appreciate both Google and UW giving me that opportunity.

Despite Google being a great place to be engineer, I realized that I didn’t want to be an engineer anymore. Ironically, the fact that I was so happy with everything about my job at Google made it the decision easier. After all, if everything was right about the job (team, manager, project) and you’re still not excited, the issue is probably the job itself.

Though I liked coding and considered myself fairly good at it, I wanted learn a little more about business: sales, marketing, product design, finance, accounting, etc. Google is a great place, but it’s not the place to learn those skills. I felt I could only get that education at a start-up, so I left.

“We will be taking memcache offline tomorrow morning from 9-10am PST (GMT-8) for routine maintenance. Calls to the memcache API will *not* throw exceptions but will instead return false for set() calls and None for get() calls (just like any other cache miss.) Your app should continue serving normally during this period, and
we’ll keep you updated on our progress.”

Google writes this as though it’s “no biggie – we’re just disabling caching for an hour – your app will operate as normal”.

If you’ve used App Engine, you know how ridiculous that is. You can’t operate an App Engine site without lots and lots of caching.

App Engine takes your generous daily quota and divides it up into tiny little minute or second long quotas. Their logic is something like this:

1. You can eat 2000 calories in one day.
   Hurray! That’s a lot of food!
2. It’s good to pace yourself and not eat it all at once.
   Absolutely. You wouldn’t want to pig out on breakfast and not be able to eat anything else all day.
3. Therefore, we will only let you eat 1.4 calories per minute.
   Well, f*ck. Pass me two thirds of a tic tac?
   

CareerCup gets about 10,000 page views per day – not the smallest site, but hardly the biggest. CareerCup cannot operate without heavy caching. By taking down caching, they took down my site for an hour. Not cool.

Now, Google could have mitigated this by removing the absurdly small quotas temporarily. CareerCup would have run slowly, but at least it would have run. Instead, though, users get punished for expensive-ish queries, with no chance to avoid it. Not cool.

This brings me to my next point:
Google, if you’re going to take down people’s sites, can you pick a better time than 9am – 10am? Try, perhaps, 2am – 3am? I know you don’t want to come into work at 2am. I know it’s not really Google culture to tell a team that they have to be at work and away from their families 2am. But you have to. You have real users operating real businesses, many of which are a whole lot bigger than CareerCup. We depend on you to keep our websites up.

Google: Don’t act like taking down memcache doesn’t disable our sites. And don’t disable our sites at 9am when you could’ve done this 2am.