How to talk about yourself in a developer interview

As someone on the hiring side of the table, I rarely care about how technically complicated it was and more about WHY it was hard, how you figured it out, and how you avoided it in the future. I've made some really dumb typos in my code that caused a debugging nightmare for me in finding them.

As a recent example, in my game engine I copy/pasted some code for framebuffer and texture creation and missed renaming one variable. A stupid mistake that took me 2 days to find. But to solve it, I needed to look at all of the various textures on-screen. Some of them are non-linear, some are single component (just red) which doesn't display well, so I ended up writing a method that allowed me to render all of the various stages of my renderer out to the screen (color, shadow, light, depth, normals, etc.) as a debug method. Only then did I realize that the shadow buffer texture was sized to width * width instead of width * height. Again, a stupid mistake, but now we've got something to dig into a talk about and it's much more about the solution than the problem.

This feels pretty pessimistic to me. A "professional" (and I only half-mean the scare quotes, I think I am one) is able to often do some pretty transformative stuff that's worth being proud of while not setting off The Bomb. I can truthfully and accurately say that I reduced one employer's deployment time of their services from six hours to six minutes with no loss of safety or increased risk--I hacked through an accretion of technical debt (after building out testing to ensure that I didn't change any functionality) that had just plain grown because nobody else had had time to pull it out and replace it with a more scalable, long-term solution! I'm pretty proud of that. And two orders of magnitude on a deploy will wow folks who've ever been personally faced with the bigger one.

(One of the other ones I'm more amused than proud of, though, is saving a client ten times the money they paid me because I happened to know about the existence of AWS D2 instances...)

Your concluding point is well-taken, though, because most people don't know how to interview and they're basically asking you to sell yourself for them. But I don't think the question is as problematic under the hood as you're framing it.

To be a good engineer requires a number of skills. You named one. Knowing what arbitrary conclusion a random interviewer wants to hear and will draw is not one of those.

You can be a great communicator AND frequently not answer this question in a way that an interviewer wants to hear. There are more excuses for bad interview practices than anything else here.

People vastly overestimate their ability to detect lying and shouldn't rely on that. How do you know when someone fooled you? You don't. Why risk that when there are alternative and better methods?

Many engineers don't realize they are self-rationalizing their own interview process without any rigorous evidence. This is the opposite of good engineering.

I'm not a developer, so my answers are different, but I've got a handful:

- Consulting for a customer where they were deploying to new hardware with a new processor architecture, I received a report that an application was running slower on the new servers than it was on the old ones. I started out looking at things with strace and ltrace, had to move deeper and pull out perf and systemtap, but found that it looked like memory access was slower than on the old hardware. I did research on the processor, and found that it was due to the 'Intel Scalable Memory Buffers'. Since memory first had to be loaded into the buffer before the CPU could access it, things not in the buffer already had higher latency, but things already in the buffer were much more quickly accessed than they would have been previously. I worked with the developers to make up for this performance decrease in other ways. Their application was well suited for using hugepages, but they were not, and TLB pressure was causing performance bottlenecks in other areas. Switching to hugepages prevented TLB pressure, and the application ended up being even more performant on the new platform due to the increased amount of available memory allowing for a large amount of hugepage allocations.

- I was consulting for a customer that was running instances on a xen platform. They were having performance issues vs. their old bare metal deployment, and had already done some analysis. They gave me a perf report that was showing a massive amount of time being spent with a specific xen hypercall. I had to dig into the xen source code to figure out exactly what that hypercall was doing, as general public documentation about it was somewhat vague. I was able to determine that it bundled up a bunch of different operations, so it wasn't conclusive from that, but it did narrow down the possibilities. It was enough to point me in the right direction, however, and I was able to determine with a little bit of trial and error with some tweaking that it was ultimately related to decisions NUMA was making. It turned out that the customer had thought they were doing NUMA node pinning, and ultimately weren't. Interestingly enough, even with pinning, we still saw some of this, and completely disabling NUMA (all the way - not just balancing) actually ended up being needed to fully reclaim the lost performance. I also learned an important lesson in trusting customers - even the ones that know what they're doing aren't always right, and while I should trust them in general, verifying their answers is important. I discounted investigating NUMA as early on they told me they had their applications pinned to nodes, and I would have otherwise investigated that more quickly and probably solved the issue in less time.

What percentage of bad hires result from your approach vs. other approaches you've tried that have failed? If you even did know that, how is this not randomness in a small sample?

This ignores the problem that if someone can elaborate, it's not necessarily an indicator. It can just mean that someone can BS well. Relaying too many specific details can actually be an indicator that someone is not telling the truth.

"Getting people talking" is really the only way you can identify these things during an interview. And this is not the same as telling a good story. And now you have to demonstrate that this results in job performance.

On here, tptacek has exhaustively described an alternative approach: https://news.ycombinator.com/item?id=9159557