2. What happens between you typing a URL into your browser address bar, hitting enter and seeing a web page?
"What happens when I'm asked a question like X? I spout a mutated form of some canned response I cribbed from a list I found on HN a while back. Because I hear that's how you're supposed to 'rock your coding interview', these days."
3. What are the things you should consider if you were writing your own database server?
"Look, you know as well as I that this job has nothing -- as in, nothing whatsoever -- to do with actually building production-grade database servers. Or anything even remotely analogous to it. Debugging that tangled mess of poorly conceived, never-reviewed JSON APIs left behind by the other developer (while you were pestering them about 'disruption' and 'just needing to get this thing to market') is more like it."
"But hey, since you're playing that game, I can play too: here's a bunch of catchphrases like 'non-blocking I/O, sharding, blah blah.' Because I hear that's the killer answer to give to questions like these. And BTW, if you really think that people Michael Widenius or Salvatore Sanfilippo would be interviewing for this job, then your problems are way bigger than I could ever hope to help you with."
Some permutation of this comment is made litterally everytime any coding interview resource is posted.
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.
I think the parent is implying they’re not a Super God programmer, and some of these interviewers are expecting them to be, when in fact their company has no need of such a programmer.
My own opinion is let’s ignore companies that make us jump through hoops, as it only encourages them to become increasingly ridiculous.
I find it interesting that in the span of 3 comments it’s gone from “this company is only looking for the best of the best” to “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.
Yes and this logic is essentially "if it works for a publicly traded company that has 25,000 full time engineers then surely it's the right approach for our start up of 25 people total."
Whether it actually works for those companies (beyond a placebo-like effect) is open to question.
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.
The truth is you just don’t know, and you have to go off of hunches - the google panel rejects on hunches all the time, regardless of the systems they put in place to minimize it.
Yup - the hunch factor isn't a "bug"; it's absolutely intrinsic to the process. Not only is fundamentally irreducible - you wouldn't want to completely remove it from the process, even if you could.
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.
> I find it interesting that in the span of 3 comments it’s gone from “this company is only looking for the best of the best” to “beggars can’t be choosers”.
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
>"Us mere mortals are willing to do whatever it takes to get our dream gigs."
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?
> 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.
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.
Yeah that's the thing - the vibe I get from these questions is, "Uh, I actually have no idea what to ask these candidates. I just know I better not fuck this up. So how about that question everyone was talking about on HN the other day? That way, if they don't give an answer as detailed as the one I vaguely read about, at least I'll know right away they're a complete moron."
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.
I like demonstration code reviews, personally, especially in combination with a short pairing session so I can see how they code too. I will happily take a short (2-3 hour) long take home, so I can demonstrate my skills in a quasi-realistic way.
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.
I think many technical interviews are simply trying to assess whether the candidate has his head screwed on straight and the ability to do basic engineering. As such, the specific topics are practically irrelevant.
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.
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?
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.
I think you nailed the disconnect between our views.
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.
Doesn't seem like a very middle question to enjoy. The question basically sats you have "Lego robot that can knock A tennis ball off the long long table." So you already have a robot that can knock this off the table, it really isn't important that if it's made of Legos or not. Now what sort of sensor would you add so it won't fall off the table as well. It specifically asks about the sensors. Don't make questions harder than they are
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.
I have no ideal what the question asks for. What kind of sensor are there? And I did lego robot a while back for optional credit in college (mine worked well).
FWIW, though I'm just one datapoint, if I'm going to have a "this isn't the day to day job" question thrown at me, I'd rather it be something more off the wall like this than most of the "do you remember this from your textbook/reference materials" style of trivia. Then I feel like approaching it from first principles is what's desired, and free to bounce ideas around, rather than being expected to remember the optimal log(n) "right" answer.
The lego question has as much to do with programming as biology question. You literally test whether the person played with lego or othrr robot kit somewhere. Why would you expect programmer to do so?
The database question seems better, because any programmer should have slight experience with it.
Exactly - and not just whether they've played with Legos, but whether you've played with (or at least been curious about) the new modern (and incredibly expensive) robotic kind (or robot kits generally).
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 agree these kinds of open ended questions are good since they can go in lots of different useful directions (specs, performance, algorithms, generality) and give you some idea what it's like to work with this person (and for them to get an idea if you're jerks or not).
> "Look, you know as well as I that this job has nothing -- as in, nothing whatsoever -- to do with actually building production-grade database servers. Or anything even remotely analogous to it. Debugging that tangled mess of poorly conceived, never-reviewed JSON APIs left behind by the other developer (while you were pestering them about 'disruption' and 'just needing to get this thing to market') is more like it."
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.
"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.
This seems to happen every time the question comes up:
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.
The URL question is a really good one though. You should absolutely understand every step of that process if you're working on web applications. The database one is weird. You don't need to know how to create a good database system yourself in order to effectively use one, I think. Neither do you need to know how to make a web browser to know how HTTP requests work.
Every step? Keyboard interrupts and the browser going from DOM to OS drawing APIs included? ;)
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 it's a job to work on a haptic feedback system, they may very well want to plumb your understanding of when interrupts fire, without prompting for canned answers.
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 think it's worth being aware that the more open-ended you make the question, the more you might freeze a less-practiced-at-interviewing candidate on not knowing where to start.
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."
You deal with BGP and ARP as often in frontend as you do with hardware interrupts.
Heartbleed and co. may or may not be your concern depending how much that frontend is into devops.
Heartbleed should be understood by frontend devs. In 2017 there is a minimum set of knowledge that frontend devs really need to have. That includes pki, client and server certificates, routing, network caching, and a whole host of other topics. Layers of the stack interoperate, and lack of knowledge of the stack leads to security vulnerabilities.
Good first follow up question would be "I am typing this URL on the mechanical keyboard, bluetooth keyboard or touchscreen?" I think the whole time for the interview could be used to discuss what happens inside the keyboard without even reaching the OS :)
You should absolutely understand every step of that process if you're working on web applications.
"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.
While that's mostly true, to use a db efficiently you need to have a bit of an idea of what it does inside.
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 :-)
To use a db efficiently you need to have a bit of an idea of what it does inside.
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.
Don't get me wrong - it's not a question I'd ask myself, but I think you'd get some interesting answers. I'm fairly sure with that starting question I'd be able to have a conversation that gave me a pretty good idea about how well someone knew databases.
Do they talk about tables? What about indexes? How about sql? Do they ask enquire about the requirements / data model?
> Do they talk about tables? What about indexes? How about sql?
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...
If someone started with 'How would you write a database?', I would just talk about simple csv reader n writer with no other promises and be done with it. Everything else is a feature.
"Meaningful" in an interview question does not have to be "correct". These questions can be used to evaluate the thought process, rather than for "ha! Wrong answer!".
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.
> The database one is weird. You don't need to know how to create a good database system yourself in order to effectively use one, I think.
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.
Of course, but that isn't always as efficient. Candidates bone up on canned responses the weekend prior, and it's also good to see which candidates are independent learners.
You'd be surprised how many senior developers freeze when they are asked to reverse a list using any language of choice.
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 my previous search, I had two interviews scheduled, one day after another, with different organizations which were diametrically opposite in outcome, though asked similar questions. It was the way they asked the questions, the body language of the interviewers, and for one of the interview sessions, a seeming desire to show that the interviewers were "smarter" than me.
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.
> What are the things you should consider if you were writing your own database server?
"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?"
Why am I writing my own database system instead of using an existing one?
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.
Why am I writing my own database system instead of using an existing one?
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.
These types of questions aren't about playing a game of catchphrases but are meant to let the candidate shine through demonstrating their thought processes. They are also used as behavioral questions to assess how a candidate deals with situations in which they are not familiar, even if the task itself is incredibly easy or not directly applicable to the job.
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.
The question we ought to ask though is:
Is a candidate that freezes when asked to reverse a list be an employee that would be incapable of basic coding?
Or more interestingly (to me) is the candidate that can easily write the reverse pseudocode on an interview whiteboard one that will be a good employee?
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
> Or more interestingly (to me) is the candidate that can easily write the reverse pseudocode on an interview whiteboard one that will be a good employee?
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.
#2 is a great filter question. You'll be surprised how many people don't have a clue on this. I'm more than willing to answer that question. It tells the interviewer I have a basic understanding and can expand on it later
What I'd love tips for, is how to politely and professionally protest certain interview styles. I want to know how to say, "sure here's how to implement foo but I also want to express that a focus on this coding trivia is distracting from the skills I feel make me an asset..."
Maybe what I'm asking is tips on how to steer an interview. One of the reasons I wouldn't even consider a tech giant interview is that I feel like I'm just one of many cattle being processed through a long gauntlet of nonsense that distils me down to quantifiable traits rather than who I am.
When I ask a straightforward problem during a technical interview, I'm trying to ensure that the human before me is actually capable of solving the straightforward problem. You're free to respond any way that you like, but if your response doesn't actually include a solution that demonstrates the capability I'm testing for, I'm not sure that I'm going to be able to distinguish you from the ~50% of interview subjects that HR puts before me that have no idea whatsoever how to program a computer.
I don't even ask softball questions. Mine are more like tee-ball questions. Too often, the tee pitches a perfect game.
I can often type the answer to a tee-ball question in under two minutes; I really don't understand people who are angry about being asked to demonstrate the skills they are selling. We spend more time in interviews introducing ourselves.
Look at it from the point of view of somebody who's been able to somehow acquire a master's degree in computer science without knowing how to write a simple Boolean expression that correctly implements a well-defined predicate. When you bomb a tee-ball question that exposes you, how are you likely to react? (a) Wow, I don't know how to program, or (b) THIS PROCESS IS UNFAIR.
The salient point is about halfway through when they put up the big chart of a couple thousand interviews and the stddev vs. mean of technical score, and say:
As you can see, roughly 25% of interviewees are consistent in their performance, but the rest are all over the place. And over a third of people with a high mean (>=3) technical performance bombed at least one interview.
Now, what this points to is a very clear failure of these standardized interviews with their allegedly "tee-ball" questions, because the results shown would be astoundingly unlikely in a world in which the interview process had any kind of consistency in identifying technical skill.
So, no. You're not doing what you think you're doing, and if you've got a high failure rate the problem is almost assuredly not with the candidates. It's with your interview process, or with you.
I don't necessarily accept either of those statements. But since most companies just copy Google's interview process, it's worth pointing out that Google can afford to reject, say, 100 qualified people in order to avoid accidentally hiring one unqualified person. The average non-Google tech company cannot afford that.
Well, the whole industry operates on a model of avoiding false positive at literally any cost. So I don't think it's an exaggeration, though I certainly agree it's ridiculous.
Out of curiosity. Would you still ask these questions if the candidate has a github/gotlab/whatever profile with X repositories where they are the main / only contributor? Could you explain why yes / no and what the specifics would be? (Volume? Complexity? Commit history? )
I think you'd get more value out of talking with them about those repos, and the process of building them, design choices, then any silly question like "how would you design a database". Of course, that would also mean you'd have to actually put more then a few minutes into prep for the candidate's interview...
I've had many, many interviews where I actually had to ask the interviewer "Did you take a look at my GitHub repositories and contributions?" only to be answered with "No, I didn't have enough time, etc. etc." It's shocking to me. Can we please cut through the songs-and-dances and talk about actual, real-world code?
To be fair the days when Github was a strong signal are long over. When interviewing it is rarely worth the interviewers time to look and figure out if it is original code or just forks. Whether the CV is well formatted and free of spelling mistakes is actually a much stronger signal than whether it has a Github link on or not.
Agreed. Every single time I've ever looked at a github profile for a candidate they've had 1 or 2 original repositories that are as bare bones as possible and 18 forked repositories so it "looks" to the untrained eye (i'm guessing recruiters) that they have an active profile.
And then you have others with 90+ repos, and 75%+ of them are original code, and have thousands and thousands of lines of code. Maybe all your candidates have been weak/just out of school.
Also, forked repos are fairly obvious, and there's a dropdown to just show source repos, and if they are manually forking to prevent it from showing as a fork on there, that's a pretty shady indicator that you may want to follow up on...
Those candidates are 1 in 100, seriously. If you have a stack of CVs to filter, it literally is not worth looking at everybody's Github to check. Just filter by formatting and spelling and you're probably good.
And that's why I think resume based hiring is shit, cause my resume isn't great, but my github and skills are stellar. But people like you would chuck my resume in the trash without thinking twice cause I'm not currently working as a programmer.
If that's true, the target of your blame should be the weak candidates who flooded Github with junk repos. And/or whichever journo or blogger started telling those people that "having a Github" was a shortcut through the hiring process.
While I agree with you for the most part, many companies want a "standardized" interview process, for both diversity and CYA reasons. Tailoring the interview to the candidate is actually illegal in certain organizations (like government), as it has large potential for abuse.
That's kind of bullshit though. There's no way for it to be truly objective or standard. You already know what university I went to and made assumptions based on that, you know where I worked before and what my hobbies are.
An interview is not like the SAT. And even the SAT is not an unbiased test.
Objectivity is not a binary, and just because we can't be 'truly' 100% objective doesn't mean we shouldn't try to be more so. If you ask everyone different questions, you don't have a baseline of responses, so you can basically fail or pass whomever you want without anyone being the wiser.
It may surprise you to know that I prepare extensively for interviews that I conduct, and that my questions do not include time-wasters like "how would you design a database". My questions are carefully tailored so that candidates who can program computers can sail right through and get to talk about interesting things.
I wish more interviewers would look at helpfully included links to public code... Didn't happen (or at least wasn't brought up) last time I applied at places. On the other side as an interviewer, I'm lucky that I haven't yet done a phone screen with an outright failure of my tee-ball question (returning true if input positive int is even), though when I see if they can do it in different ways there have been flounders, but I still ask it independent of public code since I hear so many stories like parent's of utter failure. Depending on the contents of the public code (not so much its size) I may then drop some followup sections (I do a slight variant of https://sites.google.com/site/steveyegge2/five-essential-pho... to mainly test presence of areas of knowledge, details can be googled) and make things more informal with some time to make sure they actually wrote their public code.
In our interview, we have people from 4 different departments who will talk with the candidate, as well as the team (who is there for the coding portion.)
I honestly don't want to have to test if someone can handle a simple algorithm. (I'm not talking about anything crazy here, mind you.) Can they read code? Can they think about how to test?
I've seen faked code samples, and our test has a half dozen answers on github.
I want to just assume that anybody with five years of programming experience can code, but I've worked alongside enough counterexamples that I know I can't assume that.
That said, I'd really rather not have to deal with it as a candidate or as an interviewer.
A warning: If you take this approach, you'd better be a programming god, because you're going to be the guy who was too good to knock out a simple coding problem. Every off-by-one error you commit on the job will raise an eyebrow. People will wonder, does this guy want to be an engineer or something else? Why couldn't he rip through that problem and teach _us_ a thing or two on the way? Another thing is you're basically coming in and saying "your interview process is wrong". If you're being interviewed as a manager or a lead, you can afford that risk. If not, be careful, because many people, myself included, don't want to work with somebody who cannot focus on the task at hand and feels the need to question things that have clearly been thought out ahead of time.
If someone asked me a problem that basically reduced to a textbook case of something in the middle, difficulty wise, like reservoir sampling, and I said "oh, nifty, resevoir sampling, what do you use that for in your stack?" and they said "nothing, I just want to make sure you can code," then depending on how my experience to that point in the process had been going I might challenge them on that to some extent, a la "do you find this more useful than questions that are more representative of the work you're expecting me to do?" If the loop had been going particularly robotically, this might find stronger forms - I've walked out on a mismanaged interview before, though it was way worse than this (and way worse in a very different way - they just weren't at all prepared and the tooling they wanted me to use wasn't actually functional).
Or they might answer something more like "we use it to select test cases from our logs to ensure that we're adequately testing against real behavior with proper weights" (or whatever—it's been a while since I actually did this in a past job :) ) in which case I'd still try to have what I consider a more "real" conversation ("what primary problem are we trying to solve, and what else might be options to consider"), but in that case at least they had a good answer to the question and I'd be happy to write the code too.
But lastly, frankly, as a hiring manager I absolutely want to hire people who are willing to "not focus on the task at hand" and question things. I don't want people who just blindly do what I tell them to, I want people I can trust to disagree with me and be able to make a case for why they disagree. Being a manager doesn't mean my instincts are 100% and theirs are 0%.
> "do you find this more useful than questions that are more representative of the work you're expecting me to do?"
Yes, because tasks representative of the work we're expecting you to do are too obvious and simple for an interview 95% of the time, and are too hard and take too long for an interview 5% of the time.
If 95% of the work you need done is too obvious and simple, maybe you don't need to hire as good of programmers as you think you do, and why are you trying to make things in the interview artificially harder than the work that needs to be done?
It's kind of like asking someone interviewing to be a cashier at a fast food restaurant multivariable calculus problems, because 95% of the math they're going to have to do at their job is "too obvious and simple".
> If 95% of the work you need done is too obvious and simple, maybe you don't need to hire as good of programmers as you think you do, and why are you trying to make things in the interview artificially harder than the work that needs to be done?
If these high-priority and hard 5% were easily separable from the tedious 95%, this logic would be correct.
> don't want to work with somebody who cannot focus on the task at hand and feels the need to question things that have clearly been thought out ahead of time
This seems a little too general to me. Many things are not clearly thought out, and I'd rather work with people who can recognize when that is the case and communicate well enough to correct the course. A big part of successful development in my experience is knowing when not to implement things, or having foresight to implement things in a better way. Working with people who just do what they're told is often a huge waste of time.
”If you take this approach, you'd better be a programming god, because you're going to be the guy who was too good to knock out a simple coding problem. Every off-by-one error you commit on the job will raise an eyebrow. People will wonder, does this guy want to be an engineer or something else?”
And those people are what we call “assholes”.
Everyone makes mistakes. If you make a habit of questioning people’s competence because they make mistakes, and didn’t ace your whiteboard coding tests beforehand, you are 100% the source of the problem in this industry.
>...and feels the need to question things that have clearly been thought out ahead of time.
I only take issue with this. Many things in organizations that have been through explosive growth (and sometimes others) are that way because for no reason in particular and amount to bandaids upon bandaids because nobody's ever had a chance to actually look at the process. It very well might suck. Questioning it is the first step in making it not suck.
That said, as an interviewee is probably not the right time to do so. You're an outsider, you have very little rapport or relatability compared to the people that already work there. Even if you can point to something and unambiguously prove that They're Doing It Wrong, your advice isn't in a position to be heeded.
Thank you, your second paragraph is exactly my point, and I didn't appreciate everybody else dressing it down in isolation. Of course I don't want to work with a bunch of robots. But there's a time and place, and please don't throw a wrench in the interview process to prove how smart you are: I want to work with people who pursue their initiatives tactfully.
I think you'd find more tact with a less combative-sounding opener than "If you take this approach, you'd better be a programming god, because you're going to be the guy who was too good to knock out a simple coding problem."
Moving the bit about the scope of the role (jr vs sr vs lead) up to preface the rest of the comment would've toned it down a bit, but even there I disagree with the "taking a risk" part -
a senior candidate shouldn't feel like it's risky to offer alternative perspectives. If I got the impression that the hiring manager thought asking questions would likely be a sign of "cannot focus on the task at hand," that's going to set off my own flags a bit.
If you're married to your interview process I'm worried you'd be even more married to your day-to-day process, and I haven't met a perfect company yet, so I consider being overly adherent to process instead of results a warning sign.
Correct me if I'm wrong, but a reasonable approach would be to give the interviewer the benefit of the doubt and to at least engage the programming challenge, and to also voice your concern with the process. It's no different from voicing your concerns first and grudgingly engaging the problem, but the two make wildly different impressions.
Also, as an interviewee, you stand to learn a lot more from that interaction than by rejecting it. Hell, I welcome coding challenges as an opportunity to size up the interviewer's chops!
If the challenge is conducted in a reasonable way, it should feel like any other design/pair programming session you've had at the office, and it can be quite revealing of the tendencies of your potential colleagues.
> Also, as an interviewee, you stand to learn a lot more
> from that interaction than by rejecting it.
If you already learned this is not the company you want to work for there is no need to waste your time playing stupid games just to win stupid prizes.
The chances of you learning that information via interview are minimal. Some of the best teams I've worked in have had the most dysfunctional interview processes - often for the reason I mentioned in my post - lots of growth, little time.
An approach is to proactively bring up interesting aspects of the problem yourself -- eg, the last time I was writing example code on the board, I spent most of the time talking about where hooks to add more features would go or algorithmic complexity/edge cases I encounter as I try to implement a solution.
If you're focusing on the trivia, you're probably too focused on the code and not on solving the problem -- my experience tends to be that there's at least one or two interesting edge cases you encounter if you try the naive approach, and those are generally what the interviewer wants to discuss. The reason is that discovering edge cases in requirements and solving them is what a lot of the job is, and so how you approach that matters (and to an extent, more than if your code on the board is "correct").
Another approach is to extend the problem by asking clarifying questions -- if there's something unspecified that might influence your design, ask about it and tell the interviewer why it matters. Again, this generally is more what they care about than the details of the coding.
Finally, if those skills make you an asset -- why not apply them to the question? Even tangentially by talking about how you would (if you had more time/were doing a real assignment).
Coding on the white board is more about the journey than the coding, assuming you can write vaguely correct code. (Though writing on a whiteboard is definitely a skill you have to practice.)
How to steer the interview is to be honest and to talk.
"That's a cool problem. I'm curious though - I didn't see that on the job description. I'm not expert on that, and I didn't bone up on that last night. (ha ha everyone laughs)
I can step through it if you want, but it would help me if I knew why you asked about this. If you're looking to understand how I solve problems, that's okay, I'll muddle my way through it and ask if I need any clarifications."
They'll tell you. Interviewers often hold similar views to the candidates, but may be asking for a different reason than you think.
A somewhat related experience I had with a company that advertised proudly that they don't do live coding tests. They had a take-home exercise which I did very well and I was scheduled for a phone interview later. I was expecting it to be more around system design, behavioral questions but to my surprise it was a live coding test.
After the interview was done I questioned the person why have another coding test. He said it was to test on different areas of programming. I later messaged the VP/CTO who wrote the blog post on not having live coding test. The person apologized for the experience and said that the team I interviewed for did not come under engineering org. It was a frustrating experience but at least the person responded positively.
It is only after you worked with someone lazy or barely capable of foo who charizma-around-company-pong-table his way to staying in company and being treated as genius by those who don't work directly with him that you appreciate those simple exercises.
steering an interview is all about steering the human(s) giving the interview.
real life example: an MIT PhD in distributed computing walks into the room, looking extremely tired from interviewing people like me. I can tell this is going to be rough unless I'm controlling the conversation and we have a good rapport.
He's wearing a Fender shirt. I have played guitar a bit. After he introduces himself and I myself I open with, "Oh nice shirt. I assume you play some guitar?" and there goes 20 minutes of the interview talking about guitars.
So long as I don't completely bomb the technical aspect I've left this person with a positive and relatable experience.
This is the kind of thing that people want to avoid. Hiring a person because they share a hobby is ridiculous. If a candidate tried to steer the interview to non-technical questions I'd point that out to the relevant people and make sure it was highlighted in my feedback.
If you let the candidate steer the interview in the wrong direction, the fault is in the interviewer, not the candidate.
I have been on both sides of the equation.
My stories:
1) Brain teaser questions sometimes aren't as easy or as straightforward as everybody thinks--don't ask them as an interviewer unless you genuinely KNOW the question.
Digital VLSI design loops almost always have a question that makes you use a state machine--this is actually a decent question for a whiteboard as long as you don't do something stupid like use J-K flip flops in CMOS. There are a host of basic questions you can use ... but beware of traps.
I was once asked the following question: "You have a serial bitstream that represents a binary number. Keep track of the value of that number modulo 3." This is a decent question ...
Or a really hard question ... depending upon whether the number is being clocked in MSB first or LSB first.
Unfortunately, when I wrote the numbers down on the whiteboard, I chose the "hard" direction. And had to really think ... and the interviewer kept getting more and more agitated and finally complained "Look, this is easy, just do 3 states like this". To which my response was "But clock in any of the numbers in that I wrote on the board. Your machine fails at the second clock."
His machine, of course, works just fine for one direction. But that wasn't the direction I picked and documented picking by writing it on the whiteboard. And his machine didn't work with the bitstreams I chose. And 20 minutes wasn't enough for me to see what he got wrong and demonstrate it back. And he didn't understand his question well enough to flag the reverse order.
Exercise for the reader: There are two answers to the question depending upon MSB-first or LSB-first. One answer only requires 3 states. The other answer requires 6 states, but it is NOT clear that 6 states are enough without some serious thought (you can prove 6 are enough inductively if you are clever).
2) I used to always bring to electrical engineering interviews 2 printouts with the same program--one in Python and one in Perl. This meant that when I was asked "Do you know Perl?" I could force the interviewer into MY subset of Perl--and I could explain why I avoided Perl nowadays with a compare and contrast. This simply steamrolled all but one interviewer.
3) I was interviewing with an RF company who was needing VLSI digital designers. A poor slob of an analog engineer drew the short straw for handling the digital questions and was so completely out of his depth that I felt sorry for him. After about half the interview of glazing his eyes with advanced digital architecture, I threw him a bone. I made an off-handed comment about digital really not being digital and how the old audio guys used to use the 4000-series CMOS inverters as audio amplifiers. Baited and hooked. We spent the rest of the interview discussing that as an audio amp (of course, I knew the answers to that question cold--that's why I mentioned it).
4) As an interviewer, I used to run a really difficult section of the VLSI design loop which used to intimidate candidates horribly. I had very stern words with HR that my section was supposed to always be at the end (we almost lost a REALLY excellent candidate because he hit me first, did excellently but THOUGHT he bombed, and then flubbed everybody else afterward). I only had a couple of questions, but they were bottomless. If I had a PhD in front of me, I could make him explain complicated things. If I had a newbie in font of me, I would take him one step further than he was comfortable with and see how he reacted. The candidate steered the interview, but within the bounds I set.
5) My favorite interview was when an interviewer asked me my own difficult question back. It took a moment until I realized exactly what he did, and then I launched 30 minutes into the bottomless pit until I was sure that everybody had glazed eyes and then some. We all had a good laugh afterwards.
The only answer is: memorize all the leetcode answers perfectly, and pretend you don't know the answer but that you're "working through it".
At places like Facebook, I heard that you're given several interviews with 2 coding questions to answer perfectly in 45 mins. It's basically luck of the draw whether or not you know the answer, and the best way to game it is by memorizing as many answers as possible. I know this is possible because I have friends that have gotten offers from Facebook and Google by doing exactly this.
All this does, of course, is create an arms race where interviewers ask harder and harder questions. It's frankly ridiculous unless we start taking the algorithmic portion away from the interview.
The arms race doesn't proceed all that quickly. Memorize a couple implementations of breadth-first and depth-first search, an implementation of longest common subsequence, and big O of some data structures, and you'll get surprisingly far in most big-tech-co interviews.
In a world where there is a massive shortage of developers you are the talent and the firms come to you to negotiate. Particularly in a world where anybody can look at your GitHub feed and see what you can do.
So these increasingly ridiculous interview techniques have a more sinister purpose. They are an extension of the frat tests to become part of an 'exclusive club'. It's just another brand trick to try and get you to invest so much time and energy into an application that if you actually get picked you will work for less money and worse conditions.
You might be the only applicant, but by suckering you in and getting you to jump through hoops you are less likely to walk away when you finally find out they want God on a stick for two pennies for 70 hours a week.
Look up psychological loss aversion and sunk cost. Humans hate to write things off and walk away.
If I'm hiring a developer I can look at their Github resume and see what style they are and how they work. Then really I need a chat with them to see if their personality fits with the existing team personality (ideally you interview them with the team. The team need to work out if the new prospect fits with their group personality, e.g do they think chickens with lips are funny). You pick one based upon that process and set them on a side job to see how they perform in practice. If they don't perform during probation you let them go and try again.
That is a far less costly process to go through than rigging up seven round interviews with everybody.
In some respect if you do set up a seven round interview process and invite applications you actually want to talk to those who declined the process. Particularly if they told the selector that it makes no business sense to have such an expensive and time consuming process and therefore there must be another reason for it.
Because those are then the ones who can look at the system from the perspective of the other guy, work out what is actually happening rather than what people think is happening and then determine it isn't efficient and can be improved. Which is usually what you are after.
> Generation Y interviewers (between 20 and 30): Bring along visual samples of your work and highlight your ability to multitask.
> Generation X interviewers (between 30 and 50): Emphasize your creativity and mention how work/life balance contributes to your success.
> Baby Boomer interviewers (between 50 and 70): Show that you work hard and demonstrate respect for what they've achieved.
This strikes me as an incredibly ageist thing to do. Even looking at the "suggestion" for my supposed group — what? No; answer the question as correctly as you can; if you can't, try to reason though it as much as you can, and try to convince me that you know something.
Some of this is good, but that part in particular … just no.
I think that competitive programming, the kind of programming done at IEEE / ACM competitions as well as interviews, is very different from actual day to day programming.
It tells you the person understands data structures and some aspects of programming, but translating that to productivity/success is questionable.
In addition to competitive programming you've got "collaborative programming". Programming for maintainability, growth, construction for verification, good practices, etc.
A good programmer has a balanced combination of both.
I like to make the distinction between being a good "programmer" and being a good "professional software developer". Lots of good programmers aren't necessarily good professional software developers.
I usually make it a policy not to bad-mouth my fellow coders, but I once worked with a BRILLIANT developer, knew all the trivia, rocked his interview, impressed the hell out of all of us.
He then spent two solid weeks building an email address validation micro-service. It was perhaps the most exquisite and technically correct email address validation micro-service ever built, but was that really what the business needed?
This happens when there's not a very clear expectation on what the deliverable is.
Some people have a better intuition than others when it's moment to capture those requirements. Maybe it's better to spend a few more minutes doing the requirement analysis to set those expectations clear.
Now, sometimes people tend to underestimate some things. URLs for instance, similar to e-mail addresses, can seem trivial to deal with at first but they're actually more complex than people intuitively think. Incorrect handling of URLs is a significant attack vector.
I think what the GP is implying is that even a 95%-accurate email address validator would suffice, because any email address you care about is going to get further validation when you validate the address as functional. So it's wasted effort, and suggests poor business sense and a need for close supervision.
That doesn't really say much about their skill. All Norvig says is that people who are good at competitive programming are used to quickly solving problems and move around, and that probably isn't good when it comes to real world engineering. I don't think that attests to their quality in writing code, more about the environment they are used to working in. If there actually was a net loss in hiring such candidates, the major companies would stop using that as the filtering criteria to begin with.
"Doing what you do to seek for what you desire is like climbing a tree to seek for fish." - Mencius
Coding interviews test for skills that aren't really the same skills you need to do well as a software engineer. I'm surprised the industry hasn't found any better way to evaluate job candidates yet, given how much is at stake.
I have a request. When someone takes the time to travel to come interview with you at least do them the courtesy of providing useful feedback if you decide not to hire them.
I have an idea to run mock interviews online with real HR people moonlighting, so that you can receive their honest feedback, and as a result, be better for the real thing.
I had an idea for a startup that I think could be a much better solution than code interviews.
It hinges on the fact you can get a much better sense of a developer after you've worked with her for a few weeks.
So, here's the startup idea:
Hire a group of developers to to work with you on a small project for a few weeks. They come in as a (virtual or real world) team and build something you've been meaning to do, but it's on your low priority stack.
All of the developers in that group are actually looking for a full time job. As you work with them during those 2 weeks you can see which dev you gel with best and offer them a job.
In the mean time, all the devs get paid for doing useful work for you for a short period of time, even if they don't get hired.
So... the startup is a central agency that engages developers looking for a full time job and then hires them out as a group to help clients do a small project, with a view to picking one or more of the developers for full time work.
This is a win for the agency because they have to do less work to convince a client about a candidate. It's a win for developers because they get paid to be on job interviews. And it's a win for the client because they get to try before they buy and as a result will make much higher quality hires.
Possible brand name: TeamHire
Edit: If you like this please feel free to take it and run with it :)
This already (somewhat) exists with contracting firms. My team is mostly people hired this way.
The problem is that the contracting firms still want to stuff your office full of their workers, so we still need to run diligent interviews. (This means making sure that they don't coach the candidates through the interview, because once the candidates are coached, we can't really evaluate them.)
The good news, though, is that we get much better results working with a firm like this. Most of the people we interview we hire, unlike in the past, where most of the people we interviewed were straight up morons.
I think, with the right platform (ie like hired.com), you could automate much of that initial process of deciding who you wanted to be part of your team.
I think you could do something like night or weekend teams. They could work in a virtual capacity in a hangout, or they could come in if they were close by.
Getting deja vu reading this several years ago. I think someone, maybe Stack Overflow, actually did this as part of their hiring process. I think the devs that were brought in were even paid for their work during this time.
Seriously, though, that's not a bad idea. I've seen similar startups that pre-interview a bunch of candidates (instead of farming them out for small jobs), so this is a different take to solve the same issue. Both sides get a chance to win, either way.
I'm not related to this in any way. I'll just say I paid the money recently and went through interview cake and it was really helpful. Learned a bunch and added a bunch of tools to my toolbox. Really liked the walkthroughs of problems bringing it from a brute force answer to optimal. I ended up making it to onsite final interviews with five companies in SF, which I will be going to in the coming weeks. Totally worth it.
Only gripe, the online ide you use sucks balls. Half the time I'm debugging whether I used tabs or spaces, and dealing with errors. No matter how careful I tried to be, it seemed to default to whatever I wasn't using and threw errors. Please get a new ide and add in some test cases that maybe tell me how I'm doing in those tests.
What I would really like is the ability to ask my interviewers (or better, the team I'd work with) a lot of questions - both technical and otherwise.
After all, the interview is supposed to be a two-way process. But they usually give the candidate a lot less time to ask questions.
They want to ask me all the difficult questions to see if I'm good enough for them. And I likewise want to ask questions (fairly basic ones) to see if they're good enough for me. Few things suck more than the company demanding a lot from their candidates, and then sticking you in a team with people who don't seem to know the basics.
While this is imho in a much nicer format, I also maintain a somewhat opinionated list of technical interview resources: https://github.com/andreis/interview
If its just memorized without understanding, probably not.
But I've been doing a bit of the leetcode/hackerrank challenges lately, and believe it or not, I actually think it has made me a bit better, by refreshing bits of knowledge that were getting stale, and really forcing me to think about performance (many test cases in the challenges will fail without the fastest implementations).
"What happens when I'm asked a question like X? I spout a mutated form of some canned response I cribbed from a list I found on HN a while back. Because I hear that's how you're supposed to 'rock your coding interview', these days."
3. What are the things you should consider if you were writing your own database server?
"Look, you know as well as I that this job has nothing -- as in, nothing whatsoever -- to do with actually building production-grade database servers. Or anything even remotely analogous to it. Debugging that tangled mess of poorly conceived, never-reviewed JSON APIs left behind by the other developer (while you were pestering them about 'disruption' and 'just needing to get this thing to market') is more like it."
"But hey, since you're playing that game, I can play too: here's a bunch of catchphrases like 'non-blocking I/O, sharding, blah blah.' Because I hear that's the killer answer to give to questions like these. And BTW, if you really think that people Michael Widenius or Salvatore Sanfilippo would be interviewing for this job, then your problems are way bigger than I could ever hope to help you with."