The Question

Most consumer-facing web startups these days use one of the major open source databases, either MySQL or PostgreSQL, to some degree. If you want to prove your worth it’s a good idea to get down to the nitty gritty and gain some understanding about these databases’ internals.

So, the question: “Explain to me what databases indexes are and how they work.”

The Answer

In a nutshell a database index is an auxiliary data structure which allows for faster retrieval of data stored in the database. They are keyed off of a specific column so that queries like “Give me all people with a last name of ‘Smith’” are fast.

The Theory

Database tables, at least conceptually, look something like this:

id	age	last_name	hometown
--	--	--		--
1	10	Johnson		San Francisco, CA
2	27	Smith		San Joe, CA
3	15	Rose		Palo Alto, CA
4	64	Farmer		Mill Valley, CA
5	55	Pauling		San Francisco, CA
6	17	Smith		Oakland, CA
...	...	...		...
100	49	Meyer		Berkeley, CA
101	30	Wayne		Monterey, CA
102	18	Schwartz	San Francisco, CA
104	6	Johnson		San Francisco, CA
...	...	...		...
10000	41	Fetterman	Mountain View, CA
10001	25	Breyer		Redwood City, CA

That is, a table is a collection of tuples¹. If we have a file like this sitting on disk how do we get all records that have a last name of ‘Smith?’

The code would wind up looking something like this:

Finding the appropriate records requires checking the conditions (here, having a last name of ‘Smith’) for each row. This is linear in the number of rows which, for many databases, could be millions or billions of rows. Bad news.

How can we make it faster?

Database Indexes

Any type of data structure that allows for (potentially) faster access can be considered an index. Let’s look at some.

Hash Indexes

Take the same example from above, finding all people with a last name of ‘Smith.’ One solution would be to create a hash table. The keys of the hash would be based off of the last_name field and the values would be pointers to the database row.

This type of index is called, unsurprisingly, a “hash index.” Most databases support them but they’re generally not the default type. Why?

Well, consider a query like this: “Find all people who are younger than 45.” Hashes can deal with equality but not inequality. That is, given the hashes of two fields, there’s just no way for me to tell which is greater than the other, only whether they’re equal or not.

B-tree Indexes

The data structure most commonly used for database indexes are B-trees, a specific kind of self-balancing tree. A picture’s worth a thousand words, so here’s an example.

The main benefit of a B-tree is that it allows logarithmic selections, insertions, and deletions in the worst case scenario. And unlike hash indexes it stores the data in an ordered way, allowing for faster row retrieval when the selection conditions include things like inequalities or prefixes.

For example, using the tree above, to get the records for all people younger than 13 requires looking at only the left branch of the tree root.

Other Indexes

Hash indexes and B-tree indexes are the most common types of database indexes, but there are others, too. MySQL supports R-tree indexes, which are used to query spatial data, e.g., “Show me all cities within ten miles of San Francisco, CA.”

There are also bitmap indexes, which allow for almost instantaneous read operations but are expensive to change and take up a lot of space. They are best for columns which have only a few possible values.

Subtleties

Performance

Indexes don’t come for free. What you gain for in retrieval speed you lose in insertion and deletion speed because every time you alter a table the indexes must be updated accordingly. If your table is updating frequently it’s possible that having indexes will cause overall performance of your database to suffer.

There is also a space penalty, as the indexes take up space in memory or on disk. A single index is smaller than the table because it doesn’t contain all the data, only pointers to the data, but in general the larger the table the larger the index².

Design

Nodes in a B-tree contain a value and a number of pointers to children nodes. For database indexes the “value” is really a pair of values: the indexed field and a pointer to a database row. That is, rather than storing the row data right in the index, you store a pointer to the row on disk.

For example, if we have an index on an age column, the value in the B-tree might be something like (34, 0×875900). 34 is the age and 0×875900 is a reference to the location of the data, rather than the data itself.

This often allows indexes to be stored in memory even for tables that are so large they can only be stored on disk.

