Life as a Data Analyst: Between Perfectionism and Pragmatism

Data people are the engine of BizMachine. We sat down with Honza Fait, our Data Lead, to talk about the expectations new data analysts bring when they join the company.

We wanted to know what juniors need to learn first. We also touched on how he motivates his team to enjoy their work at BizMachine.

Data science, and its combination with economics programs, is starting to appear at various universities. How well does this education prepare graduates for real-world work?

I’m a fan of formal education in data science because it gives graduates a foundational mindset and tools for solving problems. When working at BizMachine, though, you also need to understand that on the other side of a data pipeline or statistical model is a person who needs to understand the results, trust them, and put them into practice.

How do you help graduates learn to apply data science in practice?

Data is our engine. Data analysts must find a compromise between a technically perfect solution and delivering understandable outputs to the customer.

What do data analysts need to learn in their first year?

First, they need to learn to critically evaluate their own work and process. For example, being able to answer several questions: how do I verify the number I just calculated? What informational value does what I just discovered have for the end user? If I work on this for six more hours, how much will the result improve and how much more satisfied will the customer be?

What entry-level skills should a data analyst have?

An ideal junior analyst naturally understands relational databases, object-oriented programming, and basic statistics. But without interest in the client situation they’re solving, willingness to work through dirty (disorganized, inconsistent, nonexistent) data, and a degree of technical creativity, none of the above will ultimately open the door forward.

What does the BizMachine data team look like?

There are nine of us so far. A mix of different personalities, backgrounds, and contract types. The common denominator is low turnover and plenty of self-deprecating humor.

In the early days, we wanted everyone to be able to code, write predictive models, do segmentation, data mining, and database design. As the team has grown, individual talents and interests have gradually crystallized. We try to maintain a balance between our own product development and client projects — we need good coverage and want people not to stay buried in the complexities of our own data backend, but also to be on the front lines, seeing what information clients use or lack.

I think we differ from a typical BI team at a large company in the breadth of our scope. At BizMachine, the data team develops its own software solutions beyond analytics and reporting, choosing technologies and deploying them to production — whether web applications, custom libraries, or components of our Azure cloud. This develops competencies and practices more common in engineering — version control, code reviews, continuous deployment, and more.

Should a data analyst or specialist understand business? Would it be useful if they studied economics, for example?

They don’t necessarily need economics. I’d compare BizMachine’s requirements more to a consultant’s abilities when entering a new environment — they need to create a basic framework, a set of questions to evaluate the client situation. Specifically, this means understanding the client’s market: what capacity does the client’s sales team have, how long is their sales cycle, what’s the competition, how fast do they want to grow. Answers to these questions help choose the right approach, dictate requirements for segmentation or model accuracy, and reduce iterations between the brief and final implementation. What we’ve all learned over the years about how companies in various industries operate through analyzing their data, I consider an unspoken company benefit. It’s a very useful overview of the European B2B market.

What advice would you give to those who are just starting with programming and have learned maybe one specific technology?

If I could go back to my own beginnings, I’d invest more in the ability to break my program or process into functional units, each solving one problem, rather than a specific language or technology. In my early days, I focused on programming in R (R Language for Statistical Computing) and tried to deeply understand the language, syntax, and libraries, but my lacking ability to structure solutions well held me back.

My absolutely strongest recommendation is for people to pick a problem they want to solve themselves — rather than a problem assigned by a teacher or found in a tutorial. They’ll learn the most from real problems.

‍

My absolutely strongest recommendation is for people to pick a problem they want to solve themselves — rather than a problem assigned by a teacher or found in a tutorial. They’ll learn the most from real problems.