Go-собеседоваться! Чего ожидать от интервью на конференции

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

Мы наивно рассчитывали, что к нам выстроится очередь, но к рекрутерам за весь день подошли всего два Go-шника. Конечно, приятно думать, что доклады были настолько интересными, что никто не хотел их пропускать. Но вообще я задумался: почему так получилось?

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

А в статье расскажу, о чем мы беседуем, какие даем задания и как оцениваем кандидатов — пригодится, если соберетесь к нам на собес. Спойлер: нет, вопросов, кем вы видите себя через пять лет и как отмерить 15 минут с помощью свечки, не спрашиваем.

Вы ищете работу, мы — Go-разработчиков

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

В этот раз на GoCloud Tech мы искали девопсов, дата-сайентистов и бэкендеров. Я собеседовал Go-разработчиков уровня мидл и сеньор, а буквально бок о бок со мной на конфе работали люди, с которыми мы познакомились как раз на таких собеседованиях.

Для вас это возможность быстрее пройти первые этапы отбора. Не нужно отдельно откликаться на вакансию и ждать ответа. Кроме того, нет опасений «а вдруг работодатель узнает, что я обновил резюме и уволит?»: вы на месте сразу общаетесь с рекрутером, рассказываете об опыте и задаете вопросы. Затем там же можно пройти первое техническое интервью безо всяких собеседований в пять этапов, где нужно сначала одолеть ИИ-шку, а потом рассказать HR-у стишок с табуретки и ответить техлиду, почему люки делают круглыми.

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

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

Как проходили интервью

Все начиналось с заявки на сайте конференции: кандидат отправлял резюме прямо там. На этапе записи никого не отсеивали.

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

Сначала — знакомство

Дальше самое интересное — техническое интервью. На техническое собеседование отводили полчаса: десять минут на знакомство и 20 — на задачу и ее обсуждение. Разговор с рекрутером в это время не входил.

Сначала кандидат рассказывал, с какими задачами и технологиями работал. Мы, интервьюеры, тоже делились своим опытом: если находились общие темы, разговор шел легче — это помогало освоиться перед решением задачи и спокойнее объяснять ход мыслей.

Задача на техническом интервью

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

Доводить код до запуска не требовалось: за 20 минут нам было важнее понять ход мыслей кандидата.

Задачу решали на ноутбуке ThinkBook в редакторе Sublime Text.

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

В следующий раз взяли бы удобную внешнюю клавиатуру и мышь. Хочется, чтобы человек мог сосредоточиться на задаче, а не осваивать заодно новое для себя рабочее место.

Всего подготовили 16 задач. Каждому кандидату предлагали одну — с учетом его опыта, уровня и интересов. Основные темы: горутины, каналы, контекст, синхронизация, порядок обработки и завершение работы.

Учитывали и обстановку: к вечеру человек мог устать после целого дня на конференции, поэтому давать самое сложное задание только ради сложности смысла не было.

А что, если человек решит задание за две минуты? На этот случай к каждой задаче подготовили дополнительные вопросы по Go. Они продолжали тему решения: что изменится при отмене контекста, где может зависнуть горутина, кто должен закрывать канал, что произойдет при одновременной записи.

Для кандидата был исходный код с условием. Для интервьюера — решение, вопросы и ответы. Полный набор оставили в репозитории на GitHub.

Как выбирали формат задачи

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

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

Разберем одну из задач

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

Исходный код:

func RunWorkers(ctx context.Context, first, second func(context.Context) error) error {
    var wg sync.WaitGroup
    wg.Add(2)

    go func() {
        defer wg.Done()
        first(ctx)
    }()

    go func() {
        defer wg.Done()
        second(ctx)
    }()

    wg.Wait()
    return nil
}

Решение через канал

Канал с буфером на одну ошибку: первая сохраняется и вызывает отмену, остальные пропускаем.

func RunWorkers(ctx context.Context, first, second func(context.Context) error) error {
    if err := ctx.Err(); err != nil {
        return err
    }

    workCtx, cancel := context.WithCancel(ctx)
    defer cancel()

    firstError := make(chan error, 1)
    var wg sync.WaitGroup
    wg.Add(2)

    for _, run := range []func(context.Context) error{first, second} {
        go func(run func(context.Context) error) {
            defer wg.Done()
            if err := run(workCtx); err != nil {
                select {
                case firstError <- err:
                    cancel()
                default:
                }
            }
        }(run)
    }
    wg.Wait()

    select {
    case err := <-firstError:
        return err
    default:
        return ctx.Err()
    }
}

Можно обойтись и без канала: сохранять ошибку и вызывать отмену через общий для обеих горутин sync.Once:

if err := run(workCtx); err != nil {
    once.Do(func() {
        firstErr = err
        cancel()
    })
}

Тогда сохранится ошибка той горутины, которая первой выполнит Once.Do. Читать firstErr и возвращать результат нужно после wg.Wait().

Как подготовиться к задаче

Многие задачи по Go строятся вокруг одних и тех же паттернов и приемов: пул воркеров, конвейер обработки, объединение результатов нескольких горутин, отмена через контекст, работа с таймерами и тикерами. Базовых приемов не так много — их вполне можно освоить и научиться сочетать друг с другом.

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

Есть простой способ усилить впечатление от вашего решения — рассуждать вслух.

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

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

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

Как прошли собеседования

За день к рекрутерам подошли два Go-разработчика. С обоими мы провели техническое интервью.

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

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

По всем направлениям собрали 41 резюме. После предварительного отбора до технического интервью дошли пять кандидатов, двое из них наши — по Go. Итоги общения с кандидатами — на схеме:

До встречи на конференциях

Если вы видели анонсы наших конференций, и до сих пор не решились их посетить офлайн, обязательно приходите в следующий раз! Так можно не только послушать доклады, но и познакомиться с возможными будущими коллегами — сразу сможете оценить, родственный у нас вайб или нет, а заодно и собеседование пройдете.

Следите за новостями и приходите на наши конференции и стенды не только за информацией про продукты, а еще и за новой работой. Будем рады знакомству.