Furthermore, B-tree indexes are typically designed so that each node takes up one disk block. This allows each node to be read in with a single disk operation.

Also, for the pedants among us, many databases use B+ trees rather than classic B-trees for generic database indexes. InnoDB’s BTREE index type is closer to a B+ tree than a B-tree, for example.

Summary

Database indexes are auxiliary data structures that allow for quicker retrieval of data. The most common type of index is a B-tree index because it has very good general performance characteristics and allows a wide range of comparisons, including both equality and inequalities.

The penalty for having a database index is the cost required to update the index, which must happen any time the table is altered. There is also a certain about of space overhead, although indexes will be smaller than the table they index.

For specific data types different indexes might be better suited than a B-tree. R-trees, for example, allow for quicker retrieval of spatial data. For fields with only a few possible values bitmap indexes might be appropriate.

Good Question, Bad Question

I like this question because it shows whether the interviewee is curious enough to dive into these details. For certain higher-level engineering positions knowing this should be second-nature, but even for a generic web development position knowing how your database works will only help you improve the performance of your web application.

Also, it’s just arcane enough that you can go through the motions without knowing it, but not so arcane that it’s inaccessible to someone without an advanced education. Any decent programmer should be able to understand it — the exceptional ones will go out of their way to learn it.

1. For bonus points, the “relational” in “relational database” comes from this fact, not from the idea that there are “relations” between tables.
2. Technically the size of an index is going to be proportional to the cardinality of the column being indexed.

The setup usually goes something like this. We’re receiving gigabytes of data per second. Each chunk of data comes with a header that contains an unsigned 32-bit integer. Let’s call that integer the routing number. We choose the routing destination based on the number of on bits in the binary representation of the routing number.

Write a routine that returns the number of on bits in the binary representation of an unsigned 32-bit integer in C.

The Naive Solution

As usual there’s a naive solution. In this case you could loop through each bit at a time, counting the number of ones.

>> is the right bit-shift operator. It drops the right-most bit from the binary representation of an integer. So, 0x1001 >> 1 is equal to 0x0100.

The above has a few issues. First, it takes O(n) time, where n is the length of the binary representation of the integer. Can we do better? Second, it doesn’t take into account the fact that n is a 32-bit integer¹.

Pre-computation

Since speed was a requirement something that takes linear time is probably a bad idea. The key idea is to realize that a deterministic function, like bitcount, is no different than a hash where the keys are the inputs to the function and the values are the output of the function.

This is principle behind memoization, for example, but here we’re sitting pretty. Since both the input and output are unsigned integers we can create a regular array, call it bit_table, where bit_table[i] is the number of on bits in the binary representation of i.

Furthermore since we have the constraint that the integer is 32-bits we can, in theory, pre-compute the entirety of bit_table and include it in a header. It’d work like this:

Size Constraints

bit_table32 is going to contain 4,294,967,296 integers. Depending on the size of an integer on your platform this will probably take up several gigabytes of memory. If we want a constant-time algorithm that takes up significantly less memory we can create a 16-bit table and use bit arithmetic.

The Unrestricted Case

If we don’t know how many bits the integer will contain (say we moved from a 32-bit to a 64-bit platform) then we can iterate over the binary representation 16 bits at a time, using the pre-computed table at each step².

Good or Bad Question?

This question suffers from the same problems that the reversing linked lists in that you probably either know the solution or you don’t.

That said, the solution here — pre-computing a list of values to CPU time — is much more common than the tortoise and hare solution in the previous question, so the likelihood of it dawning on you during the interview is that much greater. Plus I’ve been asked this question so many times that it’s one of those must-know exercises, in my opinion, even if the question itself could be better.

1. Let’s ignore the subtleties of integer types in C for now, ok?
2. For the hard-core bit-counters out there, the C specification requires that integers contain at least 16 bits.

This installment deals with a common question about linked lists — how do we detect when one has a loop?

Linked Lists

