Yikes... Interviewing sucks but half the reason interviewers ask these types of questions is to see your attitude and how you respond. Writing an Instagram clone in Angular doesn't really tell me much about your problem solving skills when faced with a unique problem.
> How many people can actually write BFS on the spot, without preparing for it in advance?
Ughhh, should I tell him?
> why would they ask me this question, what does breadth-first search has to do with front-end development
Tree data structures are really common in front-end.. like the DOM or JSON.
I've been developing for well over a decade as full stack engineer. I've worked as a successful software dev at some big corporations (like Intel, and yes it was fulltime for several years) and almost always outperformed my peers. I work in finance now where everything is about managing portfolios for people - lots of numbers and heavy calculations.
I have no fucking clue how to write a BFS. I've never needed to know how to write a BFS. I will probably never need to know how to write a BFS. Coders like me write business applications where these things are literally never an issue. If there's something I need to know and don't, I simply research it. That's the point he's trying to make. Don't interview people on algorithms they will never ever use. It's as simple as that.
There are more productive ways to interview someone; for example take a bug in your product and see if the candidate can fix it. Or if you're worried about sharing proprietary info, then make a sample program that simulates a bug or feature that your application will use and observe the candidate working on that.
Yeah, I've seen some real horror stories about bad interview processes in the past, but this seems more like the guy outing himself as a defensive and impulsive person who immediately shuts down when he doesn't "know" something.
I can't remember Djikstra's algorithm either, but I would happily try and write a 15 line brute force recursive maze solver in an interview.
Of course it's not something I expect anyone does day to day, but it's also the kind of simple problem that I'd expect almost anyone with a CS 102 level of knowledge to be able to reason out by just taking a few minutes with a pencil and paper. As an interviewer, even a brute force solution would demonstrate a good willingness to look at problems using your fundamental skills and reason about something you don't have a ready made solution to.
> > How many people can actually write BFS on the spot, without preparing for it in advance?
> Ughhh, should I tell him?
Yeah, that's where I stopped reading. This isnt specialized knowledge. If you know how to program, you can write a BFS. The entire algorithm structure is in the name. The only extra details you need to remember or figure out are "use a FIFO for tracking what to check in the future" and "make sure you don't go backwards". Neither is some great secret. They're obvious if you sit down and think through (or talk about with the interviewer) the structure specified in the name of the algorithm.
This person is either not a good programmer or has a very poor attitude about solving new problems.
Hiring isn't broken. I'd reject this guy too. Knowledge about a specific technology is a lot less valuable than general knowledge and willingness to explore.
I've had a successful programming career since the 80s. Including a fair share of browser front end programming.
As far as I remember, I have never written any BFS code, and I would also find it absurd to be asked to do so in an interview. There is great library code that does this in any reasonable situation.
If you're the kind of shop that would rather write your own code than use third party libraries, then that's a really great sign that I shouldn't work there.
I can't write BFS off the top of my head, but I can probably do it after reading the Wikipedia page on it. The last time I interviewed (for the company I'm working for now), I faced a similar question, and said up-front, "It's been a decade since I've had to implement that, so let me Google for a quick sec." I proceeded to do so, skimmed the Wikipedia article, and wrote the code in the shared editor we were using. I got the job, so the interviewer must have seen my candor and quick comprehension as positives. But I know (based on the parent comment here, as well as discussion with colleagues) that this sentiment is not universal.
If I had claimed a lot of algorithm-heavy experience on my resume, I would have expected my response to be met much more harshly. But, as my experience was focused more on API design and interactions with business stakeholders, it wasn't a useful question to gauge my competence. However, it was useful for gauging my personality. Like everything, context is vital.
I was taken aback by the BFS thing at first as well, but after thinking about it, I'm not sure I would be so confident about writing one if I didn't already know the basic structure due to the 50 or so times I had to implement some version of it in college. I don't feel like I can judge because I was forced to implement most of the basic data structures and traversals so many times that I can usually re-create them based on knowing 3 or 4 steps and filling in the gaps myself. I think a lot of software engineers also had this experience, and so they expect it of others, but if nobody forced you to write a path finding algorithm inside a composite pr quad trie in college then you are at a huge disadvantage for interviews, but probably less of a disadvantage for actual practical programming.
Be honest, how many of us implement our own data structures these days? I sure don't. I just build on or use whatever version of map comes with the language 98% of the time.
And if the candidate will be writing a new DOM traversal API, this is a valid exercise.
As it stands, any of the libraries that do DOM manipulation for me also traverse the tree for me ... so, again, why do I need to implement a toy BFS in an interview?
Yikes... Interviewing sucks but half the reason interviewers ask these types of questions is to see how your attitude and how you respond. Writing an Instagram clone in Angular doesn't really tell me much about your problem solving skills when faced with a unique problem.
How many software developers work on "unique problems" that involve hard computer science problems compared to the number that are just using an existing framework to solve business problems?
Tree data structures are really common in front-end.. like the DOM....
And most of the time you're going to end up using a pre-existing implementation....
I stumbled a bit on "write BFS" at a FAANG interview. The specific question was to write it for the Facebook friend graph. I just blurted out my reaction, which is that this was a terrible idea (given the space requirements). His response, "Well, pretend it's not.". Ugh.
Getting around the DOM is really simple: querySelector and querySelectorAll do the work for you.
Accessing properties of a known object is better handled with the selector pattern. I guess you might use BFS to implement a search feature for user-generated content on the fly? I don't think it's relevant to most FEDs roles making CRUD apps with backend searching APIs.
And asking people tricky questions doesn't tell you about people's problem solving skills either, it just tells you that person is a good talker. Justifying tricky tree traversal interview questions by comparing it the DOM??? That is a stretch. In any case, beyond _solid_ coding skills, the thing that makes someone a great member of a dev isn't coding skills, it is a whole pile of professional best practices, social skills, and general passion for continuous improvement. It is simply not possible to test for those things in an interview.
The reality is that interviews are broken. Not because of this guys subjective perception that it is so but because for employers you just aren't getting the SNR to justify typical interviews. People who cling to that approach anyway are largely, IMO, motivated by ego and cargo cult (lack of understanding and creativity). In addition, in that context, interviews are also broken because in being worthless, they are demeaning to the candidate who isn't great at tap dancing on your command.
What does work is past performance and actually working together. Both are problematic data to get at so I don't think there are easy answers here. We do a resume review to see if they even claim to have the expertise we're interested in, a very short and simple "gut check" coding exercise (not tricky, just checking they can actually write decent code and tests), a 30min phone conversations where we check that both parties are aligned on what we're looking for, contract to hire, then exercise extreme discipline in parting ways with people that aren't great before converting to W2. Our SNR is pretty good. A lot of people don't want to contract to hire so this system has cons. YMMV of course.
I think my current company does a decent job of this. Yes, we'll ask you design questions on a whiteboard, but any algorithms or code implementations are done on a computer, and Google is encouraged.,
The thing that appears to me, most overpoweringly, is the bitterness.
I understand, I've felt bitter about interviews before, I'm sure some interviews were unfair. But I also recognize this bitterness is a weakness of mine, unproductive, unattractive.
The way the author indulges in this resentment would make me very cautious about recommending him regardless of technical capability. An employee who has low tolerance for the massive randomness/unfairness in the world probably would get sick of most companies pretty quickly.
The frustration mounts over time - give the person some slack, they’re probably just venting. Most everyone hates the interview process. The way I see it is if perfectly qualified and not nervous, you have a 40-60% chance of passing an interview - it only takes a few coin flips for someone actually competant to go “hey, this shit I’ve worked much of my life for is arbitrary and random”.
The issue I think the poster is having is they just don’t understand how algorithm interviewers think - it’s totally reasonable to think oh, frontend has a DOM tree usually, so they should know BFS (even though you’d rarely if ever use your own traversal alg - leave it to the people actually researching it, not the person building a frontend).
This was my impression as well. There were likely real issues that made the process annoying, but the tone of the post is basically "how dare you ask me those stupid questions at the interview you invited me to?".
On site interviews usually evaluate not only technical competency but also whether that person is OK to work with, especially during crunch times. Being able to point to a few github projects is good, but not sufficient. When faced with a question one cannot answer staying positive and trying a few options is often sufficient to get off the hook.
An employee who has low tolerance for the massive randomness/unfairness in the world probably would get sick of most companies pretty quickly.
Another way to look at it that they're a ... human being, attempting to come to terms with a truly toxic and dehumanizing system.
In response to which my gut instinct is not to defend the system, as would appear to be yours. But to recognize, as the original author does, that the system truly is fucked.
And if we're to maintain our health and sanity -- at some point one has to simply decide to "just say no", and start looking for and building an alternative.
It only failed 5 times, try more times and u will master all the interview process! maybe the hiring statistics is 1/6 smart guys get the job and u just had to try a little bit more.
I got this quote after failing google interview in the last round.
"Success consists of going from failure to failure without loss of enthusiasm."
> I really wish companies would be more transparent about their candidate rejection reasons
I always wish this too. At my previous job a (also at BigCorp) candidate reached out to ask why they hadn't been selected so I started putting together a little email for them trying to give polite feedback and encouraging them to apply again in a few years (they were great, but we needed a more senior role and had no open junior positions at that time). I asked my boss to review it and make sure it was okay, and he told me that under no circumstances do we ever give candidates feedback because if you say one wrong thing it's a lawsuit waiting to happen. Having been on the interview side where I really wanted to know how I could have done better, I was a bit angry on behalf of the candidate.
This is common and necessary. There are a ton of federal and state laws about what can be considered in hiring, and if one steps an inch off of the legal path, the results are dire. Written feedback is the worst. One simply can't do it, and if you were employed at yahoo, and did any interviewing, you went through that training.
Hiring is hard. It's very difficult to figure out what combination of activities/questions will correlate to actual job performance, not to mention uncover someone's day-to-day personality when their guard is up.
With that said, my interview process basically is:
* 30 minute intro call to dive into the CV a bit and see if it's worth everyone's time to go further
* 1.5-2 hour pair programming exercise using the actual language & framework they'd most likely be using for the job
* If that goes well, 30-60 minutes to meet with the team and figure out if everyone will get along
That's it. No whiteboarding, no FizzBuzz, no algorithms. If we make a mistake we try to recognize it within 6 weeks of the person starting in that position.
> * 1.5-2 hour pair programming exercise using the actual language & framework they'd most likely be using for the job
This advantages people who have actually used that language/framework for prior jobs. If that's a thing you want to optimize for, then that's fine. If you want to evaluate people as more generic software developers, it's not so great.
That's why whiteboarding algorithm questions can be useful. They're sufficiently abstract to generalize to lots of different 'stacks' and experience levels. If you just want to get generally competent developers first and then figure out where to put them later, then this type of question can make a lot of sense, which is why Google, Facebook, et al. use them.
This seems like a reasonable process. However, for me personally, I have a big portfolio of side projects with open-source code. And it irks me if a company asks me to prove my programming skills by wasting my time doing some silly tests, where if they just read my code we would be able to skip it. From all the places I've worked, the companies with the better programmers were the ones where they actually looked at your past code and had hardly any exercise or test.
I think the 6-week "probation" period is an excellent idea. Since most of the time you can recognize if they are a good fit or not.
I think developers complain way to much about the interview process. The fact of the matter is that it's very clear what type of questions will be asked for most technical interviews and there is a wealth of resources available to prepare. The ROI on spending a couple of weeks preparing is definitely worth the possibility of a substantial raise at a big technology company.
I can't think of another industry that is as high paying as software development, with such a low barrier to entry (formal education matters less and less) with such transparency regarding the interview process (books, blogs, literal guides from the company itself). And HN is flooded with a couple of posts like this every single month, is it perfect? No. What is? At the end of the day this just looks like entitlement.
It is a total failure of industry to ask people who are productively writing software one day to waste dozens of hours learning to dance an artificial interview game to get hired somewhere to start writing productive software again weeks later.
If the candidate has no resume and nothing to prove they have any skill then yes, give them a rigamarole. But for don't ask a staff artist to speedpaint you the view out the window with crayons in a lined paper binder in half an hour. They give you their porfolio, you inspect it, and if they are accredited and recognized you don't waste their time on quizbowl.
Arguing about it though is mostly pointless. The awareness is out there that these companies are throwing away not just the on hand candidates they turn down for failing their charade game but also the legions of potential employees turned off by the theatrics and immaturity of software hiring. The OP is absolutely right to say interviewing in tech is draining because you go from thinking yourself competent on the outside to interviewers trying to beat you into a sobbing mess on the inside. Its adversarial from the start at almost every company, it certainly contributes in large part to the lack of women participating in development, and businesses seem to be just fine with the outcomes since they know what they are doing is awful but so long as they are "hip" and popular they can get away with it, with an endless list of potential hires to give the rigamarole to.
> What is? At the end of the day this just looks like entitlement.
I had the same impression, particularly driven by these quotes:
From this day on, I was even more disappointed — both with myself and tech hiring process — rejection, rejection, rejection. It honestly feels as if I am a complete failure and an unhirable candidate. How is this possible — I have received emails from people all over the world, who praise and give me thanks for the work I’ve done on my open-source projects and tutorials (and I say this as humbly as I can); people who see me as an expert on Hackhands; co-workers, friends and acquaintances from meetups, hackathons, conferences who apparently think I am a decent programmer—but I cannot pass a single tech interview. How?
TBH, the author sounds like someone who went to the interviews completely unprepared, believing that just because they have some open-source projects and tutorials, they deserve to be hired.
Nobody deserves anything. Most of my friends who went up for interviews with FAANG (or whatever is the latest acronym) studied and prepared for months even before applying.
> The first round started with introductions, followed by a coding exercise — write a maze solving algorithm. What the fuck?! Seriously? Mind you, this was an interview for a front-end developer position and I am not a recent college graduate anymore.
If you balk at breaking down a relatively simple and straightforward problem into approachable steps that a computer can interpret, then what exactly do you think that programming is? You don't need to _know_ the algorithm. You need to be able to think like a problem solver. And if you can't do that, then what exactly are you doing?
> Anyway, that did not go too well, obviously, because it has been a long time since I took an Artificial Intelligence course in college
You should be able to do this even if you've never done it before. You have a start, you have an end, and you have decisions to make to get from the start to the end. That's the literal definition of programming.
The only people I know who think that basic pathfinding is some voodoo dark magic artificial intelligence problem and not just a simple straightforward algorithmic process that you should be able to do in your sleep for the rest of your life immediately after the first week of Intro CS 100 are not software engineers.
"I really wish companies would be more transparent about their candidate rejection reasons."
There is just too much legal risk from doing so. Too much risk of wording being misinterpreted and being turned around to be discrimination etc. To provide feedback you'd have to have so much oversight and absolutely ridiculous levels of paranoia about the potential interpretations of what you'd said that the risk is just not worth it.
The value giving feedback to candidates provides to the company is next-to-nothing as well, especially for the larger companies.
There is a hiring infrastructure which is sort of like those dating apps that say they want you to find true love but really they want you to keep dating. I am thinking of a lot of HR at companies, recruiters, and people that enjoy interviewing. I have worked at startups that weren't really growing that fast but we're always interviewing to fill in the churn. Interviewing feels productive, feels like a company is growing. They say: We only accept the best so any test is reasonable. This tends to discount people's accomplishments and the idea that smart people can learn.
The internet makes it possible screen a zillion candidates, so like dating it feels like there are a million fish in the sea. Why value anyone's time when there is so many to consider? I was thinking about putting my CV for a very senior role and before you could put it in they made you take this like web IQ test. Seriously? I would worry about anyone who go through that for a job that expected more than ten years high level experience. Pass.
The core problem IMHO is that a great many of the people hiring developers are not themselves developers and have little to no technical knowledge. Companies depend on these ridiculous hiring processes because many decision makers believe it allows them evaluate candidates that they have no other way to evaluate. They see Google using these approaches and figure if it is good enough for Google it is good enough for them -- not realizing that Google is an entirely different situation with needs that don't match their own (Note to 99% of companies in existence, you are NOT Google and Facebook). I speak from experience. I have been hiring and managing IT staff for 20 years. I also happen to have 25 years of experience in development and infrastructure. One of my priorities when taking over an IT division is to get rid of these useless tests and I have received push back from internal recruiters, HR, and non-technical management every time I have attempted to do this. It requires moving a good percentage of of the hiring process from non-technical management to the IT staff and its not an easy change. Recruiters and non-technical management see it as a threat to their positions. Until there is a realization that you have to know something about a topic to judge the skillsets of others I don't see this improving (I expect that to happen... never).
I disagree with the OP's premise. Yes, nobody is going to write a BFS or `Math.pow()` on the spot, but it's way too easy for people to bullshit about their experience to rely on that alone, so BFS and `Math.pow()` is what we've got to work with. While I'm a proponent of giving interviewers a bit of homework and making the interview a pairing session, there are plenty of people that complain about this being free labor (even if it isn't). OP mentioned earlier that looking these up is easy enough, so what's the harm in looking these up before the interview so you can get that out of the way?
Also, failing five face-to-face interviews smells of personality or culture fit issues, not tech issues, IMO. I've interviewed tons of people over the years, and the ones that pass the phone screen but fail the tech screen usually failed due to poor culture fit (or padding their knowledge a little too much). I would see if it's possible to message one of your past interviewers and ask for a honest opinion of what they thought of you. While you're unlikely to get a response (giving interview feedback is, sadly, a big HR no-no), some people might budge on your offer.
I'm not exactly a gifted programmer or anything but a BFS seems pretty reasonable in an interview depending upon the amount of rigor / efficiency being demanded. I remember doing it for one of my very first interviews where I was asked to implement a website crawler and hold onto URLs. Having written a lot of them while trying to scrape sites for info before every other site had an API, this was super fast for me and was a very practical problem. It's not like they're asking for a topological sort of a graph where you can use Prim v. Kruskal and now you have to make sure you remember that near the neurons that activated your memory of your 3rd week of sophomore year 2nd semester when you had a really nasty cold. If you haven't heard of breadth-first v. depth-first that should be simple.
I do this problem constantly on my laptop when I'm looking for files and start getting annoyed at how long a search is taking. You start applying -maxdepth to a find command and fumble through directories perhaps and do a for loop. This is how I wind up doing a crude variant of k means clustering using cut, sort, uniq, and some creative use of awk when trawling through a bunch of log files.
But I do feel that anyone pretty serious about programming as a career understands there's little to be gained by more or less bitching about the state of hiring and a lot more to be gained by spending a few hours or so working on some problem sets occasionally. We're all busy and have to keep our technical knowledge up to date of course, but almost every well paid professional has to do this (doctors and lawyers are required to do this to even practice, in fact). I don't bother interviewing for FAANGS because my brain's fried and burn-out makes working on interview prep an order magnitude harder, but I don't go around blaming everyone for acting in their own self interest either.
In this regard, A lot of interviews are designed to test soft skills.
I know many recruitment teams aim for soft skills first because they don't want to bother their technical staff if a candidate is not a good match.
Many algorithm questions are designed intentionally to see how you tackle an uncommon problem or even an unfair situation and to see if you have a strategy to solve it. Of course, a candidate invited for front-end position at a decent company knows how to tackle his common tasks regardless of how complex they are in comparison.
However, that is definitely not true about all interviews. Many companies just copy these interview formats without understanding what is the actual idea behind them. Or how to facilitate these interviews correctly with different candidates from different cultures in different situations.
But you shouldn't go to interviews with this assumption. I'm sure at least one of those BigCorps had a professional recruiter.
After all, hiring a professional recruiter is as hard as hiring a good software engineer.
I believe the fundamental problem is, most organizations interview in a style similar to testing in college: ask a question about a technical topic, evaluate if the answer is correct. This doesn't correlate especially well to how well a candidate will program if you hire them, but it's the method people learned in school for evaluating someone's knowledge of a topic, so it's what they use. Most developers, and most managers, have almost no training on how to interview well in order to determine who would be a good candidate, so they fall back on the only halfway-similar experience they have.
Now, this raises the question of why our society's method of educating people (or determining if that education has been effective) is not very well correlated to their real-world performance, but that's a whole 'nother conversation.
The weird part is that this is almost exclusively found in organizations that think of themselves as "tech"-y.
I work somewhere on the border between neuroscience and machine learning. Interviewing in a "neuro" group usually involves a lot of talking--what you've done on project X, how would you approach Y, what do you know about Z. Coding does come up, but in the context of stuff that I've done or would do on the job.
Applying for a very similar job in a tech company usually starts with me reversing strings on a whiteboard or abusing C++ templates to calculate factorials or something....
Breadth-First Search (BFS) and Depth-First Search (DFS) are actually both pretty interesting algorithms (although relatively simple for the basic cases - there are some variations), partly because of their applications.
It's actually initially a bit surprising that BFS has such a simple algorithm using a queue, as mentioned elsewhere in this thread and in the Wikipedia article about it [1]. Might be non-intuitive on first look, but then turns out to make perfect sense.
Many (most?) programming jobs are about understanding the tools and libraries of an ecosystem well enough to build something useful.
When I interview people, I want to know if they can think. I want to know what their attitude will be like (to work with/near them). I want to know what gets them excited (in the context of work, mind you).
The older and/or more things a candidate has done in their life, the more accumulated wisdom they will have. This will translate into making better choices earlier (about approaches to problem solving). Testing against university compsci concepts is more likely to get a candidate who will either ignore a well tested and commonly understood library in favor of rolling their own (less-maintainable) code.
This guy probably got a negative reaction because he says "hiring is broken", when what he meant was "my strategy for getting hired is broken." The goal of "hiring" is for companies to satisfy their needs, not to guarantee that every smart person that comes their way gets a job. A "hiring is broken" article coming from the position of a hiring manager would carry more weight.
Also I've never heard of this guy, not sure his handful of Medium articles and cookie-cutter tutorials is sufficient justification for his belief that Google should be lucky to talk to him.
Usually the people that says hiring isn’t brokens are the ones that benefit most from it. Algorithms and programming are not one and the same. The overlap but knowing algorithms tells me nothing about your knowledge of programming.
You know what I would be more interested in candidates knowing? Solving problems that have no immediate answers. For example, understanding how to architect a program without using a framework, Debugging a bug even though you know nothing about the library you are using (eg. Be able to read code and race the problem), and understanding the difference between algorithm and architecture in overall performance of a system.
You can memorise algorithms. You can’t memorise problem solving and architecture. Albert Einstein said something along the lines of, “Don’t memorise knowledge that you can look up in a textbook.”
What have you learned since becoming a programmer? Did you push your knowledge of programming or are you rushing to the next hype framework? I see many more of the latter than the former.
Knowing algorithms is like optimising for the flow of water for your tap in the house without understanding how the pipes layout affects the overall output. And that’s the problem when you only work on one small section of the program your entire career.
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.
OK, I can accept the fact that in some environments, knowledge of BFS (and the ability to implement it from scratch) can be considered a must-have skill for a front-end developer. (Not in all environments. But granted, in some environments).
But can someone please explain how the need to implement a function like findSum in less than O(n²) -- and in particular: to be able to whip out the sorting trick necessary to achieve it, while standing in front of a shitty whiteboard with strangers staring at you --
Can reasonably occur in an actual front-end engineering role?
[+] [-] Stoids|7 years ago|reply
> How many people can actually write BFS on the spot, without preparing for it in advance?
Ughhh, should I tell him?
> why would they ask me this question, what does breadth-first search has to do with front-end development
Tree data structures are really common in front-end.. like the DOM or JSON.
[+] [-] y-c-o-m-b|7 years ago|reply
I've been developing for well over a decade as full stack engineer. I've worked as a successful software dev at some big corporations (like Intel, and yes it was fulltime for several years) and almost always outperformed my peers. I work in finance now where everything is about managing portfolios for people - lots of numbers and heavy calculations.
I have no fucking clue how to write a BFS. I've never needed to know how to write a BFS. I will probably never need to know how to write a BFS. Coders like me write business applications where these things are literally never an issue. If there's something I need to know and don't, I simply research it. That's the point he's trying to make. Don't interview people on algorithms they will never ever use. It's as simple as that.
There are more productive ways to interview someone; for example take a bug in your product and see if the candidate can fix it. Or if you're worried about sharing proprietary info, then make a sample program that simulates a bug or feature that your application will use and observe the candidate working on that.
[+] [-] quasse|7 years ago|reply
I can't remember Djikstra's algorithm either, but I would happily try and write a 15 line brute force recursive maze solver in an interview.
Of course it's not something I expect anyone does day to day, but it's also the kind of simple problem that I'd expect almost anyone with a CS 102 level of knowledge to be able to reason out by just taking a few minutes with a pencil and paper. As an interviewer, even a brute force solution would demonstrate a good willingness to look at problems using your fundamental skills and reason about something you don't have a ready made solution to.
[+] [-] chowells|7 years ago|reply
> Ughhh, should I tell him?
Yeah, that's where I stopped reading. This isnt specialized knowledge. If you know how to program, you can write a BFS. The entire algorithm structure is in the name. The only extra details you need to remember or figure out are "use a FIFO for tracking what to check in the future" and "make sure you don't go backwards". Neither is some great secret. They're obvious if you sit down and think through (or talk about with the interviewer) the structure specified in the name of the algorithm.
This person is either not a good programmer or has a very poor attitude about solving new problems.
Hiring isn't broken. I'd reject this guy too. Knowledge about a specific technology is a lot less valuable than general knowledge and willingness to explore.
[+] [-] BurningFrog|7 years ago|reply
As far as I remember, I have never written any BFS code, and I would also find it absurd to be asked to do so in an interview. There is great library code that does this in any reasonable situation.
If you're the kind of shop that would rather write your own code than use third party libraries, then that's a really great sign that I shouldn't work there.
[+] [-] organsnyder|7 years ago|reply
If I had claimed a lot of algorithm-heavy experience on my resume, I would have expected my response to be met much more harshly. But, as my experience was focused more on API design and interactions with business stakeholders, it wasn't a useful question to gauge my competence. However, it was useful for gauging my personality. Like everything, context is vital.
[+] [-] fhood|7 years ago|reply
Be honest, how many of us implement our own data structures these days? I sure don't. I just build on or use whatever version of map comes with the language 98% of the time.
[+] [-] pier25|7 years ago|reply
99.999% of front end developers do not solve those kind of problems.
[+] [-] delinka|7 years ago|reply
As it stands, any of the libraries that do DOM manipulation for me also traverse the tree for me ... so, again, why do I need to implement a toy BFS in an interview?
[+] [-] scarface74|7 years ago|reply
How many software developers work on "unique problems" that involve hard computer science problems compared to the number that are just using an existing framework to solve business problems?
Tree data structures are really common in front-end.. like the DOM....
And most of the time you're going to end up using a pre-existing implementation....
[+] [-] faitswulff|7 years ago|reply
[+] [-] towaway1138|7 years ago|reply
[+] [-] Rumudiez|7 years ago|reply
Accessing properties of a known object is better handled with the selector pattern. I guess you might use BFS to implement a search feature for user-generated content on the fly? I don't think it's relevant to most FEDs roles making CRUD apps with backend searching APIs.
[+] [-] drugme|7 years ago|reply
I agree with the sibling commenter: responses like these are very condescending -- and basically prove the main point of the original article.
And BTW:
Writing an Instagram clone in Angular doesn't really tell me much about your problem solving skills when faced with a unique problem.
Neither do your made-up puzzle problems.
[+] [-] oarabbus_|7 years ago|reply
[+] [-] eagsalazar2|7 years ago|reply
The reality is that interviews are broken. Not because of this guys subjective perception that it is so but because for employers you just aren't getting the SNR to justify typical interviews. People who cling to that approach anyway are largely, IMO, motivated by ego and cargo cult (lack of understanding and creativity). In addition, in that context, interviews are also broken because in being worthless, they are demeaning to the candidate who isn't great at tap dancing on your command.
What does work is past performance and actually working together. Both are problematic data to get at so I don't think there are easy answers here. We do a resume review to see if they even claim to have the expertise we're interested in, a very short and simple "gut check" coding exercise (not tricky, just checking they can actually write decent code and tests), a 30min phone conversations where we check that both parties are aligned on what we're looking for, contract to hire, then exercise extreme discipline in parting ways with people that aren't great before converting to W2. Our SNR is pretty good. A lot of people don't want to contract to hire so this system has cons. YMMV of course.
[+] [-] fatnoah|7 years ago|reply
[+] [-] alexandercrohde|7 years ago|reply
I understand, I've felt bitter about interviews before, I'm sure some interviews were unfair. But I also recognize this bitterness is a weakness of mine, unproductive, unattractive.
The way the author indulges in this resentment would make me very cautious about recommending him regardless of technical capability. An employee who has low tolerance for the massive randomness/unfairness in the world probably would get sick of most companies pretty quickly.
[+] [-] taurath|7 years ago|reply
The issue I think the poster is having is they just don’t understand how algorithm interviewers think - it’s totally reasonable to think oh, frontend has a DOM tree usually, so they should know BFS (even though you’d rarely if ever use your own traversal alg - leave it to the people actually researching it, not the person building a frontend).
[+] [-] ptero|7 years ago|reply
On site interviews usually evaluate not only technical competency but also whether that person is OK to work with, especially during crunch times. Being able to point to a few github projects is good, but not sufficient. When faced with a question one cannot answer staying positive and trying a few options is often sufficient to get off the hook.
[+] [-] dunpeal|7 years ago|reply
If every interview you ever took is terrible, then you are probably the asshole.
[+] [-] drugme|7 years ago|reply
Another way to look at it that they're a ... human being, attempting to come to terms with a truly toxic and dehumanizing system.
In response to which my gut instinct is not to defend the system, as would appear to be yours. But to recognize, as the original author does, that the system truly is fucked.
And if we're to maintain our health and sanity -- at some point one has to simply decide to "just say no", and start looking for and building an alternative.
[+] [-] lelima|7 years ago|reply
I got this quote after failing google interview in the last round.
"Success consists of going from failure to failure without loss of enthusiasm."
Winston Churchill
[+] [-] LaGrange|7 years ago|reply
You're hiring a software developer, not an actor portraying a generic love interest.
[+] [-] SamWhited|7 years ago|reply
I always wish this too. At my previous job a (also at BigCorp) candidate reached out to ask why they hadn't been selected so I started putting together a little email for them trying to give polite feedback and encouraging them to apply again in a few years (they were great, but we needed a more senior role and had no open junior positions at that time). I asked my boss to review it and make sure it was okay, and he told me that under no circumstances do we ever give candidates feedback because if you say one wrong thing it's a lawsuit waiting to happen. Having been on the interview side where I really wanted to know how I could have done better, I was a bit angry on behalf of the candidate.
[+] [-] faitswulff|7 years ago|reply
Wow, how widespread is this? I've _always_ asked for feedback and I've gotten meaningful feedback maybe once.
[+] [-] bbulkow|7 years ago|reply
[+] [-] taurath|7 years ago|reply
[+] [-] cal5k|7 years ago|reply
With that said, my interview process basically is:
* 30 minute intro call to dive into the CV a bit and see if it's worth everyone's time to go further
* 1.5-2 hour pair programming exercise using the actual language & framework they'd most likely be using for the job
* If that goes well, 30-60 minutes to meet with the team and figure out if everyone will get along
That's it. No whiteboarding, no FizzBuzz, no algorithms. If we make a mistake we try to recognize it within 6 weeks of the person starting in that position.
[+] [-] TulliusCicero|7 years ago|reply
This advantages people who have actually used that language/framework for prior jobs. If that's a thing you want to optimize for, then that's fine. If you want to evaluate people as more generic software developers, it's not so great.
That's why whiteboarding algorithm questions can be useful. They're sufficiently abstract to generalize to lots of different 'stacks' and experience levels. If you just want to get generally competent developers first and then figure out where to put them later, then this type of question can make a lot of sense, which is why Google, Facebook, et al. use them.
[+] [-] anderber|7 years ago|reply
I think the 6-week "probation" period is an excellent idea. Since most of the time you can recognize if they are a good fit or not.
[+] [-] 40acres|7 years ago|reply
I can't think of another industry that is as high paying as software development, with such a low barrier to entry (formal education matters less and less) with such transparency regarding the interview process (books, blogs, literal guides from the company itself). And HN is flooded with a couple of posts like this every single month, is it perfect? No. What is? At the end of the day this just looks like entitlement.
[+] [-] zanny|7 years ago|reply
If the candidate has no resume and nothing to prove they have any skill then yes, give them a rigamarole. But for don't ask a staff artist to speedpaint you the view out the window with crayons in a lined paper binder in half an hour. They give you their porfolio, you inspect it, and if they are accredited and recognized you don't waste their time on quizbowl.
Arguing about it though is mostly pointless. The awareness is out there that these companies are throwing away not just the on hand candidates they turn down for failing their charade game but also the legions of potential employees turned off by the theatrics and immaturity of software hiring. The OP is absolutely right to say interviewing in tech is draining because you go from thinking yourself competent on the outside to interviewers trying to beat you into a sobbing mess on the inside. Its adversarial from the start at almost every company, it certainly contributes in large part to the lack of women participating in development, and businesses seem to be just fine with the outcomes since they know what they are doing is awful but so long as they are "hip" and popular they can get away with it, with an endless list of potential hires to give the rigamarole to.
[+] [-] ucaetano|7 years ago|reply
I had the same impression, particularly driven by these quotes:
From this day on, I was even more disappointed — both with myself and tech hiring process — rejection, rejection, rejection. It honestly feels as if I am a complete failure and an unhirable candidate. How is this possible — I have received emails from people all over the world, who praise and give me thanks for the work I’ve done on my open-source projects and tutorials (and I say this as humbly as I can); people who see me as an expert on Hackhands; co-workers, friends and acquaintances from meetups, hackathons, conferences who apparently think I am a decent programmer—but I cannot pass a single tech interview. How?
TBH, the author sounds like someone who went to the interviews completely unprepared, believing that just because they have some open-source projects and tutorials, they deserve to be hired.
Nobody deserves anything. Most of my friends who went up for interviews with FAANG (or whatever is the latest acronym) studied and prepared for months even before applying.
[+] [-] joshstrange|7 years ago|reply
Also previous discussion: https://news.ycombinator.com/item?id=11579757
[+] [-] ebg13|7 years ago|reply
If you balk at breaking down a relatively simple and straightforward problem into approachable steps that a computer can interpret, then what exactly do you think that programming is? You don't need to _know_ the algorithm. You need to be able to think like a problem solver. And if you can't do that, then what exactly are you doing?
> Anyway, that did not go too well, obviously, because it has been a long time since I took an Artificial Intelligence course in college
You should be able to do this even if you've never done it before. You have a start, you have an end, and you have decisions to make to get from the start to the end. That's the literal definition of programming.
The only people I know who think that basic pathfinding is some voodoo dark magic artificial intelligence problem and not just a simple straightforward algorithmic process that you should be able to do in your sleep for the rest of your life immediately after the first week of Intro CS 100 are not software engineers.
[+] [-] Twirrim|7 years ago|reply
There is just too much legal risk from doing so. Too much risk of wording being misinterpreted and being turned around to be discrimination etc. To provide feedback you'd have to have so much oversight and absolutely ridiculous levels of paranoia about the potential interpretations of what you'd said that the risk is just not worth it.
The value giving feedback to candidates provides to the company is next-to-nothing as well, especially for the larger companies.
[+] [-] georgeecollins|7 years ago|reply
The internet makes it possible screen a zillion candidates, so like dating it feels like there are a million fish in the sea. Why value anyone's time when there is so many to consider? I was thinking about putting my CV for a very senior role and before you could put it in they made you take this like web IQ test. Seriously? I would worry about anyone who go through that for a job that expected more than ten years high level experience. Pass.
[+] [-] bluejay2387|7 years ago|reply
[+] [-] nunez|7 years ago|reply
Also, failing five face-to-face interviews smells of personality or culture fit issues, not tech issues, IMO. I've interviewed tons of people over the years, and the ones that pass the phone screen but fail the tech screen usually failed due to poor culture fit (or padding their knowledge a little too much). I would see if it's possible to message one of your past interviewers and ask for a honest opinion of what they thought of you. While you're unlikely to get a response (giving interview feedback is, sadly, a big HR no-no), some people might budge on your offer.
Good luck?
[+] [-] devonkim|7 years ago|reply
I do this problem constantly on my laptop when I'm looking for files and start getting annoyed at how long a search is taking. You start applying -maxdepth to a find command and fumble through directories perhaps and do a for loop. This is how I wind up doing a crude variant of k means clustering using cut, sort, uniq, and some creative use of awk when trawling through a bunch of log files.
But I do feel that anyone pretty serious about programming as a career understands there's little to be gained by more or less bitching about the state of hiring and a lot more to be gained by spending a few hours or so working on some problem sets occasionally. We're all busy and have to keep our technical knowledge up to date of course, but almost every well paid professional has to do this (doctors and lawyers are required to do this to even practice, in fact). I don't bother interviewing for FAANGS because my brain's fried and burn-out makes working on interview prep an order magnitude harder, but I don't go around blaming everyone for acting in their own self interest either.
[+] [-] stunt|7 years ago|reply
I know many recruitment teams aim for soft skills first because they don't want to bother their technical staff if a candidate is not a good match.
Many algorithm questions are designed intentionally to see how you tackle an uncommon problem or even an unfair situation and to see if you have a strategy to solve it. Of course, a candidate invited for front-end position at a decent company knows how to tackle his common tasks regardless of how complex they are in comparison.
However, that is definitely not true about all interviews. Many companies just copy these interview formats without understanding what is the actual idea behind them. Or how to facilitate these interviews correctly with different candidates from different cultures in different situations.
But you shouldn't go to interviews with this assumption. I'm sure at least one of those BigCorps had a professional recruiter.
After all, hiring a professional recruiter is as hard as hiring a good software engineer.
[+] [-] rossdavidh|7 years ago|reply
Now, this raises the question of why our society's method of educating people (or determining if that education has been effective) is not very well correlated to their real-world performance, but that's a whole 'nother conversation.
[+] [-] mattkrause|7 years ago|reply
I work somewhere on the border between neuroscience and machine learning. Interviewing in a "neuro" group usually involves a lot of talking--what you've done on project X, how would you approach Y, what do you know about Z. Coding does come up, but in the context of stuff that I've done or would do on the job.
Applying for a very similar job in a tech company usually starts with me reversing strings on a whiteboard or abusing C++ templates to calculate factorials or something....
[+] [-] vram22|7 years ago|reply
It's actually initially a bit surprising that BFS has such a simple algorithm using a queue, as mentioned elsewhere in this thread and in the Wikipedia article about it [1]. Might be non-intuitive on first look, but then turns out to make perfect sense.
[1] https://en.wikipedia.org/wiki/Breadth-first_search
https://en.wikipedia.org/wiki/Depth-first_search
[+] [-] blunte|7 years ago|reply
When I interview people, I want to know if they can think. I want to know what their attitude will be like (to work with/near them). I want to know what gets them excited (in the context of work, mind you).
The older and/or more things a candidate has done in their life, the more accumulated wisdom they will have. This will translate into making better choices earlier (about approaches to problem solving). Testing against university compsci concepts is more likely to get a candidate who will either ignore a well tested and commonly understood library in favor of rolling their own (less-maintainable) code.
[+] [-] normal_man|7 years ago|reply
Also I've never heard of this guy, not sure his handful of Medium articles and cookie-cutter tutorials is sufficient justification for his belief that Google should be lucky to talk to him.
[+] [-] kskdndnsn|7 years ago|reply
You know what I would be more interested in candidates knowing? Solving problems that have no immediate answers. For example, understanding how to architect a program without using a framework, Debugging a bug even though you know nothing about the library you are using (eg. Be able to read code and race the problem), and understanding the difference between algorithm and architecture in overall performance of a system.
You can memorise algorithms. You can’t memorise problem solving and architecture. Albert Einstein said something along the lines of, “Don’t memorise knowledge that you can look up in a textbook.”
What have you learned since becoming a programmer? Did you push your knowledge of programming or are you rushing to the next hype framework? I see many more of the latter than the former.
Knowing algorithms is like optimising for the flow of water for your tap in the house without understanding how the pipes layout affects the overall output. And that’s the problem when you only work on one small section of the program your entire career.
Apologies for the rant..
[+] [-] drugme|7 years ago|reply
OK, I can accept the fact that in some environments, knowledge of BFS (and the ability to implement it from scratch) can be considered a must-have skill for a front-end developer. (Not in all environments. But granted, in some environments).
But can someone please explain how the need to implement a function like findSum in less than O(n²) -- and in particular: to be able to whip out the sorting trick necessary to achieve it, while standing in front of a shitty whiteboard with strangers staring at you --
Can reasonably occur in an actual front-end engineering role?
[+] [-] banachtarski|7 years ago|reply
It's not even just the attitude. It's the competence too. If you can't code a BFS on the spot, sorry... that feels like far too low of a bar.