Hacker News Reader

Maybe your idea of a front end developer differs from mine. I don't agree that front end developers need to code BFS. They just need to know that graphs can be searched, that should be it.

Frontend devs can do many tasks that systems engineers (who can supposedly whip out algorithms in their sleep) cannot do: - Make pages render properly in all popular browsers - Make responsive UIs - Align text of variable length in the vertical center of a page - Know when to use tables and when not to - Understand when to use a SPA app and what not to - Make SEO friendly pages

etc.

All this has nothing to do with said algos. I really think that people who don't understand this should not be interviewing frontend engineers.

I'm having a hard time responding to this. More and more, whole applications are being delivered in clientside Javascript using Angular or React or whatever. Are you suggesting that there are two "kinds" of front-end developers, the kind that knows how the DOM APIs work and the kind that can implement the rest of the application and domain logic in Javascript?

I am suggesting the frontend developers developing using angular/react code do not require to implement graph search algorithms.

What algorithms have you seen in practice in web frontends? I have seen nothing even minor, not even binary search or bublle sort.

I really don't know what to say to this. What kinds of applications do you work on? If what you do is primarily CRUD front-end stuff, then sure, I suppose you can get by without really understanding how to write general-purpose code. But pretty much anything past simple CRUD is going to start implicating simple data structures pretty quickly.

I can cite examples from the front-end I'm working on right now, but that wouldn't sound like a fair example (it's an AVR debugger). But all sophisticated applications are complicated in their own ways, and most of them require developers who can actually, you know, program.

Even if all you're doing is CRUD, how much computer science is embedded in even a straightforward framework like React? "Lots", is I think the answer.

I'm building an app with react which uses DFS to determine connected elements on a 2D grid: you'll have to be more specific when you say "frontend developers", since the frontend is getting more and more business logic.

I'd love for you to try to explain to me how it's relevant to my front end javascript to write a moving window algorithm in 45 minutes on a white board.

I have no problem with thinking engineers should be able to understand and implement algorithms. I have a real problem with thinking they need to know them off the top of their head.

Wouldn't a more reasonable approach be to give an algorithm and ask the person to implement it? If that's what they're actually going to do (since most of us aren't PhDs) day-to-day, and they may more likely find an appropriate algorithm on Wikipedia and implement it, isn't that more relevant?

Gladly!

Lets say your software as a service website has a real time analytics graph, so that customers can look at statistics of how much they are using the service in real time.

One potential question a customer might want to know is "How many API calls have I made over the last hour". This is a moving window average question, and it needs to be displayed/done on the front end.

My company that I work at has such a feature.

Algorithms questions come up all the time in javascript development.

Thank you for the example, but this is not a generalized problem, and is very specific to your domain, so it would be silly to receive such a question from companies that are not your company, which I have had happen.

If I were applying for your company, I would expect to have to implement an algorithm like this on the job, but I don't see why I should have to know it to get the job. As long as I was capable of implementing algorithms as described, wouldn't that be the most important factor?

How would you demonstrate that you're capable of implementing that algorithm? Isn't the best way to have them implement that algorithm? (I will admit that this is best done when the candidate has their favorite text editor and internet, and I have had an interview in the past where this was the case, which went well)

I would suggest that you provide the algorithm in process or through formulae, and have the candidate implement it. That's what they'll be doing anyway.

What kind of job do you have where someone tells you the algorithm? I can't imagine my PM saying "Let's count recent events by storing it in a hashmap and using a linked list to track which elements have expired, can you code that up?"

Instead, the PM might say "We need a system which can count how many unique events of each type has occurred in the last 100k requests, with small impact to time, high accuracy, and up to 100mb of space"

But even that would be unusually specific. It would usually be: "the service breaks sometimes, can you figure it out?" And then the engineers figure out that it's because of unusual event distributions, and they figure out what needs to be done, how much space / time they can afford to do it, etc. For instance, do you trade off accuracy by having a periodic job flush old events out of the map? Do you quantize by time to save space at the cost of resolution?

That's what I do at my job, and that's the kind of question I see in interviews. If a candidate is expecting to have the algorithms dictated to them, then I would not consider them to be a software engineer.. coding up a program from a specification would have been a technician's job 30 years ago (now largely automated by compilers, synthesizers (for HDLs), and other tools). The software engineer should be coming up with solutions, which often involve using algorithms and data structures.

And, again, I ask "are you under some kind of arbitrary time constraint when you have to create a novel problem solving approach?" Listen, most data theory problems have been solved, but for the ones that haven't, in work, we're asked to come up with a solution, but not in any weird arbitrarily short amount of time.

If your goal is to simply know how someone explores a problem, fine I guess. I don't agree with your approach but I can see your point. But if you expect a working implementation, that's unreasonable in my opinion and I believe you'll be rejecting many fine candidates using that method.

> arbitrary time constraint

Don't you have release deadlines, even if they're measured in weeks?

Depending on the complexity of the problem, I've been expected to produce code. That tends to be tricky and I don't always get it 100%, but I've not finished my code and gotten just the general direction, and still passed (received the offer).

