Data scientist career guide

Karun Thankachan begins with the scale of his mentoring work: thousands of bookings and several thousand one-to-one conversations with aspiring data professionals. That exposure shaped his view that most candidates do not lack another certificate; they lack a coherent project, a credible explanation of their decisions, and a job-search system they can sustain.

The most common portfolio mistake is using a toy dataset exactly as a tutorial used it. Karun wants a project tied to a recognizable business problem, with messy data, constraints, and an explanation of why the result matters. A hiring manager should be able to see judgment, not merely that the candidate executed someone else's notebook.

He separates model metrics from business metrics. Accuracy, precision, recall, or error can describe a model, but a company still needs to know whether the work changes revenue, cost, risk, retention, or another decision. Before selecting an algorithm, he recommends a literature review and a reasoned argument for why that method fits the data and objective.

Karun ranks strong projects first and networking immediately after. In a market flooded with applications and AI-tailored resumes, a referral or informed introduction can get a real person to inspect the evidence. Networking cannot rescue weak work, but good work is easier to miss when nobody inside the company knows why it is relevant.

A polished portfolio site is the final layer, not the foundation. Karun would first build and document projects, then make the resume and outreach clear, and only then invest in presentation. Candidates often spend weeks styling a homepage because it feels productive while avoiding the harder work of producing a defensible analysis.

His own path moved from computer science into full-stack work, data analysis, Hadoop, and predictive machine learning. Each step exposed a different part of the pipeline and eventually convinced him to pursue a master's degree. The progression was not a sudden switch into a fashionable title; it accumulated through adjacent work and growing technical depth.

Karun's first graduate-school application round targeted only five ambitious programs and ended in rejection. In the next round, he spoke with mentors and Carnegie Mellon alumni, then rebuilt his statement of purpose, recommendations, resume, and project narrative. The result taught him to treat applications as artifacts that require external review, not private declarations of ambition.

He later studied at Carnegie Mellon, completed an Amazon internship, and moved through data-scientist and applied-scientist work before becoming a senior data scientist at Walmart. The sequence matters because his interview advice comes from both sides of the market: applying for roles and evaluating the skills those roles use on real teams.

Carnegie Mellon's value, in his experience, came from demanding faculty, accessible teaching assistants, and assignments that forced students past surface familiarity. He notes that some course materials are openly available. The brand helped, but he emphasizes the rigor of solving hard problems and receiving feedback rather than treating admission itself as the transformation.

For machine learning depth, Karun highlights introductory machine learning, introductory deep learning, and machine learning for text mining. Course names and availability can change, but the combination illustrates his preferred sequence: establish broad foundations, understand neural methods, and then practice on a domain where representation and evaluation are genuinely difficult.

He describes a multiclass deep-learning assignment that required choosing model structure, layers, augmentation, and an objective rather than merely calling a library. The learning came from explaining each choice and seeing how it changed results. That is the kind of project detail candidates should be ready to discuss when an interviewer asks what they personally contributed.

Karun warns against brute-forcing every model. Start with a baseline, inspect errors, form a hypothesis, and choose the next experiment because it tests that hypothesis. This makes the work faster and the interview story stronger: instead of reciting a leaderboard, the candidate can show a chain of diagnosis, decision, evidence, and revision.

During his internship search, Karun had projects ready early but began networking later than he now recommends. He still applied cold, but learned that relationships should be built before an urgent request. The historical recruiting tactics in this episode reflect his experience; candidates should still confirm current timelines and hiring practices with each employer.

His preparation routine placed applications at night, coding practice in the morning, and theory review in written notes. Dividing the work prevented one task from consuming every day. The exact schedule is less important than covering three distinct requirements: getting into processes, passing coding screens, and explaining statistics and machine-learning decisions.

A useful connection request should mention a specific job ID and one project or experience that matches it. 'Please refer me' gives the recipient no reason to trust the fit. A short, targeted message reduces the work required to help and shows that the candidate read the role rather than sending the same appeal to hundreds of strangers.

