| Well as you are the FAANG hiring manager I expect I am going to lose the argument but I wonder if my oranges are more like apples than you suspect. I see there being two options here apples: please take the existing set of distributed components that evolved in tandem at this company and design a new application on top of and using those components oranges: please start from scratch and explain how you would build a set of components that will work as well as those in 1. Apples is what we mostly look for - in any org we have a scale and ecosystem and we don't want to throw it all out. If it must evolve it evolves in tandem with rest of the ecosystem. So if we have some scalable data layer now that has chosen one side of CP/AP and then we come along and say actually throw that out We need full concistency all the time for this HR app, we are going to build our own different CP data layer globally, hold my beer, then ... The oranges part is fine - it tells us if someone has actually understood the principles behind apples. But honestly it's a fake out of we think oranges can actually be done. And this sort of stuff gives the impression you can design the application solution by also designing the ecosystem at the same time. That's the bit Inwant to emphasise - you build the platform then design the application on the quirks of what you built And anyone who has not used the apples components won't understand their quirks and can come unstuck when the well known but non obvious behaviour strikes. I am being too vague here. I feel there is an interesting set of discussions to come out of it - Inwill reread the article |