Павел Новиков до 30 лет жил в Новосибирске и работал удаленно, собирая на Upwork заказы со всего мира. Один заказчик остался надолго — Паша строил для него систему почти с нуля, и маленький стартап превращался в огромную фирму. Основатели обещали большую должность, но потом передумали и просто некрасиво уволили.

Снова браться за мелкие заказы с апворка Паша не стал и впервые задумался о релокации. Так он оказался в Минске — там он собирает команду, чтобы открыть локальный офис израильской компании.

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

---

Мы выбрали из выпуска несколько цитат.

Зачем было переезжать в Минск, когда для тебя открыт весь мир

Москва и Питер по тем временам было просто дороги. Я не готов отдавать 800 баксов аренды. В Минске можно свободно получать московскую зарплату — при этом за аренду и все остальное отдавать на порядок меньше. Для меня это хороший вариант перевалочного пункта на пути, например, в Канаду.

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

Про удаленку на Upwork

С удаленкой произошла какая-то жесть. С Россией после одного случая я работать не хочу. Обычно я старался искать работу на апворке у иностранных заказчиков — я работал со многими странами, но в 2019 удаленка внезапно кончилась. Ты заходишь на апворк — а там ничего. Какие-то проекты за двести долларов с непонятными требованиями то ли от индусов, то ли от арабов. Скроллишь экрана четыре этой чепухи, отправляешь несколько откликов — выбираешь самых адекватных — и тебе тупо не отвечают. И так день за днем.

О собесах, где программистов гоняют по теоретическим вопросам

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

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

Слова ничего не стоят — покажите мне код. Если у человека есть github репозиторий — это интересно. Таких кандидатов я люблю, сразу же понятно, как проводить собеседование. Ты открываешь код проекта и говоришь, “давай разгребать, что ты тут написал”. Если это сложный проект, и кандидат может грамотно обосновать все технологические компромиссы, которые он сделал, пока разрабатывал — я его сразу возьму, без всяких теоретических вопросов.

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

Можно заниматься веселыми разговорами, но только на основе кода.

О стрессе во время интервью

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

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

О проблеме софт скиллов

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

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

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

Роль эйчара — быть медиатором. Просто усадить разрабов в кружок и сказать: “ребята, давайте я буду модерировать вашу дискуссию, чтобы вы не сорвались друг на друга”. Два-три сеанса такой семейной психотерапии для разработчиков — и конфликты рассасываются.

О работе над опенсорсом и пет-проектами

У меня в разработке три вещи:

Первая — Reinforced.Typings, крайне простая штука, которая экспортит шарповые классы в Тайпскрипт. Очень полезно, когда ты делаешь веб-приложение с бэкендом на шарпе, взял, поставил библиотечку, и все контролеры, все вью-модели, которые у тебя есть, она тебе взяла, и в течение билда экспортнула в TypeScript.

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

Дата гриды — это п…. везде, в любых компонентах. Тот, кто просто пытался сделать табличку с кнопкой “редактировать”, “добавить”, “сортировать”, знает сколько это занимает времени если делать с нуля. Если брать готовые компоненты, то они все поголовно ужасны. Я сделал хороший. Это подтвердилось уже в нескольких компаниях — ребята поиспользовали, говорят круто.

Третий проект — это Tecture. Архитектурный каркас для бизнес приложений. Все разработчики утыкаются в проблему, когда начинают писать приложения для бизнеса, начиная от авторизации до какой-то сложный логики. Как вообще такие приложения организовывать? Есть официальный гайд про unit of work и про репозитории. Но я считаю, что он говно, и на больших проектах скатывается в ад.

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

О синдроме самозванца, который не лечится

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

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

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

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

Я смотрю на свои проекты и думаю — ну и нафига я это начал? Зачем оно? А не мудак ли я?

---

Токсичный телеграм-чат подкаста