I ended up accepting a part-time research position here at LeTourneau University. I’m also doing some contract iPhone work, and working on my startup. I think this turned out to be the perfect mix of interesting, fun projects that let me work from my room on my own equipment, pay well, and feel really rewarding.
So how did the job search go?
Note: I won’t identify the companies I talk about by name unless they specifically promote themselves as having a unique/positive hiring methodology. I think that’s fair to everyone.
I was really excited about interviewing with these guys. Unfortunately, I was rather disappointed. One phone screen was a no-show, and the other was half an hour late. There was a stack of questions HR forced them to ask that they seemed very disinterested in, and skipped half of them to get to their own questions, which were largely (but not entirely) trivia questions about obscure sorts. The HR rep was (surprisingly) very helpful, and was open and honest throughout the entire process. Google is a very big company, and my sampling size was very small, but I find it hard to shake the impression that they seemed rather interested in things that could be found in any reference book or through their own search engine rather than algorithmic thinking.
Overall, I had the best experience interviewing with these guys. They were very professional, asked great questions, were timely, and very open and honest. My only real complaint is their excessive reliance on the phone interview, which I argue is a few steps removed from actually coding. In the real world, it’s perfectly acceptable to think before you code, but on a phone interview, spinning your wheels for a few minutes is a no-no. They also seemed particularly tied to C, which is a great language, but I got the strong impression that someone with a few years of C would do better in their process than a great hacker with little C experience. Ultimately, though, I think they’ve got quite a bit going for them.
These guys hired a consultant that was incredibly unprofessional. On four separate occasions I was confused with another applicant (I received one e-mail, two phone calls, and almost interviewed as someone else). I was asked to choose an interview timeslot, after which a week would go by before I was informed that the timeslot was now filled. The only reason I continued with the process was because the company’s reputation was very strong and their problem domain was interesting. For anything less than a steller company, I would have moved on the first time I got a mis-addressed e-mail. Think before you let a consultant represent your firm.
This company opened with a written exam, which I blew out of the park (writing, for me, is much closer to coding than talking on the telephone). They followed it up with two phone screens: I did well on the first, but there was so much consultant fail for the second interview that I was a little exasperated and certainly wasn’t on top of my phone-interview game.
I’m an avid Hacker News reader, and YC startups hold a special place in my heart. This company opened with a coding exercise (woot! Actually hiring me based on code I write!). I came up with a decent solution, and included a paragraph of text about why I chose this solution, drawbacks and bottlenecks, and gave some O-notation. They made me an offer on the spot.
Unfortunately, their offer was about half what I made last summer, and about a quarter of what I can make as an iPhone contractor. Plus the cost-of-living differential between SF Bay and where I currently live is huge. So in spite of their awesome office, cool product, and YC-ness, I couldn’t justify taking a huge pay cut and moving across the country.
I learned that my strengths lie much more in coding than talking about code on the phone. I need time to carefully think through my code, and for me, that includes copious amounts of silence. It just doesn’t play well on a phone screen. I’ve got about a 60% pass rate for a very difficult phone screen–so I can get through 1 fine. But when you start compounding the probabilities of two or three phone screens, the chances of me getting through are pretty low. Conversely, my pass rate for people who looked at my code was closer to 90%.
I learned that interview processes are often long and arbitrary, and the longer and more arbitrary it seems, the less likely it is that you’re going to get an offer. I should have bailed on several of them (to recover my time to work on my startup, school, prep for other interviews, etc.) but I kept hoping things would magically change.
UPDATE: Since press time, someone at Fog Creek has indeed taken a close look at my code, ostensibly in reaction to this blog post. If you’re reading this, as I said above, you guys were the best and the most professional, and the fact that you actually poked around in response to a random blog entry from an undergrad only confirms that.
I learned that nobody actually reads your resume. I included several prominent links on my resume to actual websites that I’ve coded, and nobody (NOT ONE PERSON) clicked through the resume links to play with a live site I wrote. There were also click-through links to actual algorithmic code I’ve written that you can download and stare at (novel approaches to classic CS problems) and nobody (NOT ONE PERSON) clicked through to examine what sort of code I actually write, whether or not I document things, etc. That was extremely disappointing, as if I were to hire a coder who included either source or live demos on his resume, the first thing I would do is see, you know, what kind of things he codes.
All in all, I think I ultimately found the right mix of good projects at good pay that give me enough autonomy and flexibility. I’m excited about the things I work on now, which is a good change from schoolwork last semester and the largely-frustrating interview process. And the people that I’m working with are really top-notch.
Comments are closed.
I think the most valuable skill in business you can have is to know what you know and know what you don’t know. It looks like you learned a lot in this area and it will serve you well.
You may be disappointed with your findings that employers do not tend to look at code/resumes. In a team effort, however, good coding skills are not always the most important ingredient in a good employee. When I worked for an internet start up company in Seattle, there was some drama between some of the employees. Drama, visible disagreements between employees, kills the momentum of a project and hurts moral.
If I were an employer, I would hire someone that I followed instructions, had a positive attitude, wanted to work for me, and had decent coding skills. I would also doubt the authorship of any sample code they sent me. I am very surprised that employers don’t read resumes.