| « Part 1: Slow and Steady | Building what’s in front of you » |
We’ve all been there before: we’re sitting across the table from someone, who is interviewing us for a new position. We’re getting close and we know it because the conversation shifts from talk of “…if you come on board…” to “…when you come on board…” And suddenly you have a thought that strikes fear into the core of your heart: what kind of code base am I getting myself into?
The truth is that nobody is ever going to volunteer that their code base is a complete mess (I’ve had it happen maybe once), and short of asking to see the code before you start, you’re not going to really know what it’s like until you dig in. Many if not most companies would be reluctant to open their code base to an outsider, so how will you know in advance?
There are three things you can do to get a sense for how the code is organized and maintained.
Most interviews leave time at the end for candidate questions. If yours does not, it’s time to pack it up and leave, because that job isn’t really for you.
Carefully questioning your interviewer about their coding practices is a good starting point for gaining insight into whether or not the code is a walking disaster before you start.
For example, does the company apply the Joel Test? A company that doesn’t score 9/12 on this test probably isn’t a place that values its developers in the first place, and isn’t a place you’ll want to work. Ask about continuous integration, test coverage, deployment process, and more. Do so with openness and willingness to hear the answers. Don’t cringe when you get a “no, we don’t do that.”
Occasionally you’ll get a manager that “gets it”, and says “Well, right now we don’t do continuous integration because our code base is so bad. But we’re working on improving it so we can get there.” You should be cautiously optimistic at this point. Ask yourself if you want to be responsible for getting them there or not, and whether or not they’re actually making progress, or just paying lip service to the idea. You can usually suss out the former or the latter by asking a multitude of people in the interview process the same set of questions about CI, CD, testing, quality, the Joel Test, and more.
Your interviewer will give away a lot about the code and the team through the process of questioning you. For example, an interviewer who is unprepared, new at the task, or just curious, will ask you things that relate to what’s happening within the company or the team.
I was once asked by an interviewer how I handled strong personalities with big opinions. That told me the team had a lot of conflict. I was asked once whether or not I believed shipping was more important than code quality. That told me the manager I was talking with believed one of those things was more important than the other (you can guess which one). Listening carefully and reading between the lines can help you to determine what an interviewer is saying to you without them actually saying it. And it can provide invaluable information in the interview process.
Even if you get an experienced interviewer who keeps the majority of the focus on you and your experiences, certain details will leak out and you’ll want to pick up on them. They’ll divulge information like how fast the company is growing or how their deployment process is broken. I once had an interviewer ask me what I’d do if the deployment process broke down every week; I didn’t take the job.
Many if not most interviews are happening via Zoom or other video conferences these days, but some still happen in person. When that happens, take advantage and keep your ears open in office to what’s going on.
When I worked at Mozilla we would do team lunches for some candidates, and of course some of our work was talked about over the table (Mozilla was open anyway, so it’s not like we had a lot of secrets to keep). But those lunches leaked information to the candidates about how the team worked and what our software looked like.
If you’re invited out to lunch or drinks with the team I say, go for it. Learn what you can by mingling when they all let their hair down. Get a sense for the team dynamic and talk a little bit about work.
Even if you’re never invited out of the office, you can still learn by listening. For example, your manager interviewer might be interrupted with a question; listen carefully to the discussion. Gather your intelligence. You might even consider being “impertinent” and asking what the conversation was about if it seemed problematic to you.
Joining a new team can be stressful, and it can be hard to know exactly what you’re walking into. Gathering intelligence and using that information to your advantage in the interview process will pay dividends in the future. I’ve turned down jobs at companies where friends worked because I didn’t want to adopt their technical problems as my own and in most cases I’ve been proved right. You can take advantage of your senses and learn about what kind of challenges an organization has. Interviews are two-way streets; take advantage of your side of the equation.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 7/22/2019 at 1:56 pm
There are currently no comments.
| « Part 1: Slow and Steady | Building what’s in front of you » |