Google's “Director of Engineering” Hiring Test

To be fair, I've interviewed people at previous companies that had patents and 15 years at IBM on their CV and completely failed even the most basic system / coding questions. (fizzbuzz style).

There are a lot of people that read great on the CV but then it turns out that they mostly kept a chair warm and organized meetings over the last decade without actually retaining any technical knowledge.

Not saying that was the case here, but it happens and it's probably worth checking people on their stated qualifications.

I'd expect any technical candidate to be able to do at least a fizzbuzz-type question.

I had a candidate in a few months ago that was interviewing for Software Development Manager, so he got an initial phone screen and then a face-to-face with myself and another dev on the team he'd be managing. I was impressed with how little he knew about programming.

"Name some data structures." "What does MVC stand for?" "Name some design patterns" etc. All of which were unanswerable. Generally when it becomes clear someone was dishonest about their skillset, the ability to get hired for any position becomes impossible.

Because there are people applying for software engineering jobs that still can't answer those questions.

"Could you write out what an HTTP request and response looks like on the board?"

I'm really surprised at how many people can't do this. If you've spent five years developing web, surely you've had to look at raw requests, either debugging using netcat or with wireshark or just looking at the information in the Chrome/Firefox debugger?

"What's the difference between a GET and a POST request?"

"What is the difference between a statically typed and a dynamically typed language?"

I had one candidate try to tell me Java was dynamically typed and Scala was statically typed. It was for a Scala position. They also said "statistically typed" instead of statically, even after I corrected them.

-_-

You want a simple question that isn't common, but that shows how they break down a problem under stress. Example: you have an input with paragraphs at 80 characters. Write a function to return the same paragraphs wrapped to 40 characters. You cannot break a word and must maintain paragraphs.

Great design questions: a word problem (You have an autoshop with, staff and customers. Customers can own multiple cars. A staff member gets assigned to a car with a work order...) .. draw an ER diagram. This is actually a pretty low stress question. It should be straight forward. If someone draws a terrible ER diagram with lists in tables and no normalization, or unnecessary relationships (or you have to keep asking them to label 1-to-n/n-to-1 relationships and they struggle), you know they're not going to be good at designing database schemas.

Another great general knowledge question: "A user types in a web address into a web browser and hits enter. Describe what happens. Go into as much detail as you can." This gives people a change to elaborate as much as they can. People can talk about DNS, HTTP, load balances, HTTP request/response, cookies, load balancers, web apps vs static content...

Questions need to be geared to the job. You don't ask someone to draw an ER diagram if they're being hired to rack servers and setup VMWare. Likewise you don't ask a web developer to write a function to do matrix multiplication.

This type of coding exercise can potentially answer more questions about the candidate in two minutes than 30 minutes of softball questions about the candidate's past experiences.

I think that people who disagree simply haven't done much interviewing or haven't worked on a team with someone who couldn't do much more than copy/paste code from SO.

But could they at least tell you why quick sort was the best sorting algorithm?

And 95% haven't used netcat or wireshark. I wouldn't have either, if it wasn't for some particular work related to messaging.

They're able to develop reasonable line of business websites in spite of that.

I would be extremely worried if they were unable to answer about the difference between GET or POST, or the difference between statically and dynamically typed languages, so I agree with those.

Of course, a sample of one (anecdota) which is most likely the min of the distribution is always the worst way to judge a distribution, but this is still upsetting.

The results speak for themself. All the good applicants do it in no time, without hesitation and give a perfect answer and usually some style points on top. The ones who have second grade coding skills have always something wrong with it.

It's a good 5 minute test whether someone can code or not. It shouldn't be the only test, of course.

As always, this sort of question is a test of competence by proxy and there are usually outliers, but statistically speaking, I think you'll find a very high correlation between inept programmers and people who don't know the difference.

I have a follow up question, "What are the advantages of a dynamically typed language over a statically typed one?"

