The Highly Experimental Blog of Erik Rose

On Interviewing

Wed 17 July 2013

I got a mail the other day from a co-worker who asked, essentially, “Do you have tips for interviewing senior developer candidates?” I accidentally a whole long thing, so here it is in its entirety, with names changed because I really like the name “Zeke” and don’t get to use it much.


Hi, Zeke. It was interesting to see the other day that Google analyzed their interview practices and found exactly zero correlation between interview performance and performance on the job. So don’t do what they do. :-) Typically, they ask some really tricky questions—it often seems like the interviewers are using the interview as an opportunity to show how clever they are.

I can’t tell you if my method works, either, but I’ve had very few regrets in hiring. In short, I interview for the basics: I don’t care if you can balance a red-black tree, because nobody ever does that in our work, and you can always look it up. I just want to know if you can rub two lines of code together (fizzbuzz, which I do during initial screens), pick some sane tests (usually I make them write tests for fizzbuzz, which makes them refactor it to use generators or whatever), and understand the rough performance characteristics of a dict. Anything else is a bonus. I guess my overarching criterion is “Would I let this person loose on my project?”

My goal during an interview is be convinced that the candidate is awesome, and I act as a facilitator to help him or her convince me. The best sort of interview is the sort I had with you. I saw an interesting project on your resume (your web-based SNES emulator) and just let you expound on it for half an hour, asking probing questions here and there. In the course of that conversation, you made clear that you understood hash tables, client/server design, and even hardware architecture. That was really ideal.

The worst sort of interview is the quiz-show sort, which, in its purest form, can feel adversarial and artificial. This sort even offends some very senior candidates. (Though I’ve had some “senior” DBA candidates be offended at simple SQL questions and then utterly fail them, so don’t take offense as a proxy for expertise.) I’m sorry to say that about two thirds of my interviews do degrade into a quiz show, and that generally indicates a lack of preparation on my part. When I have time, I Google-stalk the hell out of the candidate and try to find at least one relatively complex project of theirs to pick on, like your SNES thing. The earlier in the interview process somebody thinks to ask “What’s a piece of code that you’re proud of?”, the easier this is. Ask it in a screen, and it can inform all subsequent interviews.

Here are the areas I like to cover over a series of interviews. Pass all or most of these, and I am happy to let you loose on my project:

  • Basic coding (fizzbuzz, refactoring). This focuses hard on the ability to put things into good categories: do they split up code into functions that represent compact concepts so they’re easy to understand and reusable? Do they pick good names?
  • Testing sanity. Do they write the minimal number of tests to find the likely bugs, or are they just all MOAR TESTS ARE BETTER BWAAAAHHHH!?
  • Ability to navigate the open-source world. Can they write so they can be understood on a mailing list, IRC, or a wiki page? Can they take feedback and give it? This is an easy “pass” if they have a history of open-source contirbutions, but not everyone has that luxury.
  • Multi-machine architecture. Can they put memcache in the right place on a block diagram? Know what the plusses and minuses of DB replication are? Have some idea when and how to index something? This doesn’t require large-volume experience—I myself just had a history of crappy servers that couldn’t keep up with load.
  • Have heard of the web and grok request/response
  • Have some passion and opinions. I don’t want a pushover who won’t add anything to decisionmaking. I sometimes try to start a fight about editors or languages or something to uncover this.

Then I like a candidate to have one or more areas of deep knowledge:

  • Fancy-pants algorithms. I’m into string algorithms right now. Somebody else might be into distributed data structures.
  • Intimate knowledge of some data store, like an RDBMS or HBase
  • Mad JS, DOM, or browser chops
  • In-depth knowledge of Django or some other framework we use

If they pass that first list and have one or more from the second, they’re a great addition to Mozilla IMHO: they can start making stuff almost immediately, and, even before they get to know their project, they can act as an advisor in their areas of expertise from the second list.

Hopefully this comes off as useful to somebody, even if it’s just the people I’ll interview in the future. At the very least, it made me get my thoughts about interviewing in order.

Comments

I Will Stab Password Management In The Face

Thu 11 April 2013

