I'm sorry man no cares that you and everyone who upvoted this comment are Super God programmers with 30 offers everytime they say they are looking who can afford to tell every company where they can stuff their interview.

Us mere mortals are willing to do whatever it takes to get our dream gigs.

These guides are largely targeted are getting into the some of the best, thus pickiest and most selective, companies in the world.

And if getting on means being a dsalgo monkey in front of a whiteboard for a few hours so be it.

Let us share interview tips in peace please.

This "hurr durr technical interviews suck" but I have no real alternative and have never built a company nor seen any really flourish at the top without this is monotonous.

Put your money where your mouth is and start and only support companies that skip these kinds of interviews.

Like these fine people

https://github.com/poteto/hiring-without-whiteboards

But the snarky comments are beyond annoying.

My own opinion is let’s ignore companies that make us jump through hoops, as it only encourages them to become increasingly ridiculous.

Unfortunately not everyone is in a position to do that.. "beggars can't be choosers"

I’m of the opinion that if you are a company having trouble hiring people (everyone other than google/amazon) you should not copy their interview process.

There are great developers out there that do not do well in these interview environments, who are not worse than those who do well in them.

If you are going for a high power attorney partner job at a big firm they do not ask you to recite obscure case law. Id you are a master carpenter they do not ask you to build a cabinet using a hand lathe.

IMO provable previous work experience if a candidate has it should trump conceptual knowledge spewing, and interviews that ignore experience and give the same theoretical knowledge quiz as they do a new grad are shooting themselves in the foot. And I think everyone knows it, but most engineering orgs are terrified of letting a bad hire through so they blindly do whatever the “top” companies do.

Yup, that seems to be it.

As if there's some "secret sauce" to interviewing that all the other shops know except their own.

But the bigger point is that - even assuming for the sake of argument that these questions actually do "work", on some leel - they've become such a huge fad that people are just adopting them solely on the basis of authority, without intrinsically understanding why these questions work, or more importantly, how to interpret candidates' responses to them

In other words, they're just following a script. I wouldn't say quite it's on "blind faith", per se (because the companies do have some reputation). But it's not much better than blind faith. Such that this precious quote of yours, from just a few days ago, seems quite apt here:

This practice of blindly adopting ideas just because they work for Google needs to stop.

So I guess the problem with objective-seeming (and often just simply gratuitously hard) "filter" questions like those suggested here is that their real purpose seems to be give the process an appearance of objectivity - "We had a guy in here, his code samples looked great, and he talked a great game and all -- but would ya believe, he totally froze on that Lego robot puzzle question! What a poser!" -- when of course it's never going to be anything of the sort.

Why is that weird? The "beggars" I was referring to are people looking for jobs, not employers, so those actually seem like things that would go hand in hand, since if all companies only want the best of the best there will be many people without a job. Thankfully it seems like companies all have a different idea of what the "best" is so I am still employed

How do you know it is you "dream gig" until you have actually worked there? Have you never been excited to accept an offer from a company only to get there and realize its just the same old bag of petty politics, egos, kool-aid drinking and grunt work?

Google, Facebook and the rest of the big SV companies that "only hire the best" are no different than any other big corporation. Also not everyone that works at these big SV companies gets to work on the really interesting and sexy projects.

There seems to be this myth that if you can just pass the Google or FB white board interview you will have it made and your "dream job" awaits. The propagation of this myth has given life to a whole cottage industry of prep courses and books on how to pass them.

I also think you have misunderstood the OPs position, I don't think they were saying that they were a programming god who can't dictate where they work, quite the opposite.

What happens between you typing a URL into your browser address bar? isn't a question that requires a canned response to be parroted back – it's a starting point for a conversation about your knowledge of the web technology stack. It's not at all like there is a 'correct' answer, but demonstrating that you have a vague idea of how parts work, can identify gaps in your own knowledge, and make reasonable choices about how you might fill them.

Maybe what are the things you should consider if you were writing your own database server? is somewhat less directly applicable to most jobs, but I'd argue much the same sort of thing applies – it's a kicking-off point for a conversation about systems that you should have at least rudimentary knowledge about.

I'm curious as to what you would prefer in a technical interview - more directly relevant questions about the specific systems you would be working on?

