[angryredblock]

My response to such questions is usually along the lines 'Sorry, didn't realize I was interviewing for my ability to perform 5-second google searches.'

If 'getting the job' in that instance is the metric of success, then it doesn't work well at all, but in quality-of-life terms it's served me well.

[derekdahmer]

Being passive aggressive in an interview will never get you the job. Huge red flag on the hiring side. If you don'the like the interview style enough to not want the job, just politely leave.

[kafkaesq]

It's pretty clear that the commenter's intent was not to turn the interview around and get hired, with that remark.

[Crito]

Why be rude to the interviewer even if that is the case? What does such juvenile rudeness accomplish?

Is it genuinely offensive to be asked the complexity of bubble sort? If such a question causes you so much offense that you lash out involuntarily, then you have some serious personal problems to work out.

[kafkaesq]

Is it genuinely offensive to be asked the complexity of bubble sort?

Offensive, no. Just trite and tedious.

And more fundamentally, simply not indicative of the high quality, (genuinely) cerebral environment the interview subject, back in the original article, is looking for.

Why be rude to the interviewer even if that is the case?

I get that it's generally better to be polite. But when the same kinds of tedious and disspiriting (and sometimes downright condescending, and/or simply time-wasting) behaviors come down the interviewing pipe, over and over again... I can understand the temptation to bypass decorum, and allow a gut-level, emotional response to surface.

Being as while we might generally prefer to keep things professional -- we're not potted plants, either.

[eropple]

Literally two seconds on Github will prove out that, yes, I can write code. That means we should be talking about something substantiative rather than wasting my time. So turn it around: why should I respect an interviewer who isn't respecting me?

(I should note that, as a consultant, nobody ever asks me to whiteboard some code for them, despite often committing into their own repos and doing work that is no less important to them as a company. Almost like the hoop jumping is just some power-move crap on the part of the interviewer.)

[ubernostrum]

I've given interviewers a piece of my mind before. Frankly, most interviewing practices, even at places which allegedly are highly selective, boil down to 100% cargo-culting, and when I encounter that I have no issue with telling the interviewer that and hanging up or walking out. At that point in the interview I'm not there to validate their approach or make sure they feel good; I'm there to communicate to them what I know, and what I know -- from experience -- is how useless most of the common interview processes are.

[crdoconnor]

>What does such juvenile rudeness accomplish?

If a few more people were genuinely afraid of being humiliated for blindly cargo culting google's hiring practices it might go out of fashion quicker.

At least, that's my hope. Which is why I usually tease people for doing this (yes, that upsets them).

[Crito]

>humiliated

I think you need to pause, take a step back, and consider who is actually making an ass out of themselves in that situation.

[crdoconnor]

Put it this way: stupid people on a power trip can say some stupid things when they're angry at having their authority challenged. I've relayed those things word for word on to the non-technical boss when they subsequently come into the room to ask 'team fit' questions.

It's more effective when you're over-the-top polite when you set the trap with leading questions though.

Trolling gives me a bit of mild amusement in what is otherwise a dud investment of my time. The only people who seem to have a problem with that are people who have an exaggerated respect for authority figures (always unhealthy).

If, on the other hand, the interview process is obviously relevant to the job at hand and thorough I go out of my way to compliment the interviewer to their boss even if I know I failed.

[hueving]

If you're being passive aggressive, you've already signaled that you don't want it but you are taking the opportunity to point out to the interviewer how small-minded they are to make them reflect on the fact that they wasted their time as well as yours.

Politely leaving without saying anything doesn't improve the situation for anyone. These pop-quiz questions need to be stopped.

[angryredblock]

If you're happy to allow fellow humans to continue along a poor path, sure. I believe in establishing feedback loops and giving people opportunities to grow.

Tongue-in-cheek aside, of course passive-aggressive isn't the ideal path to improving interview processes. :P

[eveningcoffee]

I think you are missing the point.

If you do not know such things then how are you going to take them into account when you have to solve a problem?

[kafkaesq]

When have you ever needed to know the exact complexity function for bubble sort (beyond the simple fact that it's in a class well above that of any algorithm you'd typically want to use) in order to solve a real, actual work-related problem? Right there, on the spot?

That's the point of the "hate" behind these questions.

[varjag]

OK, I'll bite.

Point one, it checks if you understand the most primitive sorting algorithm out there. Pretty low bar assessment of your general CS knowledge.

Point two, it checks whether the candidate has understanding of computational complexity.

Now you might argue that you don't need any of that in the day job, but that's on you. If the interviewer wants to check you have fairly basic minimum of understanding of very basic CS concepts, that's a suitable question to ask.

[kafkaesq]

Do you see any problem with the idea that:

"Has memorized the complexity class for one particular, indisputably marginal sorting algorithm"

is equivalent to

"Has an understanding of computational complexity"?

Now you might argue that you don't need any [understanding of complexity] in the day job

That is quite clearly not what what said.

[varjag]

In theory there is a difference, in practice - none. People would at least know what that is (and hence have no problem gauging bubblesort complexity), or you'd have blank stare back.

