🎡 Увольнение - новое начало

"Все, кому удавались великие свершения, до этого оказывались в том же положении, что сейчас и вы. И лишь потом они добивались успеха." Райан Бингэм

Вышла очередная статья про лейоффы с интересной статистикой. Приведу выжимку.

• Некоторые менеджеры по найму сомневаются в качестве недавно уволенных инженеров. Другие видят возможность и извлекают выгоду, нанимая сокращенных сотрудников из Meta, Twitter и других Big Tech компаний.

• Найм ускорился в 2023. Кандидаты проходят собеседование в среднем всего за пять дней по сравнению с семью днями в 2022 году, поскольку компании спешат нанять лучших специалистов.

• По данным Karat, большинство уволенных (61%) ищут должности того же уровня, 27% стремятся к высоким позициям, переходя в более мелкие организации, и только 12% готовы проходить собеседования на должности более низкого уровня, чем раньше.

• 70% из уволенных ищут возможность остаться в технологической индустрии, ходят на интервью в SaaS и маркетплейсы. 30% рассматривают нетехнологический сектор - финансы, здравоохранение, производство.

• Каждый 13 из 100 потерявших свою работу, начинают свой собственный бизнес. 33% уволенных из Meta создают свой стартап, DoorDash - 30%, Amazon - 25%, Twitter 16%, Shopify 15%.

➡️Ссылка на оригинальную статью
https://devinterrupted.substack.com/p/where-are-all-the-laid-off-software-a41

━━━━━━━

Мне больше всего интересны последние цифры. Почему преимущественно инженеры из Amazon и Meta после layoff создают свои компании?

Я вижу 3 возможные причины:
1️⃣ Инженеры считают, что добились вершины в инженерии и дальше смысла нет продолжать в этом направлении. Решают попробовать себя в чем-то новом.
2️⃣ Разработчики просто не видят лучше альтернатив на рынке. Любая следующая компания будет априори хуже.
3️⃣ Культура Amazon/Meta поощряет написание своих проектов, устраивает хакатоны, вовлекает инженеров в бизнес дискуссии и запускает потенциальные инициативы. Это дает уверенность и навыки инженерам дальше пробовать и создавать свои сервисы.

Вообщем еще одна причина стремится туда. Интересно послушать мысли ребят из этих компаний.

❔Чтобы вы сделали, если бы сегодня получили уведомление об увольнении?
🧑‍💻 - Искал бы новую работу
🎃 - Попробовал бы сменить направление
🐳 - Открыл бы свою компанию

🕹Парадокс лояльности

Стоит ли работать сверухрочно или вне рабочее время, если попросил менеджер?

Лояльность сотрудников к компании имеет свои плюсы для обеих сторон. Но иногда работодатели используют эту преданность для эксплуатации сотрудников. Например дают дополнительные обязанности, просят поработать подольше или в выходные, нагружают тяжелыми задачами, и все это без повышения зарплаты или всего лишь несущественная надбавка.

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

Так вот, менеджера склоны эксплуатировать преданных сотрудников, чем менее лояльных коллег. Это может быть даже неосознанно, ведь с просьбой легче прийти к человеку, который скажет всегда «Да», чем к тому, который будет спорить и торговаться.

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

Вспоминается мысль из книги «Договориться можно обо всем». Добровольные уступки не смягчают другую сторону, а делают их позицию еще жестче. Всегда пытайтесь найти обмен, который вас устроит.

➡️Ссылка на публикацию
https://www.sciencedirect.com/science/article/abs/pii/S0022103122001615

❓Был ли у вас кейс, когда руководство хотело сесть на шею?

🥋Опять про сертификации

Кандидаты с сертификатами в профиле Linkedin имеют меньше шансов пройти техническое интервью. Статья от interviewing.io.

Приводится наблюдение, что обычно указывают все пройденные курсы и полученные сертификаты, люди, которые перешли в IT из другой области. То есть имеют непрофильное образование.

Предполагается, что по этой причине люди на мок интервью в interviewing показывают на 4% хуже результат, чем их визави без сертификатов.

