Welcome to episode 195 of the Nerd Journey Podcast [@NerdJourney]! We’re John White (@vJourneyman) and Nick Korte (@NetworkNerd_), two Pre-Sales Technical Engineers who are hoping to bring you the IT career advice that we wish we’d been given earlier in our careers. In today’s episode we share part 1 of an interview with David Babbitt, discussing his early career as a developer, life at a big company compared to a startup and perceptions of each, and the transition to manager which required learning interviewer skills.

Original Recording Date: 10-11-2022

Topics – Meet David Babbitt, Beginnings of a Software Development Career, Developers and Engineers, Experience in Development at IBM, Perceptions of Startup Life, Accepting New Challenges, Interviewing and Hiring

4:09 – Meet David Babbitt

• David Babbitt is currently a Principal Technical Product Manager at Amazon in part of the "last mile organization" – the Transporter Experience and Technology Group.
  • Amazon has a huge delivery arm that makes use of trucks, drones, and other technologies.
  • David’s main responsibility comes in when a driver (or the "transporter") is delivering something to a locker (something you may see at gas stations, for example) or other access point. David’s focus is when a driver interacts with one of these access points.
• David’s father was an English teacher and taught English as a second language in the Dallas, Texas area where the family lived. David’s father went back to college to get a computer science degree.
  • While in college, David’s father got very interested in what he was studying (programming).
  • David remembers looking through some of those textbooks and being very interested in the subject since about 3rd or 4th grade, feeling he is one of the few people who have known since an early age what he wanted to do for a career.
  • Thus began David’s passion for working with computers, and David’s father encouraged him to do what he wanted for a career.
  • David’s father eventually became a technical writer but continued to encourage David’s passion (which often included building computers and writing code).
• David never went into tech marketing. He wanted to write code because he enjoys the problem solving side of it and equates it to working on puzzles every day.
• The first programming language David learned was Pascal, which was what his dad was learning.
  • He would later learn C in high school.
  • In David’s college years it was a mix of C and Java.
  • As he got into his first few jobs he worked in C. Java, C Sharp, and later Ruby on Rails.

8:05 – Beginnings of a Software Development Career

• David says a career in software development was what he wanted and expected after enjoying programming so much as a young man.
• David went to Carnegie Mellon University, a top 5 school for computer science programs, and attended with some extremely bright people.
  • David recognized he probably was not going to be the best engineer / longest tenured engineer in an organization, which may have led him to seek moving out of engineering eventually (even if it was at the back of his mind then).
