Это последняя глава рассказа про моё неудачное собеседование в стартап из Долины. Раскрываю все карты — что пошло не так и какие выводы я сделал. Если вы не читали прошлые посты, посмотрите сначала их, чтобы понимать, о чём речь.

первая серия
вторая серия
третья серия
четвёртая серия
пятая серия

Итак, меня позвали на встречу, чтобы обсудить тестовое задание. Два разработчика из стартапа, я и час на общение. Мы сразу начали говорить о том, как я получил такие результаты.

Напомню, что в решении я столкнулся со странностью: несмотря на то, что на моём компьютере было 12 ядер, максимальная производительность кода достигалась при 256 потоках. Получив такой результат, я решил довериться своему бенчмарку и не углубляться в то, почему так происходит.

Мы говорили об этом моменте долго и разобрались, почему так получается. Дело в том, что в задании было сказано: «скорее всего, ваша однопоточная версия будет работать быстрее любой многопоточной, поэтому, чтобы приблизить задачу к реальности, добавьте произвольную задержку в код, который считает сумму в ячейках таблицы». Так и получилось. Я увидел, что однопоточная версия действительно работает быстрее и, как советовали в задании, добавил задержку. Сделал я это интуитивно: я усыплял текущий тред на какое-то количество микросекунд, как-то даже не задумываясь, можно ли это сделать по-другому (здесь можно посмотреть код).

Получается, что тред переставал занимать ядро: больше не участвовал в планировщике и не занимал процессор. Большинство моих тредов считали сумму ячеек, и много времени уходило на то, чтобы спать. То есть большую часть времени мой многопоточный код ждал, когда проснётся хотя бы один из тредов, а когда этот тред просыпался, занимал свободное ядро и обсчитывался.

У меня, конечно, получилась многопоточная программа, однако работала она не параллельно. Фактически вышло, что я замерил не скорость работы своей программы, а скорость работы планироващика операционной системы.

На обсуждение этой темы ушёл почти весь час. Я попрощался с командой, а потом в тот же день получил отказ. Он оказался для меня очень болезненным, и я переживал из-за этого несколько дней. Всё-таки я вложил в задание много сил, и мне казалось, что у меня получилась классная работа. Я немного попереписывался с разработчиками, которые меня собеседовали, чтобы лучше понять причины отказа. В итоге из этой истории я сделал два вывода:

1. Главная ошибка — то, что я не разобрался, почему максимум достигается на 256 потоках. То есть получив странные результаты, я с ними согласился. Конечно, можно было бы сказать — всегда разбирайтесь со всеми странностями! Но мы знаем, что когда работаешь в условиях ограниченного количества времени, это не всегда возможно. Так что просто старайтесь понимать, что происходит в вашей работе, хотя бы глобально.

2. Отказ вызвал у меня сильную эмоциональную реакцию, а это значит, что история мне запомнилась, отложилась в голове. Это значит, что в следующий раз я уделю похожему кейсу ещё больше внимания. Вывод: любой отказ — это здорово, потому что он нас чему-то учит. И готовит к будущим победам.