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.

Most people think through if they want to live in the city, but what people forget to think about is the long term impact of living in a particular city.

Suppose you’re graduating college and you get an offer from Google’s Irvine CA office. That’s fantastic. You must be really excited. Great company + great weather. What’s not to love?

But what are you going to do in, say, five years? Odds are good that you’ll want to leave the company, or at least consider leaving. Where do you go?

And there’s the problem – you’re sort of stuck. I’m sure there are other tech companies in the area, but how many? And do you want to join those companies? If you do, will you get an offer?

You may be stuck choosing between three less than great choices:

• Sticking it out at your current company for some indefinite length of time.
• Going to a less desirable company than you otherwise would have wanted.
• Leaving your friends and possible uprooting your family.

This is true for almost every field, but especially so in technology.

Even in Seattle, arguably the #2 tech hub in the US, has limited choices. If you’re a software engineer at Microsoft in Seattle, you have basically three other choices for major tech companies: Amazon, Google, and Facebook. Maybe you’ll get an offer from those companies, maybe you won’t.

The situation gets much worse if you’re not in the bay area, Seattle, or New York. It may still be worth it for personal and other reasons, of course, but that’s a tradeoff only you can make.

I’ve come up with these five skills that, I believe, virtually guarantee success in life.

1. Writing

This doesn’t mean you need to write beautiful, eloquent prose; in fact, if misused, that’s often a negative. Good writing means that you can communicate your point clearly and concisely. You need to be able to structure your thoughts and understand what information is and isn’t essential. And, of course, you need to be able to write with correct grammar and spelling.

2. Communication Skills

By communication, I am including not only public speaking, but also one-on-one or small group interactions. Like written communication skills, you need to be able to structure your thoughts and understand what’s important. You also need the confidence to not get nervous in front of large crowds. Many people struggle with the last one, but fortunately, practice will largely solve this.

3. Confidence

Confident people do better in life. You don’t need to think you’re better than everyone else; you just need to believe that you are good enough to achieve what you want. Confidence will help you push for your goals and to ask for what you want in life.

4. Quantitative Skills

Being able to sort through information and make data-driven decisions will help you make better decisions. It will also set you apart from the crowd, as far too many people are intimidated by numbers.

5. Programming

This isn’t essential, but it is a skill that, if you have it, will help you tremendously. The U.S. has a severe shortage of qualified programmers. If you’re smart and can code, you’re basically guaranteed a great job out of college.  But if you don’t want to dedicate your life to coding (and even most Computer Science graduates don’t), knowing how to write code will still be a very valuable skill. Businesses are increasingly built on technology. If you can understand computers at a deep level, you will open yourself up to fantastic jobs at tech companies — and many, many jobs elsewhere.

What do you think? What skills do you consider to be the most valuable?

• Alpha Nu Scholarship Recipient (2010).
• 1st Place, Innovation Award (2009).

Although the second bullet is a bit better than the first one, both are fairly meaningless. The reason is that both are totally “unquantified.” I have no idea what these awards really mean.

Awards can be a selling for your application because they show at least one occasion where you were, objectively, better than everyone else. So, your job is to show that this is what that award means.

Make it meaningful!

How do you do that? Tell the reader these details:

• How selective is the award? It’s great that you won an award, but there’s a big difference between placing first out of 5 teams and placing first out of 500. Tell me how many people you beat out to get that award (percentage or absolute numbers are both fine).
• What is the award for? I have no idea what the John R. Robertson award is. Tell me why you won the award. Was it academic achievement, test scores, a business plan, etc?
• What did you win? A good way to make an award “meaningful” is to tell me what you won. If you received a $50,000 scholarship, I know you must have done something pretty cool to get that. They don’t just throw $50,000 at anyone.

So next time writing you’re resume, I want to see this instead:

• Alpha Nu Scholarship Recipient (2010). Selected out of 1,500 students to receive $50,000 academic scholarship from Greenberg Bank due to outstanding academic performance and community involvement.
• 1st Place, Innovation Award (2009). Awarded most innovative senior project (out of 120 senior projects) by student and faculty vote.

This Is About More Than Just Awards

Before you assume that this doesn’t apply to you (because you don’t have any awards), remember this is about more than just awards.

Ultimately, this is about how you quantify what your accomplishments, and it’s not always as straightforward as it might seem.

Suppose you wrote this on your resume under your projects section:

• Snakes and Ladders (iPhone App): Built iPhone game for [...].

That’s neat and all. But it’s not nearly as good as this:

• Snakes and Ladders (iPhone App): Built iPhone game for [...]. Downloaded 10,000 times and received rating of 4.7 out of 5.0.

