Skip to content

Writing

Verloop NLP Interview Prep Guide

Update, September 2021: This guide is a little outdated, but not obsolete. I no longer work at Verloop.io.

Preparation Guide

I've been an early Machine Learning Engineer at Verloop.io for almost 1.5 years, primarily working on NLP problems and now more in an Engineering Manager-ish role.

This is the guide which I sometimes send to our candidates after they submit the Programming Challenge. If a candidate has relevant open source code sample, specially to other repositories we may choose to waive off the Programming Challenge completely.

I originally wrote this to give a chance to folks coming from non-NLP background to get a sense of the problem space a little better. I'd hoped that it'd absolve smart people of the assumption that Churn, Text Generation and Image Segmentation can be all solve with the same idea-kit, but no luck.

I hope this is most useful to candidate interviewing for ML roles in companies similar to us in terms of size, scale and challenges. This is also useful to:

  • Early career folks - typically less than 2 years of NLP experience
  • Folks coming from Computer Vision/Tabular Data/Classical ML background

The Role

Machine Learning Engineers at Verloop develop technologies that influence how users interact, engage and feel about chat and customer service. As a/an MLE, you will specialize in supervised/unsupervised learning and apply techniques to various problems, mostly dealing with high volume natural language processing applications.

At Verloop, the same team of engineers owns the entire stack from research to production. This means that the following roles HAVE NOT EXISTED at Verloop:

  1. Data Scientist:

    • Does: Data Analytics, Exploration, Model A/B Testing and Data Modeling
    • Tools: Everything from Data Viz to Excel, Pandas, spaCy and Scikit-Learn
  2. Data Engineer:

    • Does: Builds ata pipelines, storage, data version control, monitoring
    • Tools: Kafka, Airflow etc.
  3. ML Researcher:

    • Does: Trains forward looking, NOT production ready models. Focussed on experimentation
    • Tools: huggingface/transformers, spaCy, flair (by Zolando Research)

All of the above is done by MLE at Verloop. Every engineer is expected to build a strong suite in one or more of the above roles, while maintaining a high minimum at the others.

Verloop MLE often contribute to adjacent/overlapping challenges such as DevOps for Machine Learning aka ML Ops. These are often problems in model serving, automated deployment, data versioning, model monitoring, alerting and other parts of developer tooling.

Programming Tips

Write your code (unless otherwise stated) as if you are deploying this code to production. So anything which you'd want to pay attention to for your production code should ideally be there.

That said, here are some things which we pay attention to in your code sample:

API & Object Oriented Design

  • Almost always useful to separate views from models
  • If you are implementing REST, do REST properly
  • Keeping common sense names for endpoints make everyones life easier

See 12 Factor App for the gold standard on App Dev practices, here we select only a few and explain what we pay attention to

Code Readability, Style & Design

  • Use tools like isort in Python to neatly organize your imports. Avoid using fastai style imports of from X import *
  • Docstrings for functions, inline comments where applicable to explain the "why" or "how" - but not what
  • We like the style to be consistent. E.g. in case of Python, following PEP8 or Google Styleguide will improve your code readability by a lot
  • In Python, type hints will make your and our life easier when we have to debug something

Developer Hygiene

  • Use a requirements.txt, conda environment.yml or Dockerfile to declare your dependencies
  • Write tests!
  • Use logging. Generously with levels. But not so much that it slows your production performance.
  • README with comments, notes, assumptions and what the code is doing

Machine Learning Tips

In contrast to interview processes which go wide, covering everything from Probability, Statistics, Linear Algebra to Deep Learning and everything in between - we go deep on primarily one aspect: Applied Natural Language Processing. We operate close to Research, occassionally doing research even.

These are supposed to be indicative/descriptive of the technical skill we desire. These are not prescriptive i.e. you do not have to do the course to clear our interviews.

We just have seen everyone with equivalent skill as these courses do well in our interview process.

Deep Learning

  • Basics for Beginners: FastAI Part 1 & 2
    • Trivia: 2 out of our team of 6 have been fast.ai International Fellows.

Natural Language Processing Deep Dive

General Interview Tips

Think Out Loud -- We want to understand how you think, so explain your thought process and decision making throughout the interview.

Remember we’re not evaluating your technical ability alone, but also how you solve problems.

Clarify -- Many questions will be deliberately open-ended to provide insight into what parts and information you value within the technological puzzle.

We’re looking to see how you engage with the problem and your primary method for solving it.

Be sure to talk through your thought process and feel free to ask specific questions if you need clarification.

Do your Homework -- The primary reason that this is a Take Home Challenge plus a discussion is that we don't want to evaluate your ability to think on your feet.

That said, if you come to the interview without enough homework on your own submission and question -- you'll be put in a place where a lot of thinking will in fact be on your feet.

Machine Learning Interview Technical Prep

  • At least one interview will be focused on your expertise within Machine Learning. General knowledge of the field and its main concepts should be demonstrated throughout the interview, such as supervised learning, unsupervised learning, overfitting, boosting, and regularization.

  • Experience with common learning paradigms such as decision trees, k-means, LSTMs and understanding of how to apply those techniques to various problems is important.