The one time I have actually been asked this question it sure felt like the interviewer was expecting a certain explanation rather than trying to start a conversation. Hard to tell, since that was the only technical question I got asked in that phone interview and they rejected me after that.

If somebody is going to ask those questions in an interview, at the bare minimum this person must know deeply about the subject, so they can recognize a correct answer and judge their quality. Instead, from how people talk about this (I've personally stopped interviewing for a while) it looks like everybody asking those has no idea what a correct answer looks like, and just expects candidates to follow a script.

There are two things to note. First, it is incredibly unlikely that your interviewer knows deeply about both the HTTP protocol and databases implementation. Thus, anybody asking both is already full of bullshit. Second, it may be valuable to get a hold of the interviewer script and study it. People full of bullshit are not normally very creative, so the scripted answer should be easy to find at Google.

If I have to study things unrelated to my job for some shibboleth interview, that's time I could have spent on my actual skills instead. Besides, any interview that does not demonstrate my ability to write a unit test and encapsulate data and functionality means I know what horrors I'm likely to encounter when I get to the code.

At least that's what I try to do when I end up interviewing someone. For example, can he suggest what sensors would be good for a Lego robot that would knock a tennis ball off the ping pong table without itself falling off? Can he describe the logic? How would he test this? How long, on average, would it take? What position of robot and ball would give the worst case performance (success or time)? His job will not involve Lego robots, but IME the person who can give sane answers on those would do a lot better than a coder who knows one toolkit well and nothing else.

Right off the bat, this is very muddled question to ask.

For one, "sensors"? I think you meant to say "actuators". Because a sensor by itself can't knock anything off a table.

More fundamentally, "Legos", for those of a certain age, were entirely non-mechanical components in their day. So (even though yes, we've also vaguely seen and heard about, and rolled our eyes at, the newer kind), this just sounds like asking them to (seriously) consider the question of how to build a logical circuit out of tinker toys. Yes, it can be done - but on the face of it, that kind of a question comes off as an invitation to join a mental masturbation session. Not the kind of question you'd ask of someone you respect, and whose time you know to be as invaluably precious as you own.

The person who can give sane answers on those would do a lot better than a coder who knows one toolkit well and nothing else.

This is of course a false dichotomy. Especially given that it was -- not sure how else to put this -- a silly question to ask in the first place.

What I personally am looking for is an engineer -- someone who can look at problems formulated in a fuzzy fashion (this is critical), figure out what technical solutions exist, probing the customer/user to flesh out the initially vague requirements and come up with a few different ways to implement this.

You are looking for coders: someone who can take well posed, unambiguous problem and algorithm descriptions and turn those into a working code. That is probably a better fit for a "coding interview" referred to in the title. It is just my experience that I get much better code and value for $ by hiring engineers even though I have to pay them higher salaries. That's just me though, YMMV.

No I'm not - I'm very much looking for engineers in the mindset you describe. I just don't think your Lego robot question is a good tool for sniffing out that mindset. (For the simple reason that "muddled interview question" != "fuzzy real-world problem" - in fact there's a world of difference between the two).

But then again, we have a disconnect. Which is of course totally fine.

There's no need to make it any "harder" - the point is that just wasn't well-articulated to begin with. (Noting again that "well-articulated" is very different from fuzzy / ambiguous, in the engineering sense).

And given that the people you want to hire, by definition, are generally very busy (and have many, many important things to do with their time) -- even when they aren't currently working (despite the urban legend that "they always have jobs") -- as such, it just isn't a good use of their time.

The database question seems better, because any programmer should have slight experience with it.

Which inevitably leads to outcomes like:

"Oh I see you're from Kazakhstan, and got top grades at one of the top schools there. And your GitHub account just blew our team away, the minute we saw it. And we can tell, from talking to you for 5 minutes, that you obviously know FP and SQL/NoSQL and database internals and caching and consensus protocols inside and out."

"But wait -- what's that look in your face when we ask you about solving this little Lego problem? Do you not like puzzles? Or wait - you mean you've never heard of Legos, for chrissake? We'll, what can I say. Sorry to break this to you, but we're looking for engineers here, not mere 'coders'. And how do you tell if someone has the soul of an engineer? It's because they dig shit like Legos and robot kits and stuff. They totally geek out and go to town on problems like this, in fact!"

"But then again, that kind of person obviously isn't you. Feel free to apply again in 6 months (after you've passed another 3-hour HackerRank test and our mandatory Skype session on culture fit, of course)."

I was asked a similar type of question at Microsoft once about operating systems. I don't think the interviewer expected that I know the answer to what he was asking but rather explain what I do know, and then based off my limited understanding work backwards to see what might be done and what tradeoffs are being considered.

At least that's what the interviewer said to me when I responded with "Oh God I have no idea I have never done anything like that before." For what it's worth I did get the offer despite not knowing anything.

That being said, I did interview at another company where I was asked something that I guess the interviewer thought was very basic and I responded with something similar. His advice to me was to never say I don't know something, which I don't really agree with. I didn't pass that one.

Sounds like they're the ones who messed that one up - not you.

I hear it as:

"Tell me how detailed your understanding is of database internals in a conversational format; here is a talking prompt to help..."

regarding typing in the url question:

"Tell me the level in which you understand networking protocols"

In the real world I would hope these questions would be more of a discussion; "ah, you mention ACID, what kind of pattern can you employ to help implement that", "MVCC" etc..

This format of interview is hard to pass on simply regurgitation alone and does a pretty decent job of vetting technical understanding in a natural, conversational way.

1) Everyone swears up and down that it's an absolutely vital, fair question.

