Hacker News new | more | comments | ask | show | jobs | submit login
Data Structures Reference (interviewcake.com)
287 points by typpo 7 months ago | hide | past | web | favorite | 86 comments



I recently got double slammed with 2 graph questions during an interview after having navigated for years without getting a graph question. It's wholly irrelevant to my day-to-day work but I do hobby game development sometimes which involves more needs for graphing. Still, I can't do much of anything with a graph on a whiteboard. Puzzled as to why it's so important to some companies to grill on this stuff, expecting it to be top-of-mind, even for front end roles.


I have given a lot of thought to the interview process over the years. As a candidate I really disliked whiteboard questions and trying to come up with clever solutions on the spot with hard time and resource constraints. I was always frustrated with how different the interview experience was from actual day to day work. As an interviewer I much prefer a hands on experience with internet access. For that I have prepared a short app riddled with some bugs and half baked features to be completed. For me it is really important to see how a candidate copes with an existing codebase as most people work in environments with large and mature ones. It is also important as the interview progresses to see when and how the candidate resorts to online resources and how they conduct their search. Some just continue to bang their head when they encounter a problem or DFS into the first search result they encounter while others cleverly start opening a few tabs and evaluate proposed solutions before selecting the one that is most suitable for the current problem they are trying to solve. Most candidates after completing the interview stated that they preferred this method to 'traditional' ones and some even said that they enjoyed it.


Puzzled as to why it's so important to some companies to grill on this stuff

Because contrary to the narrative, there is no shortage of developers, there is in fact a glut so companies can not only afford to be choosy, they actually need to filter early to keep volume of applicants manageable. At least that is my interpretation of the evidence, I am curious if there is another explanation.

I can remember when there really was a shortage of developers, the dotcom boom. Companies couldn’t shove people in the door fast enough, an interview was a quick chat followed by “when can you start?”. Today it’s nothing like that. In a genuine shortage there is no ageism etc either, noone can afford it.


"Shortage" is always a funny term in these discussions, and it always starts a debate. It's too simplistic and disagreeable a term.

I agree with your point but I think it should be clarified. There is probably not a theoretical shortage of people who can be called "software developers" compared to the number of jobs available. But I find that shortages are relative. Companies make their own bars for who they're willing to hire, and how far above or below a given baseline level of competency they'd like to target.

Not all software developers with that title can be software developers at any given company. This is not just because they don't know the underlying theory or because they don't know "real" engineering. So it's much harder to discern if there's actually a shortage, because obviously not all jobs with the same title involve the same specialization or skill requirements.

I think that a more charitable interpretation is Google and other such companies use these interviewing practices because their ideation of a "software developer" is substantially different from the all-inclusive title. It's not just an arbitrary way to reduce the stack of resumes, it's an imperfect proxy for their actual criteria.


If you have read Cracking the Coding Interview, the author describes a guy who was hired in her company because there was super shortage of developers. The guy barely knew HTML. He used to come late to office, play ping pong and take off before sundown.

I believe things were quite similar in India during the dotcom bubble. Candidates were asked to do some addition programs, hir d immidietely, and within weeks their H1B was sponsored.


It's no secret that interviews at crazy, it's like an exam, and you should prepare accordingly. Yes, it's largely irrelevant.

But an engineer who can't reason about DAG, topological sorting, etc, could easily ruin an otherwise elegant architecture :)


> it's largely irrelevant

Maybe not. Wouldn't you prefer a candidate who did prep work before an interview rather that one who chose to wing it?


If they were just out of school and currently unemployed with no dependents, sure. Otherwise, memorizing answers to homework assignments from an intermediate algorithms course seems like a poor way to spend significant time for someone whose job/career does not actually involve repeatedly implementing well-studied low-level algorithms from scratch on a tight deadline with no ability to look up reference materials.


I'd definitely prefer someone who doesn't feel the need to prepare and cram for irrelevant trivia exercises.


Perhaps I do not quite understand what you meant by 'engineer that cannot reason'.

Somebody might not be able to write on a white board, during an interview a topological sort or find-a-union (https://www.hackerearth.com/practice/notes/disjoint-set-unio... ).

But does it mean that they will ruin 'elegant architecture'? (compared to somebody who passed the topologica sort exam)?

Also, wouldn't an architecture that imposes compile time constraints, good documentation and test cases -- on the usage of its most elegant pieces, be more 'elegant' than the one, that could be easily 'ruined' but somebody who does cannot write out a 'topological sort' during an interview?


Have you never worked with weak engineers?


I think their point is that just because someone can’t whiteboard something doesn’t mean they can’t reason about it.


Have you ever worked with arrogant ones?


The problem with using trivia as a hiring filter is it doesn't do a good job of differentiating between those who don't know a thing, and those who know nothing, unfairly penalizing the former.


But it is easy to filter out those who think they know something when they blurt out correct responses like machine. But in reality they just lerned canned responses. Usually you want to discuss problem to see reasoning. If there is no reasoning just canned response, that is big red flag. That person probably lacks any depth of knowledge and doesn't understand why the question is asked.


Can you predict engineering performance from whiteboard exams? I wager Ravens Matrices would do better than your whiteboard exams.


I did. Some of them, I think, would be able to pass these types of data structures test.

I observed 3 characteristics that they had. (not that I was thinking about this before, but since you posed the question...)

1) They lacked ability to leverage others people work.

