How Long Do You Have to Solve Technical Questions?

Before telling you how long you have to solve technical questions, let me ask you a question. Your math teacher assigns you a problem. It takes you 5 minutes to solve it. Is that quick or slow?

Hopefully, you're looking at this question confused. 5 minutes might be unacceptably long to compute, say, the square root of 16, but extremely quick to solve a more complex proof. I didn't tell you what the question is, so how can you tell me if 5 minutes is quick or slow?

So how long do you have to solve technical questions?

As in the above situation, it totally depends on the complexity of the question. A simple factual question might take seconds. A reasonably straightforward algorithm question might take a couple minutes. But a complex algorithm could take 30 minutes or more to solve.

That said, in a technical typical interview, a candidate typically solves one or two coding / algorithm questions. That's an average though, over typical questions; be very careful about thinking, "gee, I solved three questions, I must have done great!" Solving ten questions does not mean that you've done well, if they were easy questions. Likewise, you might have done extremely well without even finishing one question.

So how do you know how well you've done?

You don't (really, really, I promise you, you don't!). Your interview performance is impossible to judge.

Okay, folks, here’s how the Google interview process really works

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.

Read the rest at technologywoman.com.

 

Officially on sale! Cracking the Coding Interview, 5th Edition

The 5th edition of the best-selling programming interview prep book, Cracking the Coding Interview: 150 Programming Interview Questions and Solutions, is officially on sale. And even better - Amazon is currently running a 20% sale on the book!

Now, I know you're used to new editions being a couple little fixes here, packaged in a shiny new edition probably for no other reason than to get you to buy your own copy rather than borrow your friend's. That is not what this is.

The fifth edition of Cracking the Coding Interview is a massive expansion of the fourth edition. It added 200 pages of content, growing the length of the book from 308 pages to 508. A more complete description of the many, many changes are below.

As before, Cracking the Coding Interview focuses on software engineering interviews. If you're looking for a start-to-end guide on how to get a job a tech company, pick up 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. The book is rated 4.5 stars after 22 reviews and can be purchased from Amazon or any Barnes and Noble store.

Massive Expansion of Introductory Chapters
The book opens with about 70 pages of content you need to know before diving into an interview question. This includes:
  • How do companies evaluate you?
  • How do you prepare for behavioral questions?
  • What happens behind the scenes at Microsoft, Amazon, Google, Yahoo, Apple and Facebook? How does the process work? Who is evaluating you?
  • How do you write a great resume?
  • How do you tackle tricky technical questions?
  • What happens when you get a question wrong?
  • What should you evaluate in an offer?
  • How do you negotiate an offer?
Expanded Chapter Intros

Each chapter opens with a discussion of core skills and technique for solving each type of question. This ranges from 3 to 10 pages, depending on the complexity of the topic. As always, we assume that you know the really basic stuff, so you don't need to wade through stuff like what a tree is.

Rewritten Solutions (+ 24 new questions) Every questions has been carefully reviewed and the vast majority have been partially or fully re-written. New solutions were added to existing problems, and 24 new questions were also added.

As before, fully compilable Java solutions (ready for import into Eclipse) can be downloaded. The download is hosted on CrackingTheCodingInterview.com.

Website / Forum (CrackingTheCodingInterview.com)
Interview problems are best with some discussion, so we've created a website / forum built around the book. If you have questions or additional solutions you'd like to consider, post them there to discuss them with other readers. The java solutions can also be downloaded from there.

Ask Gayle: How do you negotiate offers for the big companies?

Gayle, I recently got an offer from a major software company, but it's not quite what I was hoping for. How can I negotiate my offer?

~ PV

First of all, you're off to a great start by just trying to negotiate. Most people don't even do that.

Much of the standard negotiation advice applies here:

  • Having competing offers will give you leverage
  • Know what you can get an other companies (goes back to the competing offers thing)
  • Being able to quantify your value to the company - what can you do for them?
  • Think big picture. Maybe you can't get a salary bump, but perhaps you can get a better signing bonus. Or maybe you can get relocation in cash, instead of the company directly paying for it. Or, perhaps you can get an agreement for an earlier review or opportunity for promotion.

One thing to note with big companies like Microsoft is that they often have "levels" for employees, with a small salary range for anyone at that level. You have some wiggle room within that range, but larger bumps may require jumping up to the next level. You'll need to understand what you need to demonstrate to reach that level, and use examples from your past to demonstrate that you have these qualities.

