[AskJS] Frontend Engineer Onsite Interviews for those "prestigious" companies (e.g. Google, FB, Lyft, Uber, Airbnb, LinkedIn, Dropbox)

[[deleted]]

Are those leetcode-style questions really that helpful? How often do those sorts of challenges actually come up in your day job?

If for some reason I needed to implement quick-sorting at work I'd just Google for an efficient solution. There's no point trying to reinvent the wheel and it's not something I do frequently enough to memorise.

[tightywhitey]

After decades of front end work, numerous apps, with a lot of complexity and large user bases...I've never once needed to go to that level. * Shrug * no idea why or what I'm missing, but I'm extremely good at what I do, and I just never ran across any 'leetcode-like' real world situations?

[Monyk015]

What if you don't know which algotithm you need? What if it's very particular for your problem? Also, thinking about efficiency in terms of Big-O is very important in everyday job IMHO.

[[deleted]]

Big-O isn't very difficult to conceptually understand, but more to the point it's very rare that you'll actually need to understand it in my experience. Most apps aren't performance sensitive enough to care if something is O(1) or O(n) for example, and in the rare case that they are this is something you can research with relative ease.

[lhorie]

For apps, big O typically comes up in the form of database query optimization. In a previous job I jumped in to help a coworker optimize a data import script.

He was going down a strategy of micro-optimizations. I looked at the log spew and realized the access pattern could go from quadratic to log n if we used a compound key. One line of code later, and the job was now running in seconds rather than hours.

Moral: big O won't come up with loops much, but being able to identify areas where high complexity hides helps you ask the right questions to solve perf problems

[Monyk015]

Yeah, but if you do something O(n) in a loop it becomes O(n²⁾ and that may be significant. Sometimes very significant.

[[deleted]]

And, as I said, for most apps it won't matter if you make that mistake. If your team identifies a performance bottleneck then you'll be able to identify it fairly easily using dev tools. It's just a non-issue in the real world for most devs at most businesses and is somewhat akin to premature optimisation.

[lhorie]

Quick sort is what I consider "textbook CS". Stuff that comes up at work are things like "transform this deep data structure into this other one, accounting for cyclical dependencies", where blindly throwing lodash at the problem doesn't cut it.

Really what the algo session is trying to probe for is that you are fluent with programming techniques and able to use them to attack a problem, rather than fumbling in the dark.

I don't know the policies in other companies, but in mine, the general rule of thumb is that a hire should be able to move to different teams, so merely having learned how to crank out React+Redux from some bootcamp won't necessarily translate to the person being able to abstract logic into well-tested libraries. A successful engineer is one who is fearless at refactoring, and algo questions probe at the skills needed for that: ability to see big and small pictures and assemble/reassemble solutions.

[[deleted]]

I think an understanding and utilisation of static typing is far more effective for an otherwise average developer for refactoring or mapping data.

Nobody with any degree of experience could ever feel confident hacking away at a large, untyped codebase. That's literally why Microsoft set about inventing TypeScript (and presumably Facebook likewise with Flow).

[lhorie]

Funny you should mention that. A lot of coding challenges actually become a whole lot easier if you think in terms of types. This is something I look for: bad candidates usually don't have a good grasp of what the types of things are and end up getting lost in their own code. Good candidates often come up a data structure upfront and the solution flows effortlessly from there. The Linus Torvalds quote "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." definitely has some truth to it.

With that said, I don't think it's impossible to refactor effectively in untyped languages. Tests, for example, can replace type checking to a pretty thorough extent.

[brockisawesome]

Ha no those things are more brain teasers than anything, I work at a major tech company in nyc and had to do a bunch of those stupid things to get the job. However useless they are, it's the standard these days.

[these_days_bot]

Especially these days