Narmi Machine Learning Engineer Interview: Questions, Experience & Prep (2026)

Narmi is a US-based fintech company that builds digital banking technology for community banks and credit unions. Their platform covers digital account opening, online banking, mobile banking, and data analytics for bank clients. The ML team, as candidates report, works on problems like transaction categorization, fraud detection, intelligent search, and customer behaviour insights.

As of July 2026, knok jobradar tracked 12 open roles at Narmi across all positions. Machine Learning Engineer roles at Narmi sit at the intersection of applied ML and financial data engineering. You will likely collaborate with product managers and backend engineers to ship features that go directly to the end customers of Narmi's bank clients.

The interview process typically spans three to four stages: a recruiter or hiring manager call, a technical screen (live coding or take-home), a system design round, and a final behavioral loop. Candidates report that Narmi interviewers pay close attention to how well you handle production ML constraints and fintech-specific concerns like regulatory compliance and data privacy. The exact structure can vary by team, so confirm round details with your recruiter after your first call.

These questions come from publicly shared candidate experiences and the nature of Narmi's banking platform. Expect a mix of ML fundamentals, system design, and behavioral questions across your rounds.

1. How would you build a fraud detection model for a community bank that has very limited labeled transaction data?
2. How would you handle severe class imbalance in a financial fraud dataset, and how does your choice change based on the cost of false negatives vs. false positives?
3. Walk us through how you would design a transaction categorization system that serves multiple bank clients, each with different data volumes and distributions.
4. How would you approach building a personalized financial product recommendation feature inside a banking app?
5. How would you monitor an ML model deployed in a production banking environment, and what signals would trigger a retrain?
6. How do you think about data privacy and regulations like GLBA or PCI-DSS when designing ML pipelines for a company that handles bank customer data?
7. Describe a time you applied NLP to a real problem. How might similar techniques improve search or support chat features in a banking platform?
8. How would you design an anomaly detection system to flag suspicious login or account activity in real time?
9. Tell us about a time you had to explain an ML model's output or its limitations to a non-technical stakeholder.
10. How would you detect and handle concept drift in a model predicting customer churn at a bank?
11. Narmi serves many different bank clients. How would you design models that generalise well across clients with different data patterns and sizes?
12. What trade-offs would you consider when choosing between a rule-based system and an ML model for a high-stakes banking decision?

Q: Tell us about a time you had to explain an ML model's output or its limitations to a non-technical stakeholder.

*Situation:* At my previous company, we built a credit-risk scoring model that flagged a batch of loan applications for manual review. The head of lending operations could not understand why the model was rejecting applications that looked fine to her.

*Task:* I needed to explain the model's logic clearly and rebuild her confidence in the process, without overwhelming her with jargon.

*Action:* I prepared a one-page visual showing the top three features driving each flag, used plain language ('transaction volatility' instead of 'standard deviation of daily credits'), and walked her through two specific examples side by side. I framed the model's value as: 'For every 10 flags the model raises, roughly 7 turn out to be genuine risks that manual review alone would have missed.'

*Result:* She agreed to a two-week trial. After reviewing the flagged cases, she reported the model was catching issues her team would have missed, and it was formally adopted into the review workflow.

---

Q: How would you detect and handle concept drift in a model predicting customer churn at a bank?

*Situation:* At a fintech I worked at, our churn model's precision dropped noticeably after a major interest-rate change in the market. Customer behaviour patterns had shifted, but the model had not adapted.

*Task:* My job was to set up a monitoring system and automated retraining pipeline so we would catch this faster the next time.

*Action:* I added a scheduled job that tracked three things: input feature distributions using Population Stability Index, model output distribution shifts, and live precision against a sample of ground-truth labels collected with a two-week lag. When any metric crossed a threshold, the pipeline sent an alert and triggered a retraining run on the most recent six months of data. The retrained model went through shadow evaluation before being promoted to production.

*Result:* The next time macro conditions shifted, the system detected drift within ten days, retrained automatically, and the team promoted the updated model with minimal manual effort. Prediction quality stabilised and the team gained lasting confidence in the pipeline.

---

Q: How would you build a fraud detection model for a community bank that has very limited labeled transaction data?

*Situation:* A previous client was a small cooperative bank. They had only a few hundred confirmed fraud cases across several years of transaction history, spread across millions of transactions.

*Task:* I needed to build a useful fraud signal despite severe label scarcity.

*Action:* I took a three-part approach. First, I used unsupervised anomaly detection (Isolation Forest and autoencoders) to surface statistically unusual transactions without relying on labels. Second, I applied transfer learning by fine-tuning a model pre-trained on a larger synthetic fraud dataset. Third, I worked with the fraud team to define weak labels using business rules, generating more training signal from domain knowledge. I combined all three outputs into an ensemble and set the decision threshold conservatively to prioritise recall, since missing fraud is costlier than a false alert.

*Result:* The system surfaced flagged transactions that the investigations team confirmed as fraud at a rate the bank described as well above what manual review alone was catching. We used those confirmed cases to expand the labeled dataset and strengthen the supervised component over the following quarter.

