Category Archives: Career Advice

The 40-Year-Old Loser

Are you sure you want to work for Google? Or Facebook or Twitter or some other biggish company? If you’re in your early twenties, you might want to stop and think about it. Or you could end up a 40-year-old loser like me!

Let me explain.

I get to interact with a lot of young programmers, both as part of my recruiting efforts at Google and as a side effect of Programming Interviews Exposed. The other day I was reflecting on the differences in the tech industry when I graduated (1990 — pre-Java, early C++, i.e. ancient history) compared to today. Today there are so many opportunities for good software engineers to do things that I’m actually quite envious. These opportunities were not around when I graduated. Instead, my classmates and I were busy interviewing with big companies. I turned down an offer from Microsoft, for example (which in some ways I regret because I’d probably be rich by now because of stock options!). Friends were interviewing with Sun, SCO, Bell-Northern Research, Northern Telecom, big banks, etc. — all big companies for the most part. I don’t remember anyone starting their own company.

Today, though, I see many graduating students thinking about starting or joining a startup where the pay is lowish and the work is all-consuming. And that’s great, because the possible upside — i.e., going public or being acquired — is almost limitless compared to working a 9-to-5 job for an established firm. If you love autonomy, if you want to work on something that could be the Next Big Thing, if you want to change the world, a startup is the place to be. And if you were wise enough to stay unattached through your college/university years and are willing to travel to where startups thrive (and you’re OK with continuing to live like a pauper) then I recommend you go the startup route. It’s much, much easier to create or join a startup when you’re young and have no responsibilities.

The truth is that most startups fail. So at some point you’ll probably end up working for an established company. You’ll have lots of hands-on coding experience and you’ll be a prime catch — please do apply to Google, it’s a great place to work. You won’t get rich or change the world working for an established firm, but you will enjoy the work if you choose the right company and get paid pretty well.

Looking back, I guess I regret taking the easy route with my career. I played it very safe. I didn’t even take the Microsoft offer, which would have required a move to the United States. I didn’t join RIM in its salad days — it’s ending badly now, but I’d at least have some serious money to console me. Switching to Google was the riskiest thing I’ve done career-wise, which really wasn’t much of a risk!

Don’t get me wrong, I enjoy my work and Google’s a great company to work for. But part of me thinks I’m a 40-year-old loser for not taking career risks when I had the chance. If you’re young, now is the time to take those risks. Go interview for that hot startup — what do you have to lose? You can work for a big company anytime — trust me, we’ll be happy to have you! Don’t discount the tiny companies with lofty goals and aspirations. Give a startup a chance. Or better yet, find a buddy and start your own!

Dud Coder Elimination: Why Technical Interviews Matter

This post was originally published on Amazon’s as a promotional post for Programming Interviews Exposed. I retained the rights to it and am reposting it here.

By Eric Giguere

To non-programmers, the technical interview process seems cruel and heartless. After screening by a recruiter, the candidate is subjected to a series of personal interviews that test both their programming skills and their problem-solving abilities. Armed with nothing but a marker and a whiteboard, the candidate must convince each interviewer that he or she has the chops to make a meaningful contribution as a software engineer at their company. No chops, no job—it’s that simple.

Programming interviews are a way to optimize the hiring process, much the way a compiler optimizes code. One of the simplest compiler optimizations is dead code elimination, which removes code that will never execute. Dead code elimination yields smaller executables and speeds the remaining optimization steps. Not to be harsh, but technical interviews are a form of dud coder elimination—a way to weed out the people who can code from those who can’t.

The sad truth is that many job applicants with computer science or software engineering degrees don’t actually know how to code. They may understand the technical and theoretical aspects of programming. They may know how to manage projects and teams. They may be able to give great presentations. But they can’t write good code.

Writing good code is a skill you develop mostly by writing a lot of bad code. Like any craft, it takes time and effort to develop good coding skills. The more you write, the more you learn.

The dud coders haven’t written enough code to develop those skills. A typical computer science or software engineering program doesn’t involve a whole lot of in-depth, hands-on individual programming in real-world scenarios. Dud coders can thrive in these programs by doing well on the academic side and choosing the right teammates for class projects.

Hiring a dud coder can be problematic. At best, they’ll distract the other coders by requiring extensive mentoring and in-depth code reviews and rewrites. At worst, they’ll affect the group’s morale and make negative contributions to the codebase. Dud coders eventually get fired or transferred, but they can really set a project back.

Every coder, dud or not, also has a learning curve. It takes weeks to learn a new codebase and the related development tools. Companies may not realize they’ve hired a dud until months have passed.

