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.

A candidate who freaks out upon being asked that question is not a candidate whom I'd trust to be a good problem solver. Solving a problem with simple constraints is something that happens all the time. If you don't know how to approach that, you could just "look it up", but how would you even know what to look up?

I disagree. My experience has been that these problems are exceptionally rare.

They're so uncommon that programmers get excited when presented with such a problem. It feels like "real programming" as opposed to fixing bugs, writing prototypes, or writing business logic.

> I'd expect an engineer with years of experience to have the strategies in a sort of unconscious memory, like a rock guitarist who plays the right chord progressions without knowing what they're called

This is fantasy. You're comparing the average programmer to musical savants? What?

You happen to have memorized a bunch of algorithms for traversing data structures. That's great, but nothing about that is "unconscious memory". The fallacy is expecting everyone else to have memorized the same thing you have memorized.

> If you don't know how to approach that, you could just "look it up", but how would you even know what to look up?

Google for "tree traversal" and spend 10 minutes researching common algorithms. Pick one that fits. Spend 20-30 minutes writing it (hopefully with some tests). Worst case you've spent an hour.

Someone who memorized the algorithm could probably write it (with tests) in half the time. And that's okay because how often are you doing tree traversal? And even if you're doing tree traversal all the time then you'll have memorized all these techniques in 1 month anyway.

They didn't describe a musical savant. They described someone who learned to play the guitar without any background in music theory. The analogy was not someone playing a chord without knowing the name of the chord, it was someone playing a chord progression without knowing the formal musical basis for that progression.

That kind of intuition is very common in guitarists, and I thought the analogy was rather apt.

I have no idea what guitarists and other musicians you know. I know quite a few and they've had to put in serious work on music theory (most from a young age). Many also started out with instruments like early piano lessons and transitioned to guitar.

It's quite literally a language you need to learn (memorize); kinda like maths actually. Some things may seems intuitive but only savants can compose actual music without training in music theory.

Composing music is to playing a chord progression as writing a naive algorithm implementation is to designing an optimal algorithm.

I don't see why any memorization should be necessary. I have never written a BFS algorithim. Yet I can immediately think to two different ways of implementing it. In fact, when reading the article I googled BFS to make sure it wasn't referring to something else because BFS seemed so simple to implement. All you have to do is place every node's children in a FIFO que and process the nodes in the order they are added. You could also use two arrays, one for the current level of nodes and one for the next one. It is only slightly more complicated if you are traversing a graph, rather than a tree, as you need to track visited nodes to avoid repeats.

Also, the utility of BFS and DFS in frontend seems hard to ignore, the majority of the data structures are trees (html, xml and json) and these are the two ways to traverse them.

> They're so uncommon that programmers get excited when presented with such a problem.

What about "process these things in this order" is uncommon? If anything, the constraints are far simpler and easier to understand than most of the business logic I implement.

Neither have I, but we both have prior knowledge that accounts for solving most of the problem. We know how trees are implemented. We clearly know what BFS is and what's "tricky" about it.

Someone hasn't dabbled with tree traversal has to grok a lot of information in the heat of an interview.

> Also, the utility of BFS and DFS in frontend seems hard to ignore, the majority of the data structures are trees (html, xml and json) and these are the two ways to traverse them.

I'm not 100% sure about frontend, but I haven't heard of anyone writing tree traversal algorithms for a DOM tree. That's all handled by either browser APIs (document.querySelectorAll?) or lower level libraries (ReactDOM?).

> What about "process these things in this order" is uncommon? If anything, the constraints are far simpler and easier to understand than most of the business logic I implement.

That's exactly the point. Think about it... there are literally dozens of ways to implement a BFS. The currently accepted standard way of writing a BFS is the most concise and efficient.

A minuscule amount of your business logic is as concise/efficient. Most of the time your business logic will balance finding the best solution with meeting milestones (milestones usually win).

So let's say someone doesn't have any experience traversing trees (why would they? you rarely have to, if ever). Let's also say that they haven't memorized what BFS is and what the constraints are. You're presenting them with a new problem and expecting them to come up with the most efficient/concise solution to that problem. The only people who get rewarded here are people that simply memorized the solution or the solution space. In effect you've validated nothing.

I did the some of those interviews (not specifically with BFS, but with similar problems) and my answer to that is: Nope, I do not care about "most efficient/concise solution to that problem". I just need some evidence that you are trying to solve this problem. I am here to help them -- after all, for the interview to be useful, I need to see your work.

So I'd formulate the problem (if the person forgot what those 3 letters mean), draw a diagram if candidate is having difficulty, give increasing hints for the solution ('How would you do it manually? Which node would you visit first? What about next one?' and so on...)

Even then, a surprising number of people would just give up. It is kinda weird -- it looks like when they hear some words they just think "OH NO THIS IS DIFFICULT" and stop even trying.

Those get rejected. We have often have difficult problems. If you stop at one thought of algorithms, you get 0%.

And if you have not memorized what BFS was, and I had to draw a diagram of the tree and trace the path, and give you a hint about maybe using some sort of queue for unprocessed problems and you did not even finish the solution at the end -- you'd still get 80% and might very well get an offer.