The above one shows that it wasn’t complete junk, because it got good ratings and a decent number of people downloaded it. But is 10,000 downloads great, or just decent? I don’t know – and neither will the person reading your resume.

An even better way of doing this is if you can put it in a way that other people will understand. For example:

• Snakes and Ladders (iPhone App): Built iPhone game for [...]. Downloaded 10,000 times and received rating of 4.7 out of 5.0. Ranked as #2 game on iPhone App Store in June 2011.

So remember: make your accomplishments meaningful.

What other mistakes have you made with your resume? Find out with CareerCup’s Grade My Resume service. Get your resume checked for the 15 biggest and most common problems. Learn more.

I had 5 interviews for a software development position. 4 went really well – I got all the answers perfectly. I bombed the fifth one though. I don’t think I got the best solution, and I made some mistakes in coding. What are my odds of getting an offer?

Let’s step back a moment.

First, your interview performance is nearly impossible to judge. So when you say you “bombed” this interview and did “really well” on the others, you don’t know that – trust me.

Second, I find it hard to believe that you were basically flawless in all your other interviews. For that to have happened, you either had incredibly easy questions or were one of the best candidates that anyone has ever seen. In my interviews at Google, fewer than 1% of candidates answered my moderate-to-hard difficulty questions “perfectly.” Odds are, you made a lot more mistakes than you realize.

Remember that you’re judged relative to other candidates (which is why your interview performance is nearly impossible to judge) and on things like:

• how quickly you arrive at a good solution
• how optimal your algorithm(s) are
• how you discuss the trade offs between the different approaches
• how many bugs you make in your code
• how easily you discover those bugs
• how you fix the bugs

All of these factors are qualitative (and relative to how other candidates do them), not binary “correct vs. incorrect” factors. I have never, ever asked someone a question like, “Design an algorithm to …” and reported that a candidate got the question “correct” or “incorrect.”

So when you say you got a question “correct,” it doesn’t make sense (unless it was a simple factual question). You can say you did an interview flawlessly, but that would mean that you immediately spit out the optimal solution to a problem (and somehow you knew it was optimal), coded it in completion without a single mistake, and checked for bugs anyway but there weren’t any. Did you? It’s possible, but it’s far more likely that you made a bunch of mistakes along the way.

And that’s okay – everyone makes mistakes in interviews. And you can get an offer while bombing one interview. But again – you don’t know which one you bombed, if any. I’ve see a lot of candidates say that they did “bombed” in one interview, when in fact, that was their best interview of all.

Cute things like Ninja make me think I’ll be working with idiots and hipsters. [Start-up Employee]

Personality is cool, but “ninja” is such an overused term that it decreases personality rather than adding it. [University of Washington Student]

I dislike “programmer” because it implies work consisting of only programming, as opposed to design and algorithmic aspects. “Code ninja” is a beautified form of “code monkey”, which is bad for the same reason as “programmer”. Titles like software developer are more general and more neutral. [Student]

The company shoudn’t force cool on its job descriptions. [UC Irvine Student]

Ninja / Rockstar / whatever just sounds immature. Have you ever heard someone outside of technology refer to themselves as a Ninja? [Anonymous]

Ninja and Expert are sometimes outside a new grad’s reach! So I hate it! [NC State Student]

I conducted a survey of 200+ software developers, asking them their thoughts on different titles / labels in job descriptions. Each person was asked to rate the following titles on a scale from 1 to 5, with 5 being the best.

The specific question was this: Suppose you see “we’re looking for a _____________”, do you like it or hate it (the title / job name)? 

• Programmer
• Software Engineer
• “Ninja” (Code Ninja / Java Ninja / Ruby Ninja, etc)
• “Expert” (Java Expert / Ruby Expert / C++ Expert / etc)
• Software Developer

People were also asked for their gender, country (US, India, or “Other”), and profession (Professional vs. Student). Note that the last of these was added after about half the responses had been submitted, and not everyone chose to answer these questions.

So what happened?

75% of coders like the term Software Developer in a job description; only 25% like “ninja.”

Cool terms like “ninja” do not impress – anywhere.

In the above graph, I've simplified the data to just "love" and "hate." "Love" = 4 or 5 rating. "Hate" = 1 or 2. The main (purple) bars indicate the overall rating, with the colored lines indicating the rating for a specific subgroup (US, India, Women, Students, and Professionals).

Average scores reported on a scale from 1 to 5

Percentage of people reporting each of 5 scores, on a 5-point scale, across entire population. 1 = Hate It. 5 = This is the Term I Prefer.

Another way to look at this data is this: For every person who hates the term Software Developer, 11 people like it. For every person that likes Ninja, 2 people hate it.

