[y-c-o-m-b]

This feels condescending.

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.

[cynicalkane]

A breadth-first search is a pretty basic algorithm, but even if you don't have it "memorized", the question is simply: here's a data structure, we need to traverse it in a certain order. Traversing data structures is so common that, even without a formal CS education, 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.

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?

[0xFACEFEED]

> Solving a problem with simple constraints is something that happens all the time.

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.

[throwawaymath]

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

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.

[0xFACEFEED]

> They described someone who learned to play the guitar without any background in music theory.

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.

[agentwiggles]

I would guess that the _vast_ majority of guitarists learn that "G D Em C" sounds good _long_ before they understand that it's an I V vi IV progression. I started off playing guitar with three open string power chords, and I didn't have any understanding of theory for years of playing.

[throwawaymath]

No one is talking about composing music without a classical background. We're talking about playing music without the background.

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

[shkkmo]

> The fallacy is expecting everyone else to have memorized the same thing you have memorized.

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.

[0xFACEFEED]

> I don't see why any memorization should be necessary. I have never written a BFS algorithim.

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.

[theamk]

> So let's say someone doesn't have any experience traversing trees (why would they? you rarely have to, if ever). [...] You're presenting them with a new problem and expecting them to come up with the most efficient/concise solution to that problem.

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.

[shkkmo]

> So let's say someone doesn't have any experience traversing trees (why would they? you rarely have to, if ever).

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.

[jenscow]

I think the point was, the algorithm is so basic that a moderately experienced software engineer could invent it - it doesn't need to be researched.

> as opposed to fixing bugs

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

It's a real problem.

[0xFACEFEED]

> I think the point was, the algorithm is so basic that a moderately experienced software engineer could invent it - it doesn't need to be researched.

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.

[calcifer]

> Google for "tree traversal" and spend 10 minutes researching common algorithms.

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.

[0xFACEFEED]

You're implying that someone who can't invent a BFS on the spot also doesn't know what tree traversal is. That's not true at all.

[calcifer]

If you can program [1], you can do BFS - no need to "invent" anything. Given a tree like this [2], asking you to "print the numbers in order" is not a difficult question, it's a trivial one.

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

[tptacek]

What drives me a little nuts is all the people on this thread saying BFS is simple, as simple as counting, as if that somehow strengthened their argument. It does the opposite: BFS is indeed simple, so simple that you can simply explain it to a candidate and ask them to implement it, just like you would do with an actual developer (or, more likely, that they'd just do for themselves based solely on the Wikipedia page).

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.

[0xFACEFEED]

THANK YOU. 16 years I've been writing code and I can count on one hand the people I've met who realize this. I get a little emotional about it because I've seen so many exceptional programmers crumble in interviews with trivia questions.

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.

[theamk]

I do, every time! I even drew a little diagram a couple of times and traced the path!

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)

[Twirrim]

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

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

[theamk]

Well, if at least one person reads the discussion, and then starts inventing the algorithms instead of giving up right away, I'd be happy :)

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.

[Jach]

> the question is simply: here's a data structure, we need to traverse it in a certain order

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

[emmanueloga_]

This problem can be solved with my favorite algorithm in the whole world, union-find [1], yaaay! :-p

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

[Jach]

Neat structure! I consulted my copy of Skiena's Algorithm Design Manual. He says: "Union-find is a fast, simple data structure that every programmer should know about." Well... Now I do. :) It is simple, a 'backwards' tree with pointers from a node to its parent, which lets you union two separate trees together by just taking the shorter one's root and pointing it at the taller one's (or vice versa, but this way preserves log behavior). The path compression optimization seems to just be an extra pass in find(), after you have the result, to re-parent each item along the path to the found root parent so that any future finds() of any of those items will only have one lookup to reach the component root.

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

[zeroname]

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

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.

[TheOtherHobbes]

Depends on the algorithms. Some people can brute force something basic, and the brute force answer will usually be slow and stupid at scale.

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?

[zeroname]

> Would this pass your interview process or not?

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.

[antoinevg]

You're asking the wrong question.

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.

[theamk]

But this question does not really tell me anything. It only has one possible answer, which is "Yes!"

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.

[jenscow]

That's just the type of answer I look for.

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

[antoinevg]

The problem is that here you are optimising your test for https://en.wikipedia.org/wiki/Chutzpah.

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.

[jenscow]

Yes, I'm starting to realise that finding a candidate who's able to problem-solve something basic really is "luck of the draw".

[antoinevg]

I feel like you misunderstand me entirely.

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.

[skookumchuck]

> I have no fucking clue how to write a BFS. I've never needed to know how to write a BFS. [...] If there's something I need to know and don't, I simply research it.

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

[microtherion]

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

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

[zanny]

At least in my case I'd like to think I absorbed the habit of recognizing sub-optimal traversals of data (for example, yesterday I was writing a parallel iterator and made the intentional choice to "waste" effort duplicating the map result than having to synchronize threads on mutable boundaries) but I don't remember all the buzz word jenga that was in my data structures class in uni.

