- Я опытный пользователь linux, но никогда не стояло задачи разобраться как оно работает изнутри, про большую часть системных вызовов не расскажу.
- Я понимаю как работает многопоточность, какие там подводные камни, очень аккуратно подхожу к написанию такого кода,предварительно перечитывая доки.
- Я умею пользоваться виртуалками как оператор; по-наитию понимаю, как это работает.
- Не могу свободно предсказывать алгоритмы работы Go sheduler, не знаю нюансов как то, что горутина при context switch может менять поток. Про context switch стоит получше почитать даже для FreeRTOS.
- Очень мало всякого кода писал с каналами; надо зазубрить теорию, а то каждый раз неловко.
- Мое знание HTTPS заканчивается на том, что это HTTP с шифрованием, и API для поднятия такого сервера просит ключ для шифрования. Также знаю, что HTTPS2 ‒ совсем другой протокол с кучей нюансов. Статью на вики можно в теории зазубрить, но не буду без необходимости, т.к. на практике в приватной сети летает HTTP или gRPC.
- Кажется, что большей части программистов эти знания не нужны, хотя может это мой информационный пузырь. Надо пройти десяток собесов, чтобы понять.
- В следующий раз когда сам буду проводить собеседование, буду просить человека написать вот такой вот фидбек для себя и поделиться им.
- Нужно спрашивать реальные примеры таскок на все заковыристые вопросы, иначе местами непонятно это реальные кейсы или примеры из какой-то статьи.
В описании вакансии сообщают, что в компании не гонятся за новыми фреймворками, главное скилл. На деле дают такое тестовое задание:
- Нарисовать пять звезд и сделать обработчик клика.
- Сделать банальный CRUD на backbone.js (повторить любую hello world статью по теме)
Первую часть выполнил (код просили писать на coffee по возможности). В README.md описаны мои сомнения. От второго задания отказался. Финальный диалог:
— Звёзды сделаны плохо, второе не выполнено, отказ. — Что не так со звездами? — Наложите звёзды друг на друга и посмотрите на результат. — Как мне наложить их друг на друга? Нарисовать одну поверх другой? Клик сработает на первой, но отобразится последняя. Поэтому задание плохо выполнено? — "Проявите находчивость, вы же senior))) P.S. с данным заданием джуны справляются успешно с первого раза."
Очень странная ситуация. Текст задания:
Создать два канваса 600x600 и 600x50, нарисовать в большем пять закрашенных пятиконечных звёзд. Красного, синего, зеленого, желтого, и черного цветов. По клику мышкой на цветной звезде закрашивать маленький канвас соответствующим цветом. При клике на белую (не закрашенную) область большого канваса закрашивать белым маленький канвас.
В процессе я понял, что не готов работать с таким стеком в принципе, поэтому не доделал вторую часть. Но ответ сильно удивил. Я занимался наймом людей, обычно максимально подробно комментировал результаты и оплачивал тестовое задание. У всех свои подходы, никакой критики не будет. Уличной магией с матрицей поворота alarstudios не удивить =)
Получили от меня комканное резюме в виде двух ссылок. По результатам сказали, что я больше фронт, а они ищут бека. Ок, надеюсь, с третьей-шестой попытки написать резюме у меня получится лучше, т.к. текущий вывод вообще не отражает действительности. Плюс в процессе компания уменьшила вилку, и я вылетел из кандидатов (предположение).
После моего отклика на вакансию, HR скинула две простые задачи (после codewars — это семечки). Назначила собес. Ближе к началу собеса сообразил спросить про язык, и это English. Мой уровень — B1-B2, но без разговорной практики. Многих устраивает говорить с ошибками и диким акцентоми, но не меня. Проблема решается, но со временем. Отказался. У них есть классная философия работы, но в процессе собеседования я её не увидел.
Собес с HR ок.
На созвоне с СТО смазанно рассказал про опыт; интервью ограничено по времени. Нужно зарашее спрашивать, может ли оно затянуться. Если нет — выражаться максимально коротко и ёмко. Буду учиться.
По тех.интервью базовые вопросы про Go; достаточно было прочитать Effective Go. Но тоже стоит учиться отвечать короче, если не просят другого.
Фидбека нет. Думаю, был оценен как «ни рыба ни мясо».
Название то ли не запомнил, то ли оно не было озвучено. В тексте вакансии не указано. Собес ровно на полчаса. Вопросы:
- В чём хранить бабки и что делать с деноминацией. Думаю, ответа про decimal в нормальных базах было бы достаточно и не стоит тратить тратить время на рассуждения. Если в базе этого нет, то вопрос — почему, и в крайнем случае смотреть на реализацию в том же PostgreSQL.
- Какие протоколы передачи данных бывают? Плюс HTTP2. Рассказал как попало; лучше перечитать и рассказывать более складно. Шутку про UDP не рассказал.
- В чём разница между merge и rebase? Про золотое правило своими словами рассказал, а особо больше нечего. У git flow не так много разнообразия; лекцию про git не прочитаю и не вижу смысла.
Ответ:
сказал, что для тим лида, к сожалению, по его представлению, немного не хватает тех знаний.
В вакансии было сказано, что работа либом будет когда-то в будущем, и ответ странный. Попросил чуть развернуть. Я понимаю, что я практик без вышки, но если дело в чём-то другом, то интересно узнать в чём.
Выполнил ТЗ (front+back) без back, т.к. банально postgraphile взял бы эту функцию. И предложил посмотреть мой код на Golang более сложного проекта. Вакансия подразумевает гибкость в выборе технологий, так что очень сильно смутило отсутствие гибкости при оценке ТЗ. Отказался от этой вакансии. Код ТЗ доделаю и буду показывать как свои текущие скиллы.
Много мямлил на архитектурных процессах. Нужно глянуть две-три архитектуры и коротко их описывать, чтобы на автомате закрывать банальные вещи. У HR нужно спрашивать, что конкретно ждут от Senior, чтобы правильно раскидывать акценты. Ну и на архитектурные вопросы спрашивать доп.вопросы, чтобы не гадать самостоятельно. Стоит перестать отвечать «а как сделал бы», если бы я точно этого не делал, а шёл смотреть готовое решение.
Вообще, у меня такой алгоритм:
- Выделить самые сложные части проекта, обсудить способы их решения.
- Собрать список используемых технологий в зависимости от бизнеса, команды и т.д.
- Очень быстро собрать и обсудить демку.
- Подвести итоги, запрепить список на бумаге.
- Идти делать или раскидывать задачи.
Такой подход позволяет максимально дёшево и быстро запустить демку. Дальше собрать метрики, получить фидбек и думать, что делать дальше. Стоит задать про это вопрос собеседующему.
Вопрос: как бы ты делал YouTube?
- Нужно сделать минимальную демку или готовый проект?
- Под сколько пользователей?
- Какие скиллы есть у команды?
- На каких мощностях это будет разворачиваться?
TODO: составить список топ вещей, которые делал на протяжении карьеры.