Также люди склонны указывать сертификаты, когда не имеют опыта работы в именитых компаниях. Таким образом стараются сделать красивую картинку для рекрутера, пришедшего на страницу профиля.

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

Кратко подытожу:
• Люди с образованием в Computer Science лучше проходят технические собеседования.
• Рекрутеры больше обращают внимание на опыт в крупных компаниях, нежели на сертификаты.

➡️Ссылка на статью
https://interviewing.io/blog/why-you-shouldnt-list-certifications-on-linkedIn

Согласны ли с идеей, что сертификаты в профиле LinkedIn только вредят? Поставь 👍 или 👎

😈 Пятничный тредик

Тут недавно Нурлан в комментариях предлагал написать пост, почему не стоит идти в IT.

У каждого есть свои причины любить и ненавидеть айтишку. Так вот, я подумал, почему бы не спросить у вас.

✔️ Напишите в комментариях главную причину, почему IT это ошибочный выбор профессии. Что больше всего вас разочаровало, чтобы вы хотели знать на заре карьеры, о чем умалчивают на курсах и тд.

Я начну 👇

🇨🇳 Опыт в Google, Shanghai

Куда было собеседование?

Software Engineer, Pixel Software Quality - Google, Shanghai

Какие были этапы и до какого этапа дошла?

Я подала на сайте Google Careers в три локации: Mountain View Zurich и Shanghai. Примерно в августе сообщили что прошла в Шанхайский офис и пригласили на звонок с рекрутером. После примерно через неделю пригласили на technical phone interview, дальше не прошла

Какие примерно были технические и поведенческие вопросы?

На звонке с рекрутером были чисто теоритические вопросы, тайм комплексити алгоритмов, вопросы по имплементации структур данных и одна математическая логическая задача(сказали в уме возвести 2 в степень 1024). На техническом раунде была только одна задача, приближенная к задаче из реальной практики по автодополнению слов.

Как тебе интервью процесс и сами интервьюеры?

Все очень удобно. На подготовку дают столько времени сколько нужно. Но сам процесс длительный, я запросила 2 недели на подготовку, в итоге на деле до технического раунда ждала больше месяца. Интервьюеры очень дружелюбные.

Как ты думаешь, где показала себя хорошо, а где не очень?

Этапов было не так много, поэтому могу предположить что на техническом раунде не до конца выложилась. В начале на задаче по автодополнению долго колебалась какую структуру выбрать, в итоге когда выбрала tree думаю дальше пошло немного легче.

Чтобы изменила в следующий раз?

Процесс подачи не совсем ложился с моей подготовкой, думаю мне еще нужно подтянуть себя по leetcode, подала просто потому что увидела что вакансии есть на сайте.

Автор: Балжан @baljibeka

✔️ Давайте поддержим автора лайками и добрыми комментариями 🙂

➡️ Если вы в процессе интервью и нужна помощь в подготовке, прочитайте пост https://t.me/bigtechdream/237

#google #реальныйопыт

🍿Как оценивают behavioral в Meta?

📍Поведенческое интервью имеет две задачи:
- Оценить есть ли у кандидата хорошие примеры из прошлого, которые потенциально помогут стать успешным в Meta
- Оценить уровень кандидата: junior, middle, senior

⌚Формат интервью:
- 45 минут: 5 на введение и знакомство, 35 на основную часть, 5 на вопросы кандидата
- Кандидату зададут 5-6 вопросов


📊Критерии оценки кандидатов:

- Мотивация
Что ими движет? Идеальные кандидаты целеустремленны, увлечены технологиями и продуктами, которые оказывают влияние на бизнес и пользователей.

- Инициатива
Способны ли они проявлять инициативу? Если возьмутся за сложную проблему, смогут ли они найти решение и реализовать его?

- Работа в неопределенности
Могут ли они брать на себя ответственность в неоднозначных ситуациях? Или постоянно ждут, когда им скажут, что нужно сделать?

- Настойчивость
Способны ли они довести задачу до конца, не взирая на все блокеры и препятствия?