Linked lists are one of the most simple data structures and most aspiring programmers learn them early on. But for completeness’ sake let’s cover that ground.

A linked list is a sequence of nodes. Each node contains a piece of data and a reference to the next node in the list. Graphically it looks like this

Loopy Linked Lists

It’s possible, though, that a node in a linked list might point to a previous element in the list. This is bad for many reasons, not the least of which is that any loop which iterates over all the nodes in the list by accessing the next node will never terminate.

So, it becomes important to detect when linked lists have loops. Here’s what one such errant linked list looks like.

The Easy Solution

The easy solution is to keep track of every node seen so far and check if the current node is in that list. Here’s a very simple linked list implementation in Ruby.

Here is the simple solution for detecting loops using the above implementation

This solution is workable but sub-optimal (surprise!). This has O(n²) complexity in CPU and O(n) complexity in memory, but a solution with O(n) complexity in CPU and O(1) complexity in memory is possible. In fact, this question is usually posed to preclude the above solution.

The Tortoise and the Hare

The better solution involves a bit of mathematical thinking. If there is a loop then that means any iterator, no matter how many steps it takes per iteration, must hit the offending node.

So, if we have two iterators, one of which has a length that is a multiple of the other, they’ll eventually land on the same node. The usual solution is to have one iterator advance one at a time (”the tortoise”) and a second iterator advance two at a time (”the hare”).

That algorithm looks like this

More Questions

Assuming you answer the above correctly and quickly the interviewer will probably follow up with some related questions. How do you fix the linked list when you detect a loop? What is the linked list has multiple loops? How do you determine the size of the loop?

I’ll leave you to ponder these questions. Cheers!

Every tech interview I’ve ever had has four stages:

1. Small talk and swapping brief personal bios.
2. Questions about your previous employment and projects.
3. Technical questions and brain teasers.
4. Turning the tables: “Do you have any questions for me?”

The meat of the interview is in the second and third parts where you can directly show your knowledge, skill, and passion, but don’t underestimate the value of the fourth part.

Don’t be Afraid to Ask Hard Questions

Most people use the fourth part to ask “What is it like working here?”-type questions. If you think you’re going to get interesting responses by all means ask those, but most interviewers I know lie to some degree to make their job sound approximately ten times more awesome than it really is. They probably don’t want to admit that there are parts of their job they hate to themselves, let alone some interviewee.

Besides, if you want to know the bad parts about the job — and there will be some — just ask that question directly. They’ll either be forthright or they won’t and it’s pretty easy to discern between the two cases.

Using the Questions to Show Off

In Joel Spolsky’s article The Guerilla Guide to Interviewing he says that you want to hire people who are two things: one, smart; two, able to get things done.

Since Interview 2.0 is the common interview style in most technology companies these days you don’t always have the chance to show off how smart you are, but the fourth part offers a path to redemption.

Let’s say you’re interviewing at Amazon and have a background in mathematics. You should be asking the engineers questions about the interesting mathematical things they do, have done, or have tried to do with their massive data sets. This shows that you’re not only engaged with the interviewer and the company, but have knowledge that can be brought to bear.

The same applies if you’re a marketer or whatever. If you feel like you haven’t had the chance to show the interviewer all you have to offer then asking intelligent questions that you know something about is a great strategy.

A Hard-Learned Lesson

I learned this lesson the hard way. About a month after I left Sugar, Inc. and two months after I launched Appaholic I was interviewing at Facebook. For most of the interviews the technical/quizzy type questions went well. I had even sent in solutions to two of their job puzzles before I came in.

I was a little frustrated that most of the CS-type questions were about designing databases (as in, writing one from scratch) since I’d never had to do that before. You can never know too much, though, so I only blame myself.

When it came time to ask them questions, instead of using the strategy above and showing them I did have a solid grasp of the fundamentals they were looking for, I asked them the following question: “Facebook is a _____ company. What would you put in the blank?”

Every single person said “technology” and then I probed them about that. “But you guys make money by selling attention. How does that not make you a media company?”

