В продолжении темы резюме
Слышу много жалоб на то, что резюме постоянно реджектят.
Частично, это связано с общим состоянием рынка. Сейчас рынок труда уже не тот, что был в 2021.
Но по сравнению с состоянием рынка в 2023 сейчас сильно лучше.
В Линкедине часто вижу, как кто-то постит резюме. Там не вооруженным глазом видны слабости резюме. Я уже о них писал ранее. Это и моменты связанные с оформлением (плохо парсится, длинное, много лишней информации, сайдбары, фотографии, вордарты). Но, основное, это конечно, содержание.
90+% процентов упорно продолжают писать должностные обязанности (писал код, ревьюил код, диплоил код), вместо решенных задач и достижений. Ну офигеть, а мы то думали, что программисты компьютеры чинят.
Иногда, пытаются писать достижения, но достижение заключается в том, что человек использовал какую технологию. Иногда еще пытаются подогнать это под требуемый стек в вакансии.
Достижение, вроде, написал код на Spring Boot, или использовал git и задеплоил при помощи docker - это не достижение. Это перечисление тех стека. Название технологий можно вплетать в текст, но это не самоцель. Нужно писать какую бизнес задачу вы решили. К какому результату это привело. Почему это было сложно. Что именно сделали вы (вот тут можно вплетать название технологий).
На другом конце спектра достижения, которые концентрируются только на решенной бизнес задаче. Без указания собственной роли, технической сложности и технического метода решения.
Вроде, увеличил продажи на 10%. Тут не понятно, как именно. В чем была техническая сложность задачи. Какая была во всем этом ваша роль.
Изучайте метод STAR, набросайте основные положения и если не можете сами это красиво сформулировать, скормите входные данные ChatGPT. Он как раз хорошо с текстами работает.
Халтурить в тексте резюме можно, если у вас есть в резюме топ вузы или топ компании. Это перевесит большинство недостатков. Но если у вас этого нет, то потратьте время на написание хороших, понятных и измеримых достижений.
Слышу много жалоб на то, что резюме постоянно реджектят.
Частично, это связано с общим состоянием рынка. Сейчас рынок труда уже не тот, что был в 2021.
Но по сравнению с состоянием рынка в 2023 сейчас сильно лучше.
В Линкедине часто вижу, как кто-то постит резюме. Там не вооруженным глазом видны слабости резюме. Я уже о них писал ранее. Это и моменты связанные с оформлением (плохо парсится, длинное, много лишней информации, сайдбары, фотографии, вордарты). Но, основное, это конечно, содержание.
90+% процентов упорно продолжают писать должностные обязанности (писал код, ревьюил код, диплоил код), вместо решенных задач и достижений. Ну офигеть, а мы то думали, что программисты компьютеры чинят.
Иногда, пытаются писать достижения, но достижение заключается в том, что человек использовал какую технологию. Иногда еще пытаются подогнать это под требуемый стек в вакансии.
Достижение, вроде, написал код на Spring Boot, или использовал git и задеплоил при помощи docker - это не достижение. Это перечисление тех стека. Название технологий можно вплетать в текст, но это не самоцель. Нужно писать какую бизнес задачу вы решили. К какому результату это привело. Почему это было сложно. Что именно сделали вы (вот тут можно вплетать название технологий).
На другом конце спектра достижения, которые концентрируются только на решенной бизнес задаче. Без указания собственной роли, технической сложности и технического метода решения.
Вроде, увеличил продажи на 10%. Тут не понятно, как именно. В чем была техническая сложность задачи. Какая была во всем этом ваша роль.
Изучайте метод STAR, набросайте основные положения и если не можете сами это красиво сформулировать, скормите входные данные ChatGPT. Он как раз хорошо с текстами работает.
Халтурить в тексте резюме можно, если у вас есть в резюме топ вузы или топ компании. Это перевесит большинство недостатков. Но если у вас этого нет, то потратьте время на написание хороших, понятных и измеримых достижений.
👍17🔥5
Неоднозначность в тайтлах выше Senior
Недавно собеседовал кандидата из Microsoft. Его текущий тайтл это Principal Software Engineer в Microsoft. Собеседовали его на позицию E6/L6/Staff Software Engineer. Он завалил кодинг, а на систем дизайнах и поведенческом его опредили как соответствующего E5/L5/Senior. Т.е. проекты и задачи, над которыми он работает не соответствуют уровню Staff Software Engineer.
Это все, потому что нет универсальной шкалы для уровней. В Microsoft после Senior сразу идет Principal. Что во многих компаниях соответствует Staff или TL(Tech Lead). Поэтому Principal Principal'у рознь. В некоторых компаниях это тех лид команды из 8 человек, а в некоторых это разработчик который оперирует на уровне организации в 200-300 человек и репортит VP компании.
Недавно собеседовал кандидата из Microsoft. Его текущий тайтл это Principal Software Engineer в Microsoft. Собеседовали его на позицию E6/L6/Staff Software Engineer. Он завалил кодинг, а на систем дизайнах и поведенческом его опредили как соответствующего E5/L5/Senior. Т.е. проекты и задачи, над которыми он работает не соответствуют уровню Staff Software Engineer.
Это все, потому что нет универсальной шкалы для уровней. В Microsoft после Senior сразу идет Principal. Что во многих компаниях соответствует Staff или TL(Tech Lead). Поэтому Principal Principal'у рознь. В некоторых компаниях это тех лид команды из 8 человек, а в некоторых это разработчик который оперирует на уровне организации в 200-300 человек и репортит VP компании.
👍17
Разбор резюме подписчика
Подписчик прислал резюме. Я, кратко, посмотрел. Мысли набросал тут: https://dev.to/faangmaster/razbor-rieziumie-podpischika-2acf
Резюме хорошее. Есть несколько замечаний по отсутствию summary, сильно большой секции Education для опытного программиста, порядку разделов в резюме. В резюме описано много достижений. Но во многих не хватает описание роли владельца резюме (или хорошо бы ее расширить для показаная синьерности), импакта задачи, зачем это было нужно. Для роли Middle можно ограничиться Implemented, Created или Developed, в качестве роли. Если есть достижения, где вы играли большую роль, то лучше это написать, это нужно для ролей Senior+. Led/Drove/Identified/Came up with an initiative/idea/ in a collaboration with...
Я часто задаю вопрос, зачем, к достижениям, потому что не ясен импакт. Вот вы что-то implemented, но не ясны бенефиты от этого. Добавьте, например, resulted in reduction/improvement/increase .... by x%.
Но это уже лучше, чем I was responsible for coding, code review and deployment. Достижения описаны, местами не хватает одного или пары пунктов из STAR, или если можно расширить свою роль для более синьерных позиций, а не только implemented/created.
Подписчик прислал резюме. Я, кратко, посмотрел. Мысли набросал тут: https://dev.to/faangmaster/razbor-rieziumie-podpischika-2acf
Резюме хорошее. Есть несколько замечаний по отсутствию summary, сильно большой секции Education для опытного программиста, порядку разделов в резюме. В резюме описано много достижений. Но во многих не хватает описание роли владельца резюме (или хорошо бы ее расширить для показаная синьерности), импакта задачи, зачем это было нужно. Для роли Middle можно ограничиться Implemented, Created или Developed, в качестве роли. Если есть достижения, где вы играли большую роль, то лучше это написать, это нужно для ролей Senior+. Led/Drove/Identified/Came up with an initiative/idea/ in a collaboration with...
Я часто задаю вопрос, зачем, к достижениям, потому что не ясен импакт. Вот вы что-то implemented, но не ясны бенефиты от этого. Добавьте, например, resulted in reduction/improvement/increase .... by x%.
Но это уже лучше, чем I was responsible for coding, code review and deployment. Достижения описаны, местами не хватает одного или пары пунктов из STAR, или если можно расширить свою роль для более синьерных позиций, а не только implemented/created.
👍17🔥3❤2👏1
Conflict Resolution
На поведенческом собеседовании в FAANG компании очень часто можно встретить вопросы вроде:
1) Tell me about a time you had a conflict with your manager.
2) Tell me about a time you had a conflict at work.
3) Tell me about a time you had a disagreement with someone.
Такие вопросы часто спрашивают в Facebook (Meta) для оценки Conflict Resolution, а также в Amazon при оценке Amazon Leadership Principle - Have Backbone; Disagree and Commit.
Junior-Senior кандидаты из СНГ, да и Staff тоже, очень частно заваливаются на этом вопросе. Это, очень часто, служит причиной получения офера на более низкий уровень или реджекта.
Казалось бы, какой-то бессмысленный HR-вопрос. Но поработав в FAANG более 7 лет я понял, что этот навык супер важный. Не только на собеседовании, а в ежедневной работе. Особенно, с ростом вашего левела.
Кандидаты из СНГ очень часто получают Red Flags и получают reject или down level.
Типичные Red Flags:
1) У меня никогда не было конфликтов. Это просто вранье. Конфликты на работе программиста встречаются почти каждый день. Это не конфликты по типу гопстопа или ты меня уважаешь, а конфликты по вопросам связанным с вашей работой. Это несогласия по время code review, design review, разные мнения и подходы у разных людей к той или иной проблеме. Разные мнения по поводу приоритета той или иной задачи, проекта и т.д. Конфликты возникают как между коллегами в рамках одной команды, так и разногласия между командами, отделами или даже внешними компаниями-партнерами или клиентами. Если у вас не было конфликтов - вы никогда не работали программистом. Или же вы всегда решали их двумя плохими способами: избеганием или продавливанием своего мнения.
2) У меня был конфликт X, и в итоге он решился тем, что я доказал, что я прав, а все другие не правы. Даже если такие случаи были, то это плохой пример. Вы должны обосновывать свою позицию, но должны слышать и другую сторону, а не силой пытаться ее продавить. Если у вас только такие примеры, то скорее всего большинство таких примеров, когда вторая сторона просто забила и прогнулась, для нее это не было приоритетом или у вас было больше власти, сил и желания это продавить. И скорее всего, в итоге часть таких решений были неоптимальными.
3) У меня был конфликт X, в итоге я, просто, проигнорировал и избежал конфронтации и все как-то само решилось. Конфликт на работе это не обязательно что-то плохое. Игнорирование конфликта на работе приводит к накоплению противоречий между сторонами, ухудшению collaboration, а как следствие к ухудшению эффективности организации. При правильном подходе можно найти лучшее решение, чем форсила каждая из сторон конфликта. В таком случае выигрывают все - win-win Conflict Resolution.
4) Вы не использовали данные, в конфликтах. Иногда причина конфликта - это нехватка данных и неверные предположения сторон. В таких случаях можно отложить resolution конфликта, сделать сбор данных и собраться снова и найти win-win resolution.
Не критические, но отрицательные сигналы:
1) У нас был конфликт X, и мы нашли компромисс. Это скорее всего означает, что каждая из сторон немного прогнулась, и осталась немного недовольной. Каждая из сторон просто пошла на уступки, не пытаясь найти какое-то новое, более лучшее решение, которое бы удовлетворила все валидные требования и приоритеты каждой из сторон. Обычно, это от лени и безразличия или свойства психики по избежанию конфликтов. Часто это приводит к неоптимальными решениям.
2) У нас был конфликт X, я полностью признал, что я не прав и сделал так, как сказали, не протестуя. Такое бывает, но это не оптимальный пример для собеседования. Если вы попытались возразить и уже в обсуждение поняли, что были не правы - то это хорошее поведение. Но не лучший пример для собеседования. Лучше подойдут примеры win-win. А если вы не пытались возразить, то скорее всего в итоге было получено неоптимальное решение.
На поведенческом собеседовании в FAANG компании очень часто можно встретить вопросы вроде:
1) Tell me about a time you had a conflict with your manager.
2) Tell me about a time you had a conflict at work.
3) Tell me about a time you had a disagreement with someone.
Такие вопросы часто спрашивают в Facebook (Meta) для оценки Conflict Resolution, а также в Amazon при оценке Amazon Leadership Principle - Have Backbone; Disagree and Commit.
Junior-Senior кандидаты из СНГ, да и Staff тоже, очень частно заваливаются на этом вопросе. Это, очень часто, служит причиной получения офера на более низкий уровень или реджекта.
Казалось бы, какой-то бессмысленный HR-вопрос. Но поработав в FAANG более 7 лет я понял, что этот навык супер важный. Не только на собеседовании, а в ежедневной работе. Особенно, с ростом вашего левела.
Кандидаты из СНГ очень часто получают Red Flags и получают reject или down level.
Типичные Red Flags:
1) У меня никогда не было конфликтов. Это просто вранье. Конфликты на работе программиста встречаются почти каждый день. Это не конфликты по типу гопстопа или ты меня уважаешь, а конфликты по вопросам связанным с вашей работой. Это несогласия по время code review, design review, разные мнения и подходы у разных людей к той или иной проблеме. Разные мнения по поводу приоритета той или иной задачи, проекта и т.д. Конфликты возникают как между коллегами в рамках одной команды, так и разногласия между командами, отделами или даже внешними компаниями-партнерами или клиентами. Если у вас не было конфликтов - вы никогда не работали программистом. Или же вы всегда решали их двумя плохими способами: избеганием или продавливанием своего мнения.
2) У меня был конфликт X, и в итоге он решился тем, что я доказал, что я прав, а все другие не правы. Даже если такие случаи были, то это плохой пример. Вы должны обосновывать свою позицию, но должны слышать и другую сторону, а не силой пытаться ее продавить. Если у вас только такие примеры, то скорее всего большинство таких примеров, когда вторая сторона просто забила и прогнулась, для нее это не было приоритетом или у вас было больше власти, сил и желания это продавить. И скорее всего, в итоге часть таких решений были неоптимальными.
3) У меня был конфликт X, в итоге я, просто, проигнорировал и избежал конфронтации и все как-то само решилось. Конфликт на работе это не обязательно что-то плохое. Игнорирование конфликта на работе приводит к накоплению противоречий между сторонами, ухудшению collaboration, а как следствие к ухудшению эффективности организации. При правильном подходе можно найти лучшее решение, чем форсила каждая из сторон конфликта. В таком случае выигрывают все - win-win Conflict Resolution.
4) Вы не использовали данные, в конфликтах. Иногда причина конфликта - это нехватка данных и неверные предположения сторон. В таких случаях можно отложить resolution конфликта, сделать сбор данных и собраться снова и найти win-win resolution.
Не критические, но отрицательные сигналы:
1) У нас был конфликт X, и мы нашли компромисс. Это скорее всего означает, что каждая из сторон немного прогнулась, и осталась немного недовольной. Каждая из сторон просто пошла на уступки, не пытаясь найти какое-то новое, более лучшее решение, которое бы удовлетворила все валидные требования и приоритеты каждой из сторон. Обычно, это от лени и безразличия или свойства психики по избежанию конфликтов. Часто это приводит к неоптимальными решениям.
2) У нас был конфликт X, я полностью признал, что я не прав и сделал так, как сказали, не протестуя. Такое бывает, но это не оптимальный пример для собеседования. Если вы попытались возразить и уже в обсуждение поняли, что были не правы - то это хорошее поведение. Но не лучший пример для собеседования. Лучше подойдут примеры win-win. А если вы не пытались возразить, то скорее всего в итоге было получено неоптимальное решение.
👍20🔥5
В реальной работе конфликты практически постоянно. Чем выше ваш левел, тем больше и серьезней такие конфликты. Они могут быть между целыми отделами с очень разными интересами и приоритетами. В идеале нужно стараться достичь win-win решения.
Как это можно сделать?
1) Не отрицать конфликт, признать что он есть, обозначить вовлеченные стороны и позиции.
2) Собраться, выслушать другую сторону. Выслушать нужно очень внимательно. Если вовлечены эмоции, то признать право человека на эмоции и попытаться их понять. Проявить эмпатию.
3) Попытаться поставить себя на место другой стороны, чтобы более четко понимать позицию и эмоции другой стороны.
4) Активно слушать, стараться понять в деталях позицию, приоритеты стороны и причины такой позиции.
5) Спросить, как вы видите решение проблемы?
6) Донести свою позицию и ее причины.
7) Будьте открытыми для альтернативных точек зрения, признания, что можете чего-то не знать или заблуждаться. Но нельзя соглашаться на все, просто, чтобы избежать конфликта. Концентрируйтесь на том, чтобы найти правильное и лучшее решение, чем было у каждой из сторон на момент начала конфликта.
8) Установите common ground и общие цели. Обычно, вы можете установить что-то общее. Очень часто у вас будет много общих целей и задач. В конечном счете, вы хотите решить одну и туже проблему, просто разными способами.
9) Если после обсуждения вы можете устранить сразу какие-то неверные предпосылки и решения, которые не были понятны до обсуждения, то сделайте это (например, вы чего-то не знали и узнали во время обсуждения или знали неверно, и теперь вы можете изменить свою точку зрения). Это сократит число concerns и противоречий между сторонами
10) Если для решения оставшихся разногласий нужно больше данных - сделайте паузу на сбор и анализ данных
11) найдите новое, альтернативное решение, которое удовлетворит оставшиеся концерны обоих сторон (win-win).
12) Опишите и задокументируйте достигнутое решение. В будущем вы можете на него ссылаться.
Вообще, это большая тема. Можете начать ее изучать с википедии: Conflict resolution
Как это можно сделать?
1) Не отрицать конфликт, признать что он есть, обозначить вовлеченные стороны и позиции.
2) Собраться, выслушать другую сторону. Выслушать нужно очень внимательно. Если вовлечены эмоции, то признать право человека на эмоции и попытаться их понять. Проявить эмпатию.
3) Попытаться поставить себя на место другой стороны, чтобы более четко понимать позицию и эмоции другой стороны.
4) Активно слушать, стараться понять в деталях позицию, приоритеты стороны и причины такой позиции.
5) Спросить, как вы видите решение проблемы?
6) Донести свою позицию и ее причины.
7) Будьте открытыми для альтернативных точек зрения, признания, что можете чего-то не знать или заблуждаться. Но нельзя соглашаться на все, просто, чтобы избежать конфликта. Концентрируйтесь на том, чтобы найти правильное и лучшее решение, чем было у каждой из сторон на момент начала конфликта.
8) Установите common ground и общие цели. Обычно, вы можете установить что-то общее. Очень часто у вас будет много общих целей и задач. В конечном счете, вы хотите решить одну и туже проблему, просто разными способами.
9) Если после обсуждения вы можете устранить сразу какие-то неверные предпосылки и решения, которые не были понятны до обсуждения, то сделайте это (например, вы чего-то не знали и узнали во время обсуждения или знали неверно, и теперь вы можете изменить свою точку зрения). Это сократит число concerns и противоречий между сторонами
10) Если для решения оставшихся разногласий нужно больше данных - сделайте паузу на сбор и анализ данных
11) найдите новое, альтернативное решение, которое удовлетворит оставшиеся концерны обоих сторон (win-win).
12) Опишите и задокументируйте достигнутое решение. В будущем вы можете на него ссылаться.
Вообще, это большая тема. Можете начать ее изучать с википедии: Conflict resolution
YouTube
"Have Backbone; Disagree and Commit" Leadership Principle Explained by Amazon CEO Andy Jassy
CEO Andy Jassy explains how to apply the Leadership Principle “Have Backbone; Disagree and Commit” at Amazon.
👍14🔥1👏1
Паша Техник прошел бы собес на Senior Staff
https://youtube.com/shorts/WR0Uh3-AVNA?si=-PFjaXjtB6lAt4q8
https://youtube.com/shorts/WR0Uh3-AVNA?si=-PFjaXjtB6lAt4q8
YouTube
Паша Техник — Давайте думать, подсказывайте
Паша Техник — Давайте думать, подсказывайте, чё вы мозги ебёте.#ПашаТехник #ТехникПаша
😁23✍3💯2❤1💊1
Нобелевскую премию по химии в 2024 году получил сотрудник Google
Дэмис Хассабис получил Нобелевскую премию по химии 2024 года.
Он co-founder DeepMind, которая теперь часть Google.
Он один из создателей AlphaFold, которая предсказывает структуру белка.
Дэмис Хассабис получил Нобелевскую премию по химии 2024 года.
Он co-founder DeepMind, которая теперь часть Google.
Он один из создателей AlphaFold, которая предсказывает структуру белка.
🔥12👍5🤯2
Увидел вот такой пост в линкедине. В заголовке у него была еще картинка FAANG.
Если в кратце, то он говорит, что он прошел все раунды собеседования, но получил реджект. И по его мнению, это некий новый феномен - ghost hiring. Т.е. собеседования только для метрик, без реального найма.
Я собеседую 2-3 раза в неделю и участвую в дебрифах, где принимается решение о найме. Такого ниразу не было за более чем 7 лет моей работы в разных FAAANG компаниях.
Мне интересна самоуверенность автора поста, что он прошел все раунды. Самостоятельно, после интервью, можно быть более или менее уверенным в coding раундах. Вы можете проверить, правильно ли вы решили, правильно ли протестили. Но даже так, может быть недостаточным communication.
А про system design и поведенческое быть уверенным, не зная реального фидбека, сложно. Вы можете получить много red flags, не зная о них, просто потому что вы так думали и действовали всегда, а это ред флаги для компании. Или же вы их прошли успешно, но по результатам ваш уровень ниже, чем тот на который вы собеседуетесь, а позиции на уровень ниже нет.
Иногда, даже успешных кандидатов, помещают в очередь ожидания, т.к. в моменте исчезли такие позиции. Но об этом вам сообщат, что вы в очереди ожидания или больше таких позиций нет.
Недавно собеседовали кандидата на позицию Staff, он на поведенческом рассказывал, что он во всех конфликтах побеждал, потому что все вокруг глупые, особенно, коллеги женщины. Я думаю, он был уверен, что прошел. Да и по system design он был оценен на уровень ниже.
Если в кратце, то он говорит, что он прошел все раунды собеседования, но получил реджект. И по его мнению, это некий новый феномен - ghost hiring. Т.е. собеседования только для метрик, без реального найма.
Я собеседую 2-3 раза в неделю и участвую в дебрифах, где принимается решение о найме. Такого ниразу не было за более чем 7 лет моей работы в разных FAAANG компаниях.
Мне интересна самоуверенность автора поста, что он прошел все раунды. Самостоятельно, после интервью, можно быть более или менее уверенным в coding раундах. Вы можете проверить, правильно ли вы решили, правильно ли протестили. Но даже так, может быть недостаточным communication.
А про system design и поведенческое быть уверенным, не зная реального фидбека, сложно. Вы можете получить много red flags, не зная о них, просто потому что вы так думали и действовали всегда, а это ред флаги для компании. Или же вы их прошли успешно, но по результатам ваш уровень ниже, чем тот на который вы собеседуетесь, а позиции на уровень ниже нет.
Иногда, даже успешных кандидатов, помещают в очередь ожидания, т.к. в моменте исчезли такие позиции. Но об этом вам сообщат, что вы в очереди ожидания или больше таких позиций нет.
Недавно собеседовали кандидата на позицию Staff, он на поведенческом рассказывал, что он во всех конфликтах побеждал, потому что все вокруг глупые, особенно, коллеги женщины. Я думаю, он был уверен, что прошел. Да и по system design он был оценен на уровень ниже.
👍17🥴11🔥2
Подготовка к System Design с нуля и для разных уровней
Эти книги и ресурсы пригодятся не только тем, кто готовится к собеседованиям в FAANG/Big Tech, но и тем, кто хочет развить свои навыки в architecture, software design и system design. Эти умения особенно важны для специалистов, стремящихся вырасти с уровней Junior/Middle до Senior/Staff/Architect.
Рекомендуется читать книги в оригинале, если вы планируете ориентироваться на мировой рынок труда (даже если не планируете переезд, но хотите работать с международными компаниями). Если таких целей нет или вам сложно с английским, можно рассмотреть переводы, однако учтите, что они часто содержат неточности и ошибки.
Beginner. Начать стоит с:
1) Clean Architecture: A Craftsman's Guide to Software Structure and Design by Robert C. Martin. Эта книга познакомит вас с основными парадигмами программирования, принципами SOLID, ключевыми подходами к архитектуре и многим другим.
Intermediate. Продолжить стоит с:
2) Building Microservices by Sam Newman. В этой книге рассматривается создание микросервисной архитектуры. Хотя микросервисы — это спорный подход, многие принципы применимы не только к ним, но и, например, к SOA.
3) [Опционально] System Design Interview: An Insider's Guide by Alex Xu. Книга охватывает основные концепции построения современных распределенных систем и предлагает множество реальных задач, которые встречаются на system design собеседованиях в компании, включая FAANG/Big Tech.
4) Курс Grokking the System Design Interview. Этот курс похож на предыдущую книгу, но в формате онлайн. Набор задач немного отличается.
5) [Опционально] Курс на algoexpert.io. Рекомендуется тем, кто уже занимается алгоритмами на этой платформе.
Advanced.
6) Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann. Рекомендую эту книгу всем, кто хочет углубиться в разработку высоконагруженных систем на уровнях Senior и выше. В ней детально раскрываются ключевые концепции современных высоконагруженных систем, включая replication, sharding, transaction isolation levels, two-phase commits, стриминг данных (например, Kafka), SQL и No-SQL базы, а также особенности распределенных систем.
7) [Опционально] Курс на educative.io: Grokking Modern System Design Interview for Engineers & Managers. Этот курс схож с Grokking the System Design Interview и книгой Alex Xu, но является более подробным и современным, с примерами из реальных system design собеседований.
8) [Опционально] Distributed Systems by Maarten van Steen, Andrew S. Tanenbaum
Для тех, кто хочет развиваться в AWS, то там есть и сертификация. Но для собеседований в FAANG (даже Amazon), эта сертификация не нужна. Но некоторые компании (не FAANG) могут наличие такого сертификата приветствовать.
Практика применения
Кроме самостоятельного изучения, важно получить практический опыт. Теория — это хорошо, но опыт работы с подобными системами незаменим. Постарайтесь найти проект у себя на работе, где можно поработать с архитектурой, распределенными и высоконагруженными системами, если это направление вам интересно. В FAANG/Big Tech получить подобный опыт проще, но зачастую такая возможность есть и в крупных локальных компаниях. Если ваш текущий работодатель не может предложить такой опыт, рассмотрите возможность смены работы. Однако, это имеет смысл, только если вы действительно хотите расти в этом направлении.
Эти книги и ресурсы пригодятся не только тем, кто готовится к собеседованиям в FAANG/Big Tech, но и тем, кто хочет развить свои навыки в architecture, software design и system design. Эти умения особенно важны для специалистов, стремящихся вырасти с уровней Junior/Middle до Senior/Staff/Architect.
Рекомендуется читать книги в оригинале, если вы планируете ориентироваться на мировой рынок труда (даже если не планируете переезд, но хотите работать с международными компаниями). Если таких целей нет или вам сложно с английским, можно рассмотреть переводы, однако учтите, что они часто содержат неточности и ошибки.
Beginner. Начать стоит с:
1) Clean Architecture: A Craftsman's Guide to Software Structure and Design by Robert C. Martin. Эта книга познакомит вас с основными парадигмами программирования, принципами SOLID, ключевыми подходами к архитектуре и многим другим.
Intermediate. Продолжить стоит с:
2) Building Microservices by Sam Newman. В этой книге рассматривается создание микросервисной архитектуры. Хотя микросервисы — это спорный подход, многие принципы применимы не только к ним, но и, например, к SOA.
3) [Опционально] System Design Interview: An Insider's Guide by Alex Xu. Книга охватывает основные концепции построения современных распределенных систем и предлагает множество реальных задач, которые встречаются на system design собеседованиях в компании, включая FAANG/Big Tech.
4) Курс Grokking the System Design Interview. Этот курс похож на предыдущую книгу, но в формате онлайн. Набор задач немного отличается.
5) [Опционально] Курс на algoexpert.io. Рекомендуется тем, кто уже занимается алгоритмами на этой платформе.
Advanced.
6) Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann. Рекомендую эту книгу всем, кто хочет углубиться в разработку высоконагруженных систем на уровнях Senior и выше. В ней детально раскрываются ключевые концепции современных высоконагруженных систем, включая replication, sharding, transaction isolation levels, two-phase commits, стриминг данных (например, Kafka), SQL и No-SQL базы, а также особенности распределенных систем.
7) [Опционально] Курс на educative.io: Grokking Modern System Design Interview for Engineers & Managers. Этот курс схож с Grokking the System Design Interview и книгой Alex Xu, но является более подробным и современным, с примерами из реальных system design собеседований.
8) [Опционально] Distributed Systems by Maarten van Steen, Andrew S. Tanenbaum
Для тех, кто хочет развиваться в AWS, то там есть и сертификация. Но для собеседований в FAANG (даже Amazon), эта сертификация не нужна. Но некоторые компании (не FAANG) могут наличие такого сертификата приветствовать.
Практика применения
Кроме самостоятельного изучения, важно получить практический опыт. Теория — это хорошо, но опыт работы с подобными системами незаменим. Постарайтесь найти проект у себя на работе, где можно поработать с архитектурой, распределенными и высоконагруженными системами, если это направление вам интересно. В FAANG/Big Tech получить подобный опыт проще, но зачастую такая возможность есть и в крупных локальных компаниях. Если ваш текущий работодатель не может предложить такой опыт, рассмотрите возможность смены работы. Однако, это имеет смысл, только если вы действительно хотите расти в этом направлении.
www.algoexpert.io
AlgoExpert | Ace the Coding Interviews
The leading platform to prepare for coding interviews. Master essential algorithms and data structures, and land your dream job with AlgoExpert.
🔥31👍19⚡3❤1👎1🤔1
Записал видео урок по массивам для начинающих
Видео предназначенно для начинающих и не предназначенно для подготовки к собесам. Только как пререквезит, перед более глубоким изучением.
https://youtu.be/eSloKL3XUEE?si=eT7arTMMalLUk1Q_
Видео предназначенно для начинающих и не предназначенно для подготовки к собесам. Только как пререквезит, перед более глубоким изучением.
https://youtu.be/eSloKL3XUEE?si=eT7arTMMalLUk1Q_
👍23🔥8✍1
Сегодня увидел в линкедине, в публичном доступе, хорошее резюме. Правда не разработчика. У человека опыт более 10 лет. Все уместилось на 1 страничку. Хорошее и простое оформление, хорошо парсится, есть хорошее summary, есть достижения с цифрами из которых понятно что, зачем было сделано, к какому результату привело и какая была роль человека в этом. Хотя тоже не без вопросов, но лучше чем у 90%.
👍18🔥4
Как оценивается производительность сотрудников в FAANG
Расскажу на примере Facebook.
Периодичность. Оценки производительности происходит периодически. Раньше это было раз в 6 месяцев. Потом сделали раз в год. Сейчас промежуточный вариант. Раз в 6 месяцев более лайтовая оценка и финальная раз в год. Есть также раз в квартал (раз в 3 месяца) чекапы с менеджером, что все идет как надо.
Что оценивается. Инженерные специальности оцениваются по 4 осям: project impact, operational excellence/better engineering, direction и people. Для каждой из осей и для каждого левела есть список ожиданий. Это то, что по каждой из осей ожидается от работы инженера. Этот список пересекается с тем, как оценивают соответствие левела сотрудника на поведенческом собеседовании.
Как оценивается.
Self evaluation. Инженер пишет большой документ с перечислением своих достижений за указанный промежуток времени по каждой из оси (self evaluation). Достижения должны содержать числовые характеристики, должны быть подтверждены ссылками на метрики, code change, дашборды, посты, документы и т.д. Очень желательно, чтобы эти достижения ссылались на те цели, которые были поставлены в начале полугодия. Раз в полгода, в компании происходит планирование, на котором формируются цели для команды, отдела и т.д. А также конкретный список проектов под эти цели. Инженер может быть ответственным за один или несколько проектов и целей. Или за подпроект или подзадачу, если проект большой, а его уровня не хватает быть лидом всего проекта. Большинство достижений будут так или иначе связанными с теми проектами и целями, которые были поставлены в начале полугодия. Но ваши достижения могут этим не ограничиваться. Может появится новая работа, новые идеи, вы сделали что-то еще.
Feedbacks. Инженер запрашивает фидбеки от коллег, с кем он работал в течении этого промежутка времени. Что было хорошо, что надо улучшить.
Packets. Далее ваш менеджер смотрит на ваш self-evaluation и составляет пакет документов на каждого из его инженеров. В нем, кроме всего прочего, есть краткая выжимка ваших ключевых достижений, которые повлияли на оценку от менеджера.
Предварительная оценка. После изучения ваших достижений и сравнения их с ожиданиями по каждой из осей, а также с целями, которые были поставлены в начале полугодия, ваш менеджер выставляет вам оценку. Эта оценка имеет множество градаций: does not meet expectation, meets some, meets most, meets all, exceed, greatly exceed, redefine.
Калибровки. В процессе калибровок пакеты документов для инженеров из разных команд и даже отделов сравниваются друг с другом. Происходят мешапы, в рамках которых менеджеры презентуют пакеты и сравнивают что они считают примерно один и тот же уровень достижений за meets all, exceed и т.д. Иногда в процессе этих обсуждений, какие-то пакеты могут изменить свою оценку на более высокую или более низкую. В результате инженер получает свою финальную оценку.
Performance Review Conversation. Это митинг с вашим менеджером, на котором он сообщит вам вашу оценку, причины того, что повлияло на эту оценку. Обсудит фидбеки и даст свой фидбек на вашу работу. Далее на основе этой оценки вам будет сообщено, какой бонус вы получите, какое повышение зп у вас будет и дадут ли вам и сколько новых акций (refreshers). Если у вас оценка ниже meets all, то у вас могут быть проблемы. Обычно, после двух полугодий подряд с оценкой ниже meets all - человека отправляют на pip или сразу увольняют по соглашению сторон (silent layoff).
Расскажу на примере Facebook.
Периодичность. Оценки производительности происходит периодически. Раньше это было раз в 6 месяцев. Потом сделали раз в год. Сейчас промежуточный вариант. Раз в 6 месяцев более лайтовая оценка и финальная раз в год. Есть также раз в квартал (раз в 3 месяца) чекапы с менеджером, что все идет как надо.
Что оценивается. Инженерные специальности оцениваются по 4 осям: project impact, operational excellence/better engineering, direction и people. Для каждой из осей и для каждого левела есть список ожиданий. Это то, что по каждой из осей ожидается от работы инженера. Этот список пересекается с тем, как оценивают соответствие левела сотрудника на поведенческом собеседовании.
Как оценивается.
Self evaluation. Инженер пишет большой документ с перечислением своих достижений за указанный промежуток времени по каждой из оси (self evaluation). Достижения должны содержать числовые характеристики, должны быть подтверждены ссылками на метрики, code change, дашборды, посты, документы и т.д. Очень желательно, чтобы эти достижения ссылались на те цели, которые были поставлены в начале полугодия. Раз в полгода, в компании происходит планирование, на котором формируются цели для команды, отдела и т.д. А также конкретный список проектов под эти цели. Инженер может быть ответственным за один или несколько проектов и целей. Или за подпроект или подзадачу, если проект большой, а его уровня не хватает быть лидом всего проекта. Большинство достижений будут так или иначе связанными с теми проектами и целями, которые были поставлены в начале полугодия. Но ваши достижения могут этим не ограничиваться. Может появится новая работа, новые идеи, вы сделали что-то еще.
Feedbacks. Инженер запрашивает фидбеки от коллег, с кем он работал в течении этого промежутка времени. Что было хорошо, что надо улучшить.
Packets. Далее ваш менеджер смотрит на ваш self-evaluation и составляет пакет документов на каждого из его инженеров. В нем, кроме всего прочего, есть краткая выжимка ваших ключевых достижений, которые повлияли на оценку от менеджера.
Предварительная оценка. После изучения ваших достижений и сравнения их с ожиданиями по каждой из осей, а также с целями, которые были поставлены в начале полугодия, ваш менеджер выставляет вам оценку. Эта оценка имеет множество градаций: does not meet expectation, meets some, meets most, meets all, exceed, greatly exceed, redefine.
Калибровки. В процессе калибровок пакеты документов для инженеров из разных команд и даже отделов сравниваются друг с другом. Происходят мешапы, в рамках которых менеджеры презентуют пакеты и сравнивают что они считают примерно один и тот же уровень достижений за meets all, exceed и т.д. Иногда в процессе этих обсуждений, какие-то пакеты могут изменить свою оценку на более высокую или более низкую. В результате инженер получает свою финальную оценку.
Performance Review Conversation. Это митинг с вашим менеджером, на котором он сообщит вам вашу оценку, причины того, что повлияло на эту оценку. Обсудит фидбеки и даст свой фидбек на вашу работу. Далее на основе этой оценки вам будет сообщено, какой бонус вы получите, какое повышение зп у вас будет и дадут ли вам и сколько новых акций (refreshers). Если у вас оценка ниже meets all, то у вас могут быть проблемы. Обычно, после двух полугодий подряд с оценкой ниже meets all - человека отправляют на pip или сразу увольняют по соглашению сторон (silent layoff).
🔥17👍5
Реальный импакт LLM на программистов
Прошло уже почти 2 года с момента релиза ChatGPT.
Прошлые части:
Заменят ли программистов нейросети в ближайшем будущем? Update
Основные преграды на этом пути:
Заменяют ли программистов в топ компаниях на нейросети?
Часть 2
Спустя два года я начал ощущать реальное влияние LLM на работу программистом и на вакансии. Однако это влияние не столь очевидно.
Что по замене программистов?
По прежнему, LLM и тулы на их основе не могут заменить программистов. Кроме отсутствие агентности, они не могут заменить даже кодинг. У нас на работе уже давно есть встроенный ассистент в среду разработки и отдельный внутренний LLM подобный чат. Он все также генерит плохой, неверный код, который нужно не то что проверять, его можно просто выкидывать на помойку. Часто он пытается угадать, что тебе нужно, но обычно это полная херня.
Есть ли реальный импакт? Есть и он значительный.
1) Собеседования. Из-за того, что начиная с 2020 собеседования стали проводить удаленно + появился ChatGPT - стало много кандидатов, которые пользуются ChatGPT во время собеседований. Смотри, например, Еще один подозрительный случай с собеседования, Уверенные пользователи ChatGPT кучно пошли Идиотов выявить несложно. Но, вероятно, есть кандидаты, которые немного не дотягивают по уровню, а ChatGPT им позволяет пройти этот bar не привлекая внимания санитаров. Из-за этого может начать плавно снижаться уровень сотрудников.
2) Улучшение текста на английском. Этим инструментом я пользуюсь регулярно на работе. Я часто делаю ошибки при написании на английском (да и на русском тоже 😁). По роду деятельности приходится много писать на английском: это и дизайн доки, и различные RFC, роадмапы, планы, цели, достижения, апдейты и многое другое. Я стал часто просить LLM исправить грамматику и немного «причесать» текст на английском. Генерация текста с нуля пока не дает нужного результата — содержание страдает. Если не предоставить все необходимые факты для включения, то модель создает красивый, но малосодержательный и часто неверный текст.
3) Реальный импакт на вакансии. Есть реальный импакт на вакансии. Но не из-за того, что LLM заменяет программистов. А из-за того, что теперь все стали делать много функционала так или иначе связанного или использующего LLM. Из-за этого стали менять приоритеты и нанимать больше специалистов по ML. Из-за этого сократили число открытых вакансий на остальные позиции. А из-за общего состояния экономики и рынка труда программистов в постковидное время, компании все еще не открывают много вакансий. А из тех что открыли - много отъедают вакансии так или иначе связанные с задачами связанными с LLM, AI и прочим ML.
4) Спрашивать его что-то по работе бесполезно. В компаниях, обычно, очень мало что документируется, и большая часть информации хранится лишь в головах сотрудников (или в переписках, на которых не происходит обучение). Пытаться выяснить что-то у LLM тоже не имеет смысла — всё по-прежнему приходится узнавать в общении с другими людьми.
Прошло уже почти 2 года с момента релиза ChatGPT.
Прошлые части:
Заменят ли программистов нейросети в ближайшем будущем? Update
Основные преграды на этом пути:
Заменяют ли программистов в топ компаниях на нейросети?
Часть 2
Спустя два года я начал ощущать реальное влияние LLM на работу программистом и на вакансии. Однако это влияние не столь очевидно.
Что по замене программистов?
По прежнему, LLM и тулы на их основе не могут заменить программистов. Кроме отсутствие агентности, они не могут заменить даже кодинг. У нас на работе уже давно есть встроенный ассистент в среду разработки и отдельный внутренний LLM подобный чат. Он все также генерит плохой, неверный код, который нужно не то что проверять, его можно просто выкидывать на помойку. Часто он пытается угадать, что тебе нужно, но обычно это полная херня.
Есть ли реальный импакт? Есть и он значительный.
1) Собеседования. Из-за того, что начиная с 2020 собеседования стали проводить удаленно + появился ChatGPT - стало много кандидатов, которые пользуются ChatGPT во время собеседований. Смотри, например, Еще один подозрительный случай с собеседования, Уверенные пользователи ChatGPT кучно пошли Идиотов выявить несложно. Но, вероятно, есть кандидаты, которые немного не дотягивают по уровню, а ChatGPT им позволяет пройти этот bar не привлекая внимания санитаров. Из-за этого может начать плавно снижаться уровень сотрудников.
2) Улучшение текста на английском. Этим инструментом я пользуюсь регулярно на работе. Я часто делаю ошибки при написании на английском (да и на русском тоже 😁). По роду деятельности приходится много писать на английском: это и дизайн доки, и различные RFC, роадмапы, планы, цели, достижения, апдейты и многое другое. Я стал часто просить LLM исправить грамматику и немного «причесать» текст на английском. Генерация текста с нуля пока не дает нужного результата — содержание страдает. Если не предоставить все необходимые факты для включения, то модель создает красивый, но малосодержательный и часто неверный текст.
3) Реальный импакт на вакансии. Есть реальный импакт на вакансии. Но не из-за того, что LLM заменяет программистов. А из-за того, что теперь все стали делать много функционала так или иначе связанного или использующего LLM. Из-за этого стали менять приоритеты и нанимать больше специалистов по ML. Из-за этого сократили число открытых вакансий на остальные позиции. А из-за общего состояния экономики и рынка труда программистов в постковидное время, компании все еще не открывают много вакансий. А из тех что открыли - много отъедают вакансии так или иначе связанные с задачами связанными с LLM, AI и прочим ML.
4) Спрашивать его что-то по работе бесполезно. В компаниях, обычно, очень мало что документируется, и большая часть информации хранится лишь в головах сотрудников (или в переписках, на которых не происходит обучение). Пытаться выяснить что-то у LLM тоже не имеет смысла — всё по-прежнему приходится узнавать в общении с другими людьми.
Telegram
FAANG Master
Заменят ли программистов нейросети в ближайшем будущем? Update
Прошлый подобный пост я писал 6 месяцев назад, спустя год после выхода нашумевшего ChatGPT 3: Часть 1, Часть 2.
Есть ли какие-то изменения, которые повлияли на мою оценку? Какие мои текущие…
Прошлый подобный пост я писал 6 месяцев назад, спустя год после выхода нашумевшего ChatGPT 3: Часть 1, Часть 2.
Есть ли какие-то изменения, которые повлияли на мою оценку? Какие мои текущие…
❤13👍10🔥2
Алгоритм Бинарного Поиска
Перезалил. Немного поправил громкость звука.
https://youtu.be/f2nYeGTkMog?si=VnNlVbgZ8nrKJ4w_
Перезалил. Немного поправил громкость звука.
https://youtu.be/f2nYeGTkMog?si=VnNlVbgZ8nrKJ4w_
👍18
Имеет ли значение какой язык программирования вы знаете для карьеры в FAANG/Big Tech
Краткий ответ: и да и нет.
Начнем с собеседования.
На собеседовании вы сможете самостоятельно выбрать язык программирования для решения задач. Однако это должен быть актуальный и востребованный язык программирования. Писать на псевдокоде не допускается. Код необходимо писать без использования автодополнения и гугления. Это означает, что, несмотря на возможность выбора любого языка и отсутствие прямых вопросов по синтаксису, знание выбранного языка будет проверяться на практике — сможете ли вы на нем писать код. Среди возможных языков вы можете выбрать, например, Python, Java, Kotlin, C#, JavaScript, C++, C, Rust, Go, Objective-C, Swift. Языки вроде Pascal, Basic, Ada, Cobol или 1С выбирать не стоит (и я не уверен, что это возможно).
Какие языки программирования придется использовать на работе?
Все зависит от вашей позиции. Есть позиции мобильных разработчиков, front-end разработчиков, ML/Data Scientists, Data Engineer, Software Engineer (Generalist, Product, Infra) и т.д. В зависимости от позиции, вам придется использовать разные языки программирования. Они могут отличаться от компании к компании, но часто пересекаются.
Front-end: JavaScript, TypeScript. Часто библиотеки и фреймворки типа React.
Mobile: Java, Kotlin, Objective-C, Swift. В зависимости от того, вы под Android или iOS.
ML/Data Scientists/Data Engineer: Python, SQL.
Software Engineer (Product, разработка продукта): Обычно, это full-stack разработка. Это комбинация JavaScript и какого-то языка для back-end: Java, C#, Python, Hacklang, Go, C++.
Software Engineer (Infra): Java, C#, C++, Python, Go, Hacklang, Rust и т.д.
Как видно, Front-end, Mobile, ML/Data Scientists, Data Engineer используют примерно один и тот же набор языков от компании к компании.
Product/Infra разработчики, могут использовать разные языки (набор языков) в зависимости от команды и компании.
В Amazon, Netflix много Java
В Microsoft много C#, C++
В Google - Go
В Meta - Hacklang, Python, C++
Нужно ли знать много языков программирования?
Я бы сказал, что нужно знать один очень хорошо, а в остальных ориентироваться. Например, можно хорошо знать Java, при этом, работая в Amazon в back-end или infra командах, вы будете использовать Java и немного другие языки программирования. При переходе в Meta или Google, найти команду чисто на Java будет сложно, но пересесть на Go или Hacklang с Java достаточно просто. Аналогичная история с C#. С C# пересесть на Java, Go, Hacklang будет просто. Если вы хорошо знаете C++, то практически гарантированно будут команды, которые пишут на C++. Но и пересесть на Java, C#, Go, Hacklang, Rust будет не так сложно.
При этом во многих командах, вам нужно будет использовать дополнительно другие языки, их знать очень хорошо не обязательно. Можно изучить под конкретную задачу. SQL это почти всегда. Python, С++ тоже пригодится. Трансфер Java, C# -> C++, Rust достаточно сложен, поэтому я бы не рекомендовал такой трансфер, если вы не знаете C++ на хорошем уровне. Но как дополнительный - можно.
Также часто есть позиции в Product, там часто full-stack. Тут в дополнение к вашему основному языку(Java, C#, Go) нужно ориентироваться в JavaScript, при этом не обязательно, чтобы это был вашим основным языком.
Краткий ответ: и да и нет.
Начнем с собеседования.
На собеседовании вы сможете самостоятельно выбрать язык программирования для решения задач. Однако это должен быть актуальный и востребованный язык программирования. Писать на псевдокоде не допускается. Код необходимо писать без использования автодополнения и гугления. Это означает, что, несмотря на возможность выбора любого языка и отсутствие прямых вопросов по синтаксису, знание выбранного языка будет проверяться на практике — сможете ли вы на нем писать код. Среди возможных языков вы можете выбрать, например, Python, Java, Kotlin, C#, JavaScript, C++, C, Rust, Go, Objective-C, Swift. Языки вроде Pascal, Basic, Ada, Cobol или 1С выбирать не стоит (и я не уверен, что это возможно).
Какие языки программирования придется использовать на работе?
Все зависит от вашей позиции. Есть позиции мобильных разработчиков, front-end разработчиков, ML/Data Scientists, Data Engineer, Software Engineer (Generalist, Product, Infra) и т.д. В зависимости от позиции, вам придется использовать разные языки программирования. Они могут отличаться от компании к компании, но часто пересекаются.
Front-end: JavaScript, TypeScript. Часто библиотеки и фреймворки типа React.
Mobile: Java, Kotlin, Objective-C, Swift. В зависимости от того, вы под Android или iOS.
ML/Data Scientists/Data Engineer: Python, SQL.
Software Engineer (Product, разработка продукта): Обычно, это full-stack разработка. Это комбинация JavaScript и какого-то языка для back-end: Java, C#, Python, Hacklang, Go, C++.
Software Engineer (Infra): Java, C#, C++, Python, Go, Hacklang, Rust и т.д.
Как видно, Front-end, Mobile, ML/Data Scientists, Data Engineer используют примерно один и тот же набор языков от компании к компании.
Product/Infra разработчики, могут использовать разные языки (набор языков) в зависимости от команды и компании.
В Amazon, Netflix много Java
В Microsoft много C#, C++
В Google - Go
В Meta - Hacklang, Python, C++
Нужно ли знать много языков программирования?
Я бы сказал, что нужно знать один очень хорошо, а в остальных ориентироваться. Например, можно хорошо знать Java, при этом, работая в Amazon в back-end или infra командах, вы будете использовать Java и немного другие языки программирования. При переходе в Meta или Google, найти команду чисто на Java будет сложно, но пересесть на Go или Hacklang с Java достаточно просто. Аналогичная история с C#. С C# пересесть на Java, Go, Hacklang будет просто. Если вы хорошо знаете C++, то практически гарантированно будут команды, которые пишут на C++. Но и пересесть на Java, C#, Go, Hacklang, Rust будет не так сложно.
При этом во многих командах, вам нужно будет использовать дополнительно другие языки, их знать очень хорошо не обязательно. Можно изучить под конкретную задачу. SQL это почти всегда. Python, С++ тоже пригодится. Трансфер Java, C# -> C++, Rust достаточно сложен, поэтому я бы не рекомендовал такой трансфер, если вы не знаете C++ на хорошем уровне. Но как дополнительный - можно.
Также часто есть позиции в Product, там часто full-stack. Тут в дополнение к вашему основному языку(Java, C#, Go) нужно ориентироваться в JavaScript, при этом не обязательно, чтобы это был вашим основным языком.
👍18🔥3❤2
Можно ли расти по карьере зная только один язык программирования?
Я бы сказал, что зная не один язык программирования, а зная один язык как основной. Даже на позиция Junior-Senior вам в дополнение к основному (или его аналогу) придется использовать еще немного других языков (JS, Python, SQL, C++). На позициях Staff+ вам придется работать на уровне нескольких команд или отдела в целом. С большой вероятностью, вам придется кроме создания direction в виде документов и митингов, придется писать код. И с большой вероятностью, этот код будет для команд, у которых профильный язык отличается от вашего. При этом вам не обязательно знать каждый язык глубоко. Вам нужно разбираться в базовых принципах, алгоритмах с структурах данных и уметь, когда нужно, глубоко погрузиться в задачу и в код, который вы хотите поменять или написать, даже если это не ваш профильный язык.
Я бы сказал, что зная не один язык программирования, а зная один язык как основной. Даже на позиция Junior-Senior вам в дополнение к основному (или его аналогу) придется использовать еще немного других языков (JS, Python, SQL, C++). На позициях Staff+ вам придется работать на уровне нескольких команд или отдела в целом. С большой вероятностью, вам придется кроме создания direction в виде документов и митингов, придется писать код. И с большой вероятностью, этот код будет для команд, у которых профильный язык отличается от вашего. При этом вам не обязательно знать каждый язык глубоко. Вам нужно разбираться в базовых принципах, алгоритмах с структурах данных и уметь, когда нужно, глубоко погрузиться в задачу и в код, который вы хотите поменять или написать, даже если это не ваш профильный язык.
👍19🔥4
Подборка постов в канале о работе в FAANG
Обновление подборки
1) Какие version control практики используют топ компании?
2) Используют ли FAANG компании Scrum или Kanban?
3) Как в Amazon происходит Design Review?
4) Используете ли вы сложные алгоритмы на работе?
5) Incident management в Amazon
6) COE Review в Amazon
7) Наступит ли счастье, если вы пройдете собеседование в FAANG?, Часть 2 , Часть 3.
8) Как проходят Code Review в Amazon и Facebook?, Часть 2
9) Хотите узнать сколько зарабатывают в топ IT компаниях мира?
10) Как выглядит релокация в другую страну, если вы получили offer от FAANG компании?
11) Какие языки программирования используются в крупнейших IT компаниях?
12) Используют ли в FAANG\Big Tech Spring и Spring Boot?
13) Мои первые впечатления, когда я начал работать в FAANG
14) Текущие офферы в некоторые Big Tech/FAANG компании
15) Какие тулы используют Amazon и Facebook для внутренней коммуникации?
16) В чем преимущество получения части компенсации в виде акций публичных компаний?
17) Сколько выходцев из СНГ работает в FAANG/Big Tech компаниях?
18) Как проходили массовые сокращения(layoffs) в Facebook? Часть 1.
19) Как проходили массовые сокращения(layoffs) в Facebook? Часть 2.
20) Как проходили массовые сокращения(layoffs) в Facebook? Часть 3.
21) Примеры внутренних тулов и библиотек Facebook, которые стали общедоступными
22) Что сейчас с хайрингом в FAANG?
23) Рейтинг Big Tech компаний по зп
24) Рейтинг BigTech компаний по отзывам сотрудников
25) Как FAANG компании делают бэкграуд чек
26) Почему Amazon имеет такие низкие оценки от сотрудников
27) Какие плюсы в работе в Amazon?
28) Как оценивается производительность сотрудников в FAANG
29) Имеет ли значение какой язык программирования вы знаете для карьеры в FAANG/Big Tech
30) Можно ли расти по карьере зная только один язык программирования?
Обновление подборки
1) Какие version control практики используют топ компании?
2) Используют ли FAANG компании Scrum или Kanban?
3) Как в Amazon происходит Design Review?
4) Используете ли вы сложные алгоритмы на работе?
5) Incident management в Amazon
6) COE Review в Amazon
7) Наступит ли счастье, если вы пройдете собеседование в FAANG?, Часть 2 , Часть 3.
8) Как проходят Code Review в Amazon и Facebook?, Часть 2
9) Хотите узнать сколько зарабатывают в топ IT компаниях мира?
10) Как выглядит релокация в другую страну, если вы получили offer от FAANG компании?
11) Какие языки программирования используются в крупнейших IT компаниях?
12) Используют ли в FAANG\Big Tech Spring и Spring Boot?
13) Мои первые впечатления, когда я начал работать в FAANG
14) Текущие офферы в некоторые Big Tech/FAANG компании
15) Какие тулы используют Amazon и Facebook для внутренней коммуникации?
16) В чем преимущество получения части компенсации в виде акций публичных компаний?
17) Сколько выходцев из СНГ работает в FAANG/Big Tech компаниях?
18) Как проходили массовые сокращения(layoffs) в Facebook? Часть 1.
19) Как проходили массовые сокращения(layoffs) в Facebook? Часть 2.
20) Как проходили массовые сокращения(layoffs) в Facebook? Часть 3.
21) Примеры внутренних тулов и библиотек Facebook, которые стали общедоступными
22) Что сейчас с хайрингом в FAANG?
23) Рейтинг Big Tech компаний по зп
24) Рейтинг BigTech компаний по отзывам сотрудников
25) Как FAANG компании делают бэкграуд чек
26) Почему Amazon имеет такие низкие оценки от сотрудников
27) Какие плюсы в работе в Amazon?
28) Как оценивается производительность сотрудников в FAANG
29) Имеет ли значение какой язык программирования вы знаете для карьеры в FAANG/Big Tech
30) Можно ли расти по карьере зная только один язык программирования?
Telegram
FAANG Master
Какие version control практики используют топ компании?
Одним из моих удивлений, когда я начал работать в топ компаниях, стало то, что они, в основном, используют так называемый Trunk-based development. В то время как в других, маленьких и средних компаниях…
Одним из моих удивлений, когда я начал работать в топ компаниях, стало то, что они, в основном, используют так называемый Trunk-based development. В то время как в других, маленьких и средних компаниях…
👍8🔥4
Подборка постов в канале с рекомендациями по подготовке к собеседованию
Обновление подборки
Гайд по подготовке: Как подготовиться к собеседованию в FAANG/Big Tech
Подготовка к System Design с нуля и для разных уровней
Подборки с моими разборами большого числа задач:
1) System Design
2) Алгоритмы
3) Java и Многопоточность
Посты с моими рекомендациями:
1) Как я изучал английский язык?
2) Как проходит собеседование в Meta(Facebook)?
3) Варианты подготовки к собеседованию в FAANG/около FAANG для разных уровней текущей подготовки Часть 2 , Часть 3, Часть 4
4) Сколько нужно решить задач на leetcode, чтобы пройти собеседование в FAANG компанию?
5) Какие бывают собеседования программистов и когда они имеют смысл?
7) Основные ошибки на собеседовании в FAANG, Часть 2
8) Почему решив 1500 задач на leetcode вы не сможете получить офер в FAANG
9) Как решать алгоритмические задачи на подготовке, чтобы это было эффективно
10) Как не забыть решения задач и алгоритмы
11) Как выбрать язык программирования для алгоритмического собеседования?
12) Стоит ли использовать https://www.topcoder.com/ или https://codeforces.com/ для подготовки к собеседованию по алгоритмам?
13) На чем проваливаются чаще на собеседовании в FAANG компании?, Часть2
14) Какой подход в самообразовании я использую?
15) Стоит ли учить алгоритмы и структуры данных и готовиться к собеседованиям вообще?
16) Нужно ли вам учить алгоритмы и структуры данных?
17) Когда стоит учить алгоритмы?
18) Сколько времени займет подготовка к собеседованию в FAANG или около FAANG компанию?
19) Как я готовился к собеседованию и попал в FAANG, Часть 2.
20) Как я готовился к собеседованию и попал Facebook?
21) Нужна ли сертификация Java программисту?
22) Нужно ли учить многопоточность в Java?
23) Сколько времени на самообразование вы тратите в неделю?
24) Как устроено System Design Interview в FAANG?
25) Советы по написанию резюме для FAANG, и не только
26) Плохое резюме
27) Советы по написанию достижений в резюме
28) Запись Mock Interview
29) В последнее время вижу много постов в линкедине, что кодинг собеседования по алгоритмам ничего не показывают, кроме того, насколько человек хочет попасть в компанию
30) Темплейт резюме
31) Резюме и реджекты
32) Разбор резюме подписчика
33) Conflict Resolution, Часть 2, Часть 3
34) Ghost hiring
35) Хорошее резюме
Обновление подборки
Гайд по подготовке: Как подготовиться к собеседованию в FAANG/Big Tech
Подготовка к System Design с нуля и для разных уровней
Подборки с моими разборами большого числа задач:
1) System Design
2) Алгоритмы
3) Java и Многопоточность
Посты с моими рекомендациями:
1) Как я изучал английский язык?
2) Как проходит собеседование в Meta(Facebook)?
3) Варианты подготовки к собеседованию в FAANG/около FAANG для разных уровней текущей подготовки Часть 2 , Часть 3, Часть 4
4) Сколько нужно решить задач на leetcode, чтобы пройти собеседование в FAANG компанию?
5) Какие бывают собеседования программистов и когда они имеют смысл?
7) Основные ошибки на собеседовании в FAANG, Часть 2
8) Почему решив 1500 задач на leetcode вы не сможете получить офер в FAANG
9) Как решать алгоритмические задачи на подготовке, чтобы это было эффективно
10) Как не забыть решения задач и алгоритмы
11) Как выбрать язык программирования для алгоритмического собеседования?
12) Стоит ли использовать https://www.topcoder.com/ или https://codeforces.com/ для подготовки к собеседованию по алгоритмам?
13) На чем проваливаются чаще на собеседовании в FAANG компании?, Часть2
14) Какой подход в самообразовании я использую?
15) Стоит ли учить алгоритмы и структуры данных и готовиться к собеседованиям вообще?
16) Нужно ли вам учить алгоритмы и структуры данных?
17) Когда стоит учить алгоритмы?
18) Сколько времени займет подготовка к собеседованию в FAANG или около FAANG компанию?
19) Как я готовился к собеседованию и попал в FAANG, Часть 2.
20) Как я готовился к собеседованию и попал Facebook?
21) Нужна ли сертификация Java программисту?
22) Нужно ли учить многопоточность в Java?
23) Сколько времени на самообразование вы тратите в неделю?
24) Как устроено System Design Interview в FAANG?
25) Советы по написанию резюме для FAANG, и не только
26) Плохое резюме
27) Советы по написанию достижений в резюме
28) Запись Mock Interview
29) В последнее время вижу много постов в линкедине, что кодинг собеседования по алгоритмам ничего не показывают, кроме того, насколько человек хочет попасть в компанию
30) Темплейт резюме
31) Резюме и реджекты
32) Разбор резюме подписчика
33) Conflict Resolution, Часть 2, Часть 3
34) Ghost hiring
35) Хорошее резюме
DEV Community
Как подготовиться к собеседованию в FAANG/Big Tech
Введение Вы решили пройти собеседование в FAANG (Facebook, Apple, Amazon, Netflix,...
👍13🔥5
Подборка постов в канале со случаями на собеседованиях:
Обновление подборки
1) Случай на собеседовании в FAANG
2) Еще один подозрительный случай на собеседовании
3) Классический случай на кодинг собеседовании в FAANG
4) Новая галочка про подозрение в читерстве на собеседовании в FAANG
5) Кандидаты из Google
6) Опытный кандидат с претензиями
7) Собеседовал недавно разработчика из Яндекс
8) Собеседовал сегодня еще одного кандидата из Google
10) Собеседовал сегодня кандидата из Сингапура
11) Собеседовал только что многократного победителя соревнований на Kaggle
12) Еще один подозрительный случай с собеседования
13) Уверенные пользователи ChatGPT кучно пошли
14) У подозрительного кандидата и резюме подозрительное
Обновление подборки
1) Случай на собеседовании в FAANG
2) Еще один подозрительный случай на собеседовании
3) Классический случай на кодинг собеседовании в FAANG
4) Новая галочка про подозрение в читерстве на собеседовании в FAANG
5) Кандидаты из Google
6) Опытный кандидат с претензиями
7) Собеседовал недавно разработчика из Яндекс
8) Собеседовал сегодня еще одного кандидата из Google
10) Собеседовал сегодня кандидата из Сингапура
11) Собеседовал только что многократного победителя соревнований на Kaggle
12) Еще один подозрительный случай с собеседования
13) Уверенные пользователи ChatGPT кучно пошли
14) У подозрительного кандидата и резюме подозрительное
Telegram
FAANG Master
Случай на собеседовании в FAANG
Компания, в которой я работаю, возобновила активный набор сотрудников, после практически годовой паузы. Я снова сейчас активно собеседую кандидатов.
Собеседования все также проходят online, как и в ковид. Я недавно собеседовал…
Компания, в которой я работаю, возобновила активный набор сотрудников, после практически годовой паузы. Я снова сейчас активно собеседую кандидатов.
Собеседования все также проходят online, как и в ковид. Я недавно собеседовал…
👍13🔥4