(and with that, they lacked the ability to quickly review/search/understand available corpus of knowledge )

2) they were not afraid of complexity in coding, but they seem not be able to 'conceptualize a problem' at level higher than code and technical data structures So that produced very complicate/fragile system.

That, I would call too 'literal' in interpreting the immediate business needs. Normally business needs/requiremetns are observeable gaps in some existing process, or in a high level intent. And as such -- these requirements are not 'designed'. So literally interpreting them causes the solutiosn to be short-term, that look like small 'projects', rather than products.

Specifically, they were not able to design with 'composability' in mind. Where the flexibility did not just come from 'millions of configurable attributes', but instead would come from composing working, well defined pieces - together (at the level of data models & UIs, associated with each composable element, not just code).

3) When analyzing performance problems -- they tended to solve them by optimizing details, and not looking at problem statement itself.

In other words, in my experience -- there is rather huge difference between being able to 'find solutions' from existing corpus of knowledge -- vs -- 'being quick on ones feet' so to speak, and being able to code on white board, data structure algorithms on the interview.

I normally look for people who can construct& compose from existing pieces (that includes not just code, but also articles, research papers, analogies from solutions in other domains, etc).

So I tend to look for folks who demonstrate that they can parse large corpus of knowledge, learn quickly, and reason pragmatically.

Of course, as the person describes their experience -- I tend to look for clues on what they concentrated on, what they found difficult/easy, how they leverage other's people work and why. Did they contribute to open source/etc.

I am not sure if being able to write a topological sort on an interview, automatically precludes a person from being able to reason about composable abstractions. But I just saw folks who do well on these types of interviews, but then not be able to 'increase the average of my teams', that consisted of folks who could not write those things at the interview.


I mean, tsort is already a library function. The important part is knowing it exist.


>> Puzzled as to why it's so important to some companies to grill on this stuff, expecting it to be top-of-mind, even for front end roles.

Either they do consider it important to the role, or they are trying to select for young CS grads, or they just haven't tried to do any better in their hiring process, or they don't know how.


Maybe I’m not like the interviewers/companies to which you’re referring, but I ask a DAG topo sort question (dependency resolution/task ordering) not because I expect the candidate to regurgitate the algorithm but because I legitimately want to see how they work through a problem - especially one they may(hopefully) not be familiar with.

Most of the time I don’t care if they get the optimal algorithm, rather the can think through something and know where problems might be.

Might not be how/why the “others” use that question, but its worked well for me.


Because a large proportion of "software engineers" are simply people who know how to use popular libraries/frameworks to crank out a simple website or app (which often satisfies the needs of most companies anyway).

Some companies prefer to hire people who can write software.


Surely most interviewers are interested in things that are slightly more abstract than answers to specific data structure question.

1) has requisite base level of knowledge, 2) shows humility/knows own limits, 3) has an ability to explain complex ideas simply, 4) demonstrates an innate curiosity and 5) can work through problems methodically


Once in an interview a senior designer walked in on my interview. They were introduced. Hung out for a minute. Wrote something on the whiteboard, then left. My interview ended, I was left in the room for a minute and I stared at that frackn whiteboard wondering what that was about.

I didn't get the job, but I had to assume this was something that senior designer was into--something they cared about, something they used, a skill they wanted to manage, a subject they wanted to discuss.

User ItsMe000001 says he was asked about a 'right join', choked during the interview, was still hired, and later became the go to guy for writing queries.

If a question is in the interview, it's relevant to someone in some way unless it's a psychological mind-frack test.

So the question would be, Who was also hired, and later had their head flipped?


Same, in an interview a few months I got a graph one which I did OK in. Then I got asked to write an algorithm to determine if it is acyclic on not. I could remember the visitation flag but I could not remember, of the top of my head, which side of the recursive call it was on. I picked the later side and obviously failed as I didn't get any offer, although that was more likely due to my age. I dodged a bullet in the end.


Why would you have to remember that to solve it? This is the kind of thing I definitely wouldn't already know, but should be able to reason through.


Graphs are arguably the fundamental data structure. If you can’t think about objects and references between them then how do you write nontrivial software?


Yes but in normal programming it is uncommon to need to write algorithms that traverse the global object graph. You normally care about some local view of it.


