Собеседование в зарубежную компанию

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

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

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

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

Чем мне помогло ведение канала на YouTube

Помню, что очень долго хотел создать канал на YouTube. И естественно, когда я дошёл до того, чтобы его сделать, я сделал основную тематику канала - IT. Просто потому, что я лучше разбираюсь именно в этой сфере. Что мне это дало?

Улучшилась манера изложения и формулирования мыслей
Стал лучше разбираться в том, чем я занимаюсь
В глазах потенциальных работодателей это одно из моих преимуществ
Победил страх публичных выступлений

А вот и мой YouTube канал: https://www.youtube.com/@dmitrii_gerasimov

Три вещи в разработке, которые изначально вызывали у меня недоумение

🔹Для чего нужно ООП. Изначально, когда изучали программирование в университете, мы несколько месяцев не использовали подход ООП. А потом, начали изучать все эти основные определения из ООП и переходить на данный подход. Не осознавая, на тот момент, как он сильно облегчает жизнь, мне он казался избыточным.
🔹Для чего нужен TypeScript. Довольно долгое время мне попадались проекты без TypeScript. И когда я видел, что люди добавляют типизацию, которая и так очевидна, у меня возникал вопрос: "Зачем?". Естественно, в дальнейшем я узнал, как трудно поддерживать проекты без типизации, но тогда...
🔹Зачем хуки в React. Очень долгое время, работал с React до того, как эти хуки появились. Я выучил все эти названия методов жизненного цикла. Даже сейчас их все помню, хотя не писал их несколько лет. Но когда хуки появились, то мне казалось, что изобрели что-то, что уже и так есть.

На моём текущем проекте, разработчики, которые начинали его разрабатывать, по какой-то причине приняли решение не использовать готовую библиотеку компонентов, а подключать отдельные библиотеки по мере необходимости. Всё это приводит к тому, что каждый раз приходится смотреть, какую библиотеку следует использовать. Тратится время на поиск, на установку, на тестирование. Порой, довольно нетривиальная задача, ибо большинство разработчиков используют что-то типа Material UI, Ant Design или Bootstrap, поэтому, библиотеки с каким-то отдельным компонентом, чаще всего пребывают в плачевном или заброшенном состоянии.

В какой стране можно изучать английский без проблем?

Я думаю, что не для кого не секрет, что английский для разработчика - это очень необходимый навык. Он помогает облегчить жизни и даёт дополнительные возможности. Скажу честно, что в России довольно мало возможностей его практиковать. Можно только принудительно ходить в разговорные клубы, либо изучать его онлайн. Однако, в повседневной жизни он не встречается. Идеальные условия - это использование английского в повседневной жизни. Но так сложилось, что англоязычные страны, либо требуют визу и стоимость жизни там высокая, либо в них есть проблемы с безопасностью. Так как же быть? Есть выход -- изучение английского в Сербии. Если говорить про её столицу - Белград, то здесь трудно найти человека, который плохо говорит по-английски. К тому же. тут без проблем можно задержаться надолго и стоимость жизни здесь не такая высокая.

Online codding

Я думаю, что самое неприятное в прохождении собеседований - это online codding. Довольно многим тяжело даётся написание кода в тот момент, когда на тебя смотрят. Частенько ещё просят комментировать то, что ты делаешь. И причина ясна. Когда разработчик пишет код на работе, то за этим процессом никто не наблюдает. Поэтому можно писать достаточно свободно, никто не осудит за ошибки. Раньше мне тоже было очень сложно это делать. До сих пор помню свой первый опыт около 6 лет назад, когда меня собеседовал надменный разработчик. Написать что-то я тогда не смог. Но то, что мне помогло - это изменение отношения к собеседованию. Я просто делаю то, что могу. А что не могу, то не в моих силах. И такой подход помогает мне проще относиться к любому интервью. Сейчас, online codding для меня, не проблема.

Мы хотим еще раз сказать спасибо всем, кто принял участие в нашем митапе🧡