- Разрешение конфликтов
Как они справляются со сложными отношениями? Могут ли договариваться и разрешать конфликты?

- Эмпатия
Насколько хорошо они способны видеть вещи с точки зрения других и понимать их мотивы?

- Рост
Понимают ли кандидаты свои сильные и слабые стороны, и зоны для роста? Прикладывают ли они усилия для своего профессионального развития?

- Коммуникация
Способны ли они четко изложить свою историю во время интервью?

🥇Как определяется грейд?
• Junior: Истории обычно вокруг задач, которые они делали внутри команды.
• Senior: Действует на уровне всей команды, решает проблемы, помогает, договаривается. Иногда управляет.
• Staff: Оперирует на уровне организации или нескольких команд.

➡️Ссылка на оригинальную статью
https://interviewing.io/blog/how-software-engineering-behavioral-interviews-are-evaluated-meta

👻 Новые Увольнения

Уже нужно заводить рубрику на канале по этой тематике 🙂

В октябре Nokia объявила, что увольняет порядка 14K сотрудников, после квартала, в котором прибыль упала на 69%.

Qualcomm, производитель полупроводников и компьютерных чипов, сокращает около 1258 рабочих мест в двух своих калифорнийских офисах, это около 2.5% всего штата.

Qualtrics, поставщик веб-инструментов для опросов и отчетов, планирует уволить около 780 человек по всей компании. Еще несколько сотен ролей внутри компании подвергнуться реорганизации.

Product Hunt, сайт для поиска стартапов и приложений, уволил около 60% своей команды, включая дизайнеров, продактов и продажников.

Stack Overflow, сайт для технических вопросов/ответов, принадлежащий Prosus, объявил о сокращении штата сотрудников на 28% в рамках стремления к повышению прибыльности. Ходят слухи, что это на фоне разработки новой Overflow AI, говорили об этом тут.

➡️Ссылка на статью
https://techcrunch.com/2023/10/27/tc-startups-weekly-10-27-23

━━━━━━

Увидел новость про нокию, вспомнил свой nokia 5310 xpressmusic, прослезился 🥲

🚕 Офер в Яндекс за неделю

Дисклеймер. Соглашаться на офер никто не заставляет, но это хорошая возможность потренироваться проходить технические собеседования.

Яндекс устраивает «Week Offer Backend» - возможность для бэкенд разработчиков с опытом 3+ лет получить офер за неделю.

• 13 ноября - в онлайне расскажут про нанимающие команды
• до 19 ноября - онлайн контест
• 20-25 ноября - технические собеседования
• 20-25 ноября - финальные интервью
• до 26 ноября - оферы

➡️Ссылка на новость
https://yandex.ru/project/events/backend-tour-1123

🚔 Как инженеру не сесть за решетку?

Что вы сделаете, если узнаете, что ваша компания проворачивает что-то незаконное? А что если вас попросят написать код, который нарушает закон? Пойдете на сделку со своей совестью?

Инженерному директору FTX Nishad Singh грозит 75 лет в тюрьме. Если кто не в курсе крипто новостей, криптовалютная биржа FTX украла у инвесторов 9 миллиардов долларов и сейчас идет суд. Так вот, в ходе расследования выяснилось, что Nishad не только знал о махинациях, но и решил остаться и помочь компании выбраться, еще взял в долг у компании, чтобы прикупить домик.

Хороший пример. Стартап для студенческих займов Frank утверждал, что у них 5 млн пользователей. Их купил банк JP Morgan и попросил предоставить информацию по пользователям. На деле оказалось, что пользователей было около 300К. Основатель стартапа пыталась убедить инженера сгенерировать синтетические пользовательские данные на 4.3 млн человек, но инженер отказался и предоставил банку истинные данные. В итоге инженер на свободе, фаундеры в тюрьме.