It’s uncommon but it’s used once in a while. I do it 2-3 times a year at least. And believe me, most people wouldn’t even know how to start to do it or would think it’s too hard and prefer to do it in a different way so they don’t need to ever traverse the graph.


Would you happen to have an example or reference to that kind of problem?


When faced with questions that have answers I could obviously discern by writing and running two lines of code, I willfully shrug, answer by intuition, hoping that's the trap for the wrong answer, and wait for a facial expression.

Today I was asked a question about inheritance and references within a constructor, in which the answer was an either/or for the parent or child class.

I threw up my hands and deliberately said "I dunno parent, no wait! Child!" because honestly who cares, when you can figure something like that out without even googling for it.

A question like that is like asking someone what might they expect a Hello World! program to print.

Waste my time, and I waste yours right back. I could care less what you think about me.


I don't really agree with these kinds of questions, but to be honest I find your response to be pretty childish. In my opinion it would be better to be honest and say you don't really know, but that you believe you could quickly find out. But your response indicates that you have the potential to be passive aggressive and uncooperative when presented with a question you disagree with.

Now from the interviewer's perspective, they don't know you're absolutely fed up with the culture of tech interviews. They can't see the full interiority of your thoughts. So they can't know why you're reacting like this, all they can see is your behavior. Keep in mind that you're most likely punishing an interviewer who has either been given a mandate for these questions or who doesn't know any better. From your perspective this could be a teachable moment or a way to showcase your thinking.

Even though that might have been a poor question to ask, doing what you did doesn't demonstrate that your time is important. It demonstrates you might have problems being professional and communicating effectively. It signals that you think your time is so important that you're willing to potentially burn an interview to spite someone asking you a question you feel is beneath you.

It's not a good look. Don't give people reasons to write you off.


Sympathy for the interviewer. Well guess what, you're not going to find much luck pulling this yarn.

Some interviewers get the fist. And that's just the way it goes.

If I'm supposed to play toady to this dog and pony show we're trying put on together, don't step in front of me with some condescending question, that we both know is cherry-picked trivia. You design questions to stump people, knock them off balance, introduce a choke, and project a facade of superiority, when we both know that's not fair play, and you expect something other than contempt?

I'm not reciting all the state capitals, every U.S. holiday on the calendar, and every county in the state of California for you. Try your luck with the next applicant.

You can't expect me to roll over as subordinate, when I'm looking right at you, and you and I both know that the canned question you just asked is total bullshit. Sorry, now I know you're a follower, not a leader, and I won't be led by you. Interview over.

And besides, do you really believe that passive aggression, as a personality trait, isn't a possibility, simply because it wasn't on display during that particular interview. Most smart people do have a passive aggressive mean streak, because it's a tactic, not a personality trait. It's in everyone's tool kit, and smart people use it in anger. If it gets used on you, especially when everyone in the room was trying to make a good first impression, maybe you did something to provoke that.


So I can tell you're pretty upset about being treated this way, and I can sympathize with the frustration. But maybe my point will be better received if I clarify it to make it more concise. In essence:

1. You are responding to these kinds of interviews as though the interviewers are malicious, self-aware of their biases and intentionally trying to personally offend you. But it's not personal and not all interviewers are trying to conspire like this. Consider that what you're feeling and perceiving may not be intended by the interviewers.

2. As a corollary, your relationship and responses to these interviewers are retributional and deconstructive instead of educational and constructive. You're writing off companies because their interviewers offend your sensibilities. But just as interviewers don't have enough information to know why you're reacting the way you are, you don't know if they're trying to be as demeaning as you feel they're being.

In other words, not all companies with suboptimal interviewing methods are shitty companies. Probably most are not! Given that, the way you're reacting isn't just a sensitivity to personal offense, it's getting in your own way professionally.


It's on the person holding all the cards to display their power judiciously. Something designed to provoke undue stress is either glib or provocative, by default.

Don't forget, in this card game, you may be the dealer and the asymetric equation may be tipped in your favor, but play fair or some of the players might surprise you by throwing the game.

As "The Boss" you better not only know more, but also consider how put that on display. If you're actually in possession of gifted, multi-faceted intelligence, you won't need to read minds, so much as place yourselves in the shoes of the candidate, as you probe for awareness of facts, and exposure to subject matter.

It's often enough, to understand the conceptual interplay of known processes, before worrying about which color Teletubbie was the "funny" one.

abiox 7 months ago [flagged]

> it's a tactic, not a personality trait

that seems like a false dichotomy. you behave as cruel and abusive as you do because it's within you to behave that way.


When do you ever have to rely on 100% top of mind knowledge like that when programming anyway? I usually have a console open and google even fairly trivial things because of how much quicker (second or ~10) it is to look at the API than it is to get it wrong when reloading my code and having to try again.

Usually I challenge getting silly 'traverse this data structure' questions and want to hear what they expect to get out of it.

