Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 206
Моя гипотеза как такие граждане выживают
Всё просто: они работают, вывозят сложнейшие проблемы.
А в викторинах на собесах "чем A отличается от B" процветают энциклопедические эрудиты. За них потом и приходится всё вывозить первым.
Вот я, например, недавно провалил техническое собеседование по языку C#. Один из вопросов, на который я не смог ответить: "Какой номер версии C#, с которым вы работали на последнем проекте?"
Номер версии - это действительно моветон, но если (предположим) вы писали на C# компилятор, причем указали что писали именно парсер, у вас не должно быть проблемы ответить на вопрос типа "какая была структура parsed tee в вашем парсере"? Если человек на такой вопрос ответить не может , то он парсера в компиляторе не писал. Или вы не согласны?
ответить на вопрос типа "какая была структура parsed tee в вашем парсере"
это прям единственно правильное название? А lexical tree, token tree, ... и даже комбинация из этих tree нельзя? Без названия parsed tee распарсить не возможно?
мне все равно как он это называет. Пусть опишет структуру, типы узлов, какая информация в них содержится. Если не может - он этого не делал. А это кстати не lexical tree. Лексический анализ в компиляторе и синтаксический анализ - это фундаментально разные вещи.
А это кстати не lexical tree
названия очень часто не соответствуют сути, но их уже никто не меняет, поэтому при определенных особенностях эмоционального восприятия ваш вопрос может быть очень не верно интерпретирован, я бы сначала спросил какого типа структура формируется (tree - это часть ответа все таки, наверно). А то что структуру должен как то рассказать это я согласен. А на какие единицы они разбирают мне было бы даже интересно, я могу делать только предположения, компиляторы не писал, только проверял на соответствие стандарту.
набирал впопыхах, описка - parse tree
parsed tee
Аж загуглил, не отстал ли от шарпа. Parse tree. Не пугайте так :)
Просмотрел кучу реализаций разных языков (в основном, конечно, не мейнстримовых, но и мейнстримовые тоже смотрел), и вот ни разу не встретил, чтобы использовали именно parse tree, обычно это ast, возможно с элементами синтаксиса для вспомогательных целей (типа как в Go, когда хранят токен с его позицией для диагностических сообщений и определении типа операций).
А вот какой-нибудь ANTLR генерирует parse tree, да, но по-другому и быть не может, генераторы парсеров не знают семантику языка.
А для ручных парсеров это просто лишний слой.
Я не разделяю AST и parse tree, употребляю это как синонимы. Я это дело выучил в конце 1980-х на примере portable C compiler (PCC) 1977-го года от Стивена Джонсона, с которым я кстати потом встретился вживую и даже работал в одном офисе. У него в компиляторе было дерево ориентированное на абстрактный синтаксис, то есть AST, которое потом преобразовалось в дерево для генерации кода.
Я не разделяю AST и parse tree, употребляю это как синонимы.
Ну вот опять и снова недопонимание уже на уровне терминологии. Вы задаёте вопрос, собеседуемый по-своему его понимает, и выдаёт ответ который вы тоже понимаете по-своему. Итого вердикт типа "некомпенентный, ничего не понимает", хотя на самом деле разговор в сути об одном и том же.
Так, а как с этим вопросом можно провалиться?
Я начал работать с шарпом лет 10 назад, тогда основными версиями были 4.0 и 4.5
С тех пор шарп у нас перешел на неткор, и там любую лтс версию можно называть и не ошибиться (6-8-10).
Если же вопрос внезапно про версии языка как такового, то я бы тоже завалился на вопросе, потому что языковые изменения незначительные и специфику новых конструкций редко использую, так что 5 версия наверно достаточна мне в 99% случаев, а актуальная где то на 12-14 версиях.
Подождите-ка, но он должен хоть что-то знать хорошо, для вывезения сложнейших проблем. Я не смог найти такой темы в его резюме. Если человек скажем пишет RTOS, он должен регулярно использовать Си и ассемблер и он воленс-неволенс его знает и может ответить на базовые вопросы. Если вы чего-то не знаете, не надо включать это в резюме и нарываться на вопросы.
Почему попадание темы в горячий кэш мясной памяти упорно путается со способностью манипулировать инструментом?
После очередного языка программирования и очередного фреймворка лично я скорее не буду доверять своей памяти и начну перепроверять всеми средствами, от справочников до контроля типов через подсветку в IDE.
Я просто пытался дать ему простой вопрос то тому что он сказал что знает, прежде чем копать глубоко вопросами типа "как бы вы организовали такую-то программу или проверку блока под тестом". Но он на каждый вопрос не отвечал, а перескакивал "я не идельно знаю А, знаю лучше Б". Я сам не люблю эрудитов и викторины, просто он не давал с этого режима выскочить.
Подождите-ка, но он должен хоть что-то знать хорошо
Знать != уметь вербализировать свои знания.
Из ваших вопросов правильный только про “A = B + C”. Человек который знает, действительно просто возьмёт да сделает. И не сразу идеально и набело. Т.е. если чел сходу не спросил про знаковость, это ещё не значит что он некомпетентный. Реальная разработка не ведётся сразу набело, а проходит через множество итераций, в ходе которых и вспоминаются всякие ньюансы, и решения доводится до идеального.
Вопрос про race condition тоже валидный. Это одна из типичных проблем отладки, особенно у людей с опытом менее 2 лет и не следующих определенному темплейту писания кода. Если он на это не нарывался - возникает вопрос сколько у него опыта. Если он сразу переводит стрелку на vhdl - возникает вопрос есть ли опыт вообще. После этого естественно переключиться в режим проверки валидности резюме.
race condition это не проблема отладки, это проблема работы всего параллельного. Вон у нас уже тут недопонимание в терминологии.
Если он сразу переводит стрелку на vhdl - возникает вопрос есть ли опыт вообще.
Не хочу защищать данного персонажа, возможно он и правда не тот за кого себя выдаёт. Но проведение собесов в стиле викторины - это тоже очень плохая практика.
В верилоге есть специфическая форма race condition, которая по сути баг языка (блокирующие присваивания в always @ (posedge clock) a = b; always @ (posedge clock) c = a;) что дает разный результат в разных симуляторах и может дать даже разный разультат до синтеза и после него).Это другое чем эквиваленты в софтверных языках. Против этого придумали делать неблокирующие присваивания <=, но глючный вариант оставили в языке.
Насчет vhdl - если бы он ответил на a = b+c, я бы спросил что-нибудь по делу, например как организовать testbench для какого-нибудь моста из протоколов которые есть в резюме (скажем apb в axi)
Насчет vhdl - если бы он ответил на a = b+c, я бы спросил что-нибудь по делу, например как организовать testbench для какого-нибудь моста из протоколов которые есть в резюме (скажем apb в axi)
Вот правильно. Пример конкретной проблемы - бери да решай. А все эти абстрактные академические вопросы с потолка - люди реального дела плохи в таких вещах.
Я написал ввше: Я просто пытался дать ему простой вопрос то тому что он сказал что знает, прежде чем копать глубоко вопросами типа "как бы вы организовали такую-то программу или проверку блока под тестом". Но он на каждый вопрос не отвечал, а перескакивал "я не идельно знаю А, знаю лучше Б". Я сам не люблю эрудитов и викторины, просто он не давал с этого режима выскочить
Ну он мог предложить объяснить на примере, кто ему мешал?
На вопрос про отличие он меня вынудил сам, посколько довел до необходимости проверить, валидная ли информация у него в резюме. Если человек не знает про рандеву в Аде, то он языка не знает. Это как не знать struct в языке Си. Ада сделана для параллельных процессов.
Более точная аналогия - это как не знать указатели в языке Си. Его главная фишка языка и если человек ее не знает это как использовать Си как Бейсик.
Но при этом человек много лет как-то работал и ему платили за это живые деньги.
Это не человек не знает про указатели в Си. Это задаваемые ему вопросы про указатели в Си требуют от него непонятно какого ответа. Зачастую на собесах получается так.
Но при этом человек много лет как-то работал и ему платили за это живые деньги.
Полезна ли для работодателя такая как-то работа, большой вопрос. А при найме оценивается потенциальный профит от кандидата.
Т.е. предыдущим работодателям была бесполезна, но они всё равно за неё исправно платили много лет?
Может быть только резюме подделано и никакой работы на самом деле не было.
Т.е. предыдущим работодателям была бесполезна, но они всё равно за неё исправно платили много лет?
Bullshit jobs, например.
Т.е. предыдущим работодателям была бесполезна, но они всё равно за неё исправно платили много лет?
Добро пожаловать в реальный мир.
А это разве новость, что довольно большая часть айтишников ничего не делают работе (реально, ничего) и им за это годами платят деньги? :)
Процентов 80 людей, которые пишут на С++ не понимают, что такое указатели.
Ну наверное в GUI с фреймворками это не критично, но если скажем писать компилятор или place-and-route продукт для проектирования микросхем, то там без такого знания трудно - аллокацию памяти нужно хорошо представлять под сложные структуры. А если драйвер или ядро ОС - тем более
Но при этом всё у них исправно работает? Мне бы такое не понимание!
Очень смелое заявление. Я слышал, что 80% сеньоров не могу за пять минут написать работающий FizzBuzz и это может и гиперболизированная, но похожая на правду вещь. А тут... хочешь - не хочешь при изучении C++ с указателями ты столкнешься, и если мы про raw pointers, а не про более новомодные штуки как weak_ptr, то каких-то тонких, но рядовых особенностей, которые можно не понимать или как-то неправильно интерпретировать в них просто нет. Ошибаться легко, но не по причине непонимания, а по причине их неудобства и не безопасности.
Ну тут смотря что такое «понимать».
Я вот уверен, что >80% людей, считающих, что они понимают указатели, не понимают provenance, например.
Можно ли сказать, что ты понимаешь указатели, если ты как-то зыбковато знаешь, зачем именно нужен std::launder, например?
Пипец, первый раз увидел std::launder ! Думаю в aerospace code если такое увижу - будет интересная беседа с “применителем сего” :)
Думаю в aerospace code если такое увижу - будет интересная беседа с “применителем сего” :)
В aerospace code пишут код без указателей или собирают код без оптимизаций?
В рабочем цикле память не выделяется с использованиeм custom allocators. Точнее не выделяется вообще. Стараемся использовать разумный баланс по когнитивной нагрузке. Возможно в каком то месте и придется использовать когда то… но точно будет 10 строк комментария - зачем это делается…
std::launder is rarely needed in typical application code, but it is critical for low-level library development, such as custom allocators or implementing containers like std::vector or std::optional
В рабочем цикле память не выделяется
А кроме рабочих циклов у вас есть там подготовка при запуске какая-нибудь?
с использованиeм custom allocators. Точнее не выделяется вообще.
Память не обязана выделяться из хипа и/или с недетерминированными гарантиями на скорость и успех.
Я время от времени возвращаюсь к говноедству за большие деньги HFT и прочему подобному, и там требования чутка посерьёзнее (потому что недостаточно успеть отреагировать за N микро- или наносекунд, надо к тому же отреагировать быстрее, чем все остальные игроки, которые тоже имеют все стимулы реагировать быстрее всех), да и ответственность тоже какая-то есть (думаю, иногда даже побольше: продолбать пенсии нескольких десятков-сотен тысяч людей, чей пенсионный фонд вложился в ваш хедж-фонд, может быть больнее и социально печальнее, чем невыведенный на орбиту спутник). И там используются и кастомные аллокаторы (пусть и со стека), и std::launder этот вот, и std::start_lifetime_as, и за алиасингом следят, и вообще много чего интересного происходит. Ну и свежие стандарты, конечно, да.
Подготовка есть, нормальные new/malloc, часть памяти в специальных BRAM блоках “выделяется/организуется”, с помощью статических темплайтов с проверкой в compile time.
Про HFT:
Если все пишет один или два супер профи то подход оправдан, правда я думал там (HFT) уже все на уровне железа, FPGA и даже hard-copy ASIC.
Подготовка есть, нормальные new/malloc, часть памяти в специальных BRAM блоках “выделяется/организуется”, с помощью статических темплайтов с проверкой в compile time.
Ну вот, значит, и вам всё это нужно, и вы можете тоже выиграть от тех же кастомных аллокаторов — да хоть даже на стенде залогать и проверить статистику по распределениям, или что-нибудь такое :]
Если все пишет один или два супер профи то подход оправдан
Когда как. Впрочем, лучшие команды, что я видел — там в core infra код писало действительно 2-3 человека (из которых один был спецом по кернелу и сетевым карточкам, например, а остальные полтора были спецами по плюсам).
Чем больше команда, тем почему-то хуже код и результат в целом.
правда я думал там (HFT) уже все на уровне железа, FPGA и даже hard-copy ASIC.
Можно совмещать: маленькую линеаризованную модельку гонять на FPGA, а на большом x86 рядом крутить обновление коэффициентов этой линеаризации из большой нелинейной сложной модели.
Но, впрочем, у меня тут искажённая выборка, так как я в HFT-контексте позиционирую себя специалистом по плюсам и по DSL'ям, и FPGA-only задачи (да и команды в целом) проходят мимо меня.
И смотря насколько глубоко понимать. О Pointer Provenance как по мне любой недавний джун имеет представление, когда по ручкам настучали за reinterpret_cast везде где хочется и нельзя. std::launder на фоне этого вообще не должен никаких проблем вызывать (только решать), но есть тонкость, что его в C++17 ввели и есть прекрасный шанс ни в одном проекте его не увидеть. Я, пожалуй, чаще видел людей, которые про Strict Aliasing не слышали. Сложно ли это? Да не особо, было бы желание.
О Pointer Provenance как по мне любой недавний джун имеет представление, когда по ручкам настучали за reinterpret_cast везде где хочется и нельзя.
Я знаю очень мало мест, где стучат по рукам за reinterpret_cast (или за union-style cast, или за прочие подобные финты) именно с мотивацией про provenance, а не про «ну тут static_cast был бы понятнее». По какому-то странному совпадению туда почему-то очень тяжко найти C++-программистов, и зарплаты там предлагают выше рынка раза в три.
но есть тонкость, что его в C++17 ввели и есть прекрасный шанс ни в одном проекте его не увидеть
C++17 свершился 9 лет назад, конкретно std::launder был предложен почти ровно 10 лет назад.
Хз, как это написать аккуратно, поэтому напишу неаккуратно: не знаю, как надо относиться к работе и к своему профессиональному развитию, чтобы вещи, которые случились десять лет назад в твоей сфере, списывались под предлогом «да этому всего 10 лет, шансы этим ни разу не воспользоваться [ни на работе, ни дома] весьма высоки».
не знаю, как надо относиться к работе и к своему профессиональному развитию <...>
Так мир программистов на C++ он очень разный, чуть ли не полярный. Куча проектов еще живут, которые стартовали на c++03 из соображений производительности, но не той, где наносекунды считают, а где джава рантайм таскать с собой никто не будет а дотнет тогда еле шевелился. Всякий десктоп, локальный энтерпрайз, какие-то модули-числомолотилки, в которых аллокаций вообще нет, специализированная техника, и так далее. Там сидят люди и во всем этом варятся и никакой необходимости в новых компиляторах у них нет, а уж тем более и в новых стандартах. Все равно целиком проект переписать никто не даст, а исправлять по частям смысла мало. Ну и железо все время становилось быстрее, так что если не используешь квадрат, там где n log n хватает - уже большой молодец, а даже если используешь, ну когда (скорее если вдруг) тесно станет, то кто-нибудь починит.
Я как-то на таком работал, например, так вот на работе только палки в колеса ставили, а дома... а дома я выучил C#, меня этот язык реально радует. А часть бывших коллег вообще на эту ерунду еще и дома время не тратили.
Так мир программистов на C++ он очень разный, чуть ли не полярный.
Ну да. И тут мы возвращаемся к исходному тезису:
Процентов 80 людей, которые пишут на С++ не понимают, что такое указатели.
Там сидят люди и во всем этом варятся и никакой необходимости в новых компиляторах у них нет, а уж тем более и в новых стандартах.
То есть, это не профессиональное развитие, это профессиональная смерть.
Все равно целиком проект переписать никто не даст, а исправлять по частям смысла мало.
Исправлять — возможно, да. Но писать новый код с новыми вещами — почему нет?
В том же десктопе и локальном энтерпрайзе сам Нишанов велел разобраться в корутинах, например, и наваять свою библиотечку, чтобы код был компактнее, проще и локальнее. Я так сделал в своём легаси пет-проекте — кода кратно меньше, обработка ошибок кратно лучше (потому что там, где раньше нужно было через границу асинхронных вызовов протаскивать контекст, компилятор это делает сам), о коде размышлять кратно проще, дополнительные фичи напрашиваются сами — можно просто написать
Throttle backoff;
while (!success)
{
co_await backoff;
co_await makeRequest();
…
}добавив две строки для адекватной обработки недоступности сервиса, вместо того, чтобы делать из этого классический асинхронный ужас в стиле C++03 (или даже C++17).
Добавили в C++20 (или 23? забыл уже, но какая разница) более продвинутые non-type template parameters, так что теперь строками можно нормально оперировать в компилтайме — переписал свой ORM-фреймворк на это, чтобы все запросы в компилтайме генерировались, в итоге бинари стали кратно меньше, и работать даже стало чутка быстрее.
Добавили в C++23 (или 26? забыл уже, но какая разница) structured bindings can introduce a pack — вроде мелочь, а шаблонное метапрограммирование стало ещё проще, из своего ORM-фреймворка (куда уж тырпрайзнее и десктопнее) можно удалить много кода и ускорить время сборки, всякая хрень вроде boost.pfr, макросни или magic_get больше не нужна.
А часть бывших коллег вообще на эту ерунду еще и дома время не тратили.
Их свободный выбор. Но некоторые люди на хабре периодически пишут что-то, если сжать мысль, в духе «я на эту ерунду тратить время не хочу, у меня хобби/семья/надо регулярно стирать занавески, так какого хрена работодатель её спрашивает, и тратящие на неё время люди оказываются впереди?»
на собесах […] процветают энциклопедические эрудиты
Удивительно, но под любой статьёй, обличающей незнание базы, появляются такие комментарии. Мол, это всё душные мелочи, которые не нужны в настоящей работе. И обычно дальше дискуссия развивается в сторону, что для настоящей работы вообще не нужны никакие “книжные” знания и поэтому на собеседованиях нельзя спрашивать вообще ничего.
они работают, вывозят сложнейшие проблемы
Я не совсем понимаю, зачем вы заочно защищаете людей, не знающих базы своего технологического стека? Каким образом из неспособности ответить на простейшие вопросы по языку следует успех в решении “сложнейших проблем”?
Race conditions в Верилоге — это базовое знание для работающих с Верилогом, этому учат студентов сразу же после введения в синтаксис. Это примерно так же обязательно, как для разработчика на C знать, что порядок вычисления аргументов функции не предписан стандартом и на него нельзя полагаться.
И если вы когда-нибудь хотя бы эпизодически писали на VHDL, то должны знать, что в этом прекрасном языке:
есть несколько разных типов для целых чисел/битовых шин (
signed,unsigned,std_logic_vectorи др.),они не приводятся неявно друг к другу.
Поэтому приведённая в статье портянка с resize буквально обязательна и до боли знакома любому VHDL-практику просто потому, что без неё код не скомпилируется.
Удивительно, но под любой статьёй, обличающей незнание базы, появляются такие комментарии. Мол, это всё душные мелочи, которые не нужны в настоящей работе. И обычно дальше дискуссия развивается в сторону, что для настоящей работы вообще не нужны никакие “книжные” знания и поэтому на собеседованиях нельзя спрашивать вообще ничего.
Это обычный защитный психологический механизм, из базовых.
Челвоек видит описание сложного собеседования, понимает, что он бы, возможно, тоже его не прошёл, дальше включается защита от этой неприятной мысли через инвалидацию самого собеседования. «Это не я чего-то не знаю, это собеседования у вас .удацкие, да и сами вы рожей не вышли».
Под любой статьёй про сайты знакомств комментарии точно такие же. Более того, вообще под любым материалом, описывающим процесс отбора, который потенциальный читатель имеет шансы не пройти.
Если специалист, успешено решавший задачи в промышленных масштабах, не проходит собес, то может потому что проблема не в специалисте, а в собесе?
успешено решавший задачи в промышленных масштабах
О чём мы абсолютно достоверно знаем с его собственных слов.
У человека может быть свидетельство о регистрации программы(там указан язык программирования) и это может быть известный в узких кругах продукт.
Всё ещё будете гонять его после этого на собесе по языку?
За недостаточную глубину знаний он получит отказ?
Всё ещё будете гонять его после этого на собесе по языку?
Да.
За недостаточную глубину знаний он получит отказ?
Да.
У человека может быть свидетельство о регистрации программы(там указан язык программирования) и это может быть известный в узких кругах продукт.
Ещё у него может быть диплом о высшем образовании, в котором указаны часы изучения языка программирования и итоговая оценка. «Вы ещё будете гонять его после этого на собесе по языку?».
Я чисто из опыта знаю что все дипломы можно спокойно игнорировать. У меня на интервью был студент из Стенфорда который 10 раз переписывал дизайн то ди gearbox то ли сумматора с контролем потока данных:
https://github.com/chipdesignschool/systemverilog-homework/blob/main/08_flow_control/08_05_gearbox_1_to_2_fc/08_05_gearbox_1_to_2_fc.sv
https://github.com/chipdesignschool/systemverilog-homework/blob/main/08_flow_control/08_07_a_plus_b_using_fifos_and_double_buffer/a_plus_b_using_fifos_and_double_buffer.sv
А еще была девочка из <опустим название университета> образование в котором стоит 90 тысяч долларов в год, которая на вот такой вопрос (как добавить в однотактовый процессор команду умножения используя блок умножения с латентностью два):
https://github.com/chipdesignschool/systemverilog-homework/tree/main/09_single_cycle_cpu/09_02_cpu_mul_with_latency
написала:
sr_cpu cpu ( .clk ( clk * 0.5 ),
Я тут подумал "бедные родители, потратили полмиллиона долларов на обучение чадо, а выхлоп вот такой"
Всё ещё будете гонять его после этого на собесе по языку?
После этого — да. Даже если у него там написано «C++», то, может, у него там C++11 какой-нибудь полуторадесятилетней давности, а нам тут нужно, чтобы человек комфортно себя чувствовал с идиомами C++26. Если код программы закрыт, то совершенно непонятно, что именно и как именно там написано.
На самом деле даже после гитхаба гонять — не самая плохая идея. Я как-то собеседовал одного человека, который в резюме написал, что он автор альтернативной prelude для хаскеля… хотя лан, мы тут про железо. Представьте себе, что он написал, что он автор альтернативной STL для C++, и у него даже на гитхабе есть проект, где он (и кто-то ещё) коммитил эту реализацию. Только вот на интервью спрашиваешь его про, в рамках аналогии, remove / erase idiom, а он не знает. Просишь написать простенький итератор для обхода массива в порядке «первый-последний-второй-предпоследний-...» — а он не может.
Что он там писал? Непонятно.
О чём мы абсолютно достоверно знаем с его собственных слов.
Для проверки его слов есть СБ, есть официальные документы типа трудовой и договоров ГПХ, рекомендации профессиональных сообществ которым мы можем доверять.
Незачем бродить вокруг да около и оценивать "знания". Факты завершенных проектов, схожих с нашими, обладает куда лучшей предиктивностью что кандидат и у нас справится.
Вы сейчас великолепно описываете замену 3-4 часов живого общения (считаем несколько этапов интервью) на примерно впятеро больший объём бюрократии.
При этом, что характерно для бюрократии, результат она даёт частичный и сугубо формальный. Про характер кандидата и его устремления бюрократия вам скажет ровно ничего, в трудовой книжке будет написано нейтральное «инженер-программист», СБ с удовольствием проверит, являлся ли он учредителем юридических лиц, в сообществах человека могут просто не знать (давайте, вот мы с вами сейчас в сообществе, получите тут актуальную характеристику на меня — хотя бы на уровне «чем конкретно я занимаюсь и чего в этом достиг»).
На менее официальном языке вся эта деятельность называется ЖПБ, жопоприкрывающие бумажки. Реальная эффективность никакая, но если потом что-то пойдёт не так — ваша жопа прикрыта бумажками: вот договор, вот трудовая, вот заключение СБ, проверили всё что могли, не извольте ругать.
Человек мог решать другие задачи. Например, человек мог вполне успешно 90% своего времени по факту тратить на выяснение/уточнение задач, но вот собеседующему нужен не выяснятель, а программист на данном языке.
Собсна, в комментариях под литкод-интервью-постами обычно это и выясняется: люди сами пишут «я в промышленных масштабах занимался уточнением задач и склейкой разных систем, а вы у меня тут деревья какие-то вертать просите».
У меня был случай, когда я сам отговорил кандидата устраиваться к нам.
Формально по резюме у него всё отлично, всё соответствует, этапы до меня он прошёл без замечаний — но я с ним разговариваю и вижу, что по любому вопросу он начинает с удовольствием уходить в ту область, которой у нас в работе ну процентов 20 времени проекта, а иногда и вообще нет. То есть вопрос не в том, справится ли он, а в том, что непонятно, вовлечётся ли он в оставшиеся 80 % — или начнёт умирать от скуки на рабочем месте.
Всё просто: они работают, вывозят сложнейшие проблемы.
Как это следует из неспособности ответить на простейшие вопросы по стеку?
Вот так. Знания в голове в абстракциях, а не в словах. И привести эти абстракции к словам, для аутиста-интроверта далеко не такая тривиальная задача как может показаться.
Верно и обратное. Эрудит с хорошей памятью и подвешенным языком, часами будет заливаться соловьём, но реальных знаний у него нет, только слова.
Дык именно по этой причине у меня после первого вопроса всегда идет упражнение с написанием кода (см. пример ниже с квази-конвейерным делением). Потому что действительно есть куча эрудитов с хорошей памятью которые могут рассуждать про алгоритм Томасуло и многоядерные процессоры, но ничего не могут реализовать.
Впрочем к обсуждаемому кандидату это не относится, так как он соскочил с первого вопроса на другой язык, после чего это повторял.
А эрудитов со знаниями и аутистов без таковых не бывает, поэтому эти случаи рассматривать не будем. Аутистов берем, эрудиты – на выход!
Эрудиция не равно навык, но если человек открыто врет в резюме про пять языков, то и в работе он будет сказочником
ок, вот только как это объяснить типичному каргокульту айти
Внушает, да...
Для полноты картины не хватает успешных кейсов: как кандидаты, прошедшие подобные фильтры-отборы-интервью, круто изменили компанию к лучшему именно своей работой 🥲
Круто менять необязательно. Если человек добавляет фичи в скажем десятки миллионов новых телефонов или встроенный компьютер для автомобиля (driver's assistance) - это уже круто. А вот если ничего не может сделать самостоятельно, а только копипастити потом пристает к коллегам с вопросами почему не работает, то это просто отрицательная ценность для команды.
Вот тут и приходим к тому что главное от кандидата это наличие мяса на попе уметь брать проблему и самостоятельно её решить, чего бы это ни стоило, а не знания. Знания дело наживное. В пределах разумного, конечно. А на собесах что проверяется? Совсем не то проверяется.
Но, без каких то знаний, решение проблемы может затянуться на непрогнозируемый срок, но в целом я с Вашим посылом согласен.
Пройти собес – тоже задача, почему бы и ее не решить. Мама до старости сопли подтирать не будет, надо брать ответственность за свою жизнь на себя.
Вполне нормально отсеивать кандидатов, которые слова сказать не могут, и вполне нормально, что среди них будет 0,1% немых гениев. Жизнь несправедлива.
Пройти собес – тоже задача, почему бы и ее не решить.
Конечно. Можно даже потом не работать, а дальше проходить собесы с повышением грейда и зепки.
Но мне бы хотелось нанять специалиста работать таким какой он есть, а не нарваться на специалиста проходить собесы.
В вашем случае всё предельно просто, нанимайте людей без собеседований. Такой вариант наиболее полно отвечает на указанный вами запрос.
А у других людей идут быть другие требования, например, найти хорошего специалиста.
В вашем случае всё предельно просто, нанимайте людей без собеседований.
Так и делаем. Если кандидат успешно решал схожие задачи, то оказывается никакие ритуалы его оценки и не нужны. Поэтому лучше сфокусироваться на "пробиве" кандидата. А ещё лучше брать по знакомству.
А у других людей идут быть другие требования, например, найти хорошего специалиста.
Проблема в том что хорошо проходящий собес не тождественен хорошему специалисту. Нынче даже скорее обратная корреляция сложилась.
Прикольно бы было, если бы затронут Форт (Forth) язык. :) На медни пообщался с ИИ поисковика по этому вопросу https://search.brave.com/ (в целом интересно), за исключением некоторых ньюансов по незнанию затронутых в диалоге Форт реалий, Но, на вопрос - Были ли Форт контроллеры у Atmel - говорил “Нет такой информации” , пока напрямую ему не назвал слово Marc4 (т.е. замкнул сам напрямую два или более ключевых слов в его векторной базе данных)
Да уж, если бы он вздумал соскочить на Форт, я бы его тут же зажарил живьем предложением расписать как бы он реализовывал форт-процессор на верилоге. Это шикарный интервьюшный вопрос, если у кандидата в резюме одновременно Форт и Verilog или VHDL. Очень развесистый вопрос с ответвлением про кеширование стека.
А, Форт процессоров в железе “нет”, Зачем тогда “бесполезные” вопросы? :)
Инженерный снобизм в чистом виде. Ну вот зачем вы его спрашиваете про аду, форт или jovial если в вашей компании это не используется. Вместо того что бы выдти на конструктивный диалог по конкретным задачам которые человеку предстоит решать, вы тратите время оплаченное компанией на экзамен кандидата по сферическим знаниям которые не используется в вашей компании. 😩
Если вы чего-то не знаете, не надо включать это в резюме и нарываться на вопросы.
И да в моём резюме тоже есть vhdl и verilog и когда то на нём я писал корреляторы и Фурье процессор для быстрой свертки (занимался навигацией и даже есть патенты) но это было в 2011 году и после этого я переквалифицировался сначала в DSP программиста а потом в менеджера. И что я теперь должен по вашему удалить весь этот опыт из резюме если я сейчас на RTL языках и пары строк из головы не напишу (правда чужой код прочитаю и даже скажу примерно во что синтезнется)? 😀
начало статьи: в интервьировании на позицию по моделированию и верификации процессорных ядер
если вы будете "подаваться" на дизайнера микросхем - то да, просят про RTL языки. Не потому, что они были упомянуты, а потому что вы обещаете владение ими пробуясь на такую вакансию.
На вакансии менеджера художественной галереи их, действительно, спрашивать не надо, но там спросят другое.
Вместо того что бы выдти на конструктивный диалог по конкретным задачам
Думаю, там уже после ответа на вопрос про сложение стало понятно, что кандидата решать конкретные задачи решать не возьмут. А всё остальное уже просто из любопытства, узнать как долго можно менять тему, не отвечая на вопрос.
в моём резюме тоже есть vhdl и verilog и когда то на нём я писал корреляторы и Фурье процессор для быстрой свертки
Вы смогли ответить на вопросы про race condition и сложение?
Про race conditions врядли, просто потому что так бы не написал, может скажу ересь но как помню было синхронное(<=)и асинхронное(=) присваиваивание, и просто знаю что под клоком использовать асинхронное нельзя.
Про сложение тоже бы ответил частично, я помню что есть знаковые и безнаковые типы в vhdl что нужно делать расширение шины и подключать для работы библиотеки, но вот написать код не смог бы, просто потому что последний раз его писал в 2010 ещё в Active-hdl которая на тот момент уже умирала. Больше с написанием кода я дел не имел.
Это как в универе я посчитал кучу перемножений и определителей матрицы но вот сейчас без matlab мой мозг очень сильно заскрипит что бы это сделать, да посидев и погуглив я быстро вспомню и освежу навык но вот на собесе могу и не сделать. Тоже самое и с RTL, я могу спокойно рассказать зачем используются коды грея в FIFO работающего с разными клоковомыми доменами, но вот из головы даже этот счётчик грея не напишу. 😀
Получается, что вы, не работая с HDL-кодом 15 лет, уже ответили лучше, чем тот кандидат.
просто знаю что под клоком использовать асинхронное нельзя
Оно обычно называется блокирующим присваиванием, но да — чтобы лишний раз не задумываться о гонках, в синтезируемом коде просто следуют эмпирическим правилам:
комбинационную логику пишут блокирующими присваиваниями,
синхронную логику (“под клоком”) — неблокирующими,
переменные не модифицируют более чем в одном процессе.
Если весь код написан с соблюдением этих соглашений, гонкам просто неоткуда взяться.
Нет никакого снобизма. Кандидат вынудил меня идти по этому пути, когда соскочил с вопросов про 1) SystemVerilog -> на Verilog-95 2) потом на VHDL 3) потом на Аду.
Мой типичный план интервью:
1) описание последнего проекта для разогрева;
2) простой вопрос;
3) задачки по существу - в его случае например спросить как бы он организовал testbench или bus functional model с транзакциями, то есть конкретная задача, которую ему предстоит решать.
Но он увильнул от (2) причем три раза. После этого мне просто стало интересно что будет если продолжить идти по этому пути дальше.
*** И что я теперь должен по вашему удалить весь этот опыт из резюме если я сейчас на RTL языках и пары строк из головы не напишу ***
Лучше всего это удалить. Или как минимум делать два абзаца: текущие технологии (за которые вы можете ответить) и то что вы использовали в прошлом (про что сразу говорить что вы ничего не помните). Я в конце 1990-х ставил себе в резюме Tcl, который потом не удалил и меня про это спросили через 10 лет. Это очень глупая ситуация. Идеально иметь в резюме только текущие навыки, за которые вы можете ответить.
Сейчас ИИ всем студентам автоматически добавляет в резюме SVA (SystemVerilog Assertions), и я когда вижу это SVA, тут же первым делом прошу их написать простейшее SVA. 95%+ не пишут. Сразу начинают мычать, что он де отлаживал результат SVA, а SVA писали другие инженеры. Задаю вопрос "но вы указали что отладили в проекте 120 багов. Сколько из них было найдено с помощью SVA? Ах 20-30. То есть вы видели кучу SVA и не запомнили их синтаксис?"
Самая большая хохма что еще перед AI первая выдача гугла на мой вопрос про SVA был неправильный ответ - таким образом я во время онлайн интервью определял кто сейчас смотрит на второй экран с выдачей гугла или суфлером.
Лучше всего это удалить. Или как минимум делать два абзаца: текущие технологии (за которые вы можете ответить) и то что вы использовали в прошлом (про что сразу говорить что вы ничего не помните).
Ну не знаю, я уже где то 7 лет менеджер и мне кажется именно мой опыт и то что я работал с FPGA/ASIC, DSP, MCU baremetal, RTOS, Embedded Linux и делает его уникальным. Вы же мне предлагаете отказаться от позиционирования себя как T-shaped менеджера и стать в один ряд с управенцами без технических знаний практически анулировав предыдущий опыт и оставив в резюме только первый технический диплом 😀, хотя я помимо менеджмента разбираюсь в проектировании любого embedded устройства от схемотехники до прошивки, да сейчас уже не так глубоко как раньше и уровень реализации уже где то выпадает но концептуально всё ещё помню многие вещи.
Инженерный снобизм в чистом виде. Ну вот зачем вы его спрашиваете про аду, форт или jovial если в вашей компании это не используется
Затем, что кандидат врёт про наличие опыта работы с ними.
Ну то есть буквально — сознательно врёт с корыстной целью.
Я, конечно, допускаю, что в мире АА (абстрактных аутистов) человека нанимают примерно как новую плашку памяти в ноутбук выбирают, по соответствию параметров из таблички характеристик, но в реальном коллективе нанять человека, который активно использует навык лжи с корыстными целями — очень плохая идея.
Почему врёт, если человек может прочитать код на этом языке и написать пару строк он им владеет. То что он не знает тонкостей какого-то языка это совершенно другое. Как в английском есть классификация от А1 до С2 и если я владею им на уровне А2-B1 то я считаю что я его знаю и в резюме запишу что знаю без указания уровня(для моих задач прочитать текст или написать комент или спросить где тут ресторан этого хватает с лихвой), вы собеседуете и знаете какой уровень вам необходим для работы вот и выясняйте это ваша работа, может вас устроит тот что у меня, но если я напишу конкретный уровень то во многих компаниях на собес попасть без шансов просто из за дурацкий автофильтров и глупых hr которые поставят как знание языка b2-c1. То же самое с языками я знаю СИ и в резюме пишу просто СИ но вот какой нужен вам и знаю ли я его это уже выяснять вам если не указали в вакансии (может вам нужна мисра из соображений безопасности, а может быть и нет). Здесь же человека указавшего аду пытают по адовой многопоточке а он может просто писал на ней какие то простые вещи тут как с bash и git все пишут что знают но у большинства знания как с английским на уровне А1 но для работы этого хватает. 😀
Что за чушь вы несёте?
Человек уже сидит на интервью. Он уже прошёл фильтры. Он общается с профессиональным интервьюером по своей основной специальности, которому прямо и однозначно говорит, что у него есть опыт в N, не имея такого опыта.
То есть — врёт.
Но вы можете продолжать оправдывать его (на самом деле — себя).
Но вы можете продолжать оправдывать его (на самом деле — себя).
Да без вопросов я спокойно могу сказать про себя что я дурак хоть и имею 2 диплома и за 18+ лет имея за плечами патенты и серьёзные продукты на рынке знаю только лишь то что практически ничего не знаю так как понимаю сколько различных предметных областей в embedded. А вот что я могу сказать конкретно по собесу
Спросили vhdl и verilog по первым вопросам не смогли выдти на конструктив избавляемся от кандидата по не соответствию hard/soft scils. Дальше время тратить нет это дорого для компании. Если через вас слишком большой поток неликвида нужно задуматься где проблема (плохой фильтр у hr или у вас завышенные требования к кандидатам).
Копания в аде и глубже если не нужно компании это именно снобизм и тут я приводил пример с питоном, я понимаю свои ограничения и на бэкенд не пойду но если бэк програмист прийдет ко мне я его буду спрашивать по необходимой мне предметной области и мы быстро расстанемся если он её не знает. При этом как я и писал в резюме мы оба знаем питон просто каждый в меру своей необходимости.
Теперь про знания языков зная python без многопоточки мне гораздо легче будет её освоить и написать чем тому кто вообще питон не знает(ии сейчас мне в помощь) Для меня как менеджера при найме такого человека это плюс ему в карму если его простой навык использования языка встраивается в мою предметную область (тут уже был пример с bash, git, тем же английским). И я не буду пытать его по каким то тонкостям.
Почему врёт, если человек может прочитать код на этом языке и написать пару строк он им владеет.
Как бы вы назвали более глубокие уровни знания языка, когда человек может не только написать пару строк, но и знаком с крайними случаями, тонкостями и неочевидными подводными камнями?
Здесь же человека указавшего аду пытают по адовой многопоточке а он может просто писал на ней какие то простые вещи тут как с bash и git все пишут что знают но у большинства знания как с английским на уровне А1 но для работы этого хватает.
Разница между этим и bash и git в том, что bash и git — это вспомогательные инструменты, а язык, по которому собеседуют — вроде основной.
Как бы вы назвали более глубокие уровни знания языка, когда человек может не только написать пару строк, но и знаком с крайними случаями, тонкостями и неочевидными подводными камнями?
Мне нравится аналогия принятая у лингвистов если взять английский - c1 advanced, c2 proficiency. При этом владении английским языком признается на уровне b1 intermediate и только почему то программисты засчитывают владение языком программирования когда вы знаете всё нюансы то есть если сравнивать с английским то это минимум advanced.
При этом во многих прикладных областях знать язык на уровне advanced не требуется достаточно intermediate, к тому же бывает так что архитектура проца просто не ложится на язык и часть нюансов не работает (моя любимая архитектура DSP от ti c54-c55 есть компилятор на си и даже си++ правда сильно урезанный но вот прикол байта в архитектуре нет, минимально адресуется 16 бит ещё и bigendian а вам надо rndis драйвер для USB написать ещё и eth стек на нём запустить 😀).
а язык, по которому собеседуют — вроде основной
А мне казалось что начиная с Ады там уже были вспомогательные или не используемые в компании языки просто интервьювер их знал очень хорошо а тот кого собеседовали нет потому и привёл аналогию с баш.
и только почему то программисты засчитывают владение языком программирования когда вы знаете всё нюансы то есть если сравнивать с английским то это минимум advanced.
Наверное, потому, что английский язык и язык программирования используются для несколько разных задач, и другая сторона в случае английского языка [человек] обладает несколько большим интеллектом и способностью к коррекции ошибок, чем другая сторона в случае ЯП [компилятор]?
к тому же бывает так что архитектура проца просто не ложится на язык и часть нюансов не работает
есть компилятор на си и даже си++ но вот прикол байта в архитектуре нет, минимально адресуется 16 бит
А если бы вы знали нюансы языка, то вы знали бы, что плюсовый байт не обязан быть восьмибитным, он может быть и больше :]
А если бы нюансы языка знали и другие люди, то запускать плюсовый код на системах, где CHAT_BIT не равно 8, было бы проще, и работал бы он там лучше.
Иронично получается, не правда ли?
А если бы вы знали нюансы языка, то вы знали бы, что плюсовый байт не обязан быть восьмибитным, он может быть и больше
Ну знаю я это как это мне поможет работать с байтов ым потоком,собирать его и извлекать из него инфу на процессоре который это не позволяет.
другая сторона в случае английского языка [человек] обладает несколько большим интеллектом и способностью к коррекции ошибок, чем другая сторона в случае ЯП [компилятор]
Вопрос решается на уровне корп стандарта компании типа undefined behavior не писать или общего стандарта безопасности типа мисры. Выше уже приводили пример race conditions в верилог что следуя паре простых правил вы на них никогда не нарветесь и знать о них для вас становится не обязательно чем на аналогия с intermediate и advanced.
Весело наблюдать обычно как один синьер другого собеседует, тут кто первый халат надел тот царь и бог, а второй если не наступал на те же грабли тот дурак .
А ещё веселее когда в маленьком городе миллионнике они потом встречаются и меняются местами и товарищ заваливший собеседование прошлый раз отрывается в ответ по полной. 😂
Это я к тому что один мог писать системные скрипты другой многопоточку используя один и тот же язык и в резюме указать что язык знают но при этом запросто завалить друг друга на собесе.
Embedded очень большой и областей огромное множество, и практики как и набор используемых инструментов везде разный. Надо просто смотреть понимает человек физику процессов которыми управляет через код или нет(так называемую предметную область в которой ему предстоит работать), остальное лишнее так как оно слишком часто меняется.
У меня так с python для цифровой обработки сигналов, и в резюме у меня указано что я знаю python, но при этом у меня нет знания ооп, многопоточки или Django, и любой backend программист меня просто разнесёт на собесе. Вот только если он попадётся мне то на той же фильтрации я его порву как тузик грелку. 😂
Вот только если он попадётся мне то на той же фильтрации я его порву как тузик грелку
Это если встретятся два одиночества, ни одно из которых не умеет произносить фразу «да, я с этим работал, но вот в такой конкретной предметной области, в ней спрашивайте, всё расскажу».
Вопрос, стоит ли нанимать таких людей на работу — дискуссионный.
Ну, допустим, наймут вас. А на поставленную руководителем задачу, в которой надо многопоточку фигачить, вы тоже постесняетесь сказать, что не умеете, предпочтя задачу молча завалить?
Нет я прекрасно ориентируюсь в своей области знаний а ещё я экстраверт так что сразу легко донесу до руководства свои слабые стороны подсветив что мне решение подобной задачи будет стоить больше. Это базовый навык в модели общения доверие-прозрачночть с руководством и понимание этого позволяет легко двигаться по карьерной лестнице. 😀
как бы он реализовывал форт-процессор на верилоге
И он бы тут же соскочил на лисп-машины.
Ну если он к этом моменту ещё не понял, что Юра в жизни прочитал очень много странных книжек, то это тоже не в пользу кандидата говорит ;)
Да, с лиспом его можно было бы заставить написать на верилоге linked list controller который бы вытягивал лисповские списки из памяти (car и cdr). Вопрос про списки на верилоге у меня тоже есть:
https://github.com/yuri-panchul/2019_2021_eda_playground/blob/main/linked_list_1/design.sv
Плюс похожие вопросы спрашивают на интервью в Apple и Juniper (сейчас HP).
Я занимался реализацией Forth процессора на VHDL. В моей реализации сейчас 3 стека (процессор заточен под DSP). А что не так с кешированием стека? В смысле зачем оно?
Да, тоже интересно. Если взять, какую то реализацию Форт процессора например с Github, то будет ли оно там для решения задач стоящих перед автором проекта, или как автор обсуждаемой статьи нацелен на получение Hi-End результата в своих результатах в сравнении с …
P.S. А, можете по следу своей разработки опубликовать статью?
Да, я думал про статью, но как-то все руки не доходят. Я как обычный программист - мне проще писать код чем его документировать (;
А, зря, пока, к примеру, Форт сообщество окукливается в своих индивидуальных подходах к “снаряду” Мир не стоит на месте и занимает и его исторические ниши сводя на минимум его понимание и применение в перспективных разработках.
P.S. В проекте двух стекового учебного “Форт” процессора Брус-16 (статья на Хабре https://habr.com/ru/companies/yadro/articles/1023972/ ), “любители” сразу дополнили его Форт-системой в этом топике http://fforum.winglion.ru/viewtopic.php?f=3&t=3402&p=52064&
Для снижения латентности, если стек хранится в памяти. Она из проблем стековых процессоров (например транспьютеров) по сравнению с risc-процессорами с большим регистровым файлом - заключалась в том, что для вычисления простого выражения, скажем a*b+c*d (в обратной польской записи ab*cd*+) требовалось делать много транзакций к памяти, что медленнее чем к регистровому файлу. Также это труднее было параллелить.
А что, форт сейчас где-то используется?
Интересный и не простой вопрос к ответу при анализе реалий его.
В каких изделиях, программах или закрытых применён информации мало, возможно что решения на/с нём конкурируют на “сложных” задачах под NDA. На Западе есть исторические предпосылки по использованию Форт (Forth), в России их исчезающе мало и в силу того, что студентшкольники с ним не сталкиваются, а встретив “страшилки” про него проходят мимо.
Р.S. Но, проще не пытаться вникнуть в суть разных сильных сторон языка и парадигм на которых он и его “разновидности” спроектированы, а приклеить к нему ярлык “Неуловимого. Джо” :) Моё, к примеру, резюме с акцентом на работу с Форт направлением на hh.ru вероятно так и останется в оценках “курьёзным” случаем от какого олдфага (ретрограда) не проходящее фильтры HR по возрасту и ключевым словам. А, спрашивать об опыте даже не относящегося к вакансии, как минимум имеет смысл для оценки кандидата и возможности применения его для наиболее полезного усиления созданного проекта-продукта.
Ну например loader во FreeBSD использует Forth
Или ранее использовался, а сейчас. Lua?
P.S. Пробовал находить ссылки встречаемости Форт в каких то компаниях, ПО и проектах, для cозданного топика на http://fforum.winglion.ru но их нeмного находилось, хотя по слову Forth на github много чего выдаётся в результат поиска.
Насчет использования loader_4th уже не знаю - давно в FreeBSD не работал, возможно и правда что-то изменилось. Я возлагал опеределеные надежды на использование "аппаратного" Forth процессора в FPGA для "ленивой" разработки в плане DSP. Пока не очень обнадеживает. Регистровый RISC-V вроде как проще и все таки производительней показался.
Для “ленивой” разработки DSP есть GA144, но это уж для очень “ленивых”, но без появления на рынке массовых Форт-контроллеров ничего не изменится и Форт так и будут “насиловать” в нерадной для него регистровой архитектуре разных контроллеров.
P.S. И На RISC-V уже много какие Форт-системы добавили/запустили/портировали
Наблюдал другое - спрашивают соискателя про опыт, какие последние проекты: ну там микроконтроллеры какие, IDE, как прошивали/отладка велась, как совместная работа организована - "мне нельзя говорить, NDA" 🤷♂️
И вот тоже не понятно, зачем тогда на собеседование пришёл.
Вполне нормальный ответ, вы спрашиваете про то как были построены процессы разработки в компании если компания с именем то это попадает под NDA. Переформулируйте просто вопрос и всё
Ты работал с конкретной ide или процом
Вот устройство как бы ты организовал процессы фабричной прошивки и обновления в процессе эксплуатации
Как бы ты отлаживал и собирал инфу на подобном устройстве
Если бы я назначил тебя лидом как бы ты организовал работу в команде
В этом случае человек поделится своим реальным опытом ну или может слегка пофантазировать если его нет, но при этом нет нарушения NDA, потому что он не расказывает конкретно про процессы в предыдущей компании.
Такая проблема есть, но можно задавать вопросы, которые не зависят от конкретного микроконтроллера. Например спрашивать про обработку прерывания в RTOS в такой форме, чтобы это было общее что для STM32, что для ESP32, что для PIC32.
"мне нельзя говорить, NDA"
Обычно человек, имеющий хоть какой-то жизненный опыт (но то есть возраст 30+ уже точно в эту категорию должен попадать), умеет в таких случаях составлять конструкции вида «я не могу ответить про конкретный проект и внутрянку компании, но лично я много работал с ...».
Потому что он понимает, что собеседование — компромиссный процесс, в котором ему тоже выгодно удовлетворить интервьюера. И как любой подобный процесс, он имеет компромиссную природу результата.
Ну либо он пришёл к вам от скуки, послушать чо спрашивать будете и чо предложите по бонусам, поэтому ему пять слов лишних сказать лень, но в таком случае будет логичным завершить интервью с ним после третьего «мне нельзя говорить», поставить в отзыве «не нанимать» и заняться более полезными делами.
> через несколько лет трудоустроенным в другой компании
Ну это не обязательно связано. В конце концов вы не знаете, на какую именно позицию он там устроился, могла быть совсем не про топологии.
А сама "стратегия собеседования" звучит как-то странно. Кажется, что он не хотел оффера, а просто развлекался. Потому что эта стратегия просто обнуляет его шансы.
Байка-то великолепная, но остаётся байкой. Это даже не анекдот про "если бы у рыбы была шерсть, в ней бы водились блохи" - там студент ответил на все вопросы (хотя и криво). А этот ваш соискатель - ни на один.
То есть да, счётчик запоротых вопросов нулевой. Но и счётчик отвеченных - тоже нулевой. В результате техническую часть он просто не проходит. Если конечно у него нет волосатой лапы. Но если есть - все эти хитрости ему просто не нужны.
Та кто его знает, некоторые теряются при живом общении, но в состоянии потока работают и решают сложные задачи, решают успешно.
У нас как-то один эксперт был на собеседовании, так он сразу отрезал - нет, на такие вопросы я отвечать не буду - унижение мне не нужно, у меня есть чувство собственного достоинства. Все офонарели.
Т.е. если чел. эксперт, может быть он что-то и напутает от стресса в простейших вещах. Как-то возьми выпускника по математической специальности - возможно он не вспомнит все аксиомы планиметрии, которые дети в школе изучают. Из этого можно сделать вывод что ему нужно в школу.
возьми выпускника по математической специальности - возможно он не вспомнит все аксиомы планиметрии, которые дети в школе изучают
Нет, это так не работает, тем более в математике. У математики нет внешних объектов исследования, аксиома есть основной объект исследования математики. Я ещё могу допустить, чтобы, скажем, химик забыл какие-то элементы школьной химии (тем более что изрядная часть школьной химии - это устаревшая или ложная информация). Но математик, забывший аксиомы - это не математик.
Но математик, забывший аксиомы - это не математик.
Забывший аксиомы своей области.
Как думаете, сколько прикладных математиков (которых вы скорее всего обнаружите на собеседовании) помнят аксиоматику ZFC или аксиоматику классического исчисления высказываний? (кстати, какую из?)
Сколько чистых математиков, ковыряющих аксиоматику ZFC или классического исчисления высказываний, вспомнят аксиомы планиметрии? (лично я хз вообще, что это такое — аксиомы Евклида? что-то ещё? я из аксиом Евклида помню только пятую, к слову, и то по очевидным причинам) Сколько из них вспомнит аксиомы, ну, не знаю, сигма-алгебры?
Сколько работающих специалистов по машинному обучению, пишущих продакшен-код с этими всеми вот эмель-модельками, вспомнят аксиомы сигма-алгебры? Там она замкнута относительно конечного или счётно бесконечного пересечения? А не путаете с аксиомами топологических пространств? Точно?
А это всё от зубов отлетает, чтобы дискаунт на стресс в условиях интервью?
Забывший аксиомы своей области.
Но вот те же аксиомы планиметрии из школы - по идее то все должны помнить? И можно ими унижать человека, как бы если не вспомнил на уровне таблицы умножения - можно сказать, да вам, батенька, нужно школу закончить для начала.
Унижать так-то можно любым достаточно известным, но мало полезным знанием, было бы желание (и хоть какой-то смысл).
Но аналогия с таблицей умножения неверная, пусть у человека "от зубов и не отскакивает", сколько будет шестью восемь, но он сможет дать правильный ответ спустя какое-то время, а значит считать все же умеет.
Аксиомы планиметрии... а почему тогда не список персонажей "Войны и Мира"? Примерные размеры планет солнечной системы? Правила игры в шахматы?
Мне, несмотря на оконченный математический ВУЗ, аксиомы планиметрии пригодились ровно чтобы сдать экзамен в школе по аксиомам планиметрии, не больше не меньше. Это не матан, который сплошь и рядом всплывает, и не теория вероятности, без которой вообще сложно себя считать человеком рассудительным.
И, казалось бы это несложное знание, но я изначально не склоняюсь считать простым то, что кажется лишь интуитивно просто; вот про аксиому принадлежности я не только не вспомнил без википедии, но и не вспомнил бы ее вообще, если бы мне нужно было самому создать аксиоматику. Меняет ли это хоть что-то в мире? Да вообще ничего. Это даже в геймдеве не нужно, и когда дачу строишь тоже как-то безразлично на то, что каждый отрезок имеет длину, большую нуля, потому что нулевыми отрезками как-то даже в голову не приходит крышу крепить.
Вот те же аксиомы Пеано еще попробуй забудь, если узнал. Но их почему-то даже обычно не проходят в школе. Но раз уж без этого жить можно, то что уж говорить.
Вот те же аксиомы Пеано еще попробуй забудь, если узнал.
В какой из логик? :]
Ну мне кажется, шансов начать не с определений в логике второго порядка маловато. Даже интересно, где бы могли так преподавать.
Ну, у нас на прикладной математике вообще Пеано не вспоминали.
Но логика второго порядка чуть сложнее для анализа, поэтому работу только в FOL я вполне могу понять, наверное.
В FOL уже буквально с диагональным методом Кантора возникнут такие проблемы, которые младшекурсникам не по зубам, а ведь надо как-то пределы вводить. Непрерывность определить. Ну да, выше Вы писали про ZFC, но пока уже другие будут спокойно интегралы по контуру считать, придется сидеть на парадоксе Банаха-Тарского. Мне не кажется, что это может быть проще.
В FOL уже буквально с диагональным методом Кантора возникнут такие проблемы, которые младшекурсникам не по зубам, а ведь надо как-то пределы вводить.
А чего там вводить? Эпсилон-дельта и вперёд. На среднем курсе матанализа на проблемах оснований не фокусируются. На среднем курсе матанализа это вообще, наверное, вторая неделя первого курса, если пределы последовательностей, и четвёртая — если функций. Вчерашний школьник ещё даже ни в одну игру Эренфохта не сыграл, ему и так норм.
И тот же диагональный метод вполне описывается прозой и на интуитивном уровне понимания ∀ и ∃.
Да ведь вкусовщина. На первом не сыграет, да, а на втором-третьем, если с головой на плечах - сыграет и проиграет наверняка. Было бы интересно, правда, посмотреть, где с FOL начинают. Все-таки относительно SOL + топологии это редукция, что несомненно полезно для формализации, но дает свои минусы для познания. А вот реально качественные формализации всем (без малого) студентам по жизни никак не пригодятся.
И тот же диагональный метод вполне описывается прозой и на интуитивном уровне понимания ∀ и ∃.
Тут на хабре, в среднем пару раз в год пишут "статьи" вот такие вот интуитивно понимающие, о том, что вообще континуума не существует и они могут это доказать.
Ну и продолжая вкусовщину, я благодарен за то как меня учили и с чего начинали, потому что матан я, кажется, даже в припадке не забуду. Во многом базовый, конечно, но, главное, для меня все предельно просто, и все что забыл легко выводится.
Но математик, забывший аксиомы - это не математик.
Но на практике так происходит - спрашивал людей, имеющих мат. направленность, которые не так давно закончили (может несколько лет) - далеко не все смогли вспомнить аксиомы планиметрии. По идее сразу нужно отправлять в школу, т.к. если ты не знаешь аксиомы - то ты не имеешь базы. Но мозг человека работает иначе, не как компьютер. Когда ему нужно будет - вспомнит.
В ютюбе тоже попадались прикольные ролики на эту тему, когда спрашивают именно бывших выпускников рейтинговых вузов (особенно спустя 2-3 года после обучения).
Я как-то помогал с технической частью собеседования на один проект, где нужен был миддл со знанием Qt. Ну и вот, кидают мне резюме кандидата, который выглядит как очень твердый миддл с богатым и разнообразным опытом…
Я на собесах начинаю с достаточно лёгких но нестандартных вопросов, просто чтобы кандидат расслабился и не стрессовал. Спросил: в чём отличие указателя от ссылки в си++. И кандидат завис. Начал оправдываться что в кутэ всё на указателях, своя модель управления памятью и тп. В целом говорил правильно, неплохо объяснил тот же mvc в контексте кутэ, но прямо чувствовалось отсутствие фундаментальных знаний по си++. И я не знал что делать. С одной стороны выглядело так, что человек повидал всякое энтерпрайз г**но, владеет фреймворком и с задачами мидла должен справляться, но с другой я ну никак не мог порекомендовать его именно как си++ программиста.
Или был другой случай, тоже искали си++ мидла на бэкэнд, но с виду неплохой кандидат очень плавал в многопоточности и raii. Он почувствовал это, попытался сказать, мол я программировал в основном с кутэ. И тут, я как в статье, почувствовал почву для отрыва :)
*** Спросил: в чём отличие указателя от ссылки в си++. И кандидат завис. ***
Ну в этом случае если бы он сказал что все делал без ссылок но с указателями, я бы написал что-нибудь в таком роде:
A & f (A b, A & c)
{
static A s;
if (b.a != c.a)
s = c;
c = b;
return s;
}и попросил бы его переписать это с помощью указателей, чтобы не было references. Причем проследил бы что A b передается по значению и в переписанной версии.
Если перепишет корректно - я бы списал зависание на стресс во время интервью.
Да ни в чем, и то и другое работает с адресом, чисто синтаксический сахар, еще и не понятно что лучше, особенно если делать хорошо оптимизированные templates, a использование references может подложить жабу если человек вписал имя переменной а функция эту переменную поменяла. Если prototype описан с указателем, то приходится явно указывать &var при вызове - и облегчает понимание того что туда уехал адрес а не копия значения, иначе частенько приходится лезть в прототипы или доки.
Это понятно, что это syntactic sugar, просто товарищ выше по ветке захотел от кандидата этого знания и я предложил способ как это проверить с помощью кода.
Ссылка даёт гарантию, что объект существует. И без сишных хаков это выполняется. И позволяет делать разные оптимизации. Не говоря уже о возможности делать нормальный синтаксис. Это как бы основы си++ 03. Их надо знать, если вы не собираетесь писать на си с классами вместо си++.
А с си++11 появился целый зоопарк новых типов ссылок которые значительно облегчают эффективное программирование. И если человек не считает уместным использовать возможности языка и хочет писать по старинке на сишечке, то это отказ. Как минимум чтобы не портить кодовую базу и не создавать конфликты на код ревью.
А в современном си++ указатели вообще не нужны в пользовательском коде.
При работе с железом без указателей сложно обойтись
Ссылка даёт гарантию, что объект существует.
Нет, не даёт.
Ссылка даёт гарантию, что объект существовал когда-то, и какой-то промежуток времени она на него указывала, не более.
А в современном си++ указатели вообще не нужны в пользовательском коде.
Угу, если современным считать только C++26 (std::optional<T&> появилось только там) и заодно выкинуть весь легаси-стек, начиная от каких-нибудь дров для сетевых карт, например, дающих указатели в кишки памяти сетевухи, и заканчивая какими-нибудь там Qt. Но зачем тогда брать плюсы, если не для взаимодействия с легаси-системами? Непонятно.
Ну я бы тоже подзавис. Кто-то ждет ответа, ну это просто "syntactic sugar", а кто-то будет ждать, что "указатель это отдельная переменная, сама имеющая адрес в памяти". Такой вопрос гарантированно попадает в "вопросы с ожидаемым подвохом". Отличий, как по мне, больше чем сходства. Больше в сторону, чем std::string отличается от int.
Впрочем, да, это не повод молчать и чего-то ждать.
Пишу на Go 7 лет, до этого немного php видел, в других языках правда может быть такое, что разработчик не знает на какой версии языка написан его проект? Мне правда любопытно.
По идее на версии компилятора же завязаны многие вещи и вот совсем не ответить на собеседование на твой вопрос это норма?
На счёт «не знать базу, но решать сложнейшие проблемы» - сталкивался с такими людьми, но там обычно нерешаемость проблема. для других обусловлена тем, что изначально модуль годами писался годами одним человеком без документации и со своим видением прекрасного, а так же применением всевозможных паттернов ради их применения.
Я бы наверное мог понять почему условный джун который вошел через нейронки не напишет с руки базовую вещь типа отправки хттп запроса, но сеньор который не «помнит» как писать базовы код который в любом случае пишешь - это очень подозрительно и, возможно, опасно для компании.
В лучшем случае можно рассмотреть его менеджером для обширной экспертизы, но. вопрос опять же уже в софт скиллах будет
Делаю сложные системы на ФПГА уже 30 лет (500mhz sampling 86 GB DDR addressing, MAC/IP/UDP, DDCS, FSK/QPSK modulation/demodulation, senseless FOC), но ваше интервью точно не пройду, вопросы об ошибках, которые в нормальном подходе не встречаются, классика советской школы где учили на академию а не на решение практических задач
Вы про race condition? Ну если вы пишете на VHDL, то у вас этой ошибки не возникнет.
И если вы пишете на верилоге, и при этом строго используете блокирующие присваивания в always_comb/always @* и неблокирующие в always_ff @ (posedge clk) то тоже.
Я его об этом спрашивал только потому что у него такое может встретится в тестбенчах, типа
@ (posedge clk)
dut_in = 5'd12;
@ (posedge clk)
В принципе это простой вопрос, и если бы он сказал "не знаю", я был ему задал что-то другое.
А вот вас я бы спросил микроархитектурный вопрос. Например. Допустим у вас есть черный ящик - блок с вычислением операции деления чисел с плавающей точкой за переменное количество тактов до N:
Вот с такой диаграммой:
Используйте его чтобы сделать блок умножения, который может принимать данные каждый такт бесконечно (то есть не ждать окончания деления) и давать поток результатов с фиксированной латентность, вот с такой диаграммой (латентность может быть больше чем на диаграмме):
От вас требуется:
Идея как это сделать.
Код на верилоге на доске.
Если справитесь быстро (то есть менее чем за 30 минут), дополнительный вопрос: добавьте к дизайну сигнал ready и на входе и на выходе:
Если и на это ответите быстро, дополнительное условие: данные на A и B могут приходить в разных тактах:
Диаграмма valid/ready следует правилам AXI-Stream:
При этом:
Менять исходный блок нельзя, можно только строить логику вокруг него.
Делать свои арифметические блоки нельзя.
Заводить FIFO на миллиард элементов чтобы поглотить все данные в тесте нельзя.
Ограничивать пропускную способность при отсутствие backpressure нельзя (нужно принимать A и B каждый такт).
В ИИ смотреть нельзя и гуглить тоже - все у доски.
Можете попробовать.
Это не академический вопрос - это все от сохи.
Может это и отличная задача, но без контекста - абсолютно непонятно что делать.
А какой вам нужен контекст? Интерфейс приведен. Требуемая фнкциональность приведена. Описание блоков которые можно использовать приведены. Я этот вопрос протестировал на больше десятка человек - для свежих студентов трудный, но для людей с 2-3 летним опытом приектирования блоков на Verilog или VHDL - в самый раз. Для людей с 5-10 летним опытом легкий, если опыт реален.
Код на доске это какой-то каменный век, уже у многих атрофировались нейронные связи что бы просто код писать ведь давным-давно все пишут с автокомплитом а щас ещё и с нейронкой. Ну тут хозяин барин, особенно если у вас нет kpi на количество часов которое Вы потратили на поиск подходящего кандидата. 😀
Согласен. А 30 минут (и это еще быстро?) кода на доске это вообще какая-то пытка, так или иначе. Доска для архитектуры (совсем простенькой) и, ну максимум, FizzBuzz, если любите немного поиздеваться (но зачем?).
У нас в Самсунге вернули интервью у доски, то же сделали в Гугле и в Cisco. Иначе народ повально использует ИИ-суфлеры и это раздражает.
Отличная задача, SpinalHDL Flow и Stream классы эту проблему давно решили и тратить нейроны в проектах не требуется :) Именно решив 5-10 раз такие штуки и исправив ошибки в чужом коде, на 90% переехал на Spinal
Проблема в том, что в большинстве электронных компаний ответ на SpinalHDL не примут или примут с большим скрипом, только если вы продемонстрируете что-то еще что команду интервьюеров впечатлит. Потому что встанет вопрос "как такого человека вписать в команду, если он будет вместо работы над миллионом строк верилога всех агитировать все переписать на SpinalHDL".
Решения задачи в вашем контексте не существует. Потому я не в Самсунге :)) Но есть же Efinix и SiFive и VexRiscV… И куча задач где мы заменяем команду из 30 человек
В смысле микроархитектурное решение не сушествует? Существует.
Или вы настаиваете что должен быть SpinalHDL?
Ну если SpinalHDL принимают в Efinix и VexRiscV - good for you.
Но насчет SiFive - у них же свой Chisel есть. Вы хотите сказать что SpinalHDL и Chisel однозначно отображаются друг на друга и команда в SiFive готова принять решения на SpinalHDL? У меня есть там несколько знакомых, могу спросить.
Я не упертый на Spinal, он кстаки очень хорошо сожительствует с уже существующим verilog. Один проект 25 летней давности недавно завернул в Spinal только из за возможности более удобной симуляции, были заодно выловлены вредные баги и добавлена уже Spinal периферия.
Efinix вообще имеет hard ядра VexRisc-like, создатель Spinal Charles P у них даже работал (не знаю как сейчас). SiFive ядра мы использовали в одном из ASIC проектов, к нему периферию писали на Spinal. Chisel уж слишком академичен для многих, но идея Spinal была поддержана, возможно даже скоро будет Rev2 АСИКА
Так “блок умножения” или деления ??? Как можно вытащить из одного? блока результат быстрее чем его latency или вы подразумеваете что поставим up to N блоков и планировщик ?
Ну или пару фифошек на входе и выходе для исключения мета стабильности и pll разгоняющую в N раз клок для делителя.
Про запрещение перехода в другой клоковый домен в задаче ведь ничего не сказано. 😀
Ой, ошибся. Деления конечно. N блоков и планировщик - то есть на пункт 1 вы ответили. После этого ответа я прошу изобразить код на верилоге на доске. Качественный кандидат минут за 15 пишет. После чего вопрос - как к этому добавить backpressure
Если выходная латентность больше или равна N то задача решается FIFO и сдвиговым регистром на N позиций и процессом который начинает тащщить результаты из FIFO при появлении 1 на выходе из регистра, заталкиваем 1 в сдвиговый каждый раз как arg_valid для делителя/“умножителя”.
Тут уже воспользовался корреляционным помошником:
import spinal.core._
import spinal.lib._
/** Выравнивание выхода конвейерного оператора (делителя/умножителя) с
* латентностью L >= N.
*
* arg_valid ──► shift_reg[N] ──┐
* │ token через N тактов
* op_result ──► FIFO ──────────┴──► result_out
*/
class OperatorLatencyAligner[T <: Data](
payloadType : HardType[T],
n : Int,
fifoDepth : Int
) extends Component {
require(n >= 1)
require(fifoDepth >= 1)
val io = new Bundle {
val argValid = in Bool() // импульс arg_valid оператора
val operatorOut = slave Stream(payloadType) // поток результатов с оператора → в FIFO
val resultOut = master Stream(payloadType) // выровненный по латентности выход
}
// ── N-tap сдвиговый регистр ────────────────────────────────────────
val shiftReg = Reg(Bits(n bits)) init(0)
shiftReg := shiftReg(n - 2 downto 0) ## io.argValid
val tokenAvail = shiftReg.msb // arg_valid, задержанный на N тактов
// ── FIFO результатов ───────────────────────────────────────────────
val fifo = StreamFifo(payloadType, fifoDepth)
fifo.io.push << io.operatorOut
// ── счётчик «висящих» токенов ──────────────────────────────────────
// Если L > N или потребитель backpressure'ит, токены не теряются.
val pending = Reg(UInt(log2Up(fifoDepth + n + 1) bits)) init(0)
val pushTok = tokenAvail
val popTok = io.resultOut.fire
when( pushTok && !popTok) { pending := pending + 1 }
when(!pushTok && popTok) { pending := pending - 1 }
val haveToken = pushTok || pending =/= 0 // bypass на 0 латентность
io.resultOut.valid := haveToken && fifo.io.pop.valid
io.resultOut.payload := fifo.io.pop.payload
fifo.io.pop.ready := haveToken && io.resultOut.ready
}
object OperatorLatencyAlignerVerilog extends App {
SpinalVerilog(new OperatorLatencyAligner(UInt(32 bits), n = 8, fifoDepth = 16))
}Я спиналом не владею, не понимаю что это. Это все решение или только часть? Суть задачи в том, что исходный делитель - не конвейерный. А результирующий модуль должен вести себя будто делитель конвейерный. То есть принимать аргументы в каждом такте и выдавать результат каждый такт с фиксированной латентностью если нет backpressure.
Если это только часть и если цель - выровнять выход неконвейерного делителя до фиксированной латентности, то FIFO не нужно.
То есть вот для такого преобразования FIFO не нужно:
Но это только часть задачи. Нужно еще и чтобы могло принимать каждый такт.
Вариант задачи без ready или с ready? Без ready FIFO не нужно.
Умножителя нет, только делители. Про умножитель я выше описался.
Вообще вы несколько мутно написали. В какой момент происходит вталкивание в FIFO? При появлении res_valid от делителя? А если второй делитель сработает на несколько тактов раньше чем первый, то есть arg1 появился в такте 1, res1 возник в такте 10, а arg2 пришел в такте 2, но res2 возник в такте 8? Будет ли тогда res2 втолкнут в FIFO раньше чем res1?
Вы вообще можете нарисовать все делители, сдвиговый регистр и FIFO на картинке и написать код или псевдокод?
Я честно запутался что реально требуется :) Я решил задачу для одного блока (limited resources - XC2S15 :)) ), когда мы фиксируем latency на время большее чем N. Часто нужно если управляем NCO, но если вам нужно N-1 итд (c много-блоками), то будет немного по другому. Вечером подумаю, сейчас нас ждут самолеты…
Отличная задачка на подумать. Сначала прикинул с N блоками А/В, потом решил обойтись одним. За 10-15 минут надумалась схема подсчитывающая время выдачи результата из А/В и в зависимости от этого мультиплексирующая выход A/B с его сигналом VDo на один из N сдвиговых 9-битных регистров (в случае 8-битного слова С), имеющих фиксированную нарастающую задержку от 1 до N (первый регистр = 1 такт, второй = 2... последний = N). Выходы регистров тупо мультиплексируются по ИЛИ - старший бит будет выходом VDo блока, остальные - шина результата блока. Схема контроля содержит N счётчиков, которые разрешаются/сбрасываются сигналами VDi/VDo от А/В. На каждые новые данные запускается свой индивидуальный счётчик, после задействования последнего возвращаемся к первому. Конвейерная задержка блока будет равна то ли N, то ли N+1 - выясняется на этапе разработки.
Разнотактовые входы роли никакой особо тут не сыграют. Введение RDY тоже вроде бы особых проблем не должно составить, так как этот сигнал может управлять EN сдвиговых регистров и разрешением приёма по входу. Если в момент падения RDY А/В будет работать, то вроде бы ничего страшного - схема контроля направит результат на вход нужного регистра. Тут нужно будет подумать при наличии этого сигнала защитить логику - вдруг по входу кто-то VDi выставит - это нужно будет игнорировать и, в идеале, Error выставить.
С возрастом всё самое интересное оказывается в содержании пункта 1. Идея и архитектура под неё, рисуемая квадратиками карандашиком на бумажке. Код писать - это уже рутина и работа. Тем более на доске я синтаксис точно завалю))
Реальные проблемы с таймингами никто не спросил, зато устроили экзамен по истории информатики)
О, если бы знали как тяжело внедрялся язык Си в 80-х годах прошлого столетия в нашей стране
Спустя годы, в начале 2000-х только один человек при встрече со мной сказал искреннее спасибо за то, что тогда в 80-х настаивал на изучении и внедрении Юникса и Си.
Вы смысле "если бы"? Я читал книжку Кернигана-Ричи и "ОС Инмос" (советский Unix) все в том же 9 классе в 1986 году. Я потом летом 1986 года программировал на Си - см. https://habr.com/en/posts/1028712/
Насколько я помню народ перешел с Паскаля на Си в 1985-1987. Си был внедрен в ВЦ АН в Москве, в новосибирском акдемгородке. В Курчатнике и еще одном месте возникла группа которая потом стала кооперативом Демос.
А еще была МОС ЕС на ЕС ЭВМ, тоже Unix-система:
И там где был Unix, естественно, был и Си. Но в эти годы доминировал, конечно, PL/1. И никакие доводы не могли переломить эту ситуацию. Чтобы приучить к Си, мы сначала внедрили Паскаль, а затем и Си. Книги, про которые вы пишите, были настольными книгами у меня. Но в нашем институте за Си пришлось повоевать. ВЦ АН СССР, Новосибирский академгородок, это все же не рядовые НИИ, вам повезло.
Да, ваша хаброзаметка познавательная
Риторический вопрос.
А, Форт у себя не рассматривали, т.к. по книге Баранова, Ноздрунова “Форт и его реализации” он много где отметился в НИИ СССР, не считая DSSP (Диалоговая Система Структурного Программирования) происхождением из МГУ?
Нет, не рассматривался.Тогда уже было ясно, что так или иначе будущее за ОС типа Unix (винды еще не было, да и она выйдет из Xenix-а), а это всё же Си. Реалии сегодняшнего дня подтверждаю это (тот же Linux)
Гонки в верилоге - это реально база, но гонять деда по синтаксису мертвых языков чисто ради эго - такое себе удовольствие)
Ну а что с ним делать, если он соскочил с первого же вопроса на другой язык, а потом это повторил снова и снова?
Я студентов перед экзаменом честно предупреждаю, что язык их — враг их, а валить я умею единственным вопросом: «почему?».
если именно соскочил, возможно продолжать смысла нет, это все же не экзамен на отметку в школе, у меня несколько другой стиль интервью был, вообще вопросы на которые за 2 минуты есть ответ в сети не видел смысла спрашивать, задачи по программированию тоже, тем более терминологию, просто спрашивал "как работает" типа своими словами про то, что сделано лично по резюме, не помню случая, чтобы не стало более-менее понятно, следующий уровень вопросов - начиная с краткого введения в новый проект, типа что надо делать по мнению кандидата, как и что он может contribute, плюс будет ли это для кандидата интересно, кроме оценки кандидата цель интервью также установление определенной степени доверия, типа никто его здесь не кинет, проведенных интервью было реально много
Я, кажется, понял: деда кто-то проталкивал на это место и посадить в лужу надо было показательно
Ну да, выживают за счет подвешенного языка и солидного вида. Продают себя дорого, сидят на легаси тестах, а когда пахнет жареным - просто меняют контору
Постоянно эта путаница происходит. В таких статьях работа - собеседование, не программирование. А поэтому методы могут быть любыми как его проводить и как его проходить. Можно даже скакать наперегонки.
Сам метод мне кажется сомнительным. Если уж ищут кандидата на Go, то вряд ли поможет переход на Ada.
При таком подходе я бы наверное тоже не прошел собеседование (; Хотя у меня опыт больше 40 лет. Я просто честно отвечаю - я этим занимался, но подробностей не помню, зато у меня есть опыт, я знаю где это посмотреть, что лучше применять архитектурно. Вы можеете взять студента который ответит лучше меня на вашу "викторину" - но навряд ли он сможет лучше решить конкретную задачу. Потому что если я чего-то не знаю, я умею это узнавать (;
Да, времена и нравы изменились и мало смысла пытаться поучавствовать в “тараканьих” бегах, Всё нужное Мы уже прошли и что хотели доказали себе, и на “Слабо” не имеет смысла провацировать, бумеранг прилетит обратно. :)
Так он сам попал в такой путь, когда начал перескакивать на другие языки. У каждого человека должна быть технология, которую он знает хорошо. У одного это C в embedded контексте, у другого SystemVerilog с микроархитектурой, у третьего еще что-то. Вот про это и должно быть интервью. Если такой точки нет, то первой что нужно сделать - что-то хорошо выучить, даже если это займет скажем год или два. Иначе может получиться вот такое. А что делать интервьюеру? Сказать "хорошо, мы верим, вы все выучите?" Но для такой веры нужно обоснование - пример того, что человек уже знает хорошо.
Интересен сам факт того что он весь этот стек знает даже на уровне названий (вместе с автором, что еще интереснее). Любопытный персонаж, я бы его попробовал разговорить за жизнь и по задачам, которые он решал
В надежде, что персонаж, врущий на собеседовании, вдруг раскроет душу и расскажет, как он дошёл до такой жизни?..
Скорее всего во всём этом он либо просто стоял рядом, либо через такое же собеседование устраивался на синьористую позицию, на которой сначала «надо погрузиться в проект», а дальше в соответствии с анекдотом про три конверта. В целом умение беззастенчиво врать в таком режиме года по три-четыре позволит на каждом месте продержаться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Перепрыгивание с языка на язык как тактика прохождения интервью