Why I went with them and not you

I’ve been interviewing for post-undergrad jobs on-and-off for a few months now, and I just recently hit a point where I began talking to three companies seriously about employment.

Eventually, it was clear to me that one would be the best fit. I accepted an offer from the one and sent the other two an email letting them know of my choice. An employee of one of the two companies, someone I particularly liked throughout the process, emailed me back, asking why I had accepted an offer from the other company over his.

I thought about it a while and decided that a detailed response was in order; after all, that company had invested hundreds of dollars in me simply by way of interviewing me for a few hours. After finishing my response, which ended up being far longer than I expected, I thought that it might be helpful to other employers trying to recruit software developers, so I’ve decided to post it here with the proper redactions.

I’ll refer to this guy’s company (the one I ended up not working for) as Company X, and the company from whom I accepted a job as Company Y.

The response

Hey, xxx.

Speaking frankly, it wasn’t the quantitative aspects of the other offer that were so appealing, but rather the atmosphere and the sense of culture that I got from interviewing with the other company. As I said, I was very interested in your company, but here are a few aspects that reflected relatively favorably on the other firm.

  • Emphasis and usage of Unix: this was a big one for me. The other firm develops on MacOS X (a variant of BSD) and deploys to Linux. They made it clear that I would be working in and on both platforms, and expected that I have a working knowledge of the two. Since I’m a CS major (we tend to steep ourselves in Unix and its philosophies), this was a very good sign. It’s difficult to articulate (though you may know full well what I’m talking about), but Unix encapsulates, and indeed was built on, many core principles of good software design, e.g. orthogonality and good use of abstraction. Its use encourages a solid workflow, exposes a robust tool-chain, and promotes the use of the same design principles that make it so good.

    It may seem arbitrary, but the platform an organization uses is indicative to me of a whole lot. I really wanted to be part of a team that appreciates the same design philosophies and procedures that I’ve come to accept as favorable; widespread usage of Unix indicates such a team. Talking to your company, it seemed to me that most of your development happens on Windows (though it’s almost needless to say that you deploy to Linux). This fact in itself was a big part of my decision; I prefer not developing on Windows.

  • The interview process at the other firm was more fluid. Interviews themselves were more conversations than explicit tests, despite being considerably technical. For my first round of interviews at your company, chatting with you upfront was very pleasant, but then [employee of your company] came in and drilled me with some pretty intimidating CS puzzles. The efficacy of such puzzles in determining good candidates is pretty hotly debated, but either way the immediate submersion into such puzzles was like jumping into frigid water, and left me slightly shaken and discouraged, despite the fact that I am confident in both my theoretical and practical ability as a developer. The interviews I had with [employee of your company] and [employee of your company] afterwards were very pleasant because I felt that we were having a discussion as opposed to administering a test.

    Of course, you’re hiring developers: the nature of the position is highly technical and I can understand that an interviewer would want to verify that a candidate can actually crank out some correct code. The other firm, though, administered two phone interviews before bringing me in for what they called a “technical challenge.” The second phone interview was a chat between me and two other developers and basically amounted to a relaxed conversation about some of the technology I was familiar with, some of the projects I had worked on, and some of the problems I had encountered. They would edge into technical details by asking me questions about things that we had established a context for, like some of my previous work, which felt far more natural than posing a textbook problem to me without any relevant introduction. Instead of “reverse this string,” they asked questions like, “why’d you use this library instead of this one?” or “why this design pattern as opposed to this other? Can you explain the benefits and drawbacks?”

    Their technical challenge was far more open-ended than the puzzles that [employee of your company] proctored; this resulted in interesting conversations about the choices I had made and led to more deeply-technical questions about implementation details. Ultimately, I felt that I had better displayed my strengths in that sort of an interview; I certainly got to know [Company Y’s] developers better that way.

  • The other firm seemed more up-to-date with technology. Throughout the interviews, we talked about things like memcached, nginx, node.js, jQuery, varnish, CDN, and Amazon Web Services. To a developer who strives to stay up on the latest-and-greatest, this was a really good sign. The opportunity to learn about and play with such new and interesting technology was really attractive to me. I don’t think any of these pieces of software ever came up in [Company X’s] interviews.

I hope this enumeration doesn’t make it seem like the interview process at [Company X] scared me away; it certainly didn’t. I really enjoyed the case analyses that I did with the non-developers, problem solving with you, and, as I said, the technical interview with [employee at your company] was a pleasure. I’ve just tried to highlight some of the points that I found unattractive relative to the other company. I hope this helps.