2 ms·

My feeling is that people who understand maintainability or other architectural concerns are worth more than people who master algorithmic underpinnings. I tho

My feeling is that people who understand maintainability or other architectural concerns are worth more than people who master algorithmic underpinnings. I thought the point of this discussion was how to change the industry emphasis rather than how to get good at it.

myth_drannon 4y ago
How can you test someone who can write a well maintained code? Architectural Concerns are tested during System Design round.
- mattlondon 4y ago
  Candidates who care about readable solutions, provide comments, add unit tests, think about integration testing, data validation, bootstrapping/deployment etc are the ones who are at least thinking about maintenance. Incomprehensible one-liner whizz-bang solutions in perl are great and all, but no one wants to work with someone writing code like that.
billllll 4y ago
How do you understand maintainability and architectural concerns without understanding algorithmic underpinnings? At the base level, leetcode problems and maintaining a complex system in practice requires key understandings: what your problem is, which tool to use, and how your tool works/tradeoffs. It follows what (I hope is) a universal truth: if you want to be a good coder, you need to know code. If you want to change the emphasis, just don't work at companies that provide leetcode questions. If your hypothesis is true, then all the companies that don't do leetcode questions should have an advantage since their engineers are better at the practical aspects.
- andybak 4y ago
  > How do you understand maintainability and architectural concerns without understanding algorithmic underpinnings? > At the base level, leetcode problems and maintaining a complex system in practice requires key understandings: what your problem is, which tool to use, and how your tool works/tradeoffs. It follows what (I hope is) a universal truth: if you want to be a good coder, you need to know code. I don't buy this at all. Orthogonal things are orthogonal. I work with developers who probably have no idea what a red–black tree is but I'd trust them to advise on how to structure a complex project based on user requirements. I'd rather they spent their time getting better at the latter and I don't see how getting good at puzzles is especially helpful in doing that. Programming in the large is usually about managing complexity over time. It has more akin to designing a large factory than it is to understanding how a pocket watch works. There's a huge human factor as well - complexity arises where people meet code and understanding how to keep that complexity in check is the key to being a good programmer.

myth_drannon 4y ago

How can you test someone who can write a well maintained code? Architectural Concerns are tested during System Design round.

mattlondon 4y ago
Candidates who care about readable solutions, provide comments, add unit tests, think about integration testing, data validation, bootstrapping/deployment etc are the ones who are at least thinking about maintenance. Incomprehensible one-liner whizz-bang solutions in perl are great and all, but no one wants to work with someone writing code like that.

billllll 4y ago

How do you understand maintainability and architectural concerns without understanding algorithmic underpinnings? At the base level, leetcode problems and maintaining a complex system in practice requires key understandings: what your problem is, which tool to use, and how your tool works/tradeoffs. It follows what (I hope is) a universal truth: if you want to be a good coder, you need to know code. If you want to change the emphasis, just don't work at companies that provide leetcode questions. If your hypothesis is true, then all the companies that don't do leetcode questions should have an advantage since their engineers are better at the practical aspects.

andybak 4y ago
> How do you understand maintainability and architectural concerns without understanding algorithmic underpinnings? > At the base level, leetcode problems and maintaining a complex system in practice requires key understandings: what your problem is, which tool to use, and how your tool works/tradeoffs. It follows what (I hope is) a universal truth: if you want to be a good coder, you need to know code. I don't buy this at all. Orthogonal things are orthogonal. I work with developers who probably have no idea what a red–black tree is but I'd trust them to advise on how to structure a complex project based on user requirements. I'd rather they spent their time getting better at the latter and I don't see how getting good at puzzles is especially helpful in doing that. Programming in the large is usually about managing complexity over time. It has more akin to designing a large factory than it is to understanding how a pocket watch works. There's a huge human factor as well - complexity arises where people meet code and understanding how to keep that complexity in check is the key to being a good programmer.