Ummm... what? Basic DFS of trees with nested foreach loops is incredibly common. It is not a generic, depth blind traversal, but it most certainly is tree traversal.

> You're presenting them with a new problem and expecting them to come up with the most efficient/concise solution to that problem. The only people who get rewarded here are people that simply memorized the solution or the solution space. In effect you've validated nothing.

If somebody gives up on solving such a simple problem, why would I ever want to hire them?

> The only people who get rewarded here are people that simply memorized the solution or the solution space

Says who? You are making a bunch of assumptions about why the question is being asked.

> as opposed to fixing bugs

bug: "takes too long to find a <file / json field / html node>"

It's a real problem.

Right. My point was the problem is perceived as "basic" because the commenter memorized solutions in the problem space. If it's not something you deal with regularly (or have interest in) then it isn't as basic as it seems.

People that haven't memorized the most efficient/concise solution also freak out because they know that their whiteboard solution is going to be judged on the merits of the industry standard solution.

> bug: "takes too long to find a <file / json field / html node>"

This is almost always an issue with an underlying library. The better question is why your programmers are wasting time writing slow BFS code when they should be using well tested solutions.

Example: I recently needed to write some AST transformation code. Did I write my own AST node traversal code? Hell no! I picked a library that did the job. I spent about 20 minutes catching up on state of the art AST traversal (so I'm not blindly importing a bad solution) and let the library do the work.

The point is you wouldn't know what to search for. If you don't know anything about cars, you wouldn't be able to search for "alternator fault". The best you could do is "engine problems" which won't help you solve the actual problem.

I would expect any interviewee that calls themselves a programmer to talk me through a reasonable answer to that question. Forget about what BFS means - you don't even need to know what a tree is. Looking at the image is all you need.

[1] https://blog.codinghorror.com/why-cant-programmers-program/

[2] https://upload.wikimedia.org/wikipedia/commons/3/33/Breadth-...

I'll go a little further and say that if you've qualified a candidate as capable of busting out the routine Javascript required to wire up typical front-end code, if you can't teach that developer how to implement BFS within the confines of a single interview, you the interviewer share some of the incompetence. Certainly that would be the case for a manager or team lead!

The reality is that BFS is for most jobs (frontend AND backend) a trivia question, and a status-seeking mechanism for interviewers.

If an interviewer wants to test problem solving skills with a BFS, no problem:

- Draw a tree on the whiteboard (interviewers writing the whiteboard is highly undervalued; it calms the candidate)

- Explain what a BFS is. It's easy to draw out each step in a BFS algorithm.

- Ask the candidate to write some pseudo code that implements it.

And they still failed it! It is not about trivia or what BFS is, it is all about can you reason about algorithms.

(Disclaimer: our actual interview problem is slightly different, but it it still a very basic CS one)

Okay.. so now this is about you and a bad candidate rather than the person pointing out that interviewing is broken. Got it.

Because someone saying "How would I know? If, and when, I need to know how tree-shaking is implemented, I will go look it up." makes me sad. The tree-shaking algorithm was not given to us by ancient gods. As a programmer, you job it is to solve problems no one has solved before. Interviewing may be indeed broken, but the original article was not showing any evidence of this.

Because BFS/DFS are so easy to interchange, I'd strip ordering out entirely: here's a collection of stuff where each element may also point to other stuff in the collection, starting with this element search through the stuff to see if you can find a certain element.

If I was going to ask this problem, I'd help a nervous-looking candidate by contrasting the problem (or leading with) a simpler still one: here's a collection of stuff where each element can point to at most one other thing, starting with this element see if you can find a certain one in the collection.

Linear search is, technically, an algorithm. Graph search just extends it. All these people railing against algorithms in interview problems as non-applicable surely have at least written a for loop over an array and had an if statement somewhere inside, right? Linear search. When I've given interviews I don't try to make them based on "algorithmic knowledge"[0] but at the same time I really don't like the trend of thinking of algorithms in general as "oh, that's someone else's job, I never use those" or "I can only implement algorithms by memorizing them."

[0] When I was just starting to get asked to give some I lazily asked a colleague for a reference problem, they sent me https://leetcode.com/problems/jump-game/description/ and I read the problem, immediately recognized that the general approach of graph searching would solve it[1], and coded up the 12-15 lines or so it took, made some tests, fixed some minor mistakes... Total start-finish time was 10-15 minutes, not the fastest. There's also a solution to that problem that doesn't require thinking of it as a graph, too, but I think it's harder to get the insight. Anyway, nice problem, I thought, I'll only give a problem if the candidate has 2x the time it takes me to solve it as a buffer for interview nervousness/whatever, but after giving it to a few people only one of them managed to solve it in like 50 minutes after creating a pretty verbose and pseudo-coded BFS system. (My initial approach used DFS, but it doesn't matter here -- though for the jump game 2 sequel problem which asks to find the shortest number of jumps, BFS makes sense, and it's easy to take the solution for the first problem and make minor alterations. General algorithms like "search" are great and widely applicable.)

[1] In retrospect, before I saw the problem I was writing a simple game of go client as a side project, and had recently implemented a function to, given a point on the board, determine if there's a stone there and if so determine if it's part of a larger group of stones and return their coordinates. So in some sense the problem was already 'primed', and I've written a lot of graph search skeletons for both fun and profit. It's interesting to hear that some people go decades without doing so...

It is hard to say if U/F would be more efficient for this problem. U/F can perform two `union(a, b)` and `find(a, b)` operations in O(lg n) runtime complexity, or, with some more effort (path compression), nearly constant time (a, b representing node indexes). But for this problem a first pass over all indexes would be required to build the disjoint set from the input.

I think for small inputs DFS or BFS would be more efficient, and have the plus of not needing extras storage (U/F would require a second array the same size than the input). For large arrays, probably U/F would win since the input array may encode potentially a lot of edges (say, if each index contains a number large enough) and DFS runtime complexity is O(Edges + Nodes).

Anyway, I think U/F can be really useful in the context of job interviews, there are many problems that can be reduced to connected components, after some massaging.

Here's an implementation I did a while ago [2]. Even though I love the algo, I don't really remember the details about path compression... time to refresh my memory I guess :-D

[1]: https://algs4.cs.princeton.edu/15uf/

[2]: https://gist.github.com/EmmanuelOga/bcafad14715a3f584e97

For the jump game problem, I'd expect DFS would still win almost all the time even when there are many branches because it doesn't have to explore every element of the input array except in the worst case (and you can greedily explore a neighbor without having to discover your other neighbors first), whereas to build a complete union-find structure would. Still, the fastest solution in general is probably just the single pass: if you have the insight that you can keep track of a 'max reachable index' and update it at each step to max(current-max, i + A[i]), bailing with failure if you hit an index > the current max and having no more jumps, or bailing with success if your max becomes >= the final index. (I never had this insight myself.) It could be slower of course, e.g. if the array was something like [bigNum/2, lots of 0s, bigNum/2 again in the middle, lots of 0s, end at index bigNum].

If I give you a description of what a BFS is, you as a programmer should be able to write one. A BFS is rather trivial. You shouldn't have to know how to write it, you should be able to figure it out. The same goes for implementing a linked list or the FizzBuzz problem.

As a programmer, you need to make up algorithms on the spot to solve business problems. You don't know the solution beforehand, you figure it out, that's your job. It's the key skill that basically separates you from a typist.

> There are more productive ways to interview someone; for example take a bug in your product and see if the candidate can fix it.

This is a different skill. It's an important skill, but finding errors in an existing structure and fixing it is different from being able to create that structure in the first place.

I'm working on something at the moment, and one of the key features is that while there's a fair amount of data, none of the structures are particularly big - and are very unlikely to ever become big.

So my thought process is that stupid brute force algos are absolutely fine for this domain.

If I have performance problems I can look into optimising them.

If I had hundreds of terabytes of data to start with, I'd take a different approach, and I'd research - not invent, because I don't care to reinvent a wheel if someone has already produced a much better solution - more efficient algos.

If none of the above work, then I'd consider improvising something and testing how it performs.

Would this pass your interview process or not? Do you want someone who's going to brute force an answer to your toy problem and think they've solved it with something that works but is inefficient, or someone who has memorised a collection of standard answers but maybe can't improvise something new, or someone who is going to check what's already available to save time, or someone who can improvise a super-efficient answer and do it even if it's not needed?

Who would you pick?

Do you really think this question has a simple answer?

Yes, that sounds very reasonable.

> Do you want someone who's going to brute force an answer to your toy problem and think they've solved it with something that works but is inefficient, or someone who has memorised a collection of standard answers but maybe can't improvise something new, or someone who is going to check what's already available to save time, or someone who can improvise a super-efficient answer and do it even if it's not needed?

First of all, let's talk about what I don't want. I don't want someone who can't solve the most basic problems. I'm not interested in all these details at this point in the process. Don't get stuck in analysis paralysis.

> Do you really think this question has a simple answer?

No, but it's not the question I am asking. My question would be, can you solve basic problems? I'm not looking for 100% accuracy in testing, that's impossible. Surely some kid fresh out of college will get an "unfair advantage" with something that's still on their mind, while some genius may have a bad day and fumble the test. I wouldn't personally pick BFS as a test either, but the fact that you should be able to solve it remains. The fact that "you may never need it" is irrelevant.

For all software businesses there is only one question to ask candidates: "Can you help us ship working software that solves the problem of our customer"

What I can tell you is that there are a number of books written on this subject if you need help identifying the correct interview questions to ask.

If I had a magic truth-detecting wand, it might be a good one, but in practice, candidates may be lying or honestly overestimating their ability.

You're not someone who would look at the screen and just say "I don't know" (or thank me for my time and storm out).

Which is great and all, but it it's not a quality which correlates particularly well with the stated problem you are hiring for.

Now if you were hiring for the marketing department…

Repeat after me:

A good hiring process is one that will not be affected by the luck of the draw nor the personality of the candidate.

I've been doing this for a quarter of a century and I will tell you right now that the best engineers of my generation would indeed thank you for your time, never come back and quietly advise the extensive network of young people they mentor to avoid your company like the plague.

You're going to have a really hard time finding good hires if you restrict yourself to the pool of people who can "problem-solve something basic" according to your definition of "something basic".

Maybe ask: "How can this person help the team ship working software that solves the problem of our customer?"

It's less adversarial and opens your recruitment up to that pool of folk who have literally decades experience answering that question.

So, I will come up with a little problem which is something related to the work they'd be doing - like, a real thing they would have done if they where hired a month ago. (hmm, I wonder how they would have fixed jira-123)

I'm not looking for "the answer" - I'm actually hoping they don't know it (if they do, great: here's another...), but.. do they have what it takes to solve a problem? How much hand-holding would they need? Am I able to have a technical discussion with them? Even, where are they on the passive<->arrogant scale?

