|
|
|
|
|
|
by k_sze
1900 days ago
|
|
|
Yes, but you don’t need to know how to “reverse a b-tree” for that. You just need to be aware of something called algorithmic complexity and big-O notation. You don’t even need to know how to determine the big-O for all the known algorithms and data structures: they can be readily looked up in reference books. |
|
|
while there's a lot of other things I value in coworkers, and I want a diverse mix, I really trust a coworker much more who I know can reason through, can see how the code will execute, and understand what that implies, can find & state the significance.
there's a lot of here & now tests of ability in programming, to understand syntax, language, side effects, &c. but bring able to reason about runtimes, about this then that then that... it's the bigger picture. we have some pretty basic promise questions in our interviews, & it's so remarkable how many people get cut for now being able to understand sequencing, how a little async behavior trips so many up. not quite the classic algorithm test, but to me, they seem extremely similar in that they want the dev to be able to order & comprehend how things work.
I agree that a lot of pushback against algorithms is deserved. they are misused as a hiring bar frequently. but there is also things I value a lot, & they help elaborate whether a dev grasps coding situations or no.