У нас готовы фотографии с мероприятия!
Можно посмотреть и скачать по ссылке.

Будем очень рады, если пройдешь маленький опрос по мероприятию⬇️
https://forms.gle/wBTg4pPrZFWcaNbx5

Подписывайся, чтобы быть в курсе всех новостей:
Instagram | Facebook |Telegram

Трудная задача, которая не решается очень долго, приводит к мыслям о том, что какие-то проблемы в реализации библиотек, а может и веб браузера. Но на самом деле, основная причина - это собственная невнимательность. Иногда бывает, что кажется, что всё сделал правильно, но не замечаешь то, что находится на самом видном месте. Но всё же, иногда действительно бывает так, что проблема в библиотеке (про проблемы в браузере - шанс на миллион). В таком случае, особенно если библиотека известная, то всегда можно найти обращения других разработчиков, которые столкнулись с той же проблемой, на официальном Github библиотеки. За всё время работы, мне всего пару раз попадалась проблема, которая связана с багами в библиотеке. В большинстве случаев - это была просто ошибка, которую я не заметил.

Опыт во фрилансе - не опыт?

Когда я занимался наймом сотрудников для казанского отдела frontend разработки, где я был руководителем, мне часто попадались кандидаты, которые имели несколько лет опыта во фрилансе. И казалось бы, в чём проблема? А вся проблема в том, что из невозможно понять, есть ли этот опыт у кандидата или нет. Ни для кого не секрет, что школы программирования, которые выпускают огромное количество начинающих разработчиков, часто рекомендуют писать, что у них есть несколько лет опыта на фрилансе - всё равно не проверят. К тому же, если даже человек и работал на фрилансе, то чем именно он занимался? Вполне может быть, что он делал что-то, что не обладает хорошим качеством. А как часто он работал на протяжении нескольких лет? Все эти вопросы порождают кучу сомнений.

Опасность memo в React

memo - довольно мощный инструмент, который помогает избежать лишние перерисовки компонента. И если мы используем memo, то естественно для того, чтобы это имело смысл, необходимо использовать useCallback для тех случаев, когда мы будем передавать функции в качестве параметров в компоненты. Однако это кроет в себе скрытую опасность, которая может привести к непониманию, почему в некоторых случаях мы не получаем актуальные значения данных, переданных в массиве зависимостей в функции, обёрнутой в useCallback. Это происходит тогда, когда эту функцию параметр мы попробуем использовать в useEffect или в другой функции, обёрнутой в useCallback, а точнее в том случае, если мы забудем указать эту обёрнутую в useCallback функцию в массив зависимостей.

Что делать, если постановка задачи плохая?

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

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

И как же быть? В идеальном мире, просто вернуть задачу автору с комментарием. И это очень мотивирует авторов не делать так в будущем.

Но, в реальности часто бывает, что нужно писать автору. И тут мы сталкиваемся с тем, что частенько этот человек занят. И возникает ситуация, что не знаешь, сколько времени будешь ждать ответ. То ли пару минут, а может быть половину дня.

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

К чему приводит отсутствие code review?

Одно время, по какой-то причине у нас на проекте стали пропускать code review. Думаю, что просто хотели ускорить процесс разработки, дабы успеть делать релизы в срок. В результате, после пары месяцев такой работы, я обнаружил, что в коде появилось огромное количество довольно странных конструкций, а также очень запутанная логика. И тут вопрос, почему так? Вполне может быть, что причина в том, что тот разработчик, который это всё сделал, на тот момент не понимал, как правильно нужно делать. А поскольку его код не проверял, то со временем проект пришёл к тому, что компонент формы, который разрабатывался, превратился в спагетти код, который проще переписать с нуля, чем разбираться в том, почему это произошло.

Путь разработчика