This, among other questions, will answer "How can this person help the team ship working software that solves the problem of our customer?"

Job history and qualifications don't tell me this.

If a candidate feels they're too important or experienced to do this, then by all means walk away.

The problem with that is when the best solution to a problem is a BFS, you may never recognize or realize it, because you know nothing about BFS. You won't know what to research for.

I see it when people who don't know what calculus is go to enormous efforts to develop workarounds that sort of half-assed work.

I see it in my own work when I didn't know about a class of techniques, so I invented some crappy solution. For example, reinventing bubble sort when I could have used quicksort.

BFS is awfully basic knowledge. How do you know you've never needed a BFS? Maybe you never needed a BFS because a linked list is your go-to data structure? Maybe you've been reinventing bubble sort. (I'm not the only programmer who incompetently reinvented bubble sort, not even close. I just didn't know any better.)

cf. https://escapethetower.files.wordpress.com/2010/12/tais-mode...

It's hard to do research when one doesn't recognize there's a problem, nor know what question to ask.

>The problem with that is when the best solution to a problem is a BFS, you may never recognize or realize it, because you know nothing about BFS. You won't know what to research for.

Just because someone doesn't know how to write BFS code doesn't mean they don't know what it is.

> BFS is awfully basic knowledge. How do you know you've never needed a BFS? Maybe you never needed a BFS because a linked list is your go-to data structure? Maybe you've been reinventing bubble sort. (I'm not the only programmer who incompetently reinvented bubble sort, not even close. I just didn't know any better.)

