When I get a system design question I always tell the interviewer "I'd just run it on a single server with an SQLite backend, that will be plenty for the median software service and you haven't told me any numbers that suggests this needs more" and then it turns out they wanted it to run at the scale of WhatsApp.
"So what scale are we talking about? A few million monthly users? So like hackernews? I would use a single server... "
You really need two in physically different locations (ideally ASes) with some form of failover, assuming you want a reasonable guaranteed uptime
What does it mean for an interview question to be contrived?
So overly specific that it feels inappropriately artificial within the context of testing a stranger.
Yeah, the kind of question that I'm not comfortable giving a vague nonanswer to because I'm not familiar with all the intricacies they spent months ironing out. Which then turns into "what do you want me to say" whackamole of endless questions to gain the context needed to actually answer their question. Usually asked by people who cannot provide the context that actually led to the answer but still believe they understand why it was chosen.
It's a pretty specific scenario but it's happened to me
> The daycare center aesthetic and all this weird pronoun crap achieves the same ends. If everyone around you is an androgynous alien speaking a novel language and communications mishaps will get you fired, you won't feel comfortable working there. I'd argue that if you can remember people's names, you can remember their preferred pronouns - and that if you can't, or refuse to because you think it's "weird crap", the…
I'm terrible with names, but that's my own problem. I don't do voicemail or pronouns either. The rest of it is being ostracized for refusing to acknowledge the black floor tiles are lava. Redefining the reality of others is literal brainwashing. In fostering this sort of environment you're running a cult, not a company.
It's funny to whine that, "redefining the reality of others is literal brainwashing," but you obviously feel quite comfortable redefining the reality of the people you misgender for them.
Here's how to recruit software developers. 1: define the requirements for the job 2: devise questions that attempt to give insight into how well the candidate might meet that requirement 3: note down the candidates suitability out of ten for each question 4: TALK to the candidate in a free flowing and open discussion about their work, what they have done, how they built it, why they built it that way, their role in t…
> 12: Interview gimmicks, leetcode, abstract questions should be red flags for interviewees. If you're looking for a job and find yourself in a silly interview, be willing to politely call it off and save yourself the time and hassle of dealing with a company that does not know how to recruit software developers.
The world doesn't work like that. Most companies are going to put you through the 10 round process or some other tedious process. Unless you're financially willing and able to turn down over 50% (probably a lot more actually) of job opportunities. And most people have bills, mortgages, rent, food they'd like to be able to afford. So it goes.
I don't like it either btw. I agree with you in principle.
I think the "fake product" interview is a great format, but it can be done poorly if the setup is unrealistic. I've been on the receiving end of a couple of very bad attempts. In one, which I have described here before, an interviewer asked me to design a system for selling concert tickets. After half an hour of confused back and forth, it emerged that they wanted a network service that replied to requests with unpre…
To be fair, I would say if your task is to design a system it's your job to find out what the person actually wants and not run with assumptions you made based on a bad description. The reality is that you will usually start with a bad description. So I'm not sure if these misunderstandings actually reflect that badly on the interviewer/the question.
> When interviewing as a software engineer, for example, you’ll run into places that lean heavily on algorithms interviews. And don’t get me wrong, those interviews can be fun (in the same way that Project Euler can be fun), but it’s not very relevant for most jobs I'm curious what changed around 2015-2016 that led to the current interview process. In the before times the interview was more of a technical conversatio…
I just wish that if interviewing was going to become “random irrelevant stuff from second or third year CS” that we had gotten automata theory, because that was actually fun.
"So what scale are we talking about? A few million monthly users? So like hackernews? I would use a single server... "
You really need two in physically different locations (ideally ASes) with some form of failover, assuming you want a reasonable guaranteed uptime
Does 99.995% [1] of hackernews sound reasonable enough to you?
The reality is a lot of systems (especially simple ones) run perfectly fine on a single server with next to no downtime and all the additional redundancies we introduce also add additional points of failures and without the scale that makes these necessary you might actually end up reducing your availability.
The kind of people who do best at FAANG interviews are the ones who enjoy leetcoding. We’re all selecting for the wrong skills.
Even if I enjoy leetcoding and I do, there are tons of things I would rather do before that, and that are far more useful, such as building and working on side projects. So to me leetcoding is a waste of time and less fun than actually building something, having other people use what you have built. And there is infinite things to build there and learn.
I get that. I only do medium and easy problems for a reason. Hard problems are hard and I want to solve it over morning coffee. :)
Then again, I'm sure all of my leisure activities are a waste of time on someone's metric.
I probably learn more from the comments than the problems though. People post lots of interesting idioms and it's interesting to me to see how others codify various standard algorithms. Especially across languages.
That's called an in-basket test.[1] For a really unusual interview process, see how Jane Street, the trading firm, does it. They expect people to do well at this.[2] Their actual interview process starts each candidate with a stack of poker chips. In each interview, candidates get to make bets on various things that look like financial trades. If they run out of chips, they're out. [1] https://en.wikipedia.org/wiki/I…
A software system differs from the chaos the trading world represents. You can try to evaluate traders, but the deep truth is that very good traders can become very bad traders seamlessly because nothing guarantees any success of any kind in that domain.
When interviewing software engineers you shouldn't care that much about the abilities that someone shows during the time of a technical interview on a specific day; that's not an appropriate way to measure the skills you need for your business. Leet code is an appropriate way to measure how much such engineer is able to perform as a competitive coder. You will never need a competitive coder in your team; because what to be done in SE is not about coding less than 10 lines of code in less than X minutes to transform data A into data B. But back to candidate selection, due to the short amount of time you have to meet applicants, you finally decide to hire whatever person that succeeded to find the fastest solution to the almost scholastic problem you proposed because in the end, you fail to understand what could be the appropriate selection method : aren't all candidates more or less equivalent if you stop proposing leet code problems ? What can prove that X person with 5 years of exp is less good than that one that worked at google for 6 years ? Does it really matters than candidate Y doesn't know Go when all the languages we use aren't that truly different ? Is someone from nowhere, without any education of any sort, but that seems to be an hobbyist programmer since his childhood really a bad candidate ?
You never know, but because whether you're HR or the person with technical authority in the team, you don't want to risk anything, and you believe that a good leet code solver can do the work.
And finally, to me, that's the truth : more than 50% of the persons you decided to offer an interview would have done the work with success, and at least 20% seemed very nice, and you couldn't choose so leet code was the thing.
The people who are fooled by fast talkers don’t care about the results of leetcode questions either.
Even just giving Leetcode questions isn’t enough anymore… I’ve had plenty of people just memorize the top 50 used questions and be able to answer them, but then not be able to explain anything about their answer. It’s exhausting.
Explaining the reasoning while solving the code puzzle is the most important part, though. Just being able to solve them without speaking a word has never been enough. Unless you are talking about automated coding tests (but that also has never been enough).