My first job was in a startup as a software engineer for core telecom products. As it was a startup, I wore many hats, doing end-to-end development, testing, deployment, troubleshooting, and so on.

My first foray into data science was with a Bell Labs project, where I was hand-selected for a team developing a proof-of-concept into a commercial product with 99.999% uptime availability. We collected and analyzed data traffic for telecom operators at scale for insights into fraud, infrastructure bottlenecks, application popularity, and so on. This was in 2010, when 4G was just getting launched and cloud infrastructure was still in its infancy. So, there was a lot of activity in the telecom space, and a lot of folks like me were looking at big data, though there was no term such as data scientist.

That led me to an opportunity on the business side at Rent-a-Center, where they wanted to start an advanced analytics group. They wanted the team to be part of finance—and not IT— and to look at data from the business side, rather than as a pure technology implementation. I formed that team and led it for five years. We looked at a variety of problems, from customer churn and segmentation to interesting questions of how product packaging creates or dilutes value.

After that I was itching for some product development experience. So, I went to Capital One and stayed there as an individual contributor. The mandate was to develop products for operational engineering, for our SREs, so that they could keep the infrastructure up and running and reduce the downtime.

Currently, I am with JCPenney in pricing analytics, where we track a few billion dollars in sales, over 500 stores, and a large and growing ecommerce channel to pinpoint what levers we can pull in pricing to make a significant impact to the bottomline or topline.

The business side has a huge appetite for insights based on data science. Data science teams in business units end up being the bridge between IT and the business. In the IT world, the expectation is to get a clear set of requirements and deliver to them. This is often time-consuming. Business units need to make decisions often and quickly to run their operations, and don’t have the patience to go through complete requirements-gathering processes. Data science teams have to gauge this urgency and scope the project according to their business knowledge. Mismatched gaps will result in lost opportunities.

So, the biggest lesson for me is that, before even thinking about what algorithms, solutions, or technologies you are going to use, you have to understand what people do today, the flow of their data and decision-making. Once you identify that part, you have to test your hypotheses with rapid prototyping and experimentation. With business this is even more important because they will take a decision on problems in a matter of days or weeks. So, you won’t have the time to develop a full-blown product anyway, but you have the time to really understand how they make one particular decision. And these nuggets together will form your eventual solution, product or process that will redefine the whole organization.

The magic in data science happens when a solution is co-created by both the tech and business sides of the world. You need engagement from business for experimentation and hypothesis testing. They bring domain knowledge to the table. On the other end, data science teams should think beyond particular technology stacks, models, deployments, and so on. So, you have to be a little nimble, a little open to playing by the ear. Initially there is ambiguity and awkwardness across the team. But when the joint solution appears, it is magical.

Building this mindset of customer success is a crucial aspect of managing and building high-performance teams.

One thing every candidate must understand is where their role is located, because the requirements are completely different. IT is typically responsible for deployment and getting all the data together. So, data engineering and DevOps definitely go to the IT side.

In the job description, if you hear terms like business insights, pricing analytics, or business analytics, but are expected to have some skills in Python, R, data science or machine learning, then you know that you’re going to be on the business side. The expectations are that you understand and help them with the IT language, are willing to learn the business, and understand that you’ll be dealing with people and not just data. So, you need a combination of hard and soft skills.

I’m looking for people who have soft skills and tech skills and are just looking to solve interesting problems, irrespective of their tech background/department. You need enough computer science skills to do enough coding, development, and at least some prototyping. You also need to have interest, if you don’t have prior exposure, in understanding the business. And the third aspect is you need to possess deep data science skills.

When you get together this group of generalist puzzle solvers or problem solvers, they get excited and motivated when there is a good problem to solve. The challenge on the business side is that problems appear like shooting stars. So, there are times when there is a lull period where typically, there is no immediate problem. But during this time, you need to build different data sets, aggregating and curating them so that they can be used later. A lot of data scientists think data engineering is for somebody else.

A challenge arises when the A-players on your team feel that they may not be solving all the A-grade problems and their work doesn’t make an impact. So, you have to keep the team motivated, to show them the bigger picture. My typical speech at that point tells them that it’s going to take them a year-and-half to curate and understand the business processes. But by that time, they are probably going to be the only experts in the company that can see things end-to-end.

Some data scientists don’t have the patience to see this long scheme and they get stuck on building the next best tech stack or trying some algorithm that they read about on Medium or a blog post or saw on GitHub. They get stuck on the tools rather than the big picture.

Also, technology is changing at a very rapid pace. So, there’s a big sense of FOMO every time people read about a new technology.

I think the biggest mistake is getting stuck in the old way of interviewing, where you set up a very fancy coding challenge because there are websites available for that and it’s what your HR knows. So, you send an initial impression that you are looking for very cutting-edge technologies, but none of this gets applied in your day-to-day work. And that creates a disconnect between what was promised or indicated and what is actually happening on the ground.

For my team at JCPenney I look for candidates with three skill sets, as I mentioned earlier. I look for signs to show your interest in business: perhaps investing in stock or reading about business or some models and so on. Then, there are the hardcore data science skills—what types of methodologies, processes, algorithms, tools, tech, you have used on the job or somewhere outside. The third aspect is your programming and computer science skills, what technologies you know and are comfortable with.

