Introduction

When I first entered the work force, I had a much different view the interview process than I do today. Back then I pictured a one-sided discussion where the only goal was for me to convince the hiring manager that I was the best person for the role. All I that cared about was that the job was in IT and that the pay was competitive.

Fast forward several decades and the criteria has become much more detailed to ensure, as much as possible, that both sides are happy with their choice. Not only in the short term, but for the 2-3 years that most employees stay at their position( Dice Study on Retention ).

To achieve this lofty goal, I've identified 3 categories of criteria to cover during the job discovery and interview process. We'll describe each category and identify potential problems with each one.

• The Role
• Company Culture (future article)
• Lifestyle Concerns (future article)

For the purposes of this discussion, let's clarify a few definitions

• My picture of the "employer" is a stereotypical entity based on my several decades of experience
• My picture of the "employee" is my idea of what an employee should bring to the table,  and they should expect from their employer.

The Role

From the employer perspective, the ideal candidate can do the job perfectly from day 1, is happy to do repetitive work,  and functions in different roles as needed, even if the role is far different than what was presented in the interview process. Let's tackle these from the employee's perspective.

Hit the Ground Running  - What's Next?

For the employee, they should be familiar with 50% to 60% of the job, so that there a good room for growth. Engineers like to learn new skills and solve difficult problems. They will immediately lose interest if the work becomes repetitive, or if they stop growing professionally.

It's exciting to join a new team. For weeks the employee is excited to demonstrate their ability to learn day to day operations while adding value whenever they find the opportunity. The flurry of new information, new faces, and new skills during period can be interesting enough to mask otherwise obvious questions, such as "what's next after I learn this?"

Example:

 Employee learns to operate and maintain ETL pipelines for market analysis company. They'd like to tweak database performance, update the dated Perl scripts to Python 3 for performance and scalability improvements, but are encouraged to "just keep things running the way they are". Employee doesn't see any way to grow professionally doing the same work day in, day out, so they leave to join a startup.

Project Work vs Operational Work

The Phoenix Project
The Phoenix Project demonstrates the importance of Project work over Operations work.

Many companies fall into the trap where only operational work is seen as worth pursuing. This type of work consists of maintenance - free up storage space, apply software patches, manage user accounts, write reports - and incident management - restart services, reboot services, rebuild servers, fix configuration mistakes, recovery from power outage, replace failed hardware.

While this operation work is need to restore service levels, all it accomplishes is to maintain the status quo. This work does nothing to improve the work environment or make the business more competitive in the marketplace. It's also mostly repetitive and can be automated.

Project Work is strategic work that automates operational work, improves performance of existing systems, adds a feature or service that makes operations easier, etc. This work is generally much more rewarding than operational work because it's educational, it improves the work environment ( no more cleaning up log files, it's automated! ), frees up engineer's time, and reduces the need for on-call / overtime. Who doesn't want that?

Often an employer is completely satisfied with operational or "fixit" work being 80% - 100% of their their employees do. They'll throw people and money at an outage but not reserve any capacity for a project that analyzes the root cause, designs  and implements a solution that prevents the problem from re-occurring.

For the employee, it's reasonable to expect a 50/50 Operational work to Project work ratio. With this balance, the employee learns important technical skills, project management skills, and they get the satisfaction from the lasting results of their effort. Firefighting puts out a fire , but a Project either prevents the fire or puts safeguards in place to mitigates the damage from the fire.  Which is more valuable, a restore system that replaces files lost to a hard drive failure, or a storage redundancy system the mitigates the damage caused by the same failure?  Companies I've surveyed such as Google and LinkedIn maintain this 50/50 ratio as their quarterly goal because they realize that just maintaining the status quo will lead to them losing their competitive edge in the long run. It also burns out employees and hurts retention. You'll need to ask the hard questions during the interview process to determine if the team that you'll be joining consists of firefighters or problem solvers before you accept the position.

Responsibility Drift

I didn't sign up for this!

The last topic for this post is a bit of a pet peeve of mine, only because I've experienced first-hand many times during my career. I consider it the most difficult type problem to prevent since it happens *after* the job offer has been accepted.  It's where the position transforms into something significantly different than what was presented during the interview process within a relatively short time (1-6 months) after the employee starts the new job.

Example:

Employee accepts the position of SRE whose responsibilities are to automate the system build process, software installation process, monitor health of server fleet, and provide detailed metrics of application performance while suggesting solution to improve service reliability, scalability, and efficiency.  The employee quickly adapts to requirements, automating much of previously manual build process using Perla and Python scripting languages. They also creates several performance reports that identify areas of improvement.  After 2 months on the job,  the responsibilities are changed to do statistical analysis of network traffic by collecting and analyzing tcp traffic dumps. The goal is to identify inefficiencies in the network code of the company's flagship Java application.  Having no experience with Java code or statistics, and completely blindsided by this change, the employee's performance tanks and their motivation goes to zero. They give notice and leave the company, appalled at the waste of time invested in a position that was effectively cancelled after 2 months.

From the employer perspective, they were receiving complaints about application performance and decided to reallocate their existing resources to solve the problem.

As a preventative measure, research the company and the position as much as possible.

What is company's flagship product? What kind of regulations or market forces impact the company? These factors can tell you about the companies priorities.

How long has the team existed? Is the team growing or is it hiring to fill a vacancy?

This can give you an idea how stable the position is, and whether employee's tend to stay or not.

Do the interviews yield details descriptions of responsibilities and daily activities? Or are the answers non-committal i.e.  "we can't tell you exactly what you'll be doing or which team you'll be on?"

Non-committal answers are not necessarily bad, fast-growing companies often check for cultural fit and then match the employee's skills with the one of many open positions on various teams. It can also mean that the team is new and they really don't know what you'll be doing. You could get the 50/50 ratio or be stuck working incident tickets for 100% of your time on the job.

This problem merits another example:

Employee accepts and relocates for a position of network engineer with responsibilities of configuring, deploying, and managing network equipment for a WAN that spans across continents. After few weeks of in-processing, they are told that the team recently lost both their sole Unix administrator and Oracle DBA , and that they need to employee to assume both roles. Having sold their home and travelled far to accept the position, the employee accepts the role even though it means their network skill set will stagnate. They train themselves for the new roles and do a reasonably good job in them. They leave as soon as it makes economic sense to do so.

As I implied earlier,  this is a difficult problem to avoid since it requires you to predict the future.

What's Next?

Ask questions, lots of questions. It's expected and the more the potential employee and employer know about each other the better. And don't just ask the interviewers, check on message boards, ask friends who may have worked there, check publications, Youtube channels, etc. Accepting a position is not a small choice so do your due diligence before accepting that offer.

In the next part of the three-part series, I'll tell what you need to know about the topics of Company Culture and Lifestyle Concerns, and how you can get that information.