2) Everyone justifies 1) by giving conflicting (to others' answers) criteria they're judging it by, such that no answer could possibly satisfy them all, except by saying something smart that impresses the interviewer and might not correspond to rigorous judgment criteria.

Many of these questions are very vaguely scoped which gives the confident and familiar plenty of room to show how clever they are, but also makes it more intimidating for those who haven't seen them before.

Or, to put it another way, the linked site looks like a great way to make yourself look like you have a junior-to-mid-level understanding of a lot of different areas. But the process it's optimizing for starts to break down the more senior a developer you either (a) are or (b) are trying to hire.

If you're interviewing for a front end position, you can make a nod to interrupts and continue on with BGP, ARP, DNS, TCP, IP, routers, etc. If you want to show your knowledge of security you could mention heartbleed, poodle, or even say why this isn't vulnerable to shellshock. An overview will take a minute, and the interviewer will follow up with more targeted questions if needed. It's a chance for the candidate to shine.

I'm always ready when asking something very open ended to follow up after 15 seconds or so to say "let's talk about [area X] first." For URLs, maybe this is "let's talk about what the actual network request, if you sniffed the traffic, looks like."

Exactly :)

Well if someone claims to be "full stack" - yes.

"Every step?" Not at all true, in my experience.

What you need is a reasonable sense for the breadth and depth of the topic -- which quickly reveals itself to be far broader and deeper than what most engineers (including many very capable people I know) can hope to "absolutely understand every step of". And the ability to drill down (and go down rabbit holes) when needed. Combined with the experience of actually having gone down more than a few (and having from relatively unscathed, eventually).

In fact, if anything, your observation isn't just overstated - it actually misses the point of what makes some of the most effective people as effective as they are: their ability to manage complexity, and in particular, their ability to (reasonably) "connect the dots" in a complex system despite not "absolutely" knowing, at every level of detail, how every component in that system works.

Mind you, for the right value of "reasonably". It's when knowing when their level of understanding, while imperfect, is still good enough to solve the problem at hand - and when it isn't - is that makes these people so effective.

I don't see that question as being any different really. They're both just ways of guiding a conversation around the area we work in to gauge what candidates know / are interested in.

Personally, I've poked around in Postgres a bit because I find it interesting. And having deeper knowledge means that when you're about about to add a new not null column with a default value to a massive table you can stop and reason through how you're about to shoot yourself in the face :-)

You need to have a bit of an idea, sure.

But in order to give any kind of a meaningful answer to the question, you need to have not just a "bit of" an idea, but in act, a deeply solid and intuitive idea. Either that or -- crib the answer from websites like these, know that it's one of the top 30 questions you're likely to be asked.

Which, very sadly, is exactly what the modern interview process (greatly) incentives people to do, these days.

Do they talk about tables? What about indexes? How about sql? Do they ask enquire about the requirements / data model?

Interesting, because as soon as I got over the "why the hell do you want to create a new DBMS?" question, my first thought was about filesystems. I haven't digged into any DBMS to look at, but all those you point look so easy when compared to atomic data writing...

