Who is your ideal candidate for this role?
I really like this question because it gives you a better idea of what is expected of you, by framing it in a new way. If your interviewer(s) could create a person out of thin air to fill this role, who would that person be? Sometimes they will describe you to a T and other times you’ll hear a lot that doesn’t align with your background / skills / preferences. It’s a good way to see if you’d be a good fit at the company.
For instance, one company said they wanted someone who “doesn’t need a lot of help”. To me, that’s a red flag. Anyone coming into a new code base needs help to understand the business logic, even if they’re experts in the tech the code is built on. Developers who are hostile to a learning environment are a big turn-off for me.
What are the biggest challenges for this role?
The answer to this questions depends very much on what you’ll be doing. In all cases, it’s a great way to see behind some of the sunny information you’ll get from the rest of your chat. Pay close attention to what they think will be difficult in this role, and evaluate if you’re the right person to meet those challenges.
Who sets the vision for this company?
I’m looking here for the long-term plan, and hopefully to talk some about goals for growth. The only answer that strikes me as a red flag is if they don’t know how to answer the question. “The founder” seems like a fine answer for me for a small company, and “the board” and “management” as you get into larger companies. Major bonuses if everyone feels that they have input into creating a larger vision and roadmap. Blank stares would be bad here — you want to work at a company that knows where it’s going.
How do you measure the success of the development team / individuals / the company?
Again, a process question. I want to know how my work and my team’s work will be evaluated. If they have trouble with this one, I switch it around and ask how they know if they’ve done a bad job. In my opinion, if there’s no way to know if you’ve done well, but they’re clear about what “messing up” looks like, that’s a red flag. How can you be successful at your job if you don’t know what being successful looks like?
What is the most enjoyable / frustrating thing about working here?
This question is great to re-use on multiple people. Ask it as two questions, back-to-back (I prefer asking the positive one first). You’ll often see patterns come up — everyone is annoyed about the same things. Getting people to talk about a negative is always hard in interviews, but I find this one is difficult for people to side-step.
They probably won’t tell you the big systemic problems of the company (they might) but at least you’ll get a feel for some of the process / personality / bureaucracy challenges of working there
Describe the code review process.
The answer to this one tends to be fairly short — they do PRs, a colleague reviews on GitHub / wherever. Dig a little further to find out what kinds of reviews, the average time to merge after submission, etc. Are they going to be super nit-picky about everything? Let massive errors through? Do they actually care or are they just showing off their own knowledge? What about testing? How often do they release?
How does an idea go from “out in the world” into the backlog and finally to code and production — walk me through your feature development process.
I want to know where new ideas come from. Are they looking at the data and then building based on an informed worldview? Or does the founder get an idea and then everyone jumps to meet his expectations?
This question is a lot like the “vision” one, and can be asked as a follow-up. Once you have the vision, how does an actual feature get described and then coded? I consider this the closest to “what is it like to work here?” without needing to ask in those words and get a trite answer.
Explain a technical challenge you’ve recently faced.
If they struggle with the question above, this one should be easier — I’m asking for a concrete example of recent work they’ve done. Was there collaboration among team members or did one person just figure it out themselves? Were external resources brought in? Was the feature dropped? Again, this question is good for getting an idea of the day-to-day operations.
Bonus: What are the plans for onboarding new hires? How do you incorporate new developers into the team?
I consider this one fairly low-priority unless you are junior. Juniors should be looking for significant plans for onboarding and even training. Mediors and seniors can ask this question to see if they have an answer. I’d like to know that they have considered what it is like for new developers to start. Have they thought about how to make the transition into the company easier? It’s not necessarily a deal-breaker if they haven’t — because lots of companies have not.
Are there any internal politics I need to watch out for?
In a bigger company, they can put this on “sales” and let you know that they are the gods around here and not to piss them off. In a smaller company, they are liable to tell you there are no problems. What you’re going for is some first-day-on-the-job knowledge — who actually calls the shots? Is there a project on the table that some people think is not worth doing but others love? If they’re willing to give up a little dirt here, it can help you in your first weeks. It also shows that you care about fitting into the company and properly negotiating all the personalities floating around.
“What’s your current salary?” is a trap question—Here’s how to answer it
“I just need to be sure the salary range works for your requirements so we don’t waste each other’s time.”
Nobody likes wasting time, and you especially don’t want to waste someone’s time when they might be the gatekeeper for a great job opportunity, right? So you’re inclined to just give them what they need so and get on with the interviews.
But instead, I recommend a little conversational Judo—use the reason they gave for asking again as your own leverage. Here’s how:
“It sounds like you’re trying to qualify me for a salary range. If you want to tell me what that range is, I’m happy to tell you if it’s in the ballpark.”
They claim they need to qualify you for a range, but they are also asking you to give up one of your precious pieces of information to do that. Instead, just ask them for the range.
The nice thing about the way I’ve worded this script is that you’re still not actually committing to accepting an offer in that range. You’re saying it’s “in the ballpark”. This matters because you still have full latitude to negotiate later on once they finally make you an offer.
.. There aren’t many options left, but this one is very effective. Here we go:
“I’m not comfortable sharing my current employer’s proprietary information about how they pay people, and I know they wouldn’t appreciate it if I did. I still work for them, and I’m just not comfortable sharing that information. I really don’t have a specific number in mind for a desired salary, and I look forward to hearing what you suggest.”
This is a heavy-handed answer, but it’s necessary because of the situation. You’re basically saying, “I have ethical qualms with giving you the information you’re demanding.” This has the advantage of putting the pressure back on the recruiter, who now has a clear Catch-22 if they continue to press: They’re asking you do something you see as unethical to move forward, but they probably don’t want to hire someone unethical.