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.
>> 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.
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.
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?
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.
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.
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.
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.
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.
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?
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.
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.
> 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.
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.
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.
[+] [-] kylnew|7 years ago|reply
[+] [-] maxcut|7 years ago|reply
[+] [-] gaius|7 years ago|reply
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.
[+] [-] jopsen|7 years ago|reply
But an engineer who can't reason about DAG, topological sorting, etc, could easily ruin an otherwise elegant architecture :)
[+] [-] nlawalker|7 years ago|reply
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.
[+] [-] meritt|7 years ago|reply
Some companies prefer to hire people who can write software.
[+] [-] timClicks|7 years ago|reply
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
[+] [-] xtiansimon|7 years ago|reply
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?
[+] [-] mianos|7 years ago|reply
[+] [-] User23|7 years ago|reply
[+] [-] jumper_F00BA2|7 years ago|reply
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.
[+] [-] gameguy43|7 years ago|reply
Down to chat about coding interviews and answer questions here!
[+] [-] derpistan|7 years ago|reply
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)
[+] [-] bogomipz|7 years ago|reply
I couldn't help but notice that Golang was conspicuously absent from the list of languages. Might you be adding that in the future?
[+] [-] hmottestad|7 years ago|reply
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.
[+] [-] stochastic_monk|7 years ago|reply
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.
[+] [-] deckarep|7 years ago|reply
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.
[+] [-] cup-of-tea|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] A_Person|7 years ago|reply
"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:
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?
[+] [-] clarry|7 years ago|reply
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.
[+] [-] Veedrac|7 years ago|reply
[+] [-] gav|7 years ago|reply
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.
[+] [-] idontpost|7 years ago|reply
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.
[+] [-] BerislavLopac|7 years ago|reply
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.
[+] [-] oreganoz|7 years ago|reply
But we both know they are not very much alike in practice.
[+] [-] rs86|7 years ago|reply
[+] [-] emersion|7 years ago|reply
[+] [-] newscracker|7 years ago|reply
Email != Gmail. It's one of the last decentralized systems holding up. Please don't stick one more dagger into it.
[+] [-] philphil|7 years ago|reply