Процесс найма разработчиков различен и на моём пути я был как на стороне кандидата со своей системой вопросов, получал свою уйму лулзов, так и на стороне интервьюера. Поскольку встреч с кандидатом в больших компаниях несколько, то мне удалось принимать интервью на фазе технической оценки. Постараюсь тут кратко описать итоги.
Цели
Для компании смысл технического интервью - оценка кандидата. В это входит:
1. Оценка горизонтальных архитектурных познаний. Насколько богатый спектр технологий и процессов разработки использовал или хотя-бы знает человек. Как он может связать их между собой. Какие решения для одной и той же проблемы он может предложить.
2. Оценка вертикальных, практических познаний. Насколько глубоко он знает технологии с которыми он работает. Как детально он вникает во все возможные нюансы. Как сильно он может оптимизировать задачу по performance
3. Прочие не технические качества - инициативность, качество, скорость мышления, реакция на критику, любопытство
Объективная оценка
Как это же оценить разработчика на деле и сравнить его с другими разработчиками, если все люди разные? Дабы уменьшить уровень философии и субъективности, я подхожу к оценке очень практично.
Почти все компании высылают кандидатам домашнее задание. Я подхожу к оценке его с холодным расчётом Excel'я и TDD. Так как домашняя работа должна показать знание всего цикла разработки, то я составляю таблицу оценок на каждого кандидата
После php и node начал писать на go, поэтому по-аналогии с unix-шпаргалкой, выпишу для себя основы..
Запуск
go run main.go → компиляция и запуск exe go build main.go → только компиляция и создание exe, без запуска go get -u https://github.com/x/y → импортирование зависимостей
Прошёл двухдневный workshop компании Clarified Security по основам взлома в сети и серверы. Оплатил это Pipedrive, но вы можете заказать себе такую же тренировку. Тренинги построены по шагам с такой оценочной системой, что какое-то время можно самому искать решение, потом тебе объясняют как это сделать в действительности.
Спешу поделиться самым интересным. Вначале было введение в историю, в т.ч. последние уязвимости типа KRACK.
Потом был пример взлома по-старинке - старый апач с уязвимостью на переполнение буфера. Как раньше приходилось искать код на C, компилировать. Как в ходе этого gcc ругался на отсутсвующие хедер-файлы.
Второй день мы провели в Kali Linux за двумя главными программками - Meterpreter и Armitage. Первая это библиотека эксплоитов с их поддержкой в виде сервера, а вторая это UI для управления атакой.
Итог пугающий. Уязвимости в java, flash и прочих неизвестных 0-day штуках позволяет влезть через веб к человеку на комп. Дальше обычно приходится делать повышение привилегий процесса. В винде можно прыгать с процесса на процесс, так что если клиент заразился через открытый word файл, то связь со злоумышленником остаётся переходом под более постоянный процесс, типа explorer. Повышение привилегий даёт в итоге полный контроль над машиной. Дальше можно захватывать компьютеры во внутренней сети, менять настройки файрволла так что-бы ничего не заподозрил владелец. Можно взламывать и линуксовые машины, так же поднимаясь до рута.
Кроме этих двух утилит в Kali предустановлены wordlistы, с которыми можно перебирать пароли к линуксовым shadow-файлам, есть сканеры путей для вебсайта и проч.
В продолжение темы умного дома где мой котёл умел выдавать API для мониторинга температур, захотелось мне вывести эти данные в более приятный вид. Кроме того, хотя сам котёл умеет рисовать графики, он показывал на них только температурную зону одного контура, а мне хотелось видеть два.
Поэтому я решил поизучать бесплатный dashboard и графико-генератор на основе Grafana. Зарегился и упёрся в то что он сам не хранит данные. Он умеет только подключаться к внешним источникам и делать запросы туда.
Новый MySQL мне не хотелось поднимать, а открывать существующий тем более. Cloudwatch от Амазона - видимо полезен для мониторинга сервисов если вы активно пользуетесь этой инфраструктурой. Prometheus я могу и на работе посмотреть. Выбрал InfluxDB - специальную БД для хранения временных событий.
Ставить Influx было достаточно просто. Сложней было связать графану с influx.
Сервис гоняется на 8086 порту и Grafana хочет SSL и CORS. Поэтому пришлось делать proxy на nginx и добавлять header:
Команды программистов из 3-7 человек это идеальная машина по быстрому созданию качественного продукта. Слишком много - и все погрязнут в бесконечных обсуждениях, слишком мало - будет сбиваться ритм и снижаться продуктивность и качество.
Я мало что понимаю в менеджменте, поэтому меня больше интересуют вопросы конфликтов и улучшение инспекции кода для улучшения продукта и сплочения команды.
Code review, pull request review и peer review это практически одно и то же, различие лишь в фокусе внимания - на систематичность просмотра существующего кода, на принятие чужого кода или на массовость читателей. Я буду использовать термин ревью как процесса и инспектора для принимающей стороны.
«А когда ты в последний раз видел своего отца?»
Изображает сына роялиста, опрашиваемого Парламентариями во время английской гражданской войны