The Core Pillar That Drives Technologists

This article is about putting labels on people. If you’re a technologist – a nerd at heart – I’m going to put you into one of three categories. I’ll call them D, T, and P. I’ll explain what they are in the end.

D’s like beautiful code. They love complex algorithms, elegant systems, clever hacks. They thrive on discussing design patterns, threading, synchronization. They care about HOW something is built. They don’t care what the thing is – a microcontroller in the pacemaker that saves lives or a mission control system in a nuclear weapon.

P’s don’t give a crap about how something is built. They care about the customer’s pain. They almost *feel* this pain themselves, and this empathy drives every action they take. They want that pain to go away. They want the double entry to disappear. Seeing the “OH MY GOD THIS IS AMAZING!” expression in customer’s eyes is the ultimate goal for them. P’s don’t care if the way this was achieved was through copy-pasting the same stupid code snippet thirty times, creating an unmaintainable, ugly piece of code.

T’s like breaking things. From their early age, they found satisfaction – true, internal pleasure – in pushing the boundaries of our everyday objects. Any creative person might give you dozens of ways to use a paper clip in a few minutes. T’s will tell you how to break a paper clip –  and it will be quite a natural mental exploration for them. T’s just feel so snug inside when they can look at a piece of someone else’s work, and find a way to make it do unexpected things. T’s have a drive to prove their mental superiority over the creator of the product.

Fine, fine, this wasn’t a difficult puzzle. D’s are developers. P’s are PM’s, product managers (Microsoft calls them “Program Managers”). T’s are testers.

Here’s why understanding these core pillars might be useful: when you know what should drive a successful person in this role, you can interview for it.

Test. Don’t ask them whether they’ve written automation before. Ask them to list 50 ways to break an elevator.

Dev. Don’t ask a Dev whether what the difference between ShowDialog() and DialogBox() is. That trivia can be looked up in 30 seconds or less. Ask them a basic algorithmic question; ask them to code it in any language of their choice.

PM. Interview for empathy, and the ability to convert that empathy into designs. Ask them to design an ATM for a 5-year-old kid. Ask them to design a remote-control system for window blinds.

P.S. If you didn’t guess from the rest of this blog yet, I’m very much a PM. Most of the code I write is quite crappy – it’s a means to an end.

Join the Conversation


  1. Alex, great post. One comment, though – coding a standard tree traversal algorithm in every interview gets really old really fast. What D’s should be interviewed for is ability to grasp what P’s are envisioning, getting it designed and implemented using the right technologies. The rest are technical details that can be looked up and learned. Badly designed system that does not fit customer needs won’t work no matter how beautiful the code is. What matters is beautiful software, not so much the beautiful code – as you said, good Devs will take care of that part no matter what they write.

      1. My favorite questions revolve around designing systems based on vague set of requirements (as it is in life). For example an airline ticketing system, a toll collecting system, etc. pretending you are a PM or The Customer. Going through these right there on whiteboard provides a great insight into how people think in terms of use cases, system architecture and software design vs. just implementation details. Also, when I interview, I always go down to the next more detailed level and ask people to compare and contrast technology approaches to things. For example, asking a potential Web site developer about ASP.NET session state management modes allows me to see whether or no he/she understands the basics of the technology in which he/she claims to have experience. Most importantly, I need to know if a person can make the right choice (many fail right there). Overall, I am always trying to evaluate whether or not a candidate has a sound technical foundation to help me build my product and only then start to focus on specific knowledge areas (e.g. tree traversal algorithm). I have a great deal of respect for Devs that can deliver both sound design and great implementation and I don’t particularly care for one or the other in isolation :))

        1. Fascinating. Very much makes sense. Here’s one possible pitfall, though: how do you know that you aren’t hiring an architecture astronaut? That the guy can actually code, not just speak about the technologies involved?

  2. I do ask coding questions, in the context of the larger problem we are solving on the board. For example, when they start talking about the models and the views, I ask them to design and code event-based publish/subscribe component I can use in these views. When they design something that has to do data processing, I ask them to code chain of responsibility in the data processing pipeline… But never to traverse a damn tree.

  3. Dude, asking to code how to traverse a tree, reverse a linked list, etc… are perfect first Dev interview question. It directly gives you a feel of:
    – Whether the candidate studied (if he can spit it out in 10 seconds, you know he studied before the interview, which is in itself a good sign)
    – Wheter the candidate can code trivial things (which will be his job 90% of the time)
    – If he tries to do something overly complex for a trivial problem like this, you already know what kind of coder he will be (the guy who writes 20 lines to produce a solution, or the guy who writes 25 classes with 16 design patterns to do the exact same thing)

    Of course these are nowhere near deciding factors, as everyone mentioned, it’s important to test real-life skills (taking requirements and building something useful with the right tech) but if the guy always takes 10x the time of the other guys to do it, and his code is pure shit, you just don’t want that guy in your team.

    Just a great example; I knew this guy who could code, but wasn’t a very deep kind of coder. At some point he wanted to put the current date/time on a web page (this was on a real job, not an interview). What he did was to invoke “cmd.exe /C date /t” and parse the output. Sure it works, but it shows a lack of desire to learn things (just does what he knows and moves on). That’s the kind of candidate you don’t want.

    You can ask him what tech he would use, and he can give you a good answer; but when it comes to the details, he knows none of them, and doesn’t want to learn any of them. The kind of guy who kills your codebase slowly and creates pains in the asses of everyone else. If you ask him to reverse a linked list/traverse a tree, he will come with the most convoluted solution ever seen and will not be able to use pointers correctly.

    So, should you ask trivial coding questions? I think YES! You want this kind of filters to get rid of weirdos with weird solutions to simple problems. But then you want to move to a bigger more elaborate question as well.

Leave a comment

Your email address will not be published. Required fields are marked *