Interested in Amazon Montreal? Special offer for CareerCup users

Hey Montreal folk - Interested in Amazon and looking for a way in? We've got a great offer just for CareerCup users.

Amazon is conducting a Hiring Event (mostly last Week of April, Thu Apr 28, Fri Apr 29 ) for software design engineers. The best part? No phone interviews. Interviews will be conducted in person in Montreal, with a decision typically in 2-3 days (often same day).

Take advantage of this by emailing your resume's to rh2010 <at> amazon.com. The subject line of your email should CareerCup.com Montreal.

Why You Got Rejected -- Even Though You Thought You Did Well

Ever walk out an interview thinking "I nailed that!", only to discover that you got rejected? Or, conversely, think you bombed, but then you proceed to the next round anyway? The truth is that it's incredibly hard to gauge your own performance in an interview. Usually, when you attempt this, you're looking at one of two factors: the interviewer's attitude, or how many mistakes you made.

Read on for why this doesn't work: Why Your Interview Performance is Impossible to Judge

More than a number: How much does Google care about GPA?

Gayle, I'm currently a junior at Cal Poly, and my GPA isn't great. I estimate when I graduate it'll be between a 2.7 and 3.1. Will that put me out of the running for Google and Microsoft? Do those companies really have a minimum GPA requirement? Is there anything I can do to offset my low GPA to increase my chances of getting hired?

~ Alex

Not only is there not GPA requirement, but you don't even necessarily need to have gone to college. I worked with a number of people at Google who had dropped out of college. Does that mean GPA doesn't matter? Not quite.

Both Google and Microsoft will try to use any available metrics to predict whether or not you'd be a successful employee. Once you've interviewed, your interview performance matters much, much more than anything on your resume. In fact, I never even remember GPA being discussed after someone's interview.