Just wonder what would you suggest as an alternative, if you need to confirm basic algorithms proficiency and understanding of big-O? You inevitably arrive to an algorithm question, and bubblesort is as good as any.

[kafkaesq]

Or you'd have blank stare back.

Actually the blank stare means "What is this, sophomore year again? I can't believe anyone still cares about bubble sort."

Just wonder what would you suggest as an alternative?

Look at their GitHub/Mercurial account (which you've been ignoring all this time in your desperate search for something to nail them on, but if you would spend a second or two looking, you'd find is chuck full of algorithm stuff -- much of it way more intricate than bubble sort). And ask as many questions as you like based on some project you find there.

Or, pick a problem you're working on that's algorithm-related (but which you genuinely don't fully know how to solve). Use that as discussion material. What approach they'd suggest, given that the data are sparse / not evenly distributed, whatever.

You know, as if they were a peer. Not an interrogation subject.

[GFK_of_xmaspast]

I've had at least one point in my career where bubble sort was the right tool for the job.

[hibikir]

If I have to do a very careful performance decision on something as well trodden as a sorting algorithm, I'll walk to the bookshelves, pick up The Art of Programming, Volume 3, and let Knuth handle it for me.

As a software engineer, there are things I do all the time: Reading unfamiliar code and third party documentation, do some debugging (often based on logs), and try to write code that is well factored and thoroughly tested. I want to know whether any prospective teammate is good at those things for their experience level.

Interestingly enough, the general algorithm questions are easier the newer you are, and the less you know about all the topics I mentioned, because more often than not those are learned on the jobs, while the basic algorithms are learned in college. I end up reading papers on algorithms at work, but they are not algorithms that I expect to be general knowledge, and that I'd expect people to read on the job when they are applicable: How many candidates are going to be able to explain hyper log log, Paxos or Lamport clocks on command? Is knowing all of those three by heart a sensible pass/no pass signal? I for one don't think so.

[kafkaesq]

But that's the whole point -- it's a corner case.

And hence, kind of silly to use as material to grill people on.

[eveningcoffee]

I do not think that these questions probe some corner cases. Rather these probe the general knowledge about the field.

Bubble sort question probes the understanding about the complexity theory, hopscotch hashing about concurrent algorithms and CAP theorem about problems with distributed databases.

Naturally when these questions are not open for discussion and instead only a short answer is expected then there is in my opinion something wrong with the interviewer or with the company.

You have to understand that the other side knowns in fact nothing about you and I find these questions to be quite fair to improve the situation.

[kafkaesq]

Bubble sort question probes the understanding about the complexity theory,

It's just that, again, you're picking a very marginal example to do that with.

And more fundamentally -- simply asking someone "What's the complexity of $foo"? doesn't tell you anything about whether they "understand" complexity. It only tells you whether they've adequately memorized that particular cell on their crib sheet.

As they are thoroughly incentivized to do, thanks to people employing interview techniques like these.

[eveningcoffee]

If you do not know the complexity class of the bubble sort then you probably do not a have formal CS education. It also follows that it is possible that when you see a similar bad solution then you are not able to recognize it as such.

I think that these three questions showed are quite good and fair (for example I did not what is Hopscotch hashing, but it looks quite important after looking it up, so thanks for this).

Some of such questions might be possibly indifferent for the position you were applying, but seeing some hate behind these questions is in my opinion quite unjustified.

[wutbrodo]

> If you do not know the complexity class of the bubble sort then you probably do not a have formal CS education. It also follows that it is possible that when you see a similar bad solution then you are not able to recognize it as such.

This is absolutely absurd. I have a CS degree from Berkeley (universally considered one of the best CS programs in the world), and I spent the last few years on an unusually CS-focused team within Google (specifically, artificial intelligence). Off the top of my head, I could easily imagine not remembering what exactly bubble sort is. What's the use of retaining the details of an algorithm that's literally held up as the "don't do this" solution to sorting? The most I can imagine being useful is knowing the theoretical best case average complexity of a sort. And my job is wayyy more CS-focused than the average engineering job at Google (let alone elsewhere). You heavily overestimate how useful rote memorization is to real-world productivity.

Whether a candidate _understands_ these concepts, on the other hand, can actually be illuminating. If you described bubble sort to someone and asked him to describe the complexity, then you're getting all the signals you're describing about CS understanding and education. (though there's controversy about the usefulness of these skills as well)

[ubernostrum]

You're not going to get anywhere arguing with people who believe these are useful questions.

Though to be honest, Google uses those kinds of questions and apparently treats them as useful, so I'm not sure why you'd have wanted to work there.

[wutbrodo]

I've been on both sides of the interview process at Google over the last half decade (I no longer work there) and I can tell you that asking people to recite random facts by rote was not part of their interview guidelines for as long as I was there. This includes a couple dozen interviews I conducted and the candidate notes of the other interviewers.

[eveningcoffee]

I agree with you. But I think that you actually prove that this is not that absurd question at all because you actually described exactly the content of this question and why it is asked about (at least in my opinion).

Naturally if there is no option for the discussion when somebody does not know the answer off the top of their head then this would be really absurd and pointless situation.

This question is not good for selecting out somebody for their specific knowledge, but it is in my option a good one to prune out candidates that manage to demonstrate their general ignorance about the field.

[wutbrodo]

> Naturally if there is no option for the discussion when somebody does not know the answer off the top of their head then this would be really absurd and pointless situation.

Ah ok, I guess I misunderstood you. Though this "absurd and pointless situation" does in fact happen: There definitely is a class of interviewer who will expect off-the-top-of-your-head detailed knowledge (like being able to remember bubble sort's details from just its name).

[kafkaesq]

If you do not know the complexity class of the bubble sort then you probably do not a have formal CS education.

No, it means you're smart and have learned to sift out unimportant matters of detail ("Was bubble sort, which I only ever had to think about for a week or two the first half of my sophomore algorithms class, and was only ever brought up as a negative example anyway, O(n^2) or O(n^3)?") in order to focus on much more interesting and useful stuff.

[eveningcoffee]

Pretty much spot on and that was my point. You can answer to this question, you know what is complexity class, you know that it is a negative example and it is rather bad.

See, I am not a recruiter or interviewer, but this question feels to me like an useful one to prune out ignorant fools who start to lament how unfair is to ask such questions instead of giving more or less correct answer.

Naturally if short direct answer is the only accepted answer and there is no way to discuss these things with the interviewer then I would also walk away.

[hnbroseph]

> If you do not know the complexity class of the bubble sort

not knowing or remembering doesn't preclude one from understanding that one approach or technique can be more (or less) costly than another.

[dajohnson89]

These facts can be easily googled.

[eveningcoffee]

Yes, if you take them as just mere facts. But if you are not aware of CAP theorem and its implications then how do you know that you should google it?

[striking]

I haven't received a formal education in CS, and I know about CAP and what it means.

Reading the Aphyr "Jepsen" series is what helped me learn it... when I was still in high school. And this was necessary because I was curious about which database I needed to use for a particular side project I was writing.

It's totally possible to just Google "bubble sort complexity" or "CAP" and learn about it.

[eveningcoffee]

Just to assure that my point was well understood.

Yes, you can today easily find quite a lot of information and learn about it, but this was not the situation the original poster lamented about.

The claim was that when faced with such question, one can just google it and read the answer. Problem solved. Because these are just some random facts like who is the president of France.

My point was that in my opinion these questions actually probe the general understanding about the CS field.

[sidlls]

You act as though CS knowledge is some high priesthood of supreme mathematical reasoning insulated from the internet.

As a matter of practical use, most of the time details about algorithms and data structures, from implementation through complexity analysis, can easily be regarded as "mere facts." Those times when this doesn't apply are times when somebody applying formal academic level CS is surely required, but these are far less frequent than most programming tasks require--even at Google.

[eveningcoffee]

No, this was not my intention. Sure people do not know all the facts and all the implementation details and corner cases of some specific algorithm, but I would expect them to have some basic knowledge.

This is like knowing that lookup complexity of the hash table is usually O(1) (but could become O(n)) and one should use it instead of list when frequent lookups are necessary.

I am not an interviewer, but I think that the questions listed were actually quite good pruning questions and if you do not know them, well, there are the search engines and you can look them up for the next time instead of starting lamenting about the unfairness and showing the ignorance that is in in this case in my opinion demonstrating the serious negligence.

[hnbroseph]

if someone is unaware of CAP, they're unlikely to have been working in an environment where it was relevant. if this same person starts working in an environment where it's relevant, i'd wager that it will be hard to remain unaware.

[hvidgaard]

I have a CS degree. I learned about the CAP theorem, and I work with the nature of it daily. But my mind have ventured beyond the CAP theorem, it's implications are now mere facts of distributed systems, and the name "CAP theorem" had simply sliped out of my mind. If you want to quiz knowledge, rather than google-fu and name dropping, ask if you can make a distributed system with consistency and availability.

[eveningcoffee]

I think this indeed would be a better approach.

Instead of asking about Bubble sort, ask what is generally the complexity of a naive sorting algorithm and how good it can get for a general case.

I have investigated immutable hash tables but I do not know much about concurrent hash tables. This is my blind spot, so I do not know what the relevant question about the Hopscotch hashing would be.

Instead of asking what is CAP theorem, ask if you can make a distributed system with consistency and availability at the same time.

I think that this was the intention behind these questions after all and is the reason why I am trying to argue in support of them.

[josephg]

There's a middleground between those extremes. There's lots of knowledge that isn't relevant most of the time, but when it is relevant its worth its weight in gold. (And often these things aren't so obvious that people will google search them.)

When I'm trying to evaluate a candidate, I want people who proactively search out knowledge in that middle zone. People who understand complexity theory, and CPU caching behaviour, and the C10k/C10M problem just because they know they might need it some day. Because they want to work on problems where this stuff is relevant.

This sort of knowledge is the difference between hearing "our website is slow - I think its the database?" and "our website is slow - I took a look and our database server has run out of open file handles. But I'm still confused - that shouldn't explain the latency we're seeing."

The CAP theorem is a great example of this sort of middleground might-be-useful knowledge. Understanding how your database will behave in the face of network partitions is exactly the sort of thing that separates good engineers from great ones.