- В каких сферах программирования используется математика? Для меня просто математика, алгоритмы в реальности - это сбор информации в таблицы. Впоследствии анализ ее.
Вопрос непростой, так как я вряд ли смогу назвать все области, где нужна математика. Но некоторые попробую.
Ну, во-первых, алгоритмы. Алгоритмы и структуры данных нужны для эффективного программирования - чтобы оптимизировать вычисления с точки зрения использования памяти, загрузки процессоров и времени выполнения. Одну и ту же программу можно реализовать так, что она будет считать результат 200 тысяч лет, а можно так, что доли секунд - вопрос в выборе (не)эффективного алгоритма.
Но далеко не все разработчики сталкиваются с задачами, в которых нужно использовать сложные нетривиальные алгоритмы - обычно они нужны, когда пишешь что-то большое и с серьезными требованиями по скорости выполнения и где каждая лишняя доля секунды - критичная величина. Бывают более простые и высокоуровневые задачи, где котируется простота кода и скорость его написания, а то, что он будет работать чуть медленее - не так критично.
По поводу математики.
- Математика (в частности, статистика) нужна в data science - для анализа данных, для обучения моделей машинного обучения и построения нейросетей
- В криптографии (и модном нынче блокчейне)
- В системном программировании
- В программировании чего-то специфического, связанного с математическими вычислениями (например, компьютерной графики или траекторий движения для каких-нибудь роботов)
- В программировании для научных вычислений
Есть компании, куда без хорошего знания математики и алгоритмов, скорее всего, не возьмут - например, Яндекс.
Но далеко не все разработчики используют какие-то сложные математические знания в решении своих ежедневных задач. И, по правде сказать, я не сталкивалась с тем, чтобы на собеседованиях спрашивали про матан.
Вопрос непростой, так как я вряд ли смогу назвать все области, где нужна математика. Но некоторые попробую.
Ну, во-первых, алгоритмы. Алгоритмы и структуры данных нужны для эффективного программирования - чтобы оптимизировать вычисления с точки зрения использования памяти, загрузки процессоров и времени выполнения. Одну и ту же программу можно реализовать так, что она будет считать результат 200 тысяч лет, а можно так, что доли секунд - вопрос в выборе (не)эффективного алгоритма.
Но далеко не все разработчики сталкиваются с задачами, в которых нужно использовать сложные нетривиальные алгоритмы - обычно они нужны, когда пишешь что-то большое и с серьезными требованиями по скорости выполнения и где каждая лишняя доля секунды - критичная величина. Бывают более простые и высокоуровневые задачи, где котируется простота кода и скорость его написания, а то, что он будет работать чуть медленее - не так критично.
По поводу математики.
- Математика (в частности, статистика) нужна в data science - для анализа данных, для обучения моделей машинного обучения и построения нейросетей
- В криптографии (и модном нынче блокчейне)
- В системном программировании
- В программировании чего-то специфического, связанного с математическими вычислениями (например, компьютерной графики или траекторий движения для каких-нибудь роботов)
- В программировании для научных вычислений
Есть компании, куда без хорошего знания математики и алгоритмов, скорее всего, не возьмут - например, Яндекс.
Но далеко не все разработчики используют какие-то сложные математические знания в решении своих ежедневных задач. И, по правде сказать, я не сталкивалась с тем, чтобы на собеседованиях спрашивали про матан.
Мои первые собеседования
Здесь должна быть история про то, как я мытарилась по собеседованиям, безуспешно пытаясь всем доказать, что чего-то стою в программировании, несмотря на гуманитарное образование.
Однако ничего подобного не было.
На собеседование в первую компанию меня позвали как только я выложила резюме. После собеседований сделали оффер, и потом еще девушка-рекрутер звонила по три раза на день и спрашивала - приняла ли я решение, или нет. А сейчас? А теперь? А когда вы решите? Я успела сходить на собеседование в еще одну компанию, и потом приняла первый оффер.
На первом собеседовании спросили, люблю ли я задачки на сообразительность. Я ответила, что не люблю (это правда). После этого мне задали несколько таких задачек - что-то там про шахматную доску, про шары, которые кидают с высоты итд итп. С подсказками я более или менее продвинулась в решении этих загадок. А из заданий по существу - попросили решить задачку на питоне (сам интервьюер питона не знал), и по SQL (классика - join, задачку на группировку и having). Кстати, по SQL почему-то все любят давать задание на декартово произведение, несмотря на то, что я ни разу не видела, чтобы его кто-то использовал в проде. Сама работа была в небольшой компании, а разрабатывать мне предстояло парсеры-краулеры для веб-страниц. В целом ничего сложного, но на том этапе для меня это звучало как «ты будешь строить космические корабли». Я, правда, не подала вида, что звучит очень сложно и у меня лапки, и деловито согласилась (читала в Интернете, что так надо делать 🙂 ).
Во второй компании (уже крупной) меня собеседовали на должность разработчика автотестов. Это звучало проще, но желанием идти в тестировщики я не горела. (Но зато какой крутой у них офис!) Там меня хорошо погоняли по вопросам про Linux, я, к своему удивлению, ответила на все и решила их задачи на всяких grep/sed/awk/sort/uniq итд. Сами интервьюеры сказали, что после моего резюме они совсем не ожидали таких глубоких знаний. Да я и сама не ожидала, чего уж там. Дальше меня еще пособеседовали несколько людей должностью повыше - пока в итоге я не попала к какому-то совсем «крутому дяде», судя по пиитету hr-менеджера. Он решил, что им нужен человек, который сейчас же возьмет в свои руки руководство командой автотестировщиков и наладит там процессы - и это точно было не про меня. Так я попала в первую компанию, откуда получила оффер.
Здесь должна быть история про то, как я мытарилась по собеседованиям, безуспешно пытаясь всем доказать, что чего-то стою в программировании, несмотря на гуманитарное образование.
Однако ничего подобного не было.
На собеседование в первую компанию меня позвали как только я выложила резюме. После собеседований сделали оффер, и потом еще девушка-рекрутер звонила по три раза на день и спрашивала - приняла ли я решение, или нет. А сейчас? А теперь? А когда вы решите? Я успела сходить на собеседование в еще одну компанию, и потом приняла первый оффер.
На первом собеседовании спросили, люблю ли я задачки на сообразительность. Я ответила, что не люблю (это правда). После этого мне задали несколько таких задачек - что-то там про шахматную доску, про шары, которые кидают с высоты итд итп. С подсказками я более или менее продвинулась в решении этих загадок. А из заданий по существу - попросили решить задачку на питоне (сам интервьюер питона не знал), и по SQL (классика - join, задачку на группировку и having). Кстати, по SQL почему-то все любят давать задание на декартово произведение, несмотря на то, что я ни разу не видела, чтобы его кто-то использовал в проде. Сама работа была в небольшой компании, а разрабатывать мне предстояло парсеры-краулеры для веб-страниц. В целом ничего сложного, но на том этапе для меня это звучало как «ты будешь строить космические корабли». Я, правда, не подала вида, что звучит очень сложно и у меня лапки, и деловито согласилась (читала в Интернете, что так надо делать 🙂 ).
Во второй компании (уже крупной) меня собеседовали на должность разработчика автотестов. Это звучало проще, но желанием идти в тестировщики я не горела. (Но зато какой крутой у них офис!) Там меня хорошо погоняли по вопросам про Linux, я, к своему удивлению, ответила на все и решила их задачи на всяких grep/sed/awk/sort/uniq итд. Сами интервьюеры сказали, что после моего резюме они совсем не ожидали таких глубоких знаний. Да я и сама не ожидала, чего уж там. Дальше меня еще пособеседовали несколько людей должностью повыше - пока в итоге я не попала к какому-то совсем «крутому дяде», судя по пиитету hr-менеджера. Он решил, что им нужен человек, который сейчас же возьмет в свои руки руководство командой автотестировщиков и наладит там процессы - и это точно было не про меня. Так я попала в первую компанию, откуда получила оффер.
- Что не так с работой тестировщиком? Опиши подробнее твои взаимодействия с тестировщиками сейчас, по работе
С тестировщиками всё так. Кроме того, что мне хотелось в разработку, а не в тестирование.
Вообще тестировщики тестировщикам рознь. Бывают вакансии тестировщиков, куда берут без каких-либо исходных навыков или знаний. Работа таких тестеров состоит, грубо говоря, в том, чтобы вручную потыкать интерфейс приложения как будто ты пользователь. На серьезную оплату такой работы рассчитывать не приходится, а что касается роста - тут вопрос в том, насколько компания вкладывается в развитие такого специалиста, и стремится ли повышать его квалификацию (например, обучать инженерным навыкам и программированию). Некоторые компании исходят из идеалогии «программировать у нас должны уметь все». В таком случае эта вакансия - хороший старт, и сам работодатель поможет с обучением. Но возможна и обратная ситуация, когда эта работа - просто про тыканье в кнопки, и никакой рост не подразумевается.
Другое дело, если речь идет о квалифицированном инженере-тестировщике, знакомом с теорией тестирования, знающим как правильно организовать процесс контроля качества продукта, умеющий составлять тест-дизайны, продумывать тест-кейсы и разную прочую магию QA. Такие специалисты имеют как минимум базовые знания языков программирования, на которых написан продукт, могут читать и понимать код.
Не всем продуктам вообще необходимы ручные тестировщики, и часто ограничиваются автотестами - в этом случае тестировщики - это программисты, которые пишут код тестов. Вот на такую вакансию меня и звали, но, как по мне, писать только тесты - звучит несколько муторно. И да, это предвзятая точка зрения.
Развиваться как тестировщик имеет смысл в компаниях, где есть отдел QA и в нем ценят квалифицированных специалистов по тестированию и на это выделен соответсвующий бюджет. Так можно дорости, например, до директора QA - но, повторюсь, если это направление вообще развито в данной компании.
Что касается моего опыта взаимодействия с тестироовщиками. На предыдущем месте работы я относилась к отделу Ops - мы занимались помимо прочего деплоем продукта непосредственно в продакшен, мониторингом и поддержкой его работоспособности. По сути тестировщиками, как это ни печально (и как это часто бывает) в итоге становились конечные пользователи. И все жалобы на баги прилетали первым делом в наш отдел (или же мы сами натыкались на баги). И дальше - либо бистро-бистро на коленке фиксили сами «по горяченькому» - так как до разработчиков как до луны не докричишься - они эти баги бы починили к следующему релизу, который через полгода. Либо, если баг был нетривиальный и «чик-чик и в продакшен» сделать не получалось - всё-таки пытались достучаться до разработчиков. (Да, очень часто процессы в компаниях работают через пень-колоду).
Потом появился отдел тестирования - там сначала работал 1 человек, потом наняли еще 2х. Теперь перед релизом продукта код от разработчиков попадал к тестировщикам, и они там делали свою магию, находили баги и отправляли код на доработку. И только после одобрения тестеров продукт уже попадал к нам и от нас в прод. Но для нас изменилось мало что - багов, которые надо срочно-срочно исправлять прям на коленке не убавилось - этим по-прежнему занимались мы. В других же случаях - репортили баг в отдел QA, они там проверяли продукт еще раз и уже свой отчет направляли разрабам.
В моей нынешней компании я взаимодействую с тестировщиками - никак. У нас их просто нет (по крайней мере на тех продуктах, с которыми работаю я). За качество кода, за поиск багов, за тестирование приложения, а также за деплой и поддержку отвечает его непосредственный автор - разработчик. Сплошной DevOps, в общем. По слухам, тестировщики раньше у нас были, но потом было принято решение отказаться от них. У такого подхода есть свои преимущества - разработчики меньше «халявят» и ответственнее относятся к тестированию кода, так как нет искушения «скинуть» эту работу на тестировщиков, и отдавать им «сырой», плохо отлаженный код.
С тестировщиками всё так. Кроме того, что мне хотелось в разработку, а не в тестирование.
Вообще тестировщики тестировщикам рознь. Бывают вакансии тестировщиков, куда берут без каких-либо исходных навыков или знаний. Работа таких тестеров состоит, грубо говоря, в том, чтобы вручную потыкать интерфейс приложения как будто ты пользователь. На серьезную оплату такой работы рассчитывать не приходится, а что касается роста - тут вопрос в том, насколько компания вкладывается в развитие такого специалиста, и стремится ли повышать его квалификацию (например, обучать инженерным навыкам и программированию). Некоторые компании исходят из идеалогии «программировать у нас должны уметь все». В таком случае эта вакансия - хороший старт, и сам работодатель поможет с обучением. Но возможна и обратная ситуация, когда эта работа - просто про тыканье в кнопки, и никакой рост не подразумевается.
Другое дело, если речь идет о квалифицированном инженере-тестировщике, знакомом с теорией тестирования, знающим как правильно организовать процесс контроля качества продукта, умеющий составлять тест-дизайны, продумывать тест-кейсы и разную прочую магию QA. Такие специалисты имеют как минимум базовые знания языков программирования, на которых написан продукт, могут читать и понимать код.
Не всем продуктам вообще необходимы ручные тестировщики, и часто ограничиваются автотестами - в этом случае тестировщики - это программисты, которые пишут код тестов. Вот на такую вакансию меня и звали, но, как по мне, писать только тесты - звучит несколько муторно. И да, это предвзятая точка зрения.
Развиваться как тестировщик имеет смысл в компаниях, где есть отдел QA и в нем ценят квалифицированных специалистов по тестированию и на это выделен соответсвующий бюджет. Так можно дорости, например, до директора QA - но, повторюсь, если это направление вообще развито в данной компании.
Что касается моего опыта взаимодействия с тестироовщиками. На предыдущем месте работы я относилась к отделу Ops - мы занимались помимо прочего деплоем продукта непосредственно в продакшен, мониторингом и поддержкой его работоспособности. По сути тестировщиками, как это ни печально (и как это часто бывает) в итоге становились конечные пользователи. И все жалобы на баги прилетали первым делом в наш отдел (или же мы сами натыкались на баги). И дальше - либо бистро-бистро на коленке фиксили сами «по горяченькому» - так как до разработчиков как до луны не докричишься - они эти баги бы починили к следующему релизу, который через полгода. Либо, если баг был нетривиальный и «чик-чик и в продакшен» сделать не получалось - всё-таки пытались достучаться до разработчиков. (Да, очень часто процессы в компаниях работают через пень-колоду).
Потом появился отдел тестирования - там сначала работал 1 человек, потом наняли еще 2х. Теперь перед релизом продукта код от разработчиков попадал к тестировщикам, и они там делали свою магию, находили баги и отправляли код на доработку. И только после одобрения тестеров продукт уже попадал к нам и от нас в прод. Но для нас изменилось мало что - багов, которые надо срочно-срочно исправлять прям на коленке не убавилось - этим по-прежнему занимались мы. В других же случаях - репортили баг в отдел QA, они там проверяли продукт еще раз и уже свой отчет направляли разрабам.
В моей нынешней компании я взаимодействую с тестировщиками - никак. У нас их просто нет (по крайней мере на тех продуктах, с которыми работаю я). За качество кода, за поиск багов, за тестирование приложения, а также за деплой и поддержку отвечает его непосредственный автор - разработчик. Сплошной DevOps, в общем. По слухам, тестировщики раньше у нас были, но потом было принято решение отказаться от них. У такого подхода есть свои преимущества - разработчики меньше «халявят» и ответственнее относятся к тестированию кода, так как нет искушения «скинуть» эту работу на тестировщиков, и отдавать им «сырой», плохо отлаженный код.
-
Чаще всего на собеседованиях просят написать решение на листочке (или маркером на доске). Компьютер вам вряд ли кто-то даст.
Особо страшного в этом ничего нет - каких-то мелких деталей и подробностей, которые обычно нужно гуглить, там, скорее всего не будет, а попросят вас набросать на бумаге решение небольшой задачки (ну, например, удалить из массива чисел все отрицательные). Могут попросить написать решение на знакомом вам языке, а могут на псевдокоде. Важно как вы мыслите в процессе решения, и знакомы ли с основами языка.
Что-то прям выучивать вряд ли имеет смысл - это не экзамен, тут проверяют скиллы и базовые знания, а не краткосрочную память.
На счет «написать парсер» - это вы загнули. Я даже не уверена, что поняла вас правильно.
Если собеседование удаленное, например, по скайпу, тогда вам могут предложить решать задания в каком-нибудь интерактивном интепретаторе со своего компьютера.
Более сложные и большие тестовые задания «задают на дом».
И еще важный вопрос про собеседования — как дают на них решать задачки? листок бумаги и ручка? компьютер с установленым енвайрментом? Вот почему спрашиваю — при разработке приложений для себя и для курсов и по книжкам все равно подсматриваю в свои записи, в тоториалы, в документацию к модулям. Ведь в реальной работе разрабы гуглят тоже очень много, и по памяти не помнят какие параметры передаются сюда-туда, подглядывают. А на собеседовании как? надо все выучить, чтобы можно на листочке парсер написать, никуда не подглядывая?Чаще всего на собеседованиях просят написать решение на листочке (или маркером на доске). Компьютер вам вряд ли кто-то даст.
Особо страшного в этом ничего нет - каких-то мелких деталей и подробностей, которые обычно нужно гуглить, там, скорее всего не будет, а попросят вас набросать на бумаге решение небольшой задачки (ну, например, удалить из массива чисел все отрицательные). Могут попросить написать решение на знакомом вам языке, а могут на псевдокоде. Важно как вы мыслите в процессе решения, и знакомы ли с основами языка.
Что-то прям выучивать вряд ли имеет смысл - это не экзамен, тут проверяют скиллы и базовые знания, а не краткосрочную память.
На счет «написать парсер» - это вы загнули. Я даже не уверена, что поняла вас правильно.
Если собеседование удаленное, например, по скайпу, тогда вам могут предложить решать задания в каком-нибудь интерактивном интепретаторе со своего компьютера.
Более сложные и большие тестовые задания «задают на дом».
Ваш главный враг
Мне в бота для обратной связи присылают много разных вопросов. Но почти во всех случаях подходит один и тот же ответ - не бойтесь. Ваш главный враг - это страх. Он же и основное препятствие.
Одни боятся изучать что-то новое - оно же такое сложное и непонятное. На самом деле сложным всё кажется потому, что вы боитесь думать. Если сесть и неспеша разобраться - окажется, что ничего сложного там и не было. Но паника (а к ней еще и лень) при виде того, что с первого взгляда кажется «китайской грамотой» может парализовать волю, и вместо того, чтобы приложить минимальное усилие и чуть-чуть подумать, врубается режим «ААААААА! я не смогу! сложно! я никогда это не пойму!». При виде чего-то непонятного - не пугайтесь, попытайтесь разобраться.
Другие боятся писать резюме - мол сейчас выложу, и никто на него не посмотрит! Страх-то какой! Ну даже если и так - что с того? Не зайдёт эта версия резюме, напишете другую. Не понравится одному работодателю, понравится другому. В чем проблема-то?
Третьи боятся идти на собеседование - я же там опозорюсь! Ну во-первых, собеседование - это не экзамен. Это знакомство с работодателем. Даже если вы его не пройдете, вы узнаете, какие требования там предъявляют к кандидатам, и какие у вас есть пробелы в знаниях - и можно вернуться даже в то же место через полгода, прокачавшись, где нужно. Или сходить на собеседования в другие места. Не получится сегодня - получится в следующий раз. Это вопрос подготовки.
Четвертые уже прошли предыдущие этапы, но, оказавшись на работе, снова впадают в панику. Тут незнакомые технологии, всё такое непонятное, я раньше такого не делал. Хочется схватиться руками за голову и позвать кого-то мудрого и знающего на помощь. Или уволиться и пойти работать в макдональдс. Так вот - уймите панику. Тут нужно просто сесть и вдумчиво разобраться, что за новый дивный мир перед вами - у вас же есть полный Интернет информации. И через неделю или месяц-другой всё это страшное и непонятное окажется простым и знакомым.
Мне в бота для обратной связи присылают много разных вопросов. Но почти во всех случаях подходит один и тот же ответ - не бойтесь. Ваш главный враг - это страх. Он же и основное препятствие.
Одни боятся изучать что-то новое - оно же такое сложное и непонятное. На самом деле сложным всё кажется потому, что вы боитесь думать. Если сесть и неспеша разобраться - окажется, что ничего сложного там и не было. Но паника (а к ней еще и лень) при виде того, что с первого взгляда кажется «китайской грамотой» может парализовать волю, и вместо того, чтобы приложить минимальное усилие и чуть-чуть подумать, врубается режим «ААААААА! я не смогу! сложно! я никогда это не пойму!». При виде чего-то непонятного - не пугайтесь, попытайтесь разобраться.
Другие боятся писать резюме - мол сейчас выложу, и никто на него не посмотрит! Страх-то какой! Ну даже если и так - что с того? Не зайдёт эта версия резюме, напишете другую. Не понравится одному работодателю, понравится другому. В чем проблема-то?
Третьи боятся идти на собеседование - я же там опозорюсь! Ну во-первых, собеседование - это не экзамен. Это знакомство с работодателем. Даже если вы его не пройдете, вы узнаете, какие требования там предъявляют к кандидатам, и какие у вас есть пробелы в знаниях - и можно вернуться даже в то же место через полгода, прокачавшись, где нужно. Или сходить на собеседования в другие места. Не получится сегодня - получится в следующий раз. Это вопрос подготовки.
Четвертые уже прошли предыдущие этапы, но, оказавшись на работе, снова впадают в панику. Тут незнакомые технологии, всё такое непонятное, я раньше такого не делал. Хочется схватиться руками за голову и позвать кого-то мудрого и знающего на помощь. Или уволиться и пойти работать в макдональдс. Так вот - уймите панику. Тут нужно просто сесть и вдумчиво разобраться, что за новый дивный мир перед вами - у вас же есть полный Интернет информации. И через неделю или месяц-другой всё это страшное и непонятное окажется простым и знакомым.
С чего мне начать учиться? Порекомендуйте курсы и книги.
Это самый частый вопрос, который мне задают. И, мне кажется, я уже на него отвечала в разных постах (по сути они все про это). Но повторюсь еще раз.
Думаю, самое эффективное, что доступно сейчас для обучения - это курсы при крупных It-компаниях. В идеале - не бесплатные, не краткосрочные, включающие проработанную программу из разных предметов и с гарантией трудоустройства. Какие компании предлагают такие курсы - легко загуглить (запрос: курсы при IT компаниях). На них из вас сделают готового специалиста и передадут в руки работодателя.
Если же хочется просто попробовать, что это такое в более лайтовом и ни к чему не обязывающем режиме - то заходите на любую образовательную платформу (coursera/edx/stepik/udemy итд) - выбирайте любой курс по Computer Science или программированию для начинающих - и пробуйте. В описании курса должно быть написано, что не требуется никакой начальной подготовки, и могут упоминаться слова introduction/введение/101. Такие курсы бывают совсем короткими - на 1 месяц, к примеру. Лично я училась как раз в таком режиме, но не «лайтово», так как «загребала» все курсы, которые мне попадались на пути.
В очередной раз среди онлайн-курсов на английском языке рекомендую гарвардский CS50 - Introduction into Computer Science, он есть на платформе edx.org. Он не из коротких - длится 1 учебный год. И потребует определенного количества времени и усилий, но он классный и очень вдохновляющий. Только не говорите потом «я изучал программирование в Гарварде», а то про это уже даже мем есть.
Что касается того, какие книги почитать - у меня нет своего эталонного списка рекомендованной литературы. Лично я читала преимущественно о тех технологиях, которые использую в работе и по каким-то отдельным интересным для меня темам. Дональд Кнут все еще стоит на полке и зыркает на меня укоризненно корешком. А начинала я не с книг, а с онлайн-курсов. Поэтому поискать хорошие книги для начинающих лучше в гугле - он вообще умный и много знает.
Это самый частый вопрос, который мне задают. И, мне кажется, я уже на него отвечала в разных постах (по сути они все про это). Но повторюсь еще раз.
Думаю, самое эффективное, что доступно сейчас для обучения - это курсы при крупных It-компаниях. В идеале - не бесплатные, не краткосрочные, включающие проработанную программу из разных предметов и с гарантией трудоустройства. Какие компании предлагают такие курсы - легко загуглить (запрос: курсы при IT компаниях). На них из вас сделают готового специалиста и передадут в руки работодателя.
Если же хочется просто попробовать, что это такое в более лайтовом и ни к чему не обязывающем режиме - то заходите на любую образовательную платформу (coursera/edx/stepik/udemy итд) - выбирайте любой курс по Computer Science или программированию для начинающих - и пробуйте. В описании курса должно быть написано, что не требуется никакой начальной подготовки, и могут упоминаться слова introduction/введение/101. Такие курсы бывают совсем короткими - на 1 месяц, к примеру. Лично я училась как раз в таком режиме, но не «лайтово», так как «загребала» все курсы, которые мне попадались на пути.
В очередной раз среди онлайн-курсов на английском языке рекомендую гарвардский CS50 - Introduction into Computer Science, он есть на платформе edx.org. Он не из коротких - длится 1 учебный год. И потребует определенного количества времени и усилий, но он классный и очень вдохновляющий. Только не говорите потом «я изучал программирование в Гарварде», а то про это уже даже мем есть.
Что касается того, какие книги почитать - у меня нет своего эталонного списка рекомендованной литературы. Лично я читала преимущественно о тех технологиях, которые использую в работе и по каким-то отдельным интересным для меня темам. Дональд Кнут все еще стоит на полке и зыркает на меня укоризненно корешком. А начинала я не с книг, а с онлайн-курсов. Поэтому поискать хорошие книги для начинающих лучше в гугле - он вообще умный и много знает.
Про уверенность в себе
Сегодняшний пост про две стороны уверенности в себе.
Вы наверняка слышали, как из каждого утюга кричат, что уверенность - это всё, основа успеха и всякое такое.
Так вот, собеседовали мы как-то на прошлой работе девочку. Пришла она из другого отдела, была стажером data science, а собеседовали ее зачем-то на позицию, в большей мере связанную с инженерными задачками и программированием. В целом было ясно, что и компетенций там не достаточно, и работать человек привык с другими задачами, но почему-то всем очень хотелось натянуть сову на глобус.
Сама девочка излучала такую уверенность в себе, что руководитель отдела ей поверил на слово. «Программирование? Ну с программированием у меня точно не возникнет проблем. В этом я уверена. А я слушала и понимала, что человек явно недооценивает сложность задач и количество усилий, которое нужно на потратить на освоение недостающих навыков. Знакома она была только с питоном, и то в довольно узких задачах, а работать предстояло в том числе с «этими вашими шарпами» (C#). Но где-то когда-то писали, что поколение Y - это часто такие ребята, которые могут сомневаться в ком угодно, но только не в себе.
В итоге взяли девочку. С программированием, с которым по ее убеждению проблем возникнуть было не должно, проблемы, конечно, возникли сразу. Девочка отказывалась понимать, что существует такая вещь, как языки программирования со строгой типизацией, и сколько не повторяй, что переменные надо объявлять - всё мимо, код не компилируется. С питоном, к слову, было не сильно легче - как только её код падал с каким-то исключением, она не читая текст исключения, и даже не предпринимая попыток разобраться, что за ошибка произошла - тут же звала меня «Лена! У меня тут какая-то ошибка! Чо делать?». Просьбу для начала прочитать текст на ее мониторе - там же написано, что за ошибка - она так же неизменно игнорировала, как и строгую типизацию в C#.
В итоге через какое-то время девочка сама ушла, а в её резюме я увидела новый пункт в скиллах: C#. Серьезно?
Так что уверенность в себе - это само по себе неплохо, и может даже помочь произвести хорошее впечатление на этапе знакомства. Но без скиллов и усердия это скорее минус, чем плюс. Нередко бывает, что завышенная самооценка, и даже некоторое высокомерие идут рука об руку с некомпетентностью.
Впрочем, на собеседование все же захватите с собой уверенность в себе, хотя бы столько, сколько наскребёте - не помешает.
Сегодняшний пост про две стороны уверенности в себе.
Вы наверняка слышали, как из каждого утюга кричат, что уверенность - это всё, основа успеха и всякое такое.
Так вот, собеседовали мы как-то на прошлой работе девочку. Пришла она из другого отдела, была стажером data science, а собеседовали ее зачем-то на позицию, в большей мере связанную с инженерными задачками и программированием. В целом было ясно, что и компетенций там не достаточно, и работать человек привык с другими задачами, но почему-то всем очень хотелось натянуть сову на глобус.
Сама девочка излучала такую уверенность в себе, что руководитель отдела ей поверил на слово. «Программирование? Ну с программированием у меня точно не возникнет проблем. В этом я уверена. А я слушала и понимала, что человек явно недооценивает сложность задач и количество усилий, которое нужно на потратить на освоение недостающих навыков. Знакома она была только с питоном, и то в довольно узких задачах, а работать предстояло в том числе с «этими вашими шарпами» (C#). Но где-то когда-то писали, что поколение Y - это часто такие ребята, которые могут сомневаться в ком угодно, но только не в себе.
В итоге взяли девочку. С программированием, с которым по ее убеждению проблем возникнуть было не должно, проблемы, конечно, возникли сразу. Девочка отказывалась понимать, что существует такая вещь, как языки программирования со строгой типизацией, и сколько не повторяй, что переменные надо объявлять - всё мимо, код не компилируется. С питоном, к слову, было не сильно легче - как только её код падал с каким-то исключением, она не читая текст исключения, и даже не предпринимая попыток разобраться, что за ошибка произошла - тут же звала меня «Лена! У меня тут какая-то ошибка! Чо делать?». Просьбу для начала прочитать текст на ее мониторе - там же написано, что за ошибка - она так же неизменно игнорировала, как и строгую типизацию в C#.
В итоге через какое-то время девочка сама ушла, а в её резюме я увидела новый пункт в скиллах: C#. Серьезно?
Так что уверенность в себе - это само по себе неплохо, и может даже помочь произвести хорошее впечатление на этапе знакомства. Но без скиллов и усердия это скорее минус, чем плюс. Нередко бывает, что завышенная самооценка, и даже некоторое высокомерие идут рука об руку с некомпетентностью.
Впрочем, на собеседование все же захватите с собой уверенность в себе, хотя бы столько, сколько наскребёте - не помешает.
- Добрый день, вот вопрос: как понять, что пора писать резюме и начинать ходить на собеседования? меня самого интересует тестирование, но наверное многим будет интересно при изучении, к примеру, питона.
Книжки, которые в списке маст-рид прочитаны, и примеры сделаны, три курса на степике по питону пройдено, могу ,скажем без мам-пап-и подглядываний написать транспонирование матрицы. Пора писать резюме в списке скилов питон?
Очень в тему Вашего последнего поста по самоуверенность.
Привет! А вы начинайте и пробуйте - как раз в процессе собеседований (или первых мест работы) и поймёте, готовы ли уже к работе, или что-то где-то еще нужно доучить. К тому же к тестировщикам на начальном этапе не такие уж большие требования (но это зависит от конкретного работодателя). Тянуть и закапываться в книгах - тоже не очень хороший путь, так как книги и курсы не дают опыта работы над реальными «боевыми» задачами и соответствующих скиллов. Если устроитесь на работу и поймете, что кровь из носа не хватает времени на то, чтобы еще что-то подучить - можно поискать варианты с неполной занятостью, чтобы выделить время на учебу. Но обычно самая эффективная учеба происходит в процессе работы и решения реальных задач.
В резюме на первых этапах пишите всё, что хоть в какой-то мере знаете. В примере из моего поста речь шла о том, что человек не освоил даже на начальном уровне язык и не мог на нем решать элементарных задач, но уже написал его как пункт в резюме.
- Мне кажется, девочка молодец и то, что она попала к вам не обладая навыками - это круто. Тут скорее минус в том, что ей не хватило сил и терпения разобраться во всем, вот тут минус. По практике уверен, что если влез и есть желание, то можно все потянуть. Вот тут и вопрос в другом, как бы влезть 🙂
По своему опыту (не претендую на то, что он универсальный и что мои выводы единственно верные), «влезть» - это вообще не проблема, по крайней мере в Москве, где вакансий очень много. А реальный успех зависит почти исключительно от готовности прилагать усилия и «копать глубже». Если человек не любопытный, не увлеченный, относится по-раздолбайски и «на отвали», но при этом еще совсем новичок, то ни на какой высокой самооценке тут не выедешь.
И я ни в коем случае не говорю о том, что уверенность в себе - это плохо. Это хорошо, и гораздо полезнее, чем низкая самооценка и излишняя скромность - есть много людей, которые довольно неплохие специалисты, но позиционируют себя как «да я ничего особо не умею, ничего толком не могу» - и такое отношение, разумеется, может навредить на собеседовании. Например, такой очень скромный человек, скорее всего, и зарплату попросит маленькую (ну разве я большего заслуживаю?).
Но вопрос не только в том, как вы себя презентуете при знакомстве, но и в том, объективно ли оцениваете свой уровень сами. Да, на собеседовании по возможности хорошо делать вид, что вы самый лучший. Но искренне верить в то, что вы действительно очень крутой специалист (будучи новичком) - это скорее минус, так как если вы и так крутой - то зачем стремиться к большему, зачем учиться и осваивать что-то новое? И так сойдёт.
Книжки, которые в списке маст-рид прочитаны, и примеры сделаны, три курса на степике по питону пройдено, могу ,скажем без мам-пап-и подглядываний написать транспонирование матрицы. Пора писать резюме в списке скилов питон?
Очень в тему Вашего последнего поста по самоуверенность.
Привет! А вы начинайте и пробуйте - как раз в процессе собеседований (или первых мест работы) и поймёте, готовы ли уже к работе, или что-то где-то еще нужно доучить. К тому же к тестировщикам на начальном этапе не такие уж большие требования (но это зависит от конкретного работодателя). Тянуть и закапываться в книгах - тоже не очень хороший путь, так как книги и курсы не дают опыта работы над реальными «боевыми» задачами и соответствующих скиллов. Если устроитесь на работу и поймете, что кровь из носа не хватает времени на то, чтобы еще что-то подучить - можно поискать варианты с неполной занятостью, чтобы выделить время на учебу. Но обычно самая эффективная учеба происходит в процессе работы и решения реальных задач.
В резюме на первых этапах пишите всё, что хоть в какой-то мере знаете. В примере из моего поста речь шла о том, что человек не освоил даже на начальном уровне язык и не мог на нем решать элементарных задач, но уже написал его как пункт в резюме.
- Мне кажется, девочка молодец и то, что она попала к вам не обладая навыками - это круто. Тут скорее минус в том, что ей не хватило сил и терпения разобраться во всем, вот тут минус. По практике уверен, что если влез и есть желание, то можно все потянуть. Вот тут и вопрос в другом, как бы влезть 🙂
По своему опыту (не претендую на то, что он универсальный и что мои выводы единственно верные), «влезть» - это вообще не проблема, по крайней мере в Москве, где вакансий очень много. А реальный успех зависит почти исключительно от готовности прилагать усилия и «копать глубже». Если человек не любопытный, не увлеченный, относится по-раздолбайски и «на отвали», но при этом еще совсем новичок, то ни на какой высокой самооценке тут не выедешь.
И я ни в коем случае не говорю о том, что уверенность в себе - это плохо. Это хорошо, и гораздо полезнее, чем низкая самооценка и излишняя скромность - есть много людей, которые довольно неплохие специалисты, но позиционируют себя как «да я ничего особо не умею, ничего толком не могу» - и такое отношение, разумеется, может навредить на собеседовании. Например, такой очень скромный человек, скорее всего, и зарплату попросит маленькую (ну разве я большего заслуживаю?).
Но вопрос не только в том, как вы себя презентуете при знакомстве, но и в том, объективно ли оцениваете свой уровень сами. Да, на собеседовании по возможности хорошо делать вид, что вы самый лучший. Но искренне верить в то, что вы действительно очень крутой специалист (будучи новичком) - это скорее минус, так как если вы и так крутой - то зачем стремиться к большему, зачем учиться и осваивать что-то новое? И так сойдёт.
Ты же девочка
Сложно обойти вниманием вопросы про сексизм в IT. Какого это - быть девочкой-айтишиком?
Ощущаю ли я на себе какую-либо гендерную дискриминацию? - Нет или почти нет.
Значит ли это, что сексизма вообще нет? - Не значит. Но сексизм - дело тонкое, он не всегда явный, не всегда заметный, и не обязательно затрагивает тебя лично.
Вообще сексисткие высказывания бывают двух видов - когда тебе отказывают в каких-то способностях на основании гендера, и наоборот - сексисткие комплименты. Например, лет в 20 мне льстило, когда мне говорили «Нифига себе! Ты водишь машину на ручной коробке передач! Ты же девочка». Мне казалось, что круто быть «не такой» девочкой, которая так выгодно отличается от стереотипного образа «бабы». Но сейчас я бы не стала воспринимать такое как комплимент - потому что, а что особенного в том, что я могу ездить на механике? Миллионы людей умеют это делать. Типо нужно быть какой-то «особенной» женщиной, чтобы уметь нажимать на педали и дергать ручку коробки передач? А вот homo sapiens мужского пола - это другое дело, ему это проще. Серьезно?
Поэтому когда кто-то удивляется, что как же так, девочка, да в IT - это признак довольно дубового мышления. Но на самом деле с такой формулировкой напрямую я встречалась только 1 раз, на довольно дурацком собеседовании, где hr-менеджер сначала долго пыталась меня классифицировать по соционике, не обращая внимания на мои вялые возражения о том, что это антинаучно. А потом наконец созрела для «главного вопроса»: «Как так получилось, что девушка - да в IT? Странный выбор. Я думала, все программисты - это такие ребята с бородой и в заношенном свитере». И сальными волосами, в очках с трехметровыми стеклами, ага.
Но есть и другая сторона. Если вы девушка, ваш пол может сыграть на пользу вашему резюме. Потому что нас мало. И ваше резюме будет заметнее на фоне 20 мужских - просто потому что девушек в IT мало. И с одной стороны, у работодателя могут быть сексистские предрассудки и сомнения в том, что девушка «смогёт», но с другой - ему будет интересно посмотреть на девушку-айтишника, потому что это всё ещё редкий вид. Так что вероятность, что вас заметят, позовут на собеседование, выделят среди других кандидатов и запомнят - достаточно высока. А пройдёте вы или нет собеседование, зависит уже всецело от вашей подготовки. Так что, быть может, быть девушкой даже выгоднее, в каком-то смысле.
В принципе, если у отдельных представителей индустрии есть сексистские убеждения, то единственный способ им противостоять - это быть девушкой, работать в IT и хорошо себя там проявлять. Потому что мнения меняются, и если у вчерашнего сексиста был положительный опыт работы с одной девушкой-разработчиком, он уже будет менее предвзят в следующий раз. А если с двумя или тремя - то еще в большей степени.
Но вот если наоборот относиться к работе по-раздолбайски, то стереотип «девушка не может быть айтишником» будет подкрепляться. Тут есть некоторая несправедливость, потому что если девушка тупит и косячит, про нее наверняка подумают: «ну ясное дело, девочка же». А если то же самое делает мальчик, никому не придет в голову объяснять это его полом. Да, я слышала в адрес других коллег женского пола комментарии в духе «у неё такой хаотический женский код».
А вообще нас мало, но с каждым годом становится больше. И быть женщиной в IT - это уже не ново, к этой реальности все уже потихоньку привыкают. Я не могу сказать, что хоть в какой-то мере ощущаю на себе дискриминацию. Потому что в IT встречают не «по одеждке», а по скиллам. И если относиться к своей работе ответственно, то тебя заметят и оценят.
Сложно обойти вниманием вопросы про сексизм в IT. Какого это - быть девочкой-айтишиком?
Ощущаю ли я на себе какую-либо гендерную дискриминацию? - Нет или почти нет.
Значит ли это, что сексизма вообще нет? - Не значит. Но сексизм - дело тонкое, он не всегда явный, не всегда заметный, и не обязательно затрагивает тебя лично.
Вообще сексисткие высказывания бывают двух видов - когда тебе отказывают в каких-то способностях на основании гендера, и наоборот - сексисткие комплименты. Например, лет в 20 мне льстило, когда мне говорили «Нифига себе! Ты водишь машину на ручной коробке передач! Ты же девочка». Мне казалось, что круто быть «не такой» девочкой, которая так выгодно отличается от стереотипного образа «бабы». Но сейчас я бы не стала воспринимать такое как комплимент - потому что, а что особенного в том, что я могу ездить на механике? Миллионы людей умеют это делать. Типо нужно быть какой-то «особенной» женщиной, чтобы уметь нажимать на педали и дергать ручку коробки передач? А вот homo sapiens мужского пола - это другое дело, ему это проще. Серьезно?
Поэтому когда кто-то удивляется, что как же так, девочка, да в IT - это признак довольно дубового мышления. Но на самом деле с такой формулировкой напрямую я встречалась только 1 раз, на довольно дурацком собеседовании, где hr-менеджер сначала долго пыталась меня классифицировать по соционике, не обращая внимания на мои вялые возражения о том, что это антинаучно. А потом наконец созрела для «главного вопроса»: «Как так получилось, что девушка - да в IT? Странный выбор. Я думала, все программисты - это такие ребята с бородой и в заношенном свитере». И сальными волосами, в очках с трехметровыми стеклами, ага.
Но есть и другая сторона. Если вы девушка, ваш пол может сыграть на пользу вашему резюме. Потому что нас мало. И ваше резюме будет заметнее на фоне 20 мужских - просто потому что девушек в IT мало. И с одной стороны, у работодателя могут быть сексистские предрассудки и сомнения в том, что девушка «смогёт», но с другой - ему будет интересно посмотреть на девушку-айтишника, потому что это всё ещё редкий вид. Так что вероятность, что вас заметят, позовут на собеседование, выделят среди других кандидатов и запомнят - достаточно высока. А пройдёте вы или нет собеседование, зависит уже всецело от вашей подготовки. Так что, быть может, быть девушкой даже выгоднее, в каком-то смысле.
В принципе, если у отдельных представителей индустрии есть сексистские убеждения, то единственный способ им противостоять - это быть девушкой, работать в IT и хорошо себя там проявлять. Потому что мнения меняются, и если у вчерашнего сексиста был положительный опыт работы с одной девушкой-разработчиком, он уже будет менее предвзят в следующий раз. А если с двумя или тремя - то еще в большей степени.
Но вот если наоборот относиться к работе по-раздолбайски, то стереотип «девушка не может быть айтишником» будет подкрепляться. Тут есть некоторая несправедливость, потому что если девушка тупит и косячит, про нее наверняка подумают: «ну ясное дело, девочка же». А если то же самое делает мальчик, никому не придет в голову объяснять это его полом. Да, я слышала в адрес других коллег женского пола комментарии в духе «у неё такой хаотический женский код».
А вообще нас мало, но с каждым годом становится больше. И быть женщиной в IT - это уже не ново, к этой реальности все уже потихоньку привыкают. Я не могу сказать, что хоть в какой-то мере ощущаю на себе дискриминацию. Потому что в IT встречают не «по одеждке», а по скиллам. И если относиться к своей работе ответственно, то тебя заметят и оценят.
На позиции джуниора как долго дадут тупить? Как вообще все это будет? типа ну вот мы работаем на Джанге, ты знаешь азы Питона, вот сиди читай мануал, разбирайся с какой-нибудь задачкой, или будет что-то типа: вот тебе золушка мешок зубов перебери к вечеру их все, и не волнует, знаешь, не знаешь. Думаю зависит от компании, в которую устраиваешься. Как было у Вас, лично?Вы правы, это зависит от компании и от конкретного руководителя, к которому вы попадёте. Кстати, будете на собеседовании - там и спросите, какими будут ваши первые рабочие дни, и какие задачи вас ждут на старте - там вам ответят точнее. 🙂
Первые дни (а то и недели) на новой работе обычно «тупят» все - и джуны, и даже сеньоры. Вы будете подписывать кипу разных бумаг, настраивать окружение на компе, получать доступы.
А дальше всё по-разному. Вы джун, вероятно, у вас будет наставник, который будет вводить в курс дела и помогать. Или же обязанность наставника будет размазана между разными коллегами. Адекватные коллеги понимают, что вам нужно время, чтобы войти в рабочие процессы и начать приносить пользу и не станут осуждать за «тупеж». Главное - не тупить вечно.
Какие задачи и как быстро вы получите зависит от руководителя и его подхода. Вам могут для начала давать небольшие задачки, и постепенно наращивать их сложность. Цель - сделать из вас самостоятельного сотрудника, который не будет постоянно тянуть за рукав «старших». И чем быстрее вы начнете превращаться в такого сотрудника - тем лучшее впечатление произведете.
У меня было иначе. Просить помощи особо было не у кого, конкретику, с которой мне нужно было работать, никто не знал. Сотрудник, который раньше занимался моим проектом уже давно уволился, так что вот тебе исходный код - разбирайся сама. Документации нет, комментариев в коде тоже. 🙂 По срокам никто не торопил, кнутом не погонял, в загривок не дышал. Но в целом подход был - выкинуть на середину озера, чтобы научить плавать. Так что пришлось выплывать как-то самой. Первое время мозг закипал от напряжения, вечерами болела голова и я даже начинала запинаться в речи из-за переутомления. А потом разобралась, и стало проще. Оказалось, что ничего страшного.
В таком подходе к новым сотрудникам есть и плюсы и минусы. С одной стороны, быстрее учишься самостоятельно погружаться в проект и работать над проблемой, и, если «научишься плавать», а не утонешь - то выплывешь уже относительно зрелым специалистом. С другой стороны, мой код тогда никто не ревьюил, контроля над качеством работы не было, так что можно было накостылить как попало (а так, скорее всего, я и делала тогда) - и никто не поправит, не посоветует, как сделать лучше. Так что в каком-то смысле так выращивают говнокодеров велосипедостроителей.
Так чаще бывает в компаниях с небольшим штатом и хаотической организацией работы, где людей в принципе мало, и потому каждый сотрудник - и швец, и жнец и на дуде игрец. На каждого сотрудника там приходится куча разнообразных обязанностей, и карьерный рост до какого-нибудь руководителя будет довольно быстрым. Работать в таких местах - это челлендж, так как нужно все схватывать на лету, учиться особо не у кого, а круг обязанностей четко не очерчен. И работа имеет более творческий и менее регламентированный характер.
В более крупных компаниях с отлаженной структурой и четким разделением обязанностей вы будете в большей мере винтиком, который приладят на специально предусмотренное для него место. И в этом есть свои плюсы. В таких компаниях могут быть хорошо настроены бизнес-процессы, каждый сотрудник хорошо представлять, какие обязанности входят в его зону ответственности, и какими компетенциями ему нужно обладать. И, что главное, в хороших больших компаниях есть свои выработанные best practices, и вы будете прямо на старте их впитывать и применять в своей работе. А не костылить как бог на душу положит.
Мне 25/35/40 лет. Не поздно ли уже учиться программировать?
Знаете, это вопрос не столько ко мне, сколько к вам самим. Считаете ли вы сами свой возраст точкой невозврата, после которой уже поздно что-либо менять, учиться новым навыкам и осваивать другие профессии? Или уже пришло время окопаться в привычной области, и тихо-мирно доживать свои деньки?
Не будем лукавить, учиться в 16 или в 20 лет гораздо проще, чем, скажем, в 30 - это обусловленно анатомией мозга. Мозгу с возрастом свойственно приобретать некую инертность и консервироваться в своих привычках.
Но если вдуматься, то утрата пластичности мозга - это повод скорее противостоять этому процессу, чем смиряться с ним. Потому что новые знания и новые навыки - это как раз то, что позволяет мозгу дольше оставаться молодым. Он будет сопротивляться, лениться и ругаться на вас, но в итоге ему понравится, а успех в том, что раньше казалось непроходимыми джунглями - это очень вдохновляющее чувство.
Я не могу гарантировать, что в процессе вы не сдадитесь. Как и не могу гарантировать, что в индустрии к 40-летнему новичку отнесутся с доверием. Да, трудности могут возникнуть, и для их преодоления потребуются определенные усилия.
А про возраст я могу привести вам такой пример. Недавно в телеграме я познакомилась с девушкой Сашей - она, как и автор этого блога, гуманитарий по первому образованию. Какое-то время назад она оставила профессию журналистки и уехала в Германию, где сейчас изучает программирование в университете. Так вот у Саши есть однокурсница, которой (внимание!) 60 лет. И, по словам, Саши, эта однокурсница опережает её по успехам в учебе, несмотря на такой солидный возраст. Выводы делайте сами.
Кому интересна тема образования и смены квалификации в Европе - подписывайтесь на канал Саши. Тут она расскажет, как получить стипендию, об особенностях образования в Германии, о её отношениях с программированием, об адаптации к жизни за границей, о смене гуманитарной специальности на техническую и заодно - о свиданиях - но это уже совсем другая история.
Знаете, это вопрос не столько ко мне, сколько к вам самим. Считаете ли вы сами свой возраст точкой невозврата, после которой уже поздно что-либо менять, учиться новым навыкам и осваивать другие профессии? Или уже пришло время окопаться в привычной области, и тихо-мирно доживать свои деньки?
Не будем лукавить, учиться в 16 или в 20 лет гораздо проще, чем, скажем, в 30 - это обусловленно анатомией мозга. Мозгу с возрастом свойственно приобретать некую инертность и консервироваться в своих привычках.
Но если вдуматься, то утрата пластичности мозга - это повод скорее противостоять этому процессу, чем смиряться с ним. Потому что новые знания и новые навыки - это как раз то, что позволяет мозгу дольше оставаться молодым. Он будет сопротивляться, лениться и ругаться на вас, но в итоге ему понравится, а успех в том, что раньше казалось непроходимыми джунглями - это очень вдохновляющее чувство.
Я не могу гарантировать, что в процессе вы не сдадитесь. Как и не могу гарантировать, что в индустрии к 40-летнему новичку отнесутся с доверием. Да, трудности могут возникнуть, и для их преодоления потребуются определенные усилия.
А про возраст я могу привести вам такой пример. Недавно в телеграме я познакомилась с девушкой Сашей - она, как и автор этого блога, гуманитарий по первому образованию. Какое-то время назад она оставила профессию журналистки и уехала в Германию, где сейчас изучает программирование в университете. Так вот у Саши есть однокурсница, которой (внимание!) 60 лет. И, по словам, Саши, эта однокурсница опережает её по успехам в учебе, несмотря на такой солидный возраст. Выводы делайте сами.
Кому интересна тема образования и смены квалификации в Европе - подписывайтесь на канал Саши. Тут она расскажет, как получить стипендию, об особенностях образования в Германии, о её отношениях с программированием, об адаптации к жизни за границей, о смене гуманитарной специальности на техническую и заодно - о свиданиях - но это уже совсем другая история.
Отдыхайте
Сейчас Интернет кишит разными советами про тайм-менеджмент, повышение эффективности и саморазвитие семимильными шагами. Как инструменты это всё местами применимо и полезно, но как идеология - достаточно опасно.
Отчаянно рвать попу ради того, чтобы выжать из себя максимум эффективности, чтобы каждую секунду своей жизни смиренно принести на алтарь Капитализма.
Вот только чрезмерная страсть и перфекционизм на этом пути чреваты переутомлением, выгоранием, неврозами, обострением хронических болезней (и появлением новых), депрессией и прочими «радостями» жизни. Не успевая за высокими стандартами, которые мы сами себе задаём, мы испытываем чувство вины и вгоняем себя в стресс.
Мне рассказывали про коллегу, который работал по 16 часов в день и заработал себе инсульт - и это в 30-летнем возрасте. Чувак выжил и… продолжил работать по 16 часов.
Профессиональные успехи, деньги, крутые скиллы и прочие ачивки окажутся не такими уж ценными, если здоровье - и физическое, и психическое - разрушено.
Поэтому, друзья, знайте меру - умейте замедлиться, отдохнуть, и даже потупить. Не надо пытаться впихнуть в каждую секунду жизни что-то полезное и эффективное. Если ощущаете дефицит ресурсов и пониженную мотивацию - не грызите себя за это. Нам всем необходимо восстановление. А бесконечное достигаторство уровня «белка в колесе» в долговременной перспективе - скорее вредно для конечного результата.
Сейчас Интернет кишит разными советами про тайм-менеджмент, повышение эффективности и саморазвитие семимильными шагами. Как инструменты это всё местами применимо и полезно, но как идеология - достаточно опасно.
Отчаянно рвать попу ради того, чтобы выжать из себя максимум эффективности, чтобы каждую секунду своей жизни смиренно принести на алтарь Капитализма.
Вот только чрезмерная страсть и перфекционизм на этом пути чреваты переутомлением, выгоранием, неврозами, обострением хронических болезней (и появлением новых), депрессией и прочими «радостями» жизни. Не успевая за высокими стандартами, которые мы сами себе задаём, мы испытываем чувство вины и вгоняем себя в стресс.
Мне рассказывали про коллегу, который работал по 16 часов в день и заработал себе инсульт - и это в 30-летнем возрасте. Чувак выжил и… продолжил работать по 16 часов.
Профессиональные успехи, деньги, крутые скиллы и прочие ачивки окажутся не такими уж ценными, если здоровье - и физическое, и психическое - разрушено.
Поэтому, друзья, знайте меру - умейте замедлиться, отдохнуть, и даже потупить. Не надо пытаться впихнуть в каждую секунду жизни что-то полезное и эффективное. Если ощущаете дефицит ресурсов и пониженную мотивацию - не грызите себя за это. Нам всем необходимо восстановление. А бесконечное достигаторство уровня «белка в колесе» в долговременной перспективе - скорее вредно для конечного результата.
Про экспертов-новичков
Однажды я наткнулась на статью на Хабре про такого зверя как expert beginner. И сразу заподозрила, что речь идёт обо мне. Это был первый пинок к смене работы.
Экспертом-новичком становишься, когда долго работаешь в одном месте, хорошо знаешь свои проекты и по меркам своей нынешней (часто небольшой) компании начинаешь считаться местным экспертом. Самому учиться здесь не у кого, у тебя самого уже начинают появляться подчиненные… и перенимать твои практики и излюбленные приёмы работы.
В чём тут подвох? В том, что ты всё ещё новичок, и тебе есть чему учиться. Но вместо этого ты начинаешь считаться (и сам считать себя) уже знающим специалистом и перестаёшь развиваться. У тебя есть свои любимые привычные подходы к работе. Подходы далеко не лучшие, может быть, сплошные костыли и велосипедостроение - но ты к ним привык, и относишься как к лучшим практикам. Другие люди в компании не разбираются в твоих проектах, и просто доверяют тебе как лучшему специалисту. В итоге твои не самые удачные решения принимаются как устоявшиеся и правильные подходы и используются снова и снова, в том числе вновь пришедшими молодыми специалистами.
Когда я устроилась на ту работу, у меня был нулевой опыт разработки на реальных проектах. Код я писала как умела и как получалось. Хороший он или нет - судить было некому, так как никто мой код не ревьюил и в глаза не видел. Так что решения о том, что хорошо, а что плохо приходилось принимать самостоятельно, наступая на грабли и учась на своих ошибках. И вот работала я так, работала, и однажды я уже - типо старший специалист, и у меня уже даже появились свои джуниоры. А я тогда даже тестов к своему коду не писала.
Но я вполне себе догадывалась, что это только по меркам нашей «сельской библиотеки» я сеньор-разработчик. А кто я на реальном рынке? Что я знаю о том, как устроены процессы и разработка в более современных и топовых компаниях (кроме того, что слышала о них на конференциях)? Что я вообще знаю о best practices в IT? Умею ли я вообще писать код?
До тех пор я занималась проектами, от которых напрямую не зависели пользователи. Даже если бы я там всё сломала и разнесла на части - пользователи бы этого даже не заметили и урон для компании был бы не таким уж значительным. Так что оставалось ощущение, что я всё ещё ковыряюсь в песочнице и пока не добралась до настоящей ответственной боевой разработки. И костылить в таких условиях можно было как угодно. Поэтому мне захотелось в настоящий продакшен. Чтобы почувствовать себя настоящим взрослым специалистом. А не преждевременным экспертом.
Тогда я сменила работу. Конечно, к тому были и иные причины.
Однажды я наткнулась на статью на Хабре про такого зверя как expert beginner. И сразу заподозрила, что речь идёт обо мне. Это был первый пинок к смене работы.
Экспертом-новичком становишься, когда долго работаешь в одном месте, хорошо знаешь свои проекты и по меркам своей нынешней (часто небольшой) компании начинаешь считаться местным экспертом. Самому учиться здесь не у кого, у тебя самого уже начинают появляться подчиненные… и перенимать твои практики и излюбленные приёмы работы.
В чём тут подвох? В том, что ты всё ещё новичок, и тебе есть чему учиться. Но вместо этого ты начинаешь считаться (и сам считать себя) уже знающим специалистом и перестаёшь развиваться. У тебя есть свои любимые привычные подходы к работе. Подходы далеко не лучшие, может быть, сплошные костыли и велосипедостроение - но ты к ним привык, и относишься как к лучшим практикам. Другие люди в компании не разбираются в твоих проектах, и просто доверяют тебе как лучшему специалисту. В итоге твои не самые удачные решения принимаются как устоявшиеся и правильные подходы и используются снова и снова, в том числе вновь пришедшими молодыми специалистами.
Когда я устроилась на ту работу, у меня был нулевой опыт разработки на реальных проектах. Код я писала как умела и как получалось. Хороший он или нет - судить было некому, так как никто мой код не ревьюил и в глаза не видел. Так что решения о том, что хорошо, а что плохо приходилось принимать самостоятельно, наступая на грабли и учась на своих ошибках. И вот работала я так, работала, и однажды я уже - типо старший специалист, и у меня уже даже появились свои джуниоры. А я тогда даже тестов к своему коду не писала.
Но я вполне себе догадывалась, что это только по меркам нашей «сельской библиотеки» я сеньор-разработчик. А кто я на реальном рынке? Что я знаю о том, как устроены процессы и разработка в более современных и топовых компаниях (кроме того, что слышала о них на конференциях)? Что я вообще знаю о best practices в IT? Умею ли я вообще писать код?
До тех пор я занималась проектами, от которых напрямую не зависели пользователи. Даже если бы я там всё сломала и разнесла на части - пользователи бы этого даже не заметили и урон для компании был бы не таким уж значительным. Так что оставалось ощущение, что я всё ещё ковыряюсь в песочнице и пока не добралась до настоящей ответственной боевой разработки. И костылить в таких условиях можно было как угодно. Поэтому мне захотелось в настоящий продакшен. Чтобы почувствовать себя настоящим взрослым специалистом. А не преждевременным экспертом.
Тогда я сменила работу. Конечно, к тому были и иные причины.
-
Конечно. Нет ничего зазорного в том, чтобы быть просто новичком. Но новичок, который считает себя экспертом - это уже искаженное восприятие самого себя. Из этого искажения рождаются неверные установки из серии «я лучше знаю», «я это делаю n лет, мне виднее», и «я и так знаю, как делать правильно, зачем мне учиться/спрашивать чье-то мнение» итд итп. А все привычные лично ему решения кажутся оптимальными - не потому что они таковыми являются, а потому что «я всегда так делал». А на самом деле ничего ты не знаешь, Джон Сноу.
А если разобраться - то почему он всегда так делал? Сначала не знал, как можно делать - придумал какое-то решение. С тех пор использует его и привык к нему. И к тому же стал невосприимчив к альтернативным подходам. В общем, получается такой неповоротливый консерватор и в худшем случае - самодур.
Я, конечно, утрирую. И всё сильно зависит от адекватности конкретного человека. А посыл поста был в том, что не стоит спешить надевать корону и почивать на лаврах. Даже если у вас хороший авторитет среди коллег. Задайте себе вопрос - а ̶к̶т̶о̶ ̶я̶ ̶б̶е̶з̶ ̶к̶о̶с̶т̶ю̶м̶а̶ кем бы я был в другой компании (гугле/яндексе/подставьте другое известное название)? В стартапе из 5-ти человек вы, возможно, действительно - лучший. Но так ли вы круты по меркам всего рынка?
Кто-то остаётся на должности «эксперта», потому что ему нравится наслаждаться своим авторитетом и вертикальным карьерным ростом. И это тоже выбор - у всех свои приоритеты. Есть еще вариант - оставить разработку и уходить целиком в управленческие задачи, тогда экспертиза уже и не так важна. Мне же хотелось расти в техническом плане и чувствовать себя заслуженно… ну хотя бы нормальным средним специалистом, а не псевдоэкспертом с завышенным чсв.
А в итоге - если ты новичок-эксперт, это замедляет развитие?Конечно. Нет ничего зазорного в том, чтобы быть просто новичком. Но новичок, который считает себя экспертом - это уже искаженное восприятие самого себя. Из этого искажения рождаются неверные установки из серии «я лучше знаю», «я это делаю n лет, мне виднее», и «я и так знаю, как делать правильно, зачем мне учиться/спрашивать чье-то мнение» итд итп. А все привычные лично ему решения кажутся оптимальными - не потому что они таковыми являются, а потому что «я всегда так делал». А на самом деле ничего ты не знаешь, Джон Сноу.
А если разобраться - то почему он всегда так делал? Сначала не знал, как можно делать - придумал какое-то решение. С тех пор использует его и привык к нему. И к тому же стал невосприимчив к альтернативным подходам. В общем, получается такой неповоротливый консерватор и в худшем случае - самодур.
Я, конечно, утрирую. И всё сильно зависит от адекватности конкретного человека. А посыл поста был в том, что не стоит спешить надевать корону и почивать на лаврах. Даже если у вас хороший авторитет среди коллег. Задайте себе вопрос - а ̶к̶т̶о̶ ̶я̶ ̶б̶е̶з̶ ̶к̶о̶с̶т̶ю̶м̶а̶ кем бы я был в другой компании (гугле/яндексе/подставьте другое известное название)? В стартапе из 5-ти человек вы, возможно, действительно - лучший. Но так ли вы круты по меркам всего рынка?
Кто-то остаётся на должности «эксперта», потому что ему нравится наслаждаться своим авторитетом и вертикальным карьерным ростом. И это тоже выбор - у всех свои приоритеты. Есть еще вариант - оставить разработку и уходить целиком в управленческие задачи, тогда экспертиза уже и не так важна. Мне же хотелось расти в техническом плане и чувствовать себя заслуженно… ну хотя бы нормальным средним специалистом, а не псевдоэкспертом с завышенным чсв.
-
Итак, ситуация: у вас очень уверенный в своем мнении руководитель, но у вас его подход к работе вызывает сомнения.
Тут, конечно, многое сильно зависит от адекватности конкретного руководителя и умения слушать аргументы.
Я считаю, что действовать тут надо исключительно путём рациональной аргументации - забыв про сложный характер, про то, где чье мнение и где чей авторитет.
Излагаете руководителю, почему его решение вам кажется не оптимальным: например, из-за не рационального расходования ресурсов (память, диск, цпу, деньги компании), или человеческих ресурсов (время на разработку ненужной фичи). И приводите аргументы в пользу своего решения - здесь нам не понадобится дополнительный сервер, время ожидания пользователей не возрастёт, не нужно будет нанимать нового сотрудника (итд ип). Чисто голые факты, никаких личностей и меряний питонами.
Адекватный руководитель всегда выслушает ваши сомнения и аргументы. Возможно, он их сможет опровергнуть или приведёт свои соображения.
Если же начальник остался при своем мнении - то не стоит переживать. Потому что ответственность за принятое решение и за его последствия - тоже на нём. В принципе мы всегда делаем всё так, как решило руководство - такая судьба у наёмных работников. Другое дело, что аргументировать и переубеждать начальство - это полезный и важный навык.
Если же начальник, простите, совсем «баран», и никого никогда не слушает, то возникает вопрос - а хотите ли вы работать с таким человеком? Может, имеет смысл поискать варианты с переводом в другую команду, другой отдел или даже сменить работодателя?
Как спорить с такими грозными [начальниками]? Отстаивать свое мнение. Не принимая во внимание сложный характер, может есть какой-то лайфхак?Итак, ситуация: у вас очень уверенный в своем мнении руководитель, но у вас его подход к работе вызывает сомнения.
Тут, конечно, многое сильно зависит от адекватности конкретного руководителя и умения слушать аргументы.
Я считаю, что действовать тут надо исключительно путём рациональной аргументации - забыв про сложный характер, про то, где чье мнение и где чей авторитет.
Излагаете руководителю, почему его решение вам кажется не оптимальным: например, из-за не рационального расходования ресурсов (память, диск, цпу, деньги компании), или человеческих ресурсов (время на разработку ненужной фичи). И приводите аргументы в пользу своего решения - здесь нам не понадобится дополнительный сервер, время ожидания пользователей не возрастёт, не нужно будет нанимать нового сотрудника (итд ип). Чисто голые факты, никаких личностей и меряний питонами.
Адекватный руководитель всегда выслушает ваши сомнения и аргументы. Возможно, он их сможет опровергнуть или приведёт свои соображения.
Если же начальник остался при своем мнении - то не стоит переживать. Потому что ответственность за принятое решение и за его последствия - тоже на нём. В принципе мы всегда делаем всё так, как решило руководство - такая судьба у наёмных работников. Другое дело, что аргументировать и переубеждать начальство - это полезный и важный навык.
Если же начальник, простите, совсем «баран», и никого никогда не слушает, то возникает вопрос - а хотите ли вы работать с таким человеком? Может, имеет смысл поискать варианты с переводом в другую команду, другой отдел или даже сменить работодателя?
Как понять, что IT - это «моё»?
Наверное, легче всего выбирать профориентацию людям, у которых есть выраженные предпочтения или мечта о какой-то конкретной профессии.
Я к числу таких никогда не принадлежала. «Призвание» для меня слишком громкое слово, отдающее фатализмом. Думаю, существуют десятки профессий, которыми я бы могла заниматься примерно с одинаковым успехом.
Долгих по протяженности увлечений у меня тоже особо не было - интересовалась я всем подряд, многими вещами начинала заниматься, но быстро забрасывала.
Некоторые люди выбирают профессиональную область исходя из того, какие предметы им хуже всего давались в школе. Не получалось с математикой - ну значит у меня гуманитарный склад ума, пойду изучать литературу. Не смог понять физику или химию - значит, главное держаться от них подальше.
Проблема с этим подходом в том, что неприятие каких-либо предметов в школе могло быть связано с кучей случайных факторов - преподаватель не смог заинтересовать своим предметом, плохая подача материала в учебниках, неудачно составленное расписание, просто как-то не заинтересовало или как-то быстро упустил материал и дальше уже ничего не понял. В любом случае, это не повод относиться к таким предметам как к закрытой для себя отныне области знаний.
То, что меня может в каком-то виде интересовать IT мне никогда не приходило в голову. В школе информатика была очень слабой, уроки не вселяли энтузиазма, а какие-то зачатки бейзика и паскаля, которые там всё же пытались нам дать, я благополучно пропустила мимо себя, даже не пытаясь разобраться, что это такое. Впервые открыла для себя программирование я примерно в 23-24 летнем возрасте, и пожалуй что случайно. И всё ещё не могла решить для себя - «моё» это или «не моё».
Позже я сформулировала для себя такой принцип выбора профессии: если я могу заниматься каким-то делом 3-4 часа подряд (и более) без насилия над собой - значит, оно мне подходит. Потому что примерно так будет выглядеть каждый день жизни, когда устроишься на работу. С программированием у меня всё было именно так - закапываешься в какую-то задачу, ищешь решение, и не замечаешь, как проходит несколько часов. Никакой боли или скуки этот процесс не вызывал, наоборот - довольно увлекательно и интересно - а значит подходит, можно брать. Хотя в теории меня и пугала перспектива целыми днями копаться в коде.
А громких слов о поиске своего призвания и следовании за мечтой я до сих пор не понимаю. Вместо IT у меня могло бы легко быть что-то другое. И у вас, скорее всего, тоже. Но в наше время это одна из самых передовых областей, так что почему бы не выбрать её?
Наверное, легче всего выбирать профориентацию людям, у которых есть выраженные предпочтения или мечта о какой-то конкретной профессии.
Я к числу таких никогда не принадлежала. «Призвание» для меня слишком громкое слово, отдающее фатализмом. Думаю, существуют десятки профессий, которыми я бы могла заниматься примерно с одинаковым успехом.
Долгих по протяженности увлечений у меня тоже особо не было - интересовалась я всем подряд, многими вещами начинала заниматься, но быстро забрасывала.
Некоторые люди выбирают профессиональную область исходя из того, какие предметы им хуже всего давались в школе. Не получалось с математикой - ну значит у меня гуманитарный склад ума, пойду изучать литературу. Не смог понять физику или химию - значит, главное держаться от них подальше.
Проблема с этим подходом в том, что неприятие каких-либо предметов в школе могло быть связано с кучей случайных факторов - преподаватель не смог заинтересовать своим предметом, плохая подача материала в учебниках, неудачно составленное расписание, просто как-то не заинтересовало или как-то быстро упустил материал и дальше уже ничего не понял. В любом случае, это не повод относиться к таким предметам как к закрытой для себя отныне области знаний.
То, что меня может в каком-то виде интересовать IT мне никогда не приходило в голову. В школе информатика была очень слабой, уроки не вселяли энтузиазма, а какие-то зачатки бейзика и паскаля, которые там всё же пытались нам дать, я благополучно пропустила мимо себя, даже не пытаясь разобраться, что это такое. Впервые открыла для себя программирование я примерно в 23-24 летнем возрасте, и пожалуй что случайно. И всё ещё не могла решить для себя - «моё» это или «не моё».
Позже я сформулировала для себя такой принцип выбора профессии: если я могу заниматься каким-то делом 3-4 часа подряд (и более) без насилия над собой - значит, оно мне подходит. Потому что примерно так будет выглядеть каждый день жизни, когда устроишься на работу. С программированием у меня всё было именно так - закапываешься в какую-то задачу, ищешь решение, и не замечаешь, как проходит несколько часов. Никакой боли или скуки этот процесс не вызывал, наоборот - довольно увлекательно и интересно - а значит подходит, можно брать. Хотя в теории меня и пугала перспектива целыми днями копаться в коде.
А громких слов о поиске своего призвания и следовании за мечтой я до сих пор не понимаю. Вместо IT у меня могло бы легко быть что-то другое. И у вас, скорее всего, тоже. Но в наше время это одна из самых передовых областей, так что почему бы не выбрать её?
О чем спросят на техническом собеседовании?
Тут всё всецело зависит от собеседующего и его ̶з̶а̶с̶к̶о̶к̶о̶в̶ взглядов.
Например, один мой бывший коллега заставлял кандидатов рисовать график логарифма на листочке. Зачем, спросите вы? По его мнению это должно показать, что кандидат отличает эффективные алгоритмы от неэффективных (то есть логарифмическую скорость выполнения от, например, экспоненциальной). Другой коллега возражал ему, что успешность выполнения этого задания скорее покажет, что кандидат - недавний студент, и ничего более.
Тем, кто даёт «задачки на сообразительность» я бы приготовила личный котел в аду. Просто потому что их не люблю, и никто еще не доказал, что с их помощью можно проверить хоть что-то.
Везде, разумеется, зададут вопросы (или задачку) на знание вашего языка программирования. Вопросы могут быть базовые на знание основ, но кто-то любит копать и в тонкости: например, питониста могут попросить написать декоратор и генератор и поинтересуются, что такое метакласс. И да, не исключено, что после собеседования на этом месте работы вы ни разу больше не напишете ни декоратор, ни генератор (или 1-2 раза за 5 лет), и, тем более, никогда не столкнётесь с метаклассами. Именно поэтому такие задачки считаются очень спорными.
Есть еще стандартный список вопросов для каждого языка - они легко гуглятся вместе с ответами на них. Для питона, например, это «что такое GIL» и «как работает garbage collector»? Проблема с такими вопросами в том, что кандидаты часто выучивают ответы чуть ли не наизусть. Но проницательный работодатель догадается задать уточняющие вопросы и копнуть чуть глубже, чтобы понять - действительно ли кандидат знает, о чем говорит или загуглил список типичных вопросов перед собеседованием. Кто-то же намеренно избегает расхожих вопросов. Ну а кто-то примет тупо выученные ответы за чистую монету. Лично я, кстати, ни разу не готовилась к собеседованиям специально - говорят, почти все готовятся - ну а мне это в голову не приходило, и ничего. Я, конечно, никого не призывают брать с меня пример в этом смысле.
На счёт алгоритмов тоже кипят споры - надо или не надо про них спрашивать? Если спрашивать - то, наверно, про самые простые? Отсортируй массив «пузырьком». Вот только зачем «пузырьком»? Я не уверена, что сходу вспомню, чем там этот пузырек отличается от сортировки вставками, а та от сортировки выбором. Да и кому они нужны, эти типы сортировок, они же все с квадратичной сложностью. Но просить реализовать на собесе merge sort или quick sort - это уже сложновато. Поэтому «пузырёк». «А сколько раз в своей работе ты использовал эти алгоритмы? Ни разу, верно?» - спрашивает один коллега другого, сторонника таких вопросов.
В целом я бы разделила всех собеседующих на Знаек и Незнаек. Знайки убеждены, что любой кандидат должен знать всё, если не более того. Написать на бумажке реализацию красно-черного дерева - раз плюнуть, знать ассемблер, C++ и устройство микроконтроллеров - маст хэв. И пофиг, что чувак пришел сайты писать на, прости господи, PHP. Ещё он должен уметь написать накопленную сумму на чистом SQL, знать все мыслимые и немыслимые разделы высшей математики на 5+ ну и, конечно, уметь летать.
Незнайки же возражают, что все эти знания не потребуются для решения тех прикладных задач, с которыми предстоит столкнуться кандидату, и потому требовать их - не нужно, и к тому же они не показывают, что чувак действительно хороший специалист. Но Знаек, конечно, не переубить: хороший программист должен знать всё это, иначе он - так, пустое место, а не программист.
Но не пугайтесь - знаек не так уж много. И лично я с вопросами такой сложности на собеседованиях ни разу не сталкивалась. Найти кандидата, подходящего под критерии таких Знаек сложнее, чем найти любовь всей жизни с первой попытки в Тиндере. Поэтому нереалистичные требования в итоге приходится смягчать (если, конечно, работодатель не Павел Дуров). Конечно, круто, если у вас сильная база, но если вы не во всем сильны - это не беда. Работы на всех хватит.
Тут всё всецело зависит от собеседующего и его ̶з̶а̶с̶к̶о̶к̶о̶в̶ взглядов.
Например, один мой бывший коллега заставлял кандидатов рисовать график логарифма на листочке. Зачем, спросите вы? По его мнению это должно показать, что кандидат отличает эффективные алгоритмы от неэффективных (то есть логарифмическую скорость выполнения от, например, экспоненциальной). Другой коллега возражал ему, что успешность выполнения этого задания скорее покажет, что кандидат - недавний студент, и ничего более.
Тем, кто даёт «задачки на сообразительность» я бы приготовила личный котел в аду. Просто потому что их не люблю, и никто еще не доказал, что с их помощью можно проверить хоть что-то.
Везде, разумеется, зададут вопросы (или задачку) на знание вашего языка программирования. Вопросы могут быть базовые на знание основ, но кто-то любит копать и в тонкости: например, питониста могут попросить написать декоратор и генератор и поинтересуются, что такое метакласс. И да, не исключено, что после собеседования на этом месте работы вы ни разу больше не напишете ни декоратор, ни генератор (или 1-2 раза за 5 лет), и, тем более, никогда не столкнётесь с метаклассами. Именно поэтому такие задачки считаются очень спорными.
Есть еще стандартный список вопросов для каждого языка - они легко гуглятся вместе с ответами на них. Для питона, например, это «что такое GIL» и «как работает garbage collector»? Проблема с такими вопросами в том, что кандидаты часто выучивают ответы чуть ли не наизусть. Но проницательный работодатель догадается задать уточняющие вопросы и копнуть чуть глубже, чтобы понять - действительно ли кандидат знает, о чем говорит или загуглил список типичных вопросов перед собеседованием. Кто-то же намеренно избегает расхожих вопросов. Ну а кто-то примет тупо выученные ответы за чистую монету. Лично я, кстати, ни разу не готовилась к собеседованиям специально - говорят, почти все готовятся - ну а мне это в голову не приходило, и ничего. Я, конечно, никого не призывают брать с меня пример в этом смысле.
На счёт алгоритмов тоже кипят споры - надо или не надо про них спрашивать? Если спрашивать - то, наверно, про самые простые? Отсортируй массив «пузырьком». Вот только зачем «пузырьком»? Я не уверена, что сходу вспомню, чем там этот пузырек отличается от сортировки вставками, а та от сортировки выбором. Да и кому они нужны, эти типы сортировок, они же все с квадратичной сложностью. Но просить реализовать на собесе merge sort или quick sort - это уже сложновато. Поэтому «пузырёк». «А сколько раз в своей работе ты использовал эти алгоритмы? Ни разу, верно?» - спрашивает один коллега другого, сторонника таких вопросов.
В целом я бы разделила всех собеседующих на Знаек и Незнаек. Знайки убеждены, что любой кандидат должен знать всё, если не более того. Написать на бумажке реализацию красно-черного дерева - раз плюнуть, знать ассемблер, C++ и устройство микроконтроллеров - маст хэв. И пофиг, что чувак пришел сайты писать на, прости господи, PHP. Ещё он должен уметь написать накопленную сумму на чистом SQL, знать все мыслимые и немыслимые разделы высшей математики на 5+ ну и, конечно, уметь летать.
Незнайки же возражают, что все эти знания не потребуются для решения тех прикладных задач, с которыми предстоит столкнуться кандидату, и потому требовать их - не нужно, и к тому же они не показывают, что чувак действительно хороший специалист. Но Знаек, конечно, не переубить: хороший программист должен знать всё это, иначе он - так, пустое место, а не программист.
Но не пугайтесь - знаек не так уж много. И лично я с вопросами такой сложности на собеседованиях ни разу не сталкивалась. Найти кандидата, подходящего под критерии таких Знаек сложнее, чем найти любовь всей жизни с первой попытки в Тиндере. Поэтому нереалистичные требования в итоге приходится смягчать (если, конечно, работодатель не Павел Дуров). Конечно, круто, если у вас сильная база, но если вы не во всем сильны - это не беда. Работы на всех хватит.
За офисный планктон замолвлю слово
В последнее время часто слышу, как из каждого утюга ругают работу в офисе, и призывают всех уходить во фриланс.
И, с одной стороны, эта точка зрения понятна - думаю, каждый из вас, кто когда-либо работал в офисах знает, какие в этом недостатки, и как многое там может раздражать и демотивировать.
Но у (хорошего) офиса есть и плюсы, давайте не будем забывать об этом. Да и во фрилансе тоже не всё мёдом намазано.
Так что сегодняшний мой пост про преимущества работы в офисе:
1. Общение с коллегами. Общение - это базовая потребность психики, и это я вам говорю как интроверт со стажем. Психологи говорят, что люди, например, с шизоидными чертами личности - которым общение ну совсем не даётся - часто страдают депрессиями именно за счет не удовлетворения этой потребности, даже если они её и не осознают. И еще социальные скиллы надо прокачивать, они требуются в самых разных жизненных обстоятельствах. С мозгом ведь всё так же как и со спортом - если не тренируешь, навык падает. И да, многие работодатели уже приходят к тому, что специалисты с развитыми навыками коммуникации ценнее, чем одинокие гении. Потому что, ну знаете, с одиночками сложно договориться даже по рабочим моментам. Общаться, конечно, можно и в мессенджерах, и по видеосвязи, но имхо такое общение уступает личному контакту. Офис часто критикуют за то, что люди там часто отвлекаются на кофебрейки и тому подобные «бесполезные» вещи. Я не считаю, что переключение внимания/отдых и общение (см пункт 1) - это бесполезные вещи.
2. Командная работа. Очень часто задачи, с которыми мы сталкиваемся, решаются совместными усилиями, а не кем-то в одиночку. Технические решения, архитектура приложения не отдаются на откуп одному разработчику, а обсуждаются и прорабатываются вместе. И это хорошо. Когда ты делаешь всю задачу сам, ни с кем не советуясь и не вынося на обсуждение принятые решения, ты почти наверняка упускаешь важные детали, а коллеги могут увидеть и указать тебе на недостатки выбранного решения, и на моменты, которые ты не учел. Так что всякие мозговые штурмы и архитектурные комитеты - полезная штука, как и просто возможность в любой момент посоветоваться с коллегами (особенно если ты новичок). Опять-таки, удаленно общаться - тоже можно. Но удаленно коммуникации будет меньше, и там, где в офисе ты бы наверняка посоветовался с коллегой, который сидит рядом - из дома ты часто будешь принимать решение сам. Почему-то очная коммуникация эффективнее телефонного звонка, переписки или видеоконференций. Включенности что ли больше. Ведь именно способность к коллектиной работе и объединению усилий и стали причиной появления всех цивилизаций.
3. Перенимание опыта. На работе можно встретить классных профессионалов, и учиться у них (удаленно осуществить такое сложнее). Это могут быть и очень сильные технические специалисты, и менеджеры, и люди с развитыми soft-скиллами. Наблюдаешь, например, за начальником отдела, и видишь, как он умело общается с подчиненными, как умеет к каждому найти индивиуальный подход и замотивировать. И учишься у него этим навыками. Смотришь на других руководителей и понимаешь, какие именно личностные качества и знания позволяют ими управлять людьми и разруливать разные ситуации, добиваться высоких результатов. И так ты тоже приобретаешь некоторые компетенции рукводителя. Да, разумеется, речь идёт именно о сильных профессионалах, если таких у вас на работе нет - то есть вероятность, что ловить там действительно особо нечего.
4. Вдохновение. Если вы попали в хорошую дружную команду, которая горит своим проектом, да еще и сильна технически - эти люди станут вашим вдохновением для того, чтобы расти и развиваться.
Так что офис может быть не таким уж плохим местом, потому что офис - это не бетонная коробка, офис - это люди, с которыми мы работаем, и если люди там классные, то и работа будет в радость (по крайней мере первые пару лет 🙂 )
В последнее время часто слышу, как из каждого утюга ругают работу в офисе, и призывают всех уходить во фриланс.
И, с одной стороны, эта точка зрения понятна - думаю, каждый из вас, кто когда-либо работал в офисах знает, какие в этом недостатки, и как многое там может раздражать и демотивировать.
Но у (хорошего) офиса есть и плюсы, давайте не будем забывать об этом. Да и во фрилансе тоже не всё мёдом намазано.
Так что сегодняшний мой пост про преимущества работы в офисе:
1. Общение с коллегами. Общение - это базовая потребность психики, и это я вам говорю как интроверт со стажем. Психологи говорят, что люди, например, с шизоидными чертами личности - которым общение ну совсем не даётся - часто страдают депрессиями именно за счет не удовлетворения этой потребности, даже если они её и не осознают. И еще социальные скиллы надо прокачивать, они требуются в самых разных жизненных обстоятельствах. С мозгом ведь всё так же как и со спортом - если не тренируешь, навык падает. И да, многие работодатели уже приходят к тому, что специалисты с развитыми навыками коммуникации ценнее, чем одинокие гении. Потому что, ну знаете, с одиночками сложно договориться даже по рабочим моментам. Общаться, конечно, можно и в мессенджерах, и по видеосвязи, но имхо такое общение уступает личному контакту. Офис часто критикуют за то, что люди там часто отвлекаются на кофебрейки и тому подобные «бесполезные» вещи. Я не считаю, что переключение внимания/отдых и общение (см пункт 1) - это бесполезные вещи.
2. Командная работа. Очень часто задачи, с которыми мы сталкиваемся, решаются совместными усилиями, а не кем-то в одиночку. Технические решения, архитектура приложения не отдаются на откуп одному разработчику, а обсуждаются и прорабатываются вместе. И это хорошо. Когда ты делаешь всю задачу сам, ни с кем не советуясь и не вынося на обсуждение принятые решения, ты почти наверняка упускаешь важные детали, а коллеги могут увидеть и указать тебе на недостатки выбранного решения, и на моменты, которые ты не учел. Так что всякие мозговые штурмы и архитектурные комитеты - полезная штука, как и просто возможность в любой момент посоветоваться с коллегами (особенно если ты новичок). Опять-таки, удаленно общаться - тоже можно. Но удаленно коммуникации будет меньше, и там, где в офисе ты бы наверняка посоветовался с коллегой, который сидит рядом - из дома ты часто будешь принимать решение сам. Почему-то очная коммуникация эффективнее телефонного звонка, переписки или видеоконференций. Включенности что ли больше. Ведь именно способность к коллектиной работе и объединению усилий и стали причиной появления всех цивилизаций.
3. Перенимание опыта. На работе можно встретить классных профессионалов, и учиться у них (удаленно осуществить такое сложнее). Это могут быть и очень сильные технические специалисты, и менеджеры, и люди с развитыми soft-скиллами. Наблюдаешь, например, за начальником отдела, и видишь, как он умело общается с подчиненными, как умеет к каждому найти индивиуальный подход и замотивировать. И учишься у него этим навыками. Смотришь на других руководителей и понимаешь, какие именно личностные качества и знания позволяют ими управлять людьми и разруливать разные ситуации, добиваться высоких результатов. И так ты тоже приобретаешь некоторые компетенции рукводителя. Да, разумеется, речь идёт именно о сильных профессионалах, если таких у вас на работе нет - то есть вероятность, что ловить там действительно особо нечего.
4. Вдохновение. Если вы попали в хорошую дружную команду, которая горит своим проектом, да еще и сильна технически - эти люди станут вашим вдохновением для того, чтобы расти и развиваться.
Так что офис может быть не таким уж плохим местом, потому что офис - это не бетонная коробка, офис - это люди, с которыми мы работаем, и если люди там классные, то и работа будет в радость (по крайней мере первые пару лет 🙂 )
-
Я не экстрасенс, и точно не скажу, что именно зацепило взгляд HR. Скорее всего, ей дали задание найти разработчика и ключевые слова, по которым надо искать (sql, python итд). Ключевые слова совпали с моим резюме, вот и вся загадка.
А связалась она со мной так быстро, скорее всего, потому, что на рынке IT царил и будет царить дефицит - искать людей очень сложно, и обращают внимание на всех (разве что кроме тех, у кого в резюме есть что-то откровенно отталкивающее).
-
Подчеркивать в резюме нужно всё, что вы знаете. HR-ы не экстрасенсы, и, более того, некоторые из них могут совсем не понимать предметную область. Им сказали - нужны «базы данных» - и они будут искать эти слова у вас в резюме. Не найдут - перейдут к следующему кандидату. Это во-первых. Во-вторых, это лично вам кажется, что ваши знания - сами собой разумеющиеся. Часто на собеседования приходят люди, которые ничего вообще не слышали, например, про базы данных. Ваша задача - уже в резюме выгодно выделяться на их фоне.
-
Знаете, универсального ответа тут нет. Не факт, что вы когда-то столкнётесь с Си на работе - это зависит от специфики проектов, над которыми будете работать. Например, для веб-разработки Си понадобится вряд ли. Если хотите быть в тренде (и выбирать простые пути), более востребованным может оказаться, например, Go. Но как база знание Си - это хороший навык. Когда начнёте работать, вряд ли у вас будет время и ресурсы на его изучение (если не возникнет острой необходимости). Утверждение, что вы не работали с памятью звучит немного странно - наверно, вы имели в виду, что вы не выделяли и не освобождали память явными вызовами, как это делается в Си.
-
А вы уже освоили ООП? Пишете большие классы и проектируете относительно большие программы с иерархией классов? Если да - то паттерны пригодятся. Если же вы пока на уровне небольших скриптов, или делаете всё в рамках готовых фреймворков (типа django в питоне), то паттерны на этом этапе применять будет особо негде. Это не значит, что их не стоит изучать вообще. Я лишь о том, что не факт, что это первый приоритет на этом этапе (а я даже не знаю, какой у вас этап).
Вас так быстро нашла HR прежде всего потому, что вы прошли за два года некоторое количество курсов по матану и computer science? Что ее заинтересовало в вашем резюме прежде всего? Я не экстрасенс, и точно не скажу, что именно зацепило взгляд HR. Скорее всего, ей дали задание найти разработчика и ключевые слова, по которым надо искать (sql, python итд). Ключевые слова совпали с моим резюме, вот и вся загадка.
А связалась она со мной так быстро, скорее всего, потому, что на рынке IT царил и будет царить дефицит - искать людей очень сложно, и обращают внимание на всех (разве что кроме тех, у кого в резюме есть что-то откровенно отталкивающее).
-
В ОС, протоколах и базах данных я разбираюсь, мне казалось даже странным это подчеркивать в резюме.Подчеркивать в резюме нужно всё, что вы знаете. HR-ы не экстрасенсы, и, более того, некоторые из них могут совсем не понимать предметную область. Им сказали - нужны «базы данных» - и они будут искать эти слова у вас в резюме. Не найдут - перейдут к следующему кандидату. Это во-первых. Во-вторых, это лично вам кажется, что ваши знания - сами собой разумеющиеся. Часто на собеседования приходят люди, которые ничего вообще не слышали, например, про базы данных. Ваша задача - уже в резюме выгодно выделяться на их фоне.
-
Но вот с C не сталкивался никогда, с памятью и указателями не работал. И непонятно, тратить ли на это время сейчас, пока ещё не работаю в IT.Знаете, универсального ответа тут нет. Не факт, что вы когда-то столкнётесь с Си на работе - это зависит от специфики проектов, над которыми будете работать. Например, для веб-разработки Си понадобится вряд ли. Если хотите быть в тренде (и выбирать простые пути), более востребованным может оказаться, например, Go. Но как база знание Си - это хороший навык. Когда начнёте работать, вряд ли у вас будет время и ресурсы на его изучение (если не возникнет острой необходимости). Утверждение, что вы не работали с памятью звучит немного странно - наверно, вы имели в виду, что вы не выделяли и не освобождали память явными вызовами, как это делается в Си.
-
Или лучше, например, в паттернах разобраться.А вы уже освоили ООП? Пишете большие классы и проектируете относительно большие программы с иерархией классов? Если да - то паттерны пригодятся. Если же вы пока на уровне небольших скриптов, или делаете всё в рамках готовых фреймворков (типа django в питоне), то паттерны на этом этапе применять будет особо негде. Это не значит, что их не стоит изучать вообще. Я лишь о том, что не факт, что это первый приоритет на этом этапе (а я даже не знаю, какой у вас этап).