Чтобы не собесить LLM надо собесить LLM
или что за тг канал без поста про AI
Думаю для всех тех, кто проводит собеседования по hard-скиллам актуален вопрос - что делать со списыванием из LLM любой вариации?
Конечно нельзя сбрасывать со счетов вопрос более верхнеуровневый - а надо ли что-то делать?
На него общепринятого ответа нет, но я вижу риски такого найма - кандидат который не может думать и решать без LLM качественно - будет хуже кандидата который способен это делать. Потому что когда эти два абстрактных кандидата воплотятся на работе и возьмут в руки LLM - мы получим из одного связку "Senior + junior AI" а из другого "Junior + intern AI". Ну либо Senior без AI если наняли луддита)
Так что в своем размышлении над решением этой задачи я принял следующее допущение - мы хотим на техсекциях собесов, особенно на проверке хардов, исключить влияние LLM на оценку кандидата
Вижу тут два основных направления:
1) Сделать так, чтобы LLM нельзя/сложнее было воспользоваться. Так сказать "ЕГЭобразный" подхож- ужесточаем контроль, закрываем кандидата в комнате с белыми стенами, даем ему карандаш и бумажку, запрещаем моргать чтобы не подал сигналы в космос
Понятно что я довел этот пример до абсурда, но сильными ужесточениями мы срежем себе воронку из приличных кандидатов, которые не захотят участвовать в этом перформансе. Ну и кто захочет - тот спишет, проверено в универе еще до всяких чатгптей)
2) Сделать так, чтобы LLM было пользоваться бессмысленно.
Нужен такой подход к собеседованию, когда использование LLM ухудшает результат собеседования.
Например: LLM-устойчивые задачи, специфичный бизнес контекст, хорошо воспринимаемый человеком но плохо распознаваемый и учитываемый моделью.
Таким образом, мы вынесем на первый план оценивания не написание кода, а более высокие уровни решения задач - аналитические выводы по коду, умение применить контекст, оценить сложность задачи, внести правки и корректно собрать требования (и какое совпадение - этого мы и ждем от кандидата, а вовсе не знания синтаксиса)
Остался основной вопрос - а как же построить такое "идеальное" собеседование - чтобы при адекватной трудоемкости проведения техсекций минимизировать ошибку определения подходящего кандидата?
Тут пока готового ответа у меня нет) А по поводу тезиса из заголовка - чтобы отладить такой подход я буквально собеседую ChatGPT на должность BI разработчика - чтобы понять с чем у него есть сложности и как это можно применить)
или что за тг канал без поста про AI
Думаю для всех тех, кто проводит собеседования по hard-скиллам актуален вопрос - что делать со списыванием из LLM любой вариации?
Конечно нельзя сбрасывать со счетов вопрос более верхнеуровневый - а надо ли что-то делать?
На него общепринятого ответа нет, но я вижу риски такого найма - кандидат который не может думать и решать без LLM качественно - будет хуже кандидата который способен это делать. Потому что когда эти два абстрактных кандидата воплотятся на работе и возьмут в руки LLM - мы получим из одного связку "Senior + junior AI" а из другого "Junior + intern AI". Ну либо Senior без AI если наняли луддита)
Так что в своем размышлении над решением этой задачи я принял следующее допущение - мы хотим на техсекциях собесов, особенно на проверке хардов, исключить влияние LLM на оценку кандидата
Вижу тут два основных направления:
1) Сделать так, чтобы LLM нельзя/сложнее было воспользоваться. Так сказать "ЕГЭобразный" подхож- ужесточаем контроль, закрываем кандидата в комнате с белыми стенами, даем ему карандаш и бумажку, запрещаем моргать чтобы не подал сигналы в космос
Понятно что я довел этот пример до абсурда, но сильными ужесточениями мы срежем себе воронку из приличных кандидатов, которые не захотят участвовать в этом перформансе. Ну и кто захочет - тот спишет, проверено в универе еще до всяких чатгптей)
2) Сделать так, чтобы LLM было пользоваться бессмысленно.
Нужен такой подход к собеседованию, когда использование LLM ухудшает результат собеседования.
Например: LLM-устойчивые задачи, специфичный бизнес контекст, хорошо воспринимаемый человеком но плохо распознаваемый и учитываемый моделью.
Таким образом, мы вынесем на первый план оценивания не написание кода, а более высокие уровни решения задач - аналитические выводы по коду, умение применить контекст, оценить сложность задачи, внести правки и корректно собрать требования (и какое совпадение - этого мы и ждем от кандидата, а вовсе не знания синтаксиса)
Остался основной вопрос - а как же построить такое "идеальное" собеседование - чтобы при адекватной трудоемкости проведения техсекций минимизировать ошибку определения подходящего кандидата?
Тут пока готового ответа у меня нет) А по поводу тезиса из заголовка - чтобы отладить такой подход я буквально собеседую ChatGPT на должность BI разработчика - чтобы понять с чем у него есть сложности и как это можно применить)