[skookumchuck]

I've often been able to dramatically improve other peoples' code by selecting the right data structure (array, list, tree, hash, whatever) where the original programmer clearly did not know about them. They were able to make the code work, but not very well.

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

[arvinsim]

> I have no fucking clue how to write a BFS. I've never needed to know how to write a BFS. [...] If there's something I need to know and don't, I simply research it.

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

[skookumchuck]

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

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.

[devxpy]

You think every programmer has a CS degree?

[chooseaname]

Begs the question, if they don't, shouldn't they still get familiar with CS? Honestly, how hard is it to read Grokking Algorithms?

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.

[skookumchuck]

I don't have a CS degree. But I know the freshman algorithms. It's the basic tools of the trade.

[shkkmo]

I don't. The ability to figure out how to write BFS still seem pretty basic to me.

[castis]

The theoretical interview was never about writing a BFS. Its about how you approach answering the question.

[eagsalazar2]

The fallacy here is that you are actually getting to observe people's problem solving approach when asking them questions like this (vs their ability to talk) and that your subjective perception of someone's problem solving ability in those situations maps to actual job performance at all (vs your own biases).

[castis]

The entire point is that I _am_ gauging their ability to talk with me through something they may or may not be uncomfortable with. This has worked well in the past and most people deal with this favorably.

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.

[throwawaymath]

Is that a fallacy with basic algorithm questions, or with interviewing in general? How does another category of question provide objective feedback about problem solving ability instead?

[ModernMech]

I hear this a lot, but I've been in interviews were, yes, it really is about writing the BFS (or whatever algorithm they were asking for). I can remember one, where I was asked to write write an algorithm that, given a vector of points, calculates the euclidean distance between every pair of points. I wrote out a one-liner in MATLAB that accomplished the task in about 2 minutes, but then they wanted to see it in C++. Then I wrote it out in C++, which I don't know so well, so it ended up being in pseudo-C++. Then we spent the remainder of the time quibbling about syntax errors and missing import statements. It was very clear to me the interviewer only wanted to see perfect, compiling C++ on the white board, and had no interest in my problem solving or thought process.

[mk89]

> It was very clear to me the interviewer only wanted to see perfect, compiling C++ on the white board, and had no interest in my problem solving or thought process.

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.

[ModernMech]

FWIW, this example was for a company that refused to tell me what the job description was and what the position was. They didn't tell me ahead of time which languages they preferred or what kind of work I would be doing. It's a company everyone knows and is renowned for their secrecy. While they refused to tell me what they were looking for, it became clear during the interview they were looking for something very specific.

[throwawaymath]

I'm fairly certain I know which company you're talking about - I'd recommend you redact the specific question they asked, because I'm aware that they do check online (including HN) for interview questions that were asked. You have plausible deniability as long as you don't name the company, but given the NDA they throw at you it's probably better to be safe than sorry :)

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

[jenscow]

Well, at least you knew upfront there was a high chance of it being a waste of time.

[Twirrim]

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

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.

[mk89]

Let's say you have 2 people in front of you and they both design the same algorithm and come up with the same solution (sometimes that's really the case).

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

[y-c-o-m-b]

No I got that point. You missed my point; it's completely unnecessary when there's a more productive way to observe someone approach a problem.

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

[mentat]

Not cool that he made it less inflammatory? I think you're missing the goal of HN here.

[Rooster61]

Disagree. Editing a post like that without leaving a message about why it's edited appears disingenuous.

[organsnyder]

It does make the reply look more brash, though. Good that [s]he made it less inflammatory, but it would have been courteous to add "edit: made the tone a bit nicer" or something.

[y-c-o-m-b]

That all depends on the intention. If the intention is to make my response look more hostile, than I would say it goes against the conduct of HN. They could have replied or added a remark in the edit. The poster could have said "editing, sorry for getting too heated" or something if the intention was to deescalate, but this was a ninja edit.

[castis]

The edit button exists for a reason. Your regard for what is and is not cool is of little consequence. No one owes you an explanation.

[antoinevg]

And no one owes you a white boarded BFS implementation which bears no resemblance to how they would approach a problem in the real world.

[castis]

Let us all be grateful that you were never asked for one then.

[antoinevg]

Oh I know you weren't asking, I was merely responding to the incongruence apparent in your own expectations of the world.

[zanny]

If your first contact with a potential hire is asking them asinine pointless riddles meant to try to imbalance them you are going into the process with an adversarial relationship.

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.

[watwut]

I never understoood this. What does that even means and what is good and what is bad way to approach the question?

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

[3minus1]

I'd like to say that I appreciate this comment even though I disagree. It's true that you can be a perfectly good or even above average developer without ever using BFS, and interviewers shouldn't pretend this is not so. It's also true that software development is a problem solving job. You are paid for your ability to think for yourself and solve a problem. BFS is artificial but also a nice self-contained exercise that any developer worth his salt should be able to figure out.