Side note: The correct expression is "I _couldn't_ care less"


I thought the same thing until I started doing a significant amount of code reviews. You need to know these things to explain to more junior devs to help them become better programmers.


Late to reply here, but you don't need to have the exact syntax and code at the top of your mind to review something. You just need the experience to recognise if something can be done in a different way or not. You can always google the exact improvement, implementation, etc later.


But that's the beauty of the human brain: It knows what is needed and you are going to remember very quickly all those things - when you actually need them. So if you actually have people to coach you will learn and remember all those things effortlessly and almost without noticing it yourself, but when your brain detects no use for something to push something into it by brute force is a pain. It's one thing to learn the basics, it's another to fill your mind with specifics needlessly.

I once had an interview for a very well-paid freelancer position in a large company and could not answer the question "What is a right join?". It's not like I don't know that stuff - I do, but it's strange: there are many things like that, I actually know them, but I have to look them up. I only need 5 seconds then I remember everything. But when asked out of the blue I'm clueless. I was hired - and I became the guy they asked when a large Oracle query had to be constructed to look something up in the DB. Today, right now, I again only have a fuzzy notion of "right join" and would have to look up the details. I happily remove stuff from working memory that I don't need - but one 5-10 seconds look at one of thousands of webpages describing joins is all it takes to have that knowledge back in my working memory.

There are many things that I could not answer when asked out of the blue in an interview, and yet I would claim "I know that stuff". It's not a contradiction. For the last couple of years I've been learning new things like crazy, thanks to edX and Coursera and years of time off work to recover my health. Over 60 (finished) courses thus far, many of them topics I never had anything to do with before (medical mostly). I happily shift knowledge in and out all the time, I noticed how impossible - and useless - it is to keep anything in working memory for long. I'm not sure I could name all cranial nerves right now, and I took several neuroscience courses, they were some of my favorites. Yet I would claim that I know the, I just need a quick glance at a page about cranial nerves and it would all come back.

I'm not a walking Wikipedia, and those kinds of interviews are only useful to test what someone had to deal with in the time just before the interview. Sure, it weeds out clueless people - and a lot of good ones.

What a lot of people commenting on the interview topic also ignore is again that brains don't work like computers: context matters - extremely. We have studies showing that people think differently depending on whether they walk, sit in a small room or a large room, with the exact same task. Being in an interview is not just "stressful" - it's a very specific situation. It cannot just be compared to other merely stressful situations. You can do very well under stress - but not under interview stress. Interviews are, for one, somewhat adversarial. People around you try to find your weaknesses, they will get rid of you if you leave the wrong impression. Later on the job when it becomes stressful people work with you instead, everybody as a team towards the same goal. Not to mention that finding a job is not exactly easy no matter how low the unemployment rate. The kind of stress of an interview compares to nothing in ones actual work.

After the neuroscience courses, here is extremely rough my mental model to explain learning (based on my own interpretation of what I learned, this wasn't part of the curriculum way too fuzzy for actual neuroscience):

It's not like computer (or paper) storage that you fill with "knowledge" and then it sits there ready to be used by "the CPU" (which the brain is not, the computer model to explain the brain is completely off).

Instead, it's like paths through wilderness created by things repeatedly walking the same routes. When you learn you create paths. Literally. Strengthening/weakening of existing connections but also creating and abandoning synaptic connections. But the paths don't encode the concrete knowledge! What in our (computer-centric) models are concrete individual items in the brain becomes the result of signals traveling all over, and a concept we consider one item is the result of waves of signals going all over many paths in the brain, and not just once but with loops.

So when you learn something you don't learn the concrete knowledge like a computer does: "Now it's in memory and in the original form immediately accessible". In the brain it's something else. What created the "tracks" is gone but the tracks are still there! You don't have the original item you learned available, you instead have the path that it created. What exactly that means is not quite clear, but obviously you know something. That something, however, is not a static item of knowledge, it's something dynamic! It becomes useful when you use it.

What you cannot expect is that you put in concrete knowledge and at any later point get the exact same thing out. That's what we have books and computer storage for, the brain does not work like that. Nor should it! We developed those external tools to extend our brains, why are we trying to let our brains be like our tools? Yes, brains are much less predictable. Even from person to person, giving them the exact same knowledge creates different paths in each person's already different brain, and what you get out after feeding them the same input is even more different. Since we have become obsessed with creating predictable results we prefer testing in a way that would work better for how you would test a computer system.

I think something pretty much always overlooked is this: The brain does not attempt to encode the concepts that we talk about (such as "house", "tree", "friendship", "database"). It is the opposite. Our language attempts to represent the inside of our brains, in an approximation that depends on the goal and the context. For maximum confusion we then created new stuff within that externalized language system - and then try to put it back into the brain. There is nothing solid about it, it's all very dynamic and fuzzy. I see communication between humans more like trying to synchronize different dynamic systems. "Fire and forget" (send information and expect it to be understood) only works when there was a lot of prior synchronization. That means when new people meet in a new context (for at least one of them, in an interview) it will go more smoothly if they all share the same base synchronization, the same background - but that may actually be by accident. Out of tune communication partners might actually get better results after they "synchronize their waves". The "tuning" also is not between two fixed systems, both keep changing.

What I look for in new people is not how they are currently tuned but their "tunability", especially "auto-tunability". That means I care more about how much they do on their own to find things out. When an employee does experiments on their own, finds things out that nobody asked them about, digs deep into a problem without waiting to be told to do so - to me that's far more valuable than any amount of static knowledge.


If all the questions were relevant and had objective solutions, they would be put into a lot of situations where they have no justifiable reason to reject somebody that they would prefer to discriminate against.


Founder of Interview Cake here. Thanks for the post!

Down to chat about coding interviews and answer questions here!


Hey, I just wanted to say thank you for Interview Cake in general. Your approach of unravelling the solution gradually really helped me think about these problems.

While it wasn't my only resource, it helped me a lot interviewing for Facebook and Google recently, and I got offers from both.

(throwaway account for obvious reasons)


Like your throwaway account handle.


I like you too.


:)


