Про неэтичные зарплатные торги

Если вам на собеседовании эйчар/техспец/лид/кто угодно выдает что-то типа: "ну у тебя несуразно высокие зп ожидания для твоего опыта и знаний, у нас столько СЕО получает", это 🚩

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

Что делать, если вам такое говорят

Если с вами так поступают, сразу говорите: "спасибо за уделенное время, но мы не сходимся по ценностям" и уходите нафиг с собеса. Да, даже если вы джун.

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

Что делать, если кандидат хочет больше денег, чем заложено в вилку

❌ давить: "ну ты охренел столько хотеть, у нас даже инвесторы столько не получают" и ломать на понижение;

✔️ сказать: "к сожалению, мы не можем столько предложить" и, если хочется сохранить кандидата, попробовать аккуратно начать торг;

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

Если не хочется или нет места для торга - спокойно и вежливо предлагаем "оставаться на связи", без манипуляций, и всем будет хорошо.

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

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

Сходила на подкаст "Два стула"!

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

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

Вышло очень круто, как по мне: Леся и Глеб прекрасны ❤️

🔜 Смотреть здесь

Про стереотипы вокруг курсов для джунов

💳 поддержать мои дайджесты, лонгриды и просто задонатить на кофе - 5536913954129132 (Тиньк)

Цель поста - достучаться до тех, кто презрительно относятся к выпускникам курсов, потому что уверены, что все они про "вкатиться за 2 месяца сразу на зарплату в 300к". Я уже устала слушать эти мифы.

❗️Дисклеймер #1: да, наверняка есть какие-то малоизвестные курсы, которые пытаются на чем-то таком выплыть, но я буду говорить про крупняк

❗️Дисклеймер #2: я не говорю про курсы адской троицы: skillbox, skillfactory, geekbrains. Эти господа ужасны сразу по куче факторов

❗️Дисклеймер #3: я буду показывать все на примерах курсов по фронтенду, но аналогичная история на других разрабских, QA и UI/UX-курсах

1️⃣ Стереотип "курсы пропагандируют вкат за 3-4 месяца"

Средний срок курсов - 9-12 месяцев, в зависимости от школы и сферы. На Практикуме обучение фронта идет 10-13 месяцев, на Хекслете - 9, в HTML Academy - 16.

Сроки поменьше я видела у Эльбруса, но там очный буткемп на несколько месяцев на 8-10 часов кода каждый день.

2️⃣ Стереотип "они там мало учатся и занимаются ерундой"

Количество часов обучения в неделю, заявленное на лэндингах, смело домножаем на 1.5-2. Средний джун тратит, как минимум, 3-4 часа в будни и 7-8 часов в выходные, и это с учетом фултайм-работы.

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

То, как пашут вкатуны, многим из нас не снилось. Это серьезные перегрузки и нервотрепка из-за глючащей инфраструктуры.

3️⃣ Стереотип "им там обещают 300 тыщ сразу"

На самом деле, нет. Лэндинги курсов выдают средние рыночные цены на джуна. ЯП - 69к, Хекслет - 50. И только HTML Academy зачем-то обещает 150к.

На моем опыте, Хекслет и ЯП максимально близки к истине: почти все джуны, которых я знаю, залетают примерно в вилку 50-70к рублей. Флуктуации бывают и вниз, и вверх, но запросов на 300 тыщ точно нет (и рекламы такой - тоже).

4️⃣ Стереотип "да они там херней занимаются и ничего не знают"

Не согласна. В ребят материал уминают ногами на куче теории, практики и личных проектов. Свой джун-минимум они оттуда выносят и какого-то невероятного менторинга после найма не требуют.

Знают ли они меньше теории, чем выпускники вузов? Зависит от вуза, но, с шансами, да. Просто потому что в вузах учатся 4 года (и даже с поправкой на некоторое количество ненужных предметов типа физры и ОБЖ), а на курсах - 1 год.

Разница в опыте с лихвой компенсируется мотивацией.

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

И это все при том, что основная задача курса - продать, а не удерживать потом. Люди заканчивают обучение буквально вопреки бардаку, поломанной инфре, несбалансированным (порой) материалам и возможному тотальному равнодушию менторов.

5️⃣ Стереотип "им там все разжевывают и в рот кладут"

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

6️⃣ Стереотип "курсы покупают, потому что не хотят учиться сами, по книгам, как деды учились"

Это не так работает. Во-первых, удачи вам научиться верстать по книгам или UI/UX только по книгам освоить, хехе.

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

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

🔽🔽🔽

Сегодня. Донатный МК: “Progress Bar на HTML/CSS/JS”

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