This one kinda exposes the "Java-zellot" side of programming. If you love Scala and you're applying for Scala position, you don't often think like this. Being able to think critically about the things that are harder in Scala, that would be easier in a language without strict type checking, is a another good way to gauge if people can think critically.

Hell, someone could be able to define MVC and explain how you would use it, but have no idea how to actually implement something using it for a given programming language.

Why should anyone remember what an http request or response should look like? Statically typed vs. dynamically typed language?

Fuck.

Are these entry-level positions or for someone with 10 years work-ex? A simple search on Google can tell anyone the answer of these questions, why do you expect people to carry an imprint of it in their memory? If the problem they'll work on mandates knowing these things it'd be pretty easy to solve with just one search. It is exactly questions like these that are worth kicking the host organization back in the butt.

Either your interviewing process is hilariously stupid or you're just spiking it up to boost the ego here.

if you hiring a house builder u would not ask him what a brick looks like right?

"OK, so you'd like to work here as a mechanic. What's the difference between automatic and manual transmission?"

"It's not fair to expect me to know that off the top of my head. If I need to know, I'll just do a Google search."

You're saying this is a bad question because it's too complicated? Am I missing something? It really doesn't seem more complicated than the paragraph question to me, but maybe I'm having a brain lapse.

You're gonna have a hard time drawing a comparison between a line of work where you build things and one where you fix things.

And then your non-engineer phone screener who's expecting the answer to match the scripted sheet will conclude that I don't know this "fundamental" thing and thus am unqualified.

Compare static with N tests, vs not static with N tests. In what case would the not static be safer?

The claim that "dynamically type language" allows code to more closely follows the business logic has merits. And you could follow from that to claim that type system could be causing more bugs (ie less safe).

I actually just sat down in a meeting with a dozen programmers, some of them with decades of experience, and half of them didn't know what functional programming was.

We do watch them work though so if they just copy and paste from stack overflow and they don't understand the problem, it's pretty obvious.

Learning to use wireshark or tcpdump is a power tool that does show whether you got more experience in understanding the lower levels, or stayed at requirements-and-tests. (Not necessarily bad, but a good "fork" to jump off from)

Yeah expecting many people to be able write out a complete http request from memory without a reference to look at. But the general structure of a http request is something so basic to web development that asking what the structure of a http request looks like isn't an unreasonable expectation.

Request line (method, uri), header(s), empty, body...

It's possible that he got frustrated, became condescending towards the recruiter, and the recruiter decided to screen him out.

There are plenty of companies who turn down candidates that are false negatives for various reasons. Author should probably not take that personally and just apply again.

Nope, more like "can you write out on the board what types of connectors are used in the car cooling system and in what order".

Your example shows that not every programmer has to know that.

CGI is also cool to learn about the workings of, since it almost seems too simple.

A previous employer had a sysadmin wiki. We call it Devops now, but I really liked working with the plain-text files of Dokuwiki there. Confluence is good for some things, but as a notebook of shell snippets and when to use them, it's not great.

But really, if an applicant needs to google to solve FizzBuzz, they don't have a firm grasp of the fundamentals. You're required to write one loop, a few if/then/elses and understand how the modulo operator works. Our jobs are much more demanding than that.

The problem with this is that a home builder/contractor will have a long list of references, and possibly examples of her work available for examination. Many engineers search for jobs while still employed, so they generally don't include as references co-workers and current managers. Further, if your employer doesn't allow you to open source your work, then you need to do open side projects to have any sort of real resume prospective employers can examine (and this is problematic since your day job may already take more than 40 hours of your time).

So, no, I don't need to ask a contractor if he knows what a brick looks like, but I do need to look at his references, look him on Angie's List, post to local message boards about his work. And, of course, I'm not an expert on home building, so it would be unreasonable to ask him questions about carpentry or framing.

The only code you can be sure isn't buggy is code that doesn't exist.

Sure I did.

Then I forgot most of the details because they didn't matter, and I knew I could look them up quickly if I ever needed to write a HTTP client/server for some reason.

