Data science career advice
How to spot red flags in a data science job opportunity
Here are a few ways I assess a job before deciding to accept the job offer
A while ago, I got a question from someone who had read one of my previous posts on finding a data science job. He mentioned my prioritization of work-life balance, and asked:
“I definitely agree, but how do you assess this? Do you ask in an interview something like, ‘how often do you work weekends?’ I’ve always been afraid of coming off as unenthusiastic, I suppose, and have only tried to ferret out info on Glassdoor or similar sites. And even if you do ask, I wonder how reliable the answer would be. At any rate, I’d be interested to hear your own approach for appraising a company in this regard.”
That got me thinking more broadly about all the things I’ve wanted from a job when I was an applicant, and all the ways I tried (and often failed) find out those things before I actually accepted the position. I think every job acceptance is a gamble, just as every job offer is a gamble, but I do think there are ways a candidate can minimize unexpected downside — no matter how far the job falls short of how good I thought it could be, I can at least avoid many jobs that will far exceed my expectations of how bad they could possibly be. That’s something, even if it’s not as much certainty as I would like.
So this post is about major problems I’ve discovered after accepting an offer of employment, and some ideas about how I could have spotted those problems before becoming tied to the job.
Spotting work-life balance problems
Let’s start with the issues that started this train of thought. Work-life balance is hard to assess, so I usually don’t assess it until I’m reasonably sure both I and my prospective employer feel the job is a good mutual fit. If an employer is going to cut me loose oher reasons (and there are many, even for the most experienced applicant), there’s no point in talking about anything else. By waiting until near the end of the process, I ensure as good a relationship with the hiring managers as I can expect to have without actually being hired. If the conversation still feels very threatening at that point, that tells me the job probably isn’t a very good fit for me.
I usually start the conversation along these lines: “I’d like to talk about work-life balance. I’m used to putting in whatever time and effort it takes to get the job done, but I also know how important it is for me to protect myself from burnout. Can you tell me a little about expectations along those lines? How often can I expect to need to work nights or weekends? If I have a family issue where it’s going to be better for me to work from home on a particular day, will I have the freedom to do that?”
I’ve found the answers to these questions less important than the tone and body language I observe while they are being answered. I’ve experienced obvious defensiveness: the manager bristles and says of course that sort of accommodation has to happen sometimes and it’s not realistic to expect that it doesn’t, but they try to keep it to a minimum because really they need people to put in whatever work is needed. I’ve experienced patronizing non-answers: the manager leans back in their chair and says something meaningless like “you know, we work hard and play hard here” or otherwise makes it clear that they’re using this as a teaching moment to educate me about what it means to do grown-up work. I’ve also experienced general cluelessness: the manager makes it clear that they haven’t really thought much about the subject and can’t really tell mehow often that sort of thing happens.
Defensiveness means they know work-life balance is a problem at their company but don’t feel empowered to do anything about it. Patronization means they have no respect for their employees’ time and health and are just trying squeeze as much benefit as they can out of their workforce without giving any thought to long-term sustainability. Cluelessness is either faked, in which case it means that the situation is bad but they’re not willing to be honest enough to tell me about it — in other words, they lie — or it’s real and that means they’re so disconnected from their workforce that they honestly don’t know.
Spotting unrealistic expectations about data science
Everyone says they want data science. Few people are willing to put in the work it takes to maintain a full-scale data science capability. There are several ways to spot this. In my experience, a walled-garden engineering organization, typified by a waterfall approach to planning, is a pretty strong indicator that a company isn’t ready or willing support a data scientist. Likewise, a focus on developing reports or making dashboards as a major part of the job description indicates, in my mind, that they’re not really asking for a data scientist. They’re asking for an analyst — perhaps one with statistical expertise, but an analyst nonetheless. But those are symptoms, not the disease.
The real issue, in my opinion, is whether a company values productionization of data science work. Analytic reports are made to be throw away — it doesn’t matter if the report goes to an engineer or to an executive. Any outputs that only serve the purpose of informing someone do not last. Jobs that throw my work away are not satisfying jobs — and it indicates that the company doesn’t really know what to do with my work.
In my experience, I can tell how much a company values productionization by their comfort levels when asked about productionization. As with work-life balance, the responses can range from defensive to patronizing to clueless. I’ve often seen prospective employers try to skirt this issue by talking about how they manage projects. That’s a red flag.
A project manager is an administrative position. Whenever a team is working on anything from building software to planning an event, a bunch of logistical issues (deadlines, stakeholders, division of labor, etc.) need coordinating. The bigger the team and more complicated the project, the more it can help to have someone whose job is to keep an eye on all these moving pieces. Project management is not product management. Project management figures out what part of the overall plan needs code written right now, decides what to do when a new feature exposes flaws in existing features, and maintaining control over the definition of “good enough” (which is, when all is said and done, the only real acceptance criteria any data science project ever has), and other day-to-day issues. Product management focuses on what the team has capacity to work on next (as opposed to right now), what stakeholders are asking for and what meetings are needed to flesh that out, and other ways of tying the implementation work into the larger organization.
If a company can only talk about data science work in terms of projects, I know that I don’t want to work for them. If they can talk about data science in terms of durable product offerings, and how they decide what gets put in the product and what doesn’t, then I know I might want to work for them.
Spotting a wimpy manager
I’ve found Liz Ryan’s concept of a wimpy manager useful. It’s somewhat rare, in my experience, to find a genuinely mean or abusive manager, although I know there are certainly more of those types of managers than any of us would like. It’s comparatively more common to find managers who are so unsure of their own position or competency, that they try to make everyone around them (especially those who report to them) look incompetent while at the same time imposing arbitrary rules designed to make them look “strong” and “decisive”.
I’ve found that wimpy managers systematically show those who report to them that the manager’s time is much more important than anything the employee could want. They cancel on me. They talk constantly about all the important things they did and all the important people they talked to that prevented them from really looking at the task they asked me to do. They’re unable to talk about any idea that they didn’t originate. If I’m looking for these things, they often come out in the interview process.
While a manager who obviously doesn’t care about my time is someone to be avoided, I also don’t want a manager who is painfully accommodating: never intentionally disagreeing with me, caving on a disagreement as soon as I push back, seemingly eager to assure me that whatever I want is what I’ll get. In my experience, this either means that they themselves are so under the thumb of a wimpy manager that they’ve lost their ability to assert their own will, or it means they’re telling me whatever they think I want to hear. Either way, those kinds of managers don’t manage — they just react. A data scientist is usually an individual contributor, which means it is usually a data scientists job to react to needs in the business. When I’ve had to constantly react to someone else’s reactions, I’ve burnt out.
Spotting a lack of prioritization process
Data science (and, I believe, developing code in general) works well when a company has a separation of power. Separation of power means separation of ownership — someone who has authority over one part of the process doesn’t get to have authority over the other. I tend to divide data science work into three parts: priorities, product, and people.
In an Agile framework, priorities are normally owned by the product manager (or the department in which product managers live — which in many organizations is confusingly called “product management” or just “product”). This owner gets to define and prioritize organizational asks, and is responsible for understanding and documenting systems, and for managing stakeholders. This owner has final authority on what gets planned and promised — if they determine that a feature is important enough to consume all available resources, they can put other priorities on hold, even if other people disagree with them.
The product is typically owned by the product owner, or sometimes the implementation team itself (or the department in which product owners and implementers live — which in many organization is just called the “engineering department”). This owner organizes the day-to-day work of the implementers, scheduling work, following up on delivery commitments, prioritizing bug reports, etc. This owner has final authority on the integrity of the product — if they determine that a change will threaten the stability or future availability of something already built, they can prevent the change from taking place until appropriate planning, process development, and change management has taken place.
People are owned by people manager (or the department in which people managers live, which ultimately is HR, but which in practice usually sees individual people managers embedded in all departments). This owner works on career plans and personnel reviews, manages inter-personal conflicts including when people don’t meet expectations, and deals with all of the other human aspects of running a team. This owner has final hiring/firing authority, even though they often receive input on those topics from the other owners.
Individual engineers and analysts have ownership as well — over the specifics of their implementation — but their ownership isn’t separate from the other powers. An analyst might not feel that an analytic solution is sound, but a product manager can still decide that the solution is good enough to ship, and the product owner can still decide that the solution is maintainable, and the people manager can still decide that developing and maintaining that solution is necessary for the employee to meet expectations and keep his or her employment. Good organizations don’t consistently trample on the concerns of their implementers, but the authority to do so is always there and is sometimes necessary and good, since implementers often have way too high a standard for what is good enough to meet a customer need.
Unless a company is an extremely small startup that can’t afford anything better, not having these three powers separated will prevent most data scientists from work on anything meaningful or lasting. When priorities and product are owned by the same person, unrealistic features are approved on unrealistic timeframes. When either priorities or product are owned by the same person who owns people, then mis-prioritization or failure to protect the product are bolstered because anyone who could oppose them is afraid of being fired.
In my experience, the best way to figure out if a company has a prioritization process is to ask about some of the recent things that were built and ask how it was decided that they should be built. If the answer to that kind of question is “[insert executive or manager name here] said we needed it”, that’s a problem. The best indication that a business has a decent prioritization process is that people are able to talk in terms of symptoms, diagnoses, and prescriptions. Companies worth working for can talk about the pain the company felt, explain how they identified the cause of that pain, and tell how they built something to address the cause. Other companies will dance around the issue.
What I really look for
In every case, what I really look for is someone who can give me specifics without blushing. Let’s go back to the example of work-life balance:
In my current job, which I’ve held for around two years now, I’ve worked straight through the weekend (including practically not sleeping) twice. I did that because I was obsessed with a particular analytic problem, not because anyone asked me to or even implicitly suggested that they wanted me to. I can work from home pretty much whenever I want as long as not being in the office doesn’t interfere with anyone else’s work. If you were interviewing with me, I would be able to tell you all of this while looking you in the eye. In fact, it would be obvious that I would be a little excited to be able to tell you about it, because it’s an aspect of the job that highly and genuinely value.
Contrast that with my previous job: I worked straight through nights/weekends about four times a year, and stayed late at work at few times a month, and most of the time I did this because I was told I had to (or was told, with an cynical sort of chuckle, that sometimes “you just have to put in the time it takes to get the job done”, thereby making it known what the expectation was without actually telling me to work around the clock). Work-from-home was not something management had much sympathy for although our department was a little more permissive on that issue than the rest of the company, because I thought it was an important freedom and I was the director of that department. Short deadlines were common and the people who set those deadlines didn’t have much patience for personal issues. If you had interviewed with me for a position at this company, I would have come across as a little defensive. I’d try not to give a patronizing response, but because my managers often adopted the patronizing approach, some of that probably would have bled through. You would have been able to tell that answering the question made me feel uncomfortable.
If something is important to me, it shouldn’t make a prospective employer uncomfortable to talk to me about it. If it does clearly make them uncomfortable, I will probably be disappointed with the situation if I take the job. That holds for all concerns I could potentially have about a job. It’s not a foolproof method, but it’s the best I’ve been able to figure out.
