My Non-Traditional Path to Engineering Success
I’ve been in this industry for a long time. If you had asked me 25 years ago if I would have imagined being in my current role in this industry, with the success I’ve had, I’m not sure I would have believed it. At that time I was working as a pharmacy technician, thinking of becoming a pharmacist (and giving that 6-figure pharmacy education requirement a skeptical side-eye), playing bass in the Boston club circuit, and wondering what I was going to do with my life. At the time I had just a smattering of college classes to my name, and no degree.
Getting Started
I eventually took a customer support job with a new electronics company called VideoGuide, taking calls in support of an early iteration of the integrated channel guides we all use today. It was a separate machine, with infrared transmitters hanging off of it to remote control TV and cable boxes. It was cutting edge back in the day, and a nice shift from public, in-person customer service to phone-based customer service.
I quickly got promoted to the technical help desk, and that was my first exposure to programming. The tech support team was busy crafting the company’s first website, and in between calls I played with Unix shell programming and HTML. I realized pretty quickly that I had an acumen for technology, but I did not have a computer science degree, and was not in a position to pursue one. I then spent time working in customer support for technical companies.
A couple of years later, in California, I signed on with a real estate listing service startup called PropertyFirst. The company had just received major funding and was looking to build a technical support team as it rolled out its desktop software. I was hired to be the lead technical support person. I told the hiring manager, and my manager after I started, that I wanted to be an engineer one day, and I’d join them with the understanding that if I wasn’t doing engineering work after a year, I would move on.
The help desk did not have any software or systems. At all. Nothing to manage customer data, nothing to provide information for call resolution. Nothing. On top of that, as a just-funded startup, the engineering team did not have the resources to build it, as they were already overloaded trying to get features out and manage what software they’d launched at that point.
So I wrote it. I cracked books at night, and between every call I took, I wrote software. We need something to look up customer information? I wrote it. We need something to automate a data change? I wrote it. We need reporting on something? I wrote it. The application, called “WorkCenter”, would eventually transition from desktop to web and become a staple of the company’s customer support processes for years.
And after seven months of proving myself, I landed that position on the engineering team, through hard work, intelligence, hustle, and customer obsession. PropertyFirst would merge with LoopNet, and I would eventually make my way up to what would today be a Principal Engineer or Principal Architect. My work directly led to the successful IPO of LoopNet and its eventual acquisition by CoStar Group.
Reason To Degree
I’ve written previously about my college experience at WGU. I’ve recently gone back and enrolled in a standalone class as I consider whether or not I want to pursue my Masters, and I’m not entirely sold on them again. We’ll see how I feel after the class is over.
What’s important here is the motivation for me to get my degree. I was 12 years into my technical career, and 3 years into my management career, and I was at a crossroads where I wasn’t sure what I was going to do next. I thought of a close friend of mine, who started at PropertyFirst when I did, and was also a technical manager at LoopNet. We built amazing things together, and had both advanced to senior technical manager roles at the company after years of service. I came to the realization that if the two of us were up for a position, we were essentially the same person on paper, with one exception: the degree. With WGU now an option so that I could go to class on my own terms, the decision to get my degree became an easy one.
I strongly believe I would not be the person and leader I am today if I had been professionally educated from the start, as too many of my strengths are built from doing the work, not from school. But I also believe that getting the degree led to my opportunity at Amazon, and to where I am now. A circuitous route to be sure, but a successful route to date.
The Consequences
I remember in my early days, as I worked up to positions as a technical leader, constantly battling imposter syndrome as I led meetings with engineers who were all more educated than I was. I spoke the language differently, and I conceptualized technology differently. I had to work hard to earn trust.
We were solving problems with no solutions as well, as we were ahead of technology for features like full text searching. That led to lessons learned and perspectives that didn’t always align with the overall industry. I remember very clearly an interview with an engineer that worked for NASA’s Jet Propulsion Laboratory and was applying for a position at LoopNet. They brought years of education and experience, but were focused on industry patterns and practices documented by Microsoft. We had already bypassed several of those in favor of our own solutions, and the lack of alignment from a technical perspective was palpable during the interview conversation.
It’s taken years for me to become comfortable with what I’ve learned and what I know enough that I feel my technical perspectives have value. My non-traditional, online degree did not necessarily help me with this. The best thing was my experience at Amazon. On my first day someone said to me, “This is the place where smart people come to feel stupid”, and while I never felt stupid, my ability to learn and eventually provide constructive feedback to senior Amazon engineers eventually helped me accept my own perspectives.
I still feel the absence of a full computer science degree on occasion. Recent interview forays into code challenges expose my inability to write a binary search tree or a linked list. It doesn’t mean I can’t problem solve, but I’ve never once in my lifetime had to write something like this, so LeetCode style exercises still frustrate me. There are certainly times at higher levels of scale, where performance becomes critically important, that I sometimes feel I lack historical context, or miss points others might take for granted. I tend to blame the gaps in my education, but in reality that might not be the case. It hasn’t hindered my progress from a practical standpoint, but it does make my imposter syndrome ramp up a bit.
That said, when you combine my unorthodox background with a willingness to learn, a desire to deliver, and a logical and linear problem solving approach, and then put that with all of the early projects I built that resulted in features we would take for granted today, I would argue my unique background has been a key component of my success, not only as a technician, but as someone open to new ideas, to mentoring others who came from similar backgrounds, and to thinking outside the box to solve problems.
A ChatGPT Caricature
There’s been a trend on LinkedIn, where people go to ChatGPT and enter the following prompt.
Create a caricature of me and my job based on everything you know about me.
So, I did it. And this came out.
Yep.
Behavioral Interviews
I’ve had the opportunity to participate in many, many interviews over the course of my career, including over a hundred as an interviewer at Amazon. Over time I’ve developed a perspective on behavioral interviews. Over the past couple of months, as I’ve conducted my job search, I’ve had the chance to be on the other side of the equation with high profile companies such as Meta. That has sharpened my perspective on this interview approach.
About Behavioral Interviews
Behavioral interviews focus on past experiences under the belief that past behavior best predicts future behavior. Candidates provide examples of how they handled real situations. Through conversation, candidates reveal their skills, competencies, how they handle challenges, their approach to teamwork and collaboration, and their problem-solving capabilities.
Questions are typically posed as a variation of “Tell me about a time you did a thing”, and answers are generally expected to be in the STAR format. The STAR format is prescriptive, requiring the answer to be presented with a Situation, the Task outlined to solve it, the Actions taken, and the Result.
My Candidate Approach
One of my core goals as a candidate is to present myself as calm, confident, and competent. I don’t want to be reading from a script, or perhaps perceived as leveraging AI, so while I have my list of examples sitting in a spreadsheet, I have them mostly memorized; I want to respond naturally as much as possible. I want the interview to be a conversation, not an interrogation. I want the person interviewing me to get a feel for what a working relationship would be like. I like to think I’m a strong communicator, and making the interview conversation go smoothly is a specific goal I have in mind.
I also don’t necessarily follow the STAR format as closely as I’ve seen others do it. In my opinion, its rigidity leads candidates to believe they should prepare every potential answer ahead of time. As a result, it can lead to answers that lack personality, lack depth, and sound more like a resume reading session. It also tends to mean that answers come from that predefined set of prepared responses even if the answer doesn’t clearly match the question. I prefer to tell a story, to provide a narrative, with an opening, a description, and a conclusion. I incorporate parts of the STAR format into those narratives, but I’m aware of the limitations in that format and the likely gaps it will force into my answers. Instead, I’d like to address those gaps in my initial answer; I want to control the conversation, not allow for the possibility that a follow up will take me in a direction I may not necessarily be prepared to go.
Sometimes that means I take a moment and think before answering. I do this deliberately, and I think it’s acceptable, sometimes even necessary. I make sure that my eyes are not going to what might be perceived as another screen; I’m keenly aware of body language and when I do stop to think I tend to make sure I’m looking upward if I have to avert my eyes to gather my thoughts. I’d much prefer to take a couple of moments, cycle through my examples in my head, and then answer with something as befitting as possible, or acknowledge my answer might not be the best and explain why it might still be relevant.
This can lead me to ramble. I’m very self-aware and will pause at natural stopping points and let the interviewer follow up if they choose. One of the risks I pose to myself is being too verbose in my answers; these interviews are conducted on a clock and running out of time could potentially be a deal-breaker if important points are not brought up. As a result, it’s critical to have a perspective on time as well as a perspective on what’s critical to surface to the interviewer. I limit my introduction to a specific set of data and time. I have seen candidates who, once they start, are so eager to check all the boxes that they are not able to put the brakes on as they speak. In the hands of an experienced interviewer, that can be handled with a gentle interruption; but if a candidate encounters one without that experience, they can burn valuable time and risk not providing all the data points.
What Can Go Wrong With The Process
It takes a certain nuance for an interviewer to be able to conduct a behavioral interview in a way that evaluates thought process when the candidate doesn’t provide the “right” answer. When an interviewer can’t do this, the candidate will find themselves evaluated on being able to articulate the answer the interviewer seeks rather than on how they mentally approach a problem. This is poor evaluation technique; not every candidate will approach a problem the same way, or have an approach that aligns with the interviewer, even if the result was successful. In the end, confirmation bias can be more impactful on the decision to hire or not than a clear evaluation of thought process and results.
There’s no way for someone to prepare for every possible question. As a candidate, it’s critical to be prepared to pivot to similar situations, or take that moment to think, or ask follow up questions while they find an appropriate answer. The risk here is that a candidate can be disqualified simply for not encountering a particular situation before, even though they may have been able to handle it perfectly fine based on their experience. After a discussion on coaching engineers, I was asked if I ever had to manage performance of a senior engineer on my team. I’ve been blessed with awesome senior engineers on my teams, so I honestly answered no, and provided a counter-response where I coached a senior engineer who was moving to management, not on performance, but on handling new expectations. I’m not sure if that disqualified me when they chose not to move forward, but I also strongly believe that I shouldn’t be disqualified due to not having encountered a specific situation. My background indicates I’d be perfectly fine coaching senior engineers in any situation.
I’ve gotten into the habit of cataloging the questions I am asked and taking my own notes after an interview completes to specifically target the ones I was not expecting. I actually like getting new questions, as I can incorporate them into my preparation.
There are interviewers who struggle to balance the time involved (typically 45-60 minutes) and the amount of data they need to gather. This can result in two poor outcomes. First, important data that could impact the hiring decision might be missed, as clarifying or follow up questions are not effectively executed. Second, and this happened to me recently, the interviewer is not able to conduct the questioning cleanly. I had an interview where I was interrupted after nearly every sentence to either direct or clarify what I said, before I had finished my point. This resulted in a disjointed experience, where the interviewer’s inability to coherently conduct questioning led to confusion, changes of direction, and a clearly poor result. If a company decides to pass on a candidate because there are missing data points, and the company is not willing to follow up to address those missing data points before making that decision, poor interviewing technique becomes an even greater risk to the process.
As a candidate, it’s important to maintain your composure at times like this and make sure that you are clarifying the questions you are being asked, and completing your thoughts before moving to the next one.
Final Thoughts
Interviewing is an inexact science. But behavioral interviews are even more subjective. Too often the inherent personal bias of the interviewer, the training provided, or the company guidance are more impactful than thoughtful evaluation and listening skills. The end result is companies are just as likely to hire someone that luckily manages to match their bias as they are to hire someone that actually matches their skills and qualifications. In a job market like the current one, where there’s an overabundance of candidates, companies are even less likely to feel certain about a hiring decision, and more likely to wait for that perfect candidate.
Be welcome and true.
Rob Hope 