Never had to write a BFS in all my years of programming. I am one of those programmers that write glue code and are not "real" programmers by the definition of some here in HN.

Actually, it does mean they don't know what it is. BFS stands for "Breadth First Search". If a node in a data structure has two links, one going down in the data structure, and one going sideways, breadth first means going sideways first. "Depth First" means going down first.

That's the algorithm. It ain't rocket science. There's no trick involved.

Look, I think the dev hazing ritual that is current hiring processes sucks, but Algos and Data Structs are the language that we speak. We have to be familiar with them.

If their response is "this is stupid, no one has to know how to do this" and storm out with the same indignation that is present in half of these comments then they are not the ones who dodged a bullet.

It depends on the position you apply for, I'd say.

Some jobs require C++ and algorithmic skills. If you don't know how to write a basic algorithm in C++, then you might not be the best fit - and you might not want to join the company as a junior developer.

That being said - sorry to hear that was your experience. That shouldn't have happened, but it does.

If it's down to syntax errors, and the logic is correct, what the heck does it matter? Almost everyone writes code in an IDE that will deal with those syntax errors.

One writes code that cannot be compiled while the other does. Who scores higher?

Now, let's say you are a big company and have 100 applications for that position and do the math...

EDIT: I noticed you edited your post so it looks less inflammatory. Not cool.

Which is probably the root problem. Almost all tech hiring is carried out like a war between companies that want results and candidates who don't want to be treated like shit.

Because BFS has two approaches - 1.) I know BFS or similar example and will write it with no thinking 2.) I am figuring it out in head while saying things to keep you pleased.

You don't need to know employee internal thought process. Practically, BFS tests whether you are able to BFS, which is cool by me. It is simple enough so that people who were really unable to learn it should really be filtered out.

(It is ok to not know name, obviously. Just ability to find a thing in datastructure should be question.)

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.

You'd fail the interview. The type of interviewers that ask this style of question are never interested in seeing the the naive brute force approach.

Implement -> Evaluate -> Refactor

I'd rather have someone who could caveman the first approach, recognize the inefficiencies, and improve the execution than someone who rattles off a memorized algorithm to a common problem.

If the interviewer is wanting the eloquent solution right out of the gate, then the manager might be hiring for the wrong position.

I tried doing it -- even with the knowledge of how it works, it took me at least a day to get to an acceptable implementation.

There have been interviews I have failed and instead of blaming the interviewers I took the time to actually study the problem I was given. This has helped me become a better programmer.

Interviews that require extra knowledge outside of what the job actually asks for are definitely broken.

I don't doubt you've experienced differently. But if you have, I think it's likely the interviewer, not the question. Lots of interview questions can be abused, not just basic algorithms and data structures questions.

I'm loathing the potential need to ever eventually interview for a tech position because even on trivial things like Error trait impls in Rust I end up opening 3+ pages of documentation to verify I knew what I was doing at least, or often figure out better solutions with methods not on my brains hot path of solving the problem.