✔️ Уроки, которые стоит выучить:
• Если просят сделать что-то на грани легальности, попробуйте отказаться от этой задачи, даже если обещают вознаграждение.
• Документируйте и сохраняйте все переписки и встречи. Явно показывайте свое беспокойство и озадаченность. Короче собирайте доказательную базу на черный день.
• Обратитесь за помощью к юристам для консультации. Лучше потратить часть накоплений на юриста, чем потратить свою жизнь в тюрьме.
• Всегда есть возможность уйти из компании, вы никому ничего не должны.

➡️Ссылка на статью
https://newsletter.pragmaticengineer.com/p/the-pulse-66

━━━━━━━━

Как разработчику, мне вообще не хочется задумываться насчет легальности и этичности задач, я просто хочу двигать тикеты и перекладывать джейсоны.

Но нужно периодически включать критическое мышление, чтобы не оказаться потом крайним.

Как-то давно на одном из проектов мы захардкодили количество заявок в интерфейсе. На деле было меньше сотни, а на фронте показывали +1000. Вроде не критично, но тоже не хорошо.

❓У вас были истории, когда просили сделать что-то мутное на работе?

🇬🇧 Опыт в THG, UK

Куда было собеседование?
Graduate Software Engineer, THG (UK)

Какие были этапы и до какого этапа дошел?
1. HackerRank OA
2. HackerRank Assessment Interview (спрашивают почему так написал а не так в хакерранке)
3. Technical assessment (algo)
4. Background & Cultural fit

Какие примерно были технические и поведенческие вопросы?
1. HackerRank: 1 leetcode medium, 1 rest api, 1 sql
2. HackerRank Assessment Interview: CS fundamentals (ds, algo, networking, os)
3. Technical assessment: 1 LC easy (if two strings are anagrams), 2 medium (max sum subarray)
4. Behavioral: спрашивали по CV (у меня в сиви было написано что я занимался оптимизацией и меня спросили какие техники для этого использовал), why thg?, moment i received a negative feedback

Как тебе интервью процесс и сами интервьюеры?
HR довольно быстро отвечает и отвечает на любые вопросы (не гостит), сами интервью довольно легко пройти, интервьюеры готовы всегда помочь/подсказать, и некоторые интервьюеры готовы поразгонять вопрос и выйти out of question’s scope

Как ты думаешь, где показал себя хорошо, а где не очень?
Думаю что везде хорошо себя показал.

Чтобы изменил в следующий раз?
Подготовить более детальные и интересные вопросы для интервьюеров.

✔️ Давайте поддержим анонимного автора лайками и добрыми комментариями 🙂

➡️ Если вы в процессе интервью и нужна помощь в подготовке, прочитайте пост https://t.me/bigtechdream/237

#thg #реальныйопыт

🍋Горькая правда или сладкая ложь

Выжимка из статьи «10 горьких истин работы разработчика, о которых умалчивают».

В статье указаны 10 советов, я приведу тут всего 5, по-моему самых интересных и важных.

🎒Университет не может подготовить к жизни

Научится плавать можно, только войдя в воду. После нескольких лет теории вас бросают в олимпийский бассейн, приходится учиться на ходу. У многих профессоров нет практического опыта работы и зачастую учебная программа отстает от нужд индустрии.

🧱Не ждите проектов с нуля

Во время учебы можно писать простые проекты с нуля, пробовать разные подходы. Но на реальной работе вам скорее всего придется работать с легаси кодом на тысячи строк с ограниченной свободой выбора подхода, библиотек, технологий и фреймворков. Учитесь работать с легаси.

🚮Всем насрать на чистый код

Главное это делать полезные фичи для пользователей, красивые отступы это вторично. Бизнесу важно насколько быстро вы можете реализовывать функционал. Чистый код оценят лишь коллеги на код ревью.

🤢Иногда будут попадаться некомпетентные коллеги

В It-индустрии работают много низкоквалифицированных, токсичных и/или неадекватных инженеров. Они могут влияют негативно и на вашу работу. Сосредоточтесь на своей продуктивности, сохраняйте профессиональное общение, ищите способы договориться. Если все плохо, обращайтесь на помощью.

💰От софт скиллов больше пользы, чем от хард скиллов

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