Думаю, что не для кого не секрет, что документация по большинству библиотек и технологий пишется на английском языке. И думаю, что тоже не для кого не секрет, что основная масса людей, которая её читает, не является носителем английского языка. И вроде бы, это не тайна ни для кого. А если человек не носитель языка и не переводчик, то практически уверен, что их словарный запас даже близко не приближен к словарному запасу носителя. Однако, по какой-то причине, люди, которые пишут документацию, очень часто используют очень редко встречающиеся слова. И ладно бы, если бы то, что они пишут, нельзя было выразить простыми словами. В таком случае, всё понятно. Однако, основную массу редко встречающихся слов можно заменить на более распространённые. В результате, получается, что даже если ваш словарный запас довольно богатый, всё равно придётся пользоваться словарём. А при среднем словарном запасе и вовсе не будете понимать половины того, что там написано.

Путь разработчика

Когда я только начинал работать разработчиком, я очень боялся показать, что моего опыта не хватает в каких-то вещах. У меня, естественно, были пробелы в знаниях, особенно в части инструментов для командной разработки, например repository, ci / cd. И за счёт этого, у меня возникали проблемы, поскольку я, не понимаю чего-то, не говорил об этом напрямую, а пытался догадаться сам.

Когда я стал работать с начинающими специалистами, будучи senior разработчиком, я замечал, что у этих начинающих специалистов наблюдается всё та же ситуация.

Хочу сказать, что если что-то не понятно и возникает вопрос, то следует его задать. Частенько это очень сильно сэкономит время.

Путь разработчика

В университете я совсем не изучал разработку, но когда настало время выбрать специальность, я понял, что на тот момент web разработка была самым лучшим вариантом. Мне не хотелось решать какие-то упражнения, я хотел делать проекты. И я решил делать развлекательный портал. На тот момент мне казалось, что я хочу стать PHP разработчиком, поэтому я стал делать проект именно на нём. В процессе изучения, я понял, что мне интересен frontend и я сделал небольшой проект и c использованием JavaScript и React. Это также помогло мне закрепить то, что я изучил, на практике. В процессе трудоустройства, я мог показать, что я действительно что-то сделал. Также я в открытую писал в своих резюме, что я работал над своими проектами, что и было моим опытом работы. Помню, что на первом месте работы мне организовали большое review кода. Даже подумывали взять на middle позицию, но отсутствие коммерческого опыта не дало это сделать. Я считаю, что именно те проекты помогли мне найти свою первую работу.

Путь разработчика

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

Patch
String
Branch
Framework
Development
Deploy
View
Reducer
Loop
Net

Путь разработчика

Так бывает, что некоторые технологии, тебе сначала не нравятся, а потом ты осознаёшь суть и начинаешь их любить. У меня так было с Tailwind. Помню, что Tailwind был на одном из моих проектов, года 3 назад. И в тот момент мне казалось, что это крайне неудобная вещь, да и вообще, я не понимал, чем подобный подход может кому-то нравиться. Однако, недавно я задумался над тем, какой же самый лучший инструмент для работы со стилями, и друг осознал, что это именно Tailwind. Совершенно не надо создавать отдельные файлы со стилями для каждой страницы, нет ситуации, когда изменив стили в одном месте, ты сломал что-то в другом. Да, иногда бывает неочевидно, как записать тот или иной стиль, однако это бывает крайне редко. К тому же, Tailwind не заброшен и активно расширяется. Сейчас, на вопрос от том, что бы я стал использовать для стилей, я безусловно отвечу - Tailwind. Если, вдруг, Вы не пробовали использовать Tailwind, то очень рекомендую это сделать.

Путь разработчика

Мне всегда было интересно уметь делать не только frontend, но и backend. Поэтому node.js я тоже использую в своих приложениях. Почему именно node.js? Потому, что это самая популярная технология для frontend. Но вот что изучать? Проанализировав кучу вакансий на позицию full-stack разработчика, я пришёл к выводу, что сейчас популярны:

Next
Nest

Причём, трудно выделить что-то из них. Они немного разные и у них есть существенные отличия, но они оба сейчас в тренде.

Путь разработчика