• John states learning programming languages is different from the actual job of programming for a living.
  • You need to learn algorithmic thinking and data structures and how they apply, which may come a little while after you get into a career in this field.
  • David states when he was in high school there was nothing about data structures and only a focus on trying to make the program work.
  • Before going off to school David evaluated a number of computer science programs. He saw that many of them were a few language classes with a mix of courses in algorithms, data structures, mathematics, and problem solving.
  • At Carnegie Mellon at the time David was there it was 9 computer science classes and 7 math classes.
  • John recalls one of his programming classes in college where the professor lectured in pseudocode with lab exercises using C as the language (textbook was K&R.
  • David mentions a book on Design Patterns written by a group of authors called the Gang of Four

11:07 – Developers and Engineers

• Are software developers and software engineers different names for the same thing?
  • David remembers his first job out of school being at IBM. At the time he worked with others who had proper engineering degrees and feels like those folks may not have been happy with software developers calling themselves engineers without the same type of rigor to earn the title.
  • In terms of job titles, David likes to list the title companies give him on LinkedIn (whatever that might be).
  • This goes back to our discussions with Neil Thompson from Episode 193 about certified professional engineers. If you have a new school role with the designation of engineer on it and no certification attached, the people who have sat through the certification in an engineering discipline would be insulted.
    • It would be the same if a janitor added an engineer designation to his / her role.
    • David remembers the early days when chemical engineers and other types of engineers were definitely insulted by software developers calling themselves engineers without having passed any specific exam for it, etc.
  • David did an internship right after high school in the North Texas area for the superconducting supercollider.
    • He remembers a number of mechanical engineers who worked there. They would look at CAD designs, and David would be writing code. There was a very different dynamic to the relationship.
  • Overall, David sees no specific distinction in the industry between software engineer and software developer.
• Is leveling as a software engineer similar across different companies? John mentions large tech companies as an example.
  • David worked at 5 different startups before coming to Amazon.
  • At those companies it was usually developer, senior developer, and maybe a principal level or development lead.
  • In product management (where David works now), it’s technical product manager, product manager, and then maybe a senior or principal level person. It wasn’t as regimented at the placed where David worked in the past.
  • In coming to Amazon, David has read articles about software developer 2 and software developer 3 levels, for example. He is an L7. This site may give listeners some idea of what life as a software developer could be like at Amazon. For further reading, check out:
    • [Insights into Amazon’s Compensation Philosophy & Salary Negotiation Tactics}(https://www.carrus.io/blog/insights-into-amazons-compensation-philosophy-salary-negotiation-tactics)
    • Amazon’s different salary levels explained (2022)

14:53 – Experience in Development at IBM

• David’s first job was at IBM, and he landed it through a career fair at Carnegie Mellon.
  • Despite going to school in Pennsylvania, David’s desire was to return to Dallas if possible.
  • After interviewing with multiple companies in the Austin area, David landed at IBM.
  • He worked in the TCP / IP group for the AIX product at IBM (the Unix before Linux) focusing specifically on the DHCP and DNS server for AIX over a 3 year period.
  • David had an IBM RS/6000 at his house at the time. This line was anything with a Power processor.
• Due to the specifics of the job, David had to ramp up on DHCP and DNS protocols. He had some understanding of network programming (sockets programming) from a class taken during his senior year at college.
  • David feels that in any role you will need to come up to speed a little bit on the domain you’re in.
  • Nick asked the question more for those looking to break into the software industry. Should someone new to the software development industry expect to be able to ramp on the product for which they do development as long as they have the proper development skillset?
    • The things you take (as a developer) from job to job are being able to solve a problem, being able to dig, and being able to research according to David.
    • You don’t know the domain you are stepping into necessarily (business problem you’re solving, target market, etc.).
    • One of David’s favorite parts of being an engineer is being a developer. As he worked for different companies over the years David got to learn how things worked from the inside out and always thought this was really fun.
    • When he started working for IBM David knew nothing about DNS but was quite the DNS expert by the time he left the company later on.
    • Working in different roles allows you to learn about different technologies. David had a friend who worked in foreign exchange trading, for example.
    • "I think it’s really interesting stuff that you get exposed to as a developer." – David Babbitt
• Once you gain expertise in a specific problem area as a developer (like networking in David’s case), is it easy to move around within an organization (to a database team), or does the expertise prevent your mobility and require leaving the company to make that sort of move?
  • David feels this may be more organizationally dependent. One thing he has seen at Amazon is that there does seem to be a lot of opportunity for mobility within the company (i.e. people taking on new roles inside the company).
  • At startups you’re basically working on a single product and not really changing between products or don’t necessarily have the opportunity to change between them.
  • David sees front end developers, back end developers, and full stack developers. He feels you do get a little pigeonholed in some part of the skillset.
  • Someone who specializes in databases will not be doomed to always work on databases. Your experience may be only in networking, and it may be hard to escape that at some point. Your experience may just be writing back end code / server or services code, and you’re probably not going to transition to being a front end developer or mobile developer very easily.
• What about leveraging your domain knowledge to break into software development?
  • If someone had come to IBM at the same time as David with expertise in DNS and DHCP but more of a beginner in coding, is that enough to get someone to give you a chance?
  • At IBM, David and team were doing C development, which is one of the harder ones to start off doing. So it might not be fair to say IBM would have taken that chance.
  • Nowadays David thinks there is more opportunity to make this type of transition.
  • David knows some people who are now analysts that maybe 10 years ago were working in Excel or R and are now writing Python code.
  • David’s brother is an Active Directory administrator who in the past several years has become well versed in DevOps tooling like Puppet, Chef, and PowerShell. His brother even is one of the cohosts / coleaders of the local PowerShell user group in Austin.
  • We now see domain expertise turning into programming skills, and DevOps may be part of this trend. You see people who were technologists that learned a little bit of scripting / gained domain expertise in scripting eventually becoming developers (David mentions two people he knows who have made this transition). Now there is a lot of opportunity to do this.
  • John says IT operations folks may refer to themselves as "just writing scripts" as opposed to writing programs, and developers may refer to these people in the same way due to perhaps a lack of rigor or some other perceived divide.
  • The more complex infrastructure as code or the greater DevOps world gets this delineation kind of falls away, and everyone starts to need to have the aforementioned rigor.
  • David agrees. He dabbled in DevOps a couple of jobs ago and says it is certainly not easy. The discipline in and of itself has specific challenges, problems, and rigor.
    • Seeing something more as a script compared to a structured program to David is not a reflection on how valued something is.
  • John definitely made the above delineation when writing scripts during his time in IT operations. He refers to a 3000-line script he wrote in Perl as "just a script" despite it being extremely well structured and documented.
    • David says Perl scripts can easily turn into programs of their own. John says it is the same for PowerShell (something that originated as a scripting language and has grown from there). Nick says PowerShell scripting is a skill people will hire.
• David points to high salaries in the DevOps discipline right now.
• John agrees this is an important job area for most industries and may be due to title inflation.
• David feels one of the surprises of the last 5 years – technology jobs that kind of came out of nowhere that are now top earners.
  • John feels some of this is title inflation and mentions no one hires sysadmins (or systems administrators) any longer (at least for the most part). Many who began in operations started with the sysadmin role.

23:48 – Perceptions of Startup Life

• David feels like his thoughts on IBM may apply to any large company. They had 100-300 developers contributing to AIX, and it felt like it was easy to hide. There was also the importance of what you were working on to consider.
  • David went on to later become a leader and product manager (which we will get to later) and was more focused on the product in the market and outcomes to create.
  • As a junior engineer focused on a specific feature, when your feature did not make a release it felt like you were working in a sea of engineers inside a gigantic product and that your feature just didn’t matter.
• David wanted to move to a startup next. He left IBM and didn’t feel that was the result of the .com bubble. David wanted the chance to have greater responsibility, make a bigger difference, and make bigger difference to the product.
• Dave says one common item listed on startup job postings is ability to deal with uncertainty.
• David remembers one of his leaders at a specific startup reminding the team what the definition of a startup is. It’s one of the following – an unproven product, an unproven market segment, or an unproven business model.
  • When trying to make something unproven succeed, you are going to be met with a lot of uncertainty.
  • Imagine walking into a bank for a small business loan to open up a known franchise like a Circle K. There is a known business problem and a model for being successful at it.
  • Uncertainty comes into the picture because you will be met with changes – in what you thought was the right direction for the product, in roles and responsibilities, etc.
    • Being able to "roll with the punches" in this situation is part of it.
  • Understand that you are going to wear a lot of hats. There is not going to be a box around your role, and it will require that you step outside what you think is a typical role and have to contribute to other areas, learn something new, etc.
    • This is something to be aware of, especially when startups are smaller.
    • David thinks at startups you are probably going to end up having to work a little harder. This is not meant to be analogous to the .com boom and 100 hour weeks but more the sum of the previous two points (uncertainty and wearing lots of hats).
    • You are likely going to have to step outside your role at some point because the company didn’t anticipate something. Be willing to accept that every now and then you will have to roll up your sleeves and work a little harder on something.
    • David classifies himself as a bit of a workaholic and doesn’t think it is right for a company to take advantage of this. If you are frequently having to roll up your sleeves and do other people’s jobs / having to put in an extreme amount of extra hours, at some point it is mismanagement and poor planning. But the occasional burst is ok.
      • Be willing to be there to pick up the pieces and help solve a problem a time or two.
  • There is a lot of upside in David’s opinion to working at a startup.
    • You are going to feel like you move the needle all the time. People are depending on you to get your task completed or finish a piece of the product. Hopefully it is fulfilling for you that you have that much responsibility and people are depending on you.
    • You are going to learn a lot because of the exposure to things.
    • As an example, David worked 10-12 years before moving to Spiceworks. He had been an engineer and lead engineer in his career across various products up to this point.
    • Around his second year at Spiceworks, David’s boss approached him about being a manager. In the next 3-5 years David got exposed to a number of things he had not previously been exposed to as an individual contributor such as budgeting, hiring, how business partnerships work, etc.
    • David is not certain he would have been exposed to all of these things working at a larger company and feels they are part of the reward of startup life.
• Many people talk about the risk of a startup and whether it will shutdown / fail.
  • David never really felt this. But he did work at a company ran its course and left before that happened.
  • Everyone at a startup is invested in the success of the startup and therefore invested in 1.0 of the product / service (or whatever stage it is in its lifecycle).
  • Working at a remote office for some giant company like IBM or Cisco might pose a risk of it being shutdown one day out of the blue. David always felt more job security working at a startup than at the satellite offices for a large company.
  • John says it does not even have to be a satellite office to present risk of being cut and could be a product team and everyone from the VP down regardless of location.
  • More people have been exposed to this in the last 5-10 years and have come to realize that working for a large company does not mean more job security. Large companies exist that fire people all the time.
  • No one has a lifetime commitment to you. Those days are over.
  • Maybe the frailty or risk of working at a startup has to do with the percentage of compensation that comes in the form of stock options?
    • David thinks we’re past these days and that people aren’t taking pay cuts to work for stock options as it may have been in the 1990s.
    • If you compare a startup salary to an Amazon salary, for example, they are vastly different. If you take out the FAANG companies and compare the average tech company salary to an average startup, the salaries are not so different.
  • If you are focused on your salary, your success, and your family safety and security…David feels like you get that in a startup.
    • The company may have a chance of failing, but you are likely going to be ok for a period of time.
    • David does not feel this changes whether you’re working at a startup compared to a large company.
  • John says it may have taken a cycle of people working at a reduced salary for imaginary paper to help break some of this perception of startups.
  • It also takes a cycle of people who worked for companies that went under but ended up fine because of the demand for their role and the ease of finding a new role with the skillset the person acquired at the startup.
• When going into a startup, fear of failure is something to get over.
  • Accept the possibility that the startup could fail, and think about what you could learn from it. Embrace that to a certain degree.
  • Maybe David has been very privileged over the course of his career. He has lost his job in the past and chosen to move on to other companies. But David has never lost a job for any length of time which made him felt like his family’s livelihood was at stake / threatened.
  • John says you would not want a startup to fail at the beginning of a recession but while the job market is hot. This is something to take into account when accessing risk in taking a role.
• How would a hiring company look at a failed startup on someone’s resume?
  • David could not really say firsthand and did not recall being asked about lessons learned from less successful startups.
  • When David has interviewed people in the past and saw on the person’s resume that they had tried something of their own (side business, quit their job to take a chance, etc.), David really enjoyed those conversations and saw it as a chance to learn about what someone else learned from the experience.
    • "It wasn’t so much the failure itself. I think it’s really what you took away from it." – David Babbitt
  • John says maybe if you’re being interviewed to join a founding team there is a little more scrutiny on past experiences with other startups.

35:32 – Accepting New Challenges

• Around 2009 when working for Spiceworks, David recalls about 30-60 people on staff. It was a very engineering heavy organization.
• David reported to one of the founders (a VP of Engineering) who had about 20 direct reports (too many). This founder approached David and one other engineer asking for help and gauging their interest in managing people.
  • David says he is always up for a challenge and was not thinking (at the time) that this was going to be part of his career path necessarily.
  • In retrospect, David feels he is a little bit of a team player to a fault. If the company needs it, he will try it, even if it ends up being not something he necessarily wanted to do.
  • In this case David really did enjoy managing people. He is a people person.
  • "Sort of like programming is a little bit of puzzles every day, managing people is its own little challenge." – David Babbitt
  • Management at Spiceworks was a lot like being a player coach. Managers were still writing code. There were no product managers at this time, so they got to lead the product as well as lead the engineering effort.
  • David feels it was a fun transition.
• John says it was more about making an investment in the startup and what David could do to make the startup successful than what we might call a well planned career move.
  • David agrees and thinks you could probably say the same about the rest of his career (not very calculated). David continued doing the things he enjoyed, which has taken him to where he is.
  • If that strategy is leading to success, maybe it’s a great way to go about it.
  • By and large David has enjoyed each job and its various responsibilities over the course of his career.
• It sounded like David’s leaving IBM fit the patterns Patrick Lencioni discussed in The Three Signs of a Miserable Job: A Fable for Managers (and Their Employees – anonymity, irrelevance, and immeasurement.
  • John says maybe the first two were true for David, and these were some of the reasons / justification behind moving to a startup. He would be more well known and could see directly how his contributions were impacting the company. David agreed.
  • Someone once told David their stake in the company was not as large as his (almost as if his level of effort was somehow related to how much he stood to gain from the success of the company). David could not disagree more with this statement.
  • It goes back to him not being very calculated about how career path and all about whether the team was doing right by their customers and users, whether he (David) was making an impact on the product, were people enjoying the product, etc. These items were David’s motivation and likely led to his eventually becoming a product manager.
  • Nick says continuing to make an impact does not change job satisfaction because David felt he still had a purpose.

40:04 – Interviewing and Hiring

• Nick says it seemed like interviewing people was a skill David had to learn in his role as a people manager.

  • David remembers the first few interviews being super uncomfortable and that he was often interview people with far more tenure in the industry (which can intimidate an interviewer).
  • "Who am I? I’m some kid interviewing this person. You feel really out of place." – David Babbitt
  • According to David it took lots of practice.
  • David would typically ask the same sets of questions to candidates as a way to compare the candidates and see who answered the question differently compared to others.
  • There was a running joke inside the company that people knew what David’s questions would be.
  • If you are new to interviewing (like David was), you can sit in on other interviews and see how other people ask questions, how they take the conversation, and where they go with it. This can help you develop your own process over time.
  • John had not thought about it, but he does ask similar questions in interviewing people at Google Cloud (which he does maybe once per month). At Google Cloud interviewers are not allowed to index to past people they have interviewed and have to index based on a rubric.
  • It’s a little bit more challenging if you don’t interview people very often, but for John it is easy to look up a rubric that can be used for guidance on what success looks like, what to look for in a candidate, etc.
  • David mentions at startups he does not believe it was quite as formal / methodical / scientific in their process. He states they were interviewing all the time, often times conducting 2-3 interviews or more per week.
    • David feels at the startup you would do so many interviews it was really easy to spot the bad candidates and spot the really good ones.
    • Engineering interview processes may not provide a good way to look at candidates in between the rock stars that interview well and the ones who struggle.
    • At Spiceworks they tried a number of different things, and David pushed for a number of different approaches to improve for this middle group of people.
    • David cites trying to bring people in for a half day to work with an employee to find out the sorts of questions they might ask, whether they dig to solve problems and understand, etc. As an engineering manager, you can learn a lot from this that cannot be learned from a whiteboard.

• As a naïve interviewer David thinks you start off asking trivia-like questions.

  • David cites obscure Java questions as one set of questions one might ask.
  • While his first few interviews of people may be like this, but David eventually started giving people a really hard problem and seeing how they would solve it. It became less about the programming language, and David would let people write pseudocode.

• Nick suggests the questions asked by someone closer to a hiring manager role may end up being quite different than those who are individual contributors and help with the hiring process.’

  • David remembers giving people a problem and letting them struggle with it a little. Writing a loop might be one example.
  • Over time David began asking more about culture.
  • David was curious about how people had responded to previous situations in previous jobs (i.e. "tell me about a time when…"). At startups that is more of a management style question and not necessarily what a peer would ask another engineer.
  • In David’s experience at Amazon he’s heard a lot of "tell me about a time when" type questions and believes these to be common among FAANG companies.

• John mentions you only have a methodical method of doing interviews, tracking performance, and tracking output of what those interviews when you are a large company which has an entire department of people solely focused on this.

  • If a team like this found after spending 1000 hours researching that they could save $10 million per quarter, for example, they would likely implement the changes. This is not going to happen at a startup because they don’t have this kind of team.

• This goes back to things you learn at a startup. In a way you are making it up as you go.

  • David did not interview at any type of scale until his time at Spiceworks. And at the time there was not a lot of science behind it.
  • When doing 2-3 interviews per week you are developing your craft as an interviewer.

• This also goes back to resource constraints for startups and shows up in different ways.

  • Is there a C-level HR executive who reports directly to the board at times? Likely the answer is no, or this hat could be worn by another C-level who has two other C-level responsibilities.
  • David says this is also about the scale. When you are the size of Facebook, Google, and others you recognize small improvements can be worth millions of dollars. This means you can throw engineers, data scientists, and others at it to solve these problems (all upside).
  • At startups you can never do this kind of thing. If you’re hiring 3 people to support the growth from 30 people to 500 over the course of 5 years, will you see the return on investment from it?
  • Are we going to hire an entire team to understand the math behind hiring well? It seems unlikely for a startup according to David.
  • John can see how this would be something in which a company does not invest. We keep talking to managers who have shared that hiring the wrong person can be disastrous. Making 2 or 3 bad hires can really haunt you for years.
  • Typical interviews can weed out the best and worst candidates, but David thinks there is a huge gray area between that needs better service. Perhaps companies feeling pressure to hire accepted candidates in this area and got some losses. Other companies may have been willing to put more effort into figuring it out, and rather than just saying no and moving on to the rock stars, out of the gray area, figure out which candidates are going to be great employees and which are not.
  • This difference may be that in people who know how to say the right things but when they come in are not so useful vs. those who are trainable.

• There are likely a number of startups that have solved these issues for other startups or HR services firms who have done it.

• For reference it has been a while since David has done a ton of interviewing, and he does not claim it as an area of expertise these days.

• Mentioned in the outro

  • Did David’s father’s career change affect the way David viewed risks of changing roles and careers? We forgot to ask!
  • David’s mention of servicing the candidate market in between rock stars and low level candidates (those who aren’t very strong) sounds similar to what Jeff Eberhard said about solid players (a step below high flyers).
    • Check out Episode 115 for that full interview with Jeff Eberhard.
  • Be sure to check out The Three Signs of a Miserable Job: A Fable for Managers (and Their Employees by Patrick Lencioni if you’ve not read it.

Contact us if you need help on the journey, and be sure to check out the Nerd Journey Podcast Knowledge Graph.