Hiring is hard. Hiring great engineers is harder. But cleaning up bad engineering work from bad hires is the worst!
If you are an engineering manager like me, its your responsibility to hire engineers and generally set the bar very very high for candidates. The most obvious well known trick is to hire people smarter than you(The whole A’s hire A+’s, B’s hire C’s thing). But many a times, especially in startups or service companies, due to high pressure demands, this bar can go down and there is nothing worse.
There a lot of the times engineers can be false positive -i.e. they come across as brilliant in the interviews. Many a times this is because engineers are extremely well prepared specifically for interviews(having gone through the thousand of resources available online, the data set of available questions,unheard of yet, is bound to get smaller)
So , interviewing has to model a bloom filter in reverse
Background on a bloom filter:
During the process, you are probably involved in a couple of rounds with the interviewee, but in general its your engineers who interview potential candidates. Engineers understand engineering terms better. Hence we should be modelling the process and communicating to the engineer similarly.
A Bloom filter is a space-efficient probabilistic data structure, conceived by Burton Howard Bloom in 1970, that is used to test whether an element is a member of a set. False positive matches are possible, but false negatives are not.
The idea is that a query for an item returns either “possibly in set” or “definitely not in set”. Elements can be added to the set, but not removed (though this can be addressed with a “counting” filter). The more elements that are added to the set, the larger the probability of false positives. Plus a bloom filter is a great data structure particularly if you are using strong caching mechanisms. Hence you’d do good getting your engineers to learn a swanky data structure while they interview other candidates.
How does this apply to interviewing:
Applying this to an engineering candidate is interesting. You have to be biased towards false negatives, false positives should not make it. Ala a reverse bloom filter, which could say a candidate should be looked at as “Great but wont make it” and not “OK should make the cut” or False negatives are possible but false positives aren’t. Essentially this says, its OK to lose very very good engineers who don’t make the cut(but certainly are great), but its absolutely not ok to hire bad eggs on a false curve. The cost and time spent on training and cleaning up behind these engineers can get exponentially higher than the time spent carefully interviewing candidates and selecting the right one.
Might be a convoluted way to think about it, but it’s worked so far for us. 🙂
Comments welcome. Ok maybe instead of a reverse bloom filter I could have said a lossy hash table or a LRUCache or even a direct mapped cache. But they don’t sound as catchy 🙂