Your site looks interesting.

I couldn't help but notice that Golang was conspicuously absent from the list of languages. Might you be adding that in the future?


No /specific/ plan to add it yet, but it’s on our radar. Definitely the most requested language.


Hi. I got an interview question a little while ago that the interviewer said “was not a datasteuctures/algorithm question” because it was too specific. I call bullshit, but I don’t actually know what the algorithm would be called.

Problem:

A tree of resources that you can get granted access rights to. When you get access to a node in the tree, you inherit rights to children transitivley. You can also have rights explicitly blocked. The ordering is important. An example, you start of as head of IT and have all the IT stuff granted, but explicitly no access to the IT security department. Then you make CEO and are granted right to everything, so that should overrule your previous restriction for the IT security department.


The problem you described doesn't ask a question. What are they asking you to do: implement the described data structure (not enough information), or untangle their department hierarchy?

I think the correct answer is "IT Security should be a peer of IT, not a subdepartment."


Hmmm. Can't get in your interviewer's head, but here's my guess: this might be one of those questions where the bulk of the discussion is supposed to be about weighing tradeoffs of different choices for the data model.

For example: how do you store the explicit blocks? More specifically, how do you articulate that head of IT is blocked from this subtree, but the CEO isn't? Some options:

- store the block as pairwise (individual, subtree)

- same idea, but instead of blocks you store explicit /allowances/ (and allow a tree node to have a flag set of "ignore the tree-based permission system here, and just lock everyone out who doesn't have an explicit permission")

- instead of blocking individuals, you could add an abstraction layer, e.g. user_groups, and assign permissions to /groups/.. You could also add an abstraction layer on top of the treenodes themselves (object_permission_groups?). Different tradeoffs with these options.

Again, hard to know exactly where your interviewer was trying to steer the conversation. But that'd be my guess!


The more I think about it, the less I understand why you'd ever need to explicitly block permissions. Permission groups are a good idea, but since the interviewer said it's not a data structure or algorithm question, I think it's trying to elicit problem analysis from the interviewee. What are the use-cases for blocking permissions? Why can't you just refactor the tree so that all assignments are allow? Using a mix of allow and deny is convoluted.

It seems like a trick question designed to see if the candidate is willing to question assumptions.


It seems pretty similar to how aws access controls work. By default everything is disallowed. Then you can gain more permissions explicitly. But an explicity deny overrides all explicit allows


Hmmm, since they specifically said it's not a data structures/algorithm thing, maybe they're looking for other aspects?

One potential that springs to mind is (say) governance or oversight considerations of the given situation?

Not sure how that'd apply directly either though. Feels like there's more info needed from the interviewer first, to give a hint as to the direction. :)


That would be an access control list (ACL). Find all the matching rules then process them top to bottom keeping track of whether access to the specific resource is allowed or not. Runtime is O(n) where n is the number of rules. There could be improvements but this is pretty straight-forward.