> you'll be rejecting many fine candidates using that method.

I could see that being true. Without knowing what kind of company you work at I wouldn't know. Since I work in a big tech company who interviews in this fashion, all my coworkers who I'd consider fine candidates have passed this (partly arbitrary) bar.

It's not something I was good at, but I decided that I wanted to work at a big tech company, so I decided to play the interview game.

And how would the company know you were capable of implementing algorithms as described? Perhaps by asking you during the interview how you might go about implementing it?

Precisely!

We agree about the whiteboard thing. I'm only pushing back on the argument that these things aren't relevant to front-end.

> All this has nothing to do with said algos. I really think that people who don't understand this should not be interviewing frontend engineers.

React, Angular, Ember, etc, are all basically just giant tree diffing algorithms. The DOM is a tree. Understanding how to manipulate trees is important. Memorizing algorithms, less so, but it's absurd to suggest that front-end developers should get a pass on being able to code generalized solutions to problems.

More and more, "front end" is coming to mean "the whole application," and the difficulty is moving away from the gritty individual DOM manipulations and into writing structured algorithms to process large sets of application data and wrangle state, which you then throw into your deterministic renderer of choice.

It sounds like when you say "front end developer," you might really mean, "person who is comfortable with HTML and CSS." In that case, sure, that has nothing to do with algorithms, but that person is also not a software developer.

I recently bombed an interview with a graph theory question. I hadn't done any real from-scratch implementations of that stuff, but I do know enough to discuss it and pseudocode it.

They were disappointed, they wanted to see runnable code right there on the whiteboard.

I think you're right, you should know basic conceptual computer science. I felt like I did a good job of explaining that I understand enough to do a real implementation if I had to, with man pages and my IDE and so on. But nope, they wanted a piece of acrylic to be a compiler, and that's just wrong IMO.

I spent 2 years writing multicast routing algorithm implementations for an overlay multicast startup I cofounded. The moral equivalents of PIM sparse and OSPF. I wouldn't do it this way again, knowing what I know now, but we did LSA forwarding between nodes the same way a Cisco would flood LSAs over a set of unruly PPP DS1 links. The hard way, is what I'm trying to convey here.

Anyways, I interviewed a company my friend Nate was working for, on a lark (my company was sort of winding down).

First question I got: "explain Bellman-Ford routing". Bellman-Ford is one of the simplest distributed systems algorithms there is, and certainly the simplest foundation for a routing protocol (it's what the RIP protocol does). I had, prior to that interview, implemented RIP twice, in two different jobs.

I totally bombed the interview! My mind just went blank. I could explain how link-state routing with shortest path graph reductions worked, but not how a much simpler algorithm worked.

The interview made some clucking noises about how interesting it was to be interviewing someone who wasn't a Stanford CS student.

The next interview asked me to implement Towers of Hanoi non-recursively. I refused.

Obviously, I didn't get an offer.

> The next interview asked me to implement Towers of Hanoi non-recursively.

What? Obviously this isn't a great interview question, but this seems massively pointless. I don't think there is an obvious way of doing this that doesn't just turn the call stack into an explicit stack (which, again, is pointless). And the recursive code is the only code that could possibly be understood by someone whose whole world isn't dominated by understanding those ~12 lines.

EDIT: also, ya know. Who cares. I have not even heard of a software engineering legend where solving anything remotely similar to towers of hanoi was necessary.

To be honest I was a bit taken aback by the author not being able to implement a BFS. It's a fairly standard and really simple algorithm and it's probably one of the most common ones to actually implement because of a need in your day-to-day work.

What do you do if you have a nested data structure (like a tree) and want to print it in order? You write a simple BFS on it.

It's not even a question where you need prior knowledge on the algorithm, it's just logical. He could've easily asked "Print the contents of this tree to screen" and it would've been the same.

I can see how some questions like implementing quick or merge sort can be annoying, most libraries have a sort() function that usually implement either (or similar), you don't often have to write them yourself, but a BFS does not fall into that category in my opinion.

Hold on. I'm not taken aback by their inability to do BFS in an interview at a whiteboard from memory. That, I think, is a total bullshit question, which is why I think the right play there is to one-up them.

What I have a problem with is the assertion that a front-end dev shouldn't have to grok BFS. Not "be able to implement from memory", but "be able to quickly implement on demand given a few minutes research".

I would agree with you if the author had complained about depth-first search as opposed to breadth-first search. Any decent developer should be able to understand and reason through depth-first search but I wouldn't expect breadth-first search to show up doing front-end web development. In my own side-projects, which involve much more complicated algorithms than anything I've implemented in my day job, breadth-first search has only really come up in one context that wasn't explicitly AI related, and that was a grammar parser. In every other case that I needed to search something, it was depth-first search that I was using. If you're given the whole tree at the beginning, I think most developers would probably start with depth-first search, even if they didn't know the name of the algorithm they were using.

No. if you have a tree, you get an iterator on that tree, and print each element. Because your a pro, so of course your tree is based on a well-tested library component, one that provides a way to iterate it.

My degree should be proof that given some time to study I am capable of implementing it.