Nailing the ‘Technical’ Part of the Interview

Having interviewed tens of times with companies ranging from tiny startups to large enterprises, I still get most nervous about the technical portion of the interview. That’s because I come from a non technical background. To pile onto the anxiety, no two companies I’ve interviewed with have had the same expectations for the depth of my technical knowledge.

So what’s a rule of thumb for how to think about it? You need to know enough to minimize suffering for the engineering team and be effective in understanding the ROI of investments. Specifically,

  • the cost that goes into it
  • decisions that affect speed
  • decisions that affect quality

Here’s an overview of all the concepts that will make you an effective technical counterpart for both the business and your engineering counterparts:

  • Pace of development to test worth with customers
  • Acronym: QCAE
    • Quality, reliability, functionality and performance as it directly impacts the user experience
      • Requires extra code, process, monitoring, diagnostics
    • Code cleanliness
      • Refactoring
      • Simplicity of coding; aka speed
    • Architecture
      • Cost of development
      • Cost of hardware
      • Scalability
    • Existing code
      • APIs
about author

Patricia

 

Patricia is a product manager based in Seattle. One of her many missions is to help enable aspiring or existing product managers without a technical background to feel confident in their technical competence when landing and performing a product role. Outside of that she's a personal finance, real estate, and fitness fanatic.

2 Comments on "Nailing the ‘Technical’ Part of the Interview"

Leave a Reply

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