My Google Interview and Lessons Learned

Languages I don't know, but paradigm and domains is godsend for your brain after you're over the mental uphill. After going into FP and now reading about Prolog a lot, a huge lot of ideas are blending in few concepts, recursive space exploration, trimming, continuations, graph theory ...

I wonder if it's what is expected from college graduation (we saw all these topics there after all) or if I'm late to the game but it's quite a joy nonetheless.

In his case I think the decision was correct. Once you have at least a year of experience in one language as a fresh programmer, you understand the quirks, paradigms, design patterns etc. You have a mental model of what a programming language looks like so you can evaluate other languages from that standpoint.

Once that experience is there, then yes, I agree that its usually not difficult to learn a new language.

That may be true, but I languages can be taught and learned on the job, and frequently are. When giving an interview, you're generally more concerned with processes, how the person thinks and solves problems, how they learn on the fly, etc. In each interview we give, we generally set them up for JS and PHP (we are a PHP shop), depending on the question but also give them the option of switching to a language they are more comfortable with. We can teach you PHP relatively easy; I came in with no PHP experience and was able to start building in Silex in under a month. What we care about is understanding basic architecture, database interaction, OOP principles, some design patterns, etc.

So I think his choice to stick with what he knows and focus on learning algorithms was a good one. He could learn Java or Go or Ruby prior to the interview and then find out that he was placed on a project developing in Python, assuming he took the job. Languages are generally easy to learn and teach; best practices, algorithms, design patterns, etc. are what's hard.

True story.

But fact is: JavaScript the opposite of a small little niche.