Questions are not inherently bad. It's how the interviewer interprets the answer, and whether it's used as a gateway to a discussion or a one way q&a session.

If your default answer is "Just use PostgreSQL until something screams at us that we shouldn't" then you are correct, you don't need to know about database systems.

Yet, these will be the same people screaming to use <flavoroftheweekQL> instead just using PostgreSQL.

You'd be surprised how many senior developers freeze when they are asked to reverse a list using any language of choice.

The better question is why you think that’s a good thing

Asking easy and qualifying questions upfront saves money for the company.

That's a really nasty attitude to take when someone is trying to evaluate paying you a large sum of money for many years of work.

Considering that I've run a ton of technical interviews, there's no good way to evaluate someone for competency without these kind of hypothetical questions. (This is how I screen out the morons who don't know how to use a database.) It's a two-way street, though. You can learn a lot about an organization by the kinds of questions they ask and the direction they send you down.

In the first case, I got a nice offer. In the second case, I cut short the interview.

The questions were virtually the same. In the good interview, some silly fizzbuzz stuff, followed by "how do you do X", and me doing it. In the bad interview, do this thing, in bash. Had to read a man page on it, asked the interviewer if they had man pages, found out they didn't, asked if I could use the interwebs, at which point he became more flustered and overtly hostile. I then proceeded to solve the problem, while typing in vim, while talking him through the whole process. He was visibly angry and shaking after this. Tried a few networking questions, some of which I've known, some of which are far outside my domain, have never had a reason to study/investigate, and were completely unrelated to the task at hand.

The good interview asked me similar things, and when I indicated some of the boundaries of my knowledge, proceeded to work with me on how quickly I could learn something and become useful.

There is a huge difference in these organizations. One of them is thoughtful, has great people, and would be a terrific place to work at.

The other ... not so much. Later confirmed by talking to people who worked there.

Many people are justifying "hard" problems using various reasoning. When I ran my own company and hired, I never used this. What I wanted to see, was how something thought through something they've not seen/done before. This is what I cared about. Could they learn, and apply this learning, in situ, at high speed, and grow as a worker.

It seems my viewpoint is in the minority here, with a number of people preferring to test random knowledge fragments, as compared to actual ability to learn and apply what you learn. This is a shame. This generates groups whom are really good at recall, but possibly less so at applying this (as the "applying this" is not tested/measured).

I've seen the focus on velocity and accuracy of regurgitation in grad school. Test scores from people who focused on that were high. Capabilities as researchers ... quite low, with very rare exceptions.

The same effect is likely to occur in this scenario.

Technical interviews are hard. Probing depth of knowledge is challenging. Getting a sense of thought processes requires creating things that people can learn from, and apply.

I've had precious few interviews like this. Happy my current position is one of them.

"How did I get to this situation? Why am I here? Why am I writing my own database system instead of using an existing one? Where should I leave my resignation letter? Should I give them two weeks notice or just quit right now?"

Not only is this a perfectly reasonable question to ask - one is almost tempted to fault someone for not coming back with this as the very first question to ask in response to the question that was initially asked.

Given that 99.99% of the time you're tempted to go that route (as with, similarly: your own ORM, "scripting language", whatever) - you're going to wind up with, at the very least, way more of a challenge than you initially bargained for.

My last job was to work on a proprietary, in house database, and while the case for it wasn't quite as strong as when it was originally written, it still did things that no external offering did that were considered important to our business. I probably wouldn't want to repeat the experience, but I learnt a lot there, and that company is wildly successful, not least because they make truly strategic decisions about buy or build.

You'd be surprised how many people freeze when they are asked to reverse a list of elements.

Another reason to ask fundamental questions is to ensure that an otherwise fit candidate understands the tradeoffs involved.

When I interview, I ask for her to write some code, yes. But I make it very simple: fizzbuzz, or reverse a string. But then inform the canditate that I am looking for style, craft and personality. Somewhat akin to a chef being asked to fry an egg

You're looking at it backwards. That type of question catches people who misstated their qualifications. It's a buy-in to sit at the table.

People can debate whether they should have to answer questions, but in the real world one or two small qualifying questions of this nature save the employer a lot of money and time in the hiring process.

I ask about quantification because I see it as the only way to reduce/eliminate bias.

Answer: I would consider why I'm writing my own database server, as opposed to using something off the shelf.