➡️Ссылка на статью
https://www.mensurdurakovic.com/hard-to-swallow-truths-they-wont-tell-you-about-software-engineer-job

━━━━━━━

Недавно с коллегой на работе обсуждали как раз-таки последний совет.

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

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

❓Какой софтскилл, по вашему мнению, помог бы вам добиться больших успехов в карьере?

👶 Идеальный возраст для Big Tech

Я тут на днях думал о том, когда лучше всего устраиваться в разные MAANGи и вот, что я надумал.

60% процентов работников Google в возрастной группе 20-30 лет. Медианный возраст 29 лет. Сотрудники 30-40 лет составляют 20% процентов. У Amazon похожее распределение. 60% сотрудников Google покидают компанию в течении 2 лет.

Я смело предположу, что большинство кандидатов устраиваются в MAANG в возрасте 20-30 лет. После 30 лет в силу разных причин, шансы устроиться в BigTech падают.

👉Так вот, по моему мнению, идеальный возраст для Big Tech это 23-27 лет. Попробую объяснить.

Первые 4-5 лет после университета стоит посвятит саморазвитию, набраться необходимых хард скиллов и по навыкам вырасти до мидла. Еще есть смысл попробовать поработать с токсичными коллегами, неадекватными менеджерами, сложными задачами - набрать багаж личных побед и поражений.

Также во время этого периода можно периодически собеседоваться в большие компании, получать отказы и работать над ошибками. Можно чуть ли не каждый год пробовать в Google/Amazon/Meta.

Ближе к 23-27 инженер должен иметь все необходимые навыки, чтобы попасть в MAANG. Глаза еще горят, есть желание дальше расти и совершенствоваться. Чувство риска притупленно, есть смелость уехать в другую страну и еще семью свою прихватить.

После 27 будут в запасе пару лет, чтобы поработать в big tech, разочароваться в нем и уйти в стартап/оверемплоймент. Ну или наоборот, выбрать себе компанию/команду по душе и продолжить там расти в долгий срок.

После 30 желание пробовать новое и вообще что-то менять кардинальное в своей жизни падает. Деньги и комфорт начинают превалировать. Да и лень готовиться к литкоду, хакерранку. Вообщем инженеры превращаются в драконов.

Это все субъективно и спорно конечно. Пища для размышлений и повод для дискуссии.

➡️Статистику взял отсюда
https://www.zippia.com/google-careers-24972/demographics/

━━━━━━━━━━

👍 - если верите, что рано или поздно попадете в MAANG

👎 - если нет желания, времени, веских причин стремиться туда

🇬🇧 Опыт в Bloomberg, Лондон

Куда было собеседование?

Software Engineer, London Bloomberg

Какие были этапы и до какого этапа дошел?

Ссылку на вакансии рекрутер сама прислала, так как в прошлом году у меня было собеседование. Потом позвали на phone interview. Но, к сожалению, дальше не прошел.

Какие вопросы были?

Раньше не встречал именно такой задачи, но она была похожа на задачу Merge Intervals. На самом деле задача довольно простая, и я предложил сразу оптимальное решение с сортировкой и других решений придумать не смог. Обсуждали решение, написал рабочий код без багов. Если честно, после собеседования подумал что прошел на следующий этап (так как в прошлом году прошел phone interview в bloomberg и был опыт). Но когда получил отказ, договорился с рекруктером о созвоне чтобы получить фидбэк. В фидбэке она посоветовала улучшить communication, collabration, и еще предлагать разные решения для сравнения. В итоге понял свои ошибки и еще, оказывается, в течение года потерял навыки прохождения собеседования.

Что больше всего понравилось?

На данном этапе сложно сказать, что понравилось. Все было стандартно, как и в других компаниях.

Что бы изменил в следующий раз?

Я бы проходил больше мок интервью и серьезнее готовился к интервью.

✔️ Давайте поддержим анонимного автора лайками и добрыми комментариями 🙂

➡️ Если вы в процессе интервью и нужна помощь в подготовке, прочитайте пост https://t.me/bigtechdream/237

