In a lot of the interviews for "Front end" and "Full stack" positions, developers are being grilled in algorithms rather than the actual tech stack that they work on (and are experienced in).
Do you think this is the correct way forward too? Please share your thoughts
Top comments (5)
I'm not sure anyone should be interviewed about algorithms. Asking someone how they'd build something and what types of changes they might make given certain constraints should be sufficient.
Coding algorithms is a skill based in part on wrote memorization. In reality, depending on the language, many libraries have functions that are a better choice than rolling your own. Why are we interviewing people for things they won't use on the job?
This. The best job interviews I've had have involved a take home "mini project" which basically tested how I would approach building a simple app. Use of any technology was allowed (though sometimes some were hinted as preferred) and any questions could be asked. I think this simulated a real project much more accurately than being thrown random questions on the specifics of certain languages. With the plethora of tech, patterns, languages, algorithms we're exposed to every day it's impossible to know everything which is why we all greatly rely on the Internet to assist us with our daily tasks. Why not expose that in a job interview?
I think it really depends on the job and the problems the company is trying to solve.
I'd bet 90% of companies are doing nothing truly new. Most companies are competitors in established markets or bringing technology that already exists to new markets. Of that 90%, you have a bunch of companies that are not true to themselves about what they are building and feel the need to prove they are doing something new and different which leads to questions about algorithms and data structures. In reality, on your first day you are doing the usual development tasks and so are they but they won't admit it.
Then you have that last 10% that are truly doing something new. And 10% might be a generous there. For example, Google created a search engine from scratch. A search engine back then wasn't even new! But, they came up with a new algorithm that was new and better. In that small percentage, I think it makes sense to hire someone who has a deep understanding of various algorithms and data structures because it takes that knowledge to build a new algorithm from scratch to do such a thing.
That's kind of how I view it in my head anyways. π€·π»ββοΈ
It's a difficult and vast topic. It's intertwined with old practices, assumptions on methods to filter candidates, the need to have generalists as employees, the growing number of candidates, the notion of 10x or ninja devs, the emulation of hiring practices that big tech companies have and probably also laziness (standardized testing is a way to care less about nuances).
So, should they? It really depends on the job I think.
If the offer is to write the core engine of visual studio code (random example), built with what the industry would consider frontend technologies, a familiarity with algorithms and data structures it's probably required. It's also probably not the right example because it's a desktop app built with web tech eheh.
What I mean is there are specialized frontend apps that require familiarity with algos and data structures.
It would make less sense if the offer was about redoing the UI of a legacy app to handle company's orders.
Frontend is hard, backend is hard, algorithms are a skill that can make sense on both ends.
You could argue algorithms are not a required skill for a backend dev if they are hired for a job that doesn't require them.
I don't know if we can say confidently "always no" or "always yes".
There's also the fact that people can pick up skills AFTER. It's a job where you're always learning anyway.
Here is what it is in mot of such scenarios:
Rinse and repeat.
Also in such interviews the 'techie' is almost always a 'he'.