For ML system design questions, structure your answer in five parts. Start with problem framing: restate the goal, the key metric (precision vs. recall vs. latency), and any constraints specific to banking like compliance or explainability requirements. Then cover data: what features you would use, how you would handle missing or imbalanced data, and how you would manage client-specific distribution differences. Next, walk through model choice: explain why you would start simple (logistic regression, gradient boosting) before going complex, and name the trade-offs clearly. Then address deployment: batch vs. real-time, latency requirements, and rollout strategy. Close with monitoring: how you would track data drift, model performance, and what would trigger a retrain.

For behavioral questions, use STAR: Situation (one to two sentences of context), Task (your specific responsibility), Action (what you personally did, not what the team did), and Result (a concrete outcome). Narmi interviewers reportedly value answers where the Action portion shows independent judgment, not just following instructions.

For trade-off questions (rule-based vs. ML, precision vs. recall, simple vs. complex), name the trade-off explicitly, give one concrete example from a banking context, and state which side you would pick and why. Avoid fence-sitting: interviewers want to see that you can make a decision and defend it.

For compliance and privacy questions, acknowledge the regulatory constraint first, then explain how it shapes your technical choice. For example, if GLBA restricts sharing customer data across bank clients, explain how that pushes you toward client-specific or federated models rather than a single shared model.

Narmi's ML interview, as candidates describe it, tests four things beyond raw technical skill.

Fintech context awareness. Interviewers want to see that you understand why banking ML is different from general product ML: stricter data governance, explainability requirements for regulatory reasons, and the cost asymmetry between false negatives (missed fraud) and false positives (annoyed customers). Candidates who apply generic ML answers without acknowledging these constraints tend to score lower.

Production ML maturity. Narmi ships ML features to real bank clients, so interviewers look for engineers who have thought seriously about monitoring, retraining, rollback strategies, and serving latency. Notebook-only experience is a weak signal here.

Cross-functional communication. Because you will work with product managers and bank-side stakeholders who are not ML practitioners, interviewers probe your ability to explain decisions and trade-offs in plain language. The sample answers section above shows what this looks like in practice.

Ownership and initiative. Narmi is a growth-stage company with lean teams. Interviewers reportedly respond well to candidates who describe times they identified a problem independently and drove a solution, rather than waiting for direction.

Week 1: Ground yourself in the domain.
Read Narmi's public blog, product pages, and any press coverage to understand exactly what their platform does and who their customers are. Identify two or three ML problems their product likely faces (fraud detection, transaction categorization, intelligent search) and sketch a rough system design for each. This context makes your technical answers land far better than generic ML responses.

Weeks 1-2: Core ML revision.
Refresh the fundamentals that come up most in fintech ML interviews: handling class imbalance (SMOTE, class weights, threshold tuning), anomaly detection methods, gradient boosting (XGBoost, LightGBM), model monitoring, and basic NLP (embeddings, text classification). Practice explaining each concept out loud, not just writing code.

Week 2: System design practice.
Practice designing two end-to-end ML systems: a fraud detection pipeline and a transaction categorization service. For each, think through data ingestion, feature engineering, model training, serving, and monitoring. Use the five-part framework from the Answer Frameworks section.

Weeks 2-3: Behavioral story bank.
Write down four to five real situations from your past work that demonstrate: handling ambiguity with limited data, explaining ML to non-technical people, debugging a production model issue, and working with messy or biased datasets. Structure each as a STAR story before your interview.

Final days: Mock interviews and resume review.
Do at least two timed mock interviews with a peer or via an online platform. Review your resume line by line and prepare to go deep on any ML project you mention, since interviewers typically pick one project and probe hard. If you want to keep an eye on Narmi's openings alongside other opportunities, knok checks 150+ job sites nightly, applies to matching jobs on your behalf, and messages HR for you.

1. Ignoring fintech-specific constraints. Candidates who design ML systems exactly as they would for a generic tech product, without mentioning compliance, explainability, or data isolation between bank clients, signal a lack of domain awareness. Always acknowledge the banking context early in your answer.

2. Jumping to complex models too quickly. Starting with a transformer or deep neural network before mentioning simpler baselines suggests poor engineering judgment. Narmi ships real products; interviewers want pragmatism over complexity for its own sake.

3. Weak monitoring answers. Many candidates can describe how to train a model but struggle when asked what happens after deployment. If you cannot speak to drift detection, alerting, and retraining triggers, this is a gap to fill before your interview.

4. Vague behavioral answers. Saying 'we improved model performance' without describing what you personally did or what the outcome was in concrete terms makes it hard for interviewers to assess your actual contribution. Be specific about your role and the result.

5. Not asking clarifying questions in system design. Jumping straight into a design without confirming scope, scale, and constraints looks like poor engineering instinct. Ask two or three scoping questions before you start building the system in your answer.

6. Treating compliance as an afterthought. Mentioning data privacy at the very end as an 'oh, and we should also think about compliance' rather than as a constraint shaping your design from the start signals that you have not worked in regulated industries before.