Why are some titles liked more than others? 

The titles tell you something about the job itself.

• Software Engineer / Software Developer: As the official title given at company, these terms are largely neutral and synonymous with each other. They’re not “flashy,” but you can’t really be turned off by them. It is what it is. Only 8 – 11% of people reported hating those terms, and in almost all of those cases, there was something wonky about their response (giving 1s to all or almost all of the choices, etc).
• Software Developer is just slightly preferred over Software Engineer in India, but there’s little difference in the US. Software Engineer may have more of a “science-y / advanced” connotation to it, while Software Developer sounds more practical / real-world. The data here is really too close to tell much more than it doesn’t matter much.
• Expert is preceded with an expert in something – java, rails, etc. If you’re looking so much for someone who’s a Java expert, it suggests that you might be one of those people who doesn’t understand that a good engineer can pick up a new language quickly. And if you don’t understand that, do you really respect engineers? Is your current team talented?
• Programmer sounds like code monkey. Developers are advised not to call themselves programmers, and you shouldn’t call them that either.
• Ninja is perhaps the most debatable term. Not surprisingly, it had the highest variance in responses compared with any of the other job titles. Some people love it; it’s the new hip term. For precisely that reason though, some people hate it. It’s too trendy, and it sounds like you’re trying to be cool. You’re the kid wearing the clothes that some magazine told you was “in style,” not realizing that everyone else is looking at you kind of funny. But hey, some people still think it’s cool.

• Women are statistically more likely to be turned off by job descriptions featuring competitive language (note: “competitive language” is not the same thing as “competitive jobs / careers”). And you don’t get much more competitive than terms like ninja and expert. In fact, here’s a great story: “In 2006, GNOME received almost two hundred GSoC applicants – all male. When GNOME advertised an identical program for women, but emphasizing the opportunities for mentorship and learning, they received over a hundred highly qualified female applicants for the three spots they were able to fund.”
• Students and Professionals differ little, interestingly, with the exception of their feelings on ninja. The relative youth of students probably makes them more accepting of hip / trendy terms.
• India is considerably more accepting than the US of the terms ninja and expert. I’m not an expert in Indian culture, but this might suggest a greater focus on competition. India also doesn’t like the term Software Engineer as much. Anyone who knows a bit more about India care to explain this?

The problem with joining a start-up when you graduate is that most start-ups fail. Sure, if you get into FourSquare or Twitter or Facebook when it’s young, that’s great. But no one really knows what next year’s hot start-up will be.

When you join a start-up when it’s still young and unknown, you’ll probably be jobless in a couple of years. That’s just the reality of start-ups. They fail more often than they succeed. And since anyone can get a job at a start-up, your now-prior job offers little credibility. No one looks at your resume and says, “ooh, this person is probably a great engineer since they worked for UnknownCompany.”

On the other hand, when you work for Google, Amazon, Microsoft or Facebook (and other top tech companies), that credibility will stick with you for a long, long time. Having “Amazon, Software Engineer” on your resume will establish a minimum amount of credibility in a way that “Failed Unknown Company, Software Engineer” will not.

You don’t need to stay at BigTechCompany for long. One year, or even six months, is long enough to establish that credibility. (In fact, if you want to join a start-up, make sure you leave quickly – or if you stay, you’re staying for a very good reason. It’s really easy to get sucked into the nice, cushy jobs that big tech companies offer.)

That technical credibility will help you get a job with the really hot start-ups, or help you recruit people when you found your own start-up, or help you get funding for your start-up.

Isn’t 10 or 20 years of technical credibility worth pushing off your entrepreneurial goals for just six months? I think so.

As someone who has enjoyed success self-publishing and professionally publishing, let me tell you: self-publishing is so much harder.

Calling self-publishing easy is like calling founding a business easy. A lot of people can do the paperwork, but being successful in it is much, much harder.

And this is the biggest thing that everyone needs to realize: self-published authors are entrepreneurs. As such, authors need to ask themselves the same questions that entrepreneurs do:

1. Is there a big market?
How many people want your book? Your book won’t sell well if it’s too “niche.”

2. Is there good demand in your market?
Just because people “need” your book doesn’t mean they actually want it. Is your book useful to your market? How useful? Are they already looking for something like yours?

There is a tradeoff between the size of the market and demand; the bigger your market, the less “perfectly suited” it is for any one person. My book, for instance, is only for software engineers and would be considered very “niche.” However, because it’s a small and focused market, it outsells any of the “general purpose” interview books out there.

3. How much competition is there?
You should be aware of the existing competition for your book. If there are a ton of other books out there, you need to hope that you’ve written a really, really good book (and that’s hard!).

