Ну, я бы все-таки сказал, что готовиться нужно. Иначе вообще все печально может выглядеть.
Но в целом я с вами согласен.
После долгого перерыва без собеседований я пришел на интервью, прекрасно понимал, как решать задачу, мог объяснить алгоритм словами, но написать ни одной строчки кода не смог. Просто ступор. Дыхание перехватило, из-за того что на тебя смотрят и оценивают, мысли моментально разлетелись. До сих пор не понимаю, как это работает.
При этом мои знания вполне можно оценить объективно - по отзывам коллег, по опыту и по тем материалам, которые я публикую. Например, у меня есть статья, где я подробно разбирал архитектуру MassTransit и рассказывал о реализации Sagas.
Еще одна моя ошибка была в том, что я слишком сильно воспринимал обратную связь от интервьюеров. Но чем больше общался с разными людьми, в том числе гораздо более сильными и авторитетными специалистами, тем больше понимал, что мнение какого-то руководителя из неизвестной мне компании - это далеко не истина в последней инстанции.
К тому же я встречал интервьюеров, которые сами были напряжены или явно не в настроении. Там просто надо уходить. Если человек сам постоянно находится в негативе, это его выбор. Главное - не перенимать это состояние на себя. Очень многие проблемы начинаются именно из-за нервов. Если он хочет тратить на это свое здоровье - это его дело.
И, кстати, я далеко не один такой. У друзей из других компаний были абсолютно такие же истории.
У меня так же есть друзья, которые работают уже с 15 лет проггерами. Есть накрутчики так же в отдельности. Однако они хорошие специалисты и решают задачи на высоте. Руководители ими довольны.
Порой жизнь вносит свои коррективы, и поиск работы становится вопросом выживания.
Поэтому сложно однозначно осуждать человека, который списывает. При этом так поступают не только начинающие специалисты, но и люди с большим опытом, для которых это лишь способ повысить свои шансы.
В то же время можно понять и руководителя. Он стремится собрать надежную команду и минимизировать риск неудачного найма.
У каждой стороны свои мотивы, а значит - и свой стресс.
Эта статья написана для того, чтобы помочь взглянуть на процесс собеседований спокойнее и снизить уровень этого стресса как у кандидатов, так и у нанимающих.
Это выражение применимо не только к собеседованиям, а практически к любой сделке или ситуации, которая не состоялась.
Отказы могут идти один за другим, и это само по себе не является показателем уровня знаний. Конечно, бывают случаи, когда кандидат объективно не справился с каким-то вопросом или задачей - такое тоже случается, и в этом нет ничего необычного.
В некоторых компаниях процесс выглядит максимально формально: кандидатов заносят в Excel таблицу, выставляют баллы по разным критериям, а затем принимают решение на основе итоговой оценки.
Мало баллов - значит кандидат не проходит дальше. Насколько такой подход эффективен - каждый может оценивать по-своему.
У интервьюеров может быть множество тараканов в голове. Сегодня одни, завтра другие и все этому подвержены.
Главная мысль в другом: к отказам стоит относиться спокойнее.
Эта статья написана для того, чтобы показать начинающим и даже опытным специалистам: попытка полностью контролировать процесс собеседования бессмысленна.
Слишком много факторов находится за пределами влияния человека которого собеседуют…
Достаточно один раз столкнуться с кандидатом, который успешно списывал на собеседовании, не справился с работой и отношение интервьюера может измениться.
После такого опыта он начинает видеть потенциального списывателя практически в каждом новом кандидате. Возникает излишняя подозрительность, а иногда - даже автоматические отказы тем, кто кажется «слишком подготовленным» или отвечает слишком уверенно.
Со временем это обычно проходит, но до тех пор под удар могут попасть и абсолютно честные специалисты.
Поэтому странно видеть обесценивание чужих трудов. Человек просто взял и перевел полезный материал - с инициативой и интересом к теме(раскрасил даже более красиво диаграмму, чем у ориг.автора). Не высказал своего мнения, просто перевел статью.
Не каждая статья обязана быть полезной senior и middle разработчикам и то даже в работе младших разработчиком можно найти полезности(обычно Senior/Middle специалисты в этом не признаются, ЭГО слишком велико).
Судя по реакции и закладкам, материал нашёл свою аудиторию. Дарья - junior-разработчик, который пытается разбираться в теме и делиться знаниями. Такой энтузиазм обычно хочется поддерживать, а не отбивать токсичными комментариями.
Я в первую очередь обратил внимание на ваш профиль - вы написали, что являетесь младшим специалистом в backend-разработке. Поэтому на будущее хочу сказать следующее.
Токсичность
На токсичность некоторых ребят просто не обращайте внимания - это ещё вполне адекватная публика(с долькой иронии и юмора, что вполне даже здорово). В IT-сообществе, к сожалению, хватает токсичных людей.
Люди часто ждут от статьи чего-то «взрывного» и необычного, не задумываясь о том, что за любым материалом стоят чей-то опыт, время и труд. Для кого-то описанные вещи могут быть очевидными, а для кого-то - действительно полезными и новыми.
При этом каждая опубликованная статья - это ещё и определённая конкуренция на рынке за те же вакансии. Человек делится своими знаниями, хотя мог бы оставить их при себе.
Ирония в том, что такой труд далеко не всегда бывает благодарным: работодателям порой всё равно, сколько сил ты вложил в статьи, open source или обучение других людей.
К тому же многие вообще не зарегистрированы на Хабре - они просто читают материалы без лайков, комментариев и какой-либо обратной связи. Поэтому по реакции под статьёй не всегда можно объективно судить о её реальной пользе.
Опыт близкого окружения
У меня есть друг - Senior-разработчик, сильный специалист. После одной статьи ему столько негатива и «помидоров» накидали, что, как он сам говорил, желание публиковаться на Хабре пропало совсем.
Хотя он парень действительно умный: работал в одном из крупнейших банков России.
Выбор библиотеки - это почти всегда зона ответственности сильных специалистов: техлида, иногда архитектора и других ключевых участников команды. Обычно они собираются, обсуждают варианты, взвешивают плюсы и минусы и принимают решение.
Созвоны, как известно, бывают разные: есть формата «ППР» - пришли, поговорили, разошлись, а есть действительно содержательные встречи, где решаются важные технические вопросы.
Не буду говорить о конкретном банке - это NDA, и подставлять людей не хочется. Скажу лишь так: в одном из крупнейших банков России(я уверен во множестве так), в одном из подразделений, используется MassTransit
1) не правильно вставили ссылку на sharplab(нажмите CreateGist там)* Вы же делаете статью для других, а красота в мелочах
2) Я кстати тоже разбирал state machine, ток опорой в ней была библиотека MassTransit и SagaStateMachine сравнивал с AsyncStateMachine - https://habr.com/ru/articles/1033712/#mt14 Рекомендую посмотреть.
3) И не используйте длинные "-" т.е "—" т.к это слишком сильно любит ИИ(в том числе он любит фантомить). Утверждать, что это ИИ не стану т.к в оригинальной статье данные тире есть, но это сразу бросаетсяв глаза.
В любом случае лайк уж поставлю за отсылку к оригинальной статье и за распространение в РУ сегменте(я об этой статье незнал даже, ведь как то из уст в уста информация бегает) - вполне себе полезно(как ссылка на другие источники), удачи вам!
Хочу поблагодарить всех, кто следил за статьёй, а также новых читателей. Сообщаю, что больше не планирую её поддерживать: основные и наиболее интересные(даже сверх этого, ведь подобного материала сам не встречал), на мой взгляд, темы уже разобраны.
Материал потребовал большой работы, поэтому буду благодарен за поддержку - будь то продвижение статьи, подписка или комментарий.
Как применять эту информацию дальше - остаётся на ваше усмотрение. Если остались вопросы, задавайте их в комментариях. Всем удачи!
По пунктам 1-3 уже внесены первые изменения, однако пока они носят базовый и поверхностный характер.
Следующий этап: - Углубить каждое из направлений: доработать реализацию, повысить качество структуры и сделать примеры более содержательными, детальными и практически полезными.
Статья будет постепенно расширяться, дополняться и улучшаться, пока сохраняется мотивация заниматься этим - а она есть. Поэтому, если вам интересно следить за прогрессом, рекомендую добавить страницу в закладки*.
Пока в приоритете следующие задачи:
добавить сворачиваемые блоки для кода (чтобы их можно было удобно скрывать и раскрывать для лучшей читаемости);
сделать темы статьи более «звучащими» и структурированными;
расширить примеры и сделать их более конкретными и наглядными.
Ну, я бы все-таки сказал, что готовиться нужно. Иначе вообще все печально может выглядеть.
Но в целом я с вами согласен.
После долгого перерыва без собеседований я пришел на интервью, прекрасно понимал, как решать задачу, мог объяснить алгоритм словами, но написать ни одной строчки кода не смог. Просто ступор. Дыхание перехватило, из-за того что на тебя смотрят и оценивают, мысли моментально разлетелись. До сих пор не понимаю, как это работает.
При этом мои знания вполне можно оценить объективно - по отзывам коллег, по опыту и по тем материалам, которые я публикую. Например, у меня есть статья, где я подробно разбирал архитектуру MassTransit и рассказывал о реализации Sagas.
Еще одна моя ошибка была в том, что я слишком сильно воспринимал обратную связь от интервьюеров. Но чем больше общался с разными людьми, в том числе гораздо более сильными и авторитетными специалистами, тем больше понимал, что мнение какого-то руководителя из неизвестной мне компании - это далеко не истина в последней инстанции.
К тому же я встречал интервьюеров, которые сами были напряжены или явно не в настроении. Там просто надо уходить. Если человек сам постоянно находится в негативе, это его выбор. Главное - не перенимать это состояние на себя. Очень многие проблемы начинаются именно из-за нервов. Если он хочет тратить на это свое здоровье - это его дело.
И, кстати, я далеко не один такой. У друзей из других компаний были абсолютно такие же истории.
У меня так же есть друзья, которые работают уже с 15 лет проггерами. Есть накрутчики так же в отдельности. Однако они хорошие специалисты и решают задачи на высоте. Руководители ими довольны.
Порой жизнь вносит свои коррективы, и поиск работы становится вопросом выживания.
Поэтому сложно однозначно осуждать человека, который списывает. При этом так поступают не только начинающие специалисты, но и люди с большим опытом, для которых это лишь способ повысить свои шансы.
В то же время можно понять и руководителя. Он стремится собрать надежную команду и минимизировать риск неудачного найма.
У каждой стороны свои мотивы, а значит - и свой стресс.
Эта статья написана для того, чтобы помочь взглянуть на процесс собеседований спокойнее и снизить уровень этого стресса как у кандидатов, так и у нанимающих.
Это выражение применимо не только к собеседованиям, а практически к любой сделке или ситуации, которая не состоялась.
Отказы могут идти один за другим, и это само по себе не является показателем уровня знаний. Конечно, бывают случаи, когда кандидат объективно не справился с каким-то вопросом или задачей - такое тоже случается, и в этом нет ничего необычного.
В некоторых компаниях процесс выглядит максимально формально: кандидатов заносят в Excel таблицу, выставляют баллы по разным критериям, а затем принимают решение на основе итоговой оценки.
Мало баллов - значит кандидат не проходит дальше. Насколько такой подход эффективен - каждый может оценивать по-своему.
У интервьюеров может быть множество тараканов в голове. Сегодня одни, завтра другие и все этому подвержены.
Главная мысль в другом: к отказам стоит относиться спокойнее.
Эта статья написана для того, чтобы показать начинающим и даже опытным специалистам: попытка полностью контролировать процесс собеседования бессмысленна.
Слишком много факторов находится за пределами влияния человека которого собеседуют…
Достаточно один раз столкнуться с кандидатом, который успешно списывал на собеседовании, не справился с работой и отношение интервьюера может измениться.
После такого опыта он начинает видеть потенциального списывателя практически в каждом новом кандидате. Возникает излишняя подозрительность, а иногда - даже автоматические отказы тем, кто кажется «слишком подготовленным» или отвечает слишком уверенно.
Со временем это обычно проходит, но до тех пор под удар могут попасть и абсолютно честные специалисты.
Алексей, давайте по справедливости, проверьте в Google или в Яндексе по запросу:
site:habr.com "Ranjeet Singh"или даже по уникальному фрагменту кода:
site:habr.com "awaiter = 5__1.GetStringAsync("https://msdn.microsoft.com\").GetAwaiter();"Если так последнее вбить нигде нет упоминания medium сайта.
site:habr.com "https://medium.com/@ranjeetdotme/how-async-await-works-in-c-eccf16bd3b90"Я специально проверял.
Поэтому странно видеть обесценивание чужих трудов. Человек просто взял и перевел полезный материал - с инициативой и интересом к теме(раскрасил даже более красиво диаграмму, чем у ориг.автора). Не высказал своего мнения, просто перевел статью.
Не каждая статья обязана быть полезной senior и middle разработчикам и то даже в работе младших разработчиком можно найти полезности(обычно Senior/Middle специалисты в этом не признаются, ЭГО слишком велико).
Судя по реакции и закладкам, материал нашёл свою аудиторию. Дарья - junior-разработчик, который пытается разбираться в теме и делиться знаниями. Такой энтузиазм обычно хочется поддерживать, а не отбивать токсичными комментариями.
Вообщем я вас не поддерживаю в данном вопросе.
Вводная часть
Я в первую очередь обратил внимание на ваш профиль - вы написали, что являетесь младшим специалистом в backend-разработке. Поэтому на будущее хочу сказать следующее.
Токсичность
На токсичность некоторых ребят просто не обращайте внимания - это ещё вполне адекватная публика(с долькой иронии и юмора, что вполне даже здорово). В IT-сообществе, к сожалению, хватает токсичных людей.
Люди часто ждут от статьи чего-то «взрывного» и необычного, не задумываясь о том, что за любым материалом стоят чей-то опыт, время и труд. Для кого-то описанные вещи могут быть очевидными, а для кого-то - действительно полезными и новыми.
При этом каждая опубликованная статья - это ещё и определённая конкуренция на рынке за те же вакансии. Человек делится своими знаниями, хотя мог бы оставить их при себе.
Ирония в том, что такой труд далеко не всегда бывает благодарным: работодателям порой всё равно, сколько сил ты вложил в статьи, open source или обучение других людей.
К тому же многие вообще не зарегистрированы на Хабре - они просто читают материалы без лайков, комментариев и какой-либо обратной связи. Поэтому по реакции под статьёй не всегда можно объективно судить о её реальной пользе.
Опыт близкого окружения
У меня есть друг - Senior-разработчик, сильный специалист. После одной статьи ему столько негатива и «помидоров» накидали, что, как он сам говорил, желание публиковаться на Хабре пропало совсем.
Хотя он парень действительно умный: работал в одном из крупнейших банков России.
Тут уж каждому своё.
Выбор библиотеки - это почти всегда зона ответственности сильных специалистов: техлида, иногда архитектора и других ключевых участников команды. Обычно они собираются, обсуждают варианты, взвешивают плюсы и минусы и принимают решение.
Созвоны, как известно, бывают разные: есть формата «ППР» - пришли, поговорили, разошлись, а есть действительно содержательные встречи, где решаются важные технические вопросы.
Не буду говорить о конкретном банке - это NDA, и подставлять людей не хочется. Скажу лишь так: в одном из крупнейших банков России(я уверен во множестве так), в одном из подразделений, используется MassTransit
Дарья, я понимаю, что вы перевели статью, но:
1) не правильно вставили ссылку на sharplab(нажмите CreateGist там)*
Вы же делаете статью для других, а красота в мелочах
2) Я кстати тоже разбирал state machine, ток опорой в ней была библиотека MassTransit и SagaStateMachine сравнивал с AsyncStateMachine - https://habr.com/ru/articles/1033712/#mt14
Рекомендую посмотреть.
3) И не используйте длинные "-" т.е "—" т.к это слишком сильно любит ИИ(в том числе он любит фантомить). Утверждать, что это ИИ не стану т.к в оригинальной статье данные тире есть, но это сразу бросаетсяв глаза.
В любом случае лайк уж поставлю за отсылку к оригинальной статье и за распространение в РУ сегменте(я об этой статье незнал даже, ведь как то из уст в уста информация бегает) - вполне себе полезно(как ссылка на другие источники), удачи вам!
Хочу поблагодарить всех, кто следил за статьёй, а также новых читателей. Сообщаю, что больше не планирую её поддерживать: основные и наиболее интересные(даже сверх этого, ведь подобного материала сам не встречал), на мой взгляд, темы уже разобраны.
Материал потребовал большой работы, поэтому буду благодарен за поддержку - будь то продвижение статьи, подписка или комментарий.
Как применять эту информацию дальше - остаётся на ваше усмотрение. Если остались вопросы, задавайте их в комментариях. Всем удачи!
Статус:
Выполнено углубление по каждой подтеме, далее постепенно начнётся финальная сборка и завершение статьи.
Текущий статус:
По пунктам 1-3 уже внесены первые изменения, однако пока они носят базовый и поверхностный характер.
Следующий этап:
- Углубить каждое из направлений: доработать реализацию, повысить качество структуры и сделать примеры более содержательными, детальными и практически полезными.
Статья будет постепенно расширяться, дополняться и улучшаться, пока сохраняется мотивация заниматься этим - а она есть. Поэтому, если вам интересно следить за прогрессом, рекомендую добавить страницу в закладки*.
Пока в приоритете следующие задачи:
добавить сворачиваемые блоки для кода (чтобы их можно было удобно скрывать и раскрывать для лучшей читаемости);
сделать темы статьи более «звучащими» и структурированными;
расширить примеры и сделать их более конкретными и наглядными.