For coding interviews, Karun recommends learning patterns across arrays, strings, and dynamic programming rather than counting solved questions. Lists such as Blind 75 can define a manageable syllabus. The aim is to recognize a structure, discuss tradeoffs, and implement reliably, not to memorize thousands of isolated LeetCode answers.

He organizes data-science interview preparation into three pillars: coding and data work such as DSA and SQL; statistics and foundational machine learning; and specialization in the hiring team's domain. A candidate who studies only algorithms may still fail because the role needs experimentation, product judgment, forecasting, NLP, recommendation systems, or another applied depth.

Product data science and applied data science often reward different strengths. Product roles may lean heavily on SQL, metrics, dashboards, experiments, and causal inference. Applied roles may spend more time building and improving models. Titles vary by company, so Karun recommends reading the actual responsibilities and preparing for that team's work rather than the label.

His compact foundation list includes linear and logistic regression, K-nearest neighbors, K-means clustering, support vector machines, and decision-tree ensembles. Candidates should know assumptions, strengths, weaknesses, and failure modes. Naming an algorithm is easy; explaining when it is inappropriate is often the stronger signal of understanding.

After the foundations, interviews may test specialization through system design or a case study. Karun uses a hypothetical Instagram recommendation surface as an example: define the objective, data, features, candidate generation, ranking, evaluation, and rollout. Product-data-science cases may instead ask for metrics and root-cause analysis after a sudden change.

A master's degree can accelerate access to some roles, but Karun does not call it the only route. A data analyst who becomes strong in SQL, experimentation, statistics, and product reasoning can move toward product data science. The feasible path depends on the role, employer, prior experience, immigration constraints, and current market.

He distinguishes data engineering as the work that makes reliable, usable data available at scale. Streaming, distributed systems, orchestration, and operational quality sit closer to that function. Data scientists consume those systems to analyze or model, while machine-learning engineers often focus on deploying, scaling, and maintaining models. Company boundaries still vary.

For midlevel hiring, the three pillars remain, but the resume story changes. Junior candidates emphasize implementation and learning; experienced candidates should show problem framing, design choices, influence, and measurable outcomes. Karun also shares that an urgent market once led him to accept a lower level and foreground hands-on execution rather than wait indefinitely for a perfect title.

A data-science project often begins with a roadmap and business problem, followed by discovery, data-quality checks, and a requirements document. The model is only one phase. Karun's account makes clear why interviews ask ambiguous cases: the job includes translating a business question into work that data, engineering, and product teams can actually execute.

Experiments may run for four to six weeks before a first version is compared with a non-machine-learning baseline. Teams then use A/B tests and error analysis to decide whether complexity earns its cost. A sophisticated model that does not beat a simple rule in business impact is not automatically the better product.

Karun's working toolkit spans Python, research search, generative-AI assistants, cloud platforms, PySpark, Docker, Airflow, and visualization tools such as Tableau. The list is descriptive, not a mandate to learn everything at once. He recommends choosing tools through the problems a target role solves and proving that knowledge in an end-to-end project.

He views generative AI as another layer of abstraction that can increase productivity without removing the need for logic and domain expertise. That is his outlook from the recording period, not a guarantee about future hiring. Candidates still need to evaluate output, understand the business, and explain decisions that an assistant helped produce.

Karun's closing advice is to stay current through a mechanism you enjoy: mentoring, reading, building, teaching, or following a focused set of practitioners. Fear-driven learning is hard to sustain. Keep an open mind about new tools, but avoid treating every announcement as either salvation or doom; test what improves the work in front of you.

Naman closes the episode after a practical masterclass spanning projects, graduate school, networking, interviews, role boundaries, and day-to-day data science. The advice is preserved with its original context and should be adapted to current job descriptions rather than treated as a permanent universal hiring rubric.