|
|
|
|
|
|
by rajaman0
971 days ago
|
|
|
You are comparing apples and oranges. These interviews are for engineers interviewing at companies which have scale ; not for a 0-1 growth of a product like your google example. When you're launching products at scale, you absolutely need to design large systems that are durable and can operate at said scale. And when I'm hiring, I need to filter for folks who are able to rationalize at that scale. |
|
|
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