Как стать автором
Обновить
15
0.1
Oleg Kandaurov @f0y

Кот-Программист

Фиче флаги это рубильник)

Я полагаю вы за собес в формате "30 минут по душам с руководителем"?

За 8 лет) а какой период был у вас в голове?

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

Чтобы было понятно зачем мы эту компетенцию оцениваем, то можно сравнить сильного кандидата со слабым в части декомпозиции. У слабого гарантировано возникнут проблемы на более объёмной задаче. Сильный же кандидат вполне может справится и со сложной задачей.

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

И снова здравствуйте https://habr.com/ru/companies/ods/articles/772292/

> Сэм Альтман заверил, что OpenAI не тренирует модели на данных пользователей. Это верно по умолчанию для бизнесов и разработчиков, работающих по API, а вот обычным пользователям необходимо убрать специальный флажок в настройках на сайте ChatGPT


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

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

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

P.S. Оскорблять было не обязательно.

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

Лучше не принимать на себя излишние риски без явной на то причины.

Реальное задание не могу показать, но в нём есть класс, парочка методов без реализации и javadoc c описанием что эти методы должны делать.

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

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

Если говорить про внутреннее межсервисное взаимодействие, где мы знаем всех клиентов, то используем https://www.thoughtworks.com/radar/techniques/api-expand-contract

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

Да, планируем выложить генератор, линтеры и сicd обвязку. Хотели сделать к конференции, но успели выложить только bundler https://github.com/yoomoney/openapi-bundler.

Да я просто к тому, что с kafka все гвозди не заколотить, нужен инструмент под задачу.

Спасибо!

> решение от ЯДа когда-то проросло из нашего с Яшей Сироткиным кода или независимо

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

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

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

Расскажите как решить задачу отложенного выполнения задач при помощи kafka? Скажем сделать гарантированный возврат платежа через час.

Если можно кратко - то чем не устраивает? Я не встречал такого фидбека, он был бы полезен для развития.

Информация

В рейтинге
3 243-й
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Работает в
Дата рождения
Зарегистрирован
Активность