Сегодня мы с вами потрогаем ванильный JS, обсудим работу с DOM и то, как можно создавать кастомные UI/UX-элементы, которыми удобно пользоваться.

От вас нужно:

🔘базовые знания HTML, CSS и JS;
🔘 подготовленная песочница на Codesandbox или аналоге, чтобы вы могли кодить вместе со мной и задавать вопросы;

🗓 пройдет сегодня, в четверг, 11 июля, в 19:00 по Мск

▶️ запись останется в общем доступе по этой же ссылке в посте, вход свободный

❤️ Этот МК стал возможен благодаря Оксане Ш., Ренату Ф., Василию З.

💳 поддержать новые движухи - 5536913954129132 (Тиньк)

А я сегодня вам принесла чудесную подборку каналов девчонок-айтишниц.

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

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

Итак, встречайте!

🟣Anna Sea IT - Анна, системный аналитик, ментор и тимлид, а еще и яхтсменка. Она делает публичные мок-собесы тимлидлов, рассказывает, что делать с агрессивными коллегами и помогает не продолбать мотивацию у субординатов;

🔵Выйди и зайди в IT нормально 🗿 - Агата, руководительница проектов в IT, рассказывает о том, как строить карьеру, о PM-буднях и выкладывает очаровательные фото. Она разработала план «Как начать карьеру в IT» (подойдет для начинашек и продолжающих), говорит о гигиене созвонов, делится подборкой книг для PM и интересующихся;

🟢 Никаких багов - канал Маши, амбассадорки QA, work-life balance и бережного к себе отношения. Развенчивает различные мифы о тестировщиках, предлагает не рваться на тряпки на испытательном сроке и делится списками стажировок для новичков;

🟡 frontend от ежетты - милейший фронтенд-канал с ёжиками 🦔 Много верстки (а кроме того, vue, php, sql) , добрых мемов, образовательных технических материалов, в том числе, и для подготовки к собесам (вёрстка, javascript, инструменты). Есть списки рекомендуемых книг для новичков и продолжающих. Очень дружелюбное и джуно-ориентированное место;

🟣 Хочу в STEM - Саша, продуктовый аналитик из Авито и автор маленького славного курса на степике "Что такое программирование и почему это интересно". Она классно разбирает продуктовые кейсы, рассказывает про собесы в разные компании, а еще составила подборку учебных материалов для джунов-аналитиков;

🔵 Нетипичная айтишница - Маша перекатилась из медицины в дата-инжениринг, делится мок-собесами по DE, пишет атмосферный лайф-стайл контент и рассказывает, где в Москве можно интересно провести время;

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

Поговорим про плохие увольнения

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

Я сама писала про увольнения 2 материала на канале:

🟣3 правила, которые спасут вам нервы и деньги, если вас пытаются уволить с работы (по ТК)
🟣Про увольнения с ГПХ-договора

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

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

Представители компании могут (и должны) вести себя корректно и оставаться в рамках деловой этики, не оправдывая свое поведение тем, что работник "сам виноват". Даже если работник облажался - расстаемся спокойно, профессионально и без гадостей. Если, извините, сотрудник вам насрал на стол, не надо пристраиваться рядышком и срать на этот же стол с тройным энтузиазмом. Самое дивное, что я видела: владелица бизнеса обещала сломать сотруднице руки, если та продолжит просить выплатить остаток зарплаты.

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

Итак, флаги

🚩 вам не сообщили заранее агенду встречи, и вы не знали, что это - увольнительный созвон/встреча. Вы сразу попадаете в неравное положение: они подготовились, заранее все обсудили и продумали, а вам надо что-то судорожно соображать на месте;

🚩 на встрече больше 2 человек (вашего руководителя и HR) со стороны работодателя - противодействовать толпе оппонентов очень сложно, вас, опять же, ставят в неравное положение;

🚩 от вас требуют подписать бумаги срочно, сию секунду, прям вот "нет времени объяснять - подписывай";

🚩 от вас требуют подписать "по собственному желанию" или "по соглашению" без выплат.

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

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

🚩 начинается любая эскалация эмоций, давление и угрозы: "а вот мы тебя подведем под дисциплинарки", "а вот мы будем тебя травить", "а вот мы сейчас тебе все задачи будем под роспись ставить и дрючить сковородкой", повышение голоса, оскорбления;

🚩 вам говорят, что, раз вы устроены по ГПХ/ИП/СЗ (при условии того, что это - постоянная, а не проектная работа), вы должны уйти одним днем, без компенсаций и непотраченных отпускных;