It’s pretty much your meat and potatoes data structures, excepting hash maps. I think a basic understanding of them and collision resolution strategies would benefit a learning developer. (And I'd suggest considering adding them.)

And, as an aside, I’ve found in practice that combining these lego blocks, allows you to build the sorts of specialized, efficient solutions you need.

Perhaps you could add an example of doing that, such as combining a queue with a binary search tree map to emit minimal values over a window. This would be a case where the sorted property of the tree is actually useful, as well.


“Hashtable: like an array but instead of an index you can set arbitrary keys for each value.”

This sounds like a gross over simplification of what a Hashtable really is underneath the covers.

Any candidate that shows up with that definition better be ready to dive in on what it really is and when you’d want to use it.


That doesn't even describe a hash table, it describes an associative array, or map. A hash table as one way to implement that, the other main one being self-balancing binary trees.


Or more broadly, self-balancing trees (the best performing balanced tree, the B-tree, is not generally a binary tree). And then there is the skip list.


Yes, quite right. Is a B-tree worth it when the structure is fully in memory, though? I would say that when talking about maps people are thinking of in memory structures.


It absolutely is! You get significantly better cache utilization with a B-tree.


It just amazes me that employers ask complicated CS-type questions for ordinary programming jobs. I've been out of the game for 20 years, and only did a few interviews anyway (as the interviewer), so what would I know! But FWIW, here's the kind of question I'd ask.

"I'm going to write a few lines of code on the whiteboard, tell me what you think of them." The code would be something like this:

  If f(a,b) then
    X=6
  Elseif flag1 then
    X=8
  Endif
My bet is, people would fall into one of three camps.

(1) The Bemused :-)

These people would have no idea what to say. That would be fine for a new developer, I'd just prod them in the right direction. For example, "what do you think about inline constants?" But if an experienced developer had nothing to say about that code, that would be a big red flag for me.

(2) The Defiant!

These folk would say, "Gee that looks like very old code, I'm really more interested in functional languages, do you guys do any Haskell?" This would also be a big red flag. First, he's saying that he has no interest in my priorities as the interviewer, he'll just ignore my questions and substitute his own. Second, he shows that he's not really interested in code as such. It's like a guy who says he likes cars, you take him around the corner and show him your one-off Porsche EVO hybrid, and he says "Wow, an infinity pool! What did that cost?" Fail.

(3) What I'd Expect

Here's what I'd expect from an experienced developer, off the top of his/her head:

"Ok, I see in-line constants, and short variable and function names. Those are often undesirable, I can talk about that more if you like.

But the more interesting thing, is that X is only set if one of the two conditions is true. If neither condition is true, X does not get set to anything.

That might be a bug: the programmer meant to initialise X before the first test, but forgot. Or perhaps X is initialised much higher up. But if that was the case, I'd like to refactor the code to bring that initialisation closer to the code on the whiteboard; and/or rename X to something less likely to be used by mistake in the middle; or at least, add a comment saying "X initialised above". Or you could just add an else branch to the code on the whiteboard, to ensure that X gets set even when both conditions are false.

Another slight possibility is that when the first condition is false, the second condition is necessarily true, and the developer has written in the second condition as a form of comment. But in that case, I'd rather make it more explicit, by changing "Elseif flag1 then", to "Else /* flag1 must be true */"; or even asserting that, just to be sure.

Also, if the code in question is really complex, or just messy from years of maintenance, there might still be cases where X does not get set at all. In that case you could initialise it to an impossible value, say NULL, right at the start, then assert not null at the end. Or you could even re-write the code in truth table style, which I can talk about more if you'd like."

Me: "The truth table approach sounds good. How would you do that? What kind of data structures would you use?"

And so on.

Does everyone really use CS-type questions these days? Does anyone take the different approach displayed above?


I have to agree with Veedrac and idontpost.

My first thought is, "This looks like a snippet of code completely made up or taken out of context and then anonymized by renaming variables. I have no idea what it's supposed to do, I have no idea why I'm looking at it, and I have no fucking idea what the interviewer wants form me, and I don't play guess-the-rules type of games." If this were real code, I'd have context. Not just a snippet. I'd see the things I don't see in the snippet, and I'd know why I'm looking at it and what I'm looking for. In real work, there is always a motivation for everything you do. In this case, there is none. You might as well show a sequence of bits. "What do you think of these bits?"

So by your prejudice, you'd probably categorize me in the first camp. Congrats, you probably turned down someone who's been coding for 20 years. Then again, if this really is the kind of line of business code you regularly deal with, maybe it's for the (my) best.

This is a pattern I see all the time. Interviewers come up with their games with their arbitrary rules and a bunch of prejudice about how a good or bad candidate should react. They think they came up with something clever, they always do. They have no idea.

I get the impression that good people get regularly turned down because they didn't guess the rules of the game right, or they don't even play because they got an offer at some place that doesn't play these silly games. Then there is so much complaining about talent shortage, and complaining about terrible interview practices, and complaining about having to deal with a stack of 1000 job applications.


> Interviewers come up with their games with their arbitrary rules and a bunch of prejudice about how a good or bad candidate should react.

Agreed that a lot of interviewing issues that I've seen boil down to a misunderstanding of the rules/expectations of an interview, which can be problematic on both sides. Some examples:

* I've had candidates do poorly on a warm-up question because they expect it will be difficult. Ideally, they would say the easy answer they know, but I've had candidates stay quiet while thinking of a hard solution that doesn't exist, then get frustrated when they find that the easy answer is what I was looking for. On my end, this problem is especially tricky because I don't necessarily want to say that something is a warm-up question.