How to Prepare?

  • Get extremely comfortable with writing code to do Machine Learning (and by extension, Deep Learning). This means knowing what to google, what libraries to use and so on is very valuable.

  • Be mentally prepared to talk about your approaches and results. This is effectively a defence of your work. Help us understand why you made certain decisions, choices, and what went in your head.

  • Get comfortable working with real world text datasets, for instance multi-lingual datasets, code-mixed. Look for sample efficient learning methods and learn where these models fail or mislead.

Things to Think About

  • This round is case-study driven. We value initiative and experimentation speed+quality over success. This means that even if you try an approach, which does not work for some reason - show us the work that you did: We’d love to learn what you tried.

  • Ask yourself why would they have selected this problem for the challenge? What are some basics in this domain I should know about?

  • What is the highest level of accuracy that others have achieved with this dataset or similar problems/datasets?

  • What types of visualizations will help me grasp the nature of the problem/data?

  • Which modelling techniques are good at capturing the types of relationships I see in this data?

  • What are some of the weaknesses of the model and how can the model be improved with additional work?

  • How do I measure performance? Does it help to have confidence values against the prediction?

  • What is latency and compute needs for this model?


This document is inspired by similar documents by Google Inc. I borrowed from the best when relevant.

Talent Cooling

Talent Cooling Kills Startup Growth

Evaporative Cooling of talent occurs when the most high-value contributors to a community realize that the community is no longer serving their needs anymore and, therefore, leave.

Then something remarkably interesting happens:

When that happens, it drops the general quality of the community down such that the next most high-value contributors now find the community underwhelming. Each layer of disappearances slowly reduces the average quality of the group until such a point that you reach the people who are so unskilled and unaware of it that they’re unable to tell that they’re part of a mediocre group.

This applies to startups trying to scale/grow as well. For small teams, as little as 1-2 resignations can open a dam of exits.

Best Engineers are a Guild

A useful mental model to have is this: Engineering is a Guild.

Makers, and particularly software engineers are loosely defined guilds. The guild-like behaviour emerges partially because the best engineers are ~within 3 degrees of each other at any particular given point in time. The guild decides which companies and offices it wants to support.

Most entrepreneurs and business folks e.g. product managers do not seem to mentally acknowledge the tacit existence of this guild early enough.

Recognizing Mediocrity

Here is one version of how this story plays out:

As you scale, you hire some amazing technology people. Build an engineering team. You build something useful together. 1-2 people quit.But you’re okay. You’ve promoted the people who trained under the expert. That is how you grow “your people”. You’re hiring some senior external talent too!

After a while, your tech team is unable to ship fast enough and sometimes even your basic hygiene factors like uptime are suffering. “Refactoring” becomes a rallying cry instead of shipped.

Product is blaming tech, and within tech, different functions e.g. front end vs backend work with varying degrees of distrust.

Here is where things get truly interesting. You’re now actively fighting the Fiery Demon of Talent Cooling.

The new engineering manager instils a bunch of processes, hires some amazing people and shows a lot of movement. But when you look back 1-2 quarters later, you’re again at the same place: there is no fire in your shipping engine.

Why? Because it’s extremely hard for mediocre people to realize that they’re in a mediocrity.


Sources/Further Reading: 1. https://web.archive.org/web/20190328104722/http://blog.bumblebeelabs.com/?p=1207 2. https://medriscoll-com.cdn.ampproject.org/c/s/medriscoll.com/post/9117396231/the-guild-of-silicon-valley/amp 3. If you’re interested in avoiding losing your best tech talent to discomfort and boredom, this is an excellent starting point, written by a practitioner: https://randsinrepose.com/archives/bored-people-quit/

Shreyas Karanth: Moving from SW Engg to Product

Shreyas Karanth is a Product Manager at Soroco. Soroco is a Medium-sized Enterprise-focussed B2B Automation company. Before Product Management, Shreyas was the fastest growing engineer - going from a fresh grad to a Technical Lead within 3 years of graduation.

This is also when I worked with him, during his engineering days. Here, I asked a bunch of questions why he moved to Product Management, what excites him and what he considers as Product Management work at Soroco.

Background

Nirant: How many people work at Soroco now?

Shreyas: Actually, closer to 250 I think, with around 170+ people in engineering

Nirant: And how many people can you distribute work to?

Shreyas: PM work? No one. There are 7-8 engineers in my team though.

Nirant: What is PM work here?

Shreyas: Customer demos, sales collateral, market research, sprint planning, end user facing documentation.

Nirant: Demos and collaterals should be with the functional team, right? Also, what product do you PM - if I may ask?

Shreyas: What do you mean by the functional team here? And I was PMing an internal product, where we had built a single interface to monitor and control automation systems and their dependencies.

It was originally slated to be a companion to our automation systems, but we started selling it as a standalone product by itself, a few months ago.

Nirant: Functional team - e.g. sales collateral comes from Sales team, docs from tech, market research from sales/business development.

