Where I work, architects are responsible for disambiguating requirements and breaking down the implementation across teams into achievable milestones. It’s the intersection of technical chops and social skills. One of those is a lot easier to develop than the other.
A good architect makes it seem like their job is easy, but there’s nothing easy about taking a vague idea and leading a huge cross-team effort to solve it.
>Where I work, architects are responsible for disambiguating requirements and breaking down the implementation across teams into achievable milestones. It’s the intersection of technical chops and social skills. One of those is a lot easier to develop than the other.
Good thing we're on the internet where we can talk about the actual reality and lay everything out as it is without worrying about the social and political bureaucracy that infests corporate culture.
That being said, isn't what you described the role of the tech lead or manager? The best tech lead ultimately derives technical architecture by aggregating the expertise of the team and puts that plan into motion exactly as you said.
The term "architect" usually implies greater knowledge of "architecture" where the "architect" uses this "greater knowledge" to lay down a high level plan of the infrastructure. Additionally your initial post implied that this is what you think, because this is what you study for interviews.
Like I said, usually the architecture role is actually ends up in practice becoming an ex-engineer manager. That's the only actual role they can fit while maintaining the respect of the engineers and without being completely useless. This is basically what you described about yourself.
Additionally your initial post implied that this is what you think, because this is what you study for interviews.
Thousands of people study about how to reverse a binary tree on a whiteboard and other needless leetCode to “work at a FAANG” even though they don’t do that everyday.
What you study for an interview is unfortunately often only vaguely correlated with what you do on a job.
>What you study for an interview is unfortunately often only vaguely correlated with what you do on a job.
Agreed 100%. Interviewing is hard. I would argue though that interviewing for "architecture" causes another issue. To give an analogy... it's like studying english for a programming job because english is used all the time on the job.
Architecture is just too easy and too obvious and if you just happen to not know a specific architecture or way of speeding something up, all you have to do is read about it on the internet like looking up vocabulary on a dictionary.
I would also argue that google isn't exactly just testing algorithmic skills in an interview. The spiritual goal of the interview is that the question they give you is novel and one you haven't seen before. The overall purpose of novel questions is to measure your raw intelligence.
The question isn't whether or not you know how to reverse a binary tree but whether or not from a state of not knowing how to do it, can you creatively come up with a way to do it in an hour? Raw IQ.
Of course the practice doesn't always match up with the ideal and often times interviewees can get lucky.
I'm not saying that this is the best way to interview. I'm saying that judging an interview based off of architecture is even worse. It's even easier and there's a lot of room for bullshit in a conversational interview as opposed to a technical question.
Pro tip: this applies to you to buddy, you don't even know my background so you don't even know which field I have a PhD in or how much older I am than you.
A good architect makes it seem like their job is easy, but there’s nothing easy about taking a vague idea and leading a huge cross-team effort to solve it.