Many of us have interviewed for jobs and had the potential employer ask something like, “Would you say you are detail-oriented?”
This has always struck me as one of those questions where the asker does not understand what he wants. Saying you are detail-oriented implies that you focus way more on the small things than the big picture. The question implicitly makes it a binary choice: either you are detail-focused or you are the other thing. And the other thing is “big-picture” focused. Nah, I’m all about the details. Or, I’m all about the big picture. If you said either of those, nobody would take you seriously or want to employ you.
In an interview, however, it’s not usually a good idea to remark on the stupidity of a question. Don’t come at an interview as a supplicant begging for crumbs: you are also interviewing the company to see if you want to work there. But don’t be rude either. That’s something I don’t need to tell most people. What’s needed is an answer to the question. Are you detail-oriented? Or, if not an answer exactly, you still need something relevant to say that will help sell you.
As with all such open-ended interview questions, I think the best answer comes in the form of a narrative. And your answer cannot be mine. I’m about to tell you mine, and you could attempt to steal it wholesale, but God help you if they press you for details.
I work at an insurance company, and a large part of what I do is about receiving quote requests from potential customers and collecting the appropriate information to see what limit options we are willing to offer that customer and, of course, at what price. We are working on rolling out a software upgrade. I have been working on my small corner of this rollout for months.
Today, I decided to pay special attention to detail. I passed in a request as if I were a customer. This is something software developers do in the real world all the time. It’s an example of a manual test. I fed test data into the program to see what came out. What I found was that if the customer requested a certain insurance limit, $25,000 or higher, our service rejected that request and said they could have the minimum coverage instead, $15,000.
If it was well known that our code always rejected $25,000 and always gave $15,000 instead, that would be an obvious and unmistakeable bug. But that was not an established fact. I just had this one example where it was happening, and for all I knew at the time it was supposed to do that. Sometimes that is the correct thing to do according to our business logic.
In this case, today, I decided to investigate why this was happening and see if it was correct.
Before going on, let me explain why it matters at all. If we refuse a higher coverage limit to a customer even though he wanted to pay for it and we offer him a lower limit instead, then basically we are leaving money on the table. In some cases we may decide that is the best choice because the customer represents too much risk. But the point is that if the customer chose a higher limit than the minimum, he was probably willing to pay a little more for it. The choice of whether to leave that money on the table lies with the business executives. It is good for a software developer to understand the business and its goals. That helps us to make wise choices day-to-day about what tasks deserve our attention. But we don’t actively make business decisions while wearing the software developer hat.
So, I found that at least in this one example case our application was refusing the higher limit and it was not clear to me why we would do that. I investigated. The investigating itself was basically the same thing as any other debugging task. I traced the data on its way through our application until I found the deciding factor that caused our application to reject the higher limit in favor of the default minimum limit.
What I found, buried in code I think nobody had looked at in months, was a break in the flow of information. At one place in the flow, somebody had hard-coded a negative value for a certain piece of data along with a comment, “only used for X”. When written, the code was not operational in X, so this bit of information didn’t matter. However, that is what we are doing now: X. I had never even looked at this bit of code before. Nor would it be easy for someone to find if he was not very familiar with how our application works and able to debug through it and watch the flow of information as it progresses through our application.
The point of all this is that basically on a whim I decided to investigate a small detail that seemed like it might be wrong, but at the time I could not be sure it was wrong. It was not an unmistakable sign. I used specialized knowledge and skills gained on the job, and I found a mistake that would directly affect the bottom line profits of the company if this code went into production and nobody noticed this mistake. Maybe this mistake never would have gone into production. It’s possible that our QA team might have found this error. But I don’t know if they would have, and a developer should not rely on QA that heavily. It’s up to us to deliver code that works.
That is my narrative to tell next time an interviewer asks, “are you detail-oriented”. I’ll shorten it and streamline it so it better hits the high points. The most important things to notice here are these:
- By telling a story instead of answering yes/no, I sidestepped the implicit detailed-oriented/big-picture oriented assumption underlying the question. The question itself is broken. If you say, “I’m detail oriented”, then the interviewer hears, “I cannot see the big picture.” If you say, “I’m big-picture oriented,” then the interviewer hears you say, “I frequently lose track of the small details.” Details are important to achieving the big picture, so that’s not a good thing. At the same time, I didn’t get lost in a tangent about the question itself being nonsense. I just redirected it so I could send the message I wanted to send. I stayed on message, and that message was this:
- I can keep track of details: I noticed that small difference in the expected behavior of our application and I decided to track down the cause. And—this is important—I also see the big picture. In this case, the big picture is that if nobody found this error and it went into production, then it would directly cost the company money. It’s pretty rare that a developer can offer such a direct connection between the work he does and the bottom line profits of a business. This is an example of that.
As you go about your work, I recommend that you occasionally think about what you have been doing at work recently and how you can turn it into a narrative to answer an interview question. In this industry, there’s a good chance you will go looking for another job one day, and these narrative answers to those questions really help sell it.
adamcross.blog 