This individual seems to be rather clueless about the goal of interviews. When they ask you a question, the intention is to ask something that you don't know off the top of your head to try to get a bit of insight into your thought process. A maze solving problem is a perfect example of this. They're not asking you to recite A*, they're asking you to share how you'd go about solving it. So you might start by drawing a simple maze and interpreting your own thoughts into general control flow and then convert that into an algorithm. In fact simply code dumping A* would probably result in the interviewer asking a different question as that response is almost as useless as "I'm not a recent college grad. You expect to have this memorized?!?!?" The fact this individual is seemingly incapable of producing algorithmic thought without having memorized it is most likely the reason they were not getting hired for anything. All the above applies 100% for Google who has the reputation as a tough interviewer. Your credentials get you in the door, they don't get you the job. Your display of skills and logical/creative thinking gets you the job.
While I agree with your statement about the goal of deeply technical interviews, the most important point of the article is "why am I doing algorithmic interviews when I'm applying for a front end position?"
While there still might be some merit to testing someone's problem solving skills, front end work tends to involve few to absolutely no algorithmic problems, and is generally very simple, and more about understanding the process and usage of the front end frameworks you use. I think if this guy was interviewing for a position that involves heavy data manipulation and storage, then sure, these are interview questions are quite important. That's generally just not the case with front end dev.
Maybe he should tell them that? I'll admit I'm rubbish in interviews, even having told people that their project was doomed to failure and only an idiot or masochist would work there, but I people do still seek me out and I occasionally get interesting work.
He probably should, so long as he doesn't come across as a whiner. He should at least ask (when scheduling an interview) something like "As I'm applying to be a front end dev, how technical or algorithmic is this interview going to be?" It's a perfectly valid question, and at least gives him time to prepare so he's not blindsided.
The complexity of front end work is determined by your level of seniority and what kind of work the company does. I've written entire validation frameworks for the front end. The work ended up being pretty complex. I don't think it's unreasonable to expect front end devs to have some basic algorithm knowledge. A depth first traversal is trivial, you do that kind of thing regularly.
Even so, interviews aren't just a test of knowledge, but of personality. It's about learning - How does this person approach problems they're unfamiliar with? How will they respond when they don't have the answer memorized? I'd rather watch someone struggle to think something through and then finally admit - "I'm not really sure, I think I'm close but I'd have to ask around or do some googling at this point." Rather than throw their hands up and whine about algorithm questions in front end interviews. No one is going to hire the latter.
I don't know shit about algorithms, but I'm a Lead UIE because I can build shit. When I get contract work sometimes I can tell they're just testing the water and planning to put up an offer in 3 weeks. I've based my entire success on proving I can build complex features without having a C.S. degree whatsoever, hell I was a graphic designer (really just a production artist) prior to getting into heavy JS programming.
The interview questions for a frontend, if you want someone who can produce, should really be about pre-processors, CSS/JS technical, HTML accessibility, RESPONSIVE experience and practices, maybe some SVG data charts, ask them what their opinion on jshint or semicolons are (frankly they don't result in higher quality UI code, but "feel" like that's the case).
That said if I interviewed at Google I would expect to hear performance questions which could be very difficult to answer (I'd point to Matt Bynens, Nick Zakas, JD Dalton blogs).
As far as inverted binary trees go, I'm sure someone has a job to handle that already.
Many of the big recruiters reach out to me (Amazon, Imgur, Microsoft, Adobe, etc) but I don't bother because I know their interviews aren't for me. Just have me prototype something and you'll probably want me on your team. And yes, it doesn't have to be my niche (Angular on Rails), ask me to prototype something that's not my niche and the result should still be strong. I've worked on a dozen platforms (PHP CMS, proprietary CMS ~x3), .NET CMS, Rails CMS, Phonegap), and delivered every time. You'd think the ability to ship features over multiple years and systems has value...
If I'm hiring a software dev specifically and solely for the rote UI work then sure. But if I'm not some accounting software company that survives by grunting out yet another quarterly revision of the same mediocre software package, then I want someone who can do more than just the grunt work, I want a team member who can analyze new problems and create new algorithms to solve them. And to test this skill, it's actually better to give them a problem to solve that they don't already know off the top of their head.
They're not asking you to recite A*, they're asking you to share how you'd go about solving it.
That's the textbook answer. But you just have to read some of the replies on that article to see that a lot of interviewers don't know this - they expect you to know these kinds of algorithms off the top of your head.
I knew one old-school interviewer that asked every candidate the layers in the OSI model. He told me in all the time he'd been asking, only one person knew the answer. My response to that was "Doesn't that say more about you than the candidates?"
This may be the case, but I know for a fact that I what I said applies to one of the companies he listed by name - Google. While there certainly may be some issues with hiring at some places, I think there's also another issue at play here. In computer science there are a large number incredibly skilled individuals since for many the work itself is intrinsically rewarding. This means some otherwise smart and skilled, but not as skilled, individuals are going to end up being second tier candidates. At most companies they'd still be in the upper tier of engineers, but at a company that attracts all the top talent like Google - they're not even going to get hired. And I have 0 doubt that some percent of these people are going to reconcile their failure not as a failure of themselves but as a failure of the hiring system itself - How could they possibly not be hired?!? Clearly the problem must have been in the hiring system itself!
Anyone who's done significant RDBMS work knows the thumbnail answer is "three tables." But what if all your work is C, NoSQL, and Hadoop? You could have a mountain of knowledge and skills to offer and not even know how to start answering the question.
I could look at someone who doesn't know how to answer that most basic of RDBMS questions as an idiot. Or I could simply realize that it's entirely possible to spend an entire career in IT solving big hard problems without ever touching an RDBMS. I don't agree with that philosophy, but "programming" didn't check with me.
What about "When would you use a doubly-linked list?" or "What is the fastest sort algorithm?" or "Explain a pointer to me."
There is no one "if you don't know this, you don't know programming" question. Okay, maybe there's one:
"Is there one single 'you don't know programming' question?"
If you answer "yes" to that, I'll throw you back into the ocean to get more experience.
I think you're kind of repeating yourself there. I get what you're saying, but what I'm saying is that his big lede example was not this sort of scenario that you're describing.
Inverting a binary tree is a really trivial problem that again shows whether or not somebody is capable of algorithmic thought. He even mentioned doing it on a whiteboard where he could have easily fleshed out his thought processes even if he couldn't produce the code 'cold'. I don't think I've ever had to invert a binary tree (I actually had to look it up to make sure it was what I assumed it was) and decided to give the problem a quick spin.
10 lines of code, and it works. The difference here is that in your example you're putting as a prereuisite "anybody who has done significant RDBMS." The prerequisite for this problem by contrast is being capable of thinking in a logical and algorithmic fashion and having a grasp on the most fundamental computer science datatypes. Furthermore solutions like mine which are not going to be the most pin point optimized give a clear insight into my thought process. "The only complexity in this problem is access to the parents. We need to get the parents in a fashion where we can iterate the nodes and mutate them without screwing up the iteration." From there it's wham, bam, done.
The prerequisite for this problem by contrast is being capable of thinking in a logical and algorithmic fashion and having a grasp on the most fundamental computer science datatypes.
Except that...
I actually had to look it up to make sure it was what I assumed it was
So you didn't know what it was for sure. Also, the amount of programming experience necessary to even guess what "invert a binary tree" means is probably far beyond what I am saying when I say "anybody who has done significant RDBMS work"
And here's the thing - I'm going to guess you've never done any data modeling, so my "many-many join" question looks completely alien to you. Does that mean I shouldn't hire you for any job that touches a database? Or should I ask you questions to see if you have the aptitude to grok data design and database interaction and that I can teach you what you need? Note that to do this kind of poking, I'm going to have to get out of RDBMS terminology and try to discover where you are with concepts you know (key-pair sets, hash tables, linked lists, arrays, etc).
And I'll say it again - you went with pseudocode to solve a problem you'd never addressed before. I'm asserting that I know for a fact there are interviewers who would expect you to be completely familiar with the concept and write down the standard book solution, otherwise you get a "No Hire." Someone who asks you the question and works with you through your lack of familiarity is fine; the issue are the people who think their perspective of the world is the only world and if you can't answer something they learned when they were 17, then obviously you are an idiot.
To go meta - don't think in terms of how you would treat a candidate in this situation. We're talking about pedantic asshats who don't understand how to interview.
Once again, I am not stating that the scenario you are describing does not exist somewhere. I am stating that the big named example of this article was not one of these employers. As an aside, that is compilable C# code - not pseudocode.
And I am stating that it's not an "employer" thing, it's a "person" thing, and unless you can tell me that Google has specific training for hiring interviews and has managers periodically audit the interviews of their employees, then yes, it even happens there. Because if you have a thousand people doing hiring interviews, you're gonna have a significant percentage that think it's supposed to be an exam instead of a conversation.
As for the code - my apologies. I didn't even glance at it. "Pseudocode" was not meant to be dismissive - only a lowest-common-denominator of "enough codelike substance to show your thinking in designing the algorithm." Looking at it now, it's fascinating in that it's theoretically correct, but we both know that in reality you'd have to optimize / rework it because it would freaking explode in memory. (Nature of the beast, not the solution)
Oh no I didn't take it that way. I think it's great that it looks like pseudo code. I strive for clarity in code so that's definitely a compliment! In any case the algorithm is actually perfectly performant. The entire memory required is N pointers. You could make the traversal nonrecursive if necessary, but that would not an issue in anything except rather extreme circumstances. I think it's a pretty nice implementation!
As for the interview stuff, interviews at Google don't work like at a normal company. It's not like you have your interviewer who then deals with a line of 50 people chopping them off one by one like the headsman at his block. It's a full day affair full of numerous interviews with people in the department you're interested in. The questions are prepared and reused and designed to test the technical creativity of the applicant. The phone interviews are relatively trivial and are just to ensure somebody has a basic degree of competence.
In any case this individual is in no way is describing the scenario you are. He seemed mostly upset that the interviewer only focused on actually doing things instead of talking about things he'd done in the past. And this is by design. Most of these comments are coming from chats with a friend who worked as an interviewer at Google, as many of their engineers do. One night we had a conversation about why I'm working solo since my technical interests align pretty much perfectly with Google's pursuits. My complaint was pretty similar to yours and that I felt the entire hiring process was a charade that I didn't feel like participating in. It turns out that Google's entire hiring process, and the reason they arguably end up with more top talent than any other company, is because they've specifically developed a system to counter this charade. Occam's razor here is stating pretty clearly that this guy probably just not a particularly sharp coder.
After about 10 minutes we jump right into whiteboard problems — implement a breadth-first search (BFS) algorithm.
The thing is, it takes less than three seconds with Google to find a perfect implementation of a breadth-first search algorithm, and if you actually wanted to implement one in production, no programmer in their right mind would write a solution to a known problem blind instead of using code that's already been tested a few trillion times. If the test is to discover the thought process I would follow on the job if I knew I needed to implement a breadth-first algorithm from scratch, my thoughts are that I would use Google.
Maybe it would be better to ask what the advantages and disadvantages are over other means of tree traversal, or whether I have ever used it before, which I actually have, in a chess AI, whose code they can look at if they want... To see if I actually know why and when I would use it is more important than the details of how one is implemented, when that is public information that is trivial to look up, I would think. Good judgement and understanding is not.
I've done tree traversal for a flat array of nodes with only parent_id references as the main association across thousands of objects. This was based on the linux inode pattern.
My first draft of building the tree was shit, 10s of thousands of computations. My boss showed me that a dictionary (or literally a JS data object that saved some IDs) would solve almost all of that performance. We ended up looping the nodes twice, which took the feature from factorial complexity (something like N^n, to 2N, and I don't know big-O notation at all).
So I have respect for that skill, but as a standard frontend dev it's mostly irrelevant. Such a frontend dev will be already employed at a major performance shop. e.g. Google.
I am also very unhappy with the sometimes emphasis on knowing factoids in interviews that could be looked up in 3 minutes at a desk. One time some company brought me in for an interview and I'm pretty sure they were filming me not the knowing to the answers I had written down at home for phone interviews. "Sorry dude, I don't recall what the difference between where and having is but I know where to google it."
How many people can actually write BFS on the spot, without preparing for it in advance?
While I agree with the sentiment (was rejected several times a few months ago), knowing basic algorithms is rather important. I would assume most competent programmers can write BFS on the spot. But I agree that interviews could be improved. I've had luck with simple interviews at very small companies/start-ups; no BigCorps for me
Again I don't even think you need to have BFS memorized. As long as you conceptually understand how a breadth first search works it's trivial to throw one together. I mean as long as you grasp that it's peers before children - which ought be entirely intuitive, the rest is trivial.
Never said it had to be memorized. I almost agreed with the blog author when I couldn't remember how to do BFS. But thought I'd challenge myself and figured it out in about 15 seconds, with the deque and all.
Seriously, I got to that part and had to stop reading. This guy is a huge baby. How you write it is IN THE NAME. I haven't taken algorithms in forever either but you do this kind of stuff all the time. You need to look through an object tree for something, you're generally going to end up either going breadth first or depth first. This isn't something you do every day but I'd say I do it once a month.
I disagree with it. If they can't write a BFS or DFS on the spot, from first principles, then I don't want to hire them. Sure, maybe when they have access to stackoverflow.com they are capable of cut-n-pasting their way through most business application development jobs, but I want someone who can solve new problems which don't have example code available.
But the problem is, a bunch of play-the-game candidates will memorize tree-traversal (and other stock problem) solutions, so in comparison anybody who is trying to solve them from first principles on the spot will look unprepared or subpar.
I wonder if this is a geographic thing. I did interviews on the east coast about 3 years ago for various sw positions and they were all easy. I even got an offer from the place where I thought I failed the interview because I rambled through one of those "how many piano tuners in city" questions.
It is. Logically, as the biggest names in tech are mostly on the west coast. That's a sweeping statement, of course there are big companies to the east, but they're not as hungry for C.S. geniuses, they want production. I gotta think 95% of frontend producers out there, with legitimately valued jobs, can't pass C.S. questions @ Google/BigName.
I imagine that working in San Francisco has to be a nightmare for anyone in the programming industry. The best of the best of the best will be there, all trying to find jobs. Kind of like trying to be a rock musician, general talent isn't going to be enough. My initial thought was "he probably would do well in another city". Now he works in New York.
This guy keeps whining about his own incompetence, or did I miss some great injustice? I don't think it counts as bad luck if you're lacking knowledge in this context.
Not just lacking knowledge, but he himself is the sole determiner of what constitutes the knowledge necessary to be a good frontend dev! It sounds like he did well on at least a few of the interviews but still didn't get hired. Honestly, based on what I've seen of his personality in that post, I wouldn't want to work with him either.
You mean in the context of an elite Company/Role. I don't know any frontend devs who can answer C.S. algorithm questions, and that's around a dozen of mixed skilled frontend devs.
But yea if you interview for the best, expect the best, or join the less.
They didn't like him, that's why they threw impossible questions at him. He needs to change his look, perhaps smile and sound happier (especially on the phone). But I would never work for someone else - slavery with pecking order & clique cult-ure.
If you are going to test my knowledge, at least ask relevant questions for the role.
See, this right here sums it up quite nicely of what they typically do i.e. Waste your time. This not only applies to tech industries, but also to Universities and other higher-education courses. They waste your fucking time with irrelevant shit.
The second round was a 2-on-1 interview with a whiteboard problem. I was asked to write a function findSum(array1, array2, sum) that returns true if two numbers from two sorted arrays add up to a given sum. I was able to solve it with my eyes closed using a double for loop — O(n²) time complexity. For the remaining time I was able to reduce the time complexity by converting arrays to hash maps, then finding the difference by subtracting sum from the first list element and checking if that difference is a “key” of the second hash map.
This is illustrative of this guy's lack of interest in problem-solving. Any interview question that I struggle with on the spot, I will spend time puzzling over after the interview until I get it. It's natural CS instinct and also good for future interviewing. (Although I agree that CS interviewing is pretty fucked up, and hate having to do it) I would also probably make sure to have it solved before writing about it in a blog post.
Given x1...xn in array1 and y1...ym in array2. Let i=1 and j=m. While i<=n and j>=1: if xi+yj == sum, return true. Else if xi+yj < sum, i++. Else, j--. End-while. Return false.
Pretty sure this is correct and would write out a proof if I had more time or wasn't on my phone.
This solution seems intuitive to me, and is even hinted at by the arrays being pre-sorted, which he apparently didn't try to make use of.
43 comments
20 u/rwbj 28 Apr 2016 13:11
This individual seems to be rather clueless about the goal of interviews. When they ask you a question, the intention is to ask something that you don't know off the top of your head to try to get a bit of insight into your thought process. A maze solving problem is a perfect example of this. They're not asking you to recite A*, they're asking you to share how you'd go about solving it. So you might start by drawing a simple maze and interpreting your own thoughts into general control flow and then convert that into an algorithm. In fact simply code dumping A* would probably result in the interviewer asking a different question as that response is almost as useless as "I'm not a recent college grad. You expect to have this memorized?!?!?" The fact this individual is seemingly incapable of producing algorithmic thought without having memorized it is most likely the reason they were not getting hired for anything. All the above applies 100% for Google who has the reputation as a tough interviewer. Your credentials get you in the door, they don't get you the job. Your display of skills and logical/creative thinking gets you the job.
24 u/snipez 28 Apr 2016 13:51
While I agree with your statement about the goal of deeply technical interviews, the most important point of the article is "why am I doing algorithmic interviews when I'm applying for a front end position?"
While there still might be some merit to testing someone's problem solving skills, front end work tends to involve few to absolutely no algorithmic problems, and is generally very simple, and more about understanding the process and usage of the front end frameworks you use. I think if this guy was interviewing for a position that involves heavy data manipulation and storage, then sure, these are interview questions are quite important. That's generally just not the case with front end dev.
4 u/pitenius 28 Apr 2016 14:05
Maybe he should tell them that? I'll admit I'm rubbish in interviews, even having told people that their project was doomed to failure and only an idiot or masochist would work there, but I people do still seek me out and I occasionally get interesting work.
2 u/snipez 28 Apr 2016 15:21
He probably should, so long as he doesn't come across as a whiner. He should at least ask (when scheduling an interview) something like "As I'm applying to be a front end dev, how technical or algorithmic is this interview going to be?" It's a perfectly valid question, and at least gives him time to prepare so he's not blindsided.
9 u/ForgotMyName 28 Apr 2016 14:28
The complexity of front end work is determined by your level of seniority and what kind of work the company does. I've written entire validation frameworks for the front end. The work ended up being pretty complex. I don't think it's unreasonable to expect front end devs to have some basic algorithm knowledge. A depth first traversal is trivial, you do that kind of thing regularly.
Even so, interviews aren't just a test of knowledge, but of personality. It's about learning - How does this person approach problems they're unfamiliar with? How will they respond when they don't have the answer memorized? I'd rather watch someone struggle to think something through and then finally admit - "I'm not really sure, I think I'm close but I'd have to ask around or do some googling at this point." Rather than throw their hands up and whine about algorithm questions in front end interviews. No one is going to hire the latter.
4 u/whisky_cat 28 Apr 2016 20:07
I don't know shit about algorithms, but I'm a Lead UIE because I can build shit. When I get contract work sometimes I can tell they're just testing the water and planning to put up an offer in 3 weeks. I've based my entire success on proving I can build complex features without having a C.S. degree whatsoever, hell I was a graphic designer (really just a production artist) prior to getting into heavy JS programming.
The interview questions for a frontend, if you want someone who can produce, should really be about pre-processors, CSS/JS technical, HTML accessibility, RESPONSIVE experience and practices, maybe some SVG data charts, ask them what their opinion on jshint or semicolons are (frankly they don't result in higher quality UI code, but "feel" like that's the case).
That said if I interviewed at Google I would expect to hear performance questions which could be very difficult to answer (I'd point to Matt Bynens, Nick Zakas, JD Dalton blogs).
As far as inverted binary trees go, I'm sure someone has a job to handle that already.
Many of the big recruiters reach out to me (Amazon, Imgur, Microsoft, Adobe, etc) but I don't bother because I know their interviews aren't for me. Just have me prototype something and you'll probably want me on your team. And yes, it doesn't have to be my niche (Angular on Rails), ask me to prototype something that's not my niche and the result should still be strong. I've worked on a dozen platforms (PHP CMS, proprietary CMS ~x3), .NET CMS, Rails CMS, Phonegap), and delivered every time. You'd think the ability to ship features over multiple years and systems has value...
0 u/tame 29 Apr 2016 00:06
If I'm hiring a software dev specifically and solely for the rote UI work then sure. But if I'm not some accounting software company that survives by grunting out yet another quarterly revision of the same mediocre software package, then I want someone who can do more than just the grunt work, I want a team member who can analyze new problems and create new algorithms to solve them. And to test this skill, it's actually better to give them a problem to solve that they don't already know off the top of their head.
2 u/FormerlyKnownAsGkar 29 Apr 2016 04:52
That's the textbook answer. But you just have to read some of the replies on that article to see that a lot of interviewers don't know this - they expect you to know these kinds of algorithms off the top of your head.
I knew one old-school interviewer that asked every candidate the layers in the OSI model. He told me in all the time he'd been asking, only one person knew the answer. My response to that was "Doesn't that say more about you than the candidates?"
0 u/rwbj 29 Apr 2016 05:23
This may be the case, but I know for a fact that I what I said applies to one of the companies he listed by name - Google. While there certainly may be some issues with hiring at some places, I think there's also another issue at play here. In computer science there are a large number incredibly skilled individuals since for many the work itself is intrinsically rewarding. This means some otherwise smart and skilled, but not as skilled, individuals are going to end up being second tier candidates. At most companies they'd still be in the upper tier of engineers, but at a company that attracts all the top talent like Google - they're not even going to get hired. And I have 0 doubt that some percent of these people are going to reconcile their failure not as a failure of themselves but as a failure of the hiring system itself - How could they possibly not be hired?!? Clearly the problem must have been in the hiring system itself!
1 u/FormerlyKnownAsGkar 29 Apr 2016 13:41
How do you implement a many-many join?
Anyone who's done significant RDBMS work knows the thumbnail answer is "three tables." But what if all your work is C, NoSQL, and Hadoop? You could have a mountain of knowledge and skills to offer and not even know how to start answering the question.
I could look at someone who doesn't know how to answer that most basic of RDBMS questions as an idiot. Or I could simply realize that it's entirely possible to spend an entire career in IT solving big hard problems without ever touching an RDBMS. I don't agree with that philosophy, but "programming" didn't check with me.
What about "When would you use a doubly-linked list?" or "What is the fastest sort algorithm?" or "Explain a pointer to me."
There is no one "if you don't know this, you don't know programming" question. Okay, maybe there's one:
"Is there one single 'you don't know programming' question?"
If you answer "yes" to that, I'll throw you back into the ocean to get more experience.
0 u/rwbj 29 Apr 2016 18:07
I think you're kind of repeating yourself there. I get what you're saying, but what I'm saying is that his big lede example was not this sort of scenario that you're describing.
Inverting a binary tree is a really trivial problem that again shows whether or not somebody is capable of algorithmic thought. He even mentioned doing it on a whiteboard where he could have easily fleshed out his thought processes even if he couldn't produce the code 'cold'. I don't think I've ever had to invert a binary tree (I actually had to look it up to make sure it was what I assumed it was) and decided to give the problem a quick spin.
10 lines of code, and it works. The difference here is that in your example you're putting as a prereuisite "anybody who has done significant RDBMS." The prerequisite for this problem by contrast is being capable of thinking in a logical and algorithmic fashion and having a grasp on the most fundamental computer science datatypes. Furthermore solutions like mine which are not going to be the most pin point optimized give a clear insight into my thought process. "The only complexity in this problem is access to the parents. We need to get the parents in a fashion where we can iterate the nodes and mutate them without screwing up the iteration." From there it's wham, bam, done.
0 u/FormerlyKnownAsGkar 01 May 2016 15:57
Except that...
So you didn't know what it was for sure. Also, the amount of programming experience necessary to even guess what "invert a binary tree" means is probably far beyond what I am saying when I say "anybody who has done significant RDBMS work"
And here's the thing - I'm going to guess you've never done any data modeling, so my "many-many join" question looks completely alien to you. Does that mean I shouldn't hire you for any job that touches a database? Or should I ask you questions to see if you have the aptitude to grok data design and database interaction and that I can teach you what you need? Note that to do this kind of poking, I'm going to have to get out of RDBMS terminology and try to discover where you are with concepts you know (key-pair sets, hash tables, linked lists, arrays, etc).
And I'll say it again - you went with pseudocode to solve a problem you'd never addressed before. I'm asserting that I know for a fact there are interviewers who would expect you to be completely familiar with the concept and write down the standard book solution, otherwise you get a "No Hire." Someone who asks you the question and works with you through your lack of familiarity is fine; the issue are the people who think their perspective of the world is the only world and if you can't answer something they learned when they were 17, then obviously you are an idiot.
To go meta - don't think in terms of how you would treat a candidate in this situation. We're talking about pedantic asshats who don't understand how to interview.
0 u/rwbj 01 May 2016 16:05
Once again, I am not stating that the scenario you are describing does not exist somewhere. I am stating that the big named example of this article was not one of these employers. As an aside, that is compilable C# code - not pseudocode.
0 u/FormerlyKnownAsGkar 01 May 2016 19:02
And I am stating that it's not an "employer" thing, it's a "person" thing, and unless you can tell me that Google has specific training for hiring interviews and has managers periodically audit the interviews of their employees, then yes, it even happens there. Because if you have a thousand people doing hiring interviews, you're gonna have a significant percentage that think it's supposed to be an exam instead of a conversation.
As for the code - my apologies. I didn't even glance at it. "Pseudocode" was not meant to be dismissive - only a lowest-common-denominator of "enough codelike substance to show your thinking in designing the algorithm." Looking at it now, it's fascinating in that it's theoretically correct, but we both know that in reality you'd have to optimize / rework it because it would freaking explode in memory. (Nature of the beast, not the solution)
0 u/rwbj 01 May 2016 19:59
Oh no I didn't take it that way. I think it's great that it looks like pseudo code. I strive for clarity in code so that's definitely a compliment! In any case the algorithm is actually perfectly performant. The entire memory required is N pointers. You could make the traversal nonrecursive if necessary, but that would not an issue in anything except rather extreme circumstances. I think it's a pretty nice implementation!
As for the interview stuff, interviews at Google don't work like at a normal company. It's not like you have your interviewer who then deals with a line of 50 people chopping them off one by one like the headsman at his block. It's a full day affair full of numerous interviews with people in the department you're interested in. The questions are prepared and reused and designed to test the technical creativity of the applicant. The phone interviews are relatively trivial and are just to ensure somebody has a basic degree of competence.
In any case this individual is in no way is describing the scenario you are. He seemed mostly upset that the interviewer only focused on actually doing things instead of talking about things he'd done in the past. And this is by design. Most of these comments are coming from chats with a friend who worked as an interviewer at Google, as many of their engineers do. One night we had a conversation about why I'm working solo since my technical interests align pretty much perfectly with Google's pursuits. My complaint was pretty similar to yours and that I felt the entire hiring process was a charade that I didn't feel like participating in. It turns out that Google's entire hiring process, and the reason they arguably end up with more top talent than any other company, is because they've specifically developed a system to counter this charade. Occam's razor here is stating pretty clearly that this guy probably just not a particularly sharp coder.
8 u/dizzydog 28 Apr 2016 17:03
The thing is, it takes less than three seconds with Google to find a perfect implementation of a breadth-first search algorithm, and if you actually wanted to implement one in production, no programmer in their right mind would write a solution to a known problem blind instead of using code that's already been tested a few trillion times. If the test is to discover the thought process I would follow on the job if I knew I needed to implement a breadth-first algorithm from scratch, my thoughts are that I would use Google.
Maybe it would be better to ask what the advantages and disadvantages are over other means of tree traversal, or whether I have ever used it before, which I actually have, in a chess AI, whose code they can look at if they want... To see if I actually know why and when I would use it is more important than the details of how one is implemented, when that is public information that is trivial to look up, I would think. Good judgement and understanding is not.
2 u/whisky_cat 28 Apr 2016 20:31
I've done tree traversal for a flat array of nodes with only
parent_idreferences as the main association across thousands of objects. This was based on the linux inode pattern.My first draft of building the tree was shit, 10s of thousands of computations. My boss showed me that a dictionary (or literally a JS data object that saved some IDs) would solve almost all of that performance. We ended up looping the nodes twice, which took the feature from factorial complexity (something like N^n, to 2N, and I don't know big-O notation at all).
So I have respect for that skill, but as a standard frontend dev it's mostly irrelevant. Such a frontend dev will be already employed at a major performance shop. e.g. Google.
6 u/7even6ix2wo 28 Apr 2016 14:29
I am also very unhappy with the sometimes emphasis on knowing factoids in interviews that could be looked up in 3 minutes at a desk. One time some company brought me in for an interview and I'm pretty sure they were filming me not the knowing to the answers I had written down at home for phone interviews. "Sorry dude, I don't recall what the difference between where and having is but I know where to google it."
6 u/51rH0n3y84d93r 28 Apr 2016 18:29
Archive.is link for those who want to read the company names.
1 u/J_Darnley 29 Apr 2016 14:54
Underrated, thanks.
5 u/WillyWillyBumBum 28 Apr 2016 12:41
While I agree with the sentiment (was rejected several times a few months ago), knowing basic algorithms is rather important. I would assume most competent programmers can write BFS on the spot. But I agree that interviews could be improved. I've had luck with simple interviews at very small companies/start-ups; no BigCorps for me
9 u/rwbj 28 Apr 2016 13:17
Again I don't even think you need to have BFS memorized. As long as you conceptually understand how a breadth first search works it's trivial to throw one together. I mean as long as you grasp that it's peers before children - which ought be entirely intuitive, the rest is trivial.
2 u/WillyWillyBumBum 28 Apr 2016 13:43
Never said it had to be memorized. I almost agreed with the blog author when I couldn't remember how to do BFS. But thought I'd challenge myself and figured it out in about 15 seconds, with the deque and all.
3 u/ForgotMyName 28 Apr 2016 14:16
Seriously, I got to that part and had to stop reading. This guy is a huge baby. How you write it is IN THE NAME. I haven't taken algorithms in forever either but you do this kind of stuff all the time. You need to look through an object tree for something, you're generally going to end up either going breadth first or depth first. This isn't something you do every day but I'd say I do it once a month.
2 u/whisky_cat 28 Apr 2016 20:21
Yep, I just avoid the big corps. There's 10s of thousands of companies seeking less-than-elite frontend talent. The market is huge.
0 u/tame 28 Apr 2016 23:51
I disagree with it. If they can't write a BFS or DFS on the spot, from first principles, then I don't want to hire them. Sure, maybe when they have access to stackoverflow.com they are capable of cut-n-pasting their way through most business application development jobs, but I want someone who can solve new problems which don't have example code available.
1 u/onegin 04 May 2016 14:58
But the problem is, a bunch of play-the-game candidates will memorize tree-traversal (and other stock problem) solutions, so in comparison anybody who is trying to solve them from first principles on the spot will look unprepared or subpar.
4 u/TheCompanionCube 28 Apr 2016 14:54
I wonder if this is a geographic thing. I did interviews on the east coast about 3 years ago for various sw positions and they were all easy. I even got an offer from the place where I thought I failed the interview because I rambled through one of those "how many piano tuners in city" questions.
1 u/whisky_cat 28 Apr 2016 20:26
It is. Logically, as the biggest names in tech are mostly on the west coast. That's a sweeping statement, of course there are big companies to the east, but they're not as hungry for C.S. geniuses, they want production. I gotta think 95% of frontend producers out there, with legitimately valued jobs, can't pass C.S. questions @ Google/BigName.
3 u/IIzz 28 Apr 2016 23:04
I imagine that working in San Francisco has to be a nightmare for anyone in the programming industry. The best of the best of the best will be there, all trying to find jobs. Kind of like trying to be a rock musician, general talent isn't going to be enough. My initial thought was "he probably would do well in another city". Now he works in New York.
2 u/ThisIsMyRealName 28 Apr 2016 13:32
This guy keeps whining about his own incompetence, or did I miss some great injustice? I don't think it counts as bad luck if you're lacking knowledge in this context.
1 u/ForgotMyName 28 Apr 2016 14:35
Not just lacking knowledge, but he himself is the sole determiner of what constitutes the knowledge necessary to be a good frontend dev! It sounds like he did well on at least a few of the interviews but still didn't get hired. Honestly, based on what I've seen of his personality in that post, I wouldn't want to work with him either.
1 u/whisky_cat 28 Apr 2016 20:24
You mean in the context of an elite Company/Role. I don't know any frontend devs who can answer C.S. algorithm questions, and that's around a dozen of mixed skilled frontend devs.
But yea if you interview for the best, expect the best, or join the less.
2 u/AngrySOAngry 29 Apr 2016 06:33
They didn't like him, that's why they threw impossible questions at him. He needs to change his look, perhaps smile and sound happier (especially on the phone). But I would never work for someone else - slavery with pecking order & clique cult-ure.
1 u/Scruffy_Nerfherder 28 Apr 2016 21:52
I miss programming. I just did ladder logic, nothing fantastic. It was solving problems that was the fun part. I got to do some cool stuff.
1 u/iamrage 29 Apr 2016 04:37
See, this right here sums it up quite nicely of what they typically do i.e. Waste your time. This not only applies to tech industries, but also to Universities and other higher-education courses. They waste your fucking time with irrelevant shit.
1 u/onegin 04 May 2016 15:21
This is illustrative of this guy's lack of interest in problem-solving. Any interview question that I struggle with on the spot, I will spend time puzzling over after the interview until I get it. It's natural CS instinct and also good for future interviewing. (Although I agree that CS interviewing is pretty fucked up, and hate having to do it) I would also probably make sure to have it solved before writing about it in a blog post.
Given x1...xn in array1 and y1...ym in array2. Let i=1 and j=m. While i<=n and j>=1: if xi+yj == sum, return true. Else if xi+yj < sum, i++. Else, j--. End-while. Return false.
Pretty sure this is correct and would write out a proof if I had more time or wasn't on my phone.
This solution seems intuitive to me, and is even hinted at by the arrays being pre-sorted, which he apparently didn't try to make use of.