Unfortunately, recruiters can’t always tell the duds from the non-duds, especially when they have the right accreditations and experience. The only way to ferret out the good coders from the bad or inexperienced ones is to get them to program something.

Companies could hire software engineers on a probationary basis in order to properly assess their programming skills. In fact, internships and co-op work terms are a great way for firms to find raw talent without any long-term commitment. But short-term probationary contracts don’t appeal to most programmers, especially the skilled ones.

Enter the programming interview. While it’s not a perfect process by any means, it’s a great way to get some good signals on how well a candidate can program. Several detailed interviews by experienced interviewers—software engineers who went through the same hiring process and have been trained to ask good questions—is usually enough to discern the dud coders from the good coders. And if there’s any doubt, the hiring committee will err on the side of not hiring the candidate—that’s the price most companies are willing to pay to not hire dud coders.

That’s why technical interviews matter. And why you don’t want to interview like a dud coder. Preparation and practice are the keys to landing that great programming job. Don’t be a victim of dud coder elimination!

Eric Giguere is the co-author of Programming Interviews Exposed and several other programming books. He has bachelor’s and master’s degrees in computer science and is not a dud coder. Join the mailing list for more technical interview advice.

Rejected by Google: Now What?

You’ve interviewed at Google (or Facebook, or Amazon, or the hottest new startup) and been rejected. I know what it’s like. My first interviews at Google went well, but I turned down their offer because I didn’t want to move to Mountain View. Later, when the Waterloo Region office was well-established, I re-applied and had to be re-interviewed. The interviews didn’t go as well — I didn’t take them seriously enough — and this time I didn’t get an offer. Oops!

So what do you do after you’ve been rejected? Here are my tips:

  • Don’t take it personally. I know, it’s hard, because in many ways job interviews are personal. Read Steve Yegge’s description of the ‘anti-interview’ to see why the rejection may not have anything to do with you at all. Generally speaking, I think it’s important not to place too much emphasis on where you work or what kind of title you have. If you’re a good programmer, have confidence in your own abilities. (Bonus tip: being confident will also help you do well in those interviews…)
  • Be honest with yourself. You usually know when you’re blowing an interview. It’s not a good feeling. But the lack of an offer probably won’t be that much of a surprise.
  • Don’t rant about the company. It’s never a good idea to diss potential employers. It’ll hurt your chances if you re-apply, and it makes you look bad to other employers.
  • Learn from the experience. Hopefully you read a good programming interviews book before the interviews, but reading and doing are different things. Write down the questions that you were asked and how you thought the interview went. Were you asked about algorithm complexity and you didn’t get the right answer? Go re-read the relevant book chapter and then work on some complexity problems. Don’t be afraid to explore other books, too.
  • Prepare for more interviews. Don’t stop preparing! You have to keep reading, keep working on problems, and keep programming. You should also be updating your LinkedIn profile and building an online reputation.
  • Re-apply when you’re ready. If six months have passed and you’re still interested in working for the company, re-apply for the job. Most companies will give you a second chance. You’ll be in a much better position this time because you know what to expect from the interviews and you’ll be much better prepared.

Don’t forget that hundreds or even thousands of people apply for jobs at high-profile companies like Google and Facebook. Most people don’t even make it past the screening stage. These companies spend a lot of time, effort and money to find talented employees. Making it to the interview stage is a big deal. You just have to make it a little further!

And as for my story…. I applied to Google again after about a year, took the interview process much more seriously, did proper preparation…. and this time I got in. I’m very happy working in the Google Waterloo Region office and glad it worked out in the end. I hope it works out for you, too!

Don’t Diss Your Previous Employers

I’m always surprised to see people dissing their previous employers in public, and it’s not something I recommend you do. I think it paints you in a more negative light than your previous employer.

People leave jobs for all kinds of reasons. Some people leave for better opportunities — that’s what I did last year. Some people leave because of personal issues not related to work. Some people leave because the job just doesn’t fit them anymore or because there’s nowhere else for them to advance career-wise within the company. Some people leave because of poor performance. And a very few people leave because of harassment and abuse.

But recruiters looking to determine if you’re a fit for their company don’t want to see you badmouthing your previous or (even worse) current employers. It’s not professional and it makes them wonder if you’ll be doing the same thing with their company.

Of course, you’ll never be completely happy with everything your employer does. There will be policies and decisions you disagree with. But don’t rant about them in public. Try to work internally to fix them, if you can — and I know this can be very hard in many companies. If you can’t fix them and you can’t live with those policies/decisions, maybe it’s time to look for another job.

There’s very little to be gained by complaining about an employer in public. Remember what Thumper said: If you can’t say something nice, don’t say nothin’ at all.