#bloomberg #реальныйопыт

📱Технические блоги

Я тут пытаюсь себя приучить читать инженерные блоги и изучать, как устроены крупные сервисы под капотом.

Умные люди говорят, что это отличный способ подготовиться к систем дизайну. Мол вместо того, чтобы придумывать как реализовать дропбокс, можно понять как он на самом деле реализован.

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

• Netflix TechBlog
• Uber Blog 
• The Cloudflare Blog
• Engineering at Meta
• LinkedIn Engineering
• AWS Architecture Blog 
• Stripe Blog: Engineering
• Discord Blog: Engineering & Developers
• Slack Engineering

➡️Ссылка на полный список
https://blog.bytebytego.com/p/79-engineering-blogs-to-level-up

✔️Сохрани себе, чтобы не потерять

⏰Как распределить время на систем дизайне?

Репост поста про тайм менеджмент на систем дизайн интервью за авторством Dinesh Varyani.

✅ 𝐑𝐞𝐪𝐮𝐢𝐫𝐞𝐦𝐞𝐧𝐭 𝐂𝐥𝐚𝐫𝐢𝐟𝐢𝐜𝐚𝐭𝐢𝐨𝐧𝐬 - (3-5 𝐦𝐢𝐧)
Ask clarifying questions to understand the problem and expectations of the interviewer.
  𝐚) 𝐅𝐮𝐧𝐜𝐭𝐢𝐨𝐧𝐚𝐥 𝐑𝐞𝐪𝐮𝐢𝐫𝐞𝐦𝐞𝐧𝐭𝐬
   👉 Focussed use cases to cover (MVP)
   👉 Use cases that will not be covered
   👉 Who/How will use the system
   👉 Total/Daily active users
  𝐛) 𝐍𝐨𝐧 𝐅𝐮𝐧𝐜𝐭𝐢𝐨𝐧𝐚𝐥 𝐑𝐞𝐪𝐮𝐢𝐫𝐞𝐦𝐞𝐧𝐭𝐬
   👉 Is the system Highly Available or Highly Consistent? CAP theorem?
   👉 Does the system requires low latency?
   👉 Does the system needs to be reliable?
  
✅ 𝐄𝐬𝐭𝐢𝐦𝐚𝐭𝐢𝐨𝐧𝐬 (3-5 𝐦𝐢𝐧)
  👉 Latency/Throughput expectations
  👉 QPS (Queries Per Second) Read/Write ratio
  👉 Traffic estimates
  👉 Storage estimates
  👉 Memory estimates

✅ 𝐀𝐏𝐈 𝐃𝐞𝐬𝐢𝐠𝐧 (3-5 𝐦𝐢𝐧)
  👉 Outline the different APIs for required scenarios
 
✅ 𝐃𝐚𝐭𝐚𝐛𝐚𝐬𝐞 𝐒𝐜𝐡𝐞𝐦𝐚 𝐃𝐞𝐬𝐢𝐠𝐧 (3-5 𝐦𝐢𝐧)
    👉 Identify the type of database (SQL or NoSQL)
    👉 Design schema like tables/columns and relationships with other tables (SQL)

✅ 𝐒𝐲𝐬𝐭𝐞𝐦'𝐬 𝐃𝐞𝐭𝐚𝐢𝐥𝐞𝐝 𝐃𝐞𝐬𝐢𝐠𝐧 (20 - 25 𝐦𝐢𝐧)
(a) Draw/Explain high-level components of the system involving below (if required) components -
   👉 Client (Mobile, Browser)
   👉 DNS
   👉 CDN
   👉 Load Balancers
   👉 Web / Application Servers
   👉 Microservices
   👉 Blob/Object Storage
   👉 Proxy/Reverse Proxy
   👉 Database (SQL or NoSQL)
   👉 Cache at various levels (Client side, CDN, Server side, Database side, Application level caching)
   👉 Messaging Queues for asynchronous communication

 (b) Identification of algorithm/data structures and way to scale them
 (c) Scaling individual components - Horizontal & Vertical Scaling
 (d) Database Partitioning -
   i) Methods
     👉 Horizontal Partitioning
     👉 Vertical Partitioning
     👉 Directory-Based Partitioning
   ii) Criteria    
     👉 Range-Based Partitioning
     👉 Hash-Based Partitioning (Consistent Hashing)
     👉 Round Robin
 (e) Replication & Redundancy -
    👉 Redundancy - Primary & Secondary Server
    👉 Replication - Data replication from active to mirrored database     
 (f) Databases
    👉 SQL - Sharding, Indexes, master-slave, master-master, Denormalization
    👉 NoSQL - Key-Value, Document, Wide-Column, Graph 
 (g) Communication Protocols and standards like - IP, TCP, UDP, HTTP/S, RPC, REST, Web Sockets

