I’ve built actual production systems at scale. The fact that I need to follow a guide to “demonstrate” my ability to someone who 9/10 hasn’t built (or couldn’t build) anything at scale in production shows where we are in the absurdity matrix.
The moment you start to test these claims, 90% of these candidates cannot write a line of code or describe a simple distributed system by drawing a few boxes on a whiteboard. So the current process is what we end up with.
And once in a while some genius superstar 10x programmer comes along who is too good for these silly interviews... well that's fine we don't need that arrogance either.
Then we need a better test, but the gamification and badgering isn’t effective imo.
> And once in a while some genius superstar 10x programmer comes along who is too good for these silly interviews... well that's fine we don't need that arrogance either.
It’s not arrogance to not want to be judged by someone who literally hasn’t done and probably could never do what you’ve accomplished.
The unspoken secret is that most software engineers in the industry (even at FAANGS) can really only add features to existing systems. They can’t build green field.
Maybe I’m not the one with an issue after all.
But to answer more genuinely, it’s a fact that most developers have never and will never work at web scale. Also, if you have ever worked at a FAANG, you would know that a majority of the topics that are involved in these hazing loops aren’t directly used in the dad work of most developers.
Rather than focusing on me, focus on the point I was making about the deficiencies in the hiring loops of tech companies.
It’s not ego it’s the reality of working in tech.
The educational field has been trying to do create tests that cannot be gamed for over a century. The problem is that "gamification" is just a form a studying. In general, folks want tests to have the following properties.
1. Consistency of measurement across test-takers for a defined set of skills
2. Relatively short time-bounds (few hours).
In job hiring, the approach that tries to sacrifice (2) is contract-to-hire, just let the person do the work for a month! Turns out that people with in-demand skills aren't super interested in this.
Companies with more than a handful of engineers don't want to sacrifice (1) both out of fear of lowering the hiring bar too and because it may open them to discrimination lawsuits.
Once you have both of these constraints the number of "test permutations" (along with their relevant evaluative criteria) become limited enough that people can study them and thus gamification begins.
Those are often the people with enough skill that they were put in a position that they could break it in the first place, and who provided enough value that even afterwards they were still allowed the opportunity to do it again.
Like the airplane bullet hole story.
It's great that you feel confident relying on your real world application but it takes a long time to get repetition on building things at scale in production. Practicing system design is a way to shorten that learning loop.
It’s like trusting a doctor fresh out of medical school without residency.
You probably don't need to follow a guide if you're as good as you say, though.
You might say that this is hubris about my own skill but it has nothing to do with how good I am. My resume has a LOOONG track record of consistent work in the industry. Call my references, do some actual DD on me, then ask me real questions related to actual things.
If leetcode and all these other service went straight to hell tomorrow the world would be a better place. This entire "interview" industry is propped up by a bunch of leeches capitalizing on a recently extremely popular field. Then, injecting their BS to make the process harder thereby earning them dollars. The linked article is a perfect example. It's actually an advertisement if you look close enough designed by these exact leeches. This is just a reimagining of the bloodsuckers who run SAT/GRE/GMAT prep services and "ex-ivy-league recruiter consultant" bullshit. They are the same people and the only place they belong is all the way at the back of the breadline. That may be too generous for them anyway. There are better people that deserve the bread.
There's a good chance at my career phase I have more experience than the interviewer. They "level the playing field" by asking me these stupid things. That is why it is insulting. I almost want to leave the industry entirely than have to do the process one more time. I don't need a 7 phase 360 interview with everyone including the CEO's cousin to insure I am a "culture fit". It was never like this before. It needs to stop.
At the higher levels, they're also testing for humility.
I can design you a nice document, do the research, put the pieces together, etc with the big picture. I may not know a ton about AWS or another cloud provider but I can put the document together that describes how it will be looking when it's done. That is architecture. Somewhere between UML and word documents.
What these interviews are checking, and the one you are describing, is whether or not I can parrot the correct code-words. Lambda, elastic cache, all this other nonsense. That's the purpose of the bloodsuckers I mentioned above. If you can train someone with little architecture experience to pass a senior level interview by just saying the right things and knowing the right hype tech then you're not hiring architects you're hiring grifters.
It's a problem that is endemic in this industry. You can't "gut check" 30 years of architectural experience unless you're legitimately asking the core questions of architecture. Every interview I've been in has had me studying stupid buzzwords from cloud technology and every interview I am asked how to use these technologies. As an example, I was once turned down because I didn't use Kafka. I knew what the underlying technology was and suggested using it but the fact I didn't say kafka eliminated me. The reason? I can only guess, but it's likely because the interviewer doesnt know much and was looking for a way to get into a debate over kafka vs protobuf vs whatever instead of discussing actual planning of a system. These debates are resolved after I take the problem back to my desk and think about it for a week. Not in an hour. In an hour the best I can give you is a block diagram with maybe some very rough fleshed out detail.
The humility check should be bi-directional. It has been my experience that interviewers tend to be the least humble people at a company. The power dynamic is obvious and it's not in the character at most startups where a "senior" engineer high on hopium can settle themselves into their rightful place.
> What these interviews are checking, and the one you are describing, is whether or not I can parrot the correct code-words. Lambda, elastic cache, all this other nonsense.
Maybe we've just had very different architecture interviews. All the ones I've given or received were the way you'd want. I've never specified a cloud product in these. At most might say "let's use something like Postgres." Amazon for instance didn't care that I couldn't name any of their products.
Kafka example sounds awful. I'm sorry, but on the other hand, sounds like you dodged a bullet.
This happens a lot.
I was once in the process for google and was asked a time series systems design problem. I said, “lets throw this in a time series db”. The interviewer had no idea what a time series’s db was. Mind you this was an interview for Google Cloud and the person worked on SPANNER. They also has been at the company for 2 years (by their own admission).
Left a sour taste.
That’s before wondering why they’re asking a question to gauge my competency when they don’t even understand the nuance of the question themselves.
An interviewer working on google’s enterprise nosql db but not knowing about (at least on a surface level) the breadth of nosql dbs doesn’t seem crazy to you?
The tech interview circuit has really become a bunch of people asking questions that they couldn’t really answer themselves without a rubric in front of them (whether leetcode or system design).
To be crude, it’s a bunch of nerds hazing for jobs.
> How can someone less experienced that you
This argument seems to conflate two different things, how long someone has been at a particular company and their (overall) level of experience.
Maybe the criteria for the problem was less "did they check these boxes" and more "could they be a collaborative mentor willing to work with even the junior members on the team" in the context of designing a system.
The result from the expert is that you as the layman can look around and see no pests (which anyone with their naked eye can do)… you’re not judging them on their knowledge of pesticides.
> Maybe the criteria for the problem was less "did they check these boxes" and more "could they be a collaborative mentor willing to work with even the junior members on the team" in the context of designing a system.
This is a fantastical maybe. The interview was system design.
Every db definitely does not have the same set of features. The read and write characteristics of dbs vary widely, the underlying storage and indexes vary as well.
There’s a huge difference in usecases between postgres (relational), redis (in memory cache), and influxdb (timeseriese)
The point is you've to structure your knowledge in a way the other person can understand. There is no value for any company, if you can't share whatever knowledge / experience you've in a structured format.
Not everyone is familiar with internals of commonly used tools but the underlying patterns or concepts remain the same.
If you can't explain that, then you are lacking in communication skill or maybe no one ever gave you feedback. It's just a matter of time.