Junior Developer

Screening notes

Experience

2.5 years as a full-stack developer, first at a Bogotá web agency (React + Node, Postgres), then 18 months at a US-based SaaS startup (TypeScript, Next.js 14, PostgreSQL, AWS). At the startup I shipped features end to end under senior review: a multi-step onboarding wizard, a CSV import and background-job pipeline, and a payment integration with Stripe. I write tests first on anything touching money or user data — the Stripe integration has 94% coverage. I work on US Eastern hours, which means I am in standup, in Slack, and reachable during review cycles without a lag.

Tools

TypeScript, Node.js, React/Next.js, PostgreSQL (raw and with Prisma), Redis, AWS (Lambda, SQS, RDS), Docker, GitHub Actions, Vitest, Playwright for E2E

Scenario answer

Asked: A production endpoint started returning 500s after a deploy. You have logs, git history, and a staging environment. Describe your debugging process in order, and when you'd roll back vs. fix forward.

My debugging order for a production 500 after a deploy: 1. Look at the logs immediately. Not git history yet — I want the actual error message and stack trace. A generic 500 with no context is a different problem than a TypeError on a specific line. 2. Reproduce on staging. If it reproduces there, I am not racing time with production risk. If it does not, that is critical information: environment-specific config, a database state difference, a caching layer. 3. Check git log for the deploy. diff the specific files that could have touched the failing path. I am looking for the last change before the 500 started. Most of the time it is obvious when you see it. 4. If the error is in a specific route or function, I add temporary debug logging to staging and trigger the same request, then read the output. I do not guess when I can look. 5. If staging does not reproduce: check environment variables first. The most common cause of 'works on staging, fails in prod' in my experience is a missing or wrong env var — a database URL, a feature flag, an API key. Then check database state: does production have a migration staging does not, or vice versa? Rollback vs fix forward: I roll back if I have not found the root cause within 20 minutes and the error is affecting a significant percentage of users. An unknown bug in production for 30 minutes while I keep digging is worse than a rollback followed by a clean fix. I would rather ship the fix with tests and a clear explanation of what failed than push a patch under pressure. If I found the cause and it is a one-line fix with obvious scope, I fix forward — but only after testing the fix on staging and having the rollback ready.

Work sample

Asked: Write a function (any language) that takes a list of orders {id, amount, date} and returns the top 3 months by revenue. Include how you'd test it.

// Top 3 months by revenue from a list of orders // TypeScript, but the logic is identical in JavaScript or Python interface Order { id: string; amount: number; date: string; // ISO-8601, e.g. "2024-03-15" } function top3MonthsByRevenue(orders: Order[]): { month: string; revenue: number }[] { // Reduce to a map of month-key -> total revenue const byMonth = orders.reduce<Record<string, number>>((acc, order) => { const month = order.date.slice(0, 7); // "YYYY-MM" acc[month] = (acc[month] ?? 0) + order.amount; return acc; }, {}); // Sort descending by revenue, take top 3 return Object.entries(byMonth) .sort(([, a], [, b]) => b - a) .slice(0, 3) .map(([month, revenue]) => ({ month, revenue })); } // HOW I'D TEST IT // 1. Happy path: 5 months of data, verify the correct 3 come back in the right order. // 2. Fewer than 3 months of data: returns all months, no error. // 3. Empty array: returns empty array. // 4. All orders in the same month: returns one entry. // 5. Tie for 3rd place: both tied months appear (behaviour to confirm with spec). // 6. Negative amounts (refunds): check they reduce the total correctly. // 7. Date parsing edge: an order with date "2024-01-01T00:00:00Z" — slice(0,7) must still give "2024-01" not an unexpected string. import { describe, it, expect } from 'vitest'; describe('top3MonthsByRevenue', () => { it('returns top 3 months sorted by revenue', () => { const orders = [ { id: '1', amount: 500, date: '2024-01-10' }, { id: '2', amount: 300, date: '2024-01-15' }, { id: '3', amount: 1200, date: '2024-02-01' }, { id: '4', amount: 800, date: '2024-03-05' }, { id: '5', amount: 200, date: '2024-03-20' }, { id: '6', amount: 100, date: '2024-04-01' }, ]; const result = top3MonthsByRevenue(orders); expect(result).toEqual([ { month: '2024-02', revenue: 1200 }, { month: '2024-03', revenue: 1000 }, { month: '2024-01', revenue: 800 }, ]); }); it('handles fewer than 3 months', () => { const orders = [{ id: '1', amount: 100, date: '2024-01-01' }]; expect(top3MonthsByRevenue(orders)).toHaveLength(1); }); it('returns empty array for no orders', () => { expect(top3MonthsByRevenue([])).toEqual([]); }); });

Availability

Full-time, 9am–6pm ET from Bogotá. Two weeks' notice.

Screening notes

Experience

2 years as a web developer, starting at a Manila software house doing client projects in React and Node.js, then going freelance 8 months ago. Most of my work is US-based clients — a small B2B tool, a real-estate listing scraper, a Discord bot. I write mostly JavaScript but have done Python for two data-pipeline projects. My weakest area is testing — I have been improving: I now write unit tests for utility functions and API handlers but I do not yet have a systematic E2E test suite. I am self-taught, CS graduate, and I am fast at reading documentation and picking up new libraries.

Tools

JavaScript, Node.js, React, Express, MongoDB, PostgreSQL, Git/GitHub, basic Docker, Jest for unit tests

Scenario answer

Asked: A production endpoint started returning 500s after a deploy. You have logs, git history, and a staging environment. Describe your debugging process in order, and when you'd roll back vs. fix forward.

