Hacker News Reader

Comment by missblit | Hacker News Reader

> 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).

View on HN

Well, 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.

> 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.

> 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.

agreed. 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.

> Well, I think "can this be held in memory" can be a stupid question.

absolutely not. questions like that give you a baseline for idealized performance. not that you should ever expect to reach it, but it does give a good sanity check for whether or not a technology choice is a sane one.

i've seen cassandra clusters used for datasets that would fit in a sqlite (with indexes!) in a ramdisk on a cheap laptop.

so yes, scale problems go both ways. and to your point, the "difficult" problems aren't harder necessarily, often just those that you (and your team) don't know how to solve.

My point was that there are plenty of examples of systems/requirements where the dimensions of a problem are just comically out of proportion for that question- where you can't just fit this in memory, you can fit it in memory on a commodore 64, and that whether something fits in memory is not how you should thinking about the problem.

> scale problems go both ways. and to your point, the "difficult" problems aren't harder necessarily

i like the old adage: anyone can build a bridge. Only an engineer can build a bridge that can barely standup.

I trust that is meant in the Colin Chapman sense? The racecar that fails the second after it crosses the finish line is the perfect racecar. Anything more reliable than that is excess weight, performance, cost, etc.

I like that as well, idealistically. However, we work at average places with average coworkers, and are ourselves average. I'm happy to work with folks that can "only" overbuild the bridge. There's far too many people that are on the wrong side of bridge endurance.

This 100%. I worked at a company and we hired on a self described "AI expert" (I think he was a friend of the founder). He didn't last long because when push came to shove and there wasn't any hard AI work to be done, the guy didn't know how to write HTML, and couldn't seem bothered to learn. And the product was a web app.

You know what else is a hard problem? Delivering a quality product on time and in good working order. Not everything has to be at a million user scale for it to be considered a difficult task.

> Well, I think "can this be held in memory" can be a stupid question.

Why's that? If I'm sure the answer is always yes, I can quickly write something to solve a user problem that is way faster and less expensive to run.

It 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."

They 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.

No 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.

And I wonder how often a candidate actually follows up to ask why they failed and whether many interviewers will give honest/complete answers.

I'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.)

Opinions 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.

Yeah my interview questions are more jumping off points to have a conversation. At some point I'd most like the candidate to actively start teaching me something that I didn't know and generally geeking out about something and displaying some skill at getting to the lower levels of problems and its the "off script" discussions which are best. And then just avoid any personality red flags. You can't really cram for that.