Shreyas: And before that, I worked for 3 months as a PM to build a demo version of one of our products. It was basically our enterprise offering with stripped down features, deployed as an Electron app, so that customers can download it on their machines and test out the tool quickly.

So, Sales doesn't make most of their own collateral. In Soroco, Marketing + Product makes it for them. Rather, we create a library of slides/one-pagers. It's up to Sales to choose the right ones from this library for each customer. And to request for more when it's needed -- because Marketing owns the customer-facing message.

Nirant: What are the advantages of this vs Sales owning it outright?

Shreyas: Tight control over messaging by centralizing it. Also, easier to maintain quality of collateral. Enterprise sales people don't really have the best aesthetic sense.

Nirant: Centralized to who? Marketing?

Shreyas: Yes.

What do you love the most?

Nirant: What have you loved the most, in transitioning from tech to product?

Shreyas:

  1. 90% of the articles I read when I was in tech, were "product" articles. What has been great is actually putting these things (that I'd read over the course of 2 years) into practice. Even small things, like coming up with a set of questions to ask customers, require me to go through articles and books that I'd bookmarked over the years, and then actually using those tips.

  2. Coming up with hypotheses around why certain features need to be built is also enjoyable to me. Putting together what I've learnt from the articles I've read, as well as what I have understood from sales pitches and customer interviews to come up with a view of what to do has been pretty fun.

  3. Here, PMs give a lot of customer demos, essentially doubling up as sales people on some calls. This is one thing, which I've unexpectedly come to enjoy (If you hadn't noticed already, I don't really talk much).

  4. Understanding all the other details that go into actually releasing a product in the market has been fun. Some of the things I've really enjoyed are: understanding how to price your product, figuring out whether you should go all-in on SaaS or keep an on-prem option, market research, competitor analysis and even fine-tuning sales pitches. Basically, I get to sample (almost) everything that goes into building a product.

What has been the hardest?

Shreyas:

  1. Preventing myself from getting into the technical details has been pretty hard. I've come to look at it this way: If things break, I'm not going to be the one who is going to dive in and fix it; that'll be the engineers. So, I should stop getting too involved here. (credit to @Pentropy for this advice)

  2. Writing in a way that non-technical folks can understand you has been challenging. (However, I think you will have no problem here, based on what I've seen of your writing from when you were in Soroco)

  3. The amount of organizational skills required to be a PM is pretty crazy. I thought of myself as a fairly organized person, but I've found myself coming up short after I became a PM. You need to deal with engineering, sales, marketing and also leadership. And you have only so many hours in the day.

  4. An addendum to the above point is that you will have to inevitably deprioritize some things owing to lack of bandwidth. Some people are bound to be unhappy with the priorities that you've chosen and you have to handle that well, since you may be asking them to prioritize something you need the very next week.

  5. Accountability for things that you can't directly control. You become the scapegoat, in some way, for problems that are hard for you to control. If the tech team runs into an unexpected issue and that delays a release, that's your problem. If the sales team hasn't gotten a good enough response from customers for your product, that's your problem. If the marketing team has been too busy with other things to prepare collateral for you, that's still your problem.

  6. Your responsibilities are very fluid. As a tech guy, on every project/product I worked on, I knew my main set of responsibilities very clearly. I used to help out other people with their responsibilities, but I would make sure that I fulfilled my own first. As a PM, when there's something that needs to be done, and you can't clearly call it the engineering, marketing or sales team's responsibility, it just becomes your responsibility. Sometimes, even when it is another team's responsibility, but they are busy and you need to get it done, you need to just suck it up and do it (like creating marketing collateral).

  7. (Bonus) Oh, I forgot #7 for what's been harder - the feedback loop on my work has become much longer. Code gave me instant gratification, but I am not used to deriving satisfaction from making a market research deck or a specs doc yet. Also, I am not sure whether a lot of the decisions that I have taken were the right ones.

What does your typical day look like?

Shreyas:

  1. Standup in the morning

  2. Calls with engineering to clarify features that I've written specs for

  3. Calls with design to brainstorm UI/UX design for features

  4. Some ad-hoc work for client engagement, which includes, but is not limited to

    • Help with proposals

    • Input and slides for client demos

    • Understanding and prioritizing high priority bugs in the product

    • Calls to understand asks from customers

  5. Prep for client demos (if any)

  6. Prep for customer feedback sessions (if any)

  7. Write down specs and hypotheses for features in the next sprint

  8. Work on fine-tuning:

    • Customer-facing roadmap

    • Slides for sales pitches

  9. Read about competitors

  10. Read about the market, in general

  11. Client demos and customer feedback sessions (if any)

All of the above won't happen in one day. But you can consider this as a sum of what might happen over the course of a typical week.

I may have missed out on a few things here, but I think I got the gist right. Discussions around pricing, product vision etc. happen much more rarely, so I can't really consider that as part of a typical week.

Nirant: Aaah. That is a lot of variety. Thanks a ton! This is next-level detail. And thank you for taking the time to type it out! I'll be able to revisit this because of that!

If you loved this writing, tweet to @shreyas94