Today I made the monumental error of trying to authenticate myself to work.com. Half an hour, two email accounts, a pair of password databases, and a missing-in-action password-reset email later, I collapsed defeated. I will be emailing my quarterly feedback to my colleagues instead. I tell you, password management needs to be killed with a knife.

This is out of control.

I grant that passwords are an insufficiently strong form of authentication. In time, Persona might wipe them all—or at least the web-based ones—off the face of the earth, putting all our eggs in the baskets of our email providers (which has its own problems). But for now, I've got more password databases than a reasonable person might have passwords, and it's getting worse by the day. This moment, I have before me 3 databases: a commercial one containing 236 entries; a Mac Keychain with 458; and Firefox's, with another 270. This is only on a single computer, mind you; there are various half-synced, slowly diverging copies scattered about on other devices, and it is rare that a password pulled arbitrarily from any one of these works on the first try. The Keychain generously offers 6 or 7 duplicates for many accounts, and I have to manually scan the mod dates to have any hope of success. This is beyond insane.

How did we get into this mess?

The ideal place for password management is, of course, in the OS. There, it can…

  • Work across applications and protocols
  • Know when to evict encryption keys from RAM
  • Track which applications have access to which entries and guarantee the process hasn't been tampered with since access was granted

It also doesn't hurt to have the motivational nudge of the API provider behind a password storage standard.

Though Apple made a promising start with its Keychain, it has since squandered every inch of its lead in this space. Mobile Me provided Keychain syncing across machines (though of dubious accuracy and at an additional $100 per year). iCloud provides none. Older versions of 1Password stored their data in the Keychain's single-file format, which made syncing treacherous. Newer ones abandon it for a custom, multi-file format which can be synced more easily. The rats have left the ship, and my Keychain entries are noticeably moister each time I use them.

It is a shame that Apple has no apparent interest in bringing the Keychain up to snuff, as nothing else provides the smooth integration made possible by its privileged place in the OS. Firefox Sync, LastPass, and Persona are all limited to web-based passwords. And more general databases like 1Password and PasswordWallet are still cumbersome in their ability to remember and auto-fill non-web credentials: ssh, SFTP, wifi, mail, calendar, and encypted disk images. The world is more than the web.

The cross-platform curse

Because every third-party tool is decidedly more at home on one OS than the others, we end up in the insufferable position of being unable to edit our credentials on one device or another:

  • 1Password has been promising edit support on Android "real soon now" for years.
  • PasswordWallet has great iOS sync but none on Android.
  • KeePassX and LastPass take the diplomatic tack of looking and acting equally abhorrent on all OSes.

The way out

Since we clearly cannot rely on any single party to write a password manager to meet all needs…

  • Web and non-web
  • Syncing
  • First-class support on all platforms and devices

…the obvious answer is a standardized file format we can all share. The Agile Keychain is a pretty darn good swat in this direction. It's just JSON, encrypted with 128-bit AES. It stores one entry per file, so you can use simple tools like rsync to synchronize it. Nobody's claiming any patents on it, and Agile Bits has published a rather nice sketch of the spec.

Why aren't we keeping all our passwords in this?

Comments

What They Don’t Tell You Before You Move To Silicon Valley

Wed 27 March 2013

When you move to the Bay Area, people tell you “Rent is high!” and “Public transit exists!” But they don’t think to mention a lot of the day-to-day differences that take newcomers by surprise. I’ve been here a few years now, but some of the more striking ones are still fresh in my mind:

  • You have to shove gasoline nozzles in really hard, or gas won’t dispense. This is important to figure out quickly. I visited about five different stations and nearly emptied my tank before I realized the pumps weren’t broken—merely guarding against escaping vapors.
  • Most local shops welcome dogs. They indicate it by putting a water bowl out front.
  • Surfer speak like “right on” is unsurprising, but there’s also a trademark, rapid-fire “yeahyeah”, used to indicate casual agreement. I like it.
  • Cars don’t require yearly inspection, but you do need a “smog check” every two years. California doesn’t care if your brakes work or your wheels stay on, as long as your emissions are clean.
  • There are Bizarro World versions of various food products. Hellman’s mayonnaise doesn’t exist, but Best Value comes in a cosmetically identical jar. Twizzlers are replaced by Red Vines, a slightly waxier alternative. And when you say “skim milk”, you get quizzical looks. Ask for “fat-free”.
  • Winters are mild—you’ll love it—but many trees still shed their leaves. However, they simply turn brown and fall off; there’s no pyrotechnic detour through reds or yellows for any but a few. However, if you ask your native coworkers, they will wax poetic about the fall colors and tell you the exact coordinates of the one red tree in town.
  • Turn signals don’t work. My theory is that the lingering Reality Distortion Field bleeds the charge right out of the relays.

