Question: Tell me about a time you had to push back on a customer request.
Answer: Build firewall gateways with different policies. Internal bug tracker, and also customer bug tracker. Once I got a bug about FTP upload, which stops under certain configurations, and the bug report included the build and platform details. Each customer has their own platform, and we have hundreds of customers like this.

Figured out that the customer is using a specific FTP client/server. The configuration was weird, in that it cuts the bandwidth in half after a certain amount of data is transferred. So upload speed gets cut in half.

Our service is a proxy between client and server. The customer asked why. I looked at it, and saw that we actually have a high speed from client to proxy, but from proxy to server was slow. I saw the data was being buffered at the proxy. I deduced that the configuration at the server was the cause.

I responded in the bug report, that the config was the cause, and that this was causing timeouts at the server. I suggested that they can either change the config or use policy shaping. They went with the former because it is easier to do.

Analysis

Competency asserted: Customer Obsession
Job title: Software Development Engineer (SDE II)
Interviewer role: Software Development Manager (SDM III)

Vote: Mixed

I asked The candidate about a time he had to push back on a customer request, and while his story wasn’t bad per se, it also didn’t really answer the question.

He received a bug report about a customer’s FTP client timing out. When he looked into it, he found that his company’s proxy between the client and the server was queuing up packets because the server was unable to receive data at pace. This was due to a server-side configuration that halved the upload speed once received a certain amount of data.

The candidate recognised that this wasn’t a bug, and recommended that the customer change their server configuration, which they did, and were happy with.

The only reason for the mixed rating here is that while I think the candidate did the right thing, this was a very straightforward troubleshooting exercise that doesn’t show any particular strength. It was at the SDE I level, at best due to it not having the complexity/ambiguity I’d expect to see at SDE II.

Learnings

Repeat the question out loud to make sure you understood it correctly. Pay attention to your interview’s body language and clues. Let your interviewer the opportunity to stop you and get you back on what matters, don’t be a talking head.

Leave a Reply