Once you’ve sent out resumes, you’ll hopefully get a few people interested in phone screening you. You’re really best off if you prepare for these and for the in-person interview. Get a relevant textbook and start reading it in the evenings or on your lunch break. People seem to love algorithms questions, so get a copy of The Algorithm Design Manual
The phone screen is for them to decide whether or not to bring you in for an in-person interview, and you want to help them with that decision. So you’ll spend most of your time answering their questions. You should ask a few questions of your own, but don’t spend more than 5 or 10 minutes on that.
However, once you hear that you passed the phone screen, you should do a reverse phone screen: before you schedule the in-person interview, ask to talk to the person who will be your manager if you join. Or you could ask for a tech lead, if you those are the sorts of issues that you care more about. For managers, my favourite questions are:
- What’s your management philosophy? This is so open ended that it can be hit or miss, but with the right person it can be really insightful. Plus it gets them thinking, which will help them answer the later questions. Then ask What’s company X’s management philosophy? as an individual’s style may not represent the culture of the company as a whole. Some good follow up questions are What management books would you recommend? What do you like & don’t like about each one?
- How do you figure out what to promise to the customer and when to promise it? There’s a sad truth about software process: It’s impossible to estimate exactly how long a feature will take to build. Even half way through the project, most organizations are off by up to a factor of 4. So, if they promise a fixed set of features on a fixed date more than a month or two away, you’ll probably end up being stressed and working crazy hours to deliver, and then the deadline will be pushed back anyway.
- Do you use an Agile development process? Why or why not? What specific processes do you use? Whether you like Agile or not, you should know what you’re getting into. Also, it’s amazing how many people say “yes we do [insert buzzword here]” but when you question them on it, they don’t understand it at all. I had the CTO of a 500 person company tell me they didn’t use Scrum because it was a heavyweight process involving Gantt charts.
- When an urgent task is supposed to take two days for a task, and half way through the second day the developer says “I don’t think I can finish it today,” how do you respond? I’ve been in this situation and had my boss just look at me, with a serious look on his face, and say “It has to be done today.” So now it still isn’t going to be done today, but its somehow my fault.
- When a developer is working hard but not getting far, how do you notice? It’s actually quite tricky to know how productive a developer is. Some developers pile on the quick hacks, so it looks like they’re making lots of progress. On closer inspection, their code is full of bugs, and incredibly difficult to understand, debug or extend. If you don’t have design reviews, code reviews, and/or QA from the start, this can slip by until you think you’re almost ready to ship. Other developers keep up on the latest technologies, and are able to say “this is a known problem, let’s use X for it rather than inventing our own version of it.” But more directly, if you don’t have a detailed schedule, then you don’t know whether you’re behind schedule. So dig into it. When do they do QA? Who looks over the check ins? What about people who don’t just code up the first thing that comes to mind, but spend a little time looking for a better way?
- Once you notice, what do you do?
- Here are three developer personalities from a post on Reddit. I think they do a great job of describing personalities I’ve seen. What role, if any, would they have in your company?
Coder: values velocity. Wants to “produce code” and “get things done.” They are proud of working hard, staying late, generating thousands of lines of code, and of knowing dozens of obscure APIs by heart because they type them in all the time. They’re great on anything that’s a clown fight of interacting APIs, like LAMP stacks or AJAX apps. However, they won’t produce a memory allocator that you’d want to use as anything but a prank.
Programmer: values correctness. Wants to “solve problems” and “do it right.” They are proud of working efficiently, being caught up enough that they don’t have to stay late, and deleting code. They’re good at algorithmic code like a memory allocator.
Researcher: values knowledge. Wants to “find problems” and “publish.” They are proud of producing new knowledge, and sharing it. They don’t stay late at all.
Also, what do their career paths look like?
- What’s the right level of pressure for your developers? In other words, should projects be slightly under staffed? Should deadlines be aggressive?
- In practice, how many hours a week do people typically work? You can ask this near the end of the interview, although hopefully not as the last thing. Asking it earlier may make it seem like you care more about leaving on time then on getting the job done.
- Can you give me an example of someone under you who has worked to improve their skills? For example learning new software, going to conferences, etc. What’s the right amount of time for someone to spend improving their skills?
- Do you do anything to explicitly identify “best practices”? Do you adopt best practices from outside your company? Can you give me an example of a practice or two you’ve adopted? You want to see if they learn from their mistakes, and the mistakes of others.
- What’s the best and worst thing about working at X? Both the best and worst are worth paying attention to.
For a tech lead, see the list of questions in my next post, about the in-person interview.
The big advantage of the reverse phone screen is that it’s quick. No one will miss you if you’re not at your desk for an hour, so you can do a lot of them. In-person interviews are half a day to a full day, so you have to take some PTO time for them. By doing reverse phone screens, you can consider many more companies than you normally would.
Martin C. Martin 
Excellent list! The only thing I’d note is that the reverse phone screen is subject to reverse bullshitting. Let’s look at the bullshitting involved in a “forward” interview: you’ll sometimes get, “Name for me a time when you faced a conflict at work. What did you do?”
Now, everyone knows the game that’s being played here. Potential employees are expected to give an answer like, “Well, X happened, AND THAT WAS BAD. But then I used my MASSIVE LEADERSHIP SKILLS to solve the problem, so it ALL WORKED OUT FINE IN THE END.” It’s such a game with such well-known answers that I hope no one asks it anymore.
We’re lucky in software: we can ask applicants to solve actual coding problems. It’s not a panacea, but answers are harder to fake than the standard HR question. I was recently asked to debug a problem: “Recently, here at [company X], I ran into a problem that looked like this. How would you start debugging it?” I reply, “Well, I’d look at Y.” He replies, “I did that. Turns out Y was not the problem.” And so forth. Hard to fake.
I’m concerned that management knows all the things they’re supposed to say. “We’re into agile development.” “We believe in transparency in all things.” “All that matters to us is that you get your work done.” *Sometimes* you can see that they’re lying — e.g., your example of the manager who didn’t understand what “agile” meant. In general, that’s an example to me of what interviews — forward or reverse — are really good for: filtering OUT people who don’t know what they’re talking about, rather than filtering IN good candidates.
I am extraordinarily happy with my current company. I knew right away, as soon as I walked in the door, that it was a great place: there was a lot of *energy* in the room; it was buzzing. Contrast this with a former job: a very experienced, brilliant software developer toured the building with me, and noticed that no one was happy. He took the measure of the place very quickly. And he was right. That same developer had taken a job some years before at a startup that was in stealth mode — so stealthy that they couldn’t even tell potential employees what they’d be working on. Under those circumstances, applicants had to judge the company entirely on the basis of how enjoyable their future coworkers and managers would be. Turns out that this company’s managers were brilliant and fun and cool; my friend took the job and worked there for ten years.
I guess what I’m getting at is that, unfortunately for us, there may be no good quantitative or deterministic way to get a read on managers. As much as I hate to resort to gut instinct, there’s a lot to be said for it in this case. Every other method seems easy to fake.
Over the past year I have interviewed a lot of folks. We hired two. If somebody gave me a call back and asked whether we use Agile practices, I would have to confess that we don’t. Now I wonder whether that would disqualify us from hiring the good ones.
Hey Steve,
Yes, there’s certainly a potential for that, and the questions above could certainly be improved. Discussing specifics can help a bit, e.g. prefer “what happens when a 2 day task isn’t done in 2 days?” to “what do you do when a project is late.”
But it’s still hard. One thing you can get is a sense for what they think the “right” answer is. In a startup, it’s often “work like crazy, speed wins, we’re alergic to process.” That will cloud the answers they give you, because they think it’s the right way to run a startup.
Maintenance Man, for me it’s not just whether you use Agile, but more about, are you smart about what you promise so you don’t paint yourself in a corner? Are you smart about how you motivate people to get the most out of them?
So not doing Agile is just the start of the conversation. As long as you can say how you come up with schedules, how you promise things to customers, how you learn from mistakes, etc., it doesn’t need to have a name.
At least that’s for me; for others, I’m sure NOT having any process would make them happy!
Pingback: Big list of FAQ for programmers from Reddit Programming: I’m job interviewing and need a bunch of resources « Salt in Your Coffee
Reblogged this on titifoti.