What about my fellow transplants? Got any more?

Comments

Function Names: To Verb Or Not To Verb?

Wed 20 March 2013

I thoroughly enjoyed Brandon Rhodes’ PyCon talk, The Naming of Ducks, at which he presented and justified a panoply of Python naming best practices, far beyond the mere spelling rules of PEP 8. Among his recommendations was a common one: name your functions as if they were verbs so you know what they do. create_database, polish_silverware, televise_revolution—all make fine function names, or so goes the conventional wisdom.

Except that I’ve almost entirely dropped this practice in the last few years.

My motivation has been simple and pragmatic: verbing a function means obscuring what it returns. What does create_database return? A connection object? The name of the database? Nothing at all? So, instead, I’ve actually taken to nouning my functions, as I care much less about what they’re doing—that’s an implementation detail I’m happy to abstract away—than what they return, which is the immediate concern at the call site. This also fits nicely into my style, which tends toward the functional:

(csv_file_reader(f) for f in files_from_zip(zip_path))

Oddly enough, function-nouning forms a neat corollary to one of Brandon’s other guidelines: naming variables to make clear their types. I’m a big fan of this: name an arg connection_seq or connection_map, and callers can probably guess what kind of data structure to pass in without reading any docs. Combine this with function-nouning, and you make two things automatically clear:

  • The nature of the return value
  • The information that factors into the function’s result—care of the nicely-named args you pass in

Thus, the input is clear, and the output is clear. In fact, the only thing that’s left a mystery is the process by which the function effects the input-to-output transformation, and I contend that’s of secondary importance: most of the time, I’m content just to have the output I need and don’t bother about the implementation. Isn’t that the entire point of abstracting functions to begin with?

What do you think? To verb or not to verb? Perhaps a more imperative style changes the tradeoffs, or maybe there are practical advantages in verbing that I’m not thinking of.

Comments

How to Really Reduce Greenhouse Gas Emissions

Mon 11 March 2013

My friend Fred recently got me thinking about environmental stewardship programs. Like Fred, I’m skeptical of a lot of consumer-targeting “be green” campaigns. As with hotels’ pleas to wash your towels less frequently, they are often corporate profit-boosting measures in altruistic clothing. No one ever offered me a room rate discount for using my towels a bit longer.

More generally, the “ride your bicycle” and “buy cloth shopping bags” crusades that dominate public consciousness are optimizing in the wrong places. In 2009, 16 ships burning essentially tar released as much atmospheric sulfur (the stuff that causes acid rain) as all the cars in the world.

As another example, about a quarter of greenhouse gas emissions are from electricity generation—26% in 2004. The U.S. is still 42% reliant on coal, the dirtiest fuel in common use. Coal releases over twice as much carbon dioxide as the next dirtiest fuel per kWH generated, natural gas. So, what we should be doing is running full-speed toward safe, clean nuclear. Even old generation-II reactors are 62 times less carbon-intense than coal. Modern generation-III reactors may be even lower. The entire transportation sector—including commercial interests driving big, dirty trucks—emits only 13% of greenhouse gases, and fixing that requires energy storage technology we don’t have, along with the coordination of millions of individuals and companies to purchase new equipment. This is not where to optimize.

While carting around reusable shopping bags and driving electric cars makes us feel good, it’s an awfully inefficient way to attack the problem. If you want to conserve the environment, write to your legislators instead. Campaign for cleaner shipping fuel standards. And welcome safe, modern nuclear plants into your back yard.

Comments

  • atom feed
  • github
  • twitter