Здравствуйте, Nuzhny, Вы писали:
N>С одной стороны — да. Тут ещё советуют после тестового приглашатть на второе собеседование и обсуждать написанное, просить его модифицировать. Тоже хороший вариант, но он удлиняет процесс найма. Пока другого способа я не вижу.
А зачем 2 собеседования? Я не предлагал 2. Давай задание заранее, перед собеседованием. Чтобы непеосредственно на собеседовании код и задача были предметом обсуждения.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Shmj, Вы писали:
L>>Внимание, вопрос — как узнать, что ответ задачу не решает? L>>Внимание, ответ — нужно самому быть специалистом в области.
S>Главный критерий — реальный мир, окружающая среда. Окружающая среда должна проверить решена задача или нет.
S>Как это сделать? Если задача выразима в коде — то запускаете код и смотрите что делает этот код.
Есть можно всё, но некоторые вещи только один раз...
Главный критерий — понимание человеком обоснованного результата до запуска кода, это уровень разработчика.
Если нет понимания, то это путь магии или путь тестировщика.
Инструмент для человека, а не человек для инструмента.
На мой взгляд, ты не с той стороны смотришь на проблему.
Здравствуйте, F3V, Вы писали:
F3V>Главный критерий — понимание человеком обоснованного результата до запуска кода, это уровень разработчика. F3V>Если нет понимания, то это путь магии или путь тестировщика.
Главное понимать концепции. А уже как эти концепции выражаются в том или ином языке — можно не заучивать наизусть.
К примеру, нужно понимать принцип — динамический массив, дерево, стек, хештаблица и т.д. А уже какие классы в языке отвечают за них и какие методы нужно вызывать — знать не нужно.
Здравствуйте, Shmj, Вы писали:
S>Где мне это искать? Держать в памяти? Как быстро вы сможете найти ответ? S>Вот GPT подобные вопросы решает за секунды.
Вопрос он "решит", конечно. А потом пароль или личные данные клиентов всплывают где-нибудь и вы попадаете на 100500 денег, три года в судах и банкротство.
Почему?
Потому что это неправильное решение проблемы, которой не должно было быть в первую очередь. А ты полагался на магию.
Что же произошло?
Выбирай сам:
1. Репозиторий имел форки, которые не синхронизировались после применения "магии"
2. Сохранился бранч с тем же коммитом, а то и не один.
3. Имелись бекапы — полные и снапшоты
ЧатГПТ тебе сам об этом не скажет. А ты проверить не догадаешься.
Еще раз — для тех, кто в школе прогуливал физику, мир полон магии.
Здравствуйте, Shmj, Вы писали:
S>Не будьте таким примитивным. S>Главный критерий — реальный мир, окружающая среда. Окружающая среда должна проверить решена задача или нет.
Тестирование в продакшене, да?
Удачи проверять то, что ЧатГПТ насоветует там, где IEC61850 применяется.
S>Как это сделать? Если задача выразима в коде — то запускаете код и смотрите что делает этот код.
Ты не первый и не последний, кто думает, что самое сложное в программировании — это написание кода.
Здравствуйте, landerhigh, Вы писали:
L>Что же произошло? L>Выбирай сам:
L>1. Репозиторий имел форки, которые не синхронизировались после применения "магии" L>2. Сохранился бранч с тем же коммитом, а то и не один. L>3. Имелись бекапы — полные и снапшоты
L>ЧатГПТ тебе сам об этом не скажет. А ты проверить не догадаешься.
По этому важно понимать целостную картину.
Пароль нужно поменять, т.к. в любом случае кто-то мог склонировать.
Но чтобы не позориться — нужно убрать упоминание об этой ошибке насколько возможно.
Именно такой вопрос и формируете GPT и он даст точный ответ очень быстро. А в доке вы будете искать долго, т.к. ситуация не типичная.
Т.е. по прежнему нужно понимать целостную картину — но не нужно знать детали — не нужно помнить конкретную команду или конкретную инструкцию языка.
К примеру, вы должны знать что бывают потоки, что нужно синхронизировать доступ — но вам не нужно помнить как создавать эти потоки в конкретном языке с конкретной библиотекой.
Здравствуйте, Miroff, Вы писали:
M>На самом деле не особо он и прав.
Неправ в чём? В том, что беря человека на алгоритмы надо спрашивать алгоритмы?
M>Исследовательские задачи выполняются совсем в другом масштабе времени. Придти в проект и что-то там по-быстрому оптимизировать в разы можно только если твои предшественники совсем не понимают, что они делают. В реальности, коллеги уже испробовали все наивные подходы: есть нормальные индексы, есть кэши промежуточных вычислений, алгоритмы более-менее адекватны задаче. Ресерч в таком случае делается так: недельку изучаешь литературу, подбирает 3-5 перспективных подходов, неделю делаешь прототип первого подхода, тестируешь, понимаешь что не работает, пробуешь другой подход. К концу месяца понимаешь как надо, ещё два месяца внедряешь в существующий код, потому что там тоже не все просто. И это если ограничится CPU. Если нужно портировать на GPU, то этим вообще занимается отдельный человек, потому что там наивный подход вообще не катит.
Да, проекты на 6-12 месяцев обычно. Так оно и работает. Но есть и поменьше, например, когда текущий наивный очевидный был хорош, но увеличилась нагрузка, узкое место у всех на виду, но задача пока не сильно важная. И специалисты примерно знают, что надо сделать, но руки не доходят. Вот на такие задачи лучше всего сажать людей, чтобы вкатились.
M>И это ещё если удастся ограничиться "классическими" алгоритмами до 2010 года, там хотя бы заранее понятно что лучше, а что хуже. А если нужно что-то более современное, там сплошь нейросети и гибридные вычисления к которым на кривой козе не подъедешь.
Или подъедешь. У меня перед глазами есть образцово-показательное исследование одного корейца (он на Матлебе писал), которое у меня есть в варианте на С++, это хороший алгоритм dehaze:
1. Очень медленная реализация базового алгоритма на Матлабе.
2. Оптимизация под встраиваемое железо.
3. Гибридный на нейросетях.
Это классическая и хорошая научная работа, все стадии, теория, практика, всё норм.
А теперь можно просто взять базовый алгоритм этого исследователя, взять туеву хучу затуманенных снимков с со своих камер, сгенерировать ими датасет и обучиться. Стало намного легче, оптимизация доступная каждому практически даже без знания предметной области.
F3V>>Главный критерий — понимание человеком обоснованного результата до запуска кода, это уровень разработчика. F3V>>Если нет понимания, то это путь магии или путь тестировщика.
S>Главное понимать концепции. А уже как эти концепции выражаются в том или ином языке — можно не заучивать наизусть.
Здесь можно согласиться. Дух творит себе формы. Но знаете ли какого вы духа?
S>К примеру, нужно понимать принцип — динамический массив, дерево, стек, хештаблица и т.д. А уже какие классы в языке отвечают за них и какие методы нужно вызывать — знать не нужно.
Здесь есть две возможности: ты знаешь принципы построения объекта тестирования или не знаешь.
Т.к. может возникнуть вопрос классификации его ошибок, как ошибок реализации принципов или ошибок самих принципов построения.
Тестировщик может указать лишь на факт ошибки в реализации, а классифицировать и исправить её может только разработчик.
Когда тестируешь чёрный ящик, хорошо бы его сделать хотя бы серым, но даже у белого ящика возможны чёрные пятна.
PS: Загляни, например, тут в форум обсуждения C++:
Там хоть и всё доступно, а столько всяких косяков:
от программных (прикладных), компиляторных (реализации) и даже до ошибок/неточностей в стандартах (принципах).
Здравствуйте, Shmj, Вы писали:
L>>Удачи проверять то, что ЧатГПТ насоветует там, где IEC61850 применяется.
S>А у вас что тестовой среды нет — сразу в прод?
S>Должна быть тестовая среда. Там все проверяете — тесты так же GPT может написать. И уже когда все тесты пройдены — тогда в прод.
Здравствуйте, Shmj, Вы писали:
S>По этому важно понимать целостную картину.
Вооот. Если есть понимание "целостной картины", то становится понятно, что "упс, пароль скомпрометирован". Все. И попытки "замести следы" по большому счету бессмысленны.
Те же, кто побегут за магией от "AI", ее, эту магию, и получат. Со всеми вытекающими.
S>Именно такой вопрос и формируете GPT и он даст точный ответ очень быстро.
И снова приходим к вопросу подтверждения точности ответа.
Если я читаю материал, написанный человеком, то в нем присутствуют либо ссылки на источники, либо это результат собственного исследования/эксперимента.
По крайней мере в приличных сообществах типа stackexchange, wikipedia и пр. такого рода требования прямо прописано в правилах.
Реферат без ссылок на источники мало полезен.
Разве что в случае, когда это единственный источник уникальной информации.
S>А в доке вы будете искать долго, т.к. ситуация не типичная.
А зачем тебе быстро?
Ты же сам написал, что в приведенном тобой сценарии "плохой" коммит попал в source control 2 недели назад.
Ведь правка истории в source control — это как раз тот случай, когда торопится не стоит.
Здравствуйте, landerhigh, Вы писали:
L>Вооот. Если есть понимание "целостной картины", то становится понятно, что "упс, пароль скомпрометирован". Все. И попытки "замести следы" по большому счету бессмысленны. L>Те же, кто побегут за магией от "AI", ее, эту магию, и получат. Со всеми вытекающими.
Общую картину знать нужно — а детали в голове уже не нужно держать. Т.е. саму команду вам даст GPT.
Здравствуйте, m2user, Вы писали:
M>И снова приходим к вопросу подтверждения точности ответа. M>Если я читаю материал, написанный человеком, то в нем присутствуют либо ссылки на источники, либо это результат собственного исследования/эксперимента. M>По крайней мере в приличных сообществах типа stackexchange, wikipedia и пр. такого рода требования прямо прописано в правилах.
Если ответ вам нужен для практических нужд — то вы с помощью этого ответа можете решить свою практическую проблему. Если решили — значит ответ правильный. Все просто.
Однако же соглашусь с тем, что чел. должен видеть как бы общую картину — этого GPT пока не может. Детали можно не знать, а общую картину видеть нужно.
S>>А в доке вы будете искать долго, т.к. ситуация не типичная.
M>А зачем тебе быстро? M>Ты же сам написал, что в приведенном тобой сценарии "плохой" коммит попал в source control 2 недели назад. M>Ведь правка истории в source control — это как раз тот случай, когда торопится не стоит.
Быстро нужно чтобы приступить к другим задачам как можно быстрее.
Здравствуйте, Nuzhny, Вы писали:
N>Алгоритм. Распарсить текстовый файл, правильно построить по нему граф и обойти его — вывести строки в правильном порядке. Там есть незаметные глазу нюансы в виде циклических ссылок, догадаться, что нельзя использовать рекурсию, вывести информативно сообщение о возможных ошибках во входных данных. 100-200 строк кода, не больше.
Когда задача становится чисто технической/математической и подробно сформулированна, то это уже самая легкая часть работы программиста и да, в значительной степени может быть автоматизирована. Написание чего-то типа алгоритма архивирования или обхода графа было типовой задачей программиста в 80-х и 90-х и на это тратилось очень, очень много времени. Сейчас надо очень сильно постараться, чтобы найти какую-то подобную нерешенную задачу и подобные задачи это, ИМХО, сильно меньшая часть работы сегодня. Значительно большую часть занимает путь от выскоуровневых требований уровня "сделать хорошо" до сформулированного ТЗ с учетом контекста (используемые технологии, имеющаяся инфраструктура, ограничения по времени и т.п).
Скилл решения олимпиадных задач сильно обесценивается.
Здравствуйте, Nuzhny, Вы писали:
N>Неправ в чём? В том, что беря человека на алгоритмы надо спрашивать алгоритмы?
Можно спрашивать, но большая часть работы будет же не про написание наивного алгоритма, верно?
Здравствуйте, Shmj, Вы писали:
L>>Те же, кто побегут за магией от "AI", ее, эту магию, и получат. Со всеми вытекающими.
S>Общую картину знать нужно — а детали в голове уже не нужно держать. Т.е. саму команду вам даст GPT.
Знающий "общую картину" понимает, что никакая команда не нужна.
А дурак с инициативой побежит выполнять. Хорошо, если не похерит весь репозиторий напрочь.
Здравствуйте, Shmj, Вы писали:
M>>Ведь правка истории в source control — это как раз тот случай, когда торопится не стоит. S>Быстро нужно чтобы приступить к другим задачам как можно быстрее.
Из этого "быстро нужно" отрастали самые заметные факапы в истории.
А в данном случае с репозитораием делать вообще ничего не надо.
Здравствуйте, Skorodum, Вы писали:
N>>Неправ в чём? В том, что беря человека на алгоритмы надо спрашивать алгоритмы? S>Можно спрашивать, но большая часть работы будет же не про написание наивного алгоритма, верно?
Наивного — да, даже писать не надо. Но в области есть ещё не решённые или не сильно решённые проблемы. Из того, что я уже писал — оптимизации Венгерского алгоритма под 2D задачу. Метод связных компонент на GPU я не нашёл (точнее, он есть в некоем cugraph, но это жесть, а не библиотека, да ещё и падает временами). Если про графы, то SSP для потоковых данных, типа такого, чтобы работало быстро (сейчас все работы для этого трансформеры используют). Много алгоритмов для геокоординат, пересечения с рельефом, их сглаживания и уточнения.
Есть желание помоделировать распространение выбросов от автомобилей в городской застройке, типа такого. Короче, много чего интересного, маленького и большого. Где-то надо просто собирать датасеты и тренировать нейросети, где-то больше математики, где-то физики, программирование и оптимизация. Полный набор, короче.
