A typical algorithm (LeetCode style) interview question is in some ways the exact opposite of real world software engineering work.
| Interview Question | Real World |
| Short. Short enough to complete in an interview. | Long. Some problems are open ended and can require indefinite amounts of work over many years. |
| Well-Defined. There can be multiple valid answers but you can usually determine correctness and optimal complexity. | Fuzzily-Defined. There isn’t a right answer. Goalposts can change. Priorities can change. Basic assumptions can be challenged. |
| Start with a clean-state. | Done in the context of an existing (possibly very complex) code base. |
| Worked on by a single individual | Worked on by a team. Organizational politics are possible too. |
I’m not saying that this is bad or that we have to radically change interviews or anything like that (haven’t really thought about it). I think it’s just worth noting that the stuff on the right is very important.
I would define execution as the skill to deal with the complexity of your software engineering context (basically the above 4 things) and still deliver the best possible software you can. This is important.
Comments
Post a Comment