Indeed... the whole "trick question" school of interviewing is basically an admission that this industry has absolutely no idea how to reliably rate job candidates (I'm not claiming that I have a magic solution myself, note...).

Doctors don't, in general, get asked trick/gotcha questions when they apply for jobs. Neither do lawyers. Neither do other kinds of engineers. Neither do musicians, for that matter.

From long-ago undergrad I remember that there is a data structure called a "red-black tree". Now, I've never had that as an interview question, but I could easily imagine it being one.

Would I be able to answer a cold question on red-black trees? Nope. As I said, that was a long time ago, and I've never had to use one to the best of my knowledge. Would that be a good reason to filter me out? Nope. If I needed to use a red-black tree (or, in general, had a problem where some unusual type of tree might be in order), I'd pull my copies of Knuth, CLR* and Sedgewick off the shelf, look at strengths and weaknesses of the different types of tree, and make a decision.

* mine is old enough that it's just CLR, not CLRS :-)

I've seen a lot of this. FAANG practically release a study guide, while tons of smaller companies think their precious little process will fall apart if the candidates even know the sort of interview they conduct up front.

Will there be leetcode-type questions? Roughly which level? Laptop, or whiteboard? Should I expect to be quizzed on networking? Javascript "gotchas" for crap I reflexively avoid so may have forgotten about? UX principles? Will the questions be general, or specific? Will it be a mix? How much, if any, of the day will be whiteboard stuff, and which part of the day will it be in?

The answers to these, and more, you should provide up front, without being asked, well ahead of time. Your signal will go up, not down, if your candidates have half a clue what to expect, out of the space of all things that might be asked in a software developer interview. Keeping this stuff a mystery and ambushing your candidate at 9AM sharp with data structure whiteboard questions, after they've flown for two hours to get to you, got up early, were on a plane then in a taxi for a while, et c., when they didn't know you were gonna do something like that, is just giving you tons of false negatives. Knock that shit off, you're wasting money and giving people bad days for no reason.

That, or just stop expecting people to "naturally" be able to pull this stuff out of their head and perform for you like a monkey, while in a stressful and semi-adversarial situation that does not resemble collaboration and teamwork in a real job (there's the excuse that "well you have to be able to perform under pressure" but interview pressure has nothing to do with, say, "prod broke and the DB went bye-bye" pressure, so that's bullshit, too). And then communicate that fact—that you're not going to torture them—too, so they don't have to stress out over it.

> The only "filtering candidates" job is the recruiter, not the interviewer

Then what's the point of the interview?

Considering the amount of incompetent candidates I've had to filter out, that just won't work.

IMO: We need a licensing board to do that for us. It works really well in other industries, where they don't need to test competence in their job interviews.

At my last startup I was advised not to give honest feedback, since no matter your intentions it is possible it could be construed to be discriminatory :(

Very rarely. And they shouldn't trust any answers that they receive.

It's difficult to give an honest answer to this question even if you want to be honest.

There are often so many little reasons that go into a rejection -- different reasons for different interviewers all feeding into an activation function that leads to a rejection or an acceptance (default state depends on team culture and how well you filter out candidates at the top of the funnel).

For most candidates, it's very hard to distill this into actionable criticism.

Edit: For anyone fundraising, this is also why you shouldn't listen too carefully to the reasons that investors give you when they reject your business as an investment.

I agree that people shouldn't trust the answers they receive.

All of us frequently give inaccurate explanations for our actions or attitudes because people often act on feelings, not on logic. Even when we want to be honest, we often lack the self awareness to know what what we're feeling and why.

On top of that, there are many who don't want to be honest, and will give an answer, any answer, just to make you stop asking and go away.

Even if a candidate gets an answer I'm doubtful the response will be much use. We like to think of ourselves as rational but I'm willing to bet most hiring decisions are anything but.

They might well tell you your skills are lacking when the reality is you remind the recruiter of the guy who ran off with his wife.

It's fairly common for companies to instruct interviewers not to tell candidates why they failed if they reach out for fear of being sued over the response. It really sucks for candidates, but given that it essentially costs companies nothing to have this policy, I'm not surprised they do; no company is going to make a choice that has even a small risk of a huge negative downside if there are no direct obvious upsides to counter it.

It's rare to get an employer to give any honest reason for a rejection. As others have pointed out, it may be for fear of getting sued, but that is only part of the general reason:

Further interaction with the job candidate almost certainly has a negative ROI (return on investment) for the employer.

If you tell the job candidate the honest reasons for rejection then at best you've used (wasted?) some time to tell the candidate this. At worst, the candidate sues.

But there are many other possibilities: The job candidate gets angry at you for telling them a hard-to-swallow truth and causes a scene. The candidate tries to argue or negotiate with you. The candidate accepts the truth and tries to use more of your time to discuss your original criticism and seek further advice.

None of these scenarios are a net positive for the employer.

Exactly. We don't know anything the author didn't tell us. For all we know, the author adamantly gave the wrong time complexity for quicksort. Or also possibly they were (intentionally or unintentionally) rude and condescending. Or there was a way candidate with a way better fit than our plucky author. Or, or, or....

Thankfully the author left the name of the company off. I'd hate for half of a secondhand account like this to cause candidates to avoid interviewing at a company!

        And 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...

I want to agree with you, but having been part of the pair-interviewing process at one of the FAANG companies, it did seem like candidates would be declined for the most arbitrary technical screw-ups. One time a manager (at least nominally) voted "No" on a candidate specifically because, despite figuring out the solution to the problem, had a compilation error in their Java code and ran out of time to fix it. I remember saying to the manager that that seems like a pretty silly reason to decline someone, compilation errors are typically pretty easy to fix, but I was relatively new to the job so I didn't want to rock the boat too much. He claimed that they only want "the best" and I guess that implied that the best don't have compilation errors.

If it wasn't a compilation error it would have been something else to cover up an unconscious bias or a 'gut feeling'. Basically seeking out the evidence, no matter how weak it is, to fit the 'crime'.

I wouldn't believe anyone who said they've never been there. For all the times you're told to trust your gut, there are plenty more times where your gut is just plain wrong and you have to go against it.

For sure. It seems akin to throwing out half the resumes at random because you only want to hire lucky people.

Personally, when I'm interviewing I help people get past dumb mistakes. We all make them, and some of the best developers I have worked with are the type to get nervous in interviews, so they become more likely to make them and have a hard time finding them. The "best" interviewee is not always the best developer.

About ten years ago, I applied for a SWE role at Facebook. During the interview, the only question that I didn't feel confident was when they asked me how group-by works in SQL and to write a group by query. I said I didn't know and usually looked it up, but they didn't want me to look it up. They rejected me, and the recruiter literally told me it was due to a lack of familiarity with SQL (something I'd been using with PHP for 6+ years at that point).

Edit: I interviewed a year later, wasn't asked about SQL at all, absolutely fumbled my way through some networking questions, and was still hired, so it's clearly very dependent on who's interviewing you and what they ask.

“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).

I 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.

I also came in to comment on this excerpt that failing someone over something so trivial is literally insane.

I 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...

It 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.

> 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.

Even then, it's good to stop and consider if those 1000 rows truly represent the full data set you need to run this on.

My 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.

I think you're taking this statement far too literally. It's part of the storytelling.

Reply on news.ycombinator.com