Собеседование в стартап

Как обещал выкладываю как прошло сегодняшнее собеседование, вернее даже два. Это было собеседование в один немецкий стартап, который хочет отжать часть рынка у SAP и, возможно, продаться им позже :)

Изначально мне говорили выбрать один из языков компании для собеседования - Typescript или Python. Я – Java-разработчик, но обычно не составляет труда переучиться чему-то новому. Выбрал Python, немного глянул синтаксис.

Первое собеседование выглядело следующим образом: мне дали проект, похожий на проекты компании. В проекте была реализована система учета: магазин, баланс (доходы/расходы), склад. Были реализованы операции покупки/продаже товара, получения инвестиций и другие.

Сначала мне дали самостоятельно ознакомиться со всеми реализованными классами. После этого позадавали вопросы, чтобы посмотреть как я понял код.

Потом дали написать юнит тест на один из методов. Рядом был тест на другой метод, так что я мог смотреть его реализацию. Это очень помогло, потому что на питоне я никогда не писал юнит-тесты. И вообще в последний раз использовал питон для учебного проекта в универе в 2011м году.

После юнит теста меня попросили найти баг в другом методе. Сначала я подумал, что баг будет прям очевидным. Но все оказалось немного сложнее. Баг заключался в том, что в операции "продать товар" сначала в бухгалтерский отчет вносилась информация о продаже, а потом оформлялась сама продажа. И если на складе было недостаточно товара, то функция "продать" выбрасывала исключение. Но из бухгалтерского отчета запись никуда не девалась.
К счастью, этот баг я смог обнаружить и пофиксить переносом записи в отчет после "продажи".

Дальше мне показали одну из функций, где нужно было найти что-то по ID, и сказали, что эта функция работает медленно. Попросили улучшить ее производительность. Я сразу увидел, что ищем мы по списку. Предложил вместо списка использовать Map (или dict в Python) с ключом ID и самим элементом в виде значения в мапе. Поиск по списку занимает O(N), а по мапе O(1) - (но это не точно, а вернее не всегда :))- про эти оценки напишу отдельную статью. Интервьюеров ответ удовлетворил, попросили исправить везде в коде.

Попутно просили оценить сложность различных функций, используя Big O нотацию. С этим у меня нет проблем уже давно.

В конце попросили реализовать новую функцию.

На вход функции поступал список из JournalEntity - сущность, хранящаяся в бухгалтерском отчете. JournalEntity содержал в себе разные поля, включая credit_account_id, date (дата и время операции) и amount (сумма операции). Функция должна была вернуть dict[date, Summary], где Summary включает в себя credit_account_id и максимальную сумму операций за день для этого credit_account_id. Каждый credit_account_id мог иметь несколько операций за день. То есть нужно было вернуть мапу, в которой хранились максимальные суммы операций на каждый день в разрезе аккаунтов.

Я сначала немного неправильно понял задачу. Притом я еще вначале объяснил свое понимание, чтобы начать решать правильно. И интервьюер подтвердил мое понимание. А потом оказалось, что оно неверное. Поэтому не успел дописать до конца код во второй раз.
Посмотрим, что скажут.

Сразу после этого было второе собеседование, где дали решать два алгоритма. Один был не сложный, а второй я когда-то решал на литкоде. О них напишу отдельно.

Могу сказать, что собеседование мне очень понравилось. Если я не знал как что-то написать на питоне, мне с радостью подсказывали. Сразу подчеркнули, что у них нет задачи проверять знания питона, и я не первый сотрудник, не работавший с ним. Понравилось, что задача была приближена к рабочей. Еще бы можно было гуглить (а такое собеседование я тоже проходил) или пользоваться Github copilot - было бы вообще шикарно :)