Локалка | Статьи для IT-специалистов - сохраняем лучшие статьи по программированию и администрированию в удобном для чтения формате
@Local_Area_Network
@Local_Area_Network
TDD или зачем писать тесты
TDD расшифровывается как test driven development, разработка через тестирование. Что это такое расскажу ниже, для начала пара вводных слов о самих тестах.
Прежде всего, что такое тест? Тест - это код, который проверяет, что наша программа работает правильно.
Думаю, любой без исключения разработчик хоть раз в жизни ленился писать тесты. А новички часто и вовсе сомневаются, что тесты нужны, но это потому что они еще не успели наступить на грабли и убедиться на собственных ошибках, что без тестов ошибки бывают гораздо больнее, чем с ними.
Когда мы ленимся написать тест, мы делаем так, потому что нам кажется, что в нашей программе нет никаких ошибок. И мы доверяем этому «кажется». Но представьте, что будет, если, например, при создании лекарства его создатели будут полагаться это чувство: «нам кажется, лекарство не вредное и работает», а клинических испытаний проводить не будут. Или если создатели самолётов будут просто верить, что «он летает», и никак это не проверять.
С программированием риски часто не настолько высоки, от многих программ не зависит ничья жизнь, но и тут ошибки могут привести к тому, что, например, у пользователя спишут со счета неправильную сумму денег, а это уже неприятно, и за такую работу вас никто не похвалит.
Поэтому с кодом, по большому счету, мы поступаем так же, как с лекарствами: только после испытаний мы можем утверждать, что код работает.
TDD расшифровывается как test driven development, разработка через тестирование. Что это такое расскажу ниже, для начала пара вводных слов о самих тестах.
Прежде всего, что такое тест? Тест - это код, который проверяет, что наша программа работает правильно.
Думаю, любой без исключения разработчик хоть раз в жизни ленился писать тесты. А новички часто и вовсе сомневаются, что тесты нужны, но это потому что они еще не успели наступить на грабли и убедиться на собственных ошибках, что без тестов ошибки бывают гораздо больнее, чем с ними.
Когда мы ленимся написать тест, мы делаем так, потому что нам кажется, что в нашей программе нет никаких ошибок. И мы доверяем этому «кажется». Но представьте, что будет, если, например, при создании лекарства его создатели будут полагаться это чувство: «нам кажется, лекарство не вредное и работает», а клинических испытаний проводить не будут. Или если создатели самолётов будут просто верить, что «он летает», и никак это не проверять.
С программированием риски часто не настолько высоки, от многих программ не зависит ничья жизнь, но и тут ошибки могут привести к тому, что, например, у пользователя спишут со счета неправильную сумму денег, а это уже неприятно, и за такую работу вас никто не похвалит.
Поэтому с кодом, по большому счету, мы поступаем так же, как с лекарствами: только после испытаний мы можем утверждать, что код работает.
...Теперь к вопросу о TDD. Постараюсь, как обычно, не закапываться вглубь этой методологии, а пробежаться по верхам.
Основное в TDD - тесты мы пишем до того, как пишем/меняем код самой программы. И очень часто их запускам - после любого изменения программы.
Приведу пример. Нам нужна функция, которая будет считать стоимость товаров в Интернет-магазине. Нам известна номинальная стоимость товара, но реальная стоимость будет посчитана по какой-то хитрой формуле. Для простоты предположим, что в нашем магазине все товары продаются по цене в 2 раза большей, чем их номинальная стоимость. Наша будущая функция будет называться calculate_price() и она будет принимать как аргумент номинальную стоимость.
Начнём с элементарного теста для этой функции. Если товар стоит 100 рублей номинально, мы его будем продавать за 200. Если он стоит 0, то и цена будет бесплатной:
После этого напишем саму функцию. В целях демонстрации она будет максимально простой:
Теперь мы можем запустить тест, и он отработает как нужно, если, конечно, мы нигде не ошиблись. Первая версия программы готова.
Внесение изменения
Предположим, через какое-то время нам не нравится код нашей функции, и мы решили переписать его более красиво. При этом все цены должны остаться такими же. Тут мы должны помнить, что даже минимальное изменение в коде может сломать программу. Даже когда мы уверены, что точно нигде не ошиблись. После каждого минимального, микроскопического изменения в коде
Обнаружен баг
Один покупатель в нашем Интернет-магазине оформлял заказ, и увидел, что товар стоит -200 рублей. Так мы узнаём, что наша функция может возвращать отрицательные значения. С чего мы начнем исправлять эту ошибку? Поменяем функцию
Теперь запускаем этот тест, чтобы убедиться, что он возвращает ошибку. Если тест не падает, а баг есть, значит тест написан неправильно и надо его переписать. Затем мы переписываем уже саму функцию и снова запускаем тест - на этот раз тест должен завершиться без ошибок.
Изменение логики функции
Предположим, цены в нашем магазине изменились, и теперь все товары стоят в 2 раза больше номинальной стоимости + наценка 20% от номинальной стоимости. Что мы поменяем первым делом, чтобы реализовать эту логику? Правильно, тест.
Запускаем тест, убеждаемся, что он возвращает ошибку, и переделываем саму функцию, чтобы она теперь считала стоимость по-новому.
Вот так примерно выглядит разработка по методике TDD.
Основное в TDD - тесты мы пишем до того, как пишем/меняем код самой программы. И очень часто их запускам - после любого изменения программы.
Приведу пример. Нам нужна функция, которая будет считать стоимость товаров в Интернет-магазине. Нам известна номинальная стоимость товара, но реальная стоимость будет посчитана по какой-то хитрой формуле. Для простоты предположим, что в нашем магазине все товары продаются по цене в 2 раза большей, чем их номинальная стоимость. Наша будущая функция будет называться calculate_price() и она будет принимать как аргумент номинальную стоимость.
Начнём с элементарного теста для этой функции. Если товар стоит 100 рублей номинально, мы его будем продавать за 200. Если он стоит 0, то и цена будет бесплатной:
def test_calculate_price():
assert calculate_price(100) == 200assert calculate_price(0) == 0После этого напишем саму функцию. В целях демонстрации она будет максимально простой:
def calculate_price(nominal):
return nominal * 2Теперь мы можем запустить тест, и он отработает как нужно, если, конечно, мы нигде не ошиблись. Первая версия программы готова.
Внесение изменения
Предположим, через какое-то время нам не нравится код нашей функции, и мы решили переписать его более красиво. При этом все цены должны остаться такими же. Тут мы должны помнить, что даже минимальное изменение в коде может сломать программу. Даже когда мы уверены, что точно нигде не ошиблись. После каждого минимального, микроскопического изменения в коде
calculate_price, мы заново запускаем наш тест, и проверяем, не сломали ли программу.Обнаружен баг
Один покупатель в нашем Интернет-магазине оформлял заказ, и увидел, что товар стоит -200 рублей. Так мы узнаём, что наша функция может возвращать отрицательные значения. С чего мы начнем исправлять эту ошибку? Поменяем функцию
calculate_price ? Нет, первым делом нужно доработать тесты. Раз в программе есть баг, значит тесты должны его отлавливать. Предположим, мы хотим, чтобы наша функция возвращала None, если мы передаём ей отрицательную номинальную цену. Добавим в наш тест проверку на работу с отрицательными числами:def test_calculate_price():
assert calculate_price(-100) is NoneТеперь запускаем этот тест, чтобы убедиться, что он возвращает ошибку. Если тест не падает, а баг есть, значит тест написан неправильно и надо его переписать. Затем мы переписываем уже саму функцию и снова запускаем тест - на этот раз тест должен завершиться без ошибок.
Изменение логики функции
Предположим, цены в нашем магазине изменились, и теперь все товары стоят в 2 раза больше номинальной стоимости + наценка 20% от номинальной стоимости. Что мы поменяем первым делом, чтобы реализовать эту логику? Правильно, тест.
def test_calculate_price():
assert calculate_price(100) == 220
# и так далееЗапускаем тест, убеждаемся, что он возвращает ошибку, и переделываем саму функцию, чтобы она теперь считала стоимость по-новому.
Вот так примерно выглядит разработка по методике TDD.
✅ Хотим обратить ваше внимание на полезный telegram-канал для обучения высокоуровневому языку программирования Python
На канале ежедневно публикуются задачи по Python и Machine Learning: алгоритмы, функции, классы, регулярные выражения, итераторы, генераторы, ООП, исключения, numpy, pandas, matplotlib, scikit-learn, TensorFlow и многое другое!
✔️Станьте специалистом по Python вместе с каналом "Задачи по Python и машинному обучению"
На канале ежедневно публикуются задачи по Python и Machine Learning: алгоритмы, функции, классы, регулярные выражения, итераторы, генераторы, ООП, исключения, numpy, pandas, matplotlib, scikit-learn, TensorFlow и многое другое!
✔️Станьте специалистом по Python вместе с каналом "Задачи по Python и машинному обучению"
#вашивопросы
Есть ли у меня перспективы роста, если в моей компании я делаю очень разноплановые и малосвязанные между собою задачи?
Уже восемь месяцев я работаю джуниор-пайтон-разработчиком. Моя компания хорошо ко мне относится, но она очень маленькая, я бы сказала крошечная (8 человек). У меня нет отдельного ментора, но сотрудники в целом охотно отвечают на мои вопросы.
В то же время меня смущают две вещи: во-первых, у меня достаточно разные задачи, и большинство из них не связаны между собой. То есть в одном месте я больше с Фласком копаюсь, в другом с запросами в БД, в третьем вообще со стилями в CSS.
И я вот замечаю, что за это время работы в компании у меня появился опыт, конечно, и понимание, как работает большая система, но в то же время я не могу сказать, что научилась что-то делать самостоятельно. То есть через несистематичность подхода в задачах (мне дают какую-то поточку, хотя она нередко объемная, и у меня занимает много времени просто въехать в задачу) мне трудно овладеть чем-то и уже за это держаться.
И в то же время я бы не хотела учиться в нерабочее время, потому что это мне не кажется продуктивным. Да и даже я не знаю, чему именно учиться: конечно, у меня есть мой чеклист собственных пробелов, но мне сложно допроходить какую-то тему, когда мое текущее задание совсем с ней не связано.
То есть у тебя я бы хотела спросить, это проблема в моем подходе — или же проблема компании? Если это проблема моего подхода, что бы ты мне посоветовала для систематизации знаний? Если это проблема в компании, как и что со своей стороны я могу прокомунницировать?
Мне просто хочется понять, вообще перспективно ли быть в этой компании — и главным образом меня сейчас знания и навыки интересуют. И так же хочется понять, что если это больше моя ответственность, то как изменить подход.
Ответ в следующем посте.
Есть ли у меня перспективы роста, если в моей компании я делаю очень разноплановые и малосвязанные между собою задачи?
Уже восемь месяцев я работаю джуниор-пайтон-разработчиком. Моя компания хорошо ко мне относится, но она очень маленькая, я бы сказала крошечная (8 человек). У меня нет отдельного ментора, но сотрудники в целом охотно отвечают на мои вопросы.
В то же время меня смущают две вещи: во-первых, у меня достаточно разные задачи, и большинство из них не связаны между собой. То есть в одном месте я больше с Фласком копаюсь, в другом с запросами в БД, в третьем вообще со стилями в CSS.
И я вот замечаю, что за это время работы в компании у меня появился опыт, конечно, и понимание, как работает большая система, но в то же время я не могу сказать, что научилась что-то делать самостоятельно. То есть через несистематичность подхода в задачах (мне дают какую-то поточку, хотя она нередко объемная, и у меня занимает много времени просто въехать в задачу) мне трудно овладеть чем-то и уже за это держаться.
И в то же время я бы не хотела учиться в нерабочее время, потому что это мне не кажется продуктивным. Да и даже я не знаю, чему именно учиться: конечно, у меня есть мой чеклист собственных пробелов, но мне сложно допроходить какую-то тему, когда мое текущее задание совсем с ней не связано.
То есть у тебя я бы хотела спросить, это проблема в моем подходе — или же проблема компании? Если это проблема моего подхода, что бы ты мне посоветовала для систематизации знаний? Если это проблема в компании, как и что со своей стороны я могу прокомунницировать?
Мне просто хочется понять, вообще перспективно ли быть в этой компании — и главным образом меня сейчас знания и навыки интересуют. И так же хочется понять, что если это больше моя ответственность, то как изменить подход.
Ответ в следующем посте.
[Ответ на вопрос из поста выше]
...Если я верно поняла, проблема заключается в том, что у вас слишком дробные, разрозненные задачи. По сути это ключевое отличие джуниор-разработчика от миддла и выше: джунам часто дают какие-то мелкие кусочки задач, и часто даже не разъясняют, какой более большой цели это служит (и это не совсем грамотный подход).
То есть, пример формулирования задачи для джуна: «Добавь в базу данных таблицы user новый столбец last_seen_at, дата самого последнего посещения». И всё. Никаких разъяснений - зачем нужен этот столбец? Как он будет использоваться? Какую задачу это решает? Просто вот тебе задача, выполняй. То есть, дают коммуникацию, что делать, и как это делать, но не объясняют, зачем. Я не знаю, похоже ли это на ваш случай, подумайте об этом.
Пример задачи для специалиста middle и выше: «Если пользователь не посещал сайт больше недели, мы хотим присылать ему Push-уведомление о том, что для него действует персональная скидка.» Дальше разработчик уже декомпозирует задачу (один или вместе с коллегами), и придумывает сам, как он это будет делать. В частности, он решает, что в базе данных нужно хранить дату последнего посещения сайта пользователем. Но это лишь одна из подзадач.
То, что в одной задаче вы работаете с БД, в другой с фласком, в третьей еще с чем-то - это не особо проблема, на мой взгляд. В будущем вам бы хорошо прийти в ту точку, где в одной задаче вы будете работать одновременно и с базой данных, и с Flask, и возможно еще с несколькими технологиями - всё это всего лишь инструменты, важно уметь их подбирать так, чтобы они решали поставленную задачу.
Если использовать метафоры, то задача для джуна (причем так себе сформулированная) - это «возьми молоток и ударь по этому гвоздю». Задача для зрелого специалиста - «собери шкаф». А задача для еще более верхнеуровнего специалиста, например, руководителя - «нам негде хранить бумаги. придумай что-нибудь». Чем круче специалист, тем менее детализирована задача.
Теперь к вопросу о том, что вам делать. Думаю, что коммуницировать с руководством. Во-первых, если вам не объясняют, какую задачу вы решаете и для чего вас попросили что-то сделать - всегда задавайте вопросы - зачем это нужно? Какую цель это решает? Получив большие информации, вы возможно сможете предложить решение получше того, которое вам дали на реализацию. Таким образом вы станете более вовлечены в планирование и обсуждение задач, как серьезный взрослый специалист.
Во-вторых, просите более крупные задачи, и сформулированные более верхнеуровнево. Такие, чтобы самостоятельно отвечать за гораздо более крупные куски, чем вы привыкли. Если ваши рукводители не стараются из вас вырастить более зрелого специалиста, значит вам нужно брать инициативу в свои руки.
А что касается обучения - действительно продуктивнее изучать те технологии, которые вам нужны для решения текущей задачи, чем что-то постороннее. Но и выделить время почитать что-то, укрепить базовые знания - тоже бывает полезно.
Задать вопрос автору блога можно здесь: @hum_it_bot
...Если я верно поняла, проблема заключается в том, что у вас слишком дробные, разрозненные задачи. По сути это ключевое отличие джуниор-разработчика от миддла и выше: джунам часто дают какие-то мелкие кусочки задач, и часто даже не разъясняют, какой более большой цели это служит (и это не совсем грамотный подход).
То есть, пример формулирования задачи для джуна: «Добавь в базу данных таблицы user новый столбец last_seen_at, дата самого последнего посещения». И всё. Никаких разъяснений - зачем нужен этот столбец? Как он будет использоваться? Какую задачу это решает? Просто вот тебе задача, выполняй. То есть, дают коммуникацию, что делать, и как это делать, но не объясняют, зачем. Я не знаю, похоже ли это на ваш случай, подумайте об этом.
Пример задачи для специалиста middle и выше: «Если пользователь не посещал сайт больше недели, мы хотим присылать ему Push-уведомление о том, что для него действует персональная скидка.» Дальше разработчик уже декомпозирует задачу (один или вместе с коллегами), и придумывает сам, как он это будет делать. В частности, он решает, что в базе данных нужно хранить дату последнего посещения сайта пользователем. Но это лишь одна из подзадач.
То, что в одной задаче вы работаете с БД, в другой с фласком, в третьей еще с чем-то - это не особо проблема, на мой взгляд. В будущем вам бы хорошо прийти в ту точку, где в одной задаче вы будете работать одновременно и с базой данных, и с Flask, и возможно еще с несколькими технологиями - всё это всего лишь инструменты, важно уметь их подбирать так, чтобы они решали поставленную задачу.
Если использовать метафоры, то задача для джуна (причем так себе сформулированная) - это «возьми молоток и ударь по этому гвоздю». Задача для зрелого специалиста - «собери шкаф». А задача для еще более верхнеуровнего специалиста, например, руководителя - «нам негде хранить бумаги. придумай что-нибудь». Чем круче специалист, тем менее детализирована задача.
Теперь к вопросу о том, что вам делать. Думаю, что коммуницировать с руководством. Во-первых, если вам не объясняют, какую задачу вы решаете и для чего вас попросили что-то сделать - всегда задавайте вопросы - зачем это нужно? Какую цель это решает? Получив большие информации, вы возможно сможете предложить решение получше того, которое вам дали на реализацию. Таким образом вы станете более вовлечены в планирование и обсуждение задач, как серьезный взрослый специалист.
Во-вторых, просите более крупные задачи, и сформулированные более верхнеуровнево. Такие, чтобы самостоятельно отвечать за гораздо более крупные куски, чем вы привыкли. Если ваши рукводители не стараются из вас вырастить более зрелого специалиста, значит вам нужно брать инициативу в свои руки.
А что касается обучения - действительно продуктивнее изучать те технологии, которые вам нужны для решения текущей задачи, чем что-то постороннее. Но и выделить время почитать что-то, укрепить базовые знания - тоже бывает полезно.
Задать вопрос автору блога можно здесь: @hum_it_bot
Стать программистом за 3 дня
«Невозможно», — могли подумать вы и были правы. Нельзя стать программистом за 3 дня, но разобраться, как устроен мир разработки и сделать к нему первые шаги — вполне реально.
На бесплатном трехдневном курсе Нетологии «Как стать программистом» вы узнаете, чего ждать от профессии разработчика, подходит ли она вам и как сделать самое сложное — начать.
Сделайте первый шаг к большим возможностям, а мы поможем двигаться дальше ↓
https://netolo.gy/heN
«Невозможно», — могли подумать вы и были правы. Нельзя стать программистом за 3 дня, но разобраться, как устроен мир разработки и сделать к нему первые шаги — вполне реально.
На бесплатном трехдневном курсе Нетологии «Как стать программистом» вы узнаете, чего ждать от профессии разработчика, подходит ли она вам и как сделать самое сложное — начать.
Сделайте первый шаг к большим возможностям, а мы поможем двигаться дальше ↓
https://netolo.gy/heN
#вашивопросы
Если у меня уже есть довольно большой стек технологий, стоит ли записываться на вакансии просто QA-тестировщика (например) или что-то оч низкой планки такой по отношению к стеку из-за страха, что не справлюсь?
Подробнее про стек:
Ну из основных, из языков и фреймворков, технологий, которые я знаю я знаю, ну мой стек т.е.: Python (довольно хорошо себя чувствую), Java (очень хорошо знаю), JS (начинаю учить), C++ (средне знаю, но постоянно подтягиваюсь в плюсах конкретно сейчас), SQL (средне), TypeScript (начинаю учить, но т.к. это как жс, то будет, думаю, проще), C# (начинаю учить, но схожесть с плюсами и джавой облегчают изучение неплохо так) […]
Ниже еще полстраницы навыков и скиллов, опускаю для краткости.
Дальше автор вопроса спрашивает, стоит ли ей идти в тестировщики или например в техподдержку.
Я в этом вопросе вижу большой страх искать работу разработчика, и этот страх заставляет человека прокрастинировать поиски и всячески от них уклоняться, в том числе искать обходные пути - например, устроиться на другую должность. При этом мы все склонны рационализировать свой страх, то есть придумывать кучу «рациональных» и «разумных причин» не делать то, чего мы боимся. Бесконечная учеба и перфекционизм тоже может быть видом прокрастинации.
У вас уже огромный список скиллов, даже для не новичка. Я не знаю, насколько глубоки знания каждой технологии у вас, но «в ширину» список впечатляет. И на этом этапе мне уже не совсем ясно, зачем продолжать расширять этот список, вместо того, чтобы идти и применять свои знания. Просто в качестве хобби? Или всё же учеба - это способ прокрастинации?
Чтобы преодолеть страх, нельзя позволять ему принимать решения за вас и вести куда-то за собой. Идти нужно туда, где страшно. Страх поначалу никуда не денется, так что придется просто нести его с собой. :) Чтобы было развитие, нужны задачи чуть сложнее, чем вам было бы комфортно. Если делать только то, что привычно и легко - никакого роста и не будет.
Отвечая на вопрос: в QA идите в том случае, если вы планируете карьеру тестировщика, а не разработчика. В техподдержку вообще не ходите, там не нужна техническая подготовка - это чаще всего вакансии без особых требований к техническим знаниям и скиллам.
Хочу, чтобы по времени такая реальная работа не занимала всё время, т.к. хочу продолжать изучать много чего ещё из своего чек-листа для себя и ещё заниматься совместно с друзьями проектом/начать делать свой один. И помимо просто изучения языков и прочего для себя из своих планов, я сплю около 13-15 часов, чтобы чувствовать себя хорошо + ещё общаться просто с друзьями и заниматься чем-то своим за день нужно. Ну то есть, я не выхожу никуда из дома почти никогда, но при этом времени у меня сейчас и так не особо много и много чего делать нужно.
Что касается желания иметь много свободного времени, я сомневаюсь, что реально всё вот так совмещать, как вам бы хотелось. С full-time работой, вероятнее всего, так не получится. Всё же работа диктует свой график, и работодатели не станут подстраиваться под вас. Но раз у вас есть желание усидеть на двух стульях (то есть учиться, работать и иметь кучу свободного времени) - поищите какие-нибудь стажировки с частичной занятостью, скажем на 2 дня в неделю.
И хочу именно удалёнку, нет, я знаю, что поначалу лучше не работать удалённо, но у меня проблемы в общении голосом, а предпочтение текстом/с трудом в дисе том же или ещё где общаться в принципе могу, ну и ещё времени жалко и сидеть в офисе это в принципе для меня ад, я не люблю работу в дефолтном её понимании как офисную и потом домой идти, просто ненавижу подобное.
Про удалёнку - опять-таки - тут всё зависит от готовности работодателей вам предоставить именно такую работу. Если сможете найти именно такой идеальный для вас вариант - хорошо. Но будьте готовы, что условия игры на начальном этапе диктует работодатель.
Задать вопрос автору блога можно здесь: @hum_it_bot
Если у меня уже есть довольно большой стек технологий, стоит ли записываться на вакансии просто QA-тестировщика (например) или что-то оч низкой планки такой по отношению к стеку из-за страха, что не справлюсь?
Подробнее про стек:
Ну из основных, из языков и фреймворков, технологий, которые я знаю я знаю, ну мой стек т.е.: Python (довольно хорошо себя чувствую), Java (очень хорошо знаю), JS (начинаю учить), C++ (средне знаю, но постоянно подтягиваюсь в плюсах конкретно сейчас), SQL (средне), TypeScript (начинаю учить, но т.к. это как жс, то будет, думаю, проще), C# (начинаю учить, но схожесть с плюсами и джавой облегчают изучение неплохо так) […]
Ниже еще полстраницы навыков и скиллов, опускаю для краткости.
Дальше автор вопроса спрашивает, стоит ли ей идти в тестировщики или например в техподдержку.
Я в этом вопросе вижу большой страх искать работу разработчика, и этот страх заставляет человека прокрастинировать поиски и всячески от них уклоняться, в том числе искать обходные пути - например, устроиться на другую должность. При этом мы все склонны рационализировать свой страх, то есть придумывать кучу «рациональных» и «разумных причин» не делать то, чего мы боимся. Бесконечная учеба и перфекционизм тоже может быть видом прокрастинации.
У вас уже огромный список скиллов, даже для не новичка. Я не знаю, насколько глубоки знания каждой технологии у вас, но «в ширину» список впечатляет. И на этом этапе мне уже не совсем ясно, зачем продолжать расширять этот список, вместо того, чтобы идти и применять свои знания. Просто в качестве хобби? Или всё же учеба - это способ прокрастинации?
Чтобы преодолеть страх, нельзя позволять ему принимать решения за вас и вести куда-то за собой. Идти нужно туда, где страшно. Страх поначалу никуда не денется, так что придется просто нести его с собой. :) Чтобы было развитие, нужны задачи чуть сложнее, чем вам было бы комфортно. Если делать только то, что привычно и легко - никакого роста и не будет.
Отвечая на вопрос: в QA идите в том случае, если вы планируете карьеру тестировщика, а не разработчика. В техподдержку вообще не ходите, там не нужна техническая подготовка - это чаще всего вакансии без особых требований к техническим знаниям и скиллам.
Хочу, чтобы по времени такая реальная работа не занимала всё время, т.к. хочу продолжать изучать много чего ещё из своего чек-листа для себя и ещё заниматься совместно с друзьями проектом/начать делать свой один. И помимо просто изучения языков и прочего для себя из своих планов, я сплю около 13-15 часов, чтобы чувствовать себя хорошо + ещё общаться просто с друзьями и заниматься чем-то своим за день нужно. Ну то есть, я не выхожу никуда из дома почти никогда, но при этом времени у меня сейчас и так не особо много и много чего делать нужно.
Что касается желания иметь много свободного времени, я сомневаюсь, что реально всё вот так совмещать, как вам бы хотелось. С full-time работой, вероятнее всего, так не получится. Всё же работа диктует свой график, и работодатели не станут подстраиваться под вас. Но раз у вас есть желание усидеть на двух стульях (то есть учиться, работать и иметь кучу свободного времени) - поищите какие-нибудь стажировки с частичной занятостью, скажем на 2 дня в неделю.
И хочу именно удалёнку, нет, я знаю, что поначалу лучше не работать удалённо, но у меня проблемы в общении голосом, а предпочтение текстом/с трудом в дисе том же или ещё где общаться в принципе могу, ну и ещё времени жалко и сидеть в офисе это в принципе для меня ад, я не люблю работу в дефолтном её понимании как офисную и потом домой идти, просто ненавижу подобное.
Про удалёнку - опять-таки - тут всё зависит от готовности работодателей вам предоставить именно такую работу. Если сможете найти именно такой идеальный для вас вариант - хорошо. Но будьте готовы, что условия игры на начальном этапе диктует работодатель.
Задать вопрос автору блога можно здесь: @hum_it_bot
Программирование для гуманитариев
#вашивопросы Если у меня уже есть довольно большой стек технологий, стоит ли записываться на вакансии просто QA-тестировщика (например) или что-то оч низкой планки такой по отношению к стеку из-за страха, что не справлюсь? Подробнее про стек: Ну из основных…
UPD: тут мне пишут, что я несправедлива по отношению к техподдержке, когда пишу, что что им не нужны технические знания и скиллы.
Стоит отметить, что как и с остальными должностями под техподдержкой в разных компаниях могут понимать разное. В одних случаях речь идёт о специалисте без каких-либо технических навыков и опыта, от которого требуется только вежливо общаться с клиентами, отвечать им по скрипту и направлять информацию о неполадках (например, о багах) техническим специалистам для решения. То есть по сути это сотрудник коллцентра, но не инженер и тем более не программист. Я имела в виду именно такой случай.
В других случаях под техподдержкой понимают инженеров, которые непосредственно решают проблемы, на которые жалуются пользователи. Но в этом случае речь идёт уже не о начинающих специалистах, а об опытных админах или сотрудниках эксплуатации (Ops, DevOps - в зависимости от компании).
Иногда техподдержка - это стартовая должность для будущих админов или инженеров (а иногда и аналитиков) - в таком случае человек вначале работает в коллцентре или на письмах клиентов, но постепенно вкулючается в более технические задачи и с ростом опыта его должность становится всё более технической.
В общем, как водится, везде всё по-разному.
Стоит отметить, что как и с остальными должностями под техподдержкой в разных компаниях могут понимать разное. В одних случаях речь идёт о специалисте без каких-либо технических навыков и опыта, от которого требуется только вежливо общаться с клиентами, отвечать им по скрипту и направлять информацию о неполадках (например, о багах) техническим специалистам для решения. То есть по сути это сотрудник коллцентра, но не инженер и тем более не программист. Я имела в виду именно такой случай.
В других случаях под техподдержкой понимают инженеров, которые непосредственно решают проблемы, на которые жалуются пользователи. Но в этом случае речь идёт уже не о начинающих специалистах, а об опытных админах или сотрудниках эксплуатации (Ops, DevOps - в зависимости от компании).
Иногда техподдержка - это стартовая должность для будущих админов или инженеров (а иногда и аналитиков) - в таком случае человек вначале работает в коллцентре или на письмах клиентов, но постепенно вкулючается в более технические задачи и с ростом опыта его должность становится всё более технической.
В общем, как водится, везде всё по-разному.
Программирование для гуманитариев
#вашивопросы Если у меня уже есть довольно большой стек технологий, стоит ли записываться на вакансии просто QA-тестировщика (например) или что-то оч низкой планки такой по отношению к стеку из-за страха, что не справлюсь? Подробнее про стек: Ну из основных…
Дополнение от подписчиков:
На счёт поста про стоит ли идти в тестеры или саппорт вместо разработки: хочется добавить что, возможно, автор письма предполагает, что там меньше нагрузок, поэтому можно работать меньше часов.
По факту же это обычные работы которые предполагают такую же 8 часовую занятость, как у разработчика. А иногда даже и с большим перегрузом: например тестировщик перед релизом может очень сильно перерабатывать если разработчик отдал проект с несдвигаемой датой релиза очень поздно.
На счёт поста про стоит ли идти в тестеры или саппорт вместо разработки: хочется добавить что, возможно, автор письма предполагает, что там меньше нагрузок, поэтому можно работать меньше часов.
По факту же это обычные работы которые предполагают такую же 8 часовую занятость, как у разработчика. А иногда даже и с большим перегрузом: например тестировщик перед релизом может очень сильно перерабатывать если разработчик отдал проект с несдвигаемой датой релиза очень поздно.
Как искать ошибки в коде
Мне достаточно часто присылают в бота вопрос: «А где у меня тут ошибка?» и дальше целая страница кода.
В целом такая постановка вопроса выглядит достаточно наивной, так как новичкам кажется, что более опытному разработчику будет легко найти ошибку в любом случайном и совершенно незнакомом куске кода.
На самом деле же поиск ошибки даже в своём собственном коде - это порой самая долгая и муторная часть работы. В худших случаях поиск ошибок и отлаживание кода занимает 90% всего времени разработчика. Еще сложнее найти ошибку в чужом коде, который видишь в первый раз в жизни. Даже в коде, который просто и понятно написан.
А новички чаще всего пишут ну очень сложный и запутанный код - его даже прочитать и понять с третьей попытки сложно, не то что найти там ошибку. Поэтому, когда вопрос звучит: «А где у меня тут ошибка» - это на разработческий язык переводится как: «Привет! Сделай, пожалуйста за меня 90% работы - ну у тебя же есть лишний час времени, правда?».
Но это лирическое вступление. А пост о том, как искать ошибки в коде.
Из всего того, что вы мне присылаете в бота, я могу сделать один основной вывод: новички часто не понимают код, который сами же написали. И, что еще хуже - даже не стремятся его понять, надеются, что и так сойдет. В итоге всё, что вы используете в коде - циклы, переменные, списки/массивы - используется как-то наугад, без четкого понимания, как это вообще работает. Ну и, естественно, часто такой подход не даёт ожидаемого результата.
Поэтому если ваш код работает не так, как хочется, первое что надо сделать - убедиться, что вы его понимаете. Каждая строчка, каждое действие в нем должно иметь для вас смысл. Если вы не до конца понимаете, как работает ваш цикл - скорее всего, из-за этого код и не получился. И уж точно не надо пытаться что-то наугад поменять в коде и надеяться, что он заработает.
В принципе, если вы понимаете каждую строчку своего кода, значит в нём действительно нет ошибок. В идеальном мире. В реальности мы можем в упор не замечать какую-то опечатку или неверное действие. Поэтому чтобы найти ошибку - хорошо бы сформулировать гипотезу, и даже несколько. Где я мог ошибиться? И, в идеале, написать тест, который либо опровергнет, либо подтвердит гипотезу (про тесты тут было 2 поста). Увидев, что гипотеза подтверждается, и тест её показывает - исправляем ошибку, и убеждаемся, что теперь тест проходит без ошибки.
Также для отладки кода существуют специальные удобные инструменты - дебаггеры или отладчики, они часто встроены в IDE. Эти инструменты позволяют запустить код с любого места (и в любом месте приостановить его выполнение), и проследить каждый шаг, который выполняет код, посмотреть на значение каждой переменной в любой момент времени. Таким образом, медленно, но верно, можно увидеть, где программа идёт не по тому пути, по которому она должна идти и наконец добиться того, о чем я говорила на первом шаге - идеального понимания, как работает ваша программа, вплоть до каждого шага.
Есть и множество других приёмов - например, добавить в разных местах кода вызовы print, чтобы вывести информацию на экран, и по ней понять, где в коде ошибка. Можно удалять поочередно куски кода и запускать код без них - и смотреть, появляется ли ошибка - так можно будет понять, в каком месте она возникла, а какие куски кода работают верно. В общем, таких приёмов можно придумать массу, но начните с главного - убедитесь, что вы понимаете код, который пишете. Иначе в дальнейшей учебе или работе просто нет смысла, программирование - это не магия.
Мне достаточно часто присылают в бота вопрос: «А где у меня тут ошибка?» и дальше целая страница кода.
В целом такая постановка вопроса выглядит достаточно наивной, так как новичкам кажется, что более опытному разработчику будет легко найти ошибку в любом случайном и совершенно незнакомом куске кода.
На самом деле же поиск ошибки даже в своём собственном коде - это порой самая долгая и муторная часть работы. В худших случаях поиск ошибок и отлаживание кода занимает 90% всего времени разработчика. Еще сложнее найти ошибку в чужом коде, который видишь в первый раз в жизни. Даже в коде, который просто и понятно написан.
А новички чаще всего пишут ну очень сложный и запутанный код - его даже прочитать и понять с третьей попытки сложно, не то что найти там ошибку. Поэтому, когда вопрос звучит: «А где у меня тут ошибка» - это на разработческий язык переводится как: «Привет! Сделай, пожалуйста за меня 90% работы - ну у тебя же есть лишний час времени, правда?».
Но это лирическое вступление. А пост о том, как искать ошибки в коде.
Из всего того, что вы мне присылаете в бота, я могу сделать один основной вывод: новички часто не понимают код, который сами же написали. И, что еще хуже - даже не стремятся его понять, надеются, что и так сойдет. В итоге всё, что вы используете в коде - циклы, переменные, списки/массивы - используется как-то наугад, без четкого понимания, как это вообще работает. Ну и, естественно, часто такой подход не даёт ожидаемого результата.
Поэтому если ваш код работает не так, как хочется, первое что надо сделать - убедиться, что вы его понимаете. Каждая строчка, каждое действие в нем должно иметь для вас смысл. Если вы не до конца понимаете, как работает ваш цикл - скорее всего, из-за этого код и не получился. И уж точно не надо пытаться что-то наугад поменять в коде и надеяться, что он заработает.
В принципе, если вы понимаете каждую строчку своего кода, значит в нём действительно нет ошибок. В идеальном мире. В реальности мы можем в упор не замечать какую-то опечатку или неверное действие. Поэтому чтобы найти ошибку - хорошо бы сформулировать гипотезу, и даже несколько. Где я мог ошибиться? И, в идеале, написать тест, который либо опровергнет, либо подтвердит гипотезу (про тесты тут было 2 поста). Увидев, что гипотеза подтверждается, и тест её показывает - исправляем ошибку, и убеждаемся, что теперь тест проходит без ошибки.
Также для отладки кода существуют специальные удобные инструменты - дебаггеры или отладчики, они часто встроены в IDE. Эти инструменты позволяют запустить код с любого места (и в любом месте приостановить его выполнение), и проследить каждый шаг, который выполняет код, посмотреть на значение каждой переменной в любой момент времени. Таким образом, медленно, но верно, можно увидеть, где программа идёт не по тому пути, по которому она должна идти и наконец добиться того, о чем я говорила на первом шаге - идеального понимания, как работает ваша программа, вплоть до каждого шага.
Есть и множество других приёмов - например, добавить в разных местах кода вызовы print, чтобы вывести информацию на экран, и по ней понять, где в коде ошибка. Можно удалять поочередно куски кода и запускать код без них - и смотреть, появляется ли ошибка - так можно будет понять, в каком месте она возникла, а какие куски кода работают верно. В общем, таких приёмов можно придумать массу, но начните с главного - убедитесь, что вы понимаете код, который пишете. Иначе в дальнейшей учебе или работе просто нет смысла, программирование - это не магия.
#вашивопросы
Добрый день, если говорить про тестирование то сейчас наблюдается ажиотаж вокруг этой профессии, нужно ли знание математики, или лучше пойти в devops?
В этом вопросе как-то смешалось всё в кучу.
Ажиотаж вокруг профессии тестировщиков может быть потому, что в эту профессию относительно низкий порог входа (или так считается). А «замахиваться» на профессию, например, программиста, людям кажется чем-то более страшным. Ну и определенную роль в этом играет обилие всевозможных курсов для тестировщиков.
Знания математики от тестировщиков не требуют, как и от DevOps.
А какую профессию вам лучше выбрать зависит только от ваших личных предпочтений. Если сфера DevOps вам кажется более привлекательной, то я бы начала с навыков системного администрирования. Курсы DevOps, конечно, никому не навредят, но в моем субъективном представлении в девопс работать идут люди, уже имеющие опыт системного администрирования.
Я хочу быть скрам мастером, как мне попасть на работу?
Для тех, кто «не в теме» - Scrum - это одна из разновидностей Agile - «гибкая» методология по организации работы внутри команды. В Scrum у каждого есть своя роль, и, в частности, существует такая роль как скрам-мастер - это человек, отвечающий за соблюдение всех правил Scrum внутри команды, и за проведение «церемоний», принятых в скраме. Также этот человек может отвечать за внедрение методики Scrum в команду, и обучение «скраму» команды.
Так, что самое очевидное, что требуется от такого человека - это хорошее знание Scruma - этому можно поучиться по книгам, на курсах и тренингах.
А что касается трудоустройства, тут уже могут быть нюансы - когда речь идёт об околоменджерских профессиях в IT, работодатели могут отдавать предпочтение человеку, у которого уже есть какой-то опыт работы в этой сфере - пусть и в какой-нибудь другой роли, например, бизнес-аналитика. Поэтому получается нечто вроде рекурсии: «чтобы найти работу в IT, нужно для начала поработать в IT». Поэтому желательно использовать любую возможность, чтобы приобрести хоть какой-то релевантный опыт работы и знания - разобраться, как устроен цикл разработки ПО в целом, какие там есть этапы, какие специалисты в каких ролях в этом участвуют, как в целом выглядит типичная IT-компания и ее оргструктура. Но думаю, просто менеджерский бэкграунд за пределами IT, если он у вас имеется - это уже лучше, чем ничего.
Задать вопрос автору блога можно здесь: @hum_it_bot
Добрый день, если говорить про тестирование то сейчас наблюдается ажиотаж вокруг этой профессии, нужно ли знание математики, или лучше пойти в devops?
В этом вопросе как-то смешалось всё в кучу.
Ажиотаж вокруг профессии тестировщиков может быть потому, что в эту профессию относительно низкий порог входа (или так считается). А «замахиваться» на профессию, например, программиста, людям кажется чем-то более страшным. Ну и определенную роль в этом играет обилие всевозможных курсов для тестировщиков.
Знания математики от тестировщиков не требуют, как и от DevOps.
А какую профессию вам лучше выбрать зависит только от ваших личных предпочтений. Если сфера DevOps вам кажется более привлекательной, то я бы начала с навыков системного администрирования. Курсы DevOps, конечно, никому не навредят, но в моем субъективном представлении в девопс работать идут люди, уже имеющие опыт системного администрирования.
Я хочу быть скрам мастером, как мне попасть на работу?
Для тех, кто «не в теме» - Scrum - это одна из разновидностей Agile - «гибкая» методология по организации работы внутри команды. В Scrum у каждого есть своя роль, и, в частности, существует такая роль как скрам-мастер - это человек, отвечающий за соблюдение всех правил Scrum внутри команды, и за проведение «церемоний», принятых в скраме. Также этот человек может отвечать за внедрение методики Scrum в команду, и обучение «скраму» команды.
Так, что самое очевидное, что требуется от такого человека - это хорошее знание Scruma - этому можно поучиться по книгам, на курсах и тренингах.
А что касается трудоустройства, тут уже могут быть нюансы - когда речь идёт об околоменджерских профессиях в IT, работодатели могут отдавать предпочтение человеку, у которого уже есть какой-то опыт работы в этой сфере - пусть и в какой-нибудь другой роли, например, бизнес-аналитика. Поэтому получается нечто вроде рекурсии: «чтобы найти работу в IT, нужно для начала поработать в IT». Поэтому желательно использовать любую возможность, чтобы приобрести хоть какой-то релевантный опыт работы и знания - разобраться, как устроен цикл разработки ПО в целом, какие там есть этапы, какие специалисты в каких ролях в этом участвуют, как в целом выглядит типичная IT-компания и ее оргструктура. Но думаю, просто менеджерский бэкграунд за пределами IT, если он у вас имеется - это уже лучше, чем ничего.
Задать вопрос автору блога можно здесь: @hum_it_bot
#вашивопросы
Какие знания о разработке нужны среднестатистическому продакт менеджеру?
Моё мнение - продакт-менеджер не обязан быть программистом и уметь писать код. Это не его задача.
Но ему полезно знать о раработке как о процессе в целом - как выглядит цикл разработки, из каких этапов он состоит и зачем нужен каждый этап, сколько времени может занимать разработка фичи (или целого продукта), какие специалисты в этом процессе задействованы, и какова их роль. Что может пойти не так, застопорить процесс или вовсе привести к неудаче. То есть видеть разработку как менеджер. И при этом уметь понять, когда требования к продукту или срокам по его реализации - нереалистичны, или когда задача слишком трудозатратна, и её польза не может окупить такие высокие затраты на разработку.
Также полезно знать существующие подходы (методологии) по организации процесса разработки - например, чем «водопад» отличается от Agile, и какие разновидности Agile существуют.
Помимо этого нужны знания в области IT на уровне ликбеза. То есть вам не нужно самому/самой уметь писать и запускать сайты, мобильные приложения или программы. Но нужно понимать, что такое в принципе программа или приложение или веб-сайт. Например, как устроена в общих чертах клиент-серверная архитектура, что такое API, как примерно работает веб-сайт. Чем клиентская часть сайта отличается от серверной. Что такое база данных, и для чего она нужна. Итд итп.
Также продакт-менеджеры часто отличают за изучение метрик и аналитику по своим продуктам, поэтому вам могут пригодится навыки аналитика, в частности, умение делать SQL-запросы к базе данных, чтобы получать из нее данные для оценки и изучения.
Задать вопрос автору блога можно здесь: @hum_it_bot
Какие знания о разработке нужны среднестатистическому продакт менеджеру?
Моё мнение - продакт-менеджер не обязан быть программистом и уметь писать код. Это не его задача.
Но ему полезно знать о раработке как о процессе в целом - как выглядит цикл разработки, из каких этапов он состоит и зачем нужен каждый этап, сколько времени может занимать разработка фичи (или целого продукта), какие специалисты в этом процессе задействованы, и какова их роль. Что может пойти не так, застопорить процесс или вовсе привести к неудаче. То есть видеть разработку как менеджер. И при этом уметь понять, когда требования к продукту или срокам по его реализации - нереалистичны, или когда задача слишком трудозатратна, и её польза не может окупить такие высокие затраты на разработку.
Также полезно знать существующие подходы (методологии) по организации процесса разработки - например, чем «водопад» отличается от Agile, и какие разновидности Agile существуют.
Помимо этого нужны знания в области IT на уровне ликбеза. То есть вам не нужно самому/самой уметь писать и запускать сайты, мобильные приложения или программы. Но нужно понимать, что такое в принципе программа или приложение или веб-сайт. Например, как устроена в общих чертах клиент-серверная архитектура, что такое API, как примерно работает веб-сайт. Чем клиентская часть сайта отличается от серверной. Что такое база данных, и для чего она нужна. Итд итп.
Также продакт-менеджеры часто отличают за изучение метрик и аналитику по своим продуктам, поэтому вам могут пригодится навыки аналитика, в частности, умение делать SQL-запросы к базе данных, чтобы получать из нее данные для оценки и изучения.
Задать вопрос автору блога можно здесь: @hum_it_bot
#вашивопросы
Имею высшее образование с отличием в области машиностроения (инженерконструктор), им толком не пользовалась (на практике не зашло), знаю англ на уровне В1, хочу попробовать себя в IT (вроде склад ума позволяет). Не знаю, что для себя выбрать, с какого языка/ направления начать.
Поскольку вы пока не знаете, какое направление выбрать, можно его на этом этапе и не выбирать. Начните с курса «Введение в Computer Science», я для этих целей традиционно советую всем бесплатный гарвардский курс CS50. Там будут и азы программирования, и знакомство с несколькими языками, да и с областью в целом. Возможно, после него вам станет понятнее, в каком направлении интереснее развиваться, и какие яыки, к примеру, изучать.
Может у вас есть набор/список книг для изучения базового комьютер сайенса? Вот если люди идут учиться через вуз, то им там дают какую то базу с помощью книг тоже, какие для них считаются норм? В этой тонне существующих книг попробуй разбери - где вода, а где хорошо или шикарно
Тут, к сожалению, много не подскажу, так как я сама училась не по книгам, а по онлайн-курсам - мои «книги» - это coursera, edx, stepic, и сайты университетов (MIT, Stanford итд) c онлайн-курсами. Но список литературы, который рекомендуют студентам технических ВУЗов, думаю, нагуглить несложно. А если не гуглить - то спросить на каком-нибудь студенческом форуме.
Книг я вообще читала не так уж много, и чаще всего адресно по той теме, которая мне была нужна в тот момент по работе. Из общего могу всем рекомендовать книгу Макконнелла Совершенный код - но она не для начального уровня, а для людей, которые уже умеют программировать и имеют в этом хотя бы минимальный опыт.
Задать вопрос автору блога можно здесь: @hum_it_bot
Имею высшее образование с отличием в области машиностроения (инженерконструктор), им толком не пользовалась (на практике не зашло), знаю англ на уровне В1, хочу попробовать себя в IT (вроде склад ума позволяет). Не знаю, что для себя выбрать, с какого языка/ направления начать.
Поскольку вы пока не знаете, какое направление выбрать, можно его на этом этапе и не выбирать. Начните с курса «Введение в Computer Science», я для этих целей традиционно советую всем бесплатный гарвардский курс CS50. Там будут и азы программирования, и знакомство с несколькими языками, да и с областью в целом. Возможно, после него вам станет понятнее, в каком направлении интереснее развиваться, и какие яыки, к примеру, изучать.
Может у вас есть набор/список книг для изучения базового комьютер сайенса? Вот если люди идут учиться через вуз, то им там дают какую то базу с помощью книг тоже, какие для них считаются норм? В этой тонне существующих книг попробуй разбери - где вода, а где хорошо или шикарно
Тут, к сожалению, много не подскажу, так как я сама училась не по книгам, а по онлайн-курсам - мои «книги» - это coursera, edx, stepic, и сайты университетов (MIT, Stanford итд) c онлайн-курсами. Но список литературы, который рекомендуют студентам технических ВУЗов, думаю, нагуглить несложно. А если не гуглить - то спросить на каком-нибудь студенческом форуме.
Книг я вообще читала не так уж много, и чаще всего адресно по той теме, которая мне была нужна в тот момент по работе. Из общего могу всем рекомендовать книгу Макконнелла Совершенный код - но она не для начального уровня, а для людей, которые уже умеют программировать и имеют в этом хотя бы минимальный опыт.
Задать вопрос автору блога можно здесь: @hum_it_bot
#вашивопросы
Подскажите, пожалуйста, перенасыщен ли рынок джунами (например, Java)? Тяжело ли им найти работу, высокая ли у них конкуренция? Закрадываются мысли, что могут выбрать не тебя, а другого человека, который знает больше.
Как там дела с перенасыщением (или недосыщением) рынка неопытными кандидатами я вам не отвечу, так как давно не занималась подбором кандидатов, а подбором кандидатов-джавистов не занималась в принципе никогда.
Я знаю, что канал читают в том числе и HR-специалисты, и возможно, у них найдутся комментарии к этому вопросу? Присылайте в @hum_it_bot, интересные ответы опубликую в канале.
Что же касается мысли о том, что вместо вас могут выбрать другого кандидата - это действительно так, причём независимо от профессии, и независимо от вашего уровня опыта и знаний. Даже если бы вы были бы специалистом высочайшего уровня, всё равно всегда может найтись кто-то другой, кто больше понравится отдельно взятому работодателю. Но это не такая уж проблема, если вакансий на рынке много.
А компаний, где испольуют джаву и вакансий джава-разработчиков очень и очень много. Поэтому если вам откажут на первом (втором, пятом) собеседовании - продолжайте подавать резюме в другие компании, уровень требований к кандидатам и критерии отбора везде разные.
Также если собеседование закончилось отказом - обязательно собирайте обратную связь - что именно ребятам там не понравилось? Может быть, они подскажут вам, каких знаний по их мнению вам не хватает - сможете поработать над этими знаниями.
Также после неудачного собеседования, можно предложить такой вариант работодателю: вы подтянете знания, которых вам не хватает на их взгляд, и, скажем, через два-три месяца, снова придёте на собеседование в эту компанию. Таким образом вы покажете свою готовность учиться/развиваться, а также высокую мотивацию устроиться на работу в их компанию.
Задать вопрос автору блога можно здесь: @hum_it_bot
Подскажите, пожалуйста, перенасыщен ли рынок джунами (например, Java)? Тяжело ли им найти работу, высокая ли у них конкуренция? Закрадываются мысли, что могут выбрать не тебя, а другого человека, который знает больше.
Как там дела с перенасыщением (или недосыщением) рынка неопытными кандидатами я вам не отвечу, так как давно не занималась подбором кандидатов, а подбором кандидатов-джавистов не занималась в принципе никогда.
Я знаю, что канал читают в том числе и HR-специалисты, и возможно, у них найдутся комментарии к этому вопросу? Присылайте в @hum_it_bot, интересные ответы опубликую в канале.
Что же касается мысли о том, что вместо вас могут выбрать другого кандидата - это действительно так, причём независимо от профессии, и независимо от вашего уровня опыта и знаний. Даже если бы вы были бы специалистом высочайшего уровня, всё равно всегда может найтись кто-то другой, кто больше понравится отдельно взятому работодателю. Но это не такая уж проблема, если вакансий на рынке много.
А компаний, где испольуют джаву и вакансий джава-разработчиков очень и очень много. Поэтому если вам откажут на первом (втором, пятом) собеседовании - продолжайте подавать резюме в другие компании, уровень требований к кандидатам и критерии отбора везде разные.
Также если собеседование закончилось отказом - обязательно собирайте обратную связь - что именно ребятам там не понравилось? Может быть, они подскажут вам, каких знаний по их мнению вам не хватает - сможете поработать над этими знаниями.
Также после неудачного собеседования, можно предложить такой вариант работодателю: вы подтянете знания, которых вам не хватает на их взгляд, и, скажем, через два-три месяца, снова придёте на собеседование в эту компанию. Таким образом вы покажете свою готовность учиться/развиваться, а также высокую мотивацию устроиться на работу в их компанию.
Задать вопрос автору блога можно здесь: @hum_it_bot
Во фронтенд - бесплатный роадмап/план изучения по фронтенду.
Начнем с абсолютного нуля, а финальной целью будет достаточный уровень для входа в профессию(последние этапы этого роадмапа будут полностью посвящены собесам). Пока ориентируемся на React, возможно это изменится(до него еще дойти надо).
На канале вы узнаете:
-как код пишется в реальном мире, за пределами учебников
-разборы собеседований, задач, вопросов, подводных камней
-эффективные приемы и техники изучения
Примерные сроки - 6 месяцев, в любом случае, этот роадмап останется, и можно будет идти по нему в своем темпе. welcome, @into_frontend
Начнем с абсолютного нуля, а финальной целью будет достаточный уровень для входа в профессию(последние этапы этого роадмапа будут полностью посвящены собесам). Пока ориентируемся на React, возможно это изменится(до него еще дойти надо).
На канале вы узнаете:
-как код пишется в реальном мире, за пределами учебников
-разборы собеседований, задач, вопросов, подводных камней
-эффективные приемы и техники изучения
Примерные сроки - 6 месяцев, в любом случае, этот роадмап останется, и можно будет идти по нему в своем темпе. welcome, @into_frontend
Telegram
ВО ФРОНТЕНД
Бесплатный роадмап/план изучения по фронтенду
Я намеренно не стала вчера писать про Чёрную пятницу, так как, думаю, всех уже и так достала повсеместная реклама и скидки, скидки, скидки.
Также, думаю, всем и так понятно, что в эти несколько дней каждая крупная онлайн-школа предлагает скидки, так что писать про каждую отдельную скидку я не буду.
А кто задумывается о покупке какого-либо курса - можете посмотреть мою сентябрьскую подборку онлайн-школ и скидок в них https://news.1rj.ru/str/it_human/527 - все промокоды из поста всё ещё действуют, я проверяла. Разве что точный размер скидки может отличаться.
Также, думаю, всем и так понятно, что в эти несколько дней каждая крупная онлайн-школа предлагает скидки, так что писать про каждую отдельную скидку я не буду.
А кто задумывается о покупке какого-либо курса - можете посмотреть мою сентябрьскую подборку онлайн-школ и скидок в них https://news.1rj.ru/str/it_human/527 - все промокоды из поста всё ещё действуют, я проверяла. Разве что точный размер скидки может отличаться.
#вашивопросы
Привет! Я сейчас в процессе обучения (это не высшее образование, но, думаю, это не важно), и эти учебные проекты – «общеобразовательные». Они дают хорошую базу знаний в алгоритмах, структурах данных, работе с оболочкой и т.д. (и еще они пишутся на чистом си), но все же нужно определяться с более конкретной специальностью. Я решила идти от обратного и найти крутые проекты, которые были бы мне интересны сами по себе, и ориентироваться на необходимые для них навыки, а потом уже развиваться в этом направлении. Можешь подсказать, где находить такие небольшие, но интересные стартапы?
Исходя из вашего вопроса, получается, вы ищете интересные проекты для практики - и не вижу причины их искать преимущественно у работодателей-стартапов. В целом проект может быть интересным (как и не очень интересным) практически в любой компании, независимо от того стартап это или нет - а насколько конкретный проект будет интересен именно вам, постарайтесь выяснить на собеседовании. А на счёт того, где и как искать - да там же, где все ищут работу - разместите резюме на hh и аналогах (если хотите), заведите профиль в Linkedin.
Также хочу напомнить про крутой репозиторий на гитхабе с интересными тренировочными проектами - там огромный выбор, подробнее в этом посте: https://news.1rj.ru/str/it_human/450. Это если вы рассматриваете проекты для тренировки, но не ради денег.
Ещё один путь, который не про деньги - найти интересный для себя Open Source-проект и принять участие в разработке. Искать можно на том же гитхабе, так же можно погуглить на тему опен сорс-проектов и как в них вкатиться - на этот счет написано много статей.
Задать вопрос автору блога можно здесь: @hum_it_bot
Привет! Я сейчас в процессе обучения (это не высшее образование, но, думаю, это не важно), и эти учебные проекты – «общеобразовательные». Они дают хорошую базу знаний в алгоритмах, структурах данных, работе с оболочкой и т.д. (и еще они пишутся на чистом си), но все же нужно определяться с более конкретной специальностью. Я решила идти от обратного и найти крутые проекты, которые были бы мне интересны сами по себе, и ориентироваться на необходимые для них навыки, а потом уже развиваться в этом направлении. Можешь подсказать, где находить такие небольшие, но интересные стартапы?
Исходя из вашего вопроса, получается, вы ищете интересные проекты для практики - и не вижу причины их искать преимущественно у работодателей-стартапов. В целом проект может быть интересным (как и не очень интересным) практически в любой компании, независимо от того стартап это или нет - а насколько конкретный проект будет интересен именно вам, постарайтесь выяснить на собеседовании. А на счёт того, где и как искать - да там же, где все ищут работу - разместите резюме на hh и аналогах (если хотите), заведите профиль в Linkedin.
Также хочу напомнить про крутой репозиторий на гитхабе с интересными тренировочными проектами - там огромный выбор, подробнее в этом посте: https://news.1rj.ru/str/it_human/450. Это если вы рассматриваете проекты для тренировки, но не ради денег.
Ещё один путь, который не про деньги - найти интересный для себя Open Source-проект и принять участие в разработке. Искать можно на том же гитхабе, так же можно погуглить на тему опен сорс-проектов и как в них вкатиться - на этот счет написано много статей.
Задать вопрос автору блога можно здесь: @hum_it_bot
Наткнулась на небольшой канал, который подойдёт именно для новичков, называется Культурный код.
Что там можно найти:
— Ликбез по основным понятиям из разработки: что такое AJAX? Что такое сервер? Что такое Linux? Я сама ленюсь писать такого рода статьи, рассчитывая, что читатели, если нужно, всё загуглят. А ребята вот не поленились и написали — заходи и читай
— Разъяснения мемов про IT. Приходилось ли вам видеть «смешную» картинку с шуткой про программирование, и ничего не понимать? Ребята позаботились и об этом — у них есть специальная рубрика, где берут какой-нибудь мем и объясняют, в чём там шутка
— Подборки бесплатных вводных занятий по программированию, data science и аналитике
— Подборки вакансий
— Интересные факты и истории из мира IT
Что там можно найти:
— Ликбез по основным понятиям из разработки: что такое AJAX? Что такое сервер? Что такое Linux? Я сама ленюсь писать такого рода статьи, рассчитывая, что читатели, если нужно, всё загуглят. А ребята вот не поленились и написали — заходи и читай
— Разъяснения мемов про IT. Приходилось ли вам видеть «смешную» картинку с шуткой про программирование, и ничего не понимать? Ребята позаботились и об этом — у них есть специальная рубрика, где берут какой-нибудь мем и объясняют, в чём там шутка
— Подборки бесплатных вводных занятий по программированию, data science и аналитике
— Подборки вакансий
— Интересные факты и истории из мира IT
Друзья, поскольку я сейчас перед праздниками зашиваюсь, чтобы успеть доделать всё, что нужно доделать до конца года, на канал совсем не хватает времени.
Забежала рассказать, что гикбрейнс запустили закрытую акцию "для своих" к Новому году:
- скидки до 55%
- покупателям подарят доступ к 5 другим онлайн-курсам на общую сумму 152000 рублей бесплатно
- розыгрыш iPad-ов среди покупателей.
Акция действует только для тех, кто зарегистрируется в ней по ссылке. Максимальные скидки действуют 22-24 и 29-31 декабря
Забежала рассказать, что гикбрейнс запустили закрытую акцию "для своих" к Новому году:
- скидки до 55%
- покупателям подарят доступ к 5 другим онлайн-курсам на общую сумму 152000 рублей бесплатно
- розыгрыш iPad-ов среди покупателей.
Акция действует только для тех, кто зарегистрируется в ней по ссылке. Максимальные скидки действуют 22-24 и 29-31 декабря
Возможно, я повторяюсь, но всё же (в очередной раз?) хочу поделиться с вами одним своим наблюдением: в первую очередь ваш успех в IT зависит от некоторых качеств характера и грамотного отношения к работе. И только во вторую очередь - от знаний.
Как это работает? Предположим перед вами сложная pабочая задача. Вы понятия не имеете, как к ней подступиться. Что-то пытаетесь сделать, но ничего не выходит. Но по характеру вы человек настойчивый и ответственный, и понимаете, что работа должна быть сделана. В итоге ищете решение всеми доступными способами - и в гугле, и советуетесь с коллегами, пробуете разные подходы, экспериментируете, подходите с разных сторон - и в итоге вуаля - решение есть. Может, неидеальное, может года через три вам будет стыдно за него, но главное - оно решает поставленную задачу.
И второй пример - вы не знаете, как решать задачу, немного пробуете, ну и делаете вывод - "нет, не смогу, у меня лапки". И пытаетесь либо спихнуть задачу на других коллег, либо просите кого-то о помощи, но делаете это так, что по сути человек должен за вас проделать всю основную работу. Либо просто ничего не делаете. И так происходит каждый раз, когда вы сталкиваетесь с чем-то новым хоть на 10%, незнакомым или непривычным.
В итоге - человек из первого примера, даже если он самый джунский джун, и полнейший новичок, быстро начнёт вливаться в рабочий процесс, и хоть и с трудом, но прорвётся через трудности. А человек из второго примера может обладать неплохой базой, университет закончить по профильной специальности, но как дело доходит до задач и чего-то хоть сколько-то непривычного - он сразу уходит в глухую оборону и в итоге ничего не делает. Первый человек может доучиться и добрать недостающие знания. Второй - по сути сопротивляется процессу профессионального роста.
Поэтому вывод такой - у вас есть задача - решайте её, не сдавайтесь. Работа должна быть сделана. Это верно не только в отношении IT, но и в отношении самых разных профессий, в том числе управленческих и менеджерских. Не знаете с ходу, как подступиться к решению? - Значит, надо что-то придумать. Собственно, за это нам зарплату и платят
Как это работает? Предположим перед вами сложная pабочая задача. Вы понятия не имеете, как к ней подступиться. Что-то пытаетесь сделать, но ничего не выходит. Но по характеру вы человек настойчивый и ответственный, и понимаете, что работа должна быть сделана. В итоге ищете решение всеми доступными способами - и в гугле, и советуетесь с коллегами, пробуете разные подходы, экспериментируете, подходите с разных сторон - и в итоге вуаля - решение есть. Может, неидеальное, может года через три вам будет стыдно за него, но главное - оно решает поставленную задачу.
И второй пример - вы не знаете, как решать задачу, немного пробуете, ну и делаете вывод - "нет, не смогу, у меня лапки". И пытаетесь либо спихнуть задачу на других коллег, либо просите кого-то о помощи, но делаете это так, что по сути человек должен за вас проделать всю основную работу. Либо просто ничего не делаете. И так происходит каждый раз, когда вы сталкиваетесь с чем-то новым хоть на 10%, незнакомым или непривычным.
В итоге - человек из первого примера, даже если он самый джунский джун, и полнейший новичок, быстро начнёт вливаться в рабочий процесс, и хоть и с трудом, но прорвётся через трудности. А человек из второго примера может обладать неплохой базой, университет закончить по профильной специальности, но как дело доходит до задач и чего-то хоть сколько-то непривычного - он сразу уходит в глухую оборону и в итоге ничего не делает. Первый человек может доучиться и добрать недостающие знания. Второй - по сути сопротивляется процессу профессионального роста.
Поэтому вывод такой - у вас есть задача - решайте её, не сдавайтесь. Работа должна быть сделана. Это верно не только в отношении IT, но и в отношении самых разных профессий, в том числе управленческих и менеджерских. Не знаете с ходу, как подступиться к решению? - Значит, надо что-то придумать. Собственно, за это нам зарплату и платят