This is nerd-speak for "my guess was way, way off": the database under consideration would have to not just double in size, not just be 10x larger, but be 100x, maybe even 1000x or 10,000x bigger before it stopped fitting in memory. And her time at Google had her used to dealing pretty much exclusively with datasets at several hundreds of thousands times larger than the one this job was asking her to think about.

"Orders of magnitude" are a concept found wherever you have to deal with absurdly large or absurdly tiny numbers; if you've ever seen someone write a number like "2 x 10^9" then you're seeing someone use a little of this - they're saying "about two billion".

Wikipedia's page on the subject of orders of magnitude might be a decent introduction to the concept: https://en.wikipedia.org/wiki/Order_of_magnitude

> not just double in size, not just be 10x larger

"An order of magnitude" usually refers to 10x. I interpreted it as being 10x off with his guess.

"several orders of magnitude" would imply at least 100x or 1000x, depending on how small you can interpret "several" to mean.

The dictionary packaged with OSX defines it as "more than two but not many", and the copy of an old edition of Webster's that I installed also defines it as "Consisting of a number more than two, but not very many". So we're probably looking at at least 1000x.

I had it to read it a few times to. I think they were trying to say that database was so small that obviously you wouldn't need to think about distributed systems.

I'd be surprised if that was the reason they failed the interview.

It could be. If you ask the candidate to fizzbuzz and they think the solution is a key-value database of number to fizzbuzz pairs, and then they wonder, "Hey, could that fit into memory?" That kind of answer could raise multiple flags.

That's a common way I see well-educated candidates fail our interviews. What happens is that they only have N minutes to do the whole interview... If they burn twenty minutes of that time gaming out whether the DB needs redundancy, multi-tier storage, and synchronization, they don't have time to actually show me the algorithm that will generate the data to go in the database, and that's what I'm hiring them for. "Is the database the right shape" is rarely a problem at our scale.

Have you considered giving them a hint, that you primarily are looking for the algorithm that will generate the data?

I have, often. People get nerves in an interview and don't always hear what the interview is saying, I think.

Some candidates also can get into this “word salad” mode, where they just talk and talk, and don’t listen to what you are saying. They have their script and talking points and just go on autopilot, filling every silence with words and words. You can give them obvious hints and cues: “Just give me the simplest answer and we will go from there!” …and they launch right back into 5 more minutes straight of talking.

As an interviewer, I have to manage our time appropriately so we can get into all the questions, and will sometimes even have to firmly say “STOP TALKING. Unfortunately we need to move on to the next question.”

That much is true. I get so nervous in technical interviews, and it has definitely lost me some jobs I am confident I had the technical skills for.

Their database was likely measured in megabytes not gigabytes or terabytes.

I have a similar situation... it's awesome, I can afford to back the entire production DB up in its entirety once per hour for months on end.

I read it as "the database could increase in size by several orders of magnitude and still fit in memory"

Basically, you are presented with a small-scale (possibly toy) problem: the database consists of 50k entries and fits in 3 MB of disk space.

Then the interviewee starts wondering out loud whether he could load it in full on a machine with 8 GB of RAM.

Yeah. Or they veer off and discuss setting up Redshift and designs a whole ETL pipeline and data warehousing solution and a Hadoop cluster when a local file and sqlite is much more appropriate.