✅ 𝐑𝐞𝐬𝐨𝐥𝐯𝐞 𝐛𝐨𝐭𝐭𝐥𝐞𝐧𝐞𝐜𝐤𝐬 𝐚𝐧𝐝 𝐟𝐨𝐥𝐥𝐨𝐰-𝐮𝐩 𝐪𝐮𝐞𝐬𝐭𝐢𝐨𝐧𝐬 (2-3 𝐦𝐢𝐧𝐮𝐭𝐞𝐬)

➡️Ссылка на источник
https://www.linkedin.com/posts/dinesh-varyani_google-amazon-meta-activity-7127986958584139776-Pj_z

✔️Сохрани себе на будущую подготовку
✔️Отправь друзьям и коллегам, которым тоже будет полезно

🎮Из картинки в приложение

Разработчики это будущие дизайнеры.

Приложение tldraw реализовало фичу, которая позволяет воплощать в жизнь нарисованный концепт, при помощи AI конечно же. Эта функция использует API GPT-4V OpenAI для визуального распознавания рисунка и конвертации его в функционирующий веб-код Tailwind CSS и JavaScript.

Видео в посте показывает пример, где разработчик просто рисует форму и просит сделать из нее реальную web форму. Далее простым текстом разработчик просит сделать правки: поменять текст, добавить кнопку и тд.

Люди уже начали рисовать и создавать игры при помощи этой фичи: змейки, крестики нолики и тд.

➡️Ссылка на пост
https://arstechnica.com/information-technology/2023/11/ai-powered-drawing-app-stuns-developers-by-turning-sketches-into-functional-games

━━━━━━━━━━

Концепт выглядит прикольно. Я тут подумал, а что если в будущем разработчики только и будут скармливать дизайн доки ИИ и тот будет сам реализовывать функционал, поднимать все в облаке и запускать сервис.

Вполне возможно, что появится новый слой абстракции между разработчиком и работающим кодом. Тогда от инженера будут требоваться корректные промпты и донастройка созданного софта.

Как думаете, станут ли разработчики в какой-то момент просто рисовать дизайны, вместо написания кода? 👍 👎

🗑 Алгоритмы не важны

Наткнулся на статью на хабре под названием «Алгоритмы не важны», приведу выжимку и свои мысли.

Есть два типа инженеров, те кто создают технологии и те, кто при создают решения при помощи уже существующих технологий.

Первые это те, кто создают новые базы данных, новые поисковые движки, языки программирования и так далее. Этой категории людей определенно нужно знать алгоритмы. Скорость и эффективность для них являются критичными, ведь разработчики просто не будут использовать БД, которая за O(N) находит индексы.

Вторые - это 98% всех инженеров, веб разработка, мобильная разработка, ML/DS и так далее. То есть те, которые поверх существующих баз данных, фреймворков, облачных решений строят продукты и сервисы.

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

➡️Ссылка на публикацию
https://habr.com/ru/articles/774682/

━━━━━━

На самом деле это вечный холивар. Я согласен, что алгоритмы не сильно конвертируются в пользу на работе.

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

⁉️Поделитесь в комментариях, считаете ли что алгоритмы должны исчезнуть из собеседований или наоборот думаете, что это обязательный навык каждого инженера?