When I was at Cisco, my last project was about what Cisco could do about the email spam problem. Cisco had exactly no presence with email in any form, so this was as greenfield as it could get within the confines of $MEGACORP. We got chartered by Dave Rossetti and got together a bunch of senior engineers where we immediately started tapping our white canes in the email universe. I remember talking to Eliot Lear one day about how maybe we could affix a signature to each piece of email from a stable private key from the sender and let the magic of Bayesian filtering do its job. I don't think that Eliot was overly optimistic about unanchored keys -- although I don't think he laughed out loud either. I floating the idea with the rest of the group after that. I'm struggling to remember whether Jim Fenton (Jim, help me?) had been thinking down similar lines, or not, but the end result is that our white canes were now tapping at a furious rate at what would ultimately be called Internet Identified Mail (IIM). IIM had a shiny new thing we called a key distribution server (KDS) which bound the key to a given domain, and used HTTP to transport the keys to the receiving domain to verify the signature, so I'm sure that Eliot was assuaged.
We wrote an internet draft and started socializing it. In the mean time, I hacked up a sendmail milter (code that sits in the mail flow pipeline that can munge the email) and hashed out a lot of the boring message on the wire syntax mainly by needing to get down to that level to be able to code it up. Jim and I were much more interested about the semantics, after all. After having a working prototype, along with our socialization outside Cisco we ended up finding out that Mark Delaney at Yahoo down the street from us was working on his Domain Keys draft/implementation which looked different, but eerily similar too. We finally got together and made our cases to each other -- we were looking from the vantage point of enterprise, and Mark understandably was thinking service provider. After some soul searching Jim and I decided that the main differences were with syntax in way the signatures parameters were sent, canonicalization, and the use DNS vs HTTP for key lookup. Truly yawn inducing details thinking back about it.
So DKIM was born -- Domain Keys (Mark) Identified Mail (Jim and I). This lead to a very large push outside with lots of IETF folks. One the remarkable things about the experience is that the eventual working group had rough consensus and running code in spades, and well before the actual working group was spun up. I managed to eek out a small victory in being the first one to want to interop code with others, with Murray Kucherawy then at Sendmail following like the next day. Murray's worked a lot better than mine, but he had written the DK milter, so he was at a big advantage.
During the journey, we started talking to a company called Ironport who were also participating and knew what Murray and I had done. Jim and I were part of the due diligence team that vetted Ironport that Cisco went on to buy. In the mean time, internally we had started our own effort, and my DKIM code was put into Cisco's mail pipeline with a racked up box (Cisco is a hardware company... it's what you do). So not only did I write the code for DKIM, it was running in a Fortune 500 company's mail infrastructure, and for a company that lived and died by email, that was no small thing. It never had a hiccup.
So what does this have to do with Toxic Programming Tests you quite reasonable ask? All of the above should show to any idiot that I'm quite capable of writing solid code in short order. Once Ironport was part of Cisco, it was obvious that our project was done so I decided to try to jump over to the Ironport acquisition. When I finally interviewed, they gave me a programming test -- strstr as I recall. I wrote a shitty version of it but said that in real life I'd get out Knuth and lean on his genius. I mean, I had been out of school for 25 years by then... these algorithms are not on the tip of my tongue. Afterward, I was told that the universal reaction was that I couldn't write code. I'm like what in the fucking fuck? They reduced all of the evidence to the contrary to a single coding test that I wasn't even expecting! In another interview later I was vetoed because I couldn't recall off the top of my head what the Java keyword for a constant was (final) by a shitty junior engineer. I know lots of languages and it takes a little bit of time to swap them in and out. FWIW, I knew the answer but just couldn't remember it in the interview.
That is toxic. Coding tests have always been pretty close to useless because different people like to code in different ways. I like to be holed away and absolutely loath people staring over my shoulder. But guess what, that's what coding tests force you to do! So by all means, ignore your lying eyes and base everything on 25 year old memories of algorithms which in real life you'd be fired if you were to roll your own. Rinse repeat. Over and over. Interviewers are completely convinced that if you don't know whatever obscure algorithm they are throwing at you, you can't code. Research by Google of all people -- because they are the absolute best at this toxicity -- showed that coding tests and lot of the other toxic interviewing they did was not only useless, but were actively harmful. I interviewed once at Google before this revelation and got the same idiotic treatment and rejection. For years they would call back asking me to interview again, and every time I said no and the reason why. I finally started telling recruiters that if it involved programming tests, I wasn't interested.
The thing that's most stunning about all of this is that they never want to talk about what you've done in the past. The excuse that I've been given is that it could all be a lie. But memorizing algorithms is its own sort of lie. In my opinion, your past is an excellent place to quiz the interviewee because they better be able speak to the architecture, design and implementation with authority. A thing I would look for are the subconscious "we"'s which can mean that they are embellishing their part in the project. But that's a different rant.
After doing some research on this admitted hobby horse of mine is that a Fizzbuzz-like test might be ok, but treating even mid-career engineers the same as fresh college grads is lunacy. As I've written before, a lot of these interviewers are really just looking to have their penis extended so they are doing these kinds of interviews in bad faith in the first place. Yet way too many companies seem to rely on these kinds of tests as if they were delivered wisdom. Sorry, no I'm not going to re-read Knuth to get a job at your shitty-ass company that I don't know a damn thing about, let alone what I might be doing.
Tests, to god-damned hell with tests! We have no tests. In fact, we don't need tests. I don't have to show you any stinking tests, you god-damned cabrón and chinga tu madre!
No comments:
Post a Comment