It's a (sadly) useful screen. Even more sad when you realize how popular and widespread that particular question is.

Because you did: after that you have to provide a Host: <hostname>.

I once aced a geography exam because I happened to read up on the economics of Nigeria just before I took it. By sheer luck, there was a question about Nigeria in the paper.

If I'd read about Zimbabwe instead I'd have been screwed.

Neither possibility provided much insight into my competence as a geographer.

Even if a job spec needs specific knowledge of key facts, you can't generalise from pass/fail memory questions to broad spectrum competence, or lack of it.

If a candidate has no idea what an HTML request is, that's one thing. If they know damn well what a request is but can't list all the elements in a stressful interview while you're staring at them, - because in fact they spent the last year working on database code, and the API stuff was the year before that - that's something else entirely.

It's a hypothetical no-go! Every person, even the fourth grader knows the number 4. So why ask a question that measures their ability to remember 4, say 4 or show that they know 4.

> I don't see how a programmer could be remotely competent without having been exposed…

Share this link with them:

http://stackoverflow.com/questions/1517582/what-is-the-diffe...

Invest in people and people will invest back in your business. Interview process that I follow at my workplace has just one goal to assess: whether or not it'd be great to work with this person and spend over ~50 hours per week with them.

If you require using real, compiler correct language in a coding exercise, and the problem is not trivial, than allowing search is more than fair.

But the point of Fizzbuzz is being such trivial problem that it really should not require nothing more than an understanding of basic programming logic and constructs.

In my (limited) experience, there were instances where the candidate could not even decide on a programming language to use, I told them to use pseudo-code and they still flunked horribly.

Aside from that, Fizbuzz is rarely a dealbreaking task in itself, it tends to correlate pretty well with the overall performance, I would be surprised seeing someone failing fizzbuzz and excelling in the rest of the interview (once again, in my limited experience).

You need two newlines to finis the request, plus the HTTP 1.1 standard requires clients to send a Host: header for all requests.

Not saying every interviewer would care about that in an early screening process.

There are a number of basic items that a competent programmer needs to know off the top of his head. If they had to google for every single item, then their productivity goes down the drain and so does the entire team's productivity. You should fix your hiring.

Asking "wtf did you just do" is responsible for probably 1/5 to 1/4 of the professional knowledge I have today. It's sad that many people ignore that people will often teach you their little tricks if you ask.

Absolutely. Last time I went through trying to hire people was about a year ago. Easily 90% of the applicants we saw were completely unqualified. You have to have a way to weed them out.

Absolutely! This is super super important. Fun to work with, not annoying to waste time with.

> know nothing about computers

It's sad that you think this way of people who couldn't answer your questions at the expected level.

> Or are there actually more criteria than you let on here?

Yes! One way to know if they're any good or not suitable is by giving them a problem statement like so:

'Design X, feel free to choose a language that's suitable for this problem', and then may be proceed to hint with: 'You might want to look at advantages of Static versus dynamic typing'… and then let them ask whatever questions they want to ask or read up or search or start implementing whatever.

Observe what they do -- and how fast can they get to the decision of what language and why. And how to make X (break down of steps) or if they can dive and start making X there itself. Note, if they had theoretical knowledge of what you seek during an interview it will work to their advantage naturally. Or sometimes not.

Of course, this process may not work for you as it does for us -- therefore seeking direct answers about static vs dynamic language may not be such a bad question after all (I get it), but expecting people to accurately remember what an http request or its response looks like may not be fruitful at all. It can throw good people off guard and ruin the rest of the interview for them.

  * The object returned no longer has member/property x, it is obtained by other means;
  * The endpoint returns list of such objects.

Fun thing: in the second case if your code manages to convert input list to a map and assign one returned object to a key that coincides with the removed property and map access looks syntactically the same as property access (a very specific set of assumptions, though), the bug can butterfly quite deep into the code before manifesting :)