The Developer Interview Question You Should Always Ask
Interviews are Bidirectional
When we go for a job interview we tend to be deferential and obsequious. We’re there to get a job, for money, for our careers. We try to come across as constructive and bring no negativity to the discussion.
We don’t talk about previous jobs, nor mention that we quit because our managers were jerks and liars. We obediently do whatever the interviewer says; balance a beach ball on our noses, write code on a whiteboard.
And almost nobody realizes that the interview goes both ways; yes they are going to pay you money if they hire you, but on the other hand you are going to spend at least a third of your day, half your waking hours, in their environment. Yes you need a job, yes you need money, but if the company is a man-killer, if the managers are slavers and working there is going to ruin your health, you don’t want to take the job.
Yes they are interviewing you. But you are also interviewing them.
Technical matters are mostly open and shut. These are yes/no, one or zero. You will need to know what tools and technologies you’ll be using and what you will have to learn.
The most important questions are about the work environment. If you are a junior developer you don’t have a lot of leverage and you are likely more desperate than someone with decades of experience and achievement. Will you be able to work uninterrupted? Are work weeks well in excess of forty hours rare and anomalous or are they expected? Are the divisions between developers at a high level or do many developers work in the same files?
Are there a lot of meetings? Are hours flexible or is there a regular morning meeting that requires you to have a tripled commute time?
The Critical Question for a Senior Developer
You have a lot of experience, you have learned a lot. You are coming into an existing project with a large code base. You had better ask this.
“I like what I’ve heard so far, it seems like a good company and an interesting project. But I need to ask about something.
“Suppose you hire me; we’ll have a welcome-in, I’ll learn who’s who and who to go to for questions as I get up to speed. I’ll sit down and get to know the code.
“But as I read I see something alarming; some practice that all my experience tells me is going to lead to trouble, if it hasn’t already. I hope this doesn’t happen, but it has before and I need to know how things will play out. Maybe a dangerous coding practice, maybe a bad database schema, maybe an approach to development that favors clearing one’s task list over doing solid work.
“I call it to the attention of the team. I provide solid technical justification for my concern, I make it clear that this is not merely a difference in preferences.
“OK, here’s my question.
“What is the reaction going to be?
“Will I be regarded as the impertinent “new guy” who has the temerity to tell us how to do our work even though he’s been here less than a fortnight?
“Or will my issue be examined on its technical merits? Will my justifications for the objection be debated? No I wouldn’t insist that everyone drop everything and make changes that in the long run will improve the project but in the short run introduce delays and instabilities.
But will I get a fair hearing? Or will I be seen as a troublemaker?”
Even if working remotely (I last worked onsite in 2010) I need to know this. There have been many cases where I came to regret not asking this question.
Because if you are more experienced than your coworkers, or care more about doing quality work (this approach has markedly diminished in the last twenty years) then it is likely that you will see bad practices and if you don’t want to find yourself out of a job because the company’s shoddy practices allowed others to surpass them and get to market sooner, you will encourage the use of robust practices.
In he early 1990s I worked at a Redmond, WA company making music composition software, when most new PCs didn’t yet have sound cards. The company had a three year lead over others in the same business and had real music notation in addition to the MIDI views used by modern Digital Audio Workstations.
But their code was garbage; the CEO/CTO was preoccupied with low-level optimizations and had no concept of modular programming. He wrote C++ functions over a thousand lines long. He used mid-function returns. Their competition caught up and surpassed them while they were still trying to get atop the bugs in a product getting further from release instead of closer. The company died and the executives were involved with investor lawsuits. All the developers were laid off.