Its hard not to fall into this situation even if you work for startups or small companies. Say you arrive on day 1 on a greenfield project. You will soon be f

Its hard not to fall into this situation even if you work for startups or small companies. Say you arrive on day 1 on a greenfield project. You will soon be fitting in with other developers patterns and spending time digging into code thats not your own. Even if you are the lucky one putting low level frameworks and architecture into place, that eventually stabilises too snd you move on to more typical work at a higher level of abstraction. As time goes by, your knowledge of the code, product, domain, organisation, market etc continues to grow. In a matter of weeks, you then have outsized value to that particular organisation vs starting off as a generic code monkey somewhere else. This is not a trap or a dillemna, its just the nature of team based software development. To not acheive this in each of your roles would be a bigger cause for concern! I would say, if you are hiring someone to work on your big complex legacy system, you should probably attach some value to the fact that the candidate may have proven expert in exactly that scenario over the long haul in their previous role. Succeeding in that environment takes a certain skillset, and its disingenuous to reject people for not knowing certain low level programming constructs that they wont even be using day to day. (Kernel work is one exception to this.)