The hosts of the Data Neighbor podcast interview Sandy Besson, an AI research engineer and ecosystem lead at IBM Research. The conversation ends on two positions she holds. First, an LLM's value comes from the system built around it, so reliability should be enforced at the framework level rather than left to the model's reasoning. Second, data scientists should learn above and below their stack and show it with public projects.
The role. Sandy's team runs like an incubator. It turns research from IBM and other labs into applied product, builds first-of-their-kind use cases, and open-sources the results. She tries to experiment with something new every week, at the time of recording Claude's newly released skills, and folds what works into an open-source agent framework focused on security and reliability.
Agents and frameworks. She defines an agent as an LLM calling tools in a loop until a task is done, with the framework as the code that actually executes the tools. Her team's "requirement agent" restricts which tools are exposed at each step, which prevents loops, skipped validation and premature answers, and lets smaller models compete. A co-host counters that models are improving quickly. Sandy concedes the point but expects the next leap to come from new architectures.
Tools and access. For dabblers she points to low-code builders and to vibe-coding sites that let a non-front-end developer build a website over a weekend, while she herself builds in code. The hosts compare workplace access. Their companies hold several enterprise licenses, and the host's legal-tech employer allows customer data only with zero-retention providers. Sandy concludes that no provider has clearly won.
Evals. Sandy says no benchmark tests frameworks themselves, as opposed to models, and that failure rates move whenever the model or the tools change. She separates LLM-as-judge and agent-as-judge validation from benchmark and feedback evals. The host adds that silent model updates are a sharper version of classic drift.
Systems and careers. Sandy sees coding agents and judges turning from single steps into systems, and a co-host notes that system design has always been the core skill. Her career advice for data scientists is to learn below and above their stack and build in the open, because she judges candidates by repos that show how quickly they learn. Along the way she observes that many of the AI people who bridge research and public-facing work were once theater kids, herself included.
The hosts of the Data Neighbor podcast interview Jigyasa Grover, an ML engineer at Uber, author and course instructor. She argues that agents fail at scale through weaknesses in the parts around the model: data, evaluation, memory and security. Her conclusion is that scalable evaluation, adversarial evaluation included, is the real barrier before agents can run autonomously, and that until then high-stakes decisions need a human in the loop. Critical reasoning is the human skill she would keep sharp.
The lifecycle over the model. She tells listeners not to chase the newest model and to think end to end instead. Well-governed data separates a working model from a production system. Evaluation is roughly "100x" harder than in classical ML because it has to be qualitative as well as quantitative, and every user behaves differently. The host adds that the same user's tolerance for imprecision changes with context.
Agent types and guardrails. Using Google's Agent Development Kit as her reference, she separates LLM agents from workflow agents (sequential, parallel or loop). Her travel-assistant example orders a weather check before the packing list, with events and an itinerary built in parallel. In her view workflows are themselves a guardrail. Constraints still need dynamic calibration through feedback, and a co-host adds personalization as a further guardrail.
Memory. She breaks agent memory into long-term, mid-term and short-term memory, and the work into retaining, retrieving and reasoning. Context-window limits and latency make it hard to retrieve exactly enough. She also admits she can't map human mid-term memory onto anything in current systems.
Where traditional ML stays. Asked where LLMs are being forced in, she says structured prediction such as recommendations belongs to traditional ML, which is faster, cheaper and easier to measure. LLMs augment it through explanations and feature engineering. The host describes using LLMs to create variables for causal models.
Evaluation and attack surfaces. Looking ahead to consumer agents, she says the battle is evaluation for agents that negotiate with other companies' agents. She lists the attacks: LLM jacking, prompt injection to pull another user's card number, memory poisoning, compromised API keys and social engineering. Her countermeasures are specialist adversarial testing, continuous monitoring, and role-based memory access with no cross-contamination. The host observes that most evals he sees check answer quality, not security.
Wider effects. The hosts move on to children who trust voice assistants over their parents. Jigyasa warns of over-reliance and misinformation, and a co-host argues for foundational education on how such systems work. She describes her own split of tools at the time of recording: GPT-5 for productivity, Claude Sonnet in Cursor for code, Glean for onboarding and Perplexity for research. She also raises the dilution of the human signal in training data as AI content spreads, content-provenance labels, and a shift from SEO to "GEO", optimizing to appear in LLM answers.
This episode of the Data Neighbor podcast interviews Barry, CEO of Hex, which he confirms raised a $70 million Series C a few months earlier. He argues that agents can multiply data work only on top of curated context, and that the data team's job shifts toward building and watching over that context. He ends by warning that no tool, Hex included, fixes a data team that is not invested in partnering with the business.
Why Hex exists. Barry says he started Hex to fix a problem he had himself. In his account, 80% of the effort goes into dashboards, but 80% of the interesting work happens outside them, in notebooks, SQL and spreadsheets, and gets shared as screenshots in decks. Hex moved that work to the cloud, made it collaborative and added native SQL and chart cells. It also infers an execution DAG from the code by static analysis, which he calls an early breakthrough. AI became Hex's main focus a couple of years ago and, he says, close to its sole focus this year.
Product-market fit as a moving target. Barry dates real fit to two or two and a half years in. Early this year he began telling staff "we don't have PMF", despite tens of millions in revenue, because the frontier moves daily and a quick AI hit is easy to copy. What compounds, he argues, is sustained product taste and an engineering team that can build reliable systems. Hex uses Cursor and Claude Code, but he says you still need engineers who understand the system.
The demo. On demo data, Barry asked Threads for the top-performing reps by customer segment. It searched existing projects, semantic models and tables, ran warehouse queries with visible SQL, and returned findings with charts that can be edited. Saving it as a project opened the underlying notebook and its DAG. There the notebook agent built a 12-month forecast, and the app builder published the result. Barry frames this as a "virtuous cycle" in which published work becomes context for the people who self-serve. He then showed semantic models imported from Cube, Snowflake and dbt, or written in Hex as YAML with an agent that suggested additions, validated them and listed the projects that reference the model.
Where data roles go. Barry predicts that agents will take over the stream of quick questions. Data teams will spend more time on deep dives, on curating knowledge and on "insight observability" over the answers other people get. Where the role ends up in 3–5 years, he says, no one knows. New customers, he adds, need context curated before Threads is turned on, and Hex is now embedding closely with them to build it.
Closing advice. Barry says he has told some prospects not to buy Hex. They wanted a chatbot to satisfy business users, and he argues the real problems are people and process, which a tool cannot solve on its own.
This episode of the Data Neighbor podcast interviews Umang, a machine learning engineer at TikTok who previously worked at Amazon. He ends up at a four-part prep plan and one main piece of advice: be patient. He treats an ML job search as a funnel that needs four to five final loops to produce one offer.
Getting in. After undergraduate courses in India, Umang spent six months as a research assistant at a university in Singapore, then did a CS master's at UMass Amherst. Amazon placed his internship on a checkout web team writing Java JSP. He had to accept a full-time offer on that same team, but Amazon has no lock-in period. He messaged five or six hiring managers, interviewed informally with six or seven teams, got offers from three or four, and moved to Prime Video forecasting about three months into the job. His early external interviews failed because he was a generalist, until he went deep in one area.
AI at work and in prep. At TikTok he detects coordinated bad behavior on the US platform. He says the work has moved from heuristics to classical ML to LLMs, which also explain which policy a suspended account broke. He uses a Gemini Pro subscription for code and long documents, and practices ML system design with Grok. He says most mentees still prepare from books.
Mentoring. Umang says he has helped a web developer and a data analyst move straight into ML roles, which he calls feasible at entry or mid level over 6–12 months but very hard at senior level. He separates interview skills (trade-offs, intuition) from deep framework knowledge and recommends both. He reports that big-tech interviews remain traditional: Meta's announced round allowing LLMs had not rolled out as far as he knows, while startups often allow them.
The plan. He predicts the market stays tough through 2026. He sets targets of 100+ applications, 10+ screens and four or more final loops, and splits prep into ML fundamentals, ML design, ML system design and ML coding, with one or two resources for each.
This episode of the Data Neighbor podcast interviews Manoj, formerly head of engineering for data and AI platforms at Intuit and earlier a senior engineering leader at Meta, Cloudera and Apple. Across the hour he argues one thing: treat data engineering and enterprise LLMs as platforms built proactively, not as services that react to each request. He ends with a prediction that by 2030 the best data organizations will be "super boring in a good way". In that future, AI answers anyone's question through a text box, and the remaining data staff build the context and guardrails behind it.
Lessons from scale. He opens with two experiences. A well-funded biotech data warehouse "choked" when it reached production scale, and he took from it humility and a rule that his teams now ramp traffic gradually with canary releases. At Facebook, small autonomous teams shipped models to billions of users in weeks, which taught him the value of autonomy and removing blockers. He credits the triad/quad leadership model used at Intuit and Meta, in which data, product, UX and engineering leads jointly own a roadmap and its impact, with breaking down knowledge silos. For less mature companies, he suggests defined engineer rubrics (product specialist, framework specialist, module builder), with people covering each other's gaps.
Platform as a product. He predicts the service model of one pipeline per KPI request will become "extinct", because data volumes will grow 4–10x and maintaining pipelines costs more than building them. Teams that clone pipelines produce a dozen versions of one KPI that leadership cannot reconcile. He prefers common ingestion per domain entity, which he puts at about 20 pipelines rather than 100, with lineage, governance and self-serve KPI access that could automate much of analytical engineering. Every pipeline, model and table should have an owner, a roadmap, documentation, an SLA and a contract.
The 3Gs for LLMs. He compares LLMs to Formula 1 cars that crash without roads, guardrails and a pit crew. His recipe is to ground the model in cited sources of truth with a human feedback loop, guard data with privacy by design and masking, and govern it with fairness, accuracy and drift metrics, audit trails, cost-per-answer scorecards and golden-set regression. AI breaks, he says, not on what it generates but on what it is not grounded in. A host recalls war rooms where a metric dropped because a model feature had drifted without raising an alarm.
Squads under constraint. Before a launch, a product squad moves a baseline KPI from X to Y while a platform squad builds the reusable foundations in parallel. Startups short of engineers should cut both squads down to one pain point and one module rather than give up the platform squad.
2030 and beyond. He sees fewer data engineers and scientists, but new squads for enterprise "contextual awareness" and for prompt and cost tuning. He rejects the idea of outsourcing the whole data function, because a company's knowledge of its own products cannot leave it. His closing advice is to work from principles, learn and unlearn, love the problem rather than the tools (he cites Informatica), and speak in outcomes measured against a baseline.
This episode of the Data Neighbor podcast is an interview with Aman Khan, head of product at Arize AI, an eval and observability platform. His position is that how much evaluation an AI product needs depends on its scale and its stakes: a quick local eval for a hobby app, scrappy hand-grading at around 100 users, and eval-driven development with gates and production feedback at scale. Whatever the stage, evals have to be tied to the business outcome, not just to rule-following scores.
What an AI PM is. Khan describes three overlapping roles: PMs whose core product contains a non-deterministic model, platform PMs concerned with model choice, fine-tuning, cost, latency and security, and "AI-powered" PMs who use AI tools to prototype and analyze. He expects them to merge as AI becomes as common as the database.
What an eval is. Where a lending model once retrained on whether loans defaulted, the LLM-era equivalent is a customer-support bot's thumbs up or down. Evals go further: code checks such as edit distance, and an LLM judge grading tone, correctness or rule following, aligned to a human-labelled set of about 10 to 100 examples. He accepts the "evals are just unit tests" meme only in part. Scores should rise when a change is made, but the same input can give 10 different outputs, so tests must allow for variance.
Three workflows. In the first, for apps built for yourself, you ask Claude Code or Cursor to write a local eval. In the second, at 100+ users, traces go to a spreadsheet or Airtable for thumbs-up grading and early error analysis, which he says will not scale. The third, for thousands or millions of users, is eval-driven development: evals as requirements, gates against breaking changes, A/B tests of models, and a way to catch disagreement, such as a refund correctly refused that the customer still rates badly.
Business outcomes and accountability. A host compares this to defining success criteria before launch. Khan asks what happens when the eval is good but the business metric is not, and who labels the data. His example is a data practitioner accountable for the eval metric while the PM owns the outcome. Using companion and therapist-style agents, he argues that multi-turn and session-level evals matter, and that sometimes users need to be challenged rather than simply helped.
Form factor and tools. Khan points to Claude Code as an early sign of product-market fit in a terminal interface. He cites reading that coding tools currently help less-technical people more than deep experts, and the hosts agree from their own work, including a team retro where someone said they would have been faster without AI.
Four principles and latency. Khan's framework for deciding eval effort covers the user (the CEO test, the intern-in-front-of-a-client test), the value of being right and the cost of being wrong, tolerance for waiting, and where the eval sits, from offline tests to a pre-display guardrail. On waiting, he describes a Claude research-mode query that usually takes about 5 minutes running past 15 with no indication of when it would finish. He proposes classifying a question's complexity and showing an ETA. One of his prompting experiments is to append "anticipate three more problems" so the agent keeps working.
Data teams and insight. A host says many companies are still trying to trust their data at all. Khan calls getting insight from aggregate data the hardest problem, which Arize is working on with its own analysis agent, "Alex". He also predicts that, with AI-written text everywhere, better human writing will be "the next alpha".
In this Data Neighbor podcast episode, the hosts ask Lohit, a technical principal product manager at ServiceNow building agentic systems and formerly at Adobe, how a data team swamped by ad hoc questions could build a chatbot to answer them. The conclusion is that natural-language business intelligence is close but behaves like a junior analyst: the team must own definitions and governance, constrain what users ask, test internally against the most frequent questions, and treat the agent as a permanent investment rather than a feature to switch on.
From rules to language models. Lohit traces a path from insurance chatbots in 2018 through five years at Adobe, from regex to machine learning, deep learning and LLMs. Early bots were limited in understanding, kept no context, and mapped one detected intent to one predefined workflow; a misspelling or a pause broke them. LLMs handle multi-turn conversation and ambiguity, reading "next weekend" in a trip request as a date range.
How close natural-language BI is. Lohit says "we are almost there": a system translates a question into SQL, fetches the rows and summarizes them, like a junior analyst doing about 70% of the job under supervision. Shane recalls dismissing a vendor's "data scientist in your back pocket" pitch years ago, and contrasts it with Cursor and Claude Code now writing to Snowflake for an evaluation pipeline he is building at work, because they can see how the tables were made. The gap Lohit names is business context: teams define churn and active users differently, models will not fix inconsistencies unless told how, governance must decide what is sensitive (a manager's name yes, a manager's salary no), and models choose poor charts while staying confident when wrong. Shane's view is that writing these definitions down becomes even more important.
Designing the agent. Lohit would surround the chat with dashboards, existing KPIs and frequently asked questions, so users see what the system can answer. Text-to-SQL is rated moderate-to-difficult and getting the right information hardest, since a question about data that does not exist will still pull some sales table. Responses would be graded fully or partly correct or wrong, with errors sent to a data engineer and turned into hints; accuracy should move quickly from 30–40% to 80%, then slowly from 80% to 90%.
Earning trust before launch. A co-host raises the risk that stakeholders abandon a bot after two or three wrong answers. Lohit's answer is an internal beta the data team tries to break, then a smoke test on the top 15 most-asked questions in varied phrasings; a "95% confident" label means little to an executive. Suggested tactics are RAG for definitions, query transparency, human review and a hoped-for live fact-checking system. Shane frames early versions as data collection on what the bot can and cannot answer, starting with low-risk, time-consuming questions, and predicts someone will one day publish an AI-botched earnings report.
Mindset. Shane closes that this is ongoing investment and that today is not the limit of what AI can do, citing a line he attributes to Kevin Weil on Lenny's podcast. Lohit adds that not every company needs to solve this itself, and the co-host notes the warehouse vendors are pursuing it.
In this Data Neighbor podcast episode, two co-hosts interview Siddharth Ranganathan, a director of data science at Microsoft, on what separates a data scientist who executes from one who is strategic and gets promoted. The answer arrives as a tagline: stop being the person who answers questions and become the one who frames and challenges them, judged by outcomes rather than outputs, and treat each promotion as a job application with patrons, a prepared manager and deliberate visibility.
What good looks like. Ranganathan defines good data science as decision-focused rather than complex: it starts from the right question, is scientifically sound, balances speed with substance, fits business context and works across functions. The example is a hurricane-era analysis of marketing campaigns, given as a directional answer in 3 or 4 days and followed by a full study. A co-host describes PhD statisticians who resist anything short of a causal model, and argues that quick hypotheses tested by experiment often beat six months of modelling.
Trading speed against rigor. Ranganathan starts from the decision and the cost of being wrong, defines "good enough" up front, builds for reuse rather than perfection, and brings stakeholders into the trade-off by offering a fast directional answer or a two-week deep dive. The coaching framework is speed versus rigor, simplicity versus accuracy, local versus global, short versus long term, and impact quantified in advance, without slowing a bias for action.
Misreadings of product data science. Ranganathan lists four myths: that the job is building ML models, that it is purely technical, that A/B testing is easy, and that data scientists only react to requests rather than sitting at the table in product pods. Aspirants who want ML work are steered by whether they care more about coding or business problems, since ML roles have drifted toward software engineering.
Becoming strategic. The shift is from outputs to outcomes, from a dashboard to an insight: read OKRs and strategy documents, ask the PM's biggest unknown, ask clarifying questions, form a point of view, and influence rather than inform. Résumés that cite only model accuracy, seen while growing a team from 4 to 25 this year, illustrate the miss. For a team used to saying yes, the method is to weight requests by the OKR they move, how much and how fast, check engineering bandwidth, and park the rest.
AI and the role. Ranganathan expects role-based agents, such as a marketer or capacity-planner agent, within a year or two, and a long-run merging of technical and business work. Product data scientists mostly treat AI as a feature measured on engagement and retention, though some will write custom eval pipelines; applied scientists need deeper agent knowledge.
Promotion and visibility. The traps are execution mode, activity mistaken for impact, technical depth alone, solo work, weak communication and comfort. Ranganathan frames promotion as applying for a new job: impact above level, ownership, patrons at the target level, and the manager as the referral who needs a complete case. Visibility means impact at the right scope, as with Meta expecting org-level impact at IC6, plus forums such as monthly business reviews and volunteering for new initiatives. A co-host adds asking what readiness requires several cycles early and a "road show" of rehearsals. Ranganathan names breaking down an ambiguous problem as the most underrated skill.
In this Data Neighbor podcast episode, Shane and two co-hosts interview Mahesh Yadav, an AI product manager who has worked at Microsoft, Meta, Amazon and Google and runs a Maven course on agentic AI product management. Yadav's argument is that building agents is now cheap and evaluating them is the real work: ground truth for the objective part, expert-derived yes/no checklists that make helpfulness, honesty and harmlessness objective, and validated LLM judges only where they meet the bar. It ends on a forecast of new roles, product makers and AI evaluation scientists, alongside engineering that scales what they prove.
What changes with agents. Discovery, design and deployment remain, but Yadav lists three shifts. Building costs only a prompt. Scaling does not: what works for 5 people takes 10x more effort for 50 and again for 500, because quality is a matter of taste and someone must define "right". And the rule set evolves as users trust the agent; an email agent that flags contract risks is soon asked to enter them in HubSpot, raising the stakes so that a dropped zero buys $10 million of insurance instead of $1 million. Shane adds that users forgive a recommender's misses but not an assistant failing an easy task.
Precision, recall and first impressions. Yadav explains precision and recall with a song example of 10 true positives among 12 returned. An AI product at Google between users and support saw 85% drop after the second interaction, so assistants must be precise, whereas Netflix can rely on recall. In Yadav's telling, TikTok's 60-second format made feedback part of the product, letting it throw varied videos at users and learn from early swipes, where Facebook leaned on the social graph.
Building an evaluation. For a contract-risk agent, Yadav would first narrow scope, to NDAs or master service agreements, contrasting Windsurf's focus with Devin's broad hype. A domain expert's past reviews supply ground truth for accuracy, precision and recall, plus cost measures such as time, tokens and attempts. Then helpful, honest and harmless, a framework Yadav claims while granting Anthropic or Google might too, become checklist questions learned from experts: a helpful liability answer states the amount, explains it, says when it applies, and cites a source verifiable in under 2 seconds. Yadav's current project runs 70 helpfulness, 30 honesty and 27 harmlessness checks, given as 132 questions, yielding scores like 78% helpful, 64% honest and 3% harmful that a leader can accept knowingly, publish, and run against competitors. Shane describes his own coverage, quality and faithfulness families; a co-host summarizes the job as making subjective things objective, which Yadav endorses. The scores also let a team launch on an expert's sign-off rather than whichever executive last tried the product.
Scaling the judges. Experts are scarce and costly, so the question becomes whether AI can grade itself. Yadav says LLM-as-judge has many limits: validate a judge against human labels and demand 80–90% precision and recall, and you find they fail. Harmlessness checks are automatable with off-the-shelf guardrails and groundedness with API calls; helpfulness remains the barrier, so builders need a domain expert alongside them. Launch, in Yadav's framing, is the first day of work.
How roles change. Yadav recalls Microsoft dropping its separate test-engineer role when internet products could update weekly, and expects a similar collapse now. With code a commodity and novelty fading, PMs become product makers who build the first MVP and test it with simulated or paid users; work that only fetches data insights goes away, and an evaluation scientist emerges as data scientists did after 2010. Shane sees PMs prototyping and gathering qualitative feedback before engineering, data and engineering arriving at scale, and former data scientists making the best PMs. A co-host expects AI to force first-principles thinking and today's roles to merge into new ones. Yadav also forecasts 7,000 billion-dollar vertical-agent companies, such as one handling auto-dealership compliance, rather than seven trillion-dollar ones.
In this Data Neighbor podcast episode the hosts interview Angi's first chief data officer, earlier a data science and engineering leader at Twitter and Microsoft. The conversation moves from what the role demands to where AI agents are heading, and ends on the guest's position: no one can predict AI's effect on jobs, so the only lever is where you spend your time and energy, and the right stance is to respond to uncertainty rather than react to it.
The role. Angi combined Angie's List, HomeAdvisor and Handy between 2017 and 2019, and the guest's first task was to unify the scattered data teams and bring ML matching to its homeowner–pro marketplace. The difference from big tech, the guest says, is ownership: in place of one functional sliver, everything under the data umbrella is yours, and you sit in leadership meetings on topics far from your expertise. The guest's rule there is to speak on what you know, stay quiet on what you don't, and voice intuition otherwise.
Strategy and execution. Data strategy starts from the customer: the merger left nine to ten unconnected data sources behind one customer, so the work is fixing quality, cutting fragmentation, and explaining concentric priorities to leaders who each see only their function. For speed, the guest imposes an agile, OKR-tracked operating system and a shared warehouse. On precision, the guest argues that each added "nine" of data quality costs more, as uptime does, though executives rarely see it that way, and that because ML success rates run around 10% or lower, a better team delivers more bad news. A host adds that Snowflake Summit vendors demoed agentic tools on flawless data and skipped data readiness.
AI first and the agent future. The guest treats "AI first" against "AI forward", and Anthropic's augmentation-versus-automation terms, as points on a 0-to-1 scale. Microsoft's frontier-firm report stages this from chat assistance to agents managing agents. Joining Sam Altman's wish for a model that improves AI research to Jared Kaplan's scaling law on agent working time, the guest infers agents will come to supervise and improve agents, and expects big companies to buy startups with outsized revenue per employee.
Labor and preparation. The guest declines to forecast labor effects beyond a rough guess that automating about 10% of GDP would bring real disruption. Companies need training and ways to keep people motivated, and individuals should get good with tools such as Cursor. Responding to a host's framing of Anthropic's CEO predicting 50% unemployment, the guest says such forecasts are one possibility among several. The closing advice on talking to executives is to answer first and see the problem through their eyes.
In this Data Neighbor podcast episode, Matt Harrison, a Python educator and author of Effective Visualization, argues that communication is a data professional's most underrated skill and that a chart is a story to be told rather than a plot type to be produced. The method is CLEAR (color, limited plots, explain, audience, references), a fixed sequence of questions that, Harrison says, will change most plots put through it. Harrison ends on the view that current AI can produce basic charts but not the hand-tuned, back-and-forth work professional ones need, and attributes this to missing training data.
Why an opinionated book. Harrison says theory books such as Tufte's explain color and design without showing the code, while library books list hundreds of Matplotlib features without showing how to tell a story; the book aims to bridge the two. Harrison picked Matplotlib for static charts headed into presentations, books or reports. Having recreated the same plots in Matplotlib, Seaborn, Plotly, Tableau and Excel for a Coursera course, Harrison concluded that no-code tools are fine for exploring but make small finishing tweaks hard or impossible. Curation matters, in Harrison's view, because beginners asking for directions get a path without the warnings.
The CLEAR method. Color means few, deliberate colors with the context muted in gray, and not Matplotlib's cycling defaults. Limited means sticking to line, bar, scatter and histogram plots: Harrison's sample of professional visualization teams fell into five buckets, a catch-all of maps among them, and none used radar plots or treemaps. Explain means a takeaway title, a subtitle and annotations, along the lines of "tell them what you're going to tell them, tell them, then tell them again." Audience means a chart for oneself during exploration differs from one for the CEO. References means a source line stating the data and its changes, so the chart is self-contained and can be checked.
Practice and common mistakes. Harrison says the work is iterative. Matplotlib's default of 10 histogram bins rarely fits, moving bin edges can create misleading "comb effects", and an outlier flattens a default histogram. Fully opaque scatter points blur into a blot, so Harrison sweeps size and opacity to find the clusters. Pandas bar plots of time series turn dates into categories and print every full date. To learn, Harrison recommends deliberate practice: recreate known-good charts from their cited data, study designers' style guides, and get feedback from a professional designer. A host adds that one of the most useful dashboards the hosts saw at Nextdoor was a red-and-green week-over-week Google Sheet.
AI's limits. Harrison has not seen an AI turn a CSV into an Economist-quality chart, and finds models fine on basics but hallucinating beyond them, across Matplotlib, pandas, Polars and XGBoost, because professional work and companies' valuable tabular models are not in the training data. A specialized, opinionated AI fed a style through a large context window might change that later; for now, Harrison says, it is no threat to an educator.
In this Data Neighbor podcast episode, two hosts interview Marina, an ML applied scientist at Twitch who came from political science and small-business management. The episode builds a self-study road map into machine learning and lands on a short formula: don't let fear stop you from starting, do a little every day, and keep building things. Courses get you started, projects drawn from your own life carry you forward, and communication is what separates the mentees who advance fast.
The path. Marina studied political science, worked on campaigns and at nonprofits, then ran a two-person jewelry company for four years. A public policy master's that turned out to be mostly social data science, with coding, statistics, causal inference and some ML, deep learning and NLP, led to a year at a Berlin statistical consulting firm, then Coursera, then Twitch. The Berlin job came from cold-emailing 30–40 local firms; one replied and created an internship, which became a junior role after about a year. A host calls this growing your "luck surface area". The master's covered no SQL, applied ML or deployment, so Marina filled the gaps through self-study around full-time work, including roughly 20 Coursera courses during her time there, and now mostly through technical books plus projects. Her channel's "gratitude-driven" name is her alternative to hustle culture.
Learning and promotion strategy. Marina advises fundamentals first, Python and statistics, and not tools like PySpark or Airflow, then talking to practitioners to learn which tools their jobs actually use. On promotions, she says knowing each level's criteria and regularly asking a manager where you stand brings out non-technical gaps, such as moving a business metric. AI does not change the fundamentals, in her view: coding agents still delete tests and call them passing, so supervising them takes security and scalability knowledge. ChatGPT helps as a roadmap generator, quizzer and explainer of formulas.
Projects over courses. Once past the very beginning, Marina says to learn by building: pick a problem you care about, find your own data, and learn each next step when stuck, taking it end to end to deployment. Kaggle is fine only for a first project. A host summarizes this as the loop that also prepares you for interview edge cases.
Breadth, depth and resources. Marina lists the foundations for ML: Python, SQL, basic statistics, intuition-level calculus and linear algebra, traditional ML, and evaluation, then software engineering and MLOps. After that comes depth in one area with some room for curiosity. Her controversial view is to learn ML before the math, since people quit at the math and rarely compute by hand. She recommends Coursera's Machine Learning and Deep Learning specializations, 3Blue1Brown, DeepLearning.AI's math specialization, DataCamp, Chip Huyen's Designing Machine Learning Systems and AI Engineering, and Catherine Nelson's Software Engineering for Data Scientists.
Mindset and AI. Against imposter syndrome she advises being comfortable as a beginner, remembering that others show only highlight reels, and knowing that big-tech staff are not all geniuses. On AI's future she calls it a coin toss between very bad and very good, and chooses optimism since the outcome is beyond her control.
An episode of the Data Neighbor podcast in which Sander Schulhoff, CEO of Learn Prompting and organizer of the HackAPrompt red-teaming competition, argues that AI systems are not secure and will not become so. Agentic systems will ship regardless, under market pressure, and finding their failures will remain a job for humans working with automation.
Scope and origins. Schulhoff defines red teaming as tricking AIs into doing or saying bad things, a term borrowed from cybersecurity, and extends it to non-adversarial failures such as an agent wandering off-task. A host argues these should be caught before the pattern turns malicious. Schulhoff traces the start of the competition to the first prompt-injection post: when nobody ran a competition on it within a month, Schulhoff ran one, with 13 sponsors.
The competition and its data. HackAPrompt 1.0 open-sourced 600,000 prompt injections. Schulhoff says every AI lab uses the set to benchmark its models, and the paper won best theme paper at EMNLP 2023. HackAPrompt 2.0 has a CBRNE track and an upcoming agents track. In a demo, a refused request for bioweapon instructions goes through once the user claims to be a researcher. The intro challenge runs on GPT-4o and the prize challenges on anonymized models. Three LLM judges score each submission, and a contestant can appeal to human judges.
A taxonomy of failures. Jailbreaking is a user against a model. Prompt injection adds a developer instruction to override. Indirect injection arrives through external content. Reward hacking covers a boat agent circling a buoy for points and coding models that assert true or edit pandas. Misalignment is illustrated with a hypothetical agent removing an obstacle by harmful means, and with a study in which a model rewrote a chess engine's state to win. Such real cases, Schulhoff says, have turned past dismissiveness into concern.
Why humans stay in the loop. Schulhoff now holds that automated red teaming is brittle and does not exist for agents, whose attack surface includes hidden instructions in web pages and ad images. Labs use adversarial data for benchmarks and safety tuning, and defenses are moving into pre-training, which needs far more data. The prediction: red teaming becomes more agentic and a career field.
Market pressure and policy. Schulhoff's startup advice on security is "don't". Companies deploy what they know is insecure because competitors otherwise will, and Schulhoff's team has indirectly injected agents deployed by very big companies. Schulhoff is a self-described accelerationist, though not "AGI-pilled", rates government progress as middling, and says nobody knows what they are doing, so education comes first.
An episode of the Data Neighbor podcast in which Suri, a machine learning tech lead at Adobe, walks through a GenAI product from vague idea to production, using a worked case of a retrieval chatbot. Suri's conclusion is that getting a first answer out of the system is only the feature pipeline. Productionizing really begins there and is dominated by evaluation, along with load provisioning, feedback and the question of whether an LLM was needed at all.
From idea to prototype. Requirements start vague and differ from person to person, so the first task is defining the data. Inputs are usually known; outputs often are not. For the first prototype Suri recommends existing APIs, such as Azure OpenAI or Claude, and a minimal front end in Streamlit or a Jupyter notebook that the team and product managers can try. The prototype should end with a view of what works, what doesn't, what a good output looks like and what success means. A host notes that vibe coding reaches the same starting point but still has to go through the same process to reach production.
The worked case. A host proposes a chatbot that tells staff which internal data table to use, built from table documentation. Suri lays out the RAG pipeline: gather the tables and documents into a database, preprocess them to remove noise, then chunk them. Suri recommends 250–500 tokens as a starting chunk size, tuned through end-to-end experiments. The car-brochure example shows how an oversized chunk lets the model mix up makes and years. Embeddings are mostly used off the shelf, with options such as Cohere's multilingual model or OpenAI's large embedding for long chunks. Vector stores are a choice among Weaviate, OpenSearch and Pinecone.
Query and prompt. User queries arrive incomplete and spread over several turns, so they are reformulated and, when loaded, decomposed. Suri does this with an LLM, and the hosts add that domain terminology may need subject-matter experts. Retrieval can add a reranker where needed. The system prompt should be simple: Suri says 10 critical instructions outperform 100. Step-by-step reasoning builds trust in sensitive domains, and the prompt should guard against leaking itself. The hosts' aside is that clear communication matters as much with LLMs as with people.
Evaluation. Suri calls this where "the movie starts". Human review of perhaps 100–200 cases comes first and recurs after major changes, then automated metrics for minor ones. Accuracy is joined by use-case metrics such as detail, tone and conciseness. Gold answers must include every valid variant, such as two correct SQL queries. LLM-as-judge is now standard: use a stronger model from a different family, at least two where possible, scoring binary or on a Likert scale, while remembering that families can share the same wrong answer. Embeddings are rarely evaluated on their own. Reformulation and retrieval can be, with RAGAS context precision and recall useful for debugging, though teams mostly check the final output. Defining "good" is the hard part, and Suri says it leads into personalization.
What else production needs. Suri warns against using LLMs where classical models suffice, such as classification. The remaining pieces are provisioning for expected input and output tokens, A/B testing, and capturing mostly implicit feedback in a privacy-preserving way with user consent. Cost, latency and fairness are left for a promised part two.
An episode of the Data Neighbor podcast with Robert Chang, who moved from data scientist to product manager to software engineer, all at Airbnb and all around the same metrics platform. His account ends in a prescription for internal pivots: excel where you are, build social capital, do adjacent work as proof, and find a sponsor. He calls the sponsor a necessary condition.
Data science and the drift toward tools. Chang joined Airbnb in early 2016 from Twitter, working on host-side supply growth. In 2018–19 thin data-engineering support pushed data scientists into building pipelines. A listing lifetime-value model led him to rely on the early ML feature infrastructure, and being a demanding early user of the platform team's tools earned their trust. His lesson is to learn adjacent skills through real projects, because side study did not stick.
Becoming a PM. In 2019 the data platform's head of product asked Chang for PM referrals. Chang eventually put himself forward, after four or five lunches that served as alignment meetings, and joined the metrics infrastructure team that feeds A/B tests and reporting. A major incident in week one forced a moratorium on contributions, which built trust. The surprise was how much invisible work, such as access control, SLAs and instrumentation, outranks features. The job meant constant context switching on the manager schedule.
Becoming an engineer. By 2021 Minerva had scaled across the company, and its early design was straining. Everything was precomputed into Druid for Superset, and data versioning made backfills cascade. The team chose to rebuild while running the legacy system. Wanting maker time, Chang asked to switch, and his director sponsored it. He handled the awkwardness by naming it, taking small projects, pair programming and showing progress, and later brought PM skills back in for estimating.
Cross-role lessons. Engineers must explain and sell their features, PMs should spot the common problem behind scattered requests, and data people should bring rigour after launch and understand instrumentation. The hosts add empathy for PM triage and engineers' attention to edge cases.
GenAI and pivot advice. Chang finds coding assistants good for well-defined tasks like unit tests, and LLMs excellent as patient tutors, for example explaining TypeScript in terms of Python. He doubts vibe coding for now. His pivot recipe closes the episode, restated by a host as four steps.
An episode of the Data Neighbor podcast with Will Landecker, a responsible-AI consultant (Accountable Algorithm) who previously worked at Twitter, Stripe, Lyft and Nextdoor. His argument ends on one habit: every AI organization should ask early and often how the choices behind its success metric make that metric lie, instead of trusting that "number goes up".
Background and the new exposure. Landecker's PhD was in interpretable machine learning, and his trust, safety and privacy work predated the term "responsible AI". He sees a new risk in the many organizations that can now adopt AI through an API call to Claude or ChatGPT, with less visibility into the model than ever.
Loud harms and whispers. In his lending example, a strong gender bias in approvals is quickly noticed and confirmed. Slightly different interest rates across groups take huge data to show. Accuracy hides this because a model earns credit for serving the majority, and "what does the data say?" goes unchallenged. A host notes that proxy features can rebuild an excluded attribute such as race. Another host, now at a smaller company, values user calls and subject-matter experts; Landecker's phrase for analysis without them is "a book report on the CSV".
Assessing a client. Landecker asks what is being built and whether a concern already exists, writes user stories of possible damage, then measures. Large companies tend to have unflagged small errors; small ones may never hear of a problem. Measurement is often blocked because companies hold no demographic data, sometimes on principle.
Feedback loops and agents. The pre-agentic era had checkpoints such as analysts and drift monitors. When agents interact directly, correlated errors compound at machine speed, and the user reports that once tripped the breaker drop out. A host adds the synthetic-content loop, and describes an AI voice tool that would not verify the host's voice after 30 minutes of recordings. Landecker's portrait-generator case shows an evaluation-set failure that also blocks growth into new segments. A host extends the point to A/B tests.
Evaluating LLMs for bias. Glaring bias, such as Word2Vec's doctor-to-nurse analogy around 2013, takes an intern five minutes to find. Subtle shifts from swapped pronouns or coded names need large varied corpora, and generating them with another LLM blurs accountability. Landecker calls the current tools fraught and in need of fresh research.
Culture, policy and the habit. Landecker calls an executive champion critical, recommends finding allies and reading the FAccT proceedings, and is not hopeful about government guardrails. He puts responsibility on builders, through internal policy written into the work rather than added as a reaction, and closes on the measurement habit.
Luis Serrano, founder of the Serrano Academy YouTube channel and formerly at Google, Udacity, Apple and Cohere, makes one argument across this episode of the Data Neighbor podcast: people know far more than they think, and the human part of any skill is what is left once a machine has done the rest. He ends on two prescriptions. Try to get a computer to do 100% of your job and see where it falls short, because that remainder is you. And value malleability, the ability to keep learning new things, over stored knowledge.
Why people think they are bad at math. Serrano describes himself as a slow "understander" who has to tell himself stories before abstraction makes sense, and says that is why he teaches. He was failing grade-8 math in Colombia when he took a puzzle-based olympiad exam to skip class and placed first in the country. His conclusion is that school turns students into instruction followers, and that most STEM subjects are taught in the language of abstraction, which suits a small minority. The examples are concrete ones. Everyone draws a parabola for a falling tennis ball. Children splitting candy know a third beats a quarter. Music is as complex as math, yet nobody says they are bad at music, because it is introduced through songs.
Learning by playing. His method inverts the usual advice to learn all the math, then programming, then machine learning. Hand the child the ball first. Pick a dataset tied to a hobby (his was tennis), plot it with just the line of code you need, and learn linear regression when a line appears. He applies the same approach to learning piano by songs before chords. As a demonstration he explains gradient descent as getting down a foggy mountain one locally steepest step at a time, with the loss function as your height.
What machines will not take. Serrano lays out a pyramid. Physical strength was displaced by machines, rational thinking is being displaced now (chess for more than 20 years, go, and in his prediction soon math and physics), and above both sit emotional intelligence and intuition, which he says Western society has neglected and calls "soft skills" when they are the hard ones. He expects future humans to seem less capable to us, as we would to our ancestors, while holding skills we cannot imagine. His heuristic is the 1% of human input left after automation, like telling a car where to go. In his own work, the part of making videos with language models that stays his is the questioning: he steers the model as a child would with repeated whys. The hosts connect this to executives, who also mostly ask questions.
Quantum computing. He explains qubits as switches that can be on and off at once, and entanglement as stranger than a pair of gloves split across galaxies. The practical gain is on problems that grow exponentially, such as the traveling salesman problem and factoring, which would break RSA. He expects quantum hardware to be a small step inside mostly classical computation, like a bus that only sometimes flies. He believes, flagging that he may be wrong, that quantum machines are better at generative AI because they generate true randomness, citing his own small experiments. He goes on to speculate that a quantum measurement's randomness might be where empathy or intuition, or even consciousness, could enter a machine.
Underrated skill. Asked the show's closing question, he names malleability and says knowledge is overrated now that it no longer lasts 50 years. When hiring, he weighs how many new things a person has learned, and compares that to a marathon runner who will manage an Ironman before learning to swim.
Jesse Lee, former head of data at Descript and before that a product data science lead at Meta, tells the Data Neighbor podcast hosts what it took to build a data function from nothing as a startup's first data hire. Her answer is that best practices still work, but only once you have mapped where the company actually is, and that the hardest skill is calibrating your own judgment when nobody above you knows more. After three-plus years, she says she got what she went for: a lean, effective stack, real ownership of a function, and a close view of how a CEO operates.
Why she moved. She frames the decision as push and pull. The pull was wanting to understand the full data lifecycle in order to lead data someday, earlier startup enjoyment at Flipboard, a husband who is a founder, and a one-year-old whose costs were still years off. The push was Meta's zero-to-one work, where sign-off meetings consumed the team and six-month performance cycles demanded incremental value before product-market fit. She uses the same lens on career advice: list your dimensions before interviewing, collect signal throughout, and score the offers. For people who just need a job, think two jobs ahead.
Day one. The company made what she calls an opportunistic hire: people cared about data, but there was no vision or roadmap. Her biggest shock was that she could not simply import Meta's data culture without understanding local pain points. Her onboarding was mostly learning the product. She found video editing far more complex than the social and marketplace flows she knew, and the company ran a two-week "creator boot camp". She built the map herself, using a large table of expectations, status quo and gap across data foundation, insights and culture.
Building the function. Foundation came first because of garbage in, garbage out, so about three months in she hired a founding analytics engineer and taught herself dbt and data modeling. She built experimentation from scratch by comparing vendors' documentation and statistics, and says that taught her more than Meta's polished platform did. The resulting stack includes Fivetran, dbt and Hex notebooks. Hiring was intense, at times 12 to 14 interviews a week. She looks for self-starters who are resourceful, at ease with ambiguity and growth-minded, and she says candidates who rank work-life balance first should reconsider startups.
Balancing the urgent and the important. Quarterly, the team targets about 50% big-rock projects, 30% operational work and 10–20% culture and side work. Day to day, she uses decision-driven triage: she estimates about 40% of requests fall away when stakeholders are asked what they would do differently, and the rest get scoped down.
What was hardest. Being the ceiling of her function meant no internal calibration, and outside heads of data had different contexts. She says she overcorrected into humility and found it disorienting. Asked about underrated skills, she points to AI-native workflows, saying her team had used AI only to enhance existing work.
Jess Haberman, director of product content at Anaconda and formerly an editor at O'Reilly Media, argues on the Data Neighbor podcast that AI's main effect on technical education so far is pace. Learners move faster, expect to be taught through assistants, and outgrow long fixed curricula. She concludes that the lasting advantages are human ones: a trusted voice in a flood of AI-generated content, a clear learning goal, a network, and communication and collaboration skills that AI amplifies rather than replaces.
What has already changed. Haberman says business leaders expect AI efficiency perhaps sooner than it will arrive, but learning is visibly faster. People can learn Python as they go, with generative tools translating their thoughts into code and code back into explanation. On Anaconda Learning, she reports, users finish Python material faster and want advanced content the platform has yet to build. She also reports that most Anaconda AI-assistant use, roughly 85% by her loose figure, is for learning and exploration. The job for content teams, in her view, is to make sure the assistant teaches "the Anaconda way" and that content is ready for assistants as well as search. She mentions Anaconda's recent move to enterprise Claude and its shared projects. She treats prompting as a new skill that no one has fully mastered.
The fate of curricula. She sees microlearning accelerating, with long courses broken into transcripts, audio, cheat sheets and mini-books for different learners. She doubts bootcamps survive in their current form and gives certifications little weight in her hiring, though she notes that technical managers may differ. Academic curricula, she says, will change slowly. The academia-industry gap, especially dirty data, will remain. Charismatic, trusted instructors will keep their edge over AI ones.
Trust in a sea of slop. With AI-generated and counterfeit content flooding places like Amazon, Haberman tells authors and trainers to build a personal brand or align with an established one, and calls this a hard time to self-publish. For learners, her method is to give a chatbot your level, goal and field, ask for sources with links and dates, skip content over two or three years old, and then follow the named experts and their podcasts. She stresses real, reciprocal relationships and not fearing being wrong in public. The hosts add that posting wrong answers on forums reliably draws corrections. A host also draws out the point that learners need a destination, not endless consumption.
Her path and the wider field. An English major who had intended to be a book editor, she moved from outdoor and lifestyle publishing to O'Reilly's data-engineering list knowing little, and learned by asking conference speakers to explain things simply. She then joined Anaconda through Peter Wang. She sees finance as a ripe area given its Python literacy and notes Anaconda's Python-in-Excel partnership with Microsoft. She calls herself more hopeful than afraid about lightly regulated AI.
Evergreen skills. Communication and collaboration come first. Everyone can now write with AI help but must read the output, and well-paid specialists should show value. She also says not to pigeonhole yourself, and not to gatekeep. A host adds that people with soft skills now face a lower barrier to technical ones. Her single upskilling hack is networking.
The guest, an Amazon marketing-science leader who previously worked at Walmart's Sam's Club and Nielsen, explains on the Data Neighbor podcast how marketing science answers the old complaint that half of marketing spend is wasted and nobody knows which half. His answer is to measure incrementality, not response. That means targeting people whose behavior marketing actually changes, attributing credit with models, and then proving the models with staged experiments. The episode ends on his Amazon hiring case, where he reports a 90% cut in recruitment-marketing spend with no loss in hiring, and on the caveat that such cuts are only possible where marketing is a cost rather than a revenue driver.
What marketing science is. He defines it as applying experimentation, machine learning and optimization so that you spend only where spending moves the KPI. His opening example is Dan Ariely's Economist subscription test. Adding a print-only option at the same $125 as print-plus-online moved students from 68% choosing online-only to 84% choosing the combo, because the decoy made the combo easy to compare. Large companies run separate marketing teams for acquisition, upsell, renewal and brand. He warns that optimizing only short-term sales erodes brand value.
Persuasion over propensity. At Sam's Club, costly direct mail was going to people who would never respond and to "sure things" who would shop anyway. He sorts audiences into lost causes, sure things, do-not-disturb (whom contact prompts to cancel) and persuadables, and argues that common propensity targeting wastes money on the sure things. Uplift modeling needs experiments as training inputs and patience that marketing teams focused on next week often lack. He credits the shift with over 100% lift and a 2020 award.
The five pillars and attribution. He names experimentation, attribution, machine learning, brand measurement, and optimization with automation under constraints such as a 30% budget cut. On attribution, he walks through first-touch, last-touch, equal-weight and path-based multi-touch models, and DAGs for channels that drive other channels. Media mix models handle offline channels at market level with seasonality controls. Multi-touch attribution handles digital creative allocation, and the two can work together. An eBay study found that branded search ads added nothing over organic results, though he still sees some branded spend as defense.
Getting buy-in. He calls the science the easy part. His method is to speak to each team's own KPI, propose tests in a few markets the team chooses, and scale in stages. In one case a model's 90% cut tested at about 65% at first, and he argues that does not make the model wrong. Most experiments, around 80%, fail, and stopping a campaign that hurts is still an investment in data. The common mistake he sees is leadership reacting to anecdotes from marketers who are good at marketing their own campaigns. He recommends entering industry awards such as the ANA's Genius Awards for peer validation.
Hiring at Amazon. In tier-one hiring, local recruiting-marketing specialists each made their own decisions, often over- or under-delivering applicants for two- to four-week needs at specific sites. His team centralized the decisions in a product that estimates labor risk and recommends spend from media mix models. He reports a 90% spend reduction over two years with hiring unaffected, limited to his team's scope and offered as personal opinion. He says revenue-side teams will instead ask for more return on the same budget.
AI and closing advice. Drawing on failed AutoML predictions from 2019, he expects 2025–26 to look like 2023–24. Over about five years, he expects generative AI to reshape creative work (25–30% of marketing teams) first, and to leave smaller, specialized teams working with agents. His underrated skill is storytelling, sharpened through case competitions.
The guest, a senior machine learning engineer building generative AI into Adobe Acrobat, traces document AI from OCR to LLMs on the Data Neighbor podcast. His argument is that the engineering work has shifted from training models to choosing where an LLM is worth paying for, grounding it with retrieval, and evaluating its output rigorously. He ends with a roadmap for newcomers: build current projects while learning the fundamentals, and focus above all on business impact, in a field he expects to be dominated by agents this year.
Why documents were hard. He explains that a PDF layers text, images, tables and graphics on a page. Digital PDFs are searchable, but scanned ones are images, and phone scans that arrive tilted, inverted or cropped blocked automation in finance, legal and contracts until enterprise OCR arrived. His early work in India used object-detection and segmentation models trained on open-source and internally annotated data to label titles, sections, paragraphs and nested tables. Vision-language models such as GPT-4 can now read a page, but he says their non-determinism rules them out for enterprise OCR. A host's example is a model guessing a name smudged by pencil, which the guest says it might fill in from other pages.
What Acrobat does now. By his account, Acrobat's AI Assistant answers questions across about ten uploaded documents with citations back to the source passage, to show answers are not hallucinated. Liquid Mode, released in 2023, reflows PDFs for each device, which a host likens to responsive web pages. Prompted carefully, for example asking for every key point chapter by chapter, an LLM can summarize a textbook or generate exam questions from it.
Choosing the model. He says LLM prices have fallen roughly 100–200x in two to three years, so even entity extraction now goes to a JSON-returning prompt instead of custom spaCy or NLTK training. Enterprises move slowly, though. At scale, he prefers distilled or fine-tuned BERT-style models and small language models for classification and structure. He routes queries by complexity and reserves large models for generation and summarization, grounded with RAG, which he describes as retrieving relevant chunks and passing them as context.
Production RAG. Previewing his O'Reilly AI Superstream talk on March 4, based on a year of reading nearly every RAG paper, he says the common failure is naive ingestion: one chunker with default settings for every document. The fixes he names are chunking chosen and tuned per document type, better parsing, and parallel asynchronous ingestion so that indexing billions of documents does not add latency.
Evaluation. He calls evaluation blank for many enterprises. Open-source metric frameworks cover part of it, so his team adds proprietary ones. Retrieval is scored on relevancy and ranking, and generation on embedding-based groundedness and faithfulness. Answer quality is scored by a jury of LLM judges from several providers, each given defined anchors on a 1–5 scale. Subject-matter experts write reference answers, and where their scores diverge from the judges', for example a 2 against a 3, prompts are revised. A flywheel computes live metrics and stores metrics, not user data.
Roadmap and outlook. He advises newcomers to build agents and other current projects without waiting to master the internals, balanced with in-depth courses. He names business impact as the underrated skill. He expects new job titles, risk for repetitive work, and growth in AI engineers through the Jevons paradox, with this year centred on agents.
Episode 20 of the Data Neighbor podcast has Colin Matthews, a product manager and course instructor who founded Tech for Product, arguing that AI coding tools make functional prototypes cheap enough to test an idea on users before committing to build it. The episode ends on a live Replit demo. A one-line prompt produced a working Streamlit analysis app. A deliberately vague "make me money" prompt produced a roughly 3,000-line data-analysis product. Colin attributes both results to an easy, well-trodden case rather than to the tool being able to do anything.
Why prototype. Colin's thesis is that the usual sequence, Figma mocks and then a long build and then the discovery that nobody wants the product, can be cut short. Feedback on mocks is "meh", particularly for recommendation or ML features users need to try. His own side projects took at least 3 months each, and he now estimates about a week for a testable web app. The deeper benefit, he says, is reaching the user-acquisition problem early instead of solving "all the fun parts first".
Limits and jobs. AI is best at speeding up work you already know how to do, because you can see when it goes wrong. Non-technical builders lack a model of clients, servers, databases and auth, so errors compound, and vibe-coded security or payment integrations can look as though they work when they do not. He expects teams to shrink as output rises 2–3x, starting at startups, but not the end of engineers, since system design remains the hard part. A host describes asking Cursor for simple group-bys that would have been quicker to write by hand, and finding it harder to debug code it had written.
Choosing tools. Technical users should use Cursor with a JavaScript stack (React, Node, Postgres, Railway), since models have seen the most JavaScript. Others should use Replit, an all-in-one environment that provisions a database on request and runs Python. Bolt, Lovable and v0 depend on Supabase for back ends, and he finds that integration weaker, so he uses them for client-only prototypes with mocked data and mocked AI responses.
Working method. He keeps a PRD.md spec with components, styling and phased implementation, set as a global instruction in tools that support one, so the agent refers to the spec instead of a confused chat history. He keeps to a "happy path", reverting to the last working state rather than debugging forward. He asks the model to explain a problem without writing code before asking for a fix, because these tools, all on Sonnet 3.7, default to writing code. Being more specific, he says, fixes most failures, much as a vague request from a PM frustrates a data scientist.
The demo. Replit planned, coded, hit an import error, installed the missing libraries and screenshotted its own output to check it, committing to git at each checkpoint. It found the Iris dataset without being given it and built box plots, scatter plots, histograms, correlations, a pair plot, PCA and, on request, decision tree, random forest and gradient boosting views. The "billion-dollar app" prompt led Replit to ask clarifying questions, then build "Money Maker": upload, cleaning, feature engineering, charts, descriptive statistics and an HTML report, run on fake transaction data written by Claude. Its upgrade link and user guide did not work. Colin warns that long autonomous runs rarely succeed, that Next.js would have broken where Streamlit did not, and that Replit applies changes without the accept/reject review Cursor offers. Pricing as he described it is usage-based: $25 a month buys $25 of credit, agent messages cost 25 cents and assistant edits 5 cents.
Keeping up. He calls following the news of the moment mostly wasted effort, citing MCP's sudden popularity months after its release. Most people use none of these tools, so anything that works at all is a good start.
PRD.md spec listing components, styling and implementation phases, so the agent works from that file rather than a long chat history. When bugs pile up he reverts to the last working commit instead of debugging in chat. He asks the AI to "explain the issue, don't write any code" first, because the tools, all running on Sonnet 3.7 at the time, write code by default. Non-technical users should retest every feature after each change.Episode 19 of the Data Neighbor podcast has Karun Thankachan, a senior data scientist at Walmart and former Amazon applied scientist, treating the data job search as a measurable funnel. His mentees set weekly targets for connection requests and referred applications, and they measure themselves against realistic conversion rates, so that about 95% rejection reads as normal. The conversation then turns to how recommender systems are built and where LLMs help them. It ends on his claim that the most underrated skill is making connections, because new data sources, not better models, drove his biggest wins.
His background. At Walmart he builds forecasting and personalization models for item availability. He says only about 20% of the job is modeling and the value comes from finding and cleaning the right data. At Amazon he did anomaly detection and forecasting on a fintech team, then research-heavy work on employee outcomes. He contrasts data science, where the model matters little, with applied science, where novel models are expected.
A noisier market. AI screening on the employer side and AI-driven mass applications on the candidate side have flooded the market. He reports services doing four applications for a dollar, and candidates applying to close to 1,000 jobs where they once applied to about 100. He splits success between a portfolio and resume showing the role's core skills and getting someone to refer you.
The funnel. His targets are 100 LinkedIn connection requests a week, an expected 4–6% response rate, 20 referred applications a week once the network has grown, and up to three roles per referrer. Responses can take two weeks. His mentees' callback rates have roughly halved from about 10% in 2019–2020, and referred applications now return 2–3% against a former 5%. Cold email through Apollo or Hunter has matched LinkedIn's rates. A host frames the value of such benchmarks as keeping new candidates from becoming discouraged.
Resumes. Rather than tailoring each application, he keeps three or so templates by domain and copies AI-extracted keywords into the competencies section to clear the ATS bar. Beyond that bar, he says, the score does not rank candidates, and per-role tailoring breeds mistakes. Freshers with scattered projects should aim at smaller companies or at data analyst roles, where managers take more chances. Candidates with technical or business depth, most often in ads or supply chain, should build a resume around it.
Mid-career moves. The transition from senior analyst to product data scientist is the smooth one. Applied roles need a coding bar and evidence of scalable models in production. Experienced candidates most often lack a story about handling ambiguity and the end-to-end ownership that shows in how they anticipate problems. A host adds that analyses and interviews alike should state what made the work hard.
Recommender systems. He defines recommenders as making a user's implicit preferences explicit, using Netflix's top-10 popularity recommender as the simplest case. Production systems run candidate generation, real-time ranking and business-rule scoring, the last owned by teams embedded in the business. His own entry was an Amazon onboarding-content recommender mentored by a senior (L6) applied scientist, combining popularity, matrix factorization and two-tower networks with a scoring layer for level-restricted content.
LLMs and the job. He reports LLMs helping with candidate generation and normal cold start, where a little interaction data exists, and LLM item embeddings for sequential recommendation. He offers both as early results. He does not expect AI to replace data scientists soon, because tribal knowledge is never written down. His closing advice is a monthly coffee chat with another team to learn what data exists.
Episode 18 of the Data Neighbor podcast has Maarten Grootendorst, co-author of Hands-On Large Language Models and a data scientist in healthcare, arguing for using the right-sized model rather than the shiniest one. Open models give control over data, versions and fine-tuning. Distillation will keep making small models better. Open source will always close the gap with proprietary models. Cheap representation models still beat generative ones at most classification and retrieval work. He ends on communication as the skill that matters most.
From counting to context. Bag-of-words models, at least 30 years old, still serve him daily because they are small, fast and accurate. For him the turning point was word2vec, about ten years ago, more than attention: representing a word as a vector gave it context, so "bank" could be told apart by its neighbours. The field first built representation models, then generation on top of them. GPT-3 was good for poems. OpenAI then put so much money and high-quality data into GPT-3.5 that "everything we've done in the past 10 years is now done in a couple of months". He credits his background as a psychologist for how he explains technical ideas visually.
What LLMs are for. He calls LLMs an efficiency tool, a smart rubber duck that turns him into "more of an architect" of his code, while hallucination still calls for scepticism. He doubts mass job loss or imminent AGI. Adoption has been slower than the hype because value comes from integration, and he names Cursor as the example done well. A host says he built a Mario game with Cursor despite having no engineering background.
Open versus closed. Proprietary models are costly to build and charge per token. Open models can run offline, which matters where data cannot leave, as at his cancer research institute. The trade-offs he and the hosts list are cost, ease of use, privacy and security, domain fine-tuning, and control over hidden versions, rules and outages. He sets out the pipeline: expensive pre-training for next-word prediction, fine-tuning into instruct or chat models, then optional domain fine-tuning.
Small models. DeepSeek's moment, in his view, is partly marketing, since Llama, Mistral and Qwen have run locally for years. Distilling large models' outputs into small ones will make them steadily more accurate. In agent systems they take narrow tasks under a larger model's direction, and they suit phones and browsers.
The forecast. Proprietary labs moved from train-time to test-time compute, and DeepSeek matched that and ranked in the top five. New architectures such as Mamba, BitNet and Titans cost too much for universities to test at scale, which leaves the next leap to proprietary labs. He still concludes that open source will always catch up.
Getting started. His advice is to try a chatbot on something fun rather than useful, since motivation drives learning, and he dismisses hustle-culture insistence on productive output.
Representation models. You generate embeddings once for millions of documents and reuse them for classification, clustering, BERTopic topic modeling, deduplication and retrieval-augmented generation, saving the generative model for hard tasks. A host compares this to choosing regression over XGBoost.
Communication. He names communication the most underrated skill, because stakeholders want usefulness and data teams must justify their existence. He suggests practicing with short videos.
Episode 17 of the Data Neighbor podcast has Justin Chen, who leads growth data science at Mercury Insurance after heading data science at Coinbase and earlier roles at LinkedIn and his own startup. His argument is that data teams scale by building deliberately, not by heroics or unicorn hires. The conversation ends on his account of a GPT-3.5 Slack bot his Coinbase team built in 2023 to absorb ad hoc analytics. He reads that bot as the start of AI replacing reactive analytics work, and says leaders owe employees the tools to adapt.
Go slow to go fast. Quick SQL and dashboards serve an early company, but as Coinbase grew from about 800 to 1,000–2,000 people that work was lost or failed to scale. A casual table in Airflow became a core reporting dependency and broke daily. His answer is to treat deliverables as products, with a design doc required for anything over six hours of work. Long projects should ship small pieces of insight early, to keep the feedback loop with PMs and avoid delivering something nobody needs.
When rigor pays. He maps this to startup phases: intuition before product-market fit, early signal at fit, and scalable data work once growth begins. Products inside a large company sit at different phases too. Growth data science should be as fast and experimental as a growth PM, platform work must weigh compliance risk, and B2B releases must stay slow so customers' workflows are not disrupted.
The unicorn myth. Do-everything data scientists exist, he says, but they become bottlenecks with tribal knowledge, leave holes when they depart, and can resist change. Organizations should build onboarding, tooling and training so anyone meeting the bar can succeed. At Coinbase he created specialized roles, including an applied research role for former Wall Street quants studying crypto token and trading dynamics. Hiring tested presentation and technical depth, and he says evaluation continues after hire.
Careers. He values technical chops, which the industry has come to prize over management, and warns against a planned move into management after five years. Careers should deepen in one area, then broaden for leadership. A host argues for a 9/10 strength on top of 7/10 across the board. Justin adds that early in a career learning matters more than pay.
AI and the data role. He expects three shifts: ad hoc reactive analytics gradually replaced by agents and text-to-SQL, data modeling and semantic layers becoming more important because LLMs need a clean data language, and data scientists using AI to do more with less. With no headcount in 2023, his team built the Slack bot, which answered metric questions, produced charts and definitions, and triggered Airflow backfills. He argues necessity drove it, since stakeholders prefer a human they can share blame with. He adds that companies must empower staff, not simply replace them, and advises trying things, as he does by running open models locally with Ollama and Open WebUI.
A seat at the table. Data teams should drive decisions alongside product, engineering and design. That means interpreting results against business goals, treating communication as at least half the work, and building solutions others can reuse.
In this Data Neighbors episode the hosts interview a staff data scientist at Cash App, previously at PwC, SAP and Nextdoor, about content moderation. The guest's position is that moderation has no fixed ground truth: it rests on human judgments that disagree and on policies that shift, so data science's value lies in building evaluations that keep a wandering path heading roughly the right way, and in persuading leadership the work is worth paying for. The guest ends by warning that LLMs scale persuasion, which puts the burden on AI companies to stop abuse upstream.
Human labels at the root. Even at YouTube-scale companies, the guest says, models are trained on human review, and machine learning scales the work of about 100 people to hundreds of millions of items. Beyond illegal content, what counts as bad is a policy choice. Most firms optimise for engagement and remove only what is clearly illegal. Nextdoor tried to enforce civility, but its reviewer panel agreed far less than expected. The guest's answer was to enforce where reviewers agree and rewrite the policies where they do not.
From reports to panels to LLMs. Starting in 2019, Nextdoor fine-tuned BERT embeddings and labelled content by whether users reported it or moderators removed it. Reports proved unreliable: they are rare, limited per user, and weaponised. So the team moved to panel labelling and was beginning to add LLM votes. Fine-tuning taught the model that the clown emoji signals sarcasm, but it also flagged "die Boomer", where "die" was the German article, as a death threat.
Measuring an intervention. The guest's research paper tested comment filtering with a regression discontinuity design and found no change in activity. The guest offers a hypothesis that harm from exposure is nonlinear. A host notes that a null result like this still generates the next hypotheses to test.
Making the case. Trust and safety is always a cost, the guest says. Showing that bad content drives users away lifted Nextdoor's team to a company-level OKR. The guest's advice to leaders is to talk to people who were harmed, citing fraud at Cash App, rather than reasoning only from small percentages.
Risk at AI companies. With LLMs, one person can become 1,000 or 10,000 compelling identities. AI firms' safety has to be policy-driven and upstream: filter about 99% of misuse, then patch the last 1% quickly. The guest doubts they will always prioritise this but thinks they should. The guest's underrated skill is presenting a plain answer, which AI can help with only if told what the answer is.
The hosts interview a staff data scientist at Nextdoor, formerly at Amazon and Twitter, who argues that product data science earns its place through trust and partnership. The analysis matters less than being embedded with PMs and engineers as an owner of the product rather than a service desk.
Where data fits. The guest says data does little for a 0-to-1 product but drives a mature one. It runs as a feedback loop from opportunity sizing through A/B tests and launch. At Twitter that meant showing that engagement lost to better detection of bad content was engagement worth losing. Collaboration looked alike across companies of hundreds of thousands, 8,000–9,000 and 600–700 employees.
Experiments and hypotheses. Hypotheses come from data, PM intuition and user research. Testing one can take half an hour or months. The guest says the point of a test is learning, not a launch decision.
Trust and structure. Earning trust takes the first quarters at a new job, through transparency and over-delivering. A co-host contrasts embedded teams with centralized ticket queues. The guest puts those queues down to ratios of 10 to 20 engineers per data scientist. A host argues for one data person per PM.
Tools and skills. The guest has used SQL, Hive and Spark, along with Redshift, BigQuery and Databricks, Looker, Data Studio and Tableau. The guest moved from R to Python and still uses Excel. The underrated skill the guest names is cross-functional communication.
The hosts talk with Raphael, an information systems scholar at the University of Sydney who studies the ethics of emerging technology and AI companions, about what DeepSeek changes. Raphael welcomes DeepSeek for leveling the field: it shows that capable AI can be built cheaply and openly. But Raphael argues that efficiency will not bring sustainability or safety on its own, and ends on a call for compassion-based design, binding regulation, and open, interoperable AI systems.
Why DeepSeek shocked the market. Before January 20, Raphael says, the prevailing belief was that competing at the frontier took billion-dollar data centers, venture money and the latest Nvidia chips. DeepSeek came from a China under export sanctions and matched o1 on independent benchmarks. By some estimates it used a tenth of the compute, and it was released under an MIT license. Nvidia lost $600 billion in a day, and more than $1 trillion came off big-tech valuations. Raphael adds that Nvidia has since recovered.
How it was done. Raphael treats the $6 million cost as an accounting figure that rests on earlier work. Raphael calls the theft charge ironic. The efficiency comes from mixture-of-experts routing with load balancing and from distillation into a smaller student model. Censorship lives in the app, not in the open model, which universities can download and retrain. Raphael also contrasts DeepSeek's privacy policy with OpenAI's vaguer one.
Business models. Raphael places OpenAI's advantage in API revenue, its enterprise ecosystem and its brand, and expects open models to push prices down. Raphael judges Deep Research to be ChatGPT with extra steps.
Efficiency and regulation. Under the Jevons paradox, Raphael argues, cheaper AI will be built into everything. The EU AI Act came into force on February 5, as Raphael puts it, but energy disclosure under it looks voluntary on a non-lawyer's reading. The US is heading the other way, and California's AI bill failed under lobbying. Raphael's prescription is mandated renewable energy and disclosure.
Companions and compassion. Companion platforms claim 10–30 million users, and 40% of Gen Z accept a partner having an AI companion. Raphael lists manipulation, political profiling, impersonation and suicide as the risks. Raphael's compassion paper asks for guardrails that, when a user is in distress, refer them to professional help instead of keeping them engaged. It also asks for open, interoperable systems that the government sets standards for, as it did with the internet.
The hosts interview a staff data scientist at Statsig, formerly an economist at Amazon, a product analytics data scientist at Meta and a manager at Tencent, who now teaches an AI course on Maven. The guest argues that generative AI is rapidly devaluing technical execution, so a data scientist's value lies in finding and scoping the problems worth solving. Because adoption still lags even in Silicon Valley, the guest sees a 10–18-month window in which early adopters gain an outsized edge, and ends on a recipe for preparing for it and for filtering out the noise.
Why skepticism persists. The guest started learning generative AI before ChatGPT's launch and says ML scientists, burned by earlier hype cycles, still dismissed it in 2024. The guest compares this to reviews that rated the Nokia above the iPhone, and to the 70 years it took cars to reach mass adoption: people overhype in the short term and underestimate in the long run.
What remains valuable. Asked about a LinkedIn post claiming that data scientist and analyst titles are becoming less relevant, the guest calls "data scientist" a vanity title, invented to recruit people away from Google. A student's two-hour Cursor build of a hair-pulling detector stands in for how fast technical skill is losing value. The co-hosts agree that identifying and framing problems is what lasts, and the guest's slide says difficulty is orthogonal to value. On communication, the guest calls it a tool rather than a destination. The guest's point is that you need enough depth in a skill to judge whether an AI answer is better, and that data science is a craft learned by doing.
The working setup. As of January 31, the guest recommends Cursor's agent mode and describes agentic systems as an LLM, a protocol for calling tools, and an orchestrator. The guest's setup uses o1 Pro to plan and Claude Sonnet to execute. In a clip, Cursor turned a SQLite database into a director-level weekly business review and fixed its own bug along the way. A co-host says ChatGPT once let them do several days of notebook analysis in about an hour.
The window. The guest says even top-company data scientists use AI too little because they are busy, and predicts mass adoption of agentic coding in 10 months and agentic-native products in 18. A host calls the gap an arbitrage. The guest adds that incumbents may still resist, as Kodak did. The guest's preparation route is Karpathy's GPT-2 walkthrough plus a published project, which the guest says takes about two months. To separate signal from noise, the guest applies the scientific method: build a mental model, hypothesize, predict, and test.
Josh Starmer, creator of the StatQuest YouTube channel, tells the Data Neighbor podcast hosts that explaining anything well comes down to three habits: tell it as a story that starts from a problem, edit ruthlessly down to a few main ideas, and keep practising on a real audience. Starmer ends on an argument for learners: let a real problem decide which theory to learn, because older, cheaper methods are often the ones that solve it.
Origins. Starmer began making videos to teach basic statistics to seven or eight colleagues in a genetics lab, so they could look up R-squared or a p-value while reading a paper. An early genetics video got about a thousand views in a week; the principal component analysis video opened the channel to people outside genetics.
Story and editing. A junior-high friend's advice to tell a story start to finish, without skipping around, led Starmer to the arc of romcoms and superhero films: a problem, a failed first attempt, learning, resolution. Textbooks start with an equation instead. The PCA lesson starts from a problem, data with too many variables to draw, and leaves out history. Editing matters as much: a viewer's note that Starmer dwelt too long on one detail showed that details are glue but main ideas carry over. The hosts tie this to decks shrinking with seniority, and a co-host says 90% of impact lies in how work is packaged.
Three ideas at most. "Bam, double bam, triple bam" marks three points per video; a fourth is too much. Logistic regression, planned as one video, became 11 after slide 533.
Audience and practice. Starmer tries to see things from the audience's daily life, swapping urns of marbles for M&M's. An audience that asks nothing and says "we get it" understood nothing. Weekly Friday "stat chats", encouraged by a boss, Terry Magnuson, built the skill, and drafts still go to the lab, including a reinforcement learning video due in the next couple of months.
Problems before theory. Find the problem first and let it guide the theory; it also supplies the data. At a hospital, Starmer built a nutrient calculator for neonatal-unit doctors instead of following a boss's jargon. Chasing the newest technique is the other trap: linear regression is cheap, quick and transparent where an LLM's rationale is hard to trace.
Aishwarya, a generative AI tech lead at AWS's Generative AI Innovation Center, who also teaches and advises researchers, tells the Data Neighbor podcast hosts that AI engineering is a problem-first discipline. An AI engineer decides whether a business problem is an AI problem at all, picks the usage paradigm (prompting, RAG, agents or fine-tuning), and ties evaluation to business metrics. The episode ends on evaluation as the hardest part, and on data, not models, as where failing systems get fixed.
What clients bring. At AWS, clients arrive with business problems and Aishwarya's team of applied scientists, solution architects and strategists designs, prototypes and scales solutions on Bedrock. Typical cases are knowledge search, chatting with video, SQL generation, NFL match footage, and a legal firm's thousands of contract PDFs, which Claude parsed into structured form. Part of the job is telling leaders what generative AI should not do. Therapy is too subjective for systems that are stateless and costly to retrain, and a fixed if-else workflow needs an integration, not AI. Aishwarya distrusts "AI first" companies, and says many people asking for agents have never heard of RAG.
How we got here. Aishwarya traces neural networks, RNNs and LSTMs, the 2017 Transformer, which processed words in parallel, and the discovery that scaling models and data alone improved performance. ChatGPT's 2022 interface followed, then the enterprise problem: generalist models lack private context. Prompt engineering came first, then RAG as open-book question answering, needed partly because context windows were around 32,000 tokens. Agents followed, using the LLM as a decision-maker that calls tools such as web search. Since 2023 the innovation has been at the application layer, where AI engineers work through an API.
The role. An AI engineer translates business problems into AI problems and evaluation metrics into business metrics. Frameworks matter little, since they get replaced and AWS uses Bedrock agents rather than LangGraph. Nondeterminism, including hallucination and sycophancy, is what separates the work from software engineering. In Aishwarya's team, applied scientists design solutions and metrics while machine learning engineers productionize them.
Getting in. The common mistakes are tutorial hell and a GitHub page of checklist projects nobody needs. Build on your existing domain and push a prototype toward real conditions: large documents, access controls, guardrails, a thousand concurrent requests. Learn the four paradigms first, through Aishwarya's free 10-week GitHub course and DeepLearning.AI's short courses, then automate a repetitive pain point. Aishwarya's own example is an agent that turns daily paper scores into a monthly list on GitHub. The estimate is three or four months to build competently, judging models on cost, latency, performance and evaluation, and about a year to follow research. Prompt engineering as a separate skill is fading for everyday users, Aishwarya says, as models choose tools themselves; what remains is ordinary communication.
Evaluation and data. For a chat-with-documents system, Aishwarya starts from budget, latency and performance constraints, which narrow the model choice. An evaluation set comes from past logs or synthetic data designed with subject matter experts, and data analysis looks for conflicting answers. RAG comes next, agents where data spans SQL, PDFs and video, fine-tuning for niche domains, then observability and LLM judges. Keyword metrics like BLEU and ROUGE fail when a right answer has a hundred phrasings. LLM judges vary widely when scoring 1 to 10 and favour verbose answers, so binary metrics work better, and a judge's reasoning should be checked against the human's. The AI engineer, not the domain expert, must ask the questions that calibrate the judge. Whatever the model, broken applications usually trace back to messy data.
Looking ahead. A host predicts the AI engineer role splitting into specialist functions within about five years; Aishwarya expects vertical, domain-specific AI engineers instead.
Manisha, a data science leader at Google and founder of Prep Vector, talks with Shane and a co-host on the Data Neighbor podcast about building a long data science career and moving into leadership. The episode's argument is that advancement is earned before it is granted: act like a leader before the title, tell your manager early what you want, be deserving of it, and present your work in terms of business impact rather than technique.
Three foundations. Manisha starts with three habits for a long career. Keep learning, because what was called analytics 12 years ago has become data science, ML and now AI. Build relationships, because over the long term much happens through networks: a previous manager moves companies and starts hiring. Be extremely good at the core job, since there is no workaround. A host links the second to the third: people stay in touch with someone whose work they remember.
Leading without the title. For leadership roles Manisha adds knowing your own values and leadership style, staying hands-on enough to understand the team's work, and talking to managers, skip-levels and their peers to learn business priorities and OKRs. Leading and managing differ. Anyone, even an intern, can lead by fixing what is broken. The signals Manisha watches are small: running an agenda, writing documentation, chasing late data, good feedback from partners, volunteering for shadowing. The IC and manager tracks are parallel and neither is better. The difference is looking inward at your own credit versus outward at others' success, and only managers carry performance management.
Asking for it. The co-host spent a long time doubting being a good manager, then asked, learned what was missing, did the work without the title and asked again. The co-host estimates perhaps 5% of people ask, women especially rarely. Manisha's addition is to "be deserving of what you ask for", so that the goal is a goal and not a dream; promotions lag the behaviour, and being calm and centred is noticed. Shane recalls PwC's promotion day, when top reviews were not enough because the partner needed six months' notice. Manisha was once passed over too, and a friend's lesson was "the crying baby gets the most attention".
Hiring. Manisha says most companies look for technical skills as table stakes, the ability to structure a vague problem into a clear plan, and culture fit. Candidates should treat the interview as a brainstorming conversation and judge whether they want the team. The co-host probes self-awareness by asking candidates to rate themselves from 1 to 10, then tests the claim with deeper follow-ups that expose people presenting a team's work as their own. Manisha asks only that candidates name their part.
Job search and switching in. The common complaint at Prep Vector is applying without replies, usually with one resume for every role. Manisha's fix is a base version tailored in about 10 minutes per job description. What candidates most lack is industry perspective: interviews pose business problems, not definitions, and nobody is promoted for model accuracy. A host's example is a resume quantified in precision and F1 instead of revenue or time saved. Beginners should build something, such as a Kaggle notebook, before reading company tech blogs, and programming skill stands out now that data scientists sit inside product teams. Moving from healthcare consulting, Manisha found A/B testing was the gap, and kept consulting's stakeholder and simplification skills as strengths.
Underrated skills. Answering a LinkedIn follower, Manisha names talking about one project at different altitudes, in detail with researchers and at the level of OKRs with a VP. Shane names prioritisation and saying no against stakeholders' goals, and the co-host names creativity in storytelling.
Karan Singh, an engineering leader and senior software engineer at Salesforce, walks the Data Neighbor podcast hosts through how AI reached large language models and agents. The position Karan ends on: today's LLMs are powerful retrievers that cannot yet reason, agents and RAG work around that, and artificial general intelligence follows once reasoning is solved, which Karan predicts within 5 to 10 years.
A career built on pivots and contacts. Karan moved from Android development, through a master's in software engineering with a data minor, into deploying machine learning models under compliance constraints at a fintech, and then to bringing AI into Salesforce's infrastructure layer. Both later moves came from phoning former managers, which the hosts present as the case for keeping early connections.
From rules to Transformers. Karan traces 1960s rule-based systems, probabilistic models, traditional machine learning such as linear and logistic regression, and neural networks that infrastructure held back until deep learning. A neuron is described as a linear unit with parameters, like m and c in y = mx + c, passed through an activation. Transformers allowed parallel training, which is why only the largest companies with infrastructure build frontier models.
Agents and jobs. An agent gives the LLM "brain" tools: a writer, an email sender and an SMS sender replace a month of if-else code. Karan argues that software engineers are still needed, with humans in the loop, and compares the shift to moving from PHP to React. The hosts add that creativity and domain knowledge decide what anyone can get out of these tools.
Retrieval is not reasoning. An LLM resembles a reader with photographic memory: trained on bad data, it answers anyway, and hallucination is sequence completion. RAG grounds answers in supplied knowledge and allows source tracing. Karan says AGI arrives once reasoning works, citing ReAct-style prompting and OpenAI's new reasoning models, alongside responsible-AI work. For learners the episode recommends DeepLearning.AI, Andrej Karpathy's videos, agent frameworks, and a daily AI news article for the non-technical.
This episode of the Data Neighbor podcast traces how VK, a former data journalist, became a data engineer at Meta. Its argument, made by guest and hosts alike, is that the path was found by trial: trying very different work, noticing what was enjoyable, and choosing the role that fit over the one with the most buzz. VK ends wanting to become a "full stack data professional" and holds that data engineers stay relevant by building AI's data foundation and using AI themselves.
From journalism to code. VK studied data journalism at the University of Missouri, partly because writing in English was hard to stand out in. The investigation was the part VK loved: one soybean-production story was picked up by the Associated Press. At the San Francisco startup Hoodline the data journalist title became "journalist engineer", generating neighbourhood news from geospatial and third-party data. VK describes a steep first year, learning coding and statistics from a manager and a mentor and by reading colleagues' code. The hosts draw the lesson that a transition is easiest inside your current company.
Finding the fit at Nextdoor. Nextdoor acquired Hoodline about six months after VK joined, and the team became a content data science team. Working on an ML image classifier alongside a pipeline-and-reporting project, VK felt the difference, was loaned to analytics engineering for six months, and stayed. VK defines analytics engineering as building the pipeline foundation and dashboards that enable analytics and ML, and equates it to data engineer at Meta and business intelligence engineer at Amazon. VK regrets not seeing this sooner, reckoning it cost at least two years, and notes the first promotion came only after the switch.
Moving for scale. As the analytics engineer on XP, Nextdoor's in-house experimentation platform, VK saw a prototype work in six months and maturity within a year, then left for Meta to work with larger data. VK credits Nextdoor's data science director with advice to find a role model for each career path.
Advice to newcomers. VK suits the job to people who enjoy cleaning data, organizing things and visualizing it. The suggested test is online SQL and Python courses, then LeetCode as a stand-in for real problems. Juniors are judged on execution and seniors on deciding what is worth doing. On AI, VK expects tooling to improve while the role must redefine its purpose around clean, real-time data foundations.
This Data Neighbor podcast episode follows a senior data scientist at Microsoft from a small town in Nepal through a 2009 recession, US military enlistment and federal data work into big tech. The guest's argument is that the detour was an asset: the military built resilience and leadership that he says take longer to learn than technical skills, while years as a cyber-defense analyst gave him the domain knowledge and customer focus that, in his account, matter more than model building. He ends on advice to new graduates: a personal roadmap, a mentor, and one subject learned fully before the next.
Getting to the US. The guest stayed in Nepal for a computer science degree at the Nepal College of Information Technology, turning down admission abroad because the undergraduate scholarship at home was larger and international students faced costs after 9/11. He came to the US in 2007 for a master's in information systems in upstate New York.
The 2009 decision. Graduating into high unemployment, he joined a job consultancy in New Jersey and left after about a week because it applied his resume to every role regardless of fit. With his OPT due to expire within a year, a friend on the subway passed him a recruiter's card for a temporary government program recruiting people with specialties; he was 60% to 70% decided on the 90-minute train ride home. His family's first answer was to come home. He signed around October 2009, kept the 30-day option to cancel, and started training in February 2010.
Training. Basic combat training was three months, from 4am to 10pm, with no phone and no weekends, required of every recruit whatever their job. The hardest part for him was mental: standing beside high-school graduates with a master's degree and wondering whether he was going backward. Five months of job training followed in supply and logistics, a role chosen because non-citizens could not work on computer data.
Preparing the exit. He built a Microsoft Access database and forms to replace his unit's Excel files and took a military-funded online MBA. Facing the choice to re-enlist, he saved three months of terminal leave and moved to San Diego, where VA-approved courses carried a housing benefit. Within a month he had a contract data analyst role with a US Navy cyber security unit, went full-time within about six months, and later was selected for a federal program funding a data science master's at the University of San Diego.
Data science at Microsoft. He now works on the security side as something like an internal consultant, building data science for teams with or without their own. He argues ML features come from human experience of the domain and that AutoML without subject-matter experts may not work. His hardest problem type is anomaly detection: tuning for recall creates false positives that erode trust, and benign positives from red teams complicate labelling.
This episode of the Data Neighbor podcast follows a guest who went from quantitative finance analyst to business analyst, business intelligence engineer, data scientist at Meta and, less than two months before recording, full-time entrepreneur. The conversation argues that such moves come from knowing your current priority, taking an imperfect first step, building skills on the job and promoting yourself loudly, supported by confidence and relationships that formal career ladders never mention. It ends with the guest's interview checklist and a step-by-step route into data for people outside it.
From finance to a foot in the door. The guest studied industrial engineering at UC Berkeley and, as an international student, needed any job that would sponsor a visa; about 40 interviews yielded one offer, at Bank of America. A junior-year internship at Facebook had ended without a return offer, which the guest blames on imposter syndrome: almost silence in meetings, no requests for help, and no relationships with the manager or team. The finance job took the guest to Charlotte, where they danced as an NFL cheerleader at the Super Bowl, an experience they would not trade for the millionaire-by-30 path a return offer might have brought. After failed interviews about two years out of college and rejections for five to seven data science roles a year later, the guest took an Amazon business analyst job at a 40% pay cut, which they say paid off in the long run.
Knowing your metric. A co-host frames this as knowing the metric you are optimizing, whether compensation, entry to a field or management. The guest agrees priorities shift every few years: tech at all costs then, compensation first four or five years later, once in tech with bargaining power.
Building a promotion case. At Amazon the guest found the job was mostly writing simple SQL pulls, pitched a self-serve tool to the director, and built it with an AWS database, pipelines and an Excel/VBA front end using free AWS credits. That became the evidence in a push to BIE, backed by a supportive manager; later docs arguing for headcount turned the side project into a team of five BIEs. Talking to product managers filled the product gap, and Meta made an offer on the third attempt. The hosts call this being "noisy"; the host describes brag documents at Stripe, the guest says Meta's performance reviews worked the same way, and the host says his staff promotion depended on people beyond his manager knowing him.
Confidence and superpowers. The host recalls staying quiet in consulting meetings and credits managers who amplified his work. A co-host describes feeling out of place among PhDs until owning executive storytelling as a superpower. The guest argues creativity matters more as standard problems are automated. Confidence lessons follow: a mentor's "confidence of a man", a hedged statistic that women apply at 90% of qualifications and men at 50%, and "no one here knows what they're doing."
Work-life balance. The host says long hours at Nextdoor doubled his salary, while consulting gave top reviews but no promotion or raise. A co-host argues balance matters only when work is not for yourself, and the guest says the best managers were the hardest critics. Their top lessons were raising the return on time: working on important problems, productionizing pipelines, getting feedback early and learning to say no.
Going solo. The guest left a full-time role to test a hypothesis that AI makes one-person businesses easier to start and run, supported by family, a partner and a friend who run businesses, and some savings; they caution the story may differ a year on.
How to get hired. As a coach, the guest ranks communication first, then SQL beyond advanced practice problems, then a short list of statistics applied well, then mock interviews, with large gains over about 10 sessions. Analysts should transfer internally, use referrals and keep resumes simple with quantified impact. Outsiders should master Excel or SQL before Python, build Kaggle projects from a list of 10 industries, volunteer on real data, and persist: the guest cites people applying to 6,000 jobs for 11 interviews and says their own route took four years.