Видите что-то такое? Сразу закрываем коммуникацию, прощаемся и топаем консультироваться к юристу, просим помощи в чате джунов и смотрим доклад Витали Шароватова.

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

Резюмирую

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

Лучше подписать какую-то бумагу на пару дней позже, чем подписать что-то, что вам навредит.

💳 поддержать мои дайджесты, лонгриды и просто задонатить на кофе - 5536913954129132 (Тиньк)

Дайджест полезных материалов на этом канале

📖 Самообучение и курсы

- "Золотая четверка" курсов для джунов-фронтов;
- Как писать конспекты, чтобы это было полезно;
- Про отношение к своему плохому коду (дизайну/любому другому результату);
- Вам не нужен личный ментор (почти никогда);
- Как быстро и надежно отбить себе мотивацию учиться;

✅ Поиск работы

- Основные ошибки в тестовых заданиях (и как получить бонусные баллы при проверке);
- Как подготовиться к лайвкодингу, чтобы не волноваться;
- Что такое референсы и как их получить;
- Как написать в соцсети о том, что ищешь работу, чтобы это было продуктивно;
- Как хорошо проходить собеседования;
- Почему нельзя писать сопроводительные с помощью ChatGPT;
- Рассказ о себе и достижениях по методу капусты;
- 🔥🔥🔥 Эксперимент: какая на самом деле конкуренция в IT для джунов: анализ рынка в цифрах (+ мои впечатления);
- Фото в IT-резюме: зачем и как;
- Как оформить репозиторий с тестовым заданием или пет-проектом;
- 2 вещи, которые вам надо знать про контакты в резюме на hh;
- Про неэтичные зарплатные торги;

‼️ Увольнения

- 3 правила, которые спасут вам нервы и деньги, если вас пытаются уволить с работы (по ТК);
- Про увольнения с ГПХ-договора;
- Поговорим про плохие увольнения;

🙂 Софт-скиллы и карьера

- Мой путь в IT (внешняя ссылка);
- Личный бренд: Зачем? Почему? Как?;
- Как давать положительный фидбек, чтобы не обидеть;
- Как я впервые отсобеседовала человека и что из этого вышло;
- Как задавать вопрос по работе/учебе так, чтобы вам помогли;
- Про страх публично опозориться;
- Почему "горящие глаза" - это плохо (+ где "гореть глазами" можно);
- Деньги - мотивация;
- Про оценки и собесы;
- Стереотипы вокруг курсов для джунов;
- Менторинг на работе, личный менторинг и наставничество на курсах;

💫 Frontend/UI/UX

- Идеи пет-проектов для фронтов (верстка);
- Фронтенд-инструменты для пет-проектов;
- Про доступность интерфейсов и этику;

⛵️ Фриланс

- Стереотипы о фрилансе, плюсы и минусы;
- Как собрать портфолио для фриланса;
- Как провести ресерч конкурентов;
- Как писать сопроводы на фрилансе и не только;

🎙 Стримы и МК

- Структура HTML-страницы (часть 1, часть 2);
- Анализируем сложный HTML-макет;
- МК "Рисуем на CSS": делаем тыкву;
- МК "Рисуем на CSS": делаем мышку;
- МК “Progress Bar на HTML/CSS/JS”;

🎵 Подкасты (аудио/видео)

- Frontend Weekend (внешняя ссылка);
- "Поговорим о собесах на фронта (и не только)";
- Сходила на подкаст "Два стула"!;

💬 Митапы

- Митап #1: анимация в вебе и мок-собес джуна-фронта;
- Митап #2: поиск первой темы для доклада и концептуальный подход к подготовке к собесам;
- Митап #3: основные рекрутерские боли и архитектура для джунов;
- Митап #4: мок-собесы джунов с рекрутерами и концепт стандартных задач фронта;
- Митап #5: о репутации в индустрии и том, как оценивать качество своей работы;
- Митап #6: карьерный путь до сеньора и разбор стандартной задачи фронта на примере;
- Митап #7: карьерный путь в JS-разработке, React-хуки и как разбирать сложный код на компоненты;
- Митап #8: мок-собес Java-джуна;
- Митап #9: мок-собес джуна-фронта;
- Митап #10: про архитектуру для самых маленьких и о том, как сделать пет-проект и не задолбаться;
- Митап #11: о том, кто такие Product Owner, и мок-собес джуна-фронта;
- Митап #12: мок-собес джуна-AQA (плюс фидбек собеседующему от тимлида);
- Митап #13: мониторинг веб-приложений и паттерны взаимодействия React-компонентов;
- Митап #14: мок-собес джуна .Net/C#;
- Митап #15: рассказ джуна об устройстве на первую работу, миддл + о карьерном росте и стрим с лидом QA/AQA о резюме, хардах и поиске работы;
- Митап #16: Q&A сессия с эйчар, сторителлинг для начинающих авторов контента и помощь начинающим тимлидам;
- Митап #17: демонстрация внутрянки headHunter со стороны эйчара и практикум по canvas;
- Митап #18: взаимодействие с QA и рассказ о синдроме самозванца;
- Митап #19: cookie-аутентификация и мок-собес джуна PHP;
- Митап #20: IaC инструменты: HashiCorp Terraform и круглый стол про достигаторство;
- Митап #21: как варить классный кофе и мок-собес джуна-фронта;
- Митап #22: структурная типизация и RxJS;