Theres nothing pleasant about having your tools taken away from you and then being looked down at when you are like a fish out of water. The OP even talks about it when describing the drain of technical interviews - nobody wants to be judged upon at their worst by strangers. Its humiliating.

> 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.

Programmers need a zen place to concentrate and focus. "Homework" assignments should be a good measure to test skills and questions on decisions made on his and how would he improve a code given the use cases would be more comfortable and now we are level playing field. my two cents.

Around here, the trend is requiring a 16-20 hour assignment just after a brief 15 min phone call, almost before starting the process at all.

Not only it is a ridiculous amount of effort to ask someone who may already be doing 8 hours a day programming but it's also a problem for the company. Either they have to spend significant effort evaluating each candidate's submission or -more likely, sadly- they only give it a perfunctory look and discard many on first glance. And considering that often the person doing the evaluation has his own tasks to do and is doing it on some spare time, they will tend to not make much of that effort.

The result is the company still needs to do significant effort and the candidate gets frustrated because they have had to spend a significant amount of time and, after having to wait for a couple of weeks -at the very least-, they get generic and useless feedback saying simply that they did not meet the expectations or whatever.

I would not mind at all doing a two-three hour on-site assignment. If you're there, they will at least have to make a similar effort as you are. I find this much more fair both as a candidate and as an employer.

I've had this exact thought. I got interview homework last year, was told to spend "no more than 4 hours" on it, etc, was mildly interesting. The next interview we'd have a discussion about the code and I'd present my rationale for various design decisions etc. But then I got the email that the interviewer had reviewed the code with an engineer and they decided not to move forward because there was a mistake and they "thought there would be more testing"! I felt that it was quite imbalanced to have spent 4 hours on this task, only to have it rejected without discussion after a short review.

So in the future I'm going to suggest that I'll be happy to do whatever homework assignment as part of a pairing exercise. That way I can see what it's like to work with them too.

Your success rate will be no less than someone who spends 15 hours doing whatever bullshit assignment there is.

"If only the author did these very precise things that they just so happened not to do, THEN I would find empathy". I'm pretty sure that's not how empathy works.

He probably isn't a good "programmer." He is a web developer, and has projects that are basically CRUD input and output.

He can stitch together various different components to build a functioning end product. This is a fine skill for most agency type jobs, and he will likely have a long prosperous career as a contractor.

As an interviewer, I'm always happy to talk to the candidate about the question I ask. I'm perfectly happy to answer "What is a breadth-first search? Why does it solve this problem?". I'm perfectly happy to talk about algorithms with them, and ask leading questions if the candidate explains where they're having difficulty.

As a candidate, I'm not interested in working with an interviewer who doesn't approach the interview the same way. Remember, all interviews are bidirectional.

This person's stated reaction to the question was anger that it was asked. Most likely masked in person, but even masked tells us a lot. It tells us he didn't actually talk to the interviewer. If he had talked to the interviewer and got garbage back, he would have been angry about how awful the people were, not that some technical question was asked. If he'd talked to the interviewer and got useful information back, he wouldn't have thought it was a bad question. The only options left are trying to stumble through it silently and getting it wrong, or sullenly saying "I don't know" and moving on.

And that's the problem. A good programmer isn't measured by being able to make things. A good programmer is measured by being able to work with others and make a positive contribution in a group. Everything this person is describing is how to make a bad first impression during an interview. Maybe he's a great programmer, but he's utterly failing to actually convey that in the important aspects during the interview.

I wouldn't hire him, and this writeup is exactly why. He needs to demonstrate that he's someone people want to work with. This article does the opposite.

This is something I feel a lot of interviewees aren't aware of, you DON'T have to know EVERYTHING.

I didn't know what a BFS was (I am primarily a front end web developer), so in an interview, I'd simply ask "Could you explain what that is? I'm sure I can find some way to do it."