In the resume selection process, GPA can certainly have an impact, but it's not the only factor. Ultimately, companies are looking for a "track record of achievement," or signs that you're smart and that you can code. That can be one or more of these factors:

  • Attending a good school
  • Internships / jobs at other "good" companies
  • A strong GPA (above 3.0)
  • Big / cool projects (course projects, open source work, things you've done 'for fun')
  • Other technical work: TAing, etc

If you don't have a great GPA, that's okay. Many people get interviewed with low GPAs, but they compensate with other projects and work. In fact, that's exactly what I did (my GPA varied between a 3.0 and a 3.3).

One final thing: if you're trying to compensate for a lower GPA with other projects, the quality of your resume tends to make a bigger difference. After all, if the numbers are telling a great story, it's that much more important that you learn how to.

Read our resume tips on the links below, or check out CareerCup's professional resume review service.

What's the "Right" Programming Language for an Interview?

Hi Gayle, Does it matter what language you use in an interview with Google/Facebook/Amazon? Most of my recent experience has been with C# and thats the language I'm most comfortable with. I do have prior experience with C and C++ although in an interview would prefer to use C#. I'm not sure if that would be seen as a negative.

~ Nick

Like most things in interviews, it depends on your interviewer. Theoretically, as long as your resume lists C / C++, your interviewer could ask you to code in those.  And they might, if they happen to have a favorite question that involved C or C++.

However, in general, that doesn't happen. Most candidates code in Java, and most interviewers are fine with that. C# is pretty close to Java - so close that your interviewers may not notice or care about your coding C#.

Still, I'd recommend that you brush up a bit on the few syntactical differences between C# and Java, so that you can code in Java for your interviews.  Just explain to your interviewers the situation - most wouldn't care.

What do you all think? Does the language matter?

Less Is More: How I Cut My Resume To One Page

I (very) recently wrote about Eight Reasons Why You Need a One Page Resume.  As an example of how you can cut down your resume, I wanted to provide an illustration of how you can, in fact, fit a lot of content on one page - without making your margins tiny. Here’s what I manage to fit on one page of my resume (view here):

  1. Three internships at Microsoft
  2. One internship at Apple
  3. Three years at Google
  4. One year at a start-up
  5. Founder / CEO of CareerCup
  6. Founder / Co-CEO of Seattle Anti-Freeze
  7. Author of Cracking the Coding Interview
  8. Author of The Google Resume
  9. Masters in CS from UPenn
  10. BSE in CS from UPenn
  11. Minor in Mathematics
  12. MBA from Wharton
  13. Former instructor for 1 CS course as an undergrad at UPenn
  14. Former instructor for 2 CS courses at the University of Washington
  15. Various activities: Principal at Wharton Ventures (VC Group), Yearbook Chair, Social chair of cohort, Finalist in venture capital competition

How did I fit all this on my resume?  By being very, very selective:

  • CUT: College projects.  They’re coding projects.  I’ve demonstrated that I’m highly technical by having other software engineering positions.  It just doesn’t matter any more – particularly as I’m not applying for coding jobs.
  • CUT: TA / Head TA at Penn for 4 years.  While being a TA / Head TA does show some valuable communication and other skills, I have already demonstrated that through other activities (such as being an instructor at UPenn / UW).
  • CUT: Hobbies.  It’s not that no one would care that, say, I enjoy playing squash, but a lot more people will care about almost anything else still on my resume.  Any that goes for most people - don’t waste time with your hobbies.
  • CUT: Advisor to various start-ups.  Again, it’s not that it doesn’t matter at all, but it doesn’t matter as much as other stuff.
  • REDUCED: Microsoft and Apple jobs.  Although I’ve already demonstrated technical skills through my position with Google, there is something compelling about the fact that I’ve worked at Microsoft, Apple and Google.  I don’t need to spend a ton of time discussing these jobs.  Just listing them is enough.  I put one bullet under each company, covering four internships total, and that’s enough.

See my “one pager” resume: Technical College Resume (2005); Non-Technical Professional Resume (2011)

Sure, it hurt a bit to cut that stuff.  But by removing or reducing those less impressive accomplishments / roles, I ensure that everyone who glances at my resume will see the most impressive things.

Again, if you need more convincing if you aren't convinced of why you can and should have a one page resume, read this post Eight Reasons Why You Need a One Page Resume.

Less Is More: Eight Reasons Why You Need a One Page Resume

(Don't forget to check out Part 2 - Less Is More: How I Cut My Resume to One Page.) Having reviewed resumes for five years, first for Google and now for CareerCup's resume review service, I've frequently gotten resumes from software engineers as long as eight pages.  In fact, the average resume length that I get through CareerCup is probably 2.5 pages.   Yikes!

Now, I know that they think that they've probably really impressed their resume screener.  After all, if they can fill up three (or eight) pages, they must have a ton of experience, right?

Not quite.  In fact, almost anyone can blabber on for multiple pages - and, frankly, it tends to be the people with less experience who feel the need to have such lengthy resumes.

Please, don't do it.  Stick to just one page if you have less than 10 years of experience.  If you have more than 10 years of experience, a 1.5 - 2 pages is allowable (although even there it may not be ideal).

Here are eight reasons why a short and sweet resume is best.

1. Many resume screeners will automatically toss multi-page resumes. I may not agree with that absolutism.  After all, I want to find the best people, not the best resume writers.  But,  given how many people are absolutist about one page resumes (though most make greater allowances for people with more experience), do you really want to get ruled out for such a simple thing?

2. Even if people "accept" a multi-page resume, they may groan when they get one. First impressions matter.  Do you really want someone's first impression of your resume to be "ugh?"  I'll be honest - that's my first thought when I see a three pager.

And, consciously or subconsciously, the "ugh" reaction may make someone itch for an excuse to toss out your resume just so that they'll stop having to read your resume.

3. Longer resumes do not make people assume that you have more experience. I've seen no correlation between the length of resumes and the amount of experience people have. Just because you have a lot more content on your resume does not mean that you have more experience.  Hey, when I was a freshman in college, I had a three page resume. (Yes, it was pretty awful.)

4. Just because your resume is longer does not mean people read more. Recruiters generally spend a fixed amount of time on your resume - and it's only around 15 or 30 seconds.  They do not spend longer on your resume simply because you decided to waste their time by writing a lot more.  What matters is how much - and what - they read, not how much happens to be on a page (see #3).

5. Long blocks of text scares people. My first reaction when I see five jobs with twenty bullets each is to just skip that section entirely. After all, I have a huge pile of resumes to read, I just need to make yes/no decisions on interviewing, and it's so much easier to just toss your resume than wade through massive amounts of text.

6. Longer resumes -> more dilution -> worse impression Think of it this way. Who is a better student?

  • Alex: A-, A+, A-, A
  • Pat: C, B+, C+, A-, B-, A+, B, B, A-, C, B-, A

It turns out that, although Alex seems like  a stronger student, he and Pat have actually gotten the exact same grades.   However, Alex has listed his best five, while Pat wanted to "show off his experience" by listing all his classes.

Your multi-page resume is like that. You've taken your 'A' content and diluted with B and C content. I walk away thinking you're a B candidate, rather than an A.

7. Longer resumes cause people to miss the most important stuff When you have lots of mediocre content on your resume, not only will this detract from my impression of you - but I may never even get to the best stuff.  When you have a few lines about founding a company or starting some major project, but it's buried in three pages of text, I may never see it.  Again, I don't read your resume.  I simply glance at it for 15 - 30 seconds.

8. You are not THAT awesome. Ironically, when I tell people they need to cut down their resume, I get the most push back from people who aren't all that impressive, claiming that they just have  so much experience that they can't cut it down to one page.  Sorry, but you're not that awesome.

Anywhere that you're applying will have a lot of people - perhaps even most - with a lot more experience, or more impressive experience, than you.  And they all manage to fit it on one page.

And, really, you can fit a lot on one page if you understand what you really need to say.  Want an example?  Read Less Is More: How I Cut My Resume To One Page.

The idea of the short and concise resume is to give people the best possible impression given that they're only briefly glance at your resume for 15 - 30 seconds. You'll do that best by limiting it to just your A+ content - through a one page resume.

Why Hobbies are Not Resume Material

Let's end this right here and now: most recruiters / hiring managers don't really care what your hobbies are - or at least not most hobbies. When I'm trying to hire someone, I'm looking for three things: (1) intelligence (2) coding skills (3) good personality (4) work ethic.  #3 is really only prioritized in a small company situation and #4 is really hard to determine.

On your resume, I want you to prove to me that you are smart and that you can code.  And maybe that you have a personality that I'd want to work with.  The fact that you play tennis rarely relates to any of these.

There are a few exceptions to the "No Hobbies" rule:

  • Your hobby is a major accomplishment. For example, you completed a marathon.  That might just barely show a relevant work ethic, and might just barely be worth it to add.
  • Your hobby is tech related. For example, if you write a blog about technology - yeah, I might care about that.  It improves your coding skills since you'll have a better knowledge of what's going on with technology.
  • Your hobby shows a good personality. For example, you are part of a stand-up comedy troupe.  You probably have strong communication skills and a good personality.  It won't matter at all for getting hired (I'll evaluate you based on my own interaction with you), but it might help tip you over the edge as far as selecting your resume.
  • Your hobby shows leadership. If you're the president of a club - or, better yet, founded a club - that might get at work ethic.

The vast majority of the time, your hobbies are none of these things.  They're merely some vague item like "traveling" or "tennis."  I've played tennis and thought it was fun - can I list that on a resume?  I recently saw a resume (from an Indian guy) that listed "Traveling: extensive traveling over North and South India."  This is sort of like saying that I love traveling and I've traveling all over the US.  That's not really what we call "traveling."

The problem with hobbies, other than them just being totally irrelevant, is that anybody can list the same hobbies.  They're rarely ever backed up with evidence, making them even more useless than they were to begin with.

Many students, when I tell them to cut the hobbies from their resume, tell me about how in one interview they / their friend was asked about one of their hobbies.  That's probably true - I'm sure there are lots of interviewers who periodically ask about hobbies.  But, I have a whole lot more stories about being asked about your projects, work experience, etc.

Remember: every line on your resume is replacing something else that could have gone on your resume.  You should add the line that contributes the most value.  Your hobbies rarely do.

Quitting your job? Here's what you should do next.

If you're like many people out there, you're unhappy at your job and just want out. You know you'll be able to focus more on your job search if you weren't constantly distracted with work - and you wouldn't have to make up so many fake doctor's appointments that your boss thinks you're deathly ill. But should you do it? Should you leave your job before you find a new one?

If you can afford it - that is, if you can afford being unemployed for several months - then it might be work it to just take the leap.

But here's the trick: find something "real" to do with your time. Start a business. Chip in at a friend's startup. Re-code your college senior design project in more modern technologies. Just do something!

You'll have a much better answer what you are doing with your time, you'll keep your busy, you'll make your resume a bit more interesting, and, hey, maybe you'll learn something.

Joining Google (or any great tech company)? Don't believe management's lies - 3 tips to really succeed.

Piaw Na, an ex-Googler, wrote an excellent post titled Tips for Noogler Engineers.  Piaw correctly points out that what's great for Google isn't necessarily what's great for you or your career.  For instance:

"Interviewing. It absolutely does not help your career one bit, even though it's absolutely critical for Google in the long term. It's not rewarded, considered during the promotion process, and it burns a lot of time. Put it off as long as possible. And don't even bother with hiring committees. That's even more of a time sink. ... 20% time. Depending on your manager, it could absolutely hurt your career. triple check to make sure your manager does not take a negative view on this. I liked my 20% time, but I was well aware of the trade-off for my career I was making."

I completely agree.  I enjoyed interviewing (well, until I did too much of it), and I loved my 20% project, but he's right - it doesn't help your career.  If you want to do this, you need to accept that this will be an unrewarded "vacation."  (And, even more frustrating, once you start interviewing it can be difficult to stop.  I spent 4 hours on interviewing every week, plus another 1 - 2 on hiring committee.  Google needed female engineering interviews, so I always got assigned two interviews.)

So what can you do to succeed?

  1. Get a really good manager or tech lead: One thing that's nice about Google is that you can easily switch projects.  Before switching projects, ask around about the career history of your TL/manager's underlings.  Have they been successful?
  2. Pick high profile projects: Again, what's good for a company isn't necessarily what's going to be rewarded.  The meaty maintenance issues are important, but they won't be rewarded.  You want to pick the project that people know and understand.  You want as many people as possible to recognize your impact.
  3. Tackle the meaty problems: You not only want to be on the coolest projects, but you also want to tackle the biggest problems.  Seek out the problems that are widely understandable and have tangible, or ideally measurable, impacts.

Following these three tips will not only offer you a more successful career within the company, but they will also help you build a stronger resume when you leave the company.

Read More: Great Resumes for Software Engineers (and others)

The Interview Factory: Where Do Questions Come From and Who Picks Them?

Every day, I hear one candidate ask another, "Have you interviewed with Company X?  What were you asked?"  This would be a perfectly reasonable question, if it weren't for the fact that they were doing so on a website with thousands of interview questions.  Why get 5 questions when you can get hundreds? The truth is that, at most companies, there's no grand system.  There's no structure.  No one saying, "ok, now, every candidate will get one networking question and it will cover TCP/IP."

There's just... people.  Interviewers take a bit of interviewing training, that usually covers oh-so-helpful legalese like "asking candidates about their marital status is illegal", and then off they go!  Interviews ask whatever they want to ask.  No system, no structure.  Just a bunch of people making up their own minds.

Next time you're about to ask someone else what they were asked, stop and think: will this person tell me anything new?  Relying on one person's experience for your preparation is much, much worse than relying on the experiences of many.

Instead, do the following:

  1. Check CareerCup.com for programming interview questions, but don't limit yourself to just your company's questions.  If you're interviewing for Amazon, be sure to check out the Microsoft Interview Questions and Google Interview Questions.  Companies are far more similar than they are different.
  2. Review the questions to get a general feel for what the company likes to ask.  If you're doing an Amazon interview, for example, you may notice that Amazon loves object oriented design questions.  That'll give you a good idea of where to focus.
  3. Practice!  Don't worry about getting the answer to each and every question.  Answers won't help you.  You need to solve the problems yourself, so you learn the general techniques.

While your questions may vary based on your background, your interviewer, the team, or the prospective company, interview questions are actually more consistent than not.  Interviewers don't like coming up with new interview questions for every candidates; it's hard, and results in poorly calibrated feedback.

As far who "invents" the questions, the answer is that it's rarely the interviewer.  Employees talk, and questions are shared across a company.  When people switch companies, they bring their favored interview questions with them.

I'm still asking my five favorite questions in my mock programming interviews.  I don't change them frequently because calibration is more important than creativity.  I know how to ask the question, how to lead a candidate to the solution, and exactly how well you did relative to other people.  Why change?

Ask Gayle: I left my job because I didn't like my coworkers. What do I tell future employers?

Hi Gayle, I have a question. Basically I was moved to a group that was really bad in terms of people, nature of work and my career began to stagnate. I had a vacation planned and wanted to take up a new job immediately after that. So I quit, immediately left for a vacation and back and right away applying for new positions. Before I quit, I was one of the very few people in the company who got a bonus and a letter of appreciation from the CEO.

When looking for a new job, I am confused what to tell my prospective employees. Is it fine to tell them that I quit as I did not like my new group? I am not sure if this would reflect negatively on my personality. Or is it better I tell them that I was planning a career change, so quit and took a vacation and looking for a new job now?

Could you please advise me on the best approach to take?

Thanks, Gary

Depending on how you word it, it can unfortunately reflect negatively on your personality.  Teams want to work with more positive, upbeat people - not someone who complains all the time.  Additionally, if you're complaining about your last job, a new team will fear that you'll complain about their company too.  And no one wants to take that risk.

It's better to spin it in a more positive way: what were you looking for that your old company couldn't offer (and that conveniently this new company can offer)?  I don't know the specifics of your team and why you didn't like it, but consider an answer more like this:

  • Interviewer: Why did you leave your last job?
  • Gary: I really wanted to take on a role that's more focused on the client and on feature design.  I really enjoyed at the opportunities I got to interact with clients at my last job, and I even got a bonus and a letter of appreciation from the CEO for this.  Unfortunately, they didn't have a role that would match my new focus, so I wanted to move to a faster paced firm that could offer me more of these opportunities.

A response like this shows a positive attitude while simultaneously mentioning what you're interested, and what your relevant experience is.

Ask Gayle: I am a low-level programmer. Can I get a job at Google?

Hi Gayle, I am desperate about getting a software engineer job in only Google. My dilemma is that I have worked only in RTOS (e.g. WinCE) System Software Domain in all of my 6+ yrs of overall work experience in big semiconductor companies e.g. Qualcomm, Marvell, and I have no experience in web companies.   Do you think there might be any chance for me to get a job in Google?

Thanks Avi

Google does occasionally look specifically for low-level programmers.  Scour the job openings and see if you can find something that fits your background.  However, most job openings at Google are just general "software engineering" positions, which leads to two questions:

1. Can you get an interview?

2. If you get an interview, can you get an offer?

As far as the first one, quite possibly.  You have some big name companies on your resume, and that gives you a lot of credibility.  The only drawback is that you may not have much object oriented experience.  You could try your luck applying as-is (it'll help if you can find an employee to refer you), or you could do something to boost this experience.  Is there an open source project (preferably one with Java) that interests you - one that would give you the much needed object oriented design experience?

With respect to the second question, it's really about how much you prepare for your interviews.  Read up on design patterns - the formal names aren't important, but it might be useful for you to see different ways of designing things.  Practice interview questions using object oriented design, and preferably Java.  Be aggressive about writing very clean code and designing classes and structs to hold the necessary data.

Google is desperate to hire great people, so with a bit of preparation, you can get a job there.  Good luck!

Ask Gayle: What can a student now do to prep for a programming position?

Hi Gayle, I am an international student from India and I just finished my BS in EE with minor in computer science and will be moving to CMU for my MS in computer science this coming fall.

Being an EE student, I am not so proficient at programming. Since I will be starting my MS this fall , I would like to obtain good internships during my MS which I can convert to a relevant full time positions.

My problem is that I am not sure what minimum background and knowledge is needed before I go to these interviews or be selected for them. Secondly, I am not sure which language am I expected to be really good at?  Do I have to know C inside out?  What else should my resume have to ensure that I land up an interview?

Thanks

PY

I would focus on three things:

1. Learn data structures and algorithms

Your coursework should hopefully be sufficient for this, but I'm not super familiar with your program.  Sometimes schools offer two MS programs - one for CS-undergrads, and one for non-CS undergrads.  If this is the case for you, and you're in the MS program for people without a lot of coding experience, make sure that your algorithms course is truly rigorous.  This should mean covering most of the CLRS algorithm textbook.

2. Learn object oriented programming (with Java or C++)

Formal design patterns aren't especially important for interviews, but it can be useful to see a lot of different ways of representing data.  The important thing, really, is to get out of the mindset of "throw down any code that works."  Your coursework might not cover design patterns, so here are two books: Head First Design Patterns and Design Patterns: Elements of Reusable Object-Oriented Software.

Practice these in either Java or C++.  C is generally less important.

3. Complete at least 3 "meaty" projects

Seek out the courses where you'll be doing some large programming projects.  You can also work with professors on their research, but make sure that (1) you'll be doing coding and (2) you'll really "own" a chunk of it.  You'll not only learn a lot from doing coding projects, but this will also give you material that you'll put on your resume.

As you go through school, keep in mind these resume tips for software engineers.  It's never too early to prep for your interviews!

Free Drinks, Free Lunch, Free Everything: How much do company perks really matter?

Microsoft was famous for its free all-you-can-drink sodas, until Google stepped up the game and offered free lunches (and dinners and breakfasts too). But, as a reader recently noted, do these perks really matter? My personal opinion: yes and no.

No, most perks don't really matter.  A free lunch does not fix a bad boss, and bringing your dog to work does not make up for a lack of career growth.  Don't be too fooled by these sorts of perks.  Instead, ask yourself, what is the dollar amount that this is worth to me? Free lunch, for example, is probably worth just about $2000.  Rather than being swayed by some company offering you free lunch, just pretend you are making an additional $2000 in salary.

However, some perks - the less flashy ones - can make a real, substantial difference in your life.  Microsoft's "We Pay For Everything" healthcare plan is incredibly important to some people.  Or, flexible work hours might be very important to other people.  These are the perks that you should really evaluate.

With all that said, while perks may be a flashy recruiting tool, perks are also often a reflection of the culture or history of a company.  In Amazon's case, its lack of perks are likely a reflection of its truly being a retail company - not a software company (and of its less profitable history).  Is it really fair to judge them by the same standard as Microsoft and Google?  However, in other cases, a company's lack of perks might suggest that it doesn't value its employees the way that its competitors do (or that the company isn't as desperate to recruit people).

In the end, no, it generally doesn't matter that much which perks a company offers.  You can assign a financial value to each perk by asking yourself, how much would you pay for this perk?  Remember that each person values each perk differently, and the dollars you assign might not match the actual price tag.  And that's ok.

Assign the financial value of a perk, and then look beyond all that.  Ask yourself, why is the company offering these perks - or not?  In the end, the culture of a company will make a bigger difference in your happiness than a few thousand* dollars.

* A few thousand dollars can obviously make a difference to some people.  I'm assuming here that we're comparing jobs at major tech companies, where the difference between $75k and $77k probably doesn't change your lifestyle.  If you're making considerably less or have a unique financial situation, then it can absolutely matter.

Ask Gayle: My interviewer misled me. Can I argue?

Dear Gayle, I interviewed with a major tech company and I was asked a tough question. I started to think of a brute force solution and the interviewer said that brute force is fine.  I began to write the code and before I was even finished, the interviewer began to bombard me with questions.  His questions then led me to a better solution.  I also noticed later that I had some bugs and other mistakes in my code, but these seemed fairly minor.

I feel that he misled me in telling me that my initial solution was fine, and I ended up getting a reject as a result.  Do I have any chance to put up an argument?

~ Frustrated, WA

There's a lot going on in this question, so let me break this down.

Did your interviewer mislead you in telling you that brute force is fine (when it really wasn't)?

It is possible you got a bad interviewer who didn't direct you properly.  Bad interviewers do exist, even at the best companies.  I suspect that your interviewer was probably looking for whether or not you would notice and look for a more optimal solution, or if you would be satisfied with a "good enough" solution.  Depending on how far along you were in your interview, the interviewer may also have been thinking "ok, we don't have much time, and I want to make sure I see this candidate's code.  Let me encourage him to just get on with it."

Did this cause you to be rejected?

Again, very hard to say that this really caused the reject.  First, typically about 3/4rds of candidates are rejected at each stage, so it's almost like you have to do things really, really right to not get rejected.  Second, it's unlikely to be any one issue that caused a reject.  As you noted, you had some bugs and other mistakes.  I'd guess that your interviewer's thought was more like "hmm, I liked this guy, but his solution wasn't very good, and he had some bugs in his code, and a few other mistakes."

Can you put an argument?

No.  In high school, did you ever try to argue a case to your principal that a teacher did something wrong? Did they ever side with you? Unless your teacher's actions were egregious, your principal almost certainly sided with your teacher.  This is much the same way. Whatever you say to your recruiter, he/she will almost certainly side with your interviewer.  You're more likely to spoil your decent reputation at the company, and it's just not worth it.

That said, there are times when you should not stay silent about an interviewer's behavior.  If they say anything or do anything offensive, speak up!  Or, if your recruiter asks for your feedback, then you are welcome to share it.

I'm sorry things didn't work out for you, but you're not alone.  Interviews are hard and, unfortunately, very random.  Most of my coworkers at Google admitted that they didn't think they'd pass the interviews the second time around.  Luckily, companies understand this and let you apply again in six months to a year.

Best of luck!