Avoid using "It depends"

I'm writing this as someone that says "It depends" occasionally so don't take the below as stop saying it entirely. I think people need to avoid most of its uses.

When someone utters "It depends" in the lowest stakes situations, I end up slightly more skeptical than if they simply stated the approach they'd like to take. Or perhaps if they had just shown me their "hot take".

"It depends" finds its way to lots of places. In interviews, in the most innocuous conversations, and almost always doing no good but prolong a discussion.

It's supposed to add nuance and perspective but it rarely does.

A lot of people use "It depends" as a badge of seniority but very few times have I found peopole use it well.

When I see people over use the argument my advice is always the same: replace "It depends" with a curiosity based question. Often times this advice is delivered as questions. I try to get the person to realise that they would be better off by asking the right questions. Other times, and if I'm quite comfortable with the person I'm speaking with, I'll just blurt out a "It depends, and ..." and allow the person to fill the silence.

Someone asks you if you would use Redis or PostgreSQL? Don't just state "It depends". Ask instead:
  • What's the problem you're trying to solve?
  • Is security of the data a concern?
  • Is the data ephemeral?
  • What are the constraints you can't change or affect?
If I'm interviewing, I'm usually more understanding of getting back a "It depends" but my advice is also to not use it.

But if you are the interviewee, avoid the "It depends". Try the questions above (or others) and you'll realise they work better than throwing a "It depends".

Very bluntly, if you're a Senior Engineer or higher, I expect you to understand already that systems, organisations, processes, and people are all complex, and that your answer depends on many factors. Therefore "It depends" adds nothing but point out the obvious.

Instead, and as mentioned above, ask questions to clarify how you're going to answer or how you're going to zero in on the best solution. Or at least to get a good understanding of the problem so that you're able to break it down effectively and efficiently.

~ fin ~