As an instance, I looked up "Breadth First Search" on google just now, and saw that its just a way to search a tree one generation/level at a time. Once I knew that, the naive approach is simple (I'm sure there is a better way). Start a queue with node(0,0), and loop until the end of the queue, if you don't find the correct value, add the node's children to the queue, and keep going.

I totally feel for the guy, I've been rejected more times than hired, that's for damn sure, and each time is a HUGE blow to the ego, but you have to pick yourself up. I feel he is a great contract developer (not a dig, I am also a contract developer), but not necessarily someone I would hire full time.

No, that's it. That's why so many are ragging on him; it really is that simple.

This system is corrupted but looks like it suits big corps just fine. I have never evet been asked about my real experience on large corp interview. They just don't care about your github. Small companies asks about experience, but unfortunately some small companies copy FANG approach to interviews, cargo cult is magnetic.

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.

Do keep in mind that you're eliminating the places that wrote that "third party library" in the first place. Libraries don't just grow on trees (though they can help you navigate a tree).

Just a few weeks ago I had to knock out a test framework, creating an API from scratch (basically an object model on top of some websockets messages), because there's no library that's going to do what we need. Oh, I friggin' abused Python's import keyword to hell and back, but there was a lot of stuff that just needed to be written from scratch. Given there are a few tree-like structures, I'm sure I briefly weighed depth-first vs. breadth-first before hammering out the code. And this is nothing exotic, just a small company working in the industrial controls industry. And such a task is nothing exotic, it's why they hired me. But I think to effectively create something like this in an efficient manner, having at least a rough idea of something like BFS is table stakes.

One is not being asked to implement a red-black tree on a whiteboard, just something that I think a competent software developer could come up with from first principles. A company asks you, "which direction will you be searching, and how would you do that?", and you'll reject them. I mean this with due respect: you're probably right, neither party will want you to work there, and the filter worked. Hurray?

I'll tell you what grates me, though: the companies that insist they need someone like that, and then the new employee finds out that the culture is so borked, that said employee will never get to actually do that stuff. "We need test infrastructure." Turns out the reason they don't have any isn't for lack of someone to write it, it's lack of culture to do anything with it. As just one example.

Writing code in a vacuum is humongously dangerous even for simple things like piping strings. Its why so much C software ends up chock full of overflows, segfaults, and myriad security vulnerabilities.

Wouldn't it be nice to be able to use references / existing implementations while at the board being watched and timed.

But I wouldn't think for a second those people would be incapable of being good team members or productive coders. You just let them stay in their comfort zone and approach uncertainty in the ways they are comfortable with. They will know the best way they can approach solving a problem, and if you were testing for that instead in these interviews, they wouldn't be so harmful to participation in tech by "minorities" such as women or people of color.

I'm primarily a backend dev who did a little js a couple of weeks ago that required me to populate a dynamic tree with the results of an api call.

Although I think I went depth first, so I guess technically you're right....

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.

That is actually informative on your programming ability, not regurgitating buzzwords (albeit BFS is a light one) or rote memorization.

Like just hearing these kinds of questions is infuriating because I often immediately ask things like "is the data processing complex enough to justify threading it? what are the synchronization points? if the data processing is variable, we probably want a job pool, etc". The performance of code is almost always noninutitive until you have an implementation done in order to optimize it, and questions about searching graphs are almost always these "optimize light" problems where they want you to really know how to do the navigation right because of my precious 10 cycles per branch but don't want to even consider the operating environment that could influence the decision in anything but a purely academic setting.

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.

99.999% of front end developers do not solve those kind of problems.

Fun fact: I'm lying.

In general, I think it's enough to know what your abstraction does, rather than how it does it.

https://en.wikipedia.org/wiki/Leaky_abstraction#The_Law_of_L...

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?

Also, if you know that all the companies do this, why don’t you just study before hand? Tree traversals come up multiple times in the article. I understand the author’s frustration but not their (early) insistence on not studying for an important interview. When they did study later I wonder how seriously they took it based on the tone.

And what's the likelihood of that happening with a well-used framework? Maybe the interviewer wants to see my ability to debug problems - great let's do that instead. You want to see how I work? OK, let's pair on something. Pinning this to "implement BFS at the drop of a hat on a whiteboard or in this project" is bullshit.

>Also, if you know that all the companies do this, why don’t you just study before hand?

Fine. I'll implement a few solutions to the problem in the languages I'm familiar with and put it on GitHub. Now the interviewer can check it out and we don't have to waste time at a whiteboard.

In my experience, higher than you'd hope.

Just because the interview culture has evolved to this awkward unrepresentative generally unhelpful filtering method, is no justification for "well just do it that way and you'll be fine".

If I'm the new monkey, and someone smacks me for touching the ladder, I'm going to ask why and push back if there's no good answer.

I don’t think it’s about the BFS, it’s about attitude.

The maze solving could be solved by breadth first too. It is algorithm that can be used in many different contexts.

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....

There are positions that does not involve anything harder then BFS ever, but I would not say they are majority of them.

And the 20 years of professional development was after I had been a hobbyist writing 65C02 and x86 assembly language....

It makes perfect sense to not remember the name and that should be ok. But it really is not something complex - it is pretty much simplest algorithm used to explain the concept of algorithm to students.

My current employer asked me no programming questions even though I supposedly came in as a “Senior developer” in my small company.

He was more concerned about everything I mentioned and how could I help mature the organization.

Heck, he didn’t even care that I didn’t know any $cool_kids front end framework.

Whenever my last day on my current job comes and I don’t expect that to be for a few years, I’ll probably end up working for a consulting company as an overpriced “digital transformation consultant”, “implementation consultant”, or “solutions architect”. Do you really think they are going to ask me about my leetCode capabilities?

The same should be true for anyone at a certain stage of their career.

I don't get insulted over basic questions. Mostly because I worked in a company that did not asked programming questions. As a result had to work with few people who could talk design and maintainability such, looked like great socially and turned out they could not write the code except in simplest situations. It was not good and harm was long term, Largely because of resentments etc that build up in team who had to do someones work while that person was treated as superstar. Such person needs strategy to mask inability and those are all toxic - masking own inability by blaming others etc.

What are alternatives out there? Take home assignment, fizzbuzz, simple algorithm, trivia questions, requiring you to already know exact technology they use. Someone complains about every one of these. There is no hiring process that make everyone happy and fit everyone, but imo, as long as company does not go to some crazy extreme somewhere it should be fine. If candidate have to balance red-black trees then it is very clearly too much, figuring whether string is palindrom is not too much.

There is also something good to be said about repetitive hiring process where company can compare how people did on interview and then how they did in real life. As such, it will contain some generic or easy questions.

My interviewing process for developers is giving them a skeleton of a class with corresponding unit tests that they have to make pass.

Then they get another set of unit tests that they have to make pass without breaking the first set.

The code models a simplified version of real world types of problems we had.

Another way to screw hiring is to select for algorithms loving geek who seeks algorithmic challenge and can recite obscure edge cases - and then put him on position where he has to solve normal business problems or maintain unit tests because that is what job is. And then wonder why genius is demotivated and does not seem to produce.

But, I still don't think either of these search questions is outrageous or a deal breaking question. It is within acceptable questions range - partly because it is so common that I would expect a person to quick google it if they heard it twice already and did not figured it out in stress of interview.

The inevitable response to that is "well that's an exception, it's only occasionally needed." True, as far as it goes. But if you exempt all of these "rare special cases," you've suddenly exempted 10% of the work. That 10% is among the trickier bits (though the hardest is always organizational and product).

I also hate to say this, because it's snotty, but as far as obscure algorithms or tricky, complicated algorithms go... BFS and DFS don't really fall into those categories.

I don't think that's the issue though.

The issue, as I see it, is not that you had to figure out how to implement BFS. I think many of us are confident we could do that under professional working conditions. If I had a day and some data structures to poke around with, I'd write a killer BFS supported by tests if I needed to (I've had to do similar things in the past).