Конспект: "Как дизайну и разработке найти общий язык" (ч.1)

💳 поддержать мои гайды, лонгриды и просто задонатить на кофе - 5536913954129132 (Тиньк)

Это второй выпуск рубрики "Конспект" (первый - тут), в которой я буду публиковать сюда интересные материалы с краткой выжимкой.

Итак, сегодня принесла вам статью "Отрицание, гнев, торг: как дизайну и разработке найти общий язык".

❗️Статья очень большая, поэтому постов-выжимок будет два.

Почему я вообще принесла эту статью

Везде, где я работала, UI/UX-дизайнеры не были включены в продуктовую команду разработки, они жили отдельно, своими дизайнерскими командами со своими внутренними процессами. Контакт между дизайнерами и всеми остальными выглядел примерно так: "вот вам макеты, и живите с ними, как хотите".

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

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

Теперь выжимка (ч.1)

🟣основные боли разрабов при взаимодействии с дизайнерами:

🔘 неполные и неконсистентные макеты (не хватает экранов/состояний элементов/сообщений об ошибке или успехе/лоадеров);
🔘 вместо компонентов из дизайн-системы (если она есть), просят кастомные компоненты без объяснения причин;
🔘 дизайнеры не понимают ограничений разработки и рисуют "красивое";

🔵 основные боли дизайнеров при взаимодействии с разрабами:

🔘 реализуют макеты с очевидными багами, которые невозможно не заметить;
🔘 разрабы не вникают в макеты на этапе концепта (если им показывают) и заранее не указывают на ограничения;
🔘отказываются что-то делать, потому что это "слишком сложно/невозможно" (а потом оказывается, что и возможно, и не сложно);

❤️ что нужно улучшить, чтобы порадовать всех #1: делать больше совместных грумингов, чтобы разработка могла посмотреть на макеты несколько раз до того, как их полностью согласуют с продактами и C-lvl. Это уменьшит количество сложных ситуаций и переделок;

❤️ что нужно улучшить, чтобы порадовать всех #2: делать дизайн-ревью готового фронтенда заранее, а не за день до релиза, чтобы ревью и починка багов не делались с горящей жопой и с риском не выкатить релиз;

🟢 что отдельно можно улучшить, чтобы порадовать разрабов:

🔘если есть дизайн-система, стараться все, что можно, делать с ее помощью;
🔘стараться заранее продумывать все состояния компонентов и интерактивных элементов (ховеры, лоадеры, сообщения об успехе/ошибке, темную/светлую тему - если есть итд);
🔘повысить грамотность дизайнеров в плане ограничений платформ, чтобы не рисовали невыполнимое;
🔘указывать отдельно в фигме и в чатах, что в макетах что-то изменилось;

🟡 что отдельно можно улучшить, чтобы порадовать дизайнеров:

🔘 помочь дизайнерам повышать упомянутую "грамотность": организовать локальные внутренние ликбезы/митапы, делиться обучающими материалами;
🔘 разрабам - поучиться пользоваться фигмой, посмотреть пару туториалов (или почитать эту статью);

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

Про перфекционизм

💳 поддержать мои гайды, лонгриды и просто задонатить на кофе - 5536913954129132 (Тиньк)

Перфекционизм был в моей семье всегда. Отец гордился тем, что, когда учился в школе, если делал помарку в конце тетради, переписывал ее всю заново. Вы бы видели его потрясающий почерк! Это - чистое искусство. От меня ждали такого же отношения ко всему, что я делаю: работа должна быть сделана идеально, вообще любая, а если что-то не так - выкидываем результаты в помойку и переделываем заново.

Пока ты в школе, это более-менее работает: оценка результатов прямолинейная. Задача или решена верно, или нет. Сочинение или написано с ошибками, или нет. Стихотворение или выучено, или нет. А потом мы вырастаем, находим работу, в данном случае - приходим в айти, и начинается трындец.

