I think to be frank, this gamification of interviews is BS.
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.
I get what you are saying, but I have done tech recruiting for a long time and the reality is that everyone claims they have built complex production systems at scale. Everyone has lofty resumes with the choicest buzzwords. Everyone can come up with war stories about how they single-handedly kept the internet alive. And everyone can write the names of a dozen references who can vouch for all of this.
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.
> I get what you are saying, but I have done tech recruiting for a long time and the reality is that everyone claims they have built complex production systems at scale
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.
> Then we need a better test, but the gamification and badgering isn’t effective imo.
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.
Cool then go design a better process that picks out the best engineers on the planet without asking them any engineering questions. Clearly you are smarter and have accomplished more than anyone at any company you have interviewed with, so it should be a cakewalk for you. Heck you can make billions by finally cracking the tech interview problem.
To be honest, you seem like the one with an issue. You're rejecting the general norm which is at this point painful, and everyone agrees, but it's the best thing we have. Your excuse to rejecting it is your own ego shooting outwards -- "99% of people haven't done what i have." That's cool and all, and I'm sure you're a very smart person, but just by the fact that you wrote this, I can tell you might be very painful to work with and would already be a huge red flag. Kill your ego and your experience in the world will be much better
Frankly, you don’t anything about what it’s like to work with me.
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.
You're asking the wrong question. You want the people with stories about how they broke the internet and remained on the same team or even advanced.
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.
I like to work with companies that make a lot of profit on their 5 digit customers where Single machine is enough. But we can make it 3 behind an LB. I absolute hate business whose infra is a bunch of message broker, lambda, queue .. yet make little money.
Addendum (since quite many upvotes): for the latter, they break a team of 8 (this is already a small team apart from the whole org) into 2 teams each 4 and break a monolith app into 2 microservices. At the time I saw that, the company started to have more and more managers. Guess what, not even making a break-even yet!
I guess I'm not sure if you're suggesting otherwise, but gamification is not unique to interviews. It's a natural response to any system that relies on metrics or measurements. The request to design a theoretical system is gamification as much the guide for answering it is. These games exist because it elicits answers that can be used to learn about someone's real experience level.
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.
Yeah, I don't think I want a job that asks such questions. I've done the webscale BS. I've done actual architecture that exists in reality. At this stage in my career there's nothing an interviewer can do but insult me.
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.
Companies already look at resumes, and the interview is a good way to double check things in a pass/fail manner. It's not like the SAT where you take a single test that sorta determines where you go, but even that is useful as a broad measure. Like if I'm in a top school's admissions and see 1800/2400 (idk the new scoring), there'd better be an explanation. If Amazon saw my resume and I couldn't explain to them generally how I'd architect the backend for their lockers, something would be wrong. And sometimes something is wrong; I interview someone who clearly doesn't know how to code and must've lied on the resume. I don't know how else you're supposed to do it.
At the higher levels, they're also testing for humility.
These interviews are not gutchecks. They are shibboleth checks.
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.
> 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.
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.
> There's a good chance at my career phase I have more experience than the interviewer.
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).
How can someone less experienced that you gauge your competency for a position that requires more experience than they have?
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.
If my house had a pest problem, I would need to hire an expert in pest-control. I need to do that without being an expert myself. How should anyone be able to hire someone with more experience than themselves, in your view? I've sometimes had to 'hire my own boss'.
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.
> If my house had a pest problem, I would need to hire an expert in pest-control.
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.
why not design it ? Anyone can say to throw in a time series db but what about it's internals ? How do people judge if you can build or add a feature without asking you to design something ?
If you can't be in a room with a more junior engineer and explain your ideas in simple language by drawing a few boxes on a whiteboard, then yeah you are probably not a good fit for these positions.
If you want to explain what a timeseries db is to someone who has no clue in a 45 minute (already time constrained) systems design interview (where you’re supposed to be actually showing how you would design a system), be my guest.
The issue could be time management and every database has same set of features but different implementations.
One of my teammate keeps talking and sometimes loses the context. We usually step and get on track. He has improved a lot in past few months. You might be in similar boat.
I know how to give concise descriptions of complex problems. The issue was that the interviewer didn’t understand the proposed tool.
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)
You are supposed to structure it. I know their internals on a high level but I work with internals of a oss engine. I know how their read / write paths vary, data structures for storage, for locking, for request scheduling, checkpointing algorithms, scheduler, etc.
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.
Well said. I’m nearing 30 years industrial experience. The last interview I had was 6 engineers and the HR chick all in the room grilling me. Next time I’ll get up and leave.
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.