А почему крушение поезда? В результате ничего не сломалось, а наоборот. Если б производитель поддержал калибровку, я бы откалибровал через via просто. А поскольку этого нет, пришлось искать другое решение.
С другой стороны, это именно нейросети обучались писать тескты на профессиональных статьях. Если возьмёт мою первую статью на хабре за 2014 год — Помнить всё, — там 44 длинных тире и куча списков.
У нас есть e2e тесты (подробнее писал в статье), проверяли модель на них. Локальная 4b qwen оказалась настолько же хороша, как Gigachat Lite со специально подобранным под нее промптом. Нас пока такой результат устроил, но специально ещё ничего не подгоняли.
заголовок статьи: “скажут больше, чем техническое интервью”; тезис в заголовке тезисом не является?
Тезис “скажут больше, чем технические интервью“ не равно “скажут точно“. Вы подменили понятие на “точно не скажут“ и доказываете, что неверно. А этого никто и не имел в виду изначально. Вопрос о том, скажут ли больше или меньше, остаётся открытым.
по поводу обвинения в догматичности на базе слова “любые”: моё утверждение было выводом из вашего же примера
Это же всего лишь один пример. Мы не можем говорить про “любые“.
ответ инженера, не пишущего unit-тесты: “нет”, и это не проблема коммуникации, это проблема вопроса.
Мне хочется, чтобы разработчик был умнее, чем нейросеть с промптом “отвечай“ односложно. Я сам разработчик до сих пор и часть моей ответственности — разобраться, что от меня хотят. Поэтому и считаю, что вопросы автора имеют право на жизнь.
Я предлагаю закончить дискуссию, пусть каждый возьмёт от статьи, что хочет, или не берёт ничего.
Если ваша цель — опровергнуть тезис: “метод Х позволяет гарантированно определить, подходит кандидат или нет“, то конечно, это легко опровергнуть. Но никто этот тезис не произносил. А вот ваш тезис как раз догматический:
это подтверждает, что любые вопросы на интервью, включая предложенные автором, имеют слабый предсказательный характер качества реальной работы человека
Мы не знаем, любые или не любые. Можно только сказать, что “какие-то вопросы имеют слабый предсказательный характер “. Но вы пишете “любые“, потому что пришли к этому эмпирически — и при этом упрекаете автора в эмпирике. Вот это тоже двойной стандар.
Каждый сам решает, что брать от статьи. Я давно заметил, что отбор по типу FAANG — неэффективный. Вопросы про тесты и ответственность мне нравятся. Даже если кандидата спросят, использует ли он Unit-тесты, а он ответит, что нет, и на этом разговор не продолжится, — это проблема коммуникации с двух сторон. И интервьюер должен спросить: “а как вы гарантируете качество кода“, и кандидату бы хорошо ответить не односложно сразу.
И по поводу статьи: не должен же автор писать тут ветвление всех вариантов диалога с кандидатом. Он показал, как можно начать диалог и на что обратить внимание.
метод, который систематически отсеивает сильнейших
Если бы это было доказано, то вы были бы правы. Но ни вы, ни я не знаем, какая эффективность предсказания у подхода из статьи, а какая у собеседований, как в FAANG.
текст: “корреляция оказалась удивительно высокой”.
Со всем, что вы писали, согласен, но в реальности просто нет времени досконально разбираться с каждым кандидатом. Могу даже поверить, что предложенные автором вопросы дают лучшую предсказательную силу, чем алгоритмические, архитектурные и интервью на знание ЯП.
Последний раз, когда я собеседовал разработчика, он очень плохо отвечал на вопросы — и по ЯП, и по архитектуре. И обратная связь от других интервьюеров была на троечку. Тем не менее, взяли его, потому что все остальные были еще хуже, а еще и ставку у нас могли забрать. В итоге разработчик разобрался в первую неделю с довольно большим проектом, никого не отвлекает лишними вопросами, пишет хороший код.
В идеале бы брать на тестовый период в пару месяцев и смотреть, как кандидат справляется, но мир далёк от идеала. Поэтому то, что предлагает автор статьи, имеет право на жизнь.
У меня в статье просто ирония. Подводные камни в ЯП появляются не специально, а как трейдофф. Пример: выигрываешь в читаемости — проигрываешь в перформансе, и/или бойлерплейте, и/или времени компиляции.
Спасибо. Поправил.
Чем богаты.
А почему крушение поезда? В результате ничего не сломалось, а наоборот. Если б производитель поддержал калибровку, я бы откалибровал через via просто. А поскольку этого нет, пришлось искать другое решение.
А чего так мало?
Если вы имеете в виду, что статью написала LLM, то это точно не так. Слишком много ошибок в пунктуации и текст плотный.
С другой стороны, это именно нейросети обучались писать тескты на профессиональных статьях. Если возьмёт мою первую статью на хабре за 2014 год — Помнить всё, — там 44 длинных тире и куча списков.
Почему вы решили, что статья написана ИИ? Длинное тире, буква ё и списки? Или что-то ещё?
Статья писалась в виме. Демонстрирую запись (y.disk) с undotree плагином, где видно, что изменения вносились точнечно в течение нескольких дней.
Задачи на это есть, будем смотреть и тестировать. Может быть, уже в следующем релизе всё добавим.
У нас есть e2e тесты (подробнее писал в статье), проверяли модель на них. Локальная 4b qwen оказалась настолько же хороша, как Gigachat Lite со специально подобранным под нее промптом. Нас пока такой результат устроил, но специально ещё ничего не подгоняли.
Гемму собираемся поддержать в следующем релизе.
Наши пользователи: мы на нетехнарях фокусируемся
А на чём своего пишете?
На Rust хорошо то, что по-другому написать не получится.
Так можно про любой ЯП написать, про тот же Go. А с C++ не просто так же мемы появляются:
как выуычить C++ за 21 день
Тезис “скажут больше, чем технические интервью“ не равно “скажут точно“. Вы подменили понятие на “точно не скажут“ и доказываете, что неверно. А этого никто и не имел в виду изначально. Вопрос о том, скажут ли больше или меньше, остаётся открытым.
Это же всего лишь один пример. Мы не можем говорить про “любые“.
Мне хочется, чтобы разработчик был умнее, чем нейросеть с промптом “отвечай“ односложно. Я сам разработчик до сих пор и часть моей ответственности — разобраться, что от меня хотят. Поэтому и считаю, что вопросы автора имеют право на жизнь.
Я предлагаю закончить дискуссию, пусть каждый возьмёт от статьи, что хочет, или не берёт ничего.
Если ваша цель — опровергнуть тезис: “метод Х позволяет гарантированно определить, подходит кандидат или нет“, то конечно, это легко опровергнуть. Но никто этот тезис не произносил. А вот ваш тезис как раз догматический:
Мы не знаем, любые или не любые. Можно только сказать, что “какие-то вопросы имеют слабый предсказательный характер “. Но вы пишете “любые“, потому что пришли к этому эмпирически — и при этом упрекаете автора в эмпирике. Вот это тоже двойной стандар.
Каждый сам решает, что брать от статьи. Я давно заметил, что отбор по типу FAANG — неэффективный. Вопросы про тесты и ответственность мне нравятся. Даже если кандидата спросят, использует ли он Unit-тесты, а он ответит, что нет, и на этом разговор не продолжится, — это проблема коммуникации с двух сторон. И интервьюер должен спросить: “а как вы гарантируете качество кода“, и кандидату бы хорошо ответить не односложно сразу.
И по поводу статьи: не должен же автор писать тут ветвление всех вариантов диалога с кандидатом. Он показал, как можно начать диалог и на что обратить внимание.
Если бы это было доказано, то вы были бы правы. Но ни вы, ни я не знаем, какая эффективность предсказания у подхода из статьи, а какая у собеседований, как в FAANG.
Видимо, это эмпирический вывод автора.
Вопрос же не в том, как найти способ исключить false positive и false negative, а как эффективнее получить предсказание, затратив меньше времени.
А разве кто-то утверждал, что какой-то метод отбора не имеет ограничений?
Со всем, что вы писали, согласен, но в реальности просто нет времени досконально разбираться с каждым кандидатом. Могу даже поверить, что предложенные автором вопросы дают лучшую предсказательную силу, чем алгоритмические, архитектурные и интервью на знание ЯП.
Последний раз, когда я собеседовал разработчика, он очень плохо отвечал на вопросы — и по ЯП, и по архитектуре. И обратная связь от других интервьюеров была на троечку. Тем не менее, взяли его, потому что все остальные были еще хуже, а еще и ставку у нас могли забрать. В итоге разработчик разобрался в первую неделю с довольно большим проектом, никого не отвлекает лишними вопросами, пишет хороший код.
В идеале бы брать на тестовый период в пару месяцев и смотреть, как кандидат справляется, но мир далёк от идеала. Поэтому то, что предлагает автор статьи, имеет право на жизнь.
Теперь я не понял ваше сообщение.
У меня в статье просто ирония. Подводные камни в ЯП появляются не специально, а как трейдофф. Пример: выигрываешь в читаемости — проигрываешь в перформансе, и/или бойлерплейте, и/или времени компиляции.
Сертификация вайбкодеров — это сильно.
Только что запустил на Go 1.25.5, вывелось `[4 1 2 3 4]`