Comments 195
если программист с ChatGPT не отличим от программиста без ChatGPT то тогда какая разница?
Это полностью справедливо, если бы речь шла о ежедневной настоящей работе. Но не в случае небольших тестовых заданий, для решения которых при помощи gpt почти ничего не требуется знать и уметь самому кандидату.
Внимание вопрос, как вы тогда верите что кандидат хороший потому что он хорошо решает тестовые задания, но не верите нейросетке хотя она делает тоже самое?
Кандидат точно также может бред программить в реальных условиях..и фактически аналогичен ИИ в данном вопросе... Разница только в том что вы априори знаете что сеть плохая
Но какой смысл в задачах то если они фильтруют ...кого?
На мой взгляд ответ очевиден. Тестовое задание это отборочный этап, самый базовый фильтр, после выполнения которого обычно зовут на собеседование, где начинается хоть сколько-нибудь реальный отсев. И этот первичный фильтр в современных условиях лишился своего смысла, речь только об этом.
Выйдет GPT-5 и вопрос будет уже не про тестовое.
Так это фиговый фильтр. Понятно, что вам нужен хоть какой-то.
Не очень понимаю, почему вас именно ИИ беспокоит. Судя по всему уже несколько лет назад было немало вариантов, когда задачи за соискателей решали другие люди, а потом те делились частью зарплаты. Помнится была история, как за кого-то жена все решала :).
Более того, есть серьезные опасения, что решения можно нагуглить. Ну или что-то очень похожее на решение. Неужели кандидаты такие тугие пошли, что нагуглить не могут ?
Что и зачем проверяют эти задания ?
Он лишился своего смысла задолго до бума нейросетей.
Об этом даже на хабре уже десяток статей был.
Внимание вопрос, как вы тогда верите что кандидат хороший потому что он хорошо решает тестовые задания, но не верите нейросетке хотя она делает тоже самое?
На самом деле здесь действительно срабатывает разница между человеческим мозгом и языковой моделью. Если мозг умеет программировать простое, он в общем случае сможет и программировать сложное. А языковая модель, она ведь не умеет программировать, она просто компонует куски из датасета, на котором обучалась. Которые худо-бедно складываются в простые решения (такие, которые можно полностью уложить в запрос к модели, добавив к решению только общеизвестные гайдлайны разработки), но нифига не складываются в сложные, где надо знать обширный контекст проекта и/или анализировать существующий код.
как вы тогда верите что кандидат хороший потому что он хорошо решает тестовые задания, но не верите нейросетке хотя она делает тоже самое?
Человека можно потом, ежели чо, премии лишить, ну или в крайнем случае волшебных пенделей выписать. С нейросетью такое не проканает.
На самом деле домашнее тестовое задание вполне может использоваться как адекватный критерий оценки кандидата. Ведь при приемке результата этого самого задания вполне можно кандидата допросить на предмет понимания представленного кода.
Другой вопрос, стоят ли вообще затраты на такой допрос полученного результата?
Но какой смысл в задачах то если они фильтруют ...кого?
Если не проводить дополнительную проверку на понимание представленного кода, то тех, кто не смог ни сам, ни при помощи друга, ни при помощи gpt.
Интересно только, какова доля таких индивидов?
И есть еще ряд моментов. Например, кандидат, который честно не решил, но и не стал читерить, как по мне, всяко лучше того, кто выдает чужой результат за свой. С другой стороны, он так же не подходит, как и читеры, ибо не смог, просто читеров все равно придется позже отсеять другими методами.
Неотличим на тестовом. Однако на реальных задачах разница может быть огромной, в этом и минус. Тестирование - это попытка оценить качество будущей работы, а не качество ChatGPT (я уже и так знаю, что он пока не тянет, поэтому мы всё ещё нанимаем программистов)
ChatGPT в коде регулярки использует, ну нафиг (шутка).
Программист без ChatGPT подобен программисту с ChatGPT, только без ChatGPT.
Мне кажется, что автор преувеличивает проблему нейросетей, так как в статье разобраны примеры не самых объемных и сложных задач, которые целесообразно скорее при устном собеседовании спрашивать.
Например, команда VK Видео в этом году отбирала весной людей на летнюю стажировку, соответственно, чтобы ускорить процесс людям выдали всем одно и то же задание на реализацию какого-то сервиса.
Задача была достаточно объемной и комплексной, что для неё нужны были изначально знания даже чтобы понять что именно искать надо. Объективно ChatGPT не поможет сделать правильные запросы к самому себе (а если и выдаст, то не факт что верно), потому я более чем уверен, что с отбором они отлично справились.
Да и если программист пишет верный код, то какая разница с помощью чего он это делает?
Ну, в итогах я как раз буквально и пишу, что один из вариантов это давать по настоящему большое и комплексное тестовое задание. Так что не вижу никаких противоречий :) Просто так почти никто не делает, и дают что-то вроде заданий из статьи.
Если все сделают как VK Видео и начнут давать такие задания - отлично, это тоже нормальное решение. Самого задания, о котором вы говорите, я впрочем не видел, не помешает сначала проверить и его.
Удачи вам найти желающих такое задание сделать.
Моё личное мнение, что вообще от любых заданий нужно отказаться (название статьи как бы намекает). Но вариант с большими комплексными заданиями всё равно имеет место быть, если какая-то компания может себе позволить выставлять такие требования, их право. Никто же никого не заставляет, не хочет кандидат - пусть не делает.
За деньги - почему бы и нет.
Я конечно понимаю, сложные программерские вещи, все дела... А вам не приходила в голову очевидная идея после получения задания спросить по листингу "а зачем здесь используется эта функция?"
Ну наконец-то, верная мысль.
Причем программисту, использовавшему ChatGPT при прохождении тестового задания нужно вообще то доплачивать в 10кратном размере за скилы промт инженера. Так как он на реальных задачах сможет работать в 10 раз быстрее.
Причем программисту, использовавшему ChatGPT при прохождении тестового задания нужно вообще то доплачивать в 10кратном размере за скилы промт инженера
Скиллами промт инженера писателя обладает любой копирайтер. Они и стоят не больше, чем работа копирайтера. Настоящая ценность скиллов промтописания состоит только лишь в синергии с профессиональными скиллами. И если реальных профессиональных скиллов нет, она будет весьма невысокой.
Так как он на реальных задачах сможет работать в 10 раз быстрее.
На некоторых реальных задачах, которые более-менее оторваны от общего контекста. Например "сделай форму логина на фреймворке таком-то" более-менее сделает. А даже "сделай форму регистрации" нейронка уже сделает с трудом. Потому что для формы регистрации ей надо знать структуру некоторых внутренних объектов приложения, которые она, конечно же, не знает. Плюс, все равно надо будет вручную перелопачивать вывод, подгоняя его под UI-гайдлайны проекта и т.д.
он на реальных задачах сможет работать в 10 раз быстрее.
Хакеры тоже должны ему в 10 раз больше отстёгивать — он для них оставит в 10 раз больше дырок!
Эти задания точно домой даются? Думал такое и на листочке написать можно. В любом случае, если есть хоть малейшее понимание алгоритмов погуглить решения можно за 5 минут(не все даже, кусками что-то с чем-то склеить). Тогда проще на собесе блок-схему спрашивать, если может - то нагуглит и соберёт и так.
Мне кажется, или для первой питоновской задачи сразу все неправильно. В условии массивы чисел, разделенных пробелом, т.е. как я понимаю строки, а в коде, просто массивы питона.
Подобные задания и раньше были некомильфо. Их вариации так или иначе лежат на литкодах и хакерранках.
Всегда считал, что тестовое задание стоит давать если есть какие-то сомнения в кандидате, уже ПОСЛЕ интервью. И тестовое обязательно должно разбираться совместно после выполнения. По комментариям кандидата сразу будет понятно, где он сам думал, а где - "списал". И "изюминка" в задании тоже должна быть обязательно, иначе это просто тупая трата времени. Так что ничего ИИ-помощники особо не меняют. Во всяком случае, кейс с ИИ ничем не отличается от "помощи друга". А вот идея решить проблему за счет повышения общей сложности и объема задания - очень и очень плохая.
А чем отличается "Скопировал со Stack Overflow" от "Написал ChatGPT"?
Наше тестовое задание ChatGPT 4 не делает =)
Можете скинуть? Интересно попробовать подобрать промт, любыми результатами поделюсь
Реализовать IDictionary<,> таким образом, чтобы перечисление его элементов сохраняло порядок, соответствующий порядку вставки, при этом не изменяя алгоритмическую сложность операций относительно обычного Dictionary<,>.
Только не надо копипастить сюда ответ и просить меня провести ревью. С этой задачей нормально не справляется больше 90% кандидатов, не говоря уже про ChatGPT. Потому что нефункциональные требования ещё есть.
То, что 90% кандидатов не справляются, неудивительно: для этого в голове соискателя нужен отдельный интерфейс к знаниям о разных структурах данных, реализуемых ими операциях и сложности этих операций.
Если такой интерфейс голова реализует, то все достаточно просто:
… благо такой интерфейс я когда-то зачем-то в своей голове реализовал.
Находим через этот интерфейс в списке струтур данных структуру, которая:
- поддерживает перечисление (пар ключ-значение) в порядке вставки;
- не требует соохранять пары "ключ-значение" в каком-то особом месте, чтобы можно было использовать хэш-таблицу типа Dictionary для их хранения, обеспечивая сложность O(1) поиска значения по ключу, соответствующую хэш-таблице (занудства ради: далее и везде — не сильно заполненной, чтобы коллизиями пренебречь);
- имеет сложность O(1) вставки в конец, что соответствует сложности вставки в хэш-таблицу;
- имеет сложность O(1) удаления любого элемента, что соответствует сложности удаленияв хэш-таблицу;
- вроде всё.
Простейшая такая структура AFAIK — двусвязный список+ ссылки на его первый и последний элемент. Посему сохраняем во внутреннем Dictionary пары "ключ — значение+ссылка на предыдущую пару+ссылка на следущую пару" и сохраняем значение ссылки на последнюю вставленную пару. В качестве ссылки я бы предложил просто ключ: сложность поиска по нему, O(1), не мешает удовлетворить условиям задачи. И, наконец, реализуем все методы IDictionary чисто для пары типов "ключ-значение".
Есть ещё нюансы, как реализовать ссылки на отсутствующи элементы: предыдущий элемент в первом или следующий в последнем, но это уже рассматривать лень.
И при наличии в голове нужного интерфейса такая задача вполне решается даже при кодировании "на живую" (AKA livecoding). Так что выбор ее для собеседования одобряю. При условии, что действительно нужен такой человек (см.ниже).
Другое дело, что эта задача вряд ли сколь-нибудь часто встречается на практике: сужу потому, что иначе бы кто-нибудь реализовал для ее решения опенсорсную библиотеку(и не одну), и текст решения попал бы в поле зрения ChatGPT.
И вообще, действительно ли с точки зрения интересов работы обосновано требовать от соискателя наличия упомянутого интерфейса в голове, при том, что основной частью его будущей работы почти наверняка будет перекладывание JSON в DTO и обратно с некоторой несложной промежуточной обработкой: судя по тому, что IDictionary в JS нет (AFAIK), ищется "задовик", он же — бэкендер (я угадал?)? Особенно — учитывая, что все сколь-нибудь часто встречающиеся более сложные задачи, скорее всего, уже кем-нибудь когда-нибудь были решены, и соискатель сможет это решение просто найти и переиспользовать?
А поскольку у меня нет конкретики по вашей позиции, вынужден оставить эти вопросы без ответа.
Другое дело, что эта задача вряд ли сколь-нибудь часто встречается на практике
Дык, для тестовых заданий для программистов и не надо, чтобы они часто встречались на практике, наоборот, чем реже встречается, тем лучше. Тестовое задание должно показывать, как человек умеет программировать, а не как он умеет зубрить наизусть типовые решения.
Тестовое задание должно показывать, как человек умеет программировать,
Всегда хотел понять, что именно стоит за словами "умеет программировать", как-то формализовать это понятие. Не поможете? А то как-то непонятно, что мы тут обсуждаем — одно и тоже или каждый свое.
Предложенный выше тест проверяет умение пользоваться знаниями о структурах данных и алгоритмической сложности операций над ними. По-моему, понятие "уметь программировать" этим явно не исчерпываются: вспоминаю название известной древней книги "Алгоритмы + структуры данных = программы" и наблюдаю, что знание структур данных не равносильно умению программировать, по крайней мере — согласно Вирту (автор книги, довольно известный в прошлом теоретик от программирования).
Да я как бы ничего и не писал, что реализация IDictionary<> не подходит, вполне себе годный пример для задания.
Не вопрос.
Но меня больше интересует само это понятие "умеет программировать": как его выразить? Я, вот, сам выразить затрудняюсь, потому и интересуюсь.
"...все сколь-нибудь часто встречающиеся более сложные задачи, скорее всего, уже кем-нибудь когда-нибудь были решены..."
"Все" в данном случае это популярное обобщение-заблуждение. Задачи часто бывают решены не на том языке программирования, не тем способом, с критическими ошибками или с чудовищной неэффективностью.
Кроме того, неряшливое и неумелое отношение к организации структур данных даже при "перекладывании JSON в DTO" вредит как производительности, так и понятности кода для самого разработчика и его коллег.
Задачи часто бывают решены не на том языке программирования, не тем
способом, с критическими ошибками или с чудовищной неэффективностью.
Это очень хорошо видно на Leetcode в секции решений.
Кроме того, неряшливое и неумелое отношение к организации структур
данных даже при "перекладывании JSON в DTO" вредит как
производительности, так и понятности кода для самого разработчика и его
коллег.
Это сплошь и рядом случается. Я бы винил тут не знание, а подход "и так сойдёт".
«Все» в данном случае это популярное обобщение-заблуждение.
Я написал другие слова: "все сколь-нибудь часто встречающиеся". И да, "решены… с критическими ошибками или с чудовищной неэффективностью" — это "не решены". Да и эффективность — это понятие относительное: например, если известно, что в некоем списке всегда будет, максимум, пяток элементов, и отсортировать его надо считанные разы в час, то сортировать его можно как угодно (да хоть перебором всех возможных перестановок, с O(n!)) — на эффективность всей программы это не повлияет.
Кроме того, неряшливое и неумелое отношение к организации структур данных даже при «перекладывании JSON в DTO» вредит как производительности, так и понятности кода для самого разработчика и его коллег.
Именно при "перекладывании JSON в DTO" и прочей не сильно заумной обрабоке накосячить таки трудно, потому что негде (не, есть умельцы, кончено, но их число сильно меньше числа не умеющих в структуры данных). Проблемы обычно возникают при чем-то заумном. Но тут, таки да, несовершенство нынешней методологии разработки сказывается: лид, вместо того, чтобы отнять такой кусок у джуна и отдать сеньору или сделать самому (а лучше — вообще сразу джуну не давать), пытается добиться результата от несчастного джуна (не, конечно, так рождаются сеньоры (иногда), но вот эффективность процесса...).
Лично вам, повторяю, советовать не рискну — смотрите на свою предметную область и на свой уровень организации процессов — но столбовая дорога развития индустрии разработки ПО должна явно проходить не здесь: так трудоемкость и цену разработки не снизить.
А понятность кода вполне обеспечивается другими средствами: руководством по стилю (AKA style guide), програмой автоматической проверки стиля кода (AKA linter) и процессом ревью ( с занесением, если необходимо, его результатов в KPI).
Ну это не такая простая задача. Там достаточно много заморочек, даже если ты знаешь алгоритм.
Вот например реализация в стандартной библиотеке Питона.
https://github.com/python/cpython/blob/24fb627ea7a4d57cf479b7516bafdb6c253a1645/Lib/collections/init.py#L83
Я всё-таки программиста искал, а не "котика-бояку в добрые руки". Слишком сложная задача для кандидата? Значит он нам не подходит.
Она не сколько тяжёлая, сколько требует внимания к деталям. Жонглирования нодами в связанном списке, мне например, не очень хорошо даётся в состоянии собеса.
А на дом, то в через тесты решается достаточно просто.
Кстати, тут есть интересный уточнющий вопрос — не к вам а к onyxmaster, скорее: а как собеседующий отнесется к тому, что соискатель предложил разумный вариант решения, но накосячил в деталях реализации?
Зависит от того в чём ошибка.
В данном случае ошибка — та, о которой писал Andrey_Solomatin: соискатель неправильно обновил указатели двухсвязного списка, например — при удалении узла забыл что-то поправить или затер раньше времени значение, которое надо было скопировать в другое место. Без привычки к двусвязным спискам да на нервах при кодировании наживую такое запросто получиться может IMHO.
— Вы что это? И конфеты за меня есть будете?
— Ага!
Мы даем тестовые задания (и не только разработчикам), что б было о чем "зацепиться" и подискутировать на созвоне-собесе. "Оператор ChatGPT" на собесе не сможет порассуждать почему он применил этот метод а не тот, и ваще а какой тут патерн? А почему такой?
Короче, даже если код чужой, его с "автором" все равно обсуждать проще, чем сферического коня.
Вы можете принести свой код и спокойно пообсуждать его. Какая разница за что "цепляться". По своему опыту такие собеседования очень комфортные как для соискателя так и для собеседующего и дают не меньше информации. Традиционно это выглядит так: "наш джун написал вот такой код, что вы думаете на этот счет".
почему вы так решили?
Уже давно говорят, что такие простые алгоритмические задачи ничего не показывают. Так что не удивительно, что теперь оказалось, что ChatGPT убило их окончательно.
Вместо того, собрав пытаться тащить эти задачи дальше, просто смените подход к тестовым.
Проверяйте задачи, которые гораздо ближе к реальным рабочим задачам. Они ь тестировать людей будет лучше и ChatGPT их не пойдёт.
Я программирую уже лет 15, примерно с марта оплатил подписку на ChatGPT 4.0. Это просто охрененный инструмент который до сих пор многие недооценивают. Я использую его каждый день на работе и до сих пор нахожу ему все новые и новые применения. Вот лишь небольшой список того, что он умеет делать на уровне "production ready"
генерация тестов
генерация кода согласно вводных
анализ и пояснение написанного кода
анализ фрагментов архитектуры
обсуждение вариантов реализации с аргументацией за и против
составление UML диаграмм
Единственный момент который нужно держать в голове, что он не сделает за вас всю работу. Он в душе не знает про ваши критерии качества. Но если вы можете пояснить почему сгенерированный код вас не устраивает и как вы хотите - он перепишет за считанные секунды. Если вы научитесь использовать этот инструмент, чат подымает вас на следующую ступеньку. По качеству взаимодействия ChatGPT уже превосходит среднестатического мидла.
ВАЖНО! Чат 3.5 это полнейший шлак, с ним невозможно работать.
Пример
Запрос
можешь пояснить что делает функция
export function enrichObject(object: any, propertyName: string, formula: string, defaultValue?: string) {
if (formula.trim() === "")
return
let evaluation = formula
let match = evaluation.match("([a-zA-Z][\\w]*)");
while (match) {
const value = object[match[1]]
if (value == null) {
object[propertyName] = undefined
return
}
evaluation = evaluation.replace(new RegExp("([a-zA-Z]\\w*)"), value)
console.debug(`${value} - ${evaluation}`)
match = evaluation.match("([a-zA-Z][\\w]*)");
}
try {
// eslint-disable-next-line no-new-func
const result: number = Function("\"use strict\";return (" + evaluation + ")")();
object[propertyName] = Number.isFinite(result) ? result : Number(defaultValue);
} catch (e) {
console.warn(`Формула для свойства ${propertyName} задана неверно. Пожалуйста проверьте выражение: ${formula}`)
}
}Ответ
Эта функция, `enrichObject`, принимает на вход четыре параметра:
1. `object`: объект для обогащения,
2. `propertyName`: свойство объекта, которое будет обновлено,
3. `formula`: строка, которую мы хотим вычислить и установить в качестве значения свойства объекта,
4. `defaultValue`: необязательное значение по умолчанию, которое будет использоваться, если формула выдаст бесконечное значение.
Функция работает следующим образом:
- Она проверяет, если `formula` является пустой строкой, и если это так, то функция ничего не делает и просто возвращает управление.
- Затем она начинает процесс подстановки значений переменных, найденных в `formula`, используя значения этих переменных из `object`.
- В процессе подстановки, если функция обнаруживает, что какое-то значение равно `null`, то она устанавливает свойство объекта, определенное `propertyName`, в `undefined` и возвращает управление.
- После того как все подстановки выполнены, функция пытается вычислить получившееся выражение. Если вычисление происходит успешно, она устанавливает свойство объекта `propertyName` в вычисленное значение. Если результат вычисления является бесконечностью, то она устанавливает `propertyName` в `defaultValue`. Если при вычислении происходит ошибка, она выводит предупреждение в консоль.
Таким образом, эта функция используется для динамического вычисления выражения, указанного в `formula`, и обновления свойства `propertyName` объекта на основе этого вычисления. Все переменные в `formula` должны существовать в `object`.
Запрос
я хочу изменить эту функцию таким образом, чтобы источник свойств и объект для обогащения были двумя разными параметрами
Ответ
Для изменения функции enrichObject таким образом, чтобы источник свойств и объект для обогащения были двумя разными параметрами, вы можете просто добавить еще один параметр функции. Давайте назовем его sourceObject.
Функция тогда будет выглядеть так:
export function enrichObject(object: any, sourceObject: any, propertyName: string, formula: string, defaultValue?: string) {
if (formula.trim() === "")
return
let evaluation = formula
let match = evaluation.match("([a-zA-Z][\\w]*)");
while (match) {
const value = sourceObject[match[1]]
if (value == null) {
object[propertyName] = undefined
return
}
evaluation = evaluation.replace(new RegExp("([a-zA-Z]\\w*)"), value)
console.debug(`${value} - ${evaluation}`)
match = evaluation.match("([a-zA-Z][\\w]*)");
}
try {
// eslint-disable-next-line no-new-func
const result: number = Function("\"use strict\";return (" + evaluation + ")")();
object[propertyName] = Number.isFinite(result) ? result : Number(defaultValue);
} catch (e) {
console.warn(`Формула для свойства ${propertyName} задана неверно. Пожалуйста проверьте выражение: ${formula}`)
}
}
Теперь функция enrichObject принимает два разных объекта: object (объект для обогащения) и sourceObject (источник свойств). Значения переменных для подстановки берутся из sourceObject, а обновленное свойство записывается в object.
И в чём польза этого текстового описания для кода? Его всё равно надо осмыслить и загрузить себе в мозг, чтобы потом произвести нужное изменение. Так может проще прочитать код?
Когда создавался COBOL, было принято решение делать код максимально приближенным к обычному английскому, чтобы каждый бухгалтер мог собственноручно немного починить баг. Получилось примерно вот так:
PROCEDURE DIVISION.
COMPUTE NUMC = (NUM1 * NUM2).
DIVIDE NUMA BY NUMB GIVING RES-DIV.
MULTIPLY NUMA BY NUMB GIVING RES-MULT.
SUBTRACT NUMA FROM NUMB GIVING RES-SUB.
ADD NUMA TO NUMB GIVING RES-ADD.
MOVE NUMA TO RES-MOV.
...
STOP RUN.Потом на эти грабли наступили создатели SQL. Затем — 1с.
Теперь вот предлагают читать эссе по мотивам процедурной интерпретации кода (с кучей перекрестных ссылок на имена переменных) — вместо самого кода.
Ничему людей жизнь не учит.
ну когда я первый раз открыл код на Perl..... я сразу закрыл его. А SQL ничего... выучил с удовольствием, имхо из-за понятных слов
Вы путаете высоту порога входа и удобство повседневного использования. Так-то я свой первый коммит на коболе — через час после того, как впервые увидел синтаксис — отправил (м-м-м-м, коммит в SourceSafe).
Если бы SQL был хорошим продуманным решением, в каждом первом фреймворке не городили бы OOM.
Но все равно, бухгалтеры ни на коболе, ни на сиквеле, ни на одинэсе, — магическим образом программировать не начали. Кривая обучения более пологая (особенно в сравнении с перлом, да), но это не плато.
если бы SQL не был хорошо продуманным он бы вообще не дожил до сегодняшнего дня.
Это шутка, да? Я (хвала абстракциям) с ним дела не имею, но иногда имею дело с библиотеками общего назначения (их созданием). И они иногда должны работать с сиквелом. И вот в последний раз мне пришлось одним запросом агрегировать значение по простейшему полю: джейсон валюта и сумма. Если это называется «хорошо продуманный», то я — император Китая:
CASE COUNT(DISTINCT(?->>'currency'))
WHEN 0 THEN JSON_BUILD_OBJECT('currency', NULL, 'amount', 0)
WHEN 1 THEN JSON_BUILD_OBJECT('currency', MAX(?->>'currency'), 'amount', SUM((?->>'amount')::int))
ELSE NULL
ENDИ это еще постгрес! У MySQL все в сто раз печальней:
IF(COUNT(DISTINCT(JSON_EXTRACT(?, "$.currency"))) < 2,
JSON_OBJECT(
"currency", JSON_EXTRACT(JSON_ARRAYAGG(JSON_EXTRACT(?, "$.currency")), "$[0]"),
"amount", SUM(CAST(JSON_EXTRACT(?, "$.amount") AS UNSIGNED))
),
NULL
)Простите, конечно, но любой шаг за пределы селекта — демонстрирует абсолютную несостоятельность сиквела как внятного языка. Даже перл проще читать.
А дожил он до наших дней по чисто историческим причинам, звать которые искусственная монополия, созданная Лоуренсом Эллисоном.
Строго говоря, json - не сфера компетенции языка SQL. Это уже надстройки, которые наворотили для поддержки популярного формата представления данных. И вот эти надстройки, таки да, весьма костыльные, мягко так говоря.
А сам SQL предельно прост и понятен. И ничего лучшего для чисто реляционных баз данных я пока не видел. Единственное, что несколько печалит, это излишнее разнообразие диалектов, отличающихся вроде как в мелочах, но все же достаточно различных, чтобы неприятно путаться при переходе.
С этим тезисом я как раз абсолютно согласен, просто задача о чисто реляционных базах — она немного устарела. И задачу о чисто реляционных базах (сиквел-круд, если хотите, SIUD + GO :) — довольно просто решить на любом языке.
И наличие такого количества диалектов — тоже как бы намекает. Хотя, у лиспа их тоже — вагон, но к лиспу [у меня] претензий нет.
задача о чисто реляционных базах — она немного устарела
Не так уж и устарела, учитывая, что до сих пор в основном используют именно реляционные БД.
Проблемы начинаются от желания хранить в этих БД JSON и взаимодействовать с хранимыми в этих JSON данными.
Как по мне - желание странное. Логичнее разнести эти данные по таблицам и делать запросы к ним без извращений, формируя или разбирая JSON по необходимости на входе-выходе. А если уж приспичило хранить и использовать в запросах именно JSON, то и БД следует использовать соответствующую. Там и язык должен быть не SQL, а что-то уже JSON ориентированное.
И задачу о чисто реляционных базах (сиквел-круд, если хотите, SIUD + GO :) — довольно просто решить на любом языке.
Фокус как раз в том, что SQL - это по большей части не решение какой-то задачи. Это стандартная формализованная постановка задачи для СУБД, чтобы та уже решила задачу своими методами. А решать задачу хранения, поиска и обновления данных в большом хранилище - это отдельная большая задача. И удобно, когда язык постановки этой задачи хоть немного стандартизован и однообразен для любого клиента, пусть то командная строка, формочка для формирования запроса или кнопка "сделать хорошо".
Можно, конечно, попробовать написать (и даже попытаться внедрить в массы) какую-нибудь альтернативу языку SQL, но то, что такой альтернативы до сих пор почему-то не видно даже в нишевых продуктах, говорит о том, что большинство текущее решение (SQL) вполне устраивает.
И наличие такого количества диалектов — тоже как бы намекает.
Ну диалекты у нас размножаются везде, где существует более одного центра разработки продукта. Как говорится, стандарт выполняем (впрочем, не всегда полностью), но есть его разнообразные расширения и дополнения.
о чисто реляционных базах (сиквел-круд, если хотите, SIUD + GO :) — довольно просто решить на любом языке.
Нет. Говорю так потому что я на практиве решал подобные задачи на Clipper/Paradox/Codebase(это — древняя библиотека на C для работы с dbf) — в общем это называлось навигационным доступом к БД — в первой половине 90-х, когда SQL на PC ещё не завезли. И это было куда сложнее, чем писать запросы на SQL, что я делал несколько поздее. Так что для меня SQL тогда стал поистине глотком свежего воздуха.
А точно это вопрос к SQL, а не к тому, что вы решаете задачу не тем инструментом? SQL - язык структурированных запросов к СУБД, JSON - формат сериализации объектов, созданный изначально для JavaScript, но оказавшийся популярным универсальным форматом, ибо он простой, компактный и читабельный в отличии от ранее использовавшегося XML. Который к SQL отношения вообще не имел, но т.к. популярен, разработчики многих СУБД кое-как налепили несовместимых между собой, нестандартных расширений для парсинга JSON прямо в запросах.
Но работать с документами в формате JSON средствами реляционной СУБД, хоть и можно, но совсем не нужно. Это не более чем костыли, если уж совсем никак иначе, и надо прикрутить к существующему решению хоть как-то. В реальности, если у вас данные такие, то ваш пациент - NoSQL.
Какие «такие» данные?
У меня обычная реляционная база, но в одной из табличек мне надо хранить деньги. Бывает. Раскидать их по двум полям — очень плохое решение, тут поля слишком узки́, чтобы подробно объяснять, почему именно. Хорошо, в постгресе есть composite field, и для продвинутых пользователей я рекомендую его. Но есть те, кто по своим причинам хочет джейсон (и бедолаги, которые вообще на MySQL).
Но это все лирика. Физика в том, что я могу добиться необходимого (там остряк рядом что-то про азбуку Морзе говорил, но эта «шутка» не в кассу: мне разрешено решить свою задачу средствами сиквела). Но результат получается таким, что вытекают глаза. Если это не свидетельство беспомощности языка — я не знаю, что тогда.
Это как если бы на джаве для решения нетривиальной, но выполнимой, задачи — пришлось бы писать 10 строк используя синтаксис перла.
У вас архитектурная ошибка - использование инструмента в условиях, для которых он не предназначен. Чисто технически на синтаксисе SQL можно и драйвер уровня ядра написать. Но это будет или неправильное решение от человека принимающего решения или вынужденная необходимость, которую не обойти никак - тогда какие претензии к инструменту?
Какие «такие» данные?
Конкретно тот самый json.
Но результат получается таким, что вытекают глаза. Если это не свидетельство беспомощности языка — я не знаю, что тогда.
Вот смотрите. Я беру скажем пдфку, конвертирую её в байт-строку и пихаю в json. А потом хочу по этому самому json'у делать поиск текста из содержания той самой пдфки. В принципе это можно сделать, но результат получается таким, что вытекают глаза.
Но разве это является "свидетельством беспомощности" json?
И точно так же и у вас. По хорошему если вы хотите работать именно с информацией, которая хранится в вашем json'e, то грубо говоря json надо парсить, а информацию писать в таблицы в "сыром" виде.
, но в одной из табличек мне надо хранить деньги. Бывает. Раскидать их по двум полям — очень плохое решение
Я не представляю причину, которая может заставить хранить деньги в формате JSON, а не в виде decimal-поля, плюс опционально поля с кодом валюты. Потому что деньги, это штука, по которой обычно производится аналитика, суммирование, выборки и т.д. И если у вас JSON, то очевидно, что это архитектурная ошибка, т.к. вы в простейшую арифметику добавляете тяжёлые операции по извлечению и преобразованию строковых данных. Поэтому нет, здесь я вижу, что вы просто используете инструмент не по назначению.
Согласен, с азбукой морзе SQL тоже ужасно работает.
А дожил он до наших дней по чисто историческим причинам, звать которые искусственная монополия, созданная Лоуренсом Эллисоном.
А вас, когда вы такое пишете, не смущает, что реляционная модель, основанная на ней реляционная СУБД и язык запросов к ней — SQL были разработаны в IBM? И что реляционная СУБД от IBM — DB2 — появилась аж в 1982 году и никуда с тех пор не делась, а всегда занимала свою нишу (нишу — потому что у IBM с маркетингом всегда было традиционно плохо)? То есть, что никакой монополии не было изначально?
PS Даже сразу не сообразил, что кто такой Лоуренс Эллисон: он куда более известен как Ларри Эллисон.
Вы сами так построили запрос что он стал тяжело читаем
with agg as (select sum ->> 'currency' as currency,
sum((sum ->> 'amount')::numeric(17, 2)) as amount
from test
group by sum ->> 'currency'),
json as (select json_agg(json_build_object('currency', currency,
'amount', amount))
from agg)
select *
from json;Если разнести построение объекта и все остальное то становится куда проще. Кроме вы сами выбрали json, могли же выбрать составной объект или два поля.
Важно понимать: серьезные субд это не тупая хранилка для json. У вас в запросе неверное предположение что деньги - всегда инт, хотя на самом деле decimal (я поставил с двумя знаками, хотя это не так в общем случае). Кроме завернув данные в json лишили себя возможности простого и элегантного контроля данных на уровне базы (очевидно что currency_code и amount not null и сверху check >0)
upd ну и в копилку про сложность данных, типов стало больше да, координаты и прочая гемоетрия, диапазоны и прочая многомерщина, хитрые exclude constraint и прочая радость. Json на уровне бд это не усложнение типов данных а наоборот, низведение всей прелести до текста.
У вас в запросе неверное предположение что деньги - всегда инт
Маленькая ремарка: деньги могут быть и инт, это нормально. В финансах вообще часто встречается. Просто учёт ведут целочисленно, в центах/копейках.
Ух ты, сколько тут вокруг непрошеных советов, неуместных рекомендаций и нерелевантных «вы все делаете неправильно». Отвечу тут, чтобы пять раз не вставать.
Я пишу библиотеку общего назначения (ORM, если хотите), а не решаю прикладную задачу.
Взять готовенькое, к сожалению, не вариант, потому что я и есть тот самый Пальяччо.
Не сказать, что ваш сиквел как-то особенно более лучше читается, в сравнении с моим, но это и не важно: они не изоморфны (потеряна full composability), и поэтому ваш не пойдет.
Джейсон выбирал не я (см. п. 1), где-то по соседству я оговорился: для тех, кто волен выбирать в базе — я от входа рекомендую composed field, с ним таких проблем, очевидно, нет.
Деньги — это всегда инт, любой школьник, поработавший с деньгами хотя бы годик вам это скажет.
Контроль на уровне базы — штука хорошая, но в случае двух полей мы получаем зыбкое улучшение за счет простых проверок, но теряем консистентность данных и буквально приглашаем прикладных программистов, которые этим кодом будут пользоваться, понаделать невынужденных ошибок из-за неверного апдейта.
Да, джейсон — это неизящный хак, но я не могу обойти всех пользователей библиотеки и сообщить им: вот тут на хабре посоветовали, поэтому вы выбросите свои старые базы, установите постгрес, а там сделайте composed field, по феншую.
Но это все даже не так и важно. Если посмотреть, с чего началась ветка, можно увидеть: я всего-то высказал нехитрый тезис, что закос синтаксиса языка под читаемый английский — очень плохо расширяется и в общем случае не работает.
К этому не имеют никакого отношения советы взять другой код, другой тип данных, другой движок, другую вселенную. Мне надо решить задачу, а не код на собеседовании показать. В реальной жизни код бывает не очень красивый. И то, насколько он красивый, зависит от продуманности языка. Вот и все.
При этом, я люблю сиквел как язык, и считаю, что для своего времени — это было очень круто. Что не мешает мне трезво оценивать его готовность к изменениям (ее отсутствие), расширяемость (еще хуже) и масштабируемость.
Джейсон выбирал не я (см. п. 1),
Ну ок, с этого-то и надо было начинать. Вы используете инструмент неправильно, и пишете, что он плохой. Вам накидали советов, как правильно использовать, тоже ничего страшного (как будто это не в 146% случаев в рунете случается), вы напомнили, что не вы архитектор и поехали дальше. Просто ваш аргумент, что SQL даёт нечитабельный код, надо было подкреплять каким-то другим сниппетом, т.к. в вашем нечитабельный код даёт программист, а не язык.
вот тут на хабре посоветовали, поэтому вы выбросите свои старые базы, установите постгрес, а там сделайте composed field,
Простите, но два раздельных поля поддерживают абсолютно все СУБД без исключения, и это - предпочтительнее, чем пытаться агрегировать все атрибуты денежного поля в один объект, чтобы обязательно упихнуть его в одно поле в таблицу. Такой исключительно фен-шуй слишком дорого обходится вашей библиотеке. А мы ещё удивляемся, почему некоторые ORM'ы так плохо работают.
Прощаю.
Я привык к советам некомпетентных людей, ничего страшного.
Я привык к советам некомпетентных людей, ничего страшного.
Помните анекдот? "Милый, будь осторожнее, тут в новостях передали, по твоей трассе какой-то некомпетентный движется по встречке! - Да какой некомпетентный? Их тут сотни, сотни!"
:)
Помню, конечно.
Просто «тут» — это на хабре, где кроме балаболов уже давно ни одного профессионала нет, а я как бы не один езжу, решения принимаются коллегиально в кругу людей, подтвердивших компетенции делом.
Просто «тут» — это на хабре, где кроме балаболов уже давно ни одного профессионала нет
При этом вы тоже тут на хабре и не то чтобы очень давно. То есть получается кто вы у нас? :)
а я как бы не один езжу, решения принимаются коллегиально в кругу людей, подтвердивших компетенции делом
На Хабр мы все ходим новости почитать и потрепаться, для того он и существует, поэтому логично, что именно сие вы тут и наблюдаете. Что касается ваших компетенций, ну, на словах-то в этом интернете все супермегакомпетентные, одновременно и ИТ-эксперты, и вирусологи, и военные эксперты и так далее. Но всё что я реально про вас знаю, это то, что вы чувак, который денежное поле запихнул в JSON потому, что ему захотелось инкапсулировать сумму и валюту в одном поле, и парсит каждый раз тот JSON при обращениях, помножив на ноль возможности СУБД по работе с числовыми полями. Других данных про ваш профессионализм у меня нет. Поэтому уж извините, покуда никаких других компетенций вас и вашей коллегии я не увидел, судить о вас могу только по имеющимся данным. По крайней мере, компетенции в отношении РСУБД у вас и у вашей коллегии так себе.
Случилось чудовищное недоразумение, вина за которое целиком лежит на мне.
денежное поле запихнул в JSON потому, что ему захотелось инкапсулировать сумму и валюту в одном поле
Я тут про инкапсуляцию какую-то, а вы просто не знаете, что такое fallback. Почитайте, это расширяет кругозор. Если дочитаете, то, возможно, вам будет интересно узнать, что postgres composed type, в который я (не я, но это не важно в контексте дискуссии) запихнул денежное поле в 3÷10 раз быстрее в агрегации в сравнении с двумя полями.
Я знаю, что такое postgres composite types (вы даже как они называются, плохо помните :Р), но во-первых, это просто синтаксический сахар над физически теми же 2... n столбцами в таблице, во-вторых, если они у вас в 3..10 раз быстрее в агрегации, тут у вас опять что-то не то в коде, но уже с двумя полями :)
В-третьих, этот синтаксический сахар - уникальная фича постгреса, и если ваш ОРМ кросс-платформенный, все равно у вас был выбор лишь между двумя полями и кривыми костылями. Выбрали второе, ну ок, ваше дело, все мы иногда сознательно, иногда нечаянно лажаем. Только не надо это как-то оправдывать каким-то решением очень профессионального консилиума или конклава, или что там у вас за высший орган правления в вашем Хогвардсе/Аретузе.
@PuerteMuerte да, каюсь, моя ошибка, я о таком подходе слышал и даже несколько раз его обдумывал, но в живую не видел ниразу, а работаю как раз финансовой сфере. Я себе инты не мог позволить на старте последнего проекта изза целого ряда факторов, самым существенным из которых является проблема с bigint/округлением в гетерогенных средах.
@cupraer
По поводу вашего вступления, замечу что весь смысл комментариев в общении, и тому что я писал есть конкретные причины, а вы злитесь, как будто я пришел к вам домой и цветом коврика недоволен, будьте добрее)
Взять готовенькое, к сожалению, не вариант, потому что я и есть тот самый Пальяччо.
Мы все тут с той стороны, которая делает кнопки "сделай хорошо")
Не сказать, что ваш сиквел как-то особенно более лучше читается, в сравнении с моим, но это и не важно: они не изоморфны (потеряна full composability), и поэтому ваш не пойдет.
Ну мне, как человеку который живет sql, куда проще читать, но тут вкусовщина. Запрос проще для манипцляций, но тоже вкусовщина. А вот в изоморфность я не верю: я очень много и давно работаю с разными базами и почти всегда это приводит лишь к тому, что инструмент плох во всех случаях.
Джейсон выбирал не я (см. п. 1), где-то по соседству я оговорился: для тех, кто волен выбирать в базе — я от входа рекомендую composed field, с ним таких проблем, очевидно, нет.
Верно, но есть другие, например невозможность объявить not null для каждого вложенного поля. Хотя это можно конечно решить через check.
Деньги — это всегда инт, любой школьник, поработавший с деньгами хотя бы годик вам это скажет.
Школьник не архитектор и будет работать с тем, с чем скажут и с шансом в 98% это будет numeric/number
Если он это скажет с такой категоричностью его ждет очень много открытий чудных
Сначала он выяснит что на входе и на выходе от/к пользователю у него всегда float
Потом он совершенно наивно умножит на 10^2, не обеспечит при этом централизованно управляемую систему трансформации
В какой то момент с удивлением обнаружит что умножение на степень 10 не является точной операцей и хорошо, если он добавит округлении только лишь при трансформации пользовательского ввода, иначе его ждет еще много увлекательных приключений
В какой то момент выяснит, что нужно вычислять процент от суммы и поймет что нужно поднять еще на две степени
Вполне возможно (а всего несколько лет назад, практически наверняка) познакомится с особенностями работы с int64 в гетерогенных средах, если не повезет то и с bigInt.
Столкнется с полной невозможностью использовать такой любимый и удобный two-way variable binding во фронтовых фреймворках.
В работе с float при грамотном подходе ничего страшного, в принципе, нет, если не пытаться округлять его при каждом чихе.
Контроль на уровне базы — штука хорошая, но в случае двух полей мы получаем зыбкое улучшение за счет простых проверок, но теряем консистентность данных и буквально приглашаем прикладных программистов, которые этим кодом будут пользоваться, понаделать невынужденных ошибок из-за неверного апдейта
Возможно, но в прикладных решениях смена валюты практически не встречается, а вот сущности с 10+ денежных полей - постоянно.
Да, джейсон — это неизящный хак, но я не могу обойти всех пользователей библиотеки и сообщить им: вот тут на хабре посоветовали, поэтому вы выбросите свои старые базы, установите постгрес, а там сделайте composed field, по феншую.
Конечно нет, потому что никто такого не предлагал и composite types имеет свои недостатки. А вот если вы напишете свой тип с поддержкой всех операторов, с удобными функциями и реализуете прозрачный cast с использованием таблицы курсов, то в ОГРОМНОЕ количество людей вам не то что спасибо скажут, молится на вас будут
закос синтаксиса языка под читаемый английский — очень плохо расширяется и в общем случае не работает.
На что вполне справедливо получили множество замечаний, что, таки, работает.
Если бы SQL был хорошим продуманным решением, в каждом первом фреймворке не городили бы OOM.
SQL хорошо продуман, но совершенно непривычен для большинства разработчиков. Потому что это — декларативный язык: пользователь(так задумывалось, но в реальности все же потребовался программист) выражает на нем свое «хочу», а СУБД это «хочу» реализует. Но разработчики не привыкли к декларативному программированию — они привыкли к императивному (ну, ещё иногда функциональному) программированию на базе той или иной объектной модели — классического ООП ли, аггрегирования ли. И ОРМ (полагаю, что вы именно его имели в виду) как раз предназначен для того, чтобы не затруднять (читай, не поднимать им зарплату) таких разработчиков изучать ещё и SQL.
А ещё SQL был изначально ограничен реляционной моделью данных. А всякие раширения для работы с объектными данными (XML, JSON) для него не органичны.
Если бы
SQLбыл хорошим продуманным решением, в каждом первом фреймворке не городили быOOM.
SQL - хорошее продуманное решение, но он создавался как непосредственный инструмент для работы с данными, когда клиент СУБД и пользователь - одно и то же лицо. Когда клиентами СУБД стали разного рода софтины на разных языках/фреймворках, появилась новая задача, по автоматизации преобразования между тем, что кушает и выдаёт СУБД, и тем, что кушает и выдаёт фреймворк, чтобы избавить программиста от совершенно рутинной и унылой работы по составлению SQL-запросов и парсингу ответов.
SQL - хорошее продуманное решение
[…]
от совершенно рутинной и унылой работы по составлению SQL-запросов
Вижу некоторое противоречие. Кроме того, SQL хорошо работает в ситуации, когда нужно выбрать данные из марксимум пары таблиц, сгруппировать их там, отсортировать, агрегировать.
Но его продуманность показала себя во всей красе, когда варианты типов данных усложнились, и писать запросы на нем стало фактически невозможно без поллитра (см. мой комментарий выше).
Так-то и бейсик прекрасно решал свои задачи.
SQL отлично работает и когда надо работать с кучей таблиц. Как минимум он работает не хуже (а скорее даже заметно лучше) чем альтернативы.
А вот хранить в SQL json'ы и пытаться с ними ещё как-то взаимодействовать при помощи "штатного" функционала самого SQL это уже просто из разряда "месье понимает толк в извращениях".
наоборот - чем больше таблиц в запросе - тем хуже работают OOM.
Ну, кстати, я писал простенькие скрипты на 1С еще не будучи программистом и не зная синтаксиса 1С от слова "совсем".
Так что подход в целом рабочий:)
Более того, тот "голос", который говорит в моей голове при чтении и осмыслении кода, использует другие "слова", другой порядок, совершенно другой подход. Для меня чтение вот таких объяснений это как слушать лекцию человека с неприятным тебе голосом, или с некомфортным темпом рассказа, или с фокусом совершенно не на то, что тебе интересно.
Как по мне, так функция показывает признаки некоторых более глобальных изъянов, и вот один из них:
"enrich", похоже, сильно зависит от порядка вызова.
let object = { a: 1, b: 2, c: 3 }
enrich(object, "a", "c+5")
enrich(object, "c", "b+b")
enrich(object, "b", "8")ответ наверное должен бы быть { a: 21, b: 8, c: 16 }
let object = { a: 1, b: 2 }
enrich(object, "a", "c+5")
enrich(object, "c", "b+b")
enrich(object, "b", "8")а этот пример "сломается" на переменной "a", т.к. "c" ещё не определена, хотя будет определена "попозже".
Имхо функция сначала была просто плохой и непонятной, а после этого "патча", она стала совсем плохой и ещё менее понятной для программиста. И проблема не в квалификации читающего. Я изо всех сил пытался удержаться от комментария по поводу "15 лет программирования", но не смог. Мне кажется, за 15 лет такие функции должны начать вызывать неприятные чувства.
Суть, которую я хотел донести, состоит в том, что Великолепный Инструмент не обратил внимание на подозрительные части, а безропотно помог лишь ещё сильнее ухудшить и без того стремноватую функцию.
А штука в том, что чатгпт не улучшает квалификацию программиста, а лишь безропотно(и не всегда корректно) выполняет поставленную задачу.
Помочь чатгптили тот же копайлот и вправду могут(я, например, для генерации регулярно бингчат(тот же гпт4) пользую, очень уж туго у меня с ними). Но они не сделает из джуна мидла а из мидла сеньёра. Он в текущем виде просто позволяет немного быстрее делать то что ты и так можешь. При этом важно помнить, что не стоит просить гпт сделать что то, чего ты сам не сможешь понять и проверить. Ведь написало оно, а отвечать за этот код тебе.)
За 15 лет привыкаешь что мир программирования это не розовые пони, и часто тратить две недели на рефакторинг куска говна чтоб реализовать хотелку бизнеса слишком долго/дорого. И с чего бы это код вызывал какие-то чувства. Это просто работа.
float wtf( float number )
{
long i;
float x2, y;
const float threehalfs = 1.5F;
x2 = number * 0.5F;
y = number;
i = * ( long * ) &y;
i = 0x5f3759df - ( i >> 1 );
y = * ( float * ) &i;
y = y * ( threehalfs - ( x2 * y * y ) );
return y;
}А что делает эта функция? Ну чёт умножает, чёт сдвигает, чёт отнимает. Но это не ответ.
Ну, ответ гуглится сразу же, если гуглить правильно: по используемому магическому числу 0x5f3759df — уж больно оно специфическое.
Вот только придумал, что нужно использовать именно это число, таки человек. GPT за человеком всего-навсего повторил.
А вот придумать он пока что не могёт.
Вернее, могёт, но глаза б ничьи не глядели.
Достаточно интересно. Оно "мучным конденсатором" назвало ионистор(конденсатор с двойным электрическим слоем). Сейчас там конечно более сложная химия, но начиналось всё как раз с угля(активированного) и папируса(бумага как сепаратор была). Похоже оно не всегда может подобрать правильные слова но суть пытается передать. Если это не случайность, то зачёт.
Тестовые задания вообще только джунам имеет смысл давать и то с последующим разборок вместе, потому что они будут их решать, чтобы хоть куда-то пробиться.
Мидлы и Синьоры скорее выберут миллион других компаний, где и так берут (если, конечно, нет цели попасть в конкретную компанию).
В целом и лайвкодинг в каких-то онлайн редакторах тоже очень спорный, потому что помнить все методы и их перегрузки (например в джавовой стрим апи) сложно, пушо в голове отложен ограниченный их набор, который используется на постоянке и его может быть недостаточно для решения какой-то задачи (тут именно про решение алгоритмических задач с обязательным использованием каких-то наворотов).
Мидлы и Синьоры скорее выберут миллион других компаний, где и так берут […]
Это палка о двух концах. Среди миллионов мидлов и синьёров можно запросто выбрать тех трех, кто не пожалеет пару часов на тестовое дома в креслице вместо стрессового собеседования, а все остальные пусть работают там, где и так берут.
Кроме того, жизнь показывает, что среди тех, кто мнит себя синьёром (с подтвержденной лычкой) — распределение по факту проверки несложного тестового такое: 10% — синьёры, 60% — мидлы, 30% — джуны.
Ни разу не встречал ситуацию, когда тестовое на пару часов было вместо собеса, обычно как дополнение до или после.
А самое главное, что тестовые задания даже не пересекаются с рабочими, зачастую. Условно, в тестовом алгоритмические задачки, а на работе перекидывание джейсонов.
ни разу не встречал ситуацию
Вы же понимаете, что это не означает, что такой практики не существует? Я наше тестовое написал за 40 минут (кстати, если проверяющие сами не решают свои тестовые — их нужно гнать из проверяющих).
тестовые задания даже не пересекаются с рабочими
У нас почти не пересекается. Но это не алгоритмы, конечно. Зачем ему пересекаться? Мне от тестового нужно:
посмотреть, как кандидат умеет в простейшую архитектуру
насколько идиоматичный код получается
как решается задача «покрытия тестами» (вот тут прям ух, сколько можно про кандидата узнать)
и, самое главное, с чего начать разговор на собеседовании «о жизни» (которое, разумеется, будет, но там не будет вопросов типа «сколько параметров принимает функция
fooв третьей версии этой библиотеки)
P. S. оно настолько не пересекается, что я готов рассмотреть тестовое, выполненное вообще на другом языке (в вакансии — руби, тестовое — на хаскеле).
как решается задача «покрытия тестами» (вот тут прям ух, сколько можно про кандидата узнать)
ух блин я такое видел, как решается задача покрытия? а какие тесты? а зачем? ууу…
взяли… в реальности тестов нет совсем, все пушат в master почем зря зачастую забивая на отдельные ветки… вот блин зачем? я причем даже пытался тесты внедрить там но..."а зачем это?" (с)
Ладно если пишешь на одном языке, а если их три и это только повседневные. Типа java, kotlin, typescript. И мучительно вспоминаешь уже завезли в java elvis или все еще страдаем.
да, согласен, вот у меня c#, java, js (Vue.js), pl/sql. Еще был какое-то время python, но от него я давно отвлекся. Ну не то чтобы в голове каша из всего этого, но все нюансы помнить тяжело, да и чтобы они еще были на кончиках пальцев. Я совершенно нормально пользуюсь stack overflow часто для элементарных вещей и совершенно не парюсь по этому поводу. Экономит много времени. Тем более что есть более важные архитектурные проблемы и вопросы.
И еще, обычно много вещей не пишутся с нуля. Есть куча кода в текущих и старых проектах. Ну зачем мне вспоминать например нюансы синтаксиса window functions в MSSQL, я скопипащу то что подходит и поправлю.
Тестовые задания должны быть простыми, но предполагающими несколько вариантов решения. И смотреть нужно не на то, сделано ли оно (я не могу припомнить случая, чтобы мне пришлось проверять тестовое, которое не работает), а как оно выполнено.
Разумеется, сеть решит проход по массиву, эка невидаль, его и старый добрый гуглёж решит. Но по ста строчкам кода всегда виден уровень: использованный подход, идиоматичность кода, архитектура и так далее. До соответствия этим критериям — сетям еще примерно лет сто.
А стажерам с джунами — и прежде не нужно было давать тестовое, с ними нужно разговаривать о жизни.
Без стёба, почему с миддлами и сеньорами недостаточно поговорить о жизни?
Примерно потому же, почему при трудоустройстве подтверждать квалификацию разнорабочего не просят, а хирурга — просят. И даже, гады, диплом требуют.
Я навидался людей, мнящих себя синьёрами, а на деле — не понимающих разницу между мапом и редьюсом.
Но вы же не хирурга нанимаете! Я не вижу взаимосвязи между разнорабочим и джуном, и сеньором и хирургом.
Не знал разницы между мапом и редьюсом. Загуглил 'мап редьюс разница', ткнул рандомную страницу, посмотрел картинку, прочитал описание - узнал.
Это я к тому, что буквально каждый сеньор считает, что любой другой программист должен знать то, в чем он хорошо разбирается. Но уже появилось столько направлений программирования, что все их изучить времени не хватит (особенно, если ты работаешь). А еще проверяющие любят делать выводы по одной строчке кода: делая тестовое, для сравнения расстояния между объектами использовал функцию Distance для наглядности, т.к. главным критерием была названа именно наглядность. В фидбэке получил 'кандидат никогда не занимался оптимизацией кода, т к. там надо было сравнивать квадраты растояния'. И у каждого всё по-разному - один нашел для себя std::vector - и все list, map, статический массив - всё уже сразу 'говорит о непрофессионализме кандидата'. Никакие контраргументы не способны его переубедить, ведь он уже несколько лет начальник, а начальник не может быть не прав. Получив несколько отказов из-за некрасивых названий переменных, неочевидных имен функций, очередное тестовое прежде чем сдать еще неделю рефакторил. Получил отказ с формулировкой 'у тебя слишком структурированный код'.
З.ы. сорри за многобукаф, поиск работы для меня больная тема. А по сабжу - за такие 'формально правильные решения' мне обычно отказы и приходили.
любой другой программист должен знать то, в чем он хорошо разбирается
Отнюдь. Если бы я ждал этого, мы бы вообще никогда никого не наняли.
Но есть прописные истины. Варианты работы с перечислимыми данными — одна из них. На названия переменных, выбранные контейнеры, используемые функции — я вообще внимания не обращаю. Даже на алгоритмическую сложность — по месту, и ваш аргумент «главным критерием была названа именно наглядность» меня бы вполне устроил.
Но не бывает программиста, которому никогда в работе не приходится итерировать коллекцию. Это — базовое знание, на первом курсе учат (должны учить), а если нет — приобретается в первые три месяца работы. Иначе — перед нами человек, который просто бездумно лопатит джейсоны, и мы имеем возможность такому кандидату отказать.
У меня ни разу за 8 лет работы не появилось необходимости использовать reduce. Более того, метод не применялся никем в кодовой базе всех проектов, с которыми я работал.
А вот не понимая, что такое алгоритмическая сложность, очень легко написать программу, которая будет работать существенно медленнее, чем могла бы и не заметить этого.
Вопрос именно в том, что считать прописными истинами.
Ко мне на Java-собес пришёл разработчик с 3.5 годами в Java и 16 ле в 1С по резюме, говорит что он мидл - как не верить с таким-то опытом.
Решаем небольшую задачку на совместный кодинг в IDE на его машине - максимально комфортные условия.
И вот что внезапно происходит:
5 минут убеждал компилятор что он должен переваривать
if (test1) || (test2) {в разных вариациях. При том что до его правок тут было синтаксически корректное выражение и формат можно было взять из него.Собственно саму проверку подразумевающую сравнение переменной
resultс переменнойexpectпревратил в сравнение вхождения значенияexpectв диапазон1 - 1000- откуда тут появился диапазон вообще не ясноФункцию
int applyOp(char op, int b, int a)с реализацией ровно того что описано в её доке (возврат применения указанной операцииopк двум операндамaиb) вызывали с двумя аргументами (это задача на анализ кода) - он выкинулopи реализацию заменил на "всегда складываем операнды"В конце концов привёл код к бесконечному циклу
Ни одного логически корректного изменения не было сделано за 30 минут работы с кодом
И всё равно считал что он "мидл"
Да, можно было "поговорить о жизни" и взять его на испытательный срок - "ведь потом можно уволить".
Только вот кому от этого будет лучше?
Компании? Она посчитает что вакансия закрыта и сократит объём найма, но в итоге человек съест кучу ресусов и всё равно отвалится (мы ищем минимум мидл) и потом обратно начнёт поиск, но потеряет ещё и время.
Кандидату? Он уйдёт от текущей компании, где верятно как-то справляется с его задачами, а потом не останется в нашей компании и будет судорожно искать новое место работы.
К тому же на Хабре проскакивала инфа что и с увольнением в рамках испыательного срока тоже не всё так просто.
При этом сама задачка простая и решается в течении полутора часов максимум, и это если офомлять коммиты и прочую "красоту" - потому и используем её на собесе, а не даём в качестве "домашки" - так можно быстро оценить можество моментов:
анализ существующего кода и алгоритмов в нём заложенных - этим разработчик занимается на любом проекте, пусть и алгоритм будет другим
анализ его взаимодействия с его же основным средством разработки
написание кода, его проверка и отладка
подход к стилю кода, неймингу и прочее
Нет, конечно, вы ничего этого не проверяете потому, что одно дело -- анализировать код, проверять его и отлаживать, взаимодействовать с IDE, когда ты сидишь один или хотя бы с коллегами и совсем другое -- на встрече с совершенно незнакомыми людьми, которые будут тебя сейчас проверять, правда не известно на каких задачах и с какими критериями проверки.
Из вашего описания я вижу, что или человек переволновался невероятно, или он совсем не готов программировать и мыслить логически. Если первое -- то вы, возможно, просто потеряли хорошего кандидата. Если второе, то это можно было узнать без программирования в прямом эфире, а задав вопросы: Расскажи, как ты оцениваешь, что задача выполнена хорошо? Что такое хороший код для тебя? Можно ли привести код к бесконечному циклу? Каким образом? Как себя обезопасить от этого? Программировать для этого не нужно.
Проще всего вообще начинать с резюме: вот у тебя написано, что ты умеешь работать с такой библиотекой. А почему она нужна? Как можно было бы сделать без неё? И дальше следующий вопрос задавать на основе предыдущего. За несколько вопросов легко добраться до ответа "Не знаю" и понять, насколько глубоко кандидат разбирается в том, о чём пишет, что разбирается. Притом с наименьшим стрессом по сравнению с программированием для оценки незнакомыми людьми.
Из вашего описания я вижу, что или человек переволновался невероятно, или он совсем не готов программировать и мыслить логически. Если первое -- то вы, возможно, просто потеряли хорошего кандидата.
Если вы собеседуете человека с 20-летним стажем в разработке, и он так переволновался на собеседовании, что забыл как писать код... ну и что такого, что вы его не взяли? А завтра он переволнуется и забудет как писать код, потому что у него баг тестеры обнаружат. Поймите, стоимость ошибки "упустить одного хорошего кандидата", она многократно ниже, чем стоимость ошибки "нанять плохого кандидата". Вы сегодня не взяли на работу взрослого человека, который очень волнуется, когда его спрашивают по работе другие взрослые дяди? Ну ок, возьмёте завтра другого, который просто напишет вам код без всех этих психологических заморочек, только и всего. И вам плюс, и вашему несостоявшемуся сотруднику тоже полезный опыт, он увидит свою слабую сторону, и сможет поработать над ней. Или просто выберет себе компанию, где код на собеседовании не спрашивают, и тоже ему там будет комфортно. Это нормальный рынок труда, каждый себе подбирает персонал и компанию соответственно по вкусу.
Из вашего описания я вижу, что или человек переволновался невероятно, или он совсем не готов программировать и мыслить логически.
Конечно на собеседовании всегда есть фактор волнения и я его учитываю.
Но как ты не волнуйся делать то что он делал адекватный разработчик не будет.
Если первое -- то вы, возможно, просто потеряли хорошего кандидата.
Потерял кандидата - да. Хорошего - точно нет.
Совместный кодинг, проведение демо, разбор бага с тестером, анализ алгоритма с аналитиком - всё требует совместной работы и часто - с не очень знакомыми людьми, а иногда и на не родном языке.
Если второе, то это можно было узнать без программирования в прямом эфире, а задав вопросы: ...
Вот тут уже начинается подстраивание "вопросов которые нужно бы задавать каждому" под "проблемы возникшие у конкретного".
Дело не в том знает он или не знает "как привести код к бесконечному циклу?" (это можно сделать огромным количеством способов и разными сайд-эффектами) а в том понимает ли он почему "конкретно вот этот код, написанным им вот только что" ведёт себя таким образом - вот тут и становится ясно понимает ли он ответ на такой вопрос или нет.
Что нужно спрашивать чтобы узнать что человек с N лет работы Java-разработчиком при собеседовании на Java-вакансию не сможет написать простейшее условие?
На словах все хороши ...
Я повторю: после того как он испортил всё что там было он всё ещё считал что он мидл.
Нет, конечно, вы ничего этого не проверяете потому, что одно дело -- анализировать код, проверять его и отлаживать, взаимодействовать с IDE, когда ты сидишь один или хотя бы с коллегами и совсем другое -- на встрече с совершенно незнакомыми людьми, которые будут тебя сейчас проверять, правда не известно на каких задачах и с какими критериями проверки.
Странно получается:
если я прошу человека писать код, то я "ничего не проверяю"
если я просто спрошу "а ты хорош?", то я всё это проверю?
И задача и критерии оценки озвучиваются:
исправить Java-код (файл на 99 строк из которых кода только около 70-ти)
нужно чтобы он компилировался (изначально там 4 ошибки компиляции) и работал корректно (присутствует несколько логических ошибок)
ограничений по времени нет (технически мы обычно укладываемся в 2 часа включая 30-40 минут рассказов с нашей стороны, плюс общие вопросы и обсуждения)
разрешена любая любимая
IDE, отладка, документация, Интернет и вопросы ко мне
Мне вот не понятно почему схема взаимодействия с IDE должна меняться от того один чел сидит или в группе?
Если я "в одиночку" вызываю Step over/Step into/Run/Debug/Evaluate через горячие клавиши, то почему "в группе" я должен начать использовать строго клики мышкой? Мне быстрее и привычнее использовать горячие клавиши.
Проще всего вообще начинать с резюме: вот у тебя написано, что ты умеешь работать с такой библиотекой.
Просто чтобы пройти по списку "библиотек" нужно будет потратить кучу времени и при этом всё ещё никакой гарантии что человек сможет писать код.
Когда нужно решить задачу, не важно каким образом она будет решена. Когда нужно создавать видимость работы и копать от забора и до заката, то будут заставлять писать код на листочке в закрытой комнате без интернета.
Как я когда-то говорил: да пускай программист наймёт 3 индусов и 2 джунов, а сам будет сидеть на мальдивах, и после этого будет отдавать код подходящего качества, который проходит код-ревью и выполняет задачу. Какая мне разница?
Правда, я подозреваю, что провернуть такое посложнее, чем самому программировать потому, что проверить чужой код, распределить задачи и объяснить индусу, джуну или чатджипити, что требуется -- навыки сравнимые, а то и более сложные, чем программирование.
Недавно выполнял тестовое задание на Джуна в Европе. Сложное приложение на Джанго или фаст апи , с иерархической структурой , валидаторами , куча рекурсивных функций , тесты , все должно быть обернуто в докер и сделано за 5 дней. По фаст апи , chartgpt вообще ничего путного не давал , по Джанго еще хоть как то. Любой чел со слабыми знаниями не смог бы его выполнить хоть с Chartgpt, хоть без .
Тестовые задания полезны не в бинарном варианте оценки (сделал/не сделал), а как отправная точка для разговора на собеседовании. "Почему так сделал? Почему эдак? А можно иначе? А если чуть условия изменились бы?" И т.п. Раньше ведь тоже никто не помешал бы кандидату попросить сделать тестовое знакомого программиста, и ChatGPT глобально тут ничего не изменил.
Даже интересно где Вы такие python - тестовые для соискателей нашли...
Попробуйте попросить GPT написать что то более реальное и он выдаст вам уйму несуществующих импортов и методов. А затем будет упрекать вас в том что у вас старая версия библиотеки...
Даже если человек использовал нейронки, то он всё равно должен понимать код, который они выдают.
То есть надо проверять именно понимание логики и делается это просто - даете тестовое задание, его выполняют. Дальше вы созваниваетесь на 10 минут и спрашиваете, как надо доработать код, чтобы он выполнял какой-то новый функционал. Даже не нужно просить его кодить, просто словами описать решение.
Если человек понимает, то он сможет сразу ответить, если нет - то нет.
tania_012 хорошо, что Вы написали статью. Но проблема в том, что Вы не проверили большое количество утверждений, например:
- " Наверное, все согласятся, что сущность хомо сапиенс состоит в том, как он обрабатывает информацию, т.е. в работе с информацией. Но компьютер тоже этим занят, только этим он и занят. Раз так, то два игрока на одном не поделенном поле с большой вероятностью будут "сталкиваться". ".
Один абзац, 3 предложения, во всех предложениях допущения или логические ошибки. К примеру, "согласятся" не все, обработка т.н. информации не является сущность хомо сапиенс. Если Вы имели ввиду более конкретное действие, то хорошо бы написать об этом. Вероятно, у Вас не хватает опыта чтобы понять ошибку в суждении. Жители хабра, и вообще хомо сапиенс обычно любят читать сообщения без опечаток, так мне и им будет легче понять Вас.
"Но компьютер тоже этим занят, только этим он и занят."
Занятие компьютера это скорее движение электричества по проводам, как например мельница, которая молет муку, или кукушка, которая КуКукает определённое количество раз в определённое время. Солнце находиться в постоянном движение, но это не значит что оно разумно, или оно собирает информацию и т д.
"Раз так, то два игрока на одном не поделенном поле с большой вероятностью будут "сталкиваться"
Если предыдущих утверждения не верны, почти всегда следующее тоже не верно. Мы не игроки, мы не можем быть сравнены как игроки. Вы, как человек, можете сравнить сахарную вату, лист бумаги, автомобильную покрышку и цветок, от того, что Вы сравниваете они не станут похожи. Вам нужно доказать эту похожесть. Насколько я знаю, на данный момент определённого ответа нет, или я не знаю его. К примеру, в математике у Вас есть числа, и мы договорились, что мы можем их сравнивать и они могут даже быть равными. Но мы не договаривались о равенстве машины и человека.
Судя по Вашему тексту, Вам не так много лет, хотя я могу ошибаться. Если Вам интересны эти темы, прошу Вас дальше продолжать свои изыскания. Жители хабра любят железную аргументацию, в следующий раз, сделайте так чтобы Ваша логика была отличной =)))
Есть такая мысль: что вот человеки помогают размножаться и существовать мемчикам, и в этом и есть сущность человека: поддерживать эволюцию мемчиков.
либо загодя искать новую профессию, либо прицепиться к растущему компьютеру.
Новая профессия: внимательно обращать внимание на те места, где компьютер косячит, и после этого устроиться хакером.
компьютеры стремительно идут вверх, а люди точно стремительно вверх не идут
Стандартный вопрос: а что у вас по осям? То есть, какие величины и в каких единицах измерения у вас на осях координат воображаемого графика, который вы тут описываете. И если с осью абсцисс понятно — там время, то что по оси ординат? Как и в чем мерить «верх» и «низ»? Правильный ответ — никак и ни в чем. Уж по крайней мере — не скаляром.
разве написание текста для машины кардинально отличается от написания текста для человека? Как по мне, то английскими буквами и специфичной упрощенной логикой.
Таки отличается, и не тем, что вы написали. Текст для человека совершенно необязательно писать однозначно: можно надеяться на понимание человеком контекста, который часто у пишущего и читающих общий. А компьютер (тут речь не про ChatGPT, а про старый добрый компьютер) требует однозначности, а потому либо вообще не поймет (обнаружит ошибку), либо поймет не так, как надеялся пишущий, а буквально.
А потому IMHO редакция совершенно правильно отклоннила статью с очевидными даже для КО ошибками.
правильный ответ в том, что мерить надо одной и той же практикой
Дык, практика — она не одна и та же, а весьма разная бывает. Одно дело — в очередной раз заново делать стандартные части программы. Другое — делать что-то новое, требующее творческого подхода. Одной и той же мерой это не измерить. И эффективность компьютера (с ChatGPT или даже без) на этих разных задачах будет по сравнению с человеком сильно разная. В частности, вообще непонятно, может ли компьютер решать действительно творческие задачи. А человек — может.
для вас слово компьютер и слово ChatGPT это разные сущности?
ChatGPT — это все лишь приложение для компьютера. Одно из. И весьма ресурсоемкое, а потому встраивать такую функциональность во все существующие приложения — напрасно тратить ресурсы. А потому большинство приложений пишется по старинке, на формальном языке программирования.
Что есть КО?
Капитан Очевидность (AKA Captain Obvious). Его суперсила — всегда помнить и при случае изрекать очевивидные вещи.
Вам не кажется, что задавать вопросы другому человеку, тут же отвечать на них, и далее делать выводы относительно этого другого человека — это немного не по логике?
Это было по риторике: такие вопросы называются риторическими.
Так ведь человек с огнём круче человека без огня, человек с палкой защищённее, чем человек без палки, человек со станком помощнее, чем человек без станка, человек с гитарой выразительнее, чем человек без неё, человек с компьютером продуктивнее, чем человек без него, и человек с чатджипити тоже. В чём проблема-то?
Читаешь нормальную статью, хлёсткие остроумные комменты, расслабляешься в интеллектуальном спа. И тут, *ля, опять эта Таня... НЛО, сделай уже что-нибудь с этим бесконечным флудом!
Этот текст - просто список пережеванных клише, сформулированных в самой тривиальной форме. Более того, список клише совершенно неполный - нет стандартных возражений и их разбора. Нет даже личного частного опыта. Это флуд.
Тестовое задание на дом — это достаточно наивный фильтр, если принимать достаточным просто его выполнение. И без всяких ChatGPT задача всегда могла быть сделана кем-то кроме кандидата. Основная суть тестового задания — создать поле тем для беседы, не отнимая времени интервью на подготовку: кодобаза получится относительно объемной и предполагается, что кандидат с ней хорошо знаком. Можно обсуждать как выбранные решения в текущем состоянии, так и стратегии развития приложения за рамками условностей демо-проекта.
ЗЫ Разумеется, речь о задачах с упором на архитектуру, на 4+ часа. Мелкие алгоритмы в таких условиях спрашивать смысла нет и не было.
Можно задать пару вопросов по коду и сразу понять, писал кандидат сам или нет. Мы во время ковида делали тестовое удалённо, человек принёс код в котором были три вложенных цикла, от 0 до 1000. Я спрашиваю: сколько раз вызовется функция внутри самого внутреннего цикла. Отвечает: 1000. Не взяли.
А если кандидат, напротив, разбирается в том что принёс, то какая на самом деле разница, сам он писал, взял с SO или попросил GPT сделать это за него?
На самом деле, все эти задачки легко гуглились и до появления ChatGPT. В целом тут ничего не изменилось. Как не было смысла давать такие задачки на дом, так и не появилось.
Другое дело традиционное полноценное оплачиваемое задание. Как показывает практика, ChatGPT не способен писать алгоритмически сложный и комплексный код, в отличии от человека.
Таня, дело не в вершинах. Вы просто вызываете раздражение. Я вот вас в первый раз увидел – и мне уже неприятно (хорошо, минусить не могу: потом не будет стыдно, что на эмоциях расстрелял, не вникая в смысл). И это ещё с поправкой на мой сексизм, я по умолчанию к мужчинам отношусь жёстче, чем к женщинам. А представьте, каково тем, кто с вами уже встречался?
В общем, софтскиллы качать надо.
Всегда считал, что смысл задания именно в том, чтобы проверить, что человек умеет гуглить. То, что теперь "гуглят" через бота - небольшая разница
Пока не вижу серьёзной проблемы. Подобные короткие задания – в изрядной степени тема для разговора. Придёт человек с решением, а его спросят, как поправить код, если условие чуток изменится. И тут уже будет не столь важно, написал он его сам, спросил ChatGPT или соседа Васю. Либо он понимает код и алгоритм, либо нет.
Ну да, не получится отсеять заведомо непригодных сразу, придётся потратить 15+ минут на разговор – но, когда тестовое писали прямо на собеседовании на листочке, времени уходило не меньше. Впрочем, можно прогнать своё дание через ChatGPT самим и поправить условие так, чтобы он всадил ошибку.
Как говорится, 'imho', но даже в первом задании надо суметь поставить нейронке задачу. Потому что для отсортированного массива в решении хочется увидеть слова "бинарный поиск".
Если массивы не отсортированы, но большие по размеру, я бы использовал подход "sliding window" с запоминанием элементов в структуре, позволяющей сохранять порядок их взаимного расположения.
И только для маленьких массивов с высоким ожидаемым количеством вхождений я бы рассмотрел решение цикл-в-цикле.
Подозреваю, что и ChatGPT даст такой ответ, если правильно задать вопрос.
А умение правильно задать вопрос/цель - это 90% всей работы.
Если Вы хотите, что бы получился предметный разговор - нужен Абстракт, то есть короткое содержание вашего изложения в одном абзаце, с упором на то, что в Вашем изложении есть такого, чего мы раньше не читали в десятках других мест.
1) Если шахматы не творчество и даже го не творчество, то что тогда творчество? 2) О творчестве компьютера не надо судить по лепету его новорожденного 3) Миллиарды людей решают НЕ творческие задачи, тысячи из них вообще не способны на такое — это не проблема завтрашнего дня?
- И шахматы, и го — это игры с полной информацией. И для выигрыша в них творчество не обязательно: в принципе, достаточно полного перебора. Хотя большой массив результатов уже сыгранных партий позволяет найти некоторые эвристики, уменьшающие трудоемкость перебора. А перебор — это то, что компьютер делает всяко лучге человека.
Но не все игры такие: к примеру, покер — уже игра с принципиально неполной информацией, хоть и с формальными правилами. А что до жизни, то там ещё и с выяснением формальных правил сложно. - Пока способность к творчеству компьютером не продемонстрирована, так что позитивные рассуждения о ней сейчас просто невозможны. Предлагаю вернуться к этому вопросу лет через сто ;-)
- Более того, немалое число из этих миллиардов вообще занимаются физическим трудом, т.е. используют, в основном, не свой мозг, а свои мышцы. Но практически все они потенциально могут использовать мозг, причем (я подозреваю, хотя это строго и не доказано) — творческим образом: знали бы вы, насколько те же грузчики способны к творческому подходу для удовлетворения своего желания что-нибудь сп
иереть.
После вчерашней(уже удаленной) записки про народец почитал все Ваши комментарии в попытке понять что же такого запретного Вы хотели донести. И, как и все, ни чего не понял. “ИИ победил, давайте думать как с этим жить” - вся мысль укладывается в 1 предложение. Зачем столько букв и рассуждений между которыми невозможно провести логическую связь. Вы просили совета, у меня есть чуть-чуть:
Определите о чём Ваша статья. Какую информацию читатель должен из неё получить. Пишите только об этом, без “прыжков” вправо-влево. Мысли случайного человека не являются полезной информацией. Если это претензия на что-то новое, полезным оно может быть только в формате исследования, но не рассуждения.
Удалите из статьи всё, что не относится к предыдущему пункту и структурируйте что осталось. Если с этим есть сложности дайте почитать черновик друзьям. Тот факт что Вы сами понимаете “косяки” не дает скидок, их нужно исправлять, а не требовать лояльности. Возможно на это придётся потратить не один месяц тренировок. Я вот двух слов без ошибок написать не могу, Вы же не хотите читать статьи в таком виде?
Разберитесь в теме вопроса. Если Вы пол года пытаетесь опубликовать статью по теме которая волнует, при этом называете игру в шахматы творчеством, кажется, не сильно она волнует и дальше пустого фантазирования Вы в вопросе не продвинулись.
Не ищите виноватых и не оскорбляйте людей за свои неудачи. Карму минусят не админы или мифические старожилы. Аудитория хабра это почти всё русскоязычное ИТ сообщество, в небольшом количестве не только ИТ и не только русскоязычное. Если это всё “подхалимы и глупый народец” то для кого была статья? Токсичное хабр сообщество - вымысел тех кто слил учетки в политических срачах и говностатьях или “звезд”, у которых два мнения: своё и неправильное, теперь они в личных блогах могут писать чушь и удалять комменты - на душе спокойно. Хабр конечно уже не торт, но что-то я тут ни разу не видел заминусованной качественной технической статьи. Мало просмотров, если это что-то слишком специфичное, может быть. Всё как везде.
Мне вот интересно, на каком датасете они ее обучали? пара задач явно с литкода, и там вроде как, проявив терпение и заплатив денег, можно оочень много решений нагрепать. Но вот задача про декоратор, или клиент-серверный пинг-понг, где они такой датасет взяли?
Ну и кто-то пробовал, например, StarCoder на этих задачах (мой ноут его не тянет), и если да, то статья очень будет приветствоваться.
А раньше эти задания можно было дать другу-программисту, а то и вообще на аутсорс. Ничего, всё равно отсеивали как-то)
Если кандидат вздумает надуть с домашним тестовым, то инструменты тут не важны. Тут скорее нужно понимать, для чего вообще домашние тестовые нанимателю
Если ваши тестовые задания может решить нейронка - значит у вас плохие тестовые задания.
В моем тестовом задании для трудоустройства нужно было написать asp net core mvc приложения с доской объявлений и системой авторизации.
Причем, объявления были с картинками, а система авторизации с ролями (админ и юзер).
Слабо сделать такое в chatgpt?)
Слабо сделать такое в chatgpt?)
Как раз в чатгпт может быть и получилось, не без рихтовки напильником, конечно. Приложение достаточно рутинное, из готовых кусков кода собрать вполне себе можно, т.е. нейронка должна хотя бы в общем плане справиться. Но вот мне было бы слабо сделать это в реале при трудоустройстве. Я бы сказал: "Господа, помножьте мой рейт на оценку по часам на эту задачку, и вот с такой оплатой я вам, без проблем, это сделаю". Тестовое задание должно показывать умение программировать, и не более того, а не быть рутиной на несколько часов и тем более дней. Идеальное задание - которое делается здесь и сейчас за 20 минут. Если на дом - то на час.
Кажется, вы больше не должны давать тестовые задания кандидатам на дом