Interviewing in Silicon Valley

I spent a fair amount of time interviewing for jobs before landing the one I have now. Sitting in the interviewee chair was a learning experience after many years at the same company—it had been a long time since I was an external candidate. This post might help others sitting on either side of a Silicon Valley interview.

I’m a Software Developer who manages other Software Developers. This is an important point because I was interviewing for management and non-management roles at the companies I visited. I wanted to lead a team with a strong engineering foundation. From my experience, effective teams inevitably grow to require new leaders and I would much rather be an engineer on a strong team that will grow to need (me as) a leader than to come in to lead a weak team. I also wanted to learn how a company hires its engineers as it is a good indicator of their other business practices.

There’s plenty of evidence that a manager can have an unfairly significant influence on a team or company’s culture. Hiring managers should therefore take more time and care than hiring an engineer, but what are the differences in interviewing for either case? Management style is a key indicator of culture fit, which can be the difference between success and disaster. Good interviewers asked questions that invite dialog:

• Did you ever fire anyone? Why/how?
• How do you find/manage poor performers?
• Tell me a success story and a horror story at your last job. (Very telling, but allow enough time for both stories.)
• Describe your management style.

In general, the non-technical questions were a good way to learn about a candidates cultural leanings, but were not necessarily a good way to tell if they’re any good at making software. A few interviewers fell into the trap of using the wrong technical questions to determine fitness for this purpose. There was a wide disparity in the quality of technical questions used at interviews. By quality, I mean the effectiveness of a given technical question in determining a candidate’s ability to contribute to your specific software project.

The answers to most technical interview questions can be found on the web. Interviewers need to assume that, if hired, the candidate will have the Internet at work to solve these kinds of problems. For example, any question with “hash table” as a correct answer should be avoided. Questions that have no relevance to real work are just annoying. Don’t ask for code you won’t use. In my many years as a professional developer, I have never seen a need to reverse a text string in a commercial software product.

It’s much more effective to talk about real technical problems with the project that you’re hiring for. A couple of interesting ones I was asked involved real bugs in the actual product. That was cool for me as the interviewee who learned some real-world problems I’ll encounter if hired, and good for the interviewer who may get a free bug fix in the deal. It also got a good dialog going on diagnosis/debugging techniques.

Use caution with coding exercises. It’s important to remember that programmers don’t formulate solutions alike. A whiteboard coding exercise will not be the best way to predict a programmer’s style when a real editor, compiler and debugger are available. What you’re looking for is the presence or absence of key elements in the algorithm–not the syntax. Don’t come with a coding exercise and expect the code on the whiteboard to look exactly like how you’d do it. In one interview, I was asked to implement a 1-bit run-length encoder. Although 1-bit RLE is an awful compression technique for all but the most basic monochrome bitmaps, it tells you if the candidate can understand loops and bit-operations. I’ve posted my code here, effectively reducing this interview question to another one you can answer with a web browser.

Good luck in your search!