Remember though that just as too much competition is bad, too little competition is bad too. There’s often a reason that there isn’t competition, and it may mean that there isn’t actually a big market out there.

4. How will you market / promote your book?
You can’t expect to just write a great book and suddenly have people desperate to buy it. You need to think about how you are going to promote it. Do you have a popular and relevant website or blog? Do you train people? There are many ways to promote a book or product, and you need to find one that works well for you and your market.

5. What is the minimal viable product?
In start-ups, there’s a concept of the “minimal viable product,” which is the quickest product that you can build that basically solves the customer’s needs. It might not be fully functional and do everything that they want, but it fulfills their most pressing demands. If you release with that first, it will help you get customers and to understand what customers really want.

The same concept applies to non-fiction / business / technical / reference books. The 5th edition of Cracking the Coding Interview is a 500 page paperback book. The 4th edition was “only” 300 pages. The first version? It was a 20 page PDF.

The first edition was the “minimal viable product.” It wasn’t perfect – in fact, it was far from perfect – but it was enough to establish that there was a good demand, a good market, and a good reason to continue to develop the book.

The wonderful thing about print-on-demand services like CreateSpace is that you don’t have to spend a lot of time writing the “perfect” book so that you can do a 3000 copy print-run. You can write the “minimal viable book,” and then write a bigger and better version once you figure out that lots of people want to read it.

6. Are you willing to really, really work for success?
Self-publishing is hard. Really, really hard.

In fact, in many ways, it’s harder than founding a company. At least when you’re founding a company, you have loads of entrepreneurs to turn to for advice about marketing, promotion, hiring, building a product, and so on.

Who do you turn for advice about how to self-publish a “serious” book, when all the advice is written for authors writing vampire fiction who are only self-publishing because they can’t get a “real” publisher? (Side note: I may set up a discussion list for self-published authors, if there’s enough interest. Sign up here if you’re interested.)

Self-published authors have to do everything themselves, from cover design to editing to marketing and promotion. It’s hard, confusing, and takes more time than you can imagine.

They are a lot of rewards to being a self-published author, but, like any entrepreneur, you’ll have to really work for it.

Never forget that. Success is a challenge for any entrepreneur – and you are an entrepreneur.

Fundamentally, their core frustration is not a political one, but an emotional one. They’re sick of feeling ignored by the wealthy and they want to be heard.

And heard they are – on every last demand. Even the crazy ones.

Let’s take a look at some of their most popular demands, according to the votes on OccupySeattle.org.

Allow Everyone to Vote (136 votes)

Who is this for? Ex-cons? Immigrants? Children and teenagers?

Corporate Accountability (495 votes)

Corporations are already overflowing with paperwork. It’s one of the things that makes it really hard for “regular people” to start a business. Maybe more accountability would be good, but they need to say what exactly this means.

End privatization of the commons (natural resources, education, healthcare, etc.) (139 votes)

The US already has both private and public education. And private education is, without doubt, far superior to public education. Would they like to terminate private education? Why? And if that’s not what they’re talking about, what does this mean?

Tax the rich and big business (285 votes)

Obviously the US already does. The rich and big businesses pay a much greater percentage of their income than the poor do. Would they like to raise the tax rate? To what? For whom? Or end some of the tax loop holes? Which ones?

I’m sure there are answers to these questions. But is there a consensus on these answers? And who will deliver the answers, when there is no central voice?

So what will happen to Occupy?

#1 They’ll get a voice, but they won’t get anywhere.

Everyone has gripes about the country, so they’ll get plenty of members. They may even have politicians pander to them – their sheer numbers will do that. But how can anyone meet their demands, when there’s no indication of what’s important or how they would like Washington to “end the greed”?

#2 The crazies will come – and will belong.

As long as Occupy lacks a focused voice and set of demands, every demand can be “one of theirs.” There’s no one to disavow the really crazy demands, and there’s no methodology by which to disavow them.

And if you give the media the choice of talking about the boring ol’ reasonable demands and the crazy ones, guess what they’ll pick?

#3 They’ll be the left’s Tea Party.

Sure, they’ll say they aren’t affiliated with a particular political persuasion. Tea Partiers say they aren’t affiliated with the Republicans. But when the vast majority of their members are part of a particular political party, people won’t distinguish.

Occupy will fuel Republicans’ worst fears about Democrats (even the Occupy logo looks communist!) and will hurt the democrats. And let’s face it – the vast majority of folks in the Occupy movement would much rather see a Democrat in power than a Republican.

It boils down to this: Occupy needs to learn what every business leader already knows. To effect change, you need to have a central voice and focused, reasonable vision. Without that, you’re just a bunch of kids throwing a temper tantrum.

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.