This is what I communicate to the HR or the recruiter. They look for keywords associated with these skills. Once they identify candidates and have a preliminary conversation, they forward the resumes to me. I read their LinkedIn profiles to form an initial assessment of the candidates’ fit.

Typically, once the HR recruiters have met with candidates and covered the logistics about expectations, visa status, and so forth, I meet up with candidates. I don’t have a predetermined set of questions in mind but am looking for people who are eager and have done work outside their job title. I’m looking for people who are willing to identify and solve inefficiencies in their work even if it’s not their job. Once they have interviewed with me, I set them up with an interview panel for diversity. This will involve a series of technical, job fit, culture fit, and HR interviews. Based on the feedback, the decision is made collectively or internally with a few others in my immediate organization.

The must-haves are definitely tech skills. But they should be relevant to the role they’re applying for. Mentioning tech skills that aren’t needed for a project is definitely a red flag. It indicates you like the tech for the sake of tech. That doesn’t fly well with business.

List some projects that you did and the school or program that you are graduating from. I’m not looking for a pedigree per se, but for a pattern of how you progressed through school, what projects you did and what your interests are. In my mind there is no good or bad. So, express who you are, with the mindset of where you want to go.

If you are a believer in something tech-related or like to geek about something, talk about it. That gives me a perspective of what type of person you are. Sometimes I can modify a role based on what suits a candidate and the vision that I have for the team.

If you are starting off, you should definitely go to LinkedIn and other portals and find out the templates that are being used. Once you settle on a template, look for the content for that template based on what you have done. And if there is something you haven’t done, put up a plan to achieve it, whether on your job or as a side project. That drive definitely shows up in your resume.

First, tell me about your projects, what you’ve done in school or outside on your jobs. Second, tell me what you do outside your job, whether tech-related or not. That gives me a peek into your interests, your personality. Third, tell me something about what you use for growing your skill set—what you read, where you spend your time, how you sharpen your skills. I want to know if you are on a road to be successful 10 years out or if you are going to stagnate in a few years. My biggest criterion for hiring is whether a candidate can replace me in a few years. So, I’m looking for all the skill sets that I found helpful for my career growth. If you have a blog, GitHub or Medium account, or a YouTube channel, or whatever, put it out. That will definitely leave a mark on me.

To begin with, understand the landscape of the position you are coming in for; who is on the interview panel, what are their roles, are they tech-oriented or business-oriented unit, what is the composition of the team, your future manager and so on. Next, ask about the day-to-day activities carried out by this role, by the team, by others. Once you have the complete picture, figure out how you can add value to the org. Think about the problems & business usecases, projects, keywords, and decision-making criterias that are relevant and think of solutions for them.

If you see a gap you can fill, talk about it. If a team is tech-driven, talk about the technologies you have used, the failures or challenges that you have encountered while using them, and about the things you have explored to compensate for and circumvent those challenges.

Have all those talking points ready. The worst thing that you can do in an interview is to come in expecting to think on the spot and answer questions.

If you’re coming for data science, you definitely need Python. Then, at least make a list of all the different models/technologies that exist, for example, regressions, forecasting, neural networks or reinforcement learning, recommendation engines, graphs, etc. Understand the math behind them, their applications, what assumptions go into them, and where can you use or not use them. Be very good with your math and the science behind the algorithms.

Once that theory part is done, go on Medium and search for tutorials on whatever you’re interested in. Go to Kaggle and figure out some of the competitions. If you’re thinking about forecasting, pick up a forecasting problem and try to solve it. There are so many data sets and even more tutorials online. Implement them as they have been implemented. Then take a different data set and implement it as you would have implemented, without looking at the code. So, experiment and learn from your experiments. If you have done this, you have achieved the average. Now if you go on Kaggle and solve a challenge there, or if you go on GitHub and write a code there for something relevant, you are above average.

Look for experiences. Don’t go after the brand name, don’t go after pay. Go for teams that are trying to solve a problem for which they may not have the resources. That is a good thing because it means there are no restrictions, and you can go as deep or as broad as you want to in that role. If you can get experience in a startup, by all means try that.

The most important thing is to look for people who are interested in being your mentors while you are at that job. Then patiently learn and absorb. And when you feel that your growth is stagnating, your experience is stagnating, it’s time to move on.

My team typically deals with pricing analytics, which is a subset of all the problems that JCPenney is trying to solve. In pricing analytics, we look for answers on questions like when to increase or decrease the price, what the right price is, what is the time window for the right price, and where to go next on a price. We are trying to combine and curate data for how the market or our competitors play with their prices. We also look at how JCPenney customers interact or respond to our prices, our experiments. Finally, we look at our product itself and the profitability and internal metrics for it. We’re curating data for all these three domains right now. In six months or a years’ time we will be at a point where we will be proposing solutions that will have a wider impact than the way things were done earlier. If you come and work for this team, the one thing I can guarantee is that you will feel like you are in a startup because there are no restrictions on what we can or cannot do.