This is a bad question to ask engineers, even high-ranking ones, because most engineers don’t give a crap — they just want to create cool products and gizmos and bristle when people interject marketing and business mumbo-jumbo.

And boy did they bristle. I won’t name names, but it was clear this wasn’t a welcome question. My time would have been better spent asking them technical questions because it would’ve created a discussion they wanted to take part in.

I thought I was being clever but instead I torpedoed my chances of getting an offer there by annoying my interviewers and reinforcing their opinions about my technical skills.

Not one month later I sold Appaholic/Adonomics, so it worked out well, but I still view it as a strategic mistake. Lesson learned!

The Question

You have an array A of size N. Write a routine that shuffles the array in-place. The only restrictions are that all possible permutations of A must be possible and equally likely.

This interview question serves as a test for basic algorithm construction. There’s a canonical solution that’s not too difficult to arrive at if you’ve never seen it before, so it’s a good combination of “what do you know?” and “what can you do?”

Workin’ it out

I’m going to create my solution in Ruby because that’s the language the company that asked me this question used.

The first solution most people arrive at is subtly wrong. Jeff Atwood made the mistake in his blog post. The algorithm, in words, goes like this: iterate through each item in the array, pick another element at random, and swap the two.

In Ruby the above algorithm would look like this.

This solution seems correct if not optimal, but there’s a subtle problem: not all outcomes are equally likely.

The root cause of this is because this algorithm is drawing from a sample space of size N^N, while the sample space of all permutations on an N-element array is only N!.

That is, for the naive shuffle, for each of the N steps in the iteration we make one of N decisions for a total of N^N possible outcomes.

But N^N > N! for all N > 1 and, more importantly, N! is not a divisor of N^N. This means we’re going to prefer at least one of the permutations more than the others, so the algorithm doesn’t select among the possible permutations uniformly.

KFC, KFY

The “best” solution is the Knuth-Fischer-Yates shuffle. Here it is in Ruby

This works because it’s an iterative version of an essentially recursive algorithm. If we know how to shuffle an array of size N-1 then shuffling an array of size N is easy — first shuffle the sub-array consisting of the first N-1 elements and then randomly swap in the last element to any of the N slots.

There’s a proper inductive proof in there if you’re so inclined, but it’s not particularly illuminating.

Good Questions, Bad Questions

My next article is going to be more about the interview process rather than specific questions. One key thing to understand in an interview is what information the interviewer is looking for in asking their question. Hint: it’s not always the answer.

Among other things they want to suss out the limits of your knowledge, how you solve problems, how quickly you resort to help, and a whole assortment of other, behavioral things, that they get because you’re right there (hopefully) engaging in a dialogue.

I know people keep a repertoire of interview questions at hand, so I’m not going to name names when discussing the questions. Anyhow, let’s get started!

The Question

You’re standing in front of a 100 story building with two identical bowling balls. You’ve been tasked with testing the bowling balls’ resilience. The building has a stairwell with a window at each story from which you can (conveniently) drop bowling balls.

To test the bowling balls you need to find the first floor at which they break. It might be the 100th floor or it might be the 50th floor, but if it breaks somewhere in the middle you know it will break at every floor above.

Devise an algorithm which guarantees you’ll find the first floor at which one of your bowling balls will break. You’re graded on your algorithm’s worst-case running time.

Warning: Stop reading here if you’re not interested in seeing any of my solutions!

A Few Preliminaries

The original problem stated that the building had 100 floors, but it may as well have N floors. Using N rather than 100 will make it easier to quantify the performance of the algorithm, so that’s what I’m going to do.

Solution 1: The Naïve Solution

Ok, there’s one blindingly obvious solution: take one of the bowling balls and drop it from every floor, starting from the first. At worst this will take N tries, where N is the number of stories on the building.

Interview Advice:: In an actual interview situation don’t be afraid to say the obvious solution, even if you know there’s a better one. Problem solving is iterative and your answer should be, too.

Solution 2: Two Bowling Balls