Not because you can do everything with JS (which you probably can't) but because a few things you can do with it are considered rather valuable at this moment.

Switching to a different language isn't that big of a deal for a advanced programmer.

I can't speak to the trend, but it's worth considering where these "Javascript people" came from. For example, I'm currently a Javascript dev. I learned rudimentary C, C++, Pascal, and a couple of Assembly languages in high school/college, but quickly got into Perl (and the Web) for my job. After several years of developing in Perl I learned Java to show the execs looking to do "enterprise" development that I was a team player. I hated Java, and when the chance came to switch, it was going to be either Python or Javascript, and Javascript was something I had picked up some experience with, so it was the first one to get me hired. I'd consider my experience to be fairly familiar to most full-stack or backend developers.

In contrast, I run into a lot of frontend developers that came from the opposite direction: HTML, then CSS, then Javascript. Their relationship to different languages and how it can be useful to their skillset is completely different from mine. If they are uninterested in learning any other language, it's likely because:

* They have no experience to say it will be useful to them, since they are planning to continue to develop in Javascript for the foreseeable future. * The other "languages" they know (HTML & CSS) are NOT helpful in their JS skillset. So by extension, they have experience teaching them that learning other "languages" isn't helpful.

I'd be skeptical too if someone that didn't code in my language of choice was saying that I should expend effort when my experience says otherwise: it sounds too much like an ivory tower someone speaking pompously.

Now, in my case, I DO know other languages and I know how they can benefit me. (Even language experiences I hated, such as my 5 years as a Java dev, were certainly instructional and useful in my current practices). But that's BECAUSE of my experiences, not DESPITE them. So I can see how someone with a different experience would respond differently. (Heck, I tend to look down on all strict-typing languages because of my Java experience, despite hearing from others that Java is not a great example to learn from).

So the 2 programming languages I am comfortable at are Ruby and JavaScript (which most boot camps teach). I am familiar enough with Python and Java to understand and write code, but wouldn't feel comfortable taking them on for a Google interview. And as for Ruby, I don't see myself using it professionally in the future, so it made sense to double-down on JavaScript. It definitely positively impacted the JS code that I write for work.

Which HR is most unlikely to allow, because of the PR and legal risk involved.

They're much happier with a recruiter giving a liability-free, if vague answer.

Google gave me the answer "Unfortunately, we can't provide you any feedback from the interviewers." A couple weeks later, they sent me a questionnaire for me to provide them feedback.

I suppose that if I'd made notes of each interviewer's name, I could've taken a guess at their Google e-mail addresses and tried to contact them directly, but that's definitely not something they would've made easy for me.

I have one, and only one, expectation from companies after an interview:

Please respond by the time you say you will, more or less.

It is amazing how many companies seem to be "unable" to come through on this very modest expectation.

Much of the interview process is used to determine if the candidate can program a computer at all. It's pretty obvious in the opening minutes if I ask you to write out a simple function in your chosen strong language (such as strlen, if you said C) whether you can or cannot do this. If you can stand there and write out something like:

  size_t strlen(const char* str) { [return something] }

Then at least I know that you've ever programmed in this language before, which sets you apart, strangely enough, from 95% of the applicants. I won't even care if you write the return type as int instead of size_t, as long as you're obviously aware that every function declaration must have a return type (or whatever the requirements of your language might be).

From there we can start talking about graph traversal or whatever, to determine what you know about complexity analysis.

It's really not about "production-ready code" but fluency. When you speak your native language you don't constantly bumble and make errors and leave out important words. It should be the same when you write code in your favorite programming language, and whether you can or cannot do so becomes readily apparent in technical interviews.

That's not a great example. There's a six week bar exam course that most law graduates take because law school doesn't do anything to prepare students for the bar exam. Take any reasonably intelligent person with strong written English skills, have him take one of these six week courses including doing all the homework, and he'd likely be able to pass the bar.

Practicing law is a different story. Although a significant percentage of law school has very little relevance to the day to day practice of law it would be an exaggeration to claim that law school doesn't do anything to prepare you for practice as I claimed for the bar exam.

lol never heard of Barbri huh

Except I never approached Google. They approached me. They sent me an email with a header that said "You are app-solutely fabulous." (I know, so dorky it's suspicious) Do you think it's arrogant, disrespectful or crazy for me to take on the challenge head on? I learned a great deal from the process and I'm certainly not forbidden from interviewing again in the future. But this is just my approach to things.

A company like google has the resources to basically just make their interview an IQ test with the assumption that they can throw smart people into any role they need them in.

Depends on how the whiteboard is meant to be used.

It must be perfectly fine if it's meant to draw figures and overall ideas about the solution. That's what whiteboards are for. Sometimes a picture's worth a thousand words, and drawing diagrams or illustrations is frequently indispensable for actually solving a complex problem (as opposed to having a picture in the head, or described in writing).

But I'd say it's borderline offensive to ask a person to write any realistic code (i.e. not very-high-level pseudocode that's more of a human-readable notes than something for a machine) on a whiteboard.

Never been to Google, so no idea what they ask for.

I concur with you. I do not have any allergy towards whiteboard questions. Couple of whiteboards is reasonable, but five of them seems totally unnecessary.

Google, and the other big players, will continue doing this, as long as people keep lining up to their doors in droves. When you literally have the pick of the litter, you can do whatever you want.

I've talked to a research scientist at facebook who commented on this exact issue. They've debated this, the issue is that architecture, past experience, workflow are all things that can be taught to anyone.

Google and similar companies aren't in the business of hiring anyone who can just learn anything. Given enough time anyone can develop skills to be a programmer. However, google is in the business of hiring people who are intellectually superior. People who can do things that can't necessarily be taught.

You complain about 5 whiteboard problems because most likely you won't be able to solve 5 whiteboard problems. This does not mean you're a bad programmer. However, the guy who can solve those problems without an issue has a higher probability of having higher intelligence and better programming skills than you.

I don't see the issue. Coding on a whiteboard is more about demonstrating your problem solving ability, not your raw knowledge of programming. If they ask you to implement something like a maze solver, having the exact answer seems less important than communicating the steps needed to create such a solver (e.g. making sure you truly understand the question, taking note of possible bottlenecks or corner cases, having an 'obvious' solution and proving why it's slow/wasteful, etc.).

That being said, everyone knows you need to have a solid understanding of data structures and algorithms to be seriously considered, but I don't think Google is necessarily looking for software prodigies.

> But maybe part of the interview could be spend talking about, you know, architecture, past experience, workflow, etc.

Google does to do that for many candidates, but if you're a recent school grad, you probably don't have as much past experience to talk about, so the interviewer will instead tend to focus on coding questions.

Basically, the longer your work history is, the more questions you'll get about what you have done versus demonstrating what you can do.

Nobody cares about your experience or preconceptions about architecture because your experience will be pretty much irrelevant at Google which uses almost no third-party code and has a homegrown solution to everything, and because Google's software architecture is radically different from any other company's and you have to adapt to it, not the other way around.

Given that the acceptance rate for on-site interviews is under 20%, I'd say the vast majority of us who have interviewed actually underprepared.

Well, he wasn't offered the job. So, we'll never know how prepared.

Practice does help for these whiteboarding style questions.

I completed a bunch of https://www.hackerrank.com/ problems prior to my last set of technical interviews and it definitely helped keep me sharp. My day to day CRUD work is rarely helpful in that regard.

It looked like he was putting in 4+ hours per day. He implemented all of these algorithms in code. I think it's pretty amazing. It took me about the same amount of time to implement a B+ tree variant for my Data Structures class in college. Pretty impressive on his part. Either that or I'm unimpressive ;)

I guess it depends on the role. I've seen some pretty tough Google questions, but that was years ago.

"Talk about the three main parts of TCP/IP"

"Talk about what you would do in a new BIND configuration file"

etc