MOLOCO ML Engineer Intern Coding Test: How I Prepared and What I Learned

I passed the resume screen for MOLOCO's Machine Learning Engineer Intern role and took the coding test in early March. I passed it and went on to the technical interview.

The test questions stay private under the assessment rules. What follows is how I prepared, where the time actually went, and what I would tell someone preparing next.

What the test looked like

It ran on CodeSignal in three parts.

• Multiple-choice ML concepts: metrics, ensembles, dimensionality reduction, overfitting. Many questions, but quick if you have prepared.
• Compute-by-hand, answer only: simple arithmetic where decimal slips are the risk.
• Implement a function from scratch: this is where scores split. No libraries; you write the algorithm yourself.

Time allocation mattered most. Clear the multiple choice fast and save as much time as possible for implementation.

How I prepared

• Concepts as decision rules, not definitions. Grouping ideas by when to use them (labels or no labels, parallel or sequential) made the multiple choice fast.
• Common algorithms written once without libraries. Clustering, ensemble voting, string scanning: things I normally call in one line are slower to write by hand than you expect.
• Test cases first. Empty input, all-equal input, and ties, written down before the code.

What decided the score: edge cases

All three implementation problems were tricky in the same place. Normal inputs are easy; edge cases fail silently.

• Ties. One character, > versus >=, decides whether the leftmost or rightmost candidate wins. Reading the condition to the end matters.
• An empty group. In an iterative algorithm, the moment a group gets no members you cannot take its mean and the array shape breaks. If you have not decided how to handle it, you find out mid-test. I did.
• Return types. Correct values in the wrong type broke the next step.

If I prepared again

1. One day on concepts, summarized as a single decision table.
2. Five core algorithms written from scratch, each with three edge cases listed first.
3. Before each implementation problem, run "empty, tied, all equal" in your head once.

The gap between knowing an algorithm and implementing it correctly was edge cases.