По-человечески я вам сочувствую. Вам обещали "царский путь" в IT (вместо 5 лет института 9-18 месяцев курсов), а оказалось что обманули.
С профессиональной точки у меня к вам два вопроса:
В какой форме обычно вкатуны en masse приходят к мысли "явно обманывать работодателей при приёме на работу"? Это "личное дело каждого" или "подсмотрели идею на форумах" или ближе к концу курсов явно помогают так сделать (в виде советов по "приукрашиванию" резюме)? Насколько сильно и откровенно помогают?
Есть проблема - множество людей, квалификации которых не хватает для существующих вакансий. Как вы предлагаете проблему решать? (в данный момент "вкатуны" - хотят устроиться на вакансии обманом, где их квалификации не хватает и первый работодатель будет дообучать их за свой счёт - работодателей это не устраивает).
П.С. Требования к джунам адекватны текущей экономике - рабочая единица, которая почти нарабатывает на свою зарплату (о прибыли речи не идёт, вот честно).
Люди выдают явно учебные проекты за рабочие. Любой инженер в своей области - на раз их отличит Но для этого нужно время этого инженера - а наша задача разгрузить его от этой текучки.
Натренировать девочку-HR или даже нейросеть - малореально.
Фундаменталку могут делать 1.5 конторы в РФ (ну ладно я с десяток насчитал) - но запись такой конторы в резюме - уже повод поговорить с человеком.
А мелкие конторы - делают что-то очевидно прикладное и с очевидным применением в конкретной внешней системе.
> Можете привести пример адекватной, по вашему мнению, задачи для FPGA-мидла? - ethernet + кусок сетевого стека (потому, что HF + [training / CV / радары ) - криптография с конкретным прикладным применением - "бабочка" (DFT / Адамар) - с конкретными специфическими требованиями
*) Замечу, что людей уходящих из военки я не увидел (ну просто в начале 2024 перестал собеседовать). Но проглядев с 10к резюме - любой начнёт отличать реальную работу от записанного в резюме курсовика по CV.
HR создаёт шаблонную+- вакансию и использует шаблонные
Вы плохой Нострадамус. Текст вакансиий писал я сам, пояснение "что делаем мы" и "что нужно будет делать кандидату" - для начала общения HR-кандидат тоже я.
И да "подсказка" непонятна, поэтому задам два вопроса: - сколько собеседований вы провели с 2020 года? - как надо действовать, чтобы не тратить труд квалифицированных специалистов на отсеивание заведомо неподходящих вкатунов?
П.С. Даже если в заявке почти прямым текстом написано "вкатунов не беспокоить, требования такие что вы не справитесь" - всё равно подаются сотни резюме. Кажется что вкатуны на текущем рынке рассматривают первую работу (после курсов \ стажировки) - не как работу (где ты получаешь деньги за выполнение задач работодателя), а как "последний этап обучения", - где надо правдами и неправдами получить запись о годе работы в трудовой и свалить уже на "честную вакансию миддла".
Вам как бизнесу очень хочется, чтобы технические специалисты росли вширь. Т.е. программист, отвечавший раньше за технические решения в каком-то модуле взял техническую ответственность за всю подсистему.
Предиктором того, что человек идёт по этому пути - является большое число горизонтальных связей вокруг того блока, которым он занимается.
На месте менеджера можно установить для себя "некоторые маркеры" - человек растёт таким образом.
Fauxductivity - это хакинг тех самым "маркеров менеджера".
Т.е. ты не только делаешь свою делянку. Но и распускаешь павлиний хвост - как будто ты отвечаешь за всю крупную подсистему.
Послушайте ну вот в этом вашем комментарии неправильно почти всё. От начала и до конца.
1. Автор имеет право использовать термин в каком-то специфицированном виде (т.е. называть красный цвет "зелёным" нельзя, но называть специальный вид экзамена "экзаменом" - можно) . Автор неявно это сделал "экзамен - в том смысле в котором собес превратили в экзамен в последние 5 лет". Если вы умнее - вы же и должны написать, что термин использован неверно. А не вводить всех читающих в заблуждение. Когда в статье "экзамен" значит одно, а в вашем комментарии "экзамен" - значит другое.
2. Приходит собесится на синьёра != синьёр (и даже хотя бы миддл). Это собственно проблематика "вкатуны сломали найм" последних 5 лет, примерно. И вы именно этот момент напрочь игнорируете. Ещё раз - вы напрочь игнорируете собственно основной лейтмотив статьи: "Найм сломан "вкатунами". Корпорации приспосабливаются. Приспосабливаются из рук вон криво." (Нанимал - отсобеседовал на позицию "миддл system programmer" человек 20-30 в 2022-2023 годах. Т.е. проблематику 1.5 года назад понимаю вполне хорошо. Отменторил человек 10 за карьеру. На обоих последних местах работы у нас были базовые кафедры в хороших универах - первокуров-третьекуров не просто видел, лично дообучал).
3. Человек обязан уметь програть алгоритмы - это необходимое условие. Но очень, очень, ОЧЕНЬ недостаточное, особенно по последним временам. Основная проблема вашего подхода - вам нужен инженер (человек, который через 2-3 года станет инженером), а гоняете вы его по алгоритмам. Это сильно-сильно разные области знаний, и даже человеческой деятельности).
В статье говорится про тип плохих экзаменов, появление которых на собеседованиях мы наблюдаем лет 5 как - с тех пор, как мотивацией кандидатов на собеседовании стало "пройти этот фильтр".
Если вы считаете, что собеседования всегда были экзаменами - но у вас термин "экзамен" не такой, как у автора статьи - то о разнице в терминах следует писать явно. Кому следует? Тому, кто хочет чтобы его всерьёз воспринимали как нормального собеседника (а не как держащего фигу в кармане "ненадёжного рассказчика").
Ну и до кучи туда же:
> Что такое экзамен "как в статье", против чего выступает автор:
Что такое экзамен.
Ох уж это выборочное цитирование.
мне нужно убедиться... Что человек умеет программировать.
Сдаётся мне вы или лукавите или одно из двух хД: Люди умеют программировать, в смысле обхода двоичного дерева, - после 1го курса хорошего универа или после 2 курса среднего универа. Но в большинстве случаев сегодня для того, чтобы быть инженером-программистом этого недостаточно.
Что вам нужно: Убедиться, что человек, способен решать сложные инженерные задачи со свойствами: 1. они разнообразные 2. нечётко сформулированы, 3. с заранее неизвестным множеством решений 4. множество возможных решений не упорядочено "от лучшего к худшему". 5. вы ожидаете, что сотрудник на основе своей квалификации выберет наиболее подходящее в текущем контексте.
Что вы делаете: Вы поддерживаете идею "устраивать экзамен как в статье".
Что такое экзамен "как в статье", против чего выступает автор: решение задачек, со следующими свойствами: 1. задач ограниченное множество (часто заранее известное) - алги, язык, "паттерны" 2. Задачи имеют +/- канонические формулировки; 3. Задачи имеют +/- канонические решения 4. У задач есть канонические "решения лучше" и "решения хуже".
Я был бы только за. Но проблема в том, что это не работает - т.к. одна из необходимых вещей, которые надо вычленить, - "правдивое резюме" или нет. И "в общем случае" это не вычисляется. Только в каждой небольшой специфической области (*) А всерьёз вкладываться в нейросетку (пусть даже дообучение) которая полезна 10_000 человек во всём мире - пока никто не будет. Рынок не тот.
Ну и по сути это заменяют одной из стадий - алгоритмическое интервью. Хотя бы сразу же есть измеримый показатель "кандидат умеет программировать" - пусть и олимпиадно, но хоть как-то.
*) Ну вот в системном программировании, скажем - миддл не должен "писать пятистадийный конвейр вычислительного процессора на FPGA" или "реализовывать SHA/AES/... на CUDA" - это в лучшем случае курсовики студенческие. А вот какое-нибудь "писал USB-драйвер по Windows для общения с криптографическим токеном" - скорее всего правда.
до начала 2024 исполнял роль тимлида. На вакансию "миддл-программист" 1000 откликов. Из них 250 отбираются HR как подходящие для резюме (из них больше половины - вкатыши подделавшие свои резюме так, чтобы пройти HR-фильтр).
250 резюме отсмотреть выше моих сил. Готов я при этом к примерно - ну пусть 100 резюме отсмотреть и провести 20 собеседований.
Вопрос - как 250 резюме (с больше половины обманывающих вкатышей) сократить до 100 резюме / 20 собесов? Собственно "многоуровневые" интервью идут оттуда.
П.С.1 20 собесов - я готов провести нормально разговаривая с кандидатом о том, что релевантно в его опыте. - какие ваши три последние проекта? - какую про самую "крутую" вещь которую вы лично реализовали на этих проектах ("техническую или бизнесовую" - а это вы сами выбираете что рассказать) ....
П.С.2 К стати "реферальный найм", - разумеется если по рефералу "программист приводит программиста", - одно из лучших, пока, решений. Вот пусть тот миддл+ / синьёр в команде экспертизе которого я доверяю и проведёт промежуточный скрининг между мной и HR-ом. Чтобы довести число "очных собеседований" до 20.
Вопрос - "программист" и "вайбкодер" - это одна и таже профессия или разные? Сейчас выглядит так, что разные: - вайбкодер - фуллстек для разработки мелких приложух \ MVP - программист - для работы в крупных, prodaction-ready проектах.
А если профессии разные - то какой смысл middle+ программисту переучиваться на вайбкодера, чтобы начинать карьерный путь с 0?
Скромный, не забудьте про мою потрясающую скромность!
Извините, но если человек говорит "я не ошибаюсь в граничных условиях, а ещё пишу код быстро", - а вы говорити по сути это, то я ему не верю.
Помимо того, что это крайне сложный навык у меня есть и практические наблюдения.
Мы пару раз в своей команде компиляторщиков проводили эксперимент: white-boarding задачек из собеса (когда выяснялось "что-то собеседуемые задачки решают плохо").
Меньше 50% справлялось, основные ошибки - на граничных условиях.
П.С. Сейчас я уже восстанавливаю по памяти (дисклеймер: порядка 20% воспоминаний ложные), но ЕМНИП модный нынче exhausting проблемой не был. А вот ошибки ан +/-1 - были.
Ну мне кажется что вы либо литкод заучиваете либо давненько BinSearch написать не пытались, либо вам повезло проскочить одно узкое место.
Там весьма коварные граничные условия, которые нужно либо помнить, либо копипастить либо есть шанс 50% (как встретить динозавра) просто написать неверно с первого раза, а потом 30 минут отлаживать (как раз до конца интервью с нерешённой задачей).
Из минусов - вряд-ли у вас будет личный наставник который поможет
Ну тут всё как обычно (я на степике курс по Хаскелю смотрел): плоть от плоти университетской системы образования - самые бойкие и сообразительные студенты получают подавляющее большинство времени лекторов.
Но в целом исходный формат степика - короткие теоретические материалы, и сразу же практические задания к ним - прям должен очень помогать (разумеется тут к каждым 5-10 часам такой теории нужен какой-то практический проект тоже на 5-10 часов), к сожалению не все курсы им пользуются и многие вырождаются в "вот вам лекция на 3 часа".
Мне вот интересно - что важно при составлении программы обучения, а что нет (сам больше чем "менторингом" джунов не занимался, но 1-vs-1 и учитель-vs-клас - совсем разные форматы. Для первого нужен обычный здравый смысл, для второго - нехилый опыт)?
Можете дать какие-нибудь релевантные ссылки по теме (в том числе на тот свой отзыв, что упомянули в комментарии)?
Но сегодня более содержательный термин - ЯНУ то, что позволяет управлять ресурсами аппаратуры напрямую, желательно без сайд-эффектов (как минимум в критических к этому секциях).
Простите (ну вот реально не воспримите за наезд), - а зачем вы про "2*2 = 4" портянки пишите. Я же всё про техническую часть написал до вас.
============== Из интересных затронутых тем - действительно в сегодняшнем употреблении: "ЯВУ != ~ЯНУ". Т.к. ЯВУ - про удобство наворачивания абстракций, а ЯНУ - про возможности работать с ресурсами аппаратуры напрямую.
Ну а про термины - могу только повторить: сегодняшнее словоупотребление, учитывая современный контекст (оставить ассемблер единственным синонимом ЯНУ - было бы странно) в отношении ЯНУ мне вполне устраивает.
Биться за термины ради терминов в этом месте - считаю если честно малопродуктивным.
Ну а термины "язык высокого уровня" и "язык низкого уровня" появились очень давно -- вместе с Фортраном и Коболом
Я в курсе. Более того в институте я учил определение "ЯНУ" примерно как вы сказали.
Но времена меняются и сегодня такое определение выглядит для меня устаревшим, самое главное потому, что оно мало содержательно.
======================== Разумеется о значении терминов не спорят, а договариваются (поэтому я не могу запретить вам быть тупоконечником, вы мне остроконечником - но для меня это не столь принципиально). Но сегодня более содержательный термин - ЯНУ то, что позволяет управлять ресурсами аппаратуры напрямую, желательно без сайд-эффектов (как минимум в критических к этому секциях).
Вообще-то, язык низкого уровня -- только ассемблер.
Довольно глупое определение (хотя я не могу запретить вам быть тупоконечником).
Смотрите, положим на минуту, что ассемблер( = мнемоника над ISA) единственный вариант языка низкого уровня, то зачем нам два термина "ассемблер" и "низкоуровневый ЯП". Достаточно одного. Но оба термина существуют - значит оба нужны и полезны.
Скажите, а в проектах, в которых вы учавствовали, сколько времени, по вашим оценкам тратилось на интеграцию уровня системы в сравнении с разработкой всей системы (какую-нибудь удобную вам, но понятную метрику)?
Ну и второй вопрос, чтобы диалог проходил быстрее, - о какого уровня проектах идёт речь в ваших оценках, примерно?
По-человечески я вам сочувствую.
Вам обещали "царский путь" в IT (вместо 5 лет института 9-18 месяцев курсов), а оказалось что обманули.
С профессиональной точки у меня к вам два вопроса:
В какой форме обычно вкатуны en masse приходят к мысли "явно обманывать работодателей при приёме на работу"? Это "личное дело каждого" или "подсмотрели идею на форумах" или ближе к концу курсов явно помогают так сделать (в виде советов по "приукрашиванию" резюме)? Насколько сильно и откровенно помогают?
Есть проблема - множество людей, квалификации которых не хватает для существующих вакансий. Как вы предлагаете проблему решать?
(в данный момент "вкатуны" - хотят устроиться на вакансии обманом, где их квалификации не хватает и первый работодатель будет дообучать их за свой счёт - работодателей это не устраивает).
П.С.
Требования к джунам адекватны текущей экономике - рабочая единица, которая почти нарабатывает на свою зарплату (о прибыли речи не идёт, вот честно).
Люди выдают явно учебные проекты за рабочие.
Любой инженер в своей области - на раз их отличит Но для этого нужно время этого инженера - а наша задача разгрузить его от этой текучки.
Натренировать девочку-HR или даже нейросеть - малореально.
Фундаменталку могут делать 1.5 конторы в РФ (ну ладно я с десяток насчитал) - но запись такой конторы в резюме - уже повод поговорить с человеком.
А мелкие конторы - делают что-то очевидно прикладное и с очевидным применением в конкретной внешней системе.
====================================================
> Можете привести пример адекватной, по вашему мнению, задачи для FPGA-мидла?
- ethernet + кусок сетевого стека (потому, что HF + [training / CV / радары )
- криптография с конкретным прикладным применением
- "бабочка" (DFT / Адамар) - с конкретными специфическими требованиями
*) Замечу, что людей уходящих из военки я не увидел (ну просто в начале 2024 перестал собеседовать). Но проглядев с 10к резюме - любой начнёт отличать реальную работу от записанного в резюме курсовика по CV.
Вы плохой Нострадамус.
Текст вакансиий писал я сам, пояснение "что делаем мы" и "что нужно будет делать кандидату" - для начала общения HR-кандидат тоже я.
И да "подсказка" непонятна, поэтому задам два вопроса:
- сколько собеседований вы провели с 2020 года?
- как надо действовать, чтобы не тратить труд квалифицированных специалистов на отсеивание заведомо неподходящих вкатунов?
П.С.
Даже если в заявке почти прямым текстом написано "вкатунов не беспокоить, требования такие что вы не справитесь" - всё равно подаются сотни резюме.
Кажется что вкатуны на текущем рынке рассматривают первую работу (после курсов \ стажировки) - не как работу (где ты получаешь деньги за выполнение задач работодателя), а как "последний этап обучения", - где надо правдами и неправдами получить запись о годе работы в трудовой и свалить уже на "честную вакансию миддла".
Вам как бизнесу очень хочется, чтобы технические специалисты росли вширь.
Т.е. программист, отвечавший раньше за технические решения в каком-то модуле взял техническую ответственность за всю подсистему.
Предиктором того, что человек идёт по этому пути - является большое число горизонтальных связей вокруг того блока, которым он занимается.
На месте менеджера можно установить для себя "некоторые маркеры" - человек растёт таким образом.
Fauxductivity - это хакинг тех самым "маркеров менеджера".
Т.е. ты не только делаешь свою делянку.
Но и распускаешь павлиний хвост - как будто ты отвечаешь за всю крупную подсистему.
Послушайте ну вот в этом вашем комментарии неправильно почти всё. От начала и до конца.
1. Автор имеет право использовать термин в каком-то специфицированном виде (т.е. называть красный цвет "зелёным" нельзя, но называть специальный вид экзамена "экзаменом" - можно) . Автор неявно это сделал "экзамен - в том смысле в котором собес превратили в экзамен в последние 5 лет".
Если вы умнее - вы же и должны написать, что термин использован неверно. А не вводить всех читающих в заблуждение. Когда в статье "экзамен" значит одно, а в вашем комментарии "экзамен" - значит другое.
2. Приходит собесится на синьёра != синьёр (и даже хотя бы миддл).
Это собственно проблематика "вкатуны сломали найм" последних 5 лет, примерно. И вы именно этот момент напрочь игнорируете.
Ещё раз - вы напрочь игнорируете собственно основной лейтмотив статьи: "Найм сломан "вкатунами". Корпорации приспосабливаются. Приспосабливаются из рук вон криво."
(Нанимал - отсобеседовал на позицию "миддл system programmer" человек 20-30 в 2022-2023 годах. Т.е. проблематику 1.5 года назад понимаю вполне хорошо. Отменторил человек 10 за карьеру. На обоих последних местах работы у нас были базовые кафедры в хороших универах - первокуров-третьекуров не просто видел, лично дообучал).
3. Человек обязан уметь програть алгоритмы - это необходимое условие. Но очень, очень, ОЧЕНЬ недостаточное, особенно по последним временам.
Основная проблема вашего подхода - вам нужен инженер (человек, который через 2-3 года станет инженером), а гоняете вы его по алгоритмам. Это сильно-сильно разные области знаний, и даже человеческой деятельности).
В статье говорится про тип плохих экзаменов, появление которых на собеседованиях мы наблюдаем лет 5 как - с тех пор, как мотивацией кандидатов на собеседовании стало "пройти этот фильтр".
Если вы считаете, что собеседования всегда были экзаменами - но у вас термин "экзамен" не такой, как у автора статьи - то о разнице в терминах следует писать явно.
Кому следует? Тому, кто хочет чтобы его всерьёз воспринимали как нормального собеседника (а не как держащего фигу в кармане "ненадёжного рассказчика").
Ну и до кучи туда же:
Ох уж это выборочное цитирование.
Сдаётся мне вы или лукавите или одно из двух хД:
Люди умеют программировать, в смысле обхода двоичного дерева, - после 1го курса хорошего универа или после 2 курса среднего универа. Но в большинстве случаев сегодня для того, чтобы быть инженером-программистом этого недостаточно.
Что вам нужно:
Убедиться, что человек, способен решать сложные инженерные задачи со свойствами:
1. они разнообразные
2. нечётко сформулированы,
3. с заранее неизвестным множеством решений
4. множество возможных решений не упорядочено "от лучшего к худшему".
5. вы ожидаете, что сотрудник на основе своей квалификации выберет наиболее подходящее в текущем контексте.
Что вы делаете:
Вы поддерживаете идею "устраивать экзамен как в статье".
Что такое экзамен "как в статье", против чего выступает автор:
решение задачек, со следующими свойствами:
1. задач ограниченное множество (часто заранее известное) - алги, язык, "паттерны"
2. Задачи имеют +/- канонические формулировки;
3. Задачи имеют +/- канонические решения
4. У задач есть канонические "решения лучше" и "решения хуже".
Я ничего не упустил?
Я был бы только за.
Но проблема в том, что это не работает - т.к. одна из необходимых вещей, которые надо вычленить, - "правдивое резюме" или нет.
И "в общем случае" это не вычисляется. Только в каждой небольшой специфической области (*)
А всерьёз вкладываться в нейросетку (пусть даже дообучение) которая полезна 10_000 человек во всём мире - пока никто не будет. Рынок не тот.
Ну и по сути это заменяют одной из стадий - алгоритмическое интервью.
Хотя бы сразу же есть измеримый показатель "кандидат умеет программировать" - пусть и олимпиадно, но хоть как-то.
*) Ну вот в системном программировании, скажем - миддл не должен "писать пятистадийный конвейр вычислительного процессора на FPGA" или "реализовывать SHA/AES/... на CUDA" - это в лучшем случае курсовики студенческие.
А вот какое-нибудь "писал USB-драйвер по Windows для общения с криптографическим токеном" - скорее всего правда.
до начала 2024 исполнял роль тимлида.
На вакансию "миддл-программист" 1000 откликов. Из них 250 отбираются HR как подходящие для резюме (из них больше половины - вкатыши подделавшие свои резюме так, чтобы пройти HR-фильтр).
250 резюме отсмотреть выше моих сил.
Готов я при этом к примерно - ну пусть 100 резюме отсмотреть и провести 20 собеседований.
Вопрос - как 250 резюме (с больше половины обманывающих вкатышей) сократить до 100 резюме / 20 собесов?
Собственно "многоуровневые" интервью идут оттуда.
П.С.1
20 собесов - я готов провести нормально разговаривая с кандидатом о том, что релевантно в его опыте.
- какие ваши три последние проекта?
- какую про самую "крутую" вещь которую вы лично реализовали на этих проектах ("техническую или бизнесовую" - а это вы сами выбираете что рассказать)
....
П.С.2
К стати "реферальный найм", - разумеется если по рефералу "программист приводит программиста", - одно из лучших, пока, решений.
Вот пусть тот миддл+ / синьёр в команде экспертизе которого я доверяю и проведёт промежуточный скрининг между мной и HR-ом. Чтобы довести число "очных собеседований" до 20.
Вопрос - "программист" и "вайбкодер" - это одна и таже профессия или разные?
Сейчас выглядит так, что разные:
- вайбкодер - фуллстек для разработки мелких приложух \ MVP
- программист - для работы в крупных, prodaction-ready проектах.
А если профессии разные - то какой смысл middle+ программисту переучиваться на вайбкодера, чтобы начинать карьерный путь с 0?
Проблема в том, что "все простые, но экономически выгодные" программы уже написаны. Надо писать сложные, или как минимум чуть менее простые.
А при написании "чуть менее простых" - ИИ не справляется с архитектурой.
Извините, но если человек говорит "я не ошибаюсь в граничных условиях, а ещё пишу код быстро", - а вы говорити по сути это, то я ему не верю.
Помимо того, что это крайне сложный навык у меня есть и практические наблюдения.
Мы пару раз в своей команде компиляторщиков проводили эксперимент: white-boarding задачек из собеса (когда выяснялось "что-то собеседуемые задачки решают плохо").
Меньше 50% справлялось, основные ошибки - на граничных условиях.
П.С.
Сейчас я уже восстанавливаю по памяти (дисклеймер: порядка 20% воспоминаний ложные), но ЕМНИП модный нынче exhausting проблемой не был. А вот ошибки ан +/-1 - были.
Ну мне кажется что вы либо литкод заучиваете либо давненько BinSearch написать не пытались, либо вам повезло проскочить одно узкое место.
Там весьма коварные граничные условия, которые нужно либо помнить, либо копипастить либо есть шанс 50% (как встретить динозавра) просто написать неверно с первого раза, а потом 30 минут отлаживать (как раз до конца интервью с нерешённой задачей).
Ну тут всё как обычно (я на степике курс по Хаскелю смотрел): плоть от плоти университетской системы образования - самые бойкие и сообразительные студенты получают подавляющее большинство времени лекторов.
Но в целом исходный формат степика - короткие теоретические материалы, и сразу же практические задания к ним - прям должен очень помогать (разумеется тут к каждым 5-10 часам такой теории нужен какой-то практический проект тоже на 5-10 часов), к сожалению не все курсы им пользуются и многие вырождаются в "вот вам лекция на 3 часа".
Мне вот интересно - что важно при составлении программы обучения, а что нет (сам больше чем "менторингом" джунов не занимался, но 1-vs-1 и учитель-vs-клас - совсем разные форматы. Для первого нужен обычный здравый смысл, для второго - нехилый опыт)?
Можете дать какие-нибудь релевантные ссылки по теме (в том числе на тот свой отзыв, что упомянули в комментарии)?
Простите (ну вот реально не воспримите за наезд), - а зачем вы про "2*2 = 4" портянки пишите. Я же всё про техническую часть написал до вас.
==============
Из интересных затронутых тем - действительно в сегодняшнем употреблении: "ЯВУ != ~ЯНУ". Т.к. ЯВУ - про удобство наворачивания абстракций, а ЯНУ - про возможности работать с ресурсами аппаратуры напрямую.
Ну а про термины - могу только повторить: сегодняшнее словоупотребление, учитывая современный контекст (оставить ассемблер единственным синонимом ЯНУ - было бы странно) в отношении ЯНУ мне вполне устраивает.
Биться за термины ради терминов в этом месте - считаю если честно малопродуктивным.
Я в курсе.
Более того в институте я учил определение "ЯНУ" примерно как вы сказали.
Но времена меняются и сегодня такое определение выглядит для меня устаревшим, самое главное потому, что оно мало содержательно.
========================
Разумеется о значении терминов не спорят, а договариваются (поэтому я не могу запретить вам быть тупоконечником, вы мне остроконечником - но для меня это не столь принципиально).
Но сегодня более содержательный термин - ЯНУ то, что позволяет управлять ресурсами аппаратуры напрямую, желательно без сайд-эффектов (как минимум в критических к этому секциях).
Довольно глупое определение (хотя я не могу запретить вам быть тупоконечником).
Смотрите, положим на минуту, что ассемблер( = мнемоника над ISA) единственный вариант языка низкого уровня, то зачем нам два термина "ассемблер" и "низкоуровневый ЯП". Достаточно одного.
Но оба термина существуют - значит оба нужны и полезны.
Скажите, а в проектах, в которых вы учавствовали, сколько времени, по вашим оценкам тратилось на интеграцию уровня системы в сравнении с разработкой всей системы (какую-нибудь удобную вам, но понятную метрику)?
Ну и второй вопрос, чтобы диалог проходил быстрее, - о какого уровня проектах идёт речь в ваших оценках, примерно?
Вы сейчас утверждаете, что "системные тесты" (и вообще все проверки уровня системы) - лишняя сущность.
Так?