We know the first solution is probably sub-optimal because it doesn’t make use of both bowling balls. To give us some ideas let’s just pick a floor, say the 50th floor, and drop one of the balls — we has nothing to lose since we know we can do it with only one.

If our building is 100 floors and we dropped one of the balls from the 50th floor one of two thing will happen: the ball will either break or it won’t. If it breaks then we know the floor we’re looking for is somewhere between floors 1-49. If it doesn’t then we know it’s somewhere between floors 51-100. In either case we’ve halved the size of the search space and now need at most N/2 (or 50) tries.

But 50 was arbitrary. What about other numbers? What happens if we drop the ball on the third floor? If it breaks then we can use the second ball to test floors 1-2, taking at most 3 tries. If it doesn’t break then we try the same experiment again, dropping the ball from another floor.

Here’s one possible strategy: pick a number S and call it the skip number. We drop one ball every S floors until it breaks on the k^th try. We then use the second ball to try every floor between floors (k-1)*S and k*S.

As an example, let N=100 and S=4. We’d try floors 4,8,12,16,… with one bowling ball until it breaks. Let’s say it breaks on the 60th floor. Since it didn’t break on the 56th floor we know the culprit is somewhere on floor 57, 58, 59, and we can use the second ball to test those floor one at a time using the naïve strategy.

What is the best skip size? Obviously S=100 isn’t ideal since that is equivalent to the naïve strategy, as is S=1. But we know both S=50 and S=4 are better, so there must be an optimal strategy somewhere between. To find this strategy let L(S) be the number of drops requires in the worst-case scenario for a skip number of S. If you work it out you’ll get

We want to minimize this function. Bringing back our high school calculus, the derivative of L(S) is

Setting the derivative equal to zero implies

For N=100 this gives an optima skip of S=10. If N isn’t a perfect square you’ll have to work out which skip gives the “correct” solution.

Solution 3: You can do better…

At this point in the interview you’re probably pretty happy with yourself. The above took you a few minutes to work out, perhaps with some prodding by the interviewer. But then you hear that dreaded question, “Can you do any better?”

The interviewer isn’t a jackass, though, and gives you a hint. He points out that it seems like we should be able to find a solution that works equally well irrespective of where the bad floor is. That is, it should take the same number of turns if its on the 100th floor as it would if it were on a lower floor.

We have a baseline for ourselves. For N=100 and S=10 we know we can do it in at most 19 turns. This can act as a sort of counter — if we beat this number at every step we’ve come up with a strictly better algorithm. So, at every step, we want to be able to find the floor in question in no more than 18 steps.

Let’s start by dropping the first ball on the 18th floor. If it breaks we can test floors 1-17 with the second ball, taking at most 18 turns. If it doesn’t break, we’ve used up one of our turns, leaving us with 17 turns left.

So, the next floor we should test is 18+17, or the 35th floor. If it breaks we can test floors 19-35, taking at most 18 turns. We can continue this way, shrinking the step size by one each time. Now we know we can do it in at least 18 steps.

But why not 17? If we repeat the above steps, starting with a counter of 17 rather than 18, we get an algorithm that takes at most 16 steps. Then, using 16 as a counter, we get an algorithm that takes at most 15 steps. We can’t do this forever, since there’s no possible algorithm that takes at most one step. So where is the end of the line?

The problem is that for this algorithm to work the first ball needs to be able to skip one fewer each time and still cover all 100 floors. If we set our counter to C that means we must have 1+2+…+C > 100.

Here’s the math:

Using the quadratic formula to find the exact solution and then taking into account the fact that we want an integer solution gives

as the worst possible case for our third strategy. L(100) = 14, which checks out.

That’s the best solution I know, and it was the best solution the interviewer knew, too. Can you do any better?

After The Interview

This was one of a few questions I was asked by one of four interviewers. I worked through the problem above, basically as it was written out, albeit with more digressions. How did the interview wind up going? I wasn’t offered a job. At least I got a good interview question out of it, though.