* I've had candidates who have had trouble because they viewed problems as either too concrete or too open-ended. In some cases, I hope that candidates will notice ambiguities in the problem and ask clarifying questions, or come up with creative alternate solutions. In other cases, I know that a particular high-level structure makes a good, consistent problem, and I want them to follow that structure.

* I've had candidates who have written code that's either too hacky/messy/unpolished or too professional such that it slows them down.

My best advice to interviewers is to be straightforward about expectations and open-minded about what assumptions the candidate might have coming in. For example, these days, I try to explain the code quality balance I'm looking for, something like "I'm looking for reasonably production-quality code that might pass code review, but it's still an interview setting, so it's fine to leave off things like docs and unit tests".

I think my best advice to interviewees is to keep a conversation going and be open about your thought process and your assumptions. If you're interpreting the problem wrong, a reasonable interviewer should be able to notice and correct that. The main failure mode I've seen here is people being hesitant to communicate their thought process or ask clarifying questions, which means the interviewer isn't able to know when the candidate is doing poorly because they've misunderstood the problem.


The last two places I interviewed with, there was none of this puzzling or challenges or problem solving. No warm up questions. No games, no rules. We just had introductions and then chatter about what I've done, the tools I've used, how I prefer to work, that kind of stuff. The second place didn't even ask to see any code even though I'd prepared to show them some and had my laptop open on the table. I presume both places trusted I know how to code and solve problems, since both offered a position and even tried to outbid each other.

I really liked this type of interview. It's not so much an evaluation of coding skill as it is a way to get to know the candidate.

With offers lined up, I turned down interview invites from other shops that were publicly complaining about talent shortage and simultaneously had a needlessly complicated & time consuming interview pipeline. I think companies are overthinking it.


I'm truly bemused by your response.

First, if you truly believe that the code I showed is "a snippet of code completely made up or taken out of context and then anonymized by renaming variables", I can only say that I don't believe you've ever worked on large codebases. There are millions of lines of code, in hundreds of thousands of application, in dozens of different languages, all over the world, precisely like the snipped I showed. If you've been coding for 20 years, as you say you have, and haven't seen snippets like that on a thousand occasions, you must have worked in very strange environments. If you really want me to, I'll spend 5 minutes and give you multiple links to exactly similar snippets in various large open source projects.

Second, I'm mystified by your comments regarding my trivially simple code question. that "Interviewers come up with their games with their arbitrary rules and a bunch of prejudice about how a good or bad candidate should react".

Wut? Let's make the question even simpler:

    X := Y / Z
Would you not expect an applicant to say, "What if Z is zero?" ? Would you actually expect the candidate to say - quoting you:

"This looks like a snippet of code completely made up or taken out of context and then anonymized by renaming variables. I have no idea what it's supposed to do, I have no idea why I'm looking at it, and I have no fucking idea what you want from me, and I don't play guess-the-rules type of games."

Are you seriously telling me that you'd hire a candidate who said that? Over one who said, "What if Z is zero?" ?

I think one of us is missing something...


Once again you posted a snippet without context or meaning. Once again it's like "what do you think of these bits?" Except that you didn't even ask a question. You just posted something that is presumably code.

So it's hard to engage meaningfully. Give me motivation. Tell me what I'm doing or why I'm looking at this code in the first place. Show me the context and maybe I will see whether I should care about Z possibly being zero or not. Tell me what the language is or how it handles divide by zero (does it have exceptions?) and I might figure out that we don't give a fuck about divide by zero because it's handled elsewhere or not at all relevant to this snippet. I regularly write divisions without zero check because I know the divisor is a positive compile time constant. Here, I just see a snippet out of context; again my thought is "what the hell does this guy want from me?" Show me real code with real context and a real purpose so we can talk real talk.

What's wrong with my x /= z;? Nothing, it's doing the perspective divide just right. And you don't go about checking for divide by zero because I've already clipped my primitives. There's nothing wrong with the names either.

Sure the snippet you posted could be a snippet from some real codebase but without context it is nothing. What do you think of 100101010100000100010001000110? Sorry, wrong answer! Next guy please. That's also real binary from a real file and it's easy to figure out what it says but hard to say what I want from you. Try it!

> I can only say that I don't believe you've ever worked on large codebases.

I don't suppose the operating systems and web browsers I've worked on are the largest of them all but damn. You can keep your religion though.


> it's hard to engage meaningfully

There we agree!


In a parallel universe, a candidate who is worried about a divisor of zero has his head stuck in the tiny details and is unable to do big-picture thinking. Personally I've gone my entire career without seeing a divide-by-zero bug. It's the last thing on my mind. If it's possible for Z to be zero, it will be caught in CI before we deploy/cut a release.