When a production endpoint returns 500s after a deploy, my first step is to check the server logs for the actual error. The stack trace usually points to the specific file and line. While that loads I would also check the git log to see exactly what changed in the deploy — sometimes you can spot the problem in the diff before you even see the error. Once I have the error, I try to reproduce it on staging. I use the same request that triggers it in production. If staging reproduces it, I can debug without touching production. For actual debugging: if the error points to a database query I check whether the schema migration ran correctly. If it is an import or require error I check package versions. If it is a runtime error I add logging around the suspect code on staging and trace through the execution. For rollback vs fix forward: if I cannot reproduce the issue within about 15 minutes and real users are hitting errors, I would roll back to the previous working version and investigate calmly. Rolling back is always the safer choice if the fix is not obvious quickly. If I found the bug and it is a small targeted change, I fix forward but only after testing on staging.

Work sample

Asked: Write a function (any language) that takes a list of orders {id, amount, date} and returns the top 3 months by revenue. Include how you'd test it.

// Top 3 months by revenue — JavaScript function top3MonthsByRevenue(orders) { // Build a revenue map keyed by 'YYYY-MM' const monthMap = {}; for (const order of orders) { const month = order.date.substring(0, 7); monthMap[month] = (monthMap[month] || 0) + order.amount; } // Sort and take top 3 return Object.entries(monthMap) .sort((a, b) => b[1] - a[1]) .slice(0, 3) .map(([month, revenue]) => ({ month, revenue })); } // Testing approach: // I would write unit tests using Jest with these cases: // - Normal case: spread across 4+ months, verify correct top 3 and order // - Empty input: should return [] // - Only 1 or 2 months of data: should return all months (not crash) // - All orders in one month: should return that month only // - Multiple orders in same month: amounts should be summed correctly // - I would also manually test with real-looking data before shipping // Example test: const orders = [ { id: 'a', amount: 400, date: '2024-01-05' }, { id: 'b', amount: 200, date: '2024-01-20' }, { id: 'c', amount: 900, date: '2024-02-10' }, { id: 'd', amount: 350, date: '2024-03-01' }, ]; console.log(top3MonthsByRevenue(orders)); // Expected: [{month:'2024-02',revenue:900},{month:'2024-01',revenue:600},{month:'2024-03',revenue:350}]

Availability

Full-time, flexible hours. Available immediately.

Screening notes

Experience

1.5 years as a junior developer at a Bangalore startup working on a React frontend and a Python/Django backend. I have worked on building UI components, writing API endpoints, and fixing bugs. I have used Git throughout and submit code for review regularly. My main languages are Python and JavaScript. I am still building my testing skills — I can write unit tests but I am not confident with integration tests yet. I have a computer science degree and I learn quickly.

Tools

Python, Django, JavaScript, React, PostgreSQL, Git, basic Linux commands

Scenario answer

Asked: A production endpoint started returning 500s after a deploy. You have logs, git history, and a staging environment. Describe your debugging process in order, and when you'd roll back vs. fix forward.

If a production endpoint starts returning 500 errors after a deploy, the first thing I would do is check the application logs to see the error message. This usually tells you what went wrong. Next I would look at what was changed in the deploy using git log and git diff to see which files were modified. This often points to where the bug was introduced. Then I would try to reproduce the error in the staging environment with the same request or data. If it reproduces there, I can debug safely. For debugging I would add print statements or logging to the relevant code to trace the execution. I would also check the database to make sure any schema migrations ran without problems. If I cannot find the problem quickly and a lot of users are affected, I think the right call is to roll back to the previous version. It is better to have the old working version running while you investigate carefully than to leave users seeing errors. I would fix forward only if I already understood what the problem was and had a simple, tested fix ready.

Work sample

Asked: Write a function (any language) that takes a list of orders {id, amount, date} and returns the top 3 months by revenue. Include how you'd test it.

# Top 3 months by revenue — Python def top3_months_by_revenue(orders): """Returns the top 3 months by total revenue. Args: orders: list of dicts with 'id', 'amount', and 'date' (YYYY-MM-DD string) Returns: list of dicts {'month': 'YYYY-MM', 'revenue': float}, sorted descending """ from collections import defaultdict month_totals = defaultdict(float) for order in orders: month = order['date'][:7] # 'YYYY-MM' month_totals[month] += order['amount'] sorted_months = sorted(month_totals.items(), key=lambda x: x[1], reverse=True) return [{'month': m, 'revenue': r} for m, r in sorted_months[:3]] # How I would test it: # import unittest # class TestTop3Months(unittest.TestCase): # def test_basic(self): # orders = [ # {'id': '1', 'amount': 100, 'date': '2024-01-01'}, # {'id': '2', 'amount': 200, 'date': '2024-01-15'}, # {'id': '3', 'amount': 500, 'date': '2024-02-10'}, # {'id': '4', 'amount': 300, 'date': '2024-03-05'}, # {'id': '5', 'amount': 50, 'date': '2024-04-01'}, # ] # result = top3_months_by_revenue(orders) # self.assertEqual(result[0]['month'], '2024-02') # self.assertEqual(result[0]['revenue'], 500) # self.assertEqual(len(result), 3) # # def test_empty(self): # self.assertEqual(top3_months_by_revenue([]), []) # # def test_fewer_than_3_months(self): # orders = [{'id': '1', 'amount': 100, 'date': '2024-01-01'}] # result = top3_months_by_revenue(orders) # self.assertEqual(len(result), 1)

Availability

Full-time, IST timezone (UTC+5:30). Available in 30 days.