The issue is that interviews expect us to recall this kind of specialized and rare problem solving like it's a day-to-day thing. We as candidates are being judged on how well we can come up with a novel solution on the spot to something that many of us will need to do once or twice in a career, and will be able to solve under completely different conditions.

In short, for most candidates, these kinds of questions don't test anything realistic, and a lot of people have issue with that. It's like judging whether you want to go to a chef's restaurant based on how well they did on Chopped! They might do well under pressure because they have practice with it because they're always in the weeds because their restaurant is poorly run. A terrible dining experience might translate to a win on a cooking competition show, because the show isn't testing the chef on the experience they provide you. Just as these kinds of interview questions don't test you on how you'll actually be interacting with code and solving problems day to day.

But it's about friction: I want my coworkers to be focused on the genuinely hard problems, not spending a day writing a BFS. The current interview process does manage to probe that.

Going a bit deeper, the whiteboard interview process is a good proxy for ability to prepare over the medium term (a month or three of consistent studying should give you as good a chance as anyone to get into a generalist position at a prestige company) and of IQ. The latter is controversial and most organizations can't test for it directly (owing to legal concerns), but a relatively high IQ is a core requirement of technical roles, and whiteboards provide a solid proxy for that when coupled with the opportunity to prepare for them beforehand.

That said, I'd always go for someone who has the ability to deliver on complicated, large projects over someone great at whiteboards or who has a high paper IQ. It's just that it's pretty much impossible to evaluate for that in a way that works on a general application pool.

I would say big companies that hire new people or generalist programmers benefit greatly from them. These types of questions test for intelligence at scale without outright being an IQ test. In fact, I think I read somewhere that Google engineers' performance is strongly correlated with how well they do on their interviews.

Sure, these questions might not test for conscientiousness, curiosity and general agreeableness, but that's why you have the other portions of the interview.

All this being said, I don't necessarily think these questions work at most companies where the engineering teams are significantly smaller and you can really spend a lot of 1-1 time probing knowledge and experience and reviewing coding exercises. However, I would still say basic DFS/BFS and using a hash to solve a problem is still a must. I use them on occasion, even as a generalist.

As much as I think certain companies shoot themselves in the foot by spending their interviews asking trivia questions about e.g. Rails (because that's what they use), it's not unreasonable that they might just more highly value having someone who can be productive in their Rails world immediately against someone who, while excellent, nevertheless needs a week or several to onboard the ecosystem. Or in other words, they think the goal question is answered in the affirmative more strongly for someone already in the ecosystem. A dangerous assumption, but possibly valid. There are always tradeoffs to be made in the specificity and category of your questioning, but interviewers need to keep in mind how they contribute to the overall goal's question.

For larger companies, it's more likely that there are more problems to solve, and more likely a need to get people working on them sooner rather than later, so the incentives start pushing for addressing the goal of hiring (if not for all positions, at least for many positions) by answering a simpler goal question of "is this person smart and gets things done?" (which is just high IQ + conscientiousness) and hiring en masse. If you put such people to work on any of the problems you can rightly expect they will advance them some amount, even if they have to ramp up on a programming language / framework / whatever feature of the problem's environment first, and as time goes they can shift around the company to where they're even more effective. In addition to being fast it's also very fair with respect to people's backgrounds, suddenly it doesn't really matter if you have a thousand widely used github repos or not, have a 10 year experience headstart or just graduated a bootcamp, if you have a degree or not, if you know the framework already or not; people from the "wrong background" can still be hired if they can demonstrate they are sufficiently smart and conscientious to start working on one of the various problems you need work on yesterday. The fact we have to proxy this with whiteboard hazing sucks, it's expensive for everyone involved compared to just asking for ACT/SAT scores or the results of a previously taken IQ test when available and giving an IQ test when not. In my own interviewing I try to proxy for "smart & gets things done" (because that's all my teams at my current company have needed) in a less asymmetric/aggressive way while answering other questions since we can't hire everyone. But even the aggressive whiteboarding is better than every job interview screening for highly specific backgrounds and/or trivia knowledge...