In your first snippet, would you expect a candidate to tell you that `f` might be undefined?


> In your first snippet, would you expect a candidate to tell you that `f` might be undefined?

No. Because I'd expect the candidate to focus on subtle issues, and not waste time on bleeding obvious ones!

Of course f() might be undefined. Blind Freddy knows that. But Blind Freddy can't necessarily see the other (much more subtle) problems in those 4 lines of code.

I want to know, is this candidate more than Blind Freddy? Does he inhabit what some of us call "the real world", where things like division by zero are things to be consciously managed by proper coding practices?

(Edits for clarity)


As someone who has worked on several legacy JS codebases, I can tell you with certainty that in some kinds of projects you'll find in the "real world", `f` being undefined is infinitely more likely than a divisor being zero. Maybe Freddy isn't blind. Maybe he just has a different background than you.


Quite possibly. I've worked mainly in languages where undefined functions kill the compile, and division by zero is a runtime error. Perhaps JavaScript just facilitates sloppy coding practices? Many other languages don't. Perhaps you're the one with the skewed perspective!


Wow, congrats on insulting people who use a different programming language than you. You really give an air of professionalism in your speeches.

But its the lack of communication on your front that would make people fail your test, not their lack of competence.

Anyone can summon an obscure puzzle and claim its easy when they know the key.


> who use a different programming language than you

isn't this a bit reductive?


> Wow, congrats on insulting people

I posted a detailed exposition of my own approach to interviewing. I expected nothing more than some intelligent comments thereon.

In response, someone says I'm "prejudiced", and why would he "give a fuck" about my concerns; another says my concerns exist "in a parallel universe"; and another says my views are "religious"!

Equeeze me if I don't take well to copping random insults in what is meant to be an intelligent discussion forum. Particularly from people who've contributed zero to the discussion so far - like you! I suggest you get out of the basement and get some exercise. Maybe ask your mum for a bike?


Asking someone to evaluate code that doesn't mean or do anything seems like a very poor idea. 90% of the important questions are whether you're doing the right thing in the first place, not whether you're using the Hot Trick of the Day.


Huh? (1) It's exactly the kind of code that you'll commonly see in a working line of business application. (2) The entire point of my comment is that I dislike hot tricks of the day as interview questions. What "hot trick of the day" do you see in my post?


> Does anyone take the different approach displayed above?

I do. I find getting people to reason about code is a great method of finding who can program. Given we read a lot more code that we write, it's a critical skill. Often people seem to get hung up on the stylistic issues though and don't recognize obvious bugs.

More importantly, it's code _they_ didn't write, so it removes the natural inclination to be defensive about it.

One time an interviewee told me the problem was that the code was in Java. I told them that the majority of the code we write was in Java (as per the job description). They told me that our best option was to rewrite everything in Ruby.


Wow! That sounds like a fail to me :-)


I hope you're more communicative about what you're asking in person than that one liner you introduced the code with here.

I'd fail your interview just because I don't think about whiteboard code the way I think about production code. Yeah, the variable names and magic numbers are bad practice--but it's on a whiteboard. I'm not going to waste time writing long descriptive names out by hand on a whiteboard or in pseudocode. It would never occur to me, because of the context, that you're asking me to respond like I'm reviewing production code unless you specifically said that.


> I don't think about whiteboard code the way I think about production code.

Isn't that the whole point of an interviewer writing code on the whiteboard? To see how the applicant would view that code if hired to work in the offered position? Why would an interviewer want the applicant to view that code in any other way? Is an interviewer likely to think, "I'll treat the interviewee's comments as if he was just writing the code as a hobby throwaway, nothing to do with the offered position"?

> the variable names and magic numbers are bad practice / but it's on a whiteboard. I'm not going to waste time writing long descriptive names out by hand on a whiteboard

Great! But in my post the interviewer wrote the code on the whiteboard. The interviewer did not ask the interviewee to write any code on the whiteboard. Where did you get the idea that the interviewee was to write on the whiteboard? Software development requires attention to detail, yes?


Well, both types of trees mentioned in the article are just subtypes of graph, which has numerous other subtypes.

I love this sentence from the technical docs of the NetworkX library, for pure surrealism: A lobster is a tree that reduces to a caterpillar when pruning all leaves.


By that logic, lists are just trees with one child per node. Except graphs are just 2d lists if you define them via an adjacency matrix. So we've come full circle.

But we both know they are not very much alike in practice.


This could benefit greatly from specifying what operations are available for each structure.


Damn. Too many javascripts on this page, including Facebook's. I guess I'll pass.


Off topic. I really got turned off by the "me@gmail.com" placeholder in the signup form at the bottom of the page. So I decided not to sign up.

Email != Gmail. It's one of the last decentralized systems holding up. Please don't stick one more dagger into it.


Good one but this is even more comprehensive: https://news.ycombinator.com/item?id=17427190




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: