Правила ответственной коммуникации

После опроса про важные софты решил делиться некоторыми интересными материалами. Сам предстоящий год буду инвестировать в них.

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

📍 Какие материалы и инструменты помогают мне лучше формулировать мысли:

🟣 Знаменитая книга "Пиши, сокращай", которая стала библией у многих людей, даже далеких от ИТ. Я уже лет 5 юзаю их сайт, который подсвечивает ошибки или дает совет как сделать текст читаемым
🟣 Ну и следом туда же "Новые правила деловой переписки" от этого же автора
🟣 Отличный курс от яндекс практикума "Навыки аргументации для руководителей". Этот курс, на мой взгляд, пойдет к специалистам любого уровня. А заголовок просто кликбейтный

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

Что ждет FAANG в 2024 году?

Найм в Meta вырос на 800% с января, в Netflix на 300%.

Сайт interviewing.io на основе своих данных, подготовил предсказания на 2024 год. Сервис отслеживает, кто в какие компании готовится, какие мок-интервью покупает и кто в конце концов получает оферы.

🟢 В 2024 году FAANG начнет нанимать больше инженеров. Сейчас только Meta и Netflix агрессивно нанимают, но в следующем году остальные компании последуют их примеру.

🟢 С января 2024 года найм мидлов и синьоров значительно вырастет.

🟢 Как минимум ближайшие 6 месяцев компенсационный пакет не изменится (зарплаты, бонусы, акции).

🟢 Как минимум следующие полгода, компании будут продолжать пытаться убедить кандидата принять офер на ступень ниже. В FAANG есть вероятность 57% что вам предложат грейд ниже вашего. В других компаниях этот показатель 37%.

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

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

Подробнее о ключевом слове final

Многим известно, что final классы приводят к оптимизации. Его советуют использовать также в доке по оптимизации в соурсах.

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

Основные причины использовать final:
🟡Оптимизация производительности. Методы и свойства становятся статическими, что помогает сократить поиск во время выполнения
🟢Поддержка цельности. Мы запрещаем изменение свойств и методов.

Async/Await for Swift

Я тут хотел освежить память в чем же плох GCD и зачем нам нужна новая система многопоточности.

В итоге, не нашел ничего полезного этого материала. Автор, кстати, был одним из тех, кто описывал пропосал по Structured Concurrency.

📌 Какие же главные минусы у GCD?

⏺ Pyramid of doom — вложенность кода с колбэками затрудняет чтение и дебаггинг
⏺ Проблема обработки ошибок.
⏺ Неэффективное использование ресурсов из-за ограничений тредов
⏺ Легко допустить ошибки с возвратом колбэков

Как саботировать работу в ит-компании?

Отличие опытного спеца от новичка — умение работать и принимать изъяны системы и доводить задачу до конца даже в условиях стресса и дискомфорта. Когда я был новичком моей работе мешало все и хотелось изменить мир: неидеальные процессы, несправедливые оплаты труда, неправильную оценку на собесах, громкое дыхание коллег. Никто кроме меня не знал как работать.

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

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

Некоторые советы применимы к нашей области:

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

🟣Много говорите и как можно дольше. Рассказывайте личные истории и анекдоты.

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

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

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

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

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

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

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

Welcome. Небольшой намек куда ушел 🤣

Моя любимая задача с собесов по программированию

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

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

Статья за авторством Carlos Arguelles, бывший Bar Raiser в Амазон. За свою карьеру провел больше 1000 собеседований.

Carlos поделился своей любимой задачей по програмированию, которую уже задавал порядка 500 раз и которая, по его мнению, на 95% совпадает с итоговым решением.

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

Многие стремятся сразу написать сходу самое лучшее решение. Но интервьюер оценивает не только код, но и как мыслит кандидат. Какие вопросы задает кандидат, подмечает ли краевые кейсы, как оценивает решения, сколько помощи требует. В конце концов, собеседование это поиск ответа на вопрос «Смогу ли я работать с этим человеком?».

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

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

🟣Более грамотные специалисты догадываются, что скорость поиска O(1), необходимую для превращения O(n²) в O(n), может обеспечить словарь (Map). Лучшие же кандидаты предусмотрительно отмечают недостаток такого подхода, заключающийся в использовании O(n) памяти. Здесь повышение скорости достигается за счёт увеличенного потребления памяти.

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

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

Как часто вы думаете о римской империи?

Я писал здесь большой пост об идеях Сенеки. Как его мысли последнюю неделю проходит инкубацию в моей голове. Как стоицизм отлично матчится с итишкой. Что кому-то иногда интересно читать майндсеты и ментальные практики, за что получаю спасибо в личках. Но решил сфокусироться на других задачах и тупо скинуть видос.

Одна из сильнейших идей по ресурс менеджмету и самоидентификации у стоицизма — держаться дальше от толпы

🔜 Видос: https://www.youtube.com/watch?v=9-pBBNjfO6E

Как определить сеньора?

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

🟢Платформа. Где час или два спрашивают всякие вопросы про iOS: многопоточность, управление памятью, UIKit и язык. Обычно это самая легкая секция и к ней проще подготовиться просто прочитав рекомендации или ваши любимые сливы и методички с вопросами. В зависимости от духоты и адекватности, конечно.

🟡Программирование. Её многие называют "алгоритмами", но это уже неверно. Обычно дают одну или две небольшие задачи. Смотрят на ход мышления кандидата, его самостоятельность, качество кода. Может ли он предложить лучшее решение, сравнить свой код по эффективности и как будет действовать в небольшом стрессе. Без подготовки эту секцию очень сложно сделать на отлично.

🟣Проектирование. Это обязательная секция для сеньоров на которой и решается мидл ли ты позорный или тру инженер. На нее зовут тех, кто прошел предыдущие секции на отлично. Здесь и есть возможность определить сеньорность кандидата. Секция обычно длится 1-2 часа. На ней кандидату дают какую-нибудь задачу в стиле "Запроектируй аналитику". Здесь оценивают как кандидат собирает сам требования без подсказок, проактивничает, не усложняет и все эти приколы с чистыми архитектурами и SOLID’ами, как минимум. Также эту секцию без реального опыта лидирования задач очень сложно пройти.

Интересные материалы для проектирования:
- Framework For Mobile System Design
- Mobile system design book
- Mobile Syste design

Делитесь своими материалами по систем дизайну