7 ms·
> I didn’t know the limit because it had been many years since I’d had a problem that could be solved with a DB small enough to be held in its entirety in memor
by missblit 5y ago
> I didn’t know the limit because it had been many years since I’d had a problem that could be solved with a DB small enough to be held in its entirety in memory. And they were right to fail me for that: the fact that I was good at solving strictly more difficult problems didn’t matter because I didn’t know how to solve the easier ones they actually had.
No way it's "right" to fail an interviewee because they wondered outloud if a dataset can fit in memory. A candidate should be able to estimate the answer, but beyond that it's trivia that can be researched as needed -- indeed even asking the question is a positive signal not a negative one (it's not just people with "google scale" background who reach for over-complicated solutions).
- leephillips 5y ago“No way it's "right" to fail an interviewee because [she] wondered outloud if a dataset can fit in memory.” That made no sense to me, either. My reaction was that she was fortunate not to work there (but further down she mentions that she wound up there anyway).
- sam0x17 5y agoI also came in to comment on this excerpt that failing someone over something so trivial is literally insane.
- blueplanet200 5y agoI was mostly in agreement. I suppose it depends on the scale of the data. Fitting 1000 short rows in memory is something I'd expect anyone to know off the top of their head just works. It really depends on the specifics of the question and the seniority of the role...
- woko 5y agoIt is clear by the mention of "several orders of magnitude" that we are talking about a database which fits in a few MB of disk space on a machine with a few GB of RAM. If the interviewee has never worked with a database which would fit in the memory of the machine, and if the company only deals with such databases, then it is clear that it was not a good fit. Failing the interview does not mean that the interviewee is bad, just that they don't know how to count that low, and thus were not the person for the job.
- Dylan16807 5y ago> If the interviewee has never worked with a database which would fit in the memory of the machine, and if the company only deals with such databases, then it is clear that it was not a good fit. Why? That's not clear at all to me. Most of the job is the same, and the parts that are different are themselves mostly removing steps that aren't needed at a smaller scale.
- Dylan16807 5y agoEven then, it's good to stop and consider if those 1000 rows truly represent the full data set you need to run this on.
- robocat 5y agoMy guess is that the interviewer was using the question to select for people who choose appropriate solutions. Someone who suggests a complex highly scalable replicated database architecture for a 5MB database is very likely an unsuitable candidate. Also the interviewer could be looking for whether someone asks the right questions to be able to suggest an appropriate solution, rather than someone who doesn’t ask, jumps to conclusions, and makes poor assumptions. Once you have worked with one architectinaut that builds baroque solutions, you make sure you don’t employ that kind of person. Anyone can design something complex, it takes talent to simplify everything properly.
- zomglings 5y agoNo one knows why they actually failed her on the interview. Have run many interviews, and it is very rarely the case that you fail a candidate for one technical slip up.
- ellyagg 5y agoAnd I retrained on smaller numbers and got that job at that start-up. Folks are probably much more likely to tell you why you didn't make it the first time you applied...
- ragnese 5y agoAnd I wonder how often a candidate actually follows up to ask why they failed and whether many interviewers will give honest/complete answers.
- gwbas1c 5y agoI'd never give a detailed answer, because I don't want future candidates to cheat. The last thing I want is for someone to share my interview, and then I can no longer filter out bad candidates. It takes a super-long time to write a good interview. But, more importantly, very few candidates fail on a single question. They usually fail on patterns: Poor comprehension of the task at hand, too many snap judgements, or lack of professionalism. (Another reason, though, is that I've rejected a lot of people who I believe shouldn't be software engineers. It's not my place to tell them they should pick another career, nor do I want to make it easier for them to bluff their way to becoming someone else's headache.)
- thanhhaimai 5y agoOpinions are my own. If you rely on a "not-leaked" interview to filter out bad candidates, it's likely that you may not be conducting an effective interview. Good interview is about figuring out "what the candidate is good at" not about "gotcha I proved that you're a bad one to filter out". I don't have a set of questions I ask all the candidates. Instead, I based the questions on their experience and projects. It's common that I found out "the candidate is not as good as they claim for this subject", and that's fine. The interviewer can switch the topic and see if the candidate is good at another subject. Everyone is good at something. The job of the interviewer is to find out that, and whether that fits the business needs. The job of the hiring committee is to decide whether it's worth paying for that compared to other candidates. The only "filtering candidates" job is the recruiter, not the interviewer.
- fullshark 5y agoI took it as poetic license, most interviewees don't know why they failed, maybe an interviewer's offhand comment caused her to fill in blanks or extrapolate from the general point -> She wasn't the right fit due to the scale of problems.
- deleted 5y ago[deleted]
- Traster 5y agoWell, I think "can this be held in memory" can be a stupid question. What I thought was more of a problem is: > And they were right to fail me for that: the fact that I was good at solving strictly more difficult problems didn’t matter because I didn’t know how to solve the easier ones they actually had. Scale problems are a type of problem. They aren't strictly more difficult than problems on a smaller scale. Being able to scale to thousands users/cpus/shards is a skill. Thinking your niche skills are solving the "difficult" problems and other skills are easier is not a good attitude.
- zem 5y agoagreed. in fact, in my time at google i've focused on the other end of the spectrum, solving "small" (in terms of resources required) problems well so they can be used reliably by the people building larger-scale systems.
- PragmaticPulp 5y ago> Thinking your niche skills are solving the "difficult" problems and other skills are easier is not a good attitude. This is one of the biggest obstacles I've encountered when hiring people out of big companies and into smaller startups. At a very big, very established tech company it's easy to focus on your narrow problem and leverage all of the company's infrastructure to get things done. Moreover, you should be leveraging the company's infrastructure and not reinventing the wheel. Some (though not all) of these people struggle to adapt when they move to another company where all of that infrastructure isn't available. Maybe they never had a chance to learn how to do it. Or maybe they've just been convinced that their previous company's infrastructure was the only correct way to do something. Either way, they get stuck in a position where they don't know how to solve problems without their previous company's infrastructure. Best case, they admit the gap in their knowledge and work on filling it as fast as possible. Worst case, they spend years trying to recreate their previous company's big-company infrastructure before they can get started on this new small-company problem that they've been given.
- chii 5y ago> they don't know how to solve problems without their previous company's infrastructure. this is basically an indication of the lack of problem solving, and instead, they've just been "tool using". It's the same sort of phenomenon as someone copying a snippet off stackoverflow, and tweaking it, without understanding _exactly_ how it works (and all of the underlying theory/understanding required). Real problem-solvers don't need this, but only reach for a tool from their toolbag after they've completely understood the problem, and have a solution in mind.
- ineptech 5y agoIt seems likely that that was shorthand for "I failed the interview because I was unsuitable for the role, due to the effect described in this essay, as pithily illustrated by a particular exchange which helped us both realize that this was not a good fit."
- crate_barre 5y agoThey just probably got turned off by how senior the guy was and assumed he/she would be unable to be wrangled. It’s a bad judgement call, because usually you gain many years of experience at various companies because of exactly that, your ability to state your view, yet still compromise with leadership. Yet, in the interview they judge it as ‘this person won’t listen if I need them to’. They will, that’s how they made it that far. In fact, they are speaking to you this way because they’ve been trusted to speak this way in the past, and you are interviewing them because they’ve been trusted to also do the job in the past.
- jiveturkey 5y agoI think you're taking this statement far too literally. It's part of the storytelling.