Как только мы делаем что-то сложнее "поправить мелкий баг", вляпываемся в сразу несколько проблем:

🟣 никто ничерта не знает, что такое "сделать идеально". Есть бест-практисы, но даже об них с энтузиазмом ломают копья убеленные сединами айтишные деды. Попробуйте найти хоть один концепт или технологию, вокруг которых не было бы десятков эпичных конфликтов: говно оно или не говно - не выйдет;

🟢 более того, очень хорошее в моменте решение может отстрелить тебе жопу через несколько месяцев. А если в этом самом моменте начать защищаться от всех "а что, если", нагородишь таких переусложнений, что потом не разгребет никто;

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

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

Альтернатива перфекционизму - подход "достаточно хорошо"

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

Что такое "достаточно хорошо" на примере. Представим, что мы - фронтенд-разраб, и у нас задача - сделать модальное окошко. "Достаточно хорошо" будет, если:

🔘 мы соблюли визуальные требования - модалка с начинкой соответствуют дизайну;

🔘 мы соблюли функциональные требования - модалка открывается по клику на нужную кнопку, закрывается, показывает верную начинку, начинка тоже работает;

🔘 мы учли типовые продуктовые корнер-кейсы - поддержку разных браузеров (если надо), поддержку разных типов устройств (если надо), ситуацию, если "начинка" не прогрузилась/ее слишком много, например, 100 абзацев текста (это называется проверкой на переполнение контентом);

🔘 мы сделали аккуратный код без видимых костылей, заложили базовую автономность компонента с модалкой (не прибили его гвоздями к текущему компоненту), учли самые типовые корнер-кейсы, соблюли код-стайл проекта (или сформировали пак предложений в случае необходимости от него отступить);

🔘 на всякий случай, перепроверили свою работу перед сдачей;

Все, вы великолепны!

А если я вижу, как улучшать и улучшать дальше

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

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

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

Помните главное. Лучше сделать что-то, пусть не идеально, и разобрать свои ошибки по итогу, чем сделать идеальное "ничего"

Как критиковать, чтобы это было конструктивно

Дисклеймер. Я не буду в этом посте рассказывать про сэндвич-концепт ("похвали" - "поругай" - похвали"), сосредоточусь на другом.

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

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

Дисклеймер #2. Я не говорю о ситуациях, когда собеседник вас достал, и вы хотите защитить свои границы. Это уже не критика и выходит за рамки поста.

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

Хорошо, а как на практике?

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

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

Что вырасти не помогает

🟣 любые переходы на личности (критика человека, а не идеи/результата). Приведу примеры из фидбеков на реальных мок-собесов с ютуба: от "Ну для человека без формального образования достаточно хорошо" до "Когда говорю с вами, ощущение, что общаюсь с ChatGpt" (речь не про то, что кандидат списывает, а про манеру разговора);

🟣видимые обесценивания. Тоже из реального мока: "вообще, эта задача должна быть решена за 2 минуты, и то, если ночь не спать". Задача уже не решена за это время, хотя собеседуемый выложился на полную. От того, что ткнешь человека в его несовершенства таким образом, легче никому не будет;

🟣отсутствие конкретики. "Не, ну плохо сделано" - не конкретика. Совершенно неясно, что с этим замечательным фактом делать.

Что вырасти помогает

Связка "что неправильно -> почему это неправильно -> как правильно -> какие дополнительные шаги сделать, чтобы улучшить (опционально)".

У критикуемого по каждому пункту должно остаться на руках 3 вещи: что именно не так, почему оно не так и как сделать, чтобы было "так".

Например: "Решение задачи, на мой взгляд, неоптимально, потому что <... список причин ... >. Чтобы было оптимально, нужен подход такой-то и потому-то. Почитай Васю Пупкина, он в своих статьях отлично это раскрывает, можно еще добить книгой Пупки Васина, если хочется".

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

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

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

Когда давать критику, чтобы было конструктивно

1️⃣ когда вас о ней просят (просьба должны быть прямой. Если человек что-то выложил в интернет, это не запрос на критику);

2️⃣ когда это подразумевает контекст (например, вы ревьюите коллегу или проводите мок-собес);

Если меня не просят, а хочется покритиковать?

Говорим: "Мне кажется, я могу помочь улучшить твой результат. Хочешь?". Если ответ положительный - отлично, критикуем, если отрицательный - тоже хорошо, что вы не потратили зря время.

Вот я и рассказала, что хотела. Гарантирую, эти правила сберегут и вам, и окружающим много сил и нервов.