And I agree that BFS/DFS is appropriate, though needlessly so (i.e. there are even simpler questions that take less time), as a first step in answering the business goal which is simply verifying: can this person who says they can program, actually program? Unless you're willing to train people to program, you have to start the cutoff somewhere. It's modestly appropriate to answer the question of: does this person know their craft's basic tools?

This is where I have a problem. Why are we the only industry that has this expectation of months of preparation? Engineers don't do it. Doctors don't it. Professors don't do it. Why?

An analogy from finance: if you take a pen and a paper, and think about it for a few minutes it'll be clear that buying a stock and a put option is equivalent to buying a call option (and a bond, since you're also locking in some capital). This is fine, and most people can do that. But the brilliance happens only when such things are immediately obvious to you, in the same manner as you don't need to consciously decode English while reading this sentence. It's another question whether this or that particular company really needs brilliance.

(not accounting for the people who are just bad at writing anything on the spot in a high pressure interview situation, of course)

If your point is that you do a mix of questions that are definitely relevant and some that are academic and might be relevant, why not just do 100% known-relevant questions? What’s the value add of asking questions that are less than 100% relevant?

My guess is: not very many.

Let's make up a synthetic problem, like "the closest friend which has property X". Then you'd first check all of your direct friends for X, then check friends-of-friends for X, then check friends-of-friends-of-friends for X, and so on. You'd go on forever until you either find a friend with property X, or run out of time/space.

This is the classic BFS problem, and I can see how it would make a good interview question.

DFS or IDFS can generally use space proportional to the diameter of the graph, which is far smaller.

That caveat with BFS turns out to be so bad in practice that I've never seen the algorithm used in practice, outside of a classroom. And indeed, I first thought the point of the question was to elicit this complaint. The interviewer wasn't on that page, though.

The problem being asked was considerably more complex than "closest friend with property X". I don't recall the details, but perhaps it was something more like "find the ten shortest friend paths to (a unique but unknown) someone with property X, where those paths share no nodes".

My assumption for the Facebook graph would be that there is basically no way we can traverse it all, so your only hope is to find the path without expanding all the nodes. DFS will not work for that at all, but both BFS and IDFS may give you practical results.

This leaves the question of BFS vs IDFS, and that depends heavily on the details of the problem. For example, if the graph is already in RAM, then IDFS would be the best. But if the graph is not already in RAM, and you have to fetch it (from database or remote API), you'd definitely want the caching between successful IDFS rounds. And if you do that, then you might as well do BFS -- approximately the same memory performance, and much easier code.

As for usage, while BFS itself is not used this much, it's more advanced versions, Dijkstra and A*, are used all the time in graph traversals. For example, in many computer games, navigation apps and robotics planners.

(And back to original topic: if we had conversation like this during the interview, then you would likely get good score from me, even if I was fully convinced that BFS is the only way to go. After all, I am not testing for the specific bot of trivia -- I am testing for the ability to reason about algorithms)

Maybe, but for "find the closest friend with property X" basic DFS is completely useless. It's likely to give you some distant rando with property X. Fast, sure, but not useful if you're looking for a friend.

Besides, if you have cycles in your graph, DFS also needs to keep track of which nodes you've already visited, or it's never going to end. Or use iterative deepening, which you probably want to use anyway to prevent ending up with some distant rando. Slower than BFS but consumes less memory.

> "find the ten shortest friend paths to (a unique but unknown) someone with property X, where those paths share no nodes".

Ah, but that's a completely different problem.

Still, intuitively I'd expect that it depends a lot on the shape of your search space, the cost of your memory and the cost of traversing your network, which one is actually more efficient.

As you point out, IDFS (or IDA*, etc) work far better if you have a means to avoid re-exploring the same nodes repeatedly.

Nonetheless, run-time can theoretically be greater, since you're iterating. Theoretically, though, each iteration will take N times longer than the prior, which means that the running time up to the final iteration doesn't matter that much (because it's such a small fraction of the total). The extra bookkeeping required by BFS can easily outmatch that in running time.

Definitely, it all depends.

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.

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.

Then the person could not really pull their share. They did a few simple PRs, it all looks good. You gave them the more complex task, and they just could not make it to work. After teaching them basic CS concepts for a while, you give up, and try to move them to backend -- and they do not do better there. Then to do data analysis -- no luck. You really do not want to fire them, but this seems the only way forward.

The resulting experience is painful and time-consuming for the team. You wasted many weeks trying to teach that person and nothing good came out of it. You promise that in the future, your interviews would always contain technical questions, and no one who does not know about big-O complexity would be hired.

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.