Комментарии 54
Интересно, как вообще должно выглядеть резюме, чтобы взяли в бигтех? Я пока из таких фирм на собесе был только в Яндексе.
Да как обычно. Желательно 1 страничка, тупо опыт, описание пары самых больших задач + достижения. Везде суй цифры + технологии релевантные, например для го это что-то про микросервисы, Kafka, PostgreSQL, gRPC и тд по списку. В канале в комментах к последнему посту парню резюме прожарили, можешь посмотреть, если интересно)
Везде суй цифры
Все хотят цифры аля "фича X дала прирост Y в количестве Z", вот только откуда эти цифры взять? Разраб делает фичи, а не проводит исследования "насколько фича повлияла на проект". Его это вообще не должно касаться, это должно волновать ПМа
Если ты не можешь даже оценить как твой код повлиял на техдолг, производительность, и делал только что сказали только в том объёме как сказали -- в бигтехе тебе не понравится, так что все хорошо и система работает.
Если ты приходил хоть раз с предложением переехать на новый стек (чтоб пилить фичи в джва рваза бвыстрее) или сделать рефакторинг (чтоб перестать копипастить уже наконец) или пофиксить тесты (которые только падают на них все забили) -- то ты знаешь, что приходить надо с каким-то исследованием, как твоё предложение повляет на проект -- и ты понимаешь о чем речь.
приходить надо с каким-то исследованием, как твоё предложение повляет на проект -- и ты понимаешь о чем речь.
Любой специалист понимает, что в масштабных проектах невозможно точно оценить индивидуальный вклад. Даже если вы предложили идею на миллион долларов это не значит, что этот миллион был заработан лишь благодаря вам. Ни какая работа не делается в одну каску - как минимум ее кто-то должен захотеть, апрувнуть, продать, выделить бюджет и т.п. Результат здесь всегда является следствием синергетического эффекта от работы разных сотрудников на различных уровнях. Поэтому все эти проценты в резюме инженеров по сути должны вызывать либо умиление как детская наивность, либо отвращение как откровенная ложь.
Любой специалист понимает, что в масштабных проектах невозможно точно оценить индивидуальный вклад.
Если есть желание гарантированно измерять индивидуальный вклад, заходите в инфраструктурные команды. Там каждый персональный чих может снизить потреблние цпу, время ответов и прочие метрики так, что прямо на графиках виден этот чих.
А дальше можно в лидов кидаться статьёй от амазона, и если чих напрямую не конвертируется в рубли, то хотя бы обретает неизмеримый, но в то же время существенный вес.
Как только метрика становится целью, она перестаёт быть хорошей метрикой. Ну а если она к тому же попадает в пресс-релизы, то написанному разумеется нужно сразу верить.
То что Амазон в одном месте пишет про миллисекунды, ни сколько не мешает им в других предлагать неоптимальные решения и динамить проблемы годами. Может это тоже как-то влияет на их бизнес: "вот мы ничего не исправляли, периодически делая только хуже и на этом зарабатывали кучу денег" - я бы хотел увидеть такие откровения в чьём-нибудь резюме. Если что у работодателя энтерпрайзная подписка на AWS и премиальный саппорт, с которым мне приходится общаться время от времени.
Вы не обязаны кидаться долларами. Я как-то снизил потребление одной функции сру на 15%. Это никак не повлияло на загрузку системы.
Но по метрике "обработано данных" я могу сказать, что это дало 3% буст к общей продуктивности системы.
В доллары это пересчитывать не нужно, так как доллары сиеминутны, а прогресс неумолим :)
Ранвно как и экономия пары петабайт может быть солидно в попугаях, но в процентах тысячные доли...
В чем принципиальная разница между добавлением фич с исправлением багов, которыми инженер занимается изо дня в день в рамках своих задач, и такой вот работой?
Сеньёрностью. Если делаешь что просят когда просят и в объёме как попросили -- ты отличный исполнитель и на пятки наступают сетки.
Если ты понимаешь зачем оно, как оно надо -- ты в среднем меньше создаёшь багов при запиливании фич, в среднем поддерживаешь техдолг уровнем ниже, и требуешь меньше ресурсов на надзор-постановку задачи-итп.
Разумеется, это не так (не всегда так, не для всех так и вообще слишком упрощённая модель); но при любом найме всегда надо как-то упростить требования: так, чтоб можно было проверить.
Если ты не можешь даже оценить как твой код повлиял на техдолг, производительность, и делал только что сказали только в том объёме как сказали -- в бигтехе тебе не понравится, так что все хорошо и система работает.
- Сделал фичу F1
- Молодец, теперь делай фичу F2
- Эээ, нет, я ещё не закончил тестирование вклада фичи F1 в производительность проекта
- ???
Вы думаете разрабу кто-то будет давать проводить такие тесты делать? Нет. Почему? Потому что эти тесты не приносят денег. Если фича на рефакторинг была запланирована, то ускорение кодовой базы/улучшение качества кода очевидно. Будете ли вы каждый раз проводить такое тестирование после каждой такой фичи?
Пм говорит "чёт как-то надо поработать над техдолгом и кодовой базой", заводит спринт рефакторинга, совершается работа, а затем по результатам спринта собирает метрики насколько стало лучше
Вы только что описали процессы не совместимые с жизнью в тех самых бигтехах, которые живут цифрами. "Сделал фичу F1"... У нас была в команде ходовая шутка про "is it done done or just done?". Да, ты пилишь фичу. Да, ты измеряешь результат. Да, ты учитываешь время на то, что в какой-то момент пойдёшь и сделашь речёрч на тему импакта своих действий -- в конце концов, те же цифры тебе в свой перф вносить. Бонус хочешь? :)
... последний мой коммит в гугле закоммитился 2 года после моего ухода. Потому что Done != Done Done :) И я не только код правил и подготовил изменения на очистку от старья и в документацию, с условным коммитом на уход первой версии из продакшена за горизонт поддержки.
У меня в бинго-карточке всратых резюме разрабов одна из ячеек как раз так звучит: "Сделал X, что дало +Y% к метрике Z".
Я такие вещи читаю как "Работал работу, но ничего примечательного. Признаться в этом почему-то стыдно или страшно, поэтому пришлось рисовать рандомные цифры, чтобы совсем пусто не выглядело".
Но я не в бигтехе, может быть, для них это действительно важно
так не нужно давать в резюме. "фича X дала прирост Y в количестве Z ". данная фича вам сыграет, когда вы либо напрямую с CEO сидите на интервью, либо твоя задача Продать проект, а не себя, с перспективой.
Оценка деятельности прошлой работы в своём резюме, как по мне (я был и интревьером) - это лишь "загрязнение" резюме. Потому что в 90% случая резюме смотрят HR и такие же разрабы интервьеры. Они прекрасно осведомлены, что цифры "взяты с потолка"
В российских бигтехах требуются сотрудники очень разных уровней скиллов. Даже формошлёпы. И даже много. Так что не считаю, что им нужно какое-то особое резюме.
И не скажу за всех, но на сеньорских бекендерских должностях ещё очень полезны строчки резюме про то, каких масштабов проекты вы проектировали (сколько данных, сколько юзеров, на каком железе, сколько человек работали над ними), либо какие фичи вы оптимизировали по железу/пингам и т.п., и во сколько рублей эта экономия вылилась.
Да особое резюме как будто бы и не нужно. У меня было дефолтное резюме в несколько строк типа: был такой-то проект на таком-то стеке, делал то-то и то-то. Никаких достижений, цифр и тд. Были приглашения от Сбера, Яндекса, Касперского
Почему пустая структура в Go занимает 0 байт (https://t.me/siliconchannel/64).
Между прочим, ответа на вопрос "почему" по этой ссылке не написано.
Стандарт Си гарантирует, что любые два разных объекта будут иметь разные адреса. Поэтому даже malloc(0) обязан зарезервировать хоть сколько-то байтов памяти.
Зачем это сделано в стандарте, это отдельный вопрос, но оно там есть.
В спецификации же Go таких гарантий нет. Поэтому компилятор вправе "выделять" под struct{} ноль байт и "наслаивать" такие структуры друг на друга.
Так что на вопрос "почему" тут следует ответить, "потому, что может". А может потому, что разработчики Go учли многие ошибки, случившиеся при разработке Си.
Что-то вы путаете. Malloc(0) может вернуть даже NULL.
Или указатель куда-то куда попало.
Если честно, у меня сложилось ощущение, что вы написали что-то не совсем связное, лишь бы поумничать в комментах, получилось не впопад) Пустая структура зачастую весит 0 и в посте расписано как это реализовано. Когда на собесах говорят, что пустая структура весит 0, под капотом подразумевают этот механизм.
Вот смотрите, как работает Си:
#include <stdio.h>
int main() {
struct {} s1;
struct {} s2;
printf("%d, %p\n", (int) sizeof(s1), &s1);
printf("%d, %p\n", (int) sizeof(s2), &s2);
return 0;
}
Печатает:
0, 0x7ffdb4eb4f0e
0, 0x7ffdb4eb4f0f
Обратите внимания, структуры пустые, размер нулевой, а адреса разные. Это то, что гарантирует Си, что у двух разных объектов разные адреса. И он не может никак по-другому это гарантировать, кроме как выделяя под пустую структуру хотя бы один байт адресного пространства.
Теперь аналогичная совершенно программа на Go:
package main
import "unsafe"
func main() {
var s1 struct{}
var s2 struct{}
println(unsafe.Sizeof(s1), &s1)
println(unsafe.Sizeof(s2), &s2)
}
Печатает:
0 0xc000076740
0 0xc000076740
Размер нулевой и адреса одинаковые. Потому что Go не связан сишными гарантиями выдавать разные адреса под разные объекты, поэтому может не выделять под них память, а вернуть "какой-то" условно-валидный указатель.
sizeof(пустая структура) зачастую возвращает 1, а не ноль: https://godbolt.org/z/GnPanhEra
Какой компилятор распечатал?
gcc
А, в режиме Си а не Си++: https://godbolt.org/z/zW39senfe -- sizeof 0 у clang и gcc, а msvc отказывается компилировать.
При этом у gcc -- ОДИНАКОВЫЙ адрес:
Program returned: 0
0, 0x7fffffe539c0
0, 0x7fffffe539c0
Потому что в C пустые структуры на самом деле запрещены. What is the size of an empty struct in C?. Компиляция с опцией -pedantic выдаёт в gcc: warning: struct has no members, а в clang: warning: empty struct is a GNU extension.
Да, я не знал этого нюанса, что malloc(0) может вернуть что угодно. Просто в нормальной программе я б не рискнул позвать malloc с нулевым аргументом, поэтому что там стандарт про это пишет, в голове не держу.
Однако обратите внимание (см ниже), если заводить пустые структуры на стеке, они получают разные адреса.
Кстати, если сделать их static, адреса получатся одинаковыми. Но мне лень уж так далеко копать, чтобы выяснить, ошибка это gcc или в стандарте есть исключение.
Не сказал бы что просмотр решений мешает двигаться в решении алго-задач. Иногда бывают такие задачи до решения которых голова вообще не дойдет, и эти решения глаза открывают)
интересно, а как подходит уровень про к SVG/XML = XSVGML ) без Skia/Cairo/Boost или уже все всё создали ) что я сейчас вижу частично это комплекс литкодовских задачек ) + подсветил тему интересующимся где можно применить знания )
Совсем недавно на собеседовании по алгоритмам в бигтех я потратил почти всё время, решая не ту задачу, которая была поставлена. Причём сделал это 2 раза. То есть, когда первый раз выяснилось, что я не так понял задачу, я перечитал и опять её не так понял, и стал решать опять не ту. А на третью попытку уже не хватило времени. Так что читайте очень внимательно, переспрашивайте много, пишите тут же, до начала решения, тесты/примеры, которые подтверждают, что вы правильно поняли задачу, и так далее. Кстати, в моем случае два примера в задаче специально были выбраны так, чтобы тестируемый мог понять задачу неверно.
Звучит довольно просто на самом деле. Главное не нужна математика. Ну в том виде в котором она нужна в мл например имею в виду
А у вас есть Telegram-канал? Дайте ссылку.
Ох, я уже боялся не спросите. Держите конечно https://t.me/siliconchannel !
Я постил на Хабре аналогичную статью в 2023 году. Там тоже было и про Go, и про те же компании. Похоже пока ничего особо не изменилось ))
Позволю себе оставить здесь цитату из одной популярной статьи на хабре
Тут что-то написано про leetcode, но я человек ответственный, поэтому к интервью не готовлюсь. Это кстати я не шуткую, реально: если вы ответственный человек, то вы, когда предстаёте перед компанией, отвечаете за то, что вы заявляете как ваши умения. Можно выучить типовые вопросы и даже казаться умнее и опытнее, чем есть, но по факту это переобучение на тестовых заданиях/вопросах. Ребята из ml поймут. Поэтому я гол как сокол и чист как стёклышко или что там ещё блин, если что-то знаю - скажу, что-то не знаю - скажу что не знаю. Таким образом работодатель знает, что он покупает и сколько ещё нужно вложить в меня средств на обучение. Все счастливы.
много умных ребят готовясь к собесам не имеют четкой системы подготовки, и из-за этого заваливают технические собесы в компании
Вы, насколько я понял, тоже не имеете чёткой системы подготовки кроме представления какие есть этапы на собеседовании и что там спрашивают
Умный в гору не пойдёт — умный гору обойдёт!
Дополнил бы про подход к решению задач и вообще подготовку этим роликом, да, очень долгий, если что суть по таймкоду в ссылке. Помогает понять, что в большинстве проблем и сомнений разработки и подготовки ты не один и есть решение, либо взгляд-принятие, с которым проблема уже не является проблемой
Самое интересное, что ты сделал практически всё, что нужно CV, Leetcode, алгосы и т.п и такой в конце: "Поздравляю ты получил базовый набор". Базовый?! Да мне, кажется, я уже профессиональный набор должен был получить, несколько медалей и заслуженный выход на пенсию 🤣🤣😂
Про Leetcode есть нюансы, в статье переплетается тёплое и мягкое (отсутствие подхода к задаче и паттерны), при этом тёплое подводка к мягкому мол так не надо. Поясню в цитатах:
Тут большинство просто открывают литкод и начинают решать алгоритмы: решают задачу, если не получается — смотрят решение и идут дальше. В теории это работает супер, только вот на практике для большинства это выглядит как просто постоянная копипаста решения задачек, и никакого прогресса в самостоятельном решении нет.
Это больше говорит про отсутствие систематического подхода, отдельно взятая задача прорабатывается плохо, копипаста решения, общий результат плох, да, но паттерны здесь ни при чём, это отдельный аспект. Про подход здесь, в статье об этом нет.
+ Мне нравятся разборы разных паттернов от Влада Тена, можете для начала просмотреть плейлист с его разборами и решить задачи из видео.
Это расходится с цитатой выше. Сам попадался в эту ловушку. Можно посмотреть для старта, для мотивации, но чем больше опоры на разборы, тем проще забить, сдаться, подсмотреть решение и не наработать навык решения проблем. По сути это провоцирует проблемы из первой цитаты, а наибольшая самостоятельность в решении, отказ от разборов выглядит как лучший путь, но дальше в статье речь о паттернах, а не о подходе, это большое упущение.
Очевидно, необходим подход, привычка и ограничение времени на решение, но без копипасты готовых решений. Берём решение, выносим суть, сами пишем реализацию. Это может дать рост, копипаста нет.
Из разборов Влада Тен стоит вынести эти мысли и ссылку на Leetcode Patterns для самостоятельной практики, это удобнее, чем фильтровать по тегам из графа автора, который очень уж похож на популярный с Neetcode, тоже хороший листинг основных задач LC для практики с базовыми решениями на большинстве популярных языков и видеоразбором.
Сам Влад Тен иронично высказывался о своих разборах в них же. Если правильно помню суть тейков: самостоятельное решение в разы лучше. Хорошо, если это популяризирует решение литкода, но идти по разборам не самый лучший путь, просмотр без практики бесполезен и отдаляет от практики.
В бигтех не так сложно собеседоваться "технически", как пробиться через "мэтч с ожиданиями HR" - хотя бы до уровня "мы Вам перезвоним".
Поработал в Али и Озон.
Ты решаешь LeetCode неправильно. Как пройти любое собеседование в BigTech?