3 ms·

As a hiring manager whose teams are mostly building CRUD applications, I ignore them entirely. Algorithms skills have little bearing on whether someone can arch

As a hiring manager whose teams are mostly building CRUD applications, I ignore them entirely. Algorithms skills have little bearing on whether someone can architect maintainable and scalable apps, and people who are excited by those sorts of challenges will probably be bored and frustrated doing this work.

inertiatic 8y ago
>Algorithms skills have little bearing on whether someone can architect maintainable and scalable apps While I believe that interviews based around testing these skills in isolation are not ideal, I think it is a bit too naive to say that these skills aren't related. Especially scaling by it's nature requires knowing what approach is the best based on the employed algorithms themselves. Also anecdotally having worked with people focused on the skills you mentioned, it really is a drag having to walk them through even relatively easy pieces of code with some algorithm not offloaded to a library, time and time again, and always having to have some other person work on whatever problem involves more than glueing together some components based on "best practices" etc.
- cimmanom 8y ago
  We have yet to encounter scaling problems that are best solved with custom algorithms; and only once in the last three years have we had a bottleneck related to computational complexity in our own code. We encounter scaling problems in general probably once every six months; most are solved by proper application of existing open source tooling. Our codebase is chock full of business logic complexity, but very little of our code contains any meaningful custom algorithms. Maintaining that business logic complexity requires a specific mindset that's very different from solving or optimizing algorithmic puzzles. Good CRUD developers aren't necessarily idiots or code monkeys who only know how to glue together Stack Overflow answers. But selecting for people who enjoy / are good at solving HackerRank challenges would just get us unhappy and ill-suited engineers. We select instead for people who have strong software design and architecture skills and get a kick out of improving products and making end users' lives better. The result has been an effective, high-performing team with a high retention rate. So you do what works for you and we'll do what works for us.
- tmemfnskdj 8y ago
  > Especially scaling by it's nature requires knowing what approach is the best based on the employed algorithms themselves I have yet to design a system that requires more knowledge in algorithms than understanding architecture and CAP theorem. Scaling systems is based on a series of trade offs. There are very few scenarios that would require knowledge based on the underlying embedded algorithm unless your problem domain requires so.

inertiatic 8y ago

>Algorithms skills have little bearing on whether someone can architect maintainable and scalable apps While I believe that interviews based around testing these skills in isolation are not ideal, I think it is a bit too naive to say that these skills aren't related. Especially scaling by it's nature requires knowing what approach is the best based on the employed algorithms themselves. Also anecdotally having worked with people focused on the skills you mentioned, it really is a drag having to walk them through even relatively easy pieces of code with some algorithm not offloaded to a library, time and time again, and always having to have some other person work on whatever problem involves more than glueing together some components based on "best practices" etc.

cimmanom 8y ago
We have yet to encounter scaling problems that are best solved with custom algorithms; and only once in the last three years have we had a bottleneck related to computational complexity in our own code. We encounter scaling problems in general probably once every six months; most are solved by proper application of existing open source tooling. Our codebase is chock full of business logic complexity, but very little of our code contains any meaningful custom algorithms. Maintaining that business logic complexity requires a specific mindset that's very different from solving or optimizing algorithmic puzzles. Good CRUD developers aren't necessarily idiots or code monkeys who only know how to glue together Stack Overflow answers. But selecting for people who enjoy / are good at solving HackerRank challenges would just get us unhappy and ill-suited engineers. We select instead for people who have strong software design and architecture skills and get a kick out of improving products and making end users' lives better. The result has been an effective, high-performing team with a high retention rate. So you do what works for you and we'll do what works for us.
tmemfnskdj 8y ago
> Especially scaling by it's nature requires knowing what approach is the best based on the employed algorithms themselves I have yet to design a system that requires more knowledge in algorithms than understanding architecture and CAP theorem. Scaling systems is based on a series of trade offs. There are very few scenarios that would require knowledge based on the underlying embedded algorithm unless your problem domain requires so.