S>а могли бы вы пожалуйста привести пример хорошего кандидата
S>я могу начать, в Америки хороший кандидат проработал больше года в известной IT компании S>запилил достаточно известтный проект
Хороший кандидат — это потенциально хороший коллега. А понятие хороших коллег у каждого свое.
Могу озвучить мое понимание, кого я бы хотел видеть рядом с собой.
Мне нужен тот, кто поможет тащить проект. Остальное — второстепенно.
Очень тяжело точно понять, будет ли человек решать проблемы, или же их создавать в рамках собеседования/тестовых заданий.
Поэтому приходится опираться на искусственные критерии и "жоп-филинг"
Итак, критерии не в порядке важности, а в том порядке как они пришли в голову:
Человек должен:
0. Хотеть работать. (Поразительно, как много людей хотят просиживать штаны, дуть щеки и получать деньги)
1. Не быть откровенно токсичным. (А мелкие тараканы — они есть у каждого, ничего, сработаемся)
2. Иметь околопрофильное образование. (Наличие сертификатов/конференций/гитхаба/пет проджекта значения не имеет, потому как может быть как признаком профессионализма и всестороннего развития так и признаком пустышки, пытющейся сертификатами скомпенсировать неумение работать)
3. Иметь опыт работы несколько лет на соответсвующем стеке (Вовсе не обязательно в компаниях из "первого дивизиона". Главное, чтобы не какое-то "КБ" или ООО "Вектор" из 3-х человек)
4. Отвечать на средней глубины теоретические вопросы по стеку с примерами (для .NET знать, как работает GC, понимать, что будет, если вылетит Exception в Dispose(). или в ~ClassName()). Иметь понятие о принципах и шаблонах.
5. Уметь стройно описать архитектуру предыдущего проекта. Кратко рассказать о слабых и сильных сторонах. Показать свое видение развития. Аргументировать свою позицию.
6. Уметь внятно объяснить, что и как он делал на предыдущем проекте/проектах. Проект не обязательно должен быть известным. Рассказать о своих достижениях. Своих, а не своей команды. С конкретными примерами. Быть способным обосновать, почему он принял то или иное решение.
7. Продемонстрировать умение читать код и рефакторить. Я даю распечатку синтезированного концентрата гов..кода на пол-странички, кандидат должен прочитать, сказать, что делает код, что с ним не так, как улучшить. ИМХО это самый важный тест в течении всего интервью!
8. Продемонстрировать умение логически мыслить. Для этого решить или по крайнем мере решить с подсказкой несложную задачку (например, отсортировать массив из миллиарда чисел типа Int16)
$>Назовите паттерны проектирования в кучу, сколько вспомнит. Вспоминает фабрику и в ступор.
Хорошее, годное интервью. Хочешь совет? Давай в качестве домашнего задания сочинение на тему "Единство и борьба противоположностей в реализации паттерна singleton". Поможешь нормальным людям проигнорировать неадекватную компанию. Столько неадекавта отсеешь!
$>Есть мысль давать домашнее задание кандидату перед техническим интервью. Сложное для интервью, но с элегантным решением и легко гуглящееся. А потом по результату порасспрашивать, как он/она сделал и почему.
$>Преследуемые цели:
$>- не устраивать экзамен
$>- дать шанс освежить в памяти базовые структуры данных. Чтобы не было неожиданностью требование знать bigO notation.
Ну и еще провести первичный отсев и т.д. и т.п.
Зачем вам давать домашнее задание — понятно.
Зачем кандидату его решать?
Ну т.е. смотрите, возьмем толкового сферического разработчика в вакууме который раз в 2-3 года меняет работу.
В половине случаев устраивается строго по рекомендации, а во второй половине случаев проходит порядка 5 on site интервью. Обычно он начнет проходить интервью не увольняясь. То есть со свободным временем у него туго.
Значит, грубо говоря, раз в 5 лет человек проходит 5 собеседований с целью трудоустройства.
При прочих равных, если вы — не Гугл, то толковый разработчик выберет сходить побеседовать в компанию, на которую не надо тратить время до интервью Что конкретно ваша компания может предложить такого, чтобы одно из этих 5 собеседований было ваше?
$>Здравствуйте, sergey2b, Вы писали:
S>>Можно пример нескольких вопросов
$>Назовите паттерны проектирования в кучу, сколько вспомнит. Вспоминает фабрику и в ступор.
Мда, вот это качество нужное. Я даже не помню, как SOLID и GRASP расшифровываются, что не мешает проектировать расширяемые компоненты и системы. Где-то три-пять шаблонов из пятнадцати мне абсолютно никогда не приходилось использовать, ибо никогда не были нужны. К Template method в своё "раннее" время пришёл сам, и только потом узнал об этом крутом названии. Так что я тоже в ступоре.
$>Здравствуйте, Gradiens, Вы писали:
G>>Зачем кандидату его решать? G>>Ну т.е. смотрите, возьмем толкового сферического разработчика в вакууме который раз в 2-3 года меняет работу.
$>На самом деле, это red flag если не контрактор.
Ну, это реалии рынка в РФ.
Я слышал, что в Долине — тоже, но не могу подтвердить, т.к. выводы основываются на статьях из сети.
$>Рекомендация не влияет на планку требований.
Спорно.
Когда меня хантили мои бывшие начальники на новую работу, никто из них не озадачивал домашним заданием/онлайн тестами/писаниной кода на бумажке. Ибо зачем?
Рекомендация влияет на то, что человек просто не выйдет на рынок. Его захантят, и вы даже не будете иметь шанса узнать, что он искал работу.
$>Если он толковый, то несложный тест не займёт много времени.
Если он толковый — то у него есть список компаний, куда его позвали на собеседование.
И он при прочих равных сначала сходит в те компании, которые не требуют предварительных ласк.
$>Посмотри на это с другой стороны: мы ведь не знаем, пока не отсобеседуем. Его очередь может долго не подходить, его резюме может быть менее впечатляющим, и в итоге его подберет другая контора.
Еще лучше. Человек потратит на вас свое время, а потом "Его очередь может долго не подходить"! Браво!
G>>Что конкретно ваша компания может предложить такого, чтобы одно из этих 5 собеседований было ваше?
$>Что что?
Как что? Мат ожидание количества собеседований прежде чем кандидат примет оффер приблизительно равно 5. Количество компаний на рынке, скорее всего, больше чем 5.
Что вы можете предложить такого, чтобы попасть в top-5 компаний для толкового кандидата?
Требование прелюдии перед собеседованием автоматически выбивает вас из этого списка.
Это случайно не о word count влоб и "на хадупе"? Я бы просто порасспрашивал о недавних и, по возможности, сложных задачах (самому было бы интересно), с которыми кандидат имел дело на текущем проекте или одном из прошлых (многое помнится длительное время); о том, как он их решал и решил; о том, что повлияло на такое решение и какие трудности были у него на пути. Всякие там сопутствующие вопросы о структурах данных, сложности доступа, алгоритмах и т.д., архитектурных решениях, процессе разработки и в целом промелькали бы по ходу разговора сами собой. Это располагает к общению и обмену знаниями, а не превращается в неинтерактивное код-ревю, которое зависит от ревювера, его компетентности и личных предпочтений в частности. Дома человеку интересно пожить своей жизнью и как минимум отдохнуть от работы.
$>Назовите паттерны проектирования в кучу, сколько вспомнит. Вспоминает фабрику и в ступор.
Паттерны сейчас своего рода антипаттерн. Они прижились в мире Java и частично C++, но за их пределами мало кому нужны и это правильно. Зачем тебе паттерны в современных языках типа Clojue, Python, Go? Паттерны в функциональных языках вообще отдельный мир. Я бы вопросы по паттернам закапывал за исключением "почему синглтон это зло?".
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Lexey, Вы писали:
L>>Ты, вроде, исключение в Dispose в исходном посте упоминал. А теперь про финализатор почему-то заговорил (который зачем-то деструктором обозвал). Может все-таки стоит сначала самому с терминологией определиться, а потом вопросы задавать?
S>Не все так однозначно -- https://habr.com/ru/post/122639/
S>Если не ошибаюсь, то финализатор вызывет Dispose, если он есть, есть ли нет -- то деструктор ~MyClass{}
~MyClass{} — это и есть финализатор, деструкторов в c# нет. dispose никто сам ниоткуда не вызывает, ты должен делать это руками (если нужно, а нужно не всегда).
$>Здравствуйте, ssp_alex, Вы писали:
_>>Если решение гуглится — то суть интервью проверить умеет ли кандидат гуглить,
$>Если умеет самостоятельно нагуглить оптимальное решение и понять, такой по сути и нужен.
_>>80% за то, что вы отклоните кандидата, который решает задачки как программер-олимпиадник
$>Задача отсеять кандидата, неспособного самостоятельно решить поставленную задачу.
Вот в чем закавырка — кандидат может нагуглить оптимальное решение и даже объяснить его, и может даже к месу говорить много умных слов и владеть терминологией, но при этом он запросто может оказаться неспособным решать поставленные задачи. Как показывает практика — таких полно, и что обидно — они не хотят ни меняться и ни учиться. С этим самая засада.
Возможно будет лучший вариант — заранее предупредить, что будет задание на кодерство и сказать в какой области IT. А на собеседовании давать решаемую задачку с ограниченным временем на выполенение и несколькими вариантами, тут можно увидеть — способен думать кандидат или нет, может он решать задачи, как решает, пишет код аккуратно или небрежно, решение сопровождаемое или одноразовое. Хотя мне кажется я вольными словами пересказываю "Путь программиста" в части проведения собеседования.
Здравствуйте, Gradiens, Вы писали:
G>Какая у тебя доменная область?
Я бы вообще не сказал что имеется какая-то ярко выраженная. Обычно работаю там, где есть передача данных (сети) от драйверов до облаков и/или безопасность. Но без какого-либо акцента, т.е. не могу сказать что в какой-то одной конкретной области прям охренеть какой эксперт. Да это и не надо в современном мире
KP>>т.е. если есть разработчик с опытом в JVM и в той же доменной области, то он все равно никак не подойдет к .NET стеку? А почему? G>Не подойдет, потому что даже если он эксперт на других стеках (что, кстати, не тривиально проверить, т.к. я-то — не эксперт), то переучить его на другой стек обойдется компании в копеечку.
Да ладно, сильное преувеличение. Я вообще затрудняюсь сказать на каком языке пишу, всё время что-то разное, ни кому это не мешало, ни когда с C++ позвали на Java писать, ни когда с C++ на Go перешел (параллельно дорабатывая проекты на C#), ни сейчас, когда с Go перешел на Elixir. Язык вообще значения не имеет
G>Что приводит нас к тому же вопросу: какая может быть доменная область, обучение которой дороже смены стека?
Любая вообще. Не просто же так большие компании ищут разработчиков которые просто умеют хорошо программировать. Все языки похожи... ладно, все языки по парадигмам похожи, берешь того кто в нужной парадигме в состоянии нормально писать и вперед.
Здравствуйте, sergey2b, Вы писали:
aik>>>Т.е. правильный ответ это когда напишет "double check locking", а не напишет — свободен? S>$>Не засчитается. S>какой засчитаеться ?
Неудивительно что с кандидатами такая печаль — хрен поймёшь что этот собеседователь от тебя хочет.
Здравствуйте, Gradiens, Вы писали:
G>Зачем кандидату его решать? G>Ну т.е. смотрите, возьмем толкового сферического разработчика в вакууме который раз в 2-3 года меняет работу.
На самом деле, это red flag если не контрактор.
G>В половине случаев устраивается строго по рекомендации, а во второй половине случаев проходит порядка 5 on site интервью. Обычно он начнет проходить интервью не увольняясь. То есть со свободным временем у него туго.
Рекомендация не влияет на планку требований.
G>Значит, грубо говоря, раз в 5 лет человек проходит 5 собеседований с целью трудоустройства. G>При прочих равных, если вы — не Гугл, то толковый разработчик выберет сходить побеседовать в компанию, на которую не надо тратить время до интервью
Если он толковый, то несложный тест не займёт много времени. Посмотри на это с другой стороны: мы ведь не знаем, пока не отсобеседуем. Его очередь может долго не подходить, его резюме может быть менее впечатляющим, и в итоге его подберет другая контора.
G>Что конкретно ваша компания может предложить такого, чтобы одно из этих 5 собеседований было ваше?
Что что?
$>Откуда мы знаем про ваших начальников и ваш уровень? Я видел соискателя на позицию техлида, который не мог рекурсию написать на доске.
Техлид должен программистам объяснять про рекурсию чтоле?! Или я не понял
За весь мой 20+ летний опыт в программировании рекурсию использовал лишь 2 или 3 раза... Один раз при удалении каталога с вложенными подкаталогами, второй — при парсинге XML. Третий про запас оставил
Здравствуйте, $$, Вы писали:
>>Вот видишь, как плохо, когда разработчики не знают паттерны проектирования. Проблема ведь не в Синглтон, а в неумении его готовить. >>Корректный порядок инициализации гарантирует DI. И по устройству DI (какие алгоритмы и структуры данных там применяются) можно поспрашивать. Но много народа слов таких не слышало.
Не вижу, так как я описал только одну, самую злобную проблему. Куча других проблем, таких как появление неявных зависимостей, появление дополнительного, внешнего состояния, появление неявной точки синхронизации никуда не деваются. В идеале поведение кода вообще не должно зависеть от состояний, только от входных данных (ага, привет функциональное программирование).
Да и DI ваше тоже говно, зависимости надо передавать явно.
Здравствуйте, sergey2b, Вы писали:
S>насколько я слышал в Австралии люди месяцами не могут найти работу
Немногие оставшиеся продуктовые компании Австралии строят из себя девочек. Каждые "рога и копыта" мнят себя гуглем с наса в одном флаконе с ковырнадцатью раундами интервью. Потому пока еще типа могут, но то, что в них уже Артемкам поручают нанимать людей, уже само по себе показатель.
Скоро получится как в НЗ. Там вроде тоже какое-то IT теплится, но все, кто мог, давно свалили в Австралию или сразу куда-нибудь еще.
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, $$,
V_S>Ты так и не ответил на ключевой вопрос: на позиции, куда собеседуется кандидат, во сколько раз зарплата превышает среднюю?
насколько я слышал в Австралии люди месяцами не могут найти работу
в США во время кризиса 2008 года наарод писал тесты на неделю и не возмущался, сам видел
Есть мысль давать домашнее задание кандидату перед техническим интервью. Сложное для интервью, но с элегантным решением и легко гуглящееся. А потом по результату порасспрашивать, как он/она сделал и почему.
Преследуемые цели:
— не устраивать экзамен
— дать шанс освежить в памяти базовые структуры данных. Чтобы не было неожиданностью требование знать bigO notation.
$>Есть мысль давать домашнее задание кандидату перед техническим интервью. Сложное для интервью, но с элегантным решением и легко гуглящееся. А потом по результату порасспрашивать, как он/она сделал и почему.
Вот давай так: у тебя во сколько раз зарплата превышает среднюю? Ни во сколько? Тогда зачем ты мне с твоим домашним заданием, если я пойду в десять фирм без этой муры?
G>7. Продемонстрировать умение читать код и рефакторить. Я даю распечатку синтезированного концентрата гов..кода на пол-странички, кандидат должен прочитать
Эк ты сейчас приложил сразу все эти фейсбуки-гуглы-микрософта
И заодно объяснил, почему огромное количество "продукции" (С) оных гигантов столь ужасного качества. Вот ровно потому, что на собеседовании ищут людей, которые умеют писать код, хотя на самом-то деле от них нужно уметь читать. Ибо написано кода уже столько, что больше и не надо, а вот прочитать его в силах лишь немногие. Проще еще написать...
G>Конкретно в моем посте был вопрос про специфику работы деструкторов в .NET. Опытный разработчик должен понимать, что будет в случае брошенного в деструкторе исключения. А может быть, он даже ловил такие ситуации на практике. Это вопрос на понимание работы платформы
Так и что будет-то? И эт... а разве сложно нагуглить ответ? Просто если это занимает 5 минут (нагуглить), то вопрос попросту не имеет смысла.
SD>>Эти слова бы, да всем ФП-разработчикам на лбу высечь, дабы отучились "а мы сейчас это в ETS-таблицу сложим и будет вам shared state". S>Это имеет право на жизнь если в таблицу пишет только один процесс, а читают многие (protected ETS) или в каждый ключ пишет свой процесс.
И как это решает всю ту кучу проблем, которую имеет shared state? Как это поможет от отсутствия garbage в этой таблице? Как это помешает одним процессам разгромить state других? Насколько хорошо это будет работать с concurrency? А что будет, если все планировщики будут одновременно исполнять процессы, читающие эту таблицу, в NUMA-архитектуре? (ответ: огромное количество minor page faults).
В общем, shared state — это всегда shared state, и нужно понимать все implications.
S>Не соглашусь. Быть может ищут действительно сильного программиста, которые такие детали должен знать. Ну вот нужен сильный программист .net. И если человек S>такие вещи не знает, то это уже звонок. Сложная кодовая база, нужно писать новый функционал и т.д. Такие люди иногда нужны.
Нет, нет, нет и еще раз нет. Сильный программист — это не тот, который *прямо сейчас* помнит эти детали. А тот, который:
1. Не будет делать того, что он не понимает.
2. Может быстро разобраться и понять.
3. Сделает то, что действительно нужно, и так, чтобы в будущем не наступать на эти же грабли снова.
Иными словами, сильный программист — это не тот, кто помнит мантру "если в деструкторе вылетает исключение, программа terminate-ится", а тот, кто понимает, как устроен современный софт, как устроена обработка ошибок/исключений, как работает система типов и тому подобные фундаментальные вещи.
Тем и отличается сильный программист от слабого. Фуднаментом. Который является мультипликатором продуктивности. Современные императивные платформы, будь то Java, .NET, C++ или что угодно еще, имеют по сути один фундамент. Еще один — это функциональщина, там надо вывернуть мозги набекрень (не у всех удается, и лучше делать в молодом возрасте). И с багажом знаний — двумя фундаментами, елси угодно, плюс профильным образованием — вот это уже действительно сильный программист, что может двигать мир. Такие есть, пусть и немного их.
S>Ну знаете ли, с таким подходмо навыки программирования вообще не нужны. Нагуглит. Глваное, чтобы умел искать инф-ию.
Добро пожаловать в Гугл, Фейсбук, Амазон, и подавляющее большинство ИТ (и не только ИТ) контор. Более того, добро пожаловать в современный мир. Правильно, immediate knowledge не нужно, ибо прикладные знания легко доступны. В отличие от фундаментальных. Которые не имеют однозначного вопрос-ответа.
S>Увы, похоже это так. Но код разный бывает. Бывает сложная кодовая база, где используется много продвинутых вещей, знать которые необходимо, S>чтобы править и читать.
Под такие задачи чаще всего или уже есть нужный человек (тот, что писал именно ту "продвинутую вещь"), либо нужен действительно редкий и сильный программист. Но задач таких, надо отметить, очень и очень мало.
Здравствуйте, aik, Вы писали:
aik>$>Вопрос архи сложный, понимаю. Уровня Страуструпа, не меньше. aik>Удивляет не вопрос,
Удивляет?
Меня давно уже не удивляет. Еще один хрестоматийный пример "вычитал в умной книжке одну прикольную фигню, сам нифига не понял, но теперь точно всех завалю".
S>В том плане, что стратегически надо синглтонов избавляться?
Не только от синглтонов, но и в целом от "внезапно инициализирующихся данных". Как правильно заметил landerhigh, зависимости должны быть явными (explicit).
Здравствуйте, $$, Вы писали:
SD>>Не только от синглтонов, но и в целом от "внезапно инициализирующихся данных". Как правильно заметил landerhigh, зависимости должны быть явными (explicit).
$>Наличие lazy loading зависит от требований.
Lazy loading и явные зависимости — совершенно ортогональные понятия.
Здравствуйте, Gradiens, Вы писали:
G>0. Хотеть работать. (Поразительно, как много людей хотят просиживать штаны, дуть щеки и получать деньги)
Как проверять на собеседовании? Вся Индия озвереть как "хочет работать" на словах, кстати...
G>1. Не быть откровенно токсичным. (А мелкие тараканы — они есть у каждого, ничего, сработаемся)
Да, это худо-бедно но можно проверить на собеседовании.
G>2. Иметь околопрофильное образование. (Наличие сертификатов/конференций/гитхаба/пет проджекта значения не имеет, потому как может быть как признаком профессионализма и всестороннего развития так и признаком пустышки, пытющейся сертификатами скомпенсировать неумение работать)
Профильное образование вообще ни о чем не говорит, кроме усидчивости, в отличие от того, что было причислено к потенциальным признакам пустышки. Там хоть потенциальные, тут же просто индикатор потраченного времени.
G>3. Иметь опыт работы несколько лет на соответсвующем стеке (Вовсе не обязательно в компаниях из "первого дивизиона". Главное, чтобы не какое-то "КБ" или ООО "Вектор" из 3-х человек)
Зачем?! Стек вообще не показатель ничего, достаточно доменной области.
G>4. Отвечать на средней глубины теоретические вопросы по стеку с примерами (для .NET знать, как работает GC, понимать, что будет, если вылетит Exception в Dispose(). или в ~ClassName()). Иметь понятие о принципах и шаблонах.
т.е. если есть разработчик с опытом в JVM и в той же доменной области, то он все равно никак не подойдет к .NET стеку? А почему?
G>5. Уметь стройно описать архитектуру предыдущего проекта. Кратко рассказать о слабых и сильных сторонах. Показать свое видение развития. Аргументировать свою позицию. G>6. Уметь внятно объяснить, что и как он делал на предыдущем проекте/проектах. Проект не обязательно должен быть известным. Рассказать о своих достижениях. Своих, а не своей команды. С конкретными примерами. Быть способным обосновать, почему он принял то или иное решение. G>7. Продемонстрировать умение читать код и рефакторить. Я даю распечатку синтезированного концентрата гов..кода на пол-странички, кандидат должен прочитать, сказать, что делает код, что с ним не так, как улучшить. ИМХО это самый важный тест в течении всего интервью! G>8. Продемонстрировать умение логически мыслить. Для этого решить или по крайнем мере решить с подсказкой несложную задачку (например, отсортировать массив из миллиарда чисел типа Int16)
Да, вот предыдущие 4 пункта очень разумны, согласен.
Здравствуйте, $$, Вы писали:
aik>>Что именно надо "рассказать про паттерн" чтоб пройти дальше?
$>Если кандидат дремучий, он влепит лок. Достойный скажет, что надо вот с таким паттерном (вспомнит название) или как питон, расскажет про стандарт C++ 11.
$>Хотя тут можно прямо попросить рассказать и написать псевдокод про double check locking.
Т.е. правильный ответ это когда напишет "double check locking", а не напишет — свободен?
Все вполне однозначно, если не заниматься софистикой. Деструкторов в привычном понимании в .net'е нет. Финализатор деструктором можно назвать только с огромным натягом.
S>Если не ошибаюсь, то финализатор вызывет Dispose, если он есть, есть ли нет -- то деструктор ~MyClass{}
Ошибаешься. Финализатор может вызвать Dispose только если этот вызов явно прописан в коде финализатора. При правильном дизайне подобный вызов нужен крайне редко — только если ты пишешь обертку вокруг какого-то нового неуправляемого ресурса, для которого нет готовой управляемой обертки. А ~MyClass() в шарпе — это всего лишь синтаксис для описания финализатора.
The injector tracks the dependencies for each type and uses bindings to inject them. This is the core of Guice, although you rarely interact with it directly. This "behind-the-scenes" operation is what distinguishes dependency injection from its cousin, the service locator pattern.
Здравствуйте, Sharov, Вы писали:
S>Ага, т.е. для service locattor'а я явно запрашиваю интерфейсы и потом конструирую объект,т.е. он выдает тип по интерфейсу, а DI конструирует объект без моего вмешательства, так?
DI инициализирует зависимости в правильной последовательности (привет топологическая сортировка) и передает их в конструктор. Единичные явные вызовы интерфейса- точка входа.
Здравствуйте, sergey2b, Вы писали:
S>Можно пример нескольких вопросов
Access cost for ArrayList, LinkedList, HashMap, TreeMap.
When ArrayList better suited than LinkedList, vise versa.
When HashMap better suited than TreeMap, vise versa.
Пара алгоритмических очень простых на рекурсию и использование структур данных из предыдущего списка. Естественно, я жду оптимальное за O(n), но выдают 2 вложенных цикла за O(n*n) и некорректным результатом. На рекурсии meltdown или в лучшем случае лишняя проверка условий, и на прямые подсказки не реагирует.
Назовите паттерны проектирования в кучу, сколько вспомнит. Вспоминает фабрику и в ступор.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, sergey2b, Вы писали:
S>>насколько я слышал в Австралии люди месяцами не могут найти работу
L>Немногие оставшиеся продуктовые компании Австралии строят из себя девочек. Каждые "рога и копыта" мнят себя гуглем с наса в одном флаконе с ковырнадцатью раундами интервью. Потому пока еще типа могут, но то, что в них уже Артемкам поручают нанимать людей, уже само по себе показатель. L>Скоро получится как в НЗ. Там вроде тоже какое-то IT теплится, но все, кто мог, давно свалили в Австралию или сразу куда-нибудь еще.
я когда то был фанатом PCTools
и напросился к ним на собеседование, был редкостный треш, а жаль тк компания когда то была интерестная
G>Значит, грубо говоря, раз в 5 лет человек проходит 5 собеседований с целью трудоустройства. G>При прочих равных, если вы — не Гугл, то толковый разработчик выберет сходить побеседовать в компанию, на которую не надо тратить время до интервью G>Что конкретно ваша компания может предложить такого, чтобы одно из этих 5 собеседований было ваше?
а могли бы вы пожалуйста привести пример хорошего кандидата
я могу начать, в Америки хороший кандидат проработал больше года в известной IT компании
запилил достаточно известтный проект
Здравствуйте, sergey2b, Вы писали:
S>я могу начать, в Америки хороший кандидат проработал больше года в известной IT компании S>запилил достаточно известтный проект
Ну, эээ.... В известных ИТ компаниях полно бестолковых людей, даже в Гугле хватает чуваков "ни о чем".
Запилил известный проект — во-первых — таких кандидатов будет мало, во-вторых — далеко не все из них вам подойдут.
Например — ковбои в одиночку запилившие неплохие продукты-фичи могут легко запороть командную работу. Особенно в Штатах на таких ковбоев насмотрелся, никаких нервов с ними работать не напасешься.
Да, хорошо когда человек продуктивно работал в команде над известным опенсорс продуктом, можно коммиты итп посмотреть — но таких кандидатов будет еще меньше, они редко сами ищут работу.
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, Gradiens, Вы писали:
S>спасибо, было интерестно
G>>8. Продемонстрировать умение логически мыслить. Для этого решить или по крайнем мере решить с подсказкой несложную задачку (например, отсортировать массив из миллиарда чисел типа Int16)
S>count sort ? или что то другое
Да, я имел в виду count sort. Но если кандидат предложит что-то другое — попрошу сравнить стоимость алгоритмов.
Но эта задачка — всего лишь пример для понимания сложности вопросов.
Я исхожу из специфики своей работы: энтерпрайз. Местами кровавый, да.
Тут не надо вертеть деревья. Надо лишь не писать код со сложностью O(n^2) там где есть очевидное решение O(n)
Здравствуйте, Gradiens, Вы писали:
G>>>Зачем кандидату его решать? G>>>Ну т.е. смотрите, возьмем толкового сферического разработчика в вакууме который раз в 2-3 года меняет работу. G>$>На самом деле, это red flag если не контрактор.
G>Ну, это реалии рынка в РФ. G>Я слышал, что в Долине — тоже, но не могу подтвердить, т.к. выводы основываются на статьях из сети.
В статьях в сети много чего пишут. Например, как джун из Минска с 6 мес опыта на PHP запилил проект, который потом команда опытных гуглеров не могла тянуть. А ещё про самородка, который написал новую ОС на коленке, с блекджеком и уникальными обоями.
G>$>Рекомендация не влияет на планку требований. G>Спорно.
У нас рекомендующий просит коллегу пособеседовать вместо него.
G>Когда меня хантили мои бывшие начальники на новую работу, никто из них не озадачивал домашним заданием/онлайн тестами/писаниной кода на бумажке. Ибо зачем?
Откуда мы знаем про ваших начальников и ваш уровень? Я видел соискателя на позицию техлида, который не мог рекурсию написать на доске. Крутой список работ, бак и магистр по компьютерным наукам. Это была бы большая жопа иметь такого у себя начальником.
G>Рекомендация влияет на то, что человек просто не выйдет на рынок. Его захантят, и вы даже не будете иметь шанса узнать, что он искал работу.
И отсутствие домашнего задания не поможет . Частица хорошего тоже есть- если такой попадёт к конкурентам, будет бесплатно им вредить
G>$>Если он толковый, то несложный тест не займёт много времени. G>Если он толковый — то у него есть список компаний, куда его позвали на собеседование. G>И он при прочих равных сначала сходит в те компании, которые не требуют предварительных ласк.
Кандидат, надувающий губки на кодерскую задачку, вызывает вопросы, а любит ли он кодить, или научился надувать щёки?
G>$>Посмотри на это с другой стороны: мы ведь не знаем, пока не отсобеседуем. Его очередь может долго не подходить, его резюме может быть менее впечатляющим, и в итоге его подберет другая контора. G>Еще лучше. Человек потратит на вас свое время, а потом "Его очередь может долго не подходить"! Браво!
В Яндекс тоже затягивают пылесосом всех подряд? Или в Касперского?
Здравствуйте, $$, Вы писали:
R>>За весь мой 20+ летний опыт в программировании рекурсию использовал лишь 2 или 3 раза...
$>Сочувствую.
А, вот и третий раз! Недавно было: рекурсия по внешним бинарным данным, а в данных баг. В результате через пару часов прод умирал, выжрав 80+ гиг ОЗУ. Неприятно вспоминать
Так что рекурсия — это редкий и опасный зверёк... Я вполне допускаю мысль, что техлид с рекурсией не сталкивался и знать он её не обязан.
Здравствуйте, $$, Вы писали:
G>>>И он при прочих равных сначала сходит в те компании, которые не требуют предварительных ласк.
$>>Кандидат, надувающий губки на кодерскую задачку, вызывает вопросы, а любит ли он кодить, или научился надувать щёки?
Я ничего не писал про надувание губок.
При чисто прагматическом подходе кандидат пойдет на собеседование туда, где сразу можно говорить о деле. И только, если во всех других компаниях его отшили, потратит время на ваши задачки.
И ты так и не ответил, что ваша компания предлагает такого, чего нет у конкурентов, кроме требования потратить время до собеседования?
Впрочем, понятное дело, вы можете искать как вам хочется. Это же ваш бизнес ))
G>>>Еще лучше. Человек потратит на вас свое время, а потом "Его очередь может долго не подходить"! Браво!
$>>В Яндекс тоже затягивают пылесосом всех подряд? Или в Касперского?
В Яндексе не был.
В Касперском был года 3 назад, получил оффер.
Собеседование назначили дня через три после созвона. Никто там не давал домашних задачек. Никто не заставлял проходить идиотские опросники. Ребята сумели запихнуть все этапы собеседования в один день.
А теперь скажи, только честно, допустим у нас есть хороший разраб. Вот он поговорил по телефону с Касперским, и его приглашают на очное интервью. Потом он поговорил с твоей компанией, ты выдал ему домашнее задание, и только после выполнения этого задания можно начать договариваться об интервью.
На какое интервью он пойдет?
Здравствуйте, Gradiens, Вы писали:
G>Мы вообще не контролируем ни время ни поток выполнения деструктора, потому что они выполняются рантаймом в специально выделенном потоке c наивысшим приоритетом. Необработанное исключение в этом специальном потоке может привести к повреждению состояния приложения. И вообще, деструкторы нужно реализовавать редко и крайне осторожно, например, для работы с неуправляемыми ресурсами.
Ты, вроде, исключение в Dispose в исходном посте упоминал. А теперь про финализатор почему-то заговорил (который зачем-то деструктором обозвал). Может все-таки стоит сначала самому с терминологией определиться, а потом вопросы задавать?
$>Ты натянул сову на глобус. Понятно, что ООП это плохо, а ФП хорошо. Но ты и другие отметившиеся тут топите, что паттерны знать вредно при ООП. При этом вспоминаешь про ФП. При этом, если чел действительно мыслит категориями ФП, то проблемы написать через рекурсию или развернуть хвостовую рекурсию, у него не должно возникнуть. Как например, и отсортировать массив. Как и написать топологическую сортировку на доске (что лежит в основе корректной инициализации DI).
сколько раз в жизни ты писал топологическую сортировку?
я один раз
KP>Да и DI ваше тоже говно, зависимости надо передавать явно.
О!
Еще одни золотые слова.
Я смотрю, уровень участников RSDN довольно заметно растет, и к тому же коррелирует с освоением новых более мощных языков и инструментов. Глядишь, уже скоро дойдет до обсуждения действительно сложных вещей, large scale, concurrency, distribution, property-based testing, и т.п.
Здравствуйте, landerhigh, Вы писали:
L>Тёма, ты только что доказал, что не работал с мало-мальски сложными проектами с историей на плюсах. Поэтому между тобой и людьми, которые на этом собаку съели, такая пропасть, что им после вопроса про синглтон банально не о чем дальше с тобой разговаривать. L>Ты даже не понял, что за проблему KP упомянул.
Ты так гордишься, что булькаешься в "проектах с историей на плюсах".
На самом деле конечно, есть проекты где на плюсах и с паттернами всё нормально. Просто ты в такие компании с твоим отношением к этой тематике не пройдешь.
Здравствуйте, landerhigh, Вы писали:
L>Немногие оставшиеся продуктовые компании Австралии строят из себя девочек. Каждые "рога и копыта" мнят себя гуглем с наса в одном флаконе с ковырнадцатью раундами интервью. Потому пока еще типа могут, но то, что в них уже Артемкам поручают нанимать людей, уже само по себе показатель.
Артёмка вроде грамотный программист. С чего такая ненависть?
S>Вопрос, впринципе, нормальный, чтобы понять как человек глубоко копал не сколько даже практику, а теорию. Если не ответит, значит нужно попроще, иначе -- посложнее.
Это не "попроще" и "посложнее". Это просто показывает, делал ли человек что-то с этим связанное относительно недавно (так что еще не успел забыть). Для программиста это не главное. А главное то, что программист может такую информацию найти на короткое время. Именно это и следует смотреть на собеседовании. Не то, что программист недавно делал (и потому помнит), а то, как он способен разобраться в задаче, которую он еще не делал.
Поэтому я считаю задачу "найти и исправить проблемы в говнокоде" — жизненной. Ибо это как бы не 90% реальности, данной нам в офисе.
Здравствуйте, aik, Вы писали:
aik>>>Но сам ты такой ответ не примешь. Я в тупике. aik>$>Не приписывай мне, что я не говорил.
aik>wuuut? http://rsdn.org/forum/job/7610029.1
Здравствуйте, kaa.python, Вы писали:
KP>Насколько помню, в C++11 и выше можно ограничиться обычной статической переменной так как гарантируется её атомарная инициализация. Компилятор барьеры напихает в код всё будет пучком.
Маловато будет, увы. Для глобальных статических переменных не гарантируется порядок инициализации. Так что, если тебе из одной статической переменной нужен доступ к другой, то может быть упс...
Можно засунуть статическую переменную в функцию, но тогда мы по факту получаем реализацию синглетона стандартными средствами языка.
Здравствуйте, Lexey, Вы писали:
KP>>Насколько помню, в C++11 и выше можно ограничиться обычной статической переменной так как гарантируется её атомарная инициализация. Компилятор барьеры напихает в код всё будет пучком.
L>Маловато будет, увы. Для глобальных статических переменных не гарантируется порядок инициализации. Так что, если тебе из одной статической переменной нужен доступ к другой, то может быть упс...
Да в самый раз будет для штуки, которой в коде быть не должно И, кстати, если еще зависимости между синглтонами делать это вообще ад будет. Типа такого
$>Есть мысль давать домашнее задание кандидату перед техническим интервью. Сложное для интервью, но с элегантным решением и легко гуглящееся. А потом по результату порасспрашивать, как он/она сделал и почему.
$>Преследуемые цели:
$>- не устраивать экзамен
$>- дать шанс освежить в памяти базовые структуры данных. Чтобы не было неожиданностью требование знать bigO notation.
$>Дискас.
В америки за 30 мин тел интервью выясняют подноготную кандидата
Примерно два вопроса в минуту задают
Так что на собеседование попадают только достойные
Там обязательно дают задачку на Кодинг
Здравствуйте, sergey2b, Вы писали:
S> В америки за 30 мин тел интервью выясняют подноготную кандидата S>Примерно два вопроса в минуту задают
Выглядит примерно так: первые 30 минут тест на адекватность. Этот этап все проходят от удовлетворительно до блестяще. Прям хочется сразу взять. Вторые 30 минут- технические вопросы, и там вскрываются неприятные вещи. Причём, даже кидаю прозрачные подсказки, но кандидат их не воспринимает. На прямые вопросы "какая цена доступа в ArrayList" выдаёт дичь.
$>Здравствуйте, sergey2b, Вы писали:
S>> В америки за 30 мин тел интервью выясняют подноготную кандидата S>>Примерно два вопроса в минуту задают
$>Выглядит примерно так: первые 30 минут тест на адекватность. Этот этап все проходят от удовлетворительно до блестяще. Прям хочется сразу взять. Вторые 30 минут- технические вопросы, и там вскрываются неприятные вещи. Причём, даже кидаю прозрачные подсказки, но кандидат их не воспринимает. На прямые вопросы "какая цена доступа в ArrayList" выдаёт дичь.
$>Здравствуйте, sergey2b, Вы писали:
S>>Можно пример нескольких вопросов
$>Access cost for ArrayList, LinkedList, HashMap, TreeMap.
$>When ArrayList better suited than LinkedList, vise versa.
$>When HashMap better suited than TreeMap, vise versa.
$>Пара алгоритмических очень простых на рекурсию и использование структур данных из предыдущего списка. Естественно, я жду оптимальное за O(n), но выдают 2 вложенных цикла за O(n*n) и некорректным результатом. На рекурсии meltdown или в лучшем случае лишняя проверка условий, и на прямые подсказки не реагирует.
$>Назовите паттерны проектирования в кучу, сколько вспомнит. Вспоминает фабрику и в ступор.
Вопросы простые должны отвечать на них
Я вспоминаю на более 5 патеров и фабрика первая или вторая
Здравствуйте, halo, Вы писали:
H>Здравствуйте, $$, Вы писали:
H>$>Дискас.
H>Это случайно не о word count влоб и "на хадупе"? Я бы просто порасспрашивал о недавних и, по возможности, сложных задачах (самому было бы интересно), с которыми кандидат имел дело на текущем проекте или одном из прошлых (многое помнится длительное время); о том, как он их решал и решил; о том, что повлияло на такое решение и какие трудности были у него на пути. Всякие там сопутствующие вопросы о структурах данных, сложности доступа, алгоритмах и т.д., архитектурных решениях, процессе разработки и в целом промелькали бы по ходу разговора сами собой. Это располагает к общению и обмену знаниями, а не превращается в неинтерактивное код-ревю, которое зависит от ревювера, его компетентности и личных предпочтений в частности. Дома человеку интересно пожить своей жизнью и как минимум отдохнуть от работы.
святой человек, а теперь представте у вас 200 кагдидатов а вам нуужен 1-2 сотрудника
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, sergey2b, Вы писали:
S>>святой человек, а теперь представте у вас 200 кагдидатов а вам нуужен 1-2 сотрудника
L>Тогда вам нужно поручить вопрос найма кому-то более компетентному в данном вопросе.
я не занимаюсь наймом
и в собеседования участвовал всего несколько раз, просил показать код который написал кандидат и который он сам считает хорошим
просил написать простую задачку (точно не уровня гугла) посмотреть что он умеет писать
$>Выглядит примерно так: первые 30 минут тест на адекватность. Этот этап все проходят от удовлетворительно до блестяще. Прям хочется сразу взять. Вторые 30 минут- технические вопросы, и там вскрываются неприятные вещи. Причём, даже кидаю прозрачные подсказки, но кандидат их не воспринимает. На прямые вопросы "какая цена доступа в ArrayList" выдаёт дичь.
Тех, кто валится на ArrayList действительно, стоит отправлять подучиться...
Но если кандидаты сыпятся на более сложных задачах, возникает вопрос: А в описании вакансии у вас указано, что требуются знания алгоритмов и структур данных?
Если нет — укажите. Сэкономите время и себе и кандидатам.
Приведу пример с другой стороны баррикад:
Собеседовался как-то в "позитивную и технологичную" компанию (кто там был, название угадает). Сходу стали спрашивать про контекстно-свободные грамматики. Я честно сказал, понимаете, я их изучал 15 лет назад. Но чуваки на полном серьезе хотели чтобы я им писал какие-то формулы, промурыжили час.
При этому в описании вакансии много воды, и ни слова про математику.
F>Ну, эээ.... В известных ИТ компаниях полно бестолковых людей, даже в Гугле хватает чуваков "ни о чем". F>Запилил известный проект — во-первых — таких кандидатов будет мало, во-вторых — далеко не все из них вам подойдут. F>Например — ковбои в одиночку запилившие неплохие продукты-фичи могут легко запороть командную работу. Особенно в Штатах на таких ковбоев насмотрелся, никаких нервов с ними работать не напасешься. F>Да, хорошо когда человек продуктивно работал в команде над известным опенсорс продуктом, можно коммиты итп посмотреть — но таких кандидатов будет еще меньше, они редко сами ищут работу.
какая твоя версия хорошего кандидата ?
и можно плиз пример, что с точки зрения вашей team кандидат должен знать и уметь делать на C++
G>8. Продемонстрировать умение логически мыслить. Для этого решить или по крайнем мере решить с подсказкой несложную задачку (например, отсортировать массив из миллиарда чисел типа Int16)
Здравствуйте, sergey2b, Вы писали:
S>какая твоя версия хорошего кандидата ? S>и можно плиз пример, что с точки зрения вашей team кандидат должен знать и уметь делать на C++
Gradiens хорошо ответил. А про C++ — опять же от команды зависит, в нашей команде некого среднего уровня С++/С++11 достаточно.
Понимание основ работы с памятью, классами, смарт-поинтеры, мув-семантика итп, никакой эзотерики. Какие-то пробелы ни разу не критичны — см ответ Gradiens.
Спрашивать про аргументы методов imho моветон. Спрашивать про count sort- годный вопрос, но это вопрос-ответ. Не-токсичность есть у многих, а элементарно рекурсию написать не могут. Я бы лучше взял толкового токсичного, чем нетоксичного нетолкового.
Здравствуйте, VovkaMorkovka, Вы писали:
VM>Вот давай так: у тебя во сколько раз зарплата превышает среднюю? Ни во сколько? Тогда зачем ты мне с твоим домашним заданием, если я пойду в десять фирм без этой муры?
Здравствуйте, landerhigh, Вы писали:
L>$>Назовите паттерны проектирования в кучу, сколько вспомнит. Вспоминает фабрику и в ступор.
L>Хорошее, годное интервью. Хочешь совет? Давай в качестве домашнего задания сочинение на тему "Единство и борьба противоположностей в реализации паттерна singleton". Поможешь нормальным людям проигнорировать неадекватную компанию. Столько неадекавта отсеешь!
По синглтону есть хороший вопрос- как его реализовать для многопоточки. Надуватели щёк сразу сдуваются
Конечно, спрашивать синтаксис — моветон. Кроме того, это абсолютно бесполезно.
Конкретно в моем посте был вопрос про специфику работы деструкторов в .NET. Опытный разработчик должен понимать, что будет в случае брошенного в деструкторе исключения. А может быть, он даже ловил такие ситуации на практике. Это вопрос на понимание работы платформы.
И опять-таки, это всего лишь пример. Я уверен, существуют вопросы получше ))
$> Спрашивать про count sort- годный вопрос, но это вопрос-ответ.
Если соискатель — толковый, то да. И это хорошо, меньше времени потратим.
$> Я бы лучше взял толкового токсичного, чем нетоксичного нетолкового.
Мое мнение, что токсичный человек способен подпортить жизнь всей команде.
Если есть только толковый токсичный и нетоксичный бестолковый — я бы не взял никого.
Здравствуйте, kaa.python, Вы писали:
G>>3. Иметь опыт работы несколько лет на соответсвующем стеке (Вовсе не обязательно в компаниях из "первого дивизиона". Главное, чтобы не какое-то "КБ" или ООО "Вектор" из 3-х человек) KP>Зачем?! Стек вообще не показатель ничего, достаточно доменной области.
Воот, это очень интересный вопрос.
Какая у тебя доменная область?
Я, например, работаю над LIMS и могу сказать, что это не rocket science.
Да, своя специфика есть, но наличие толкового аналитика, переводящего с медицинского английского на обычный английский, сильно ускоряет и облегчает вхождение.
На предыдущей работе я клепал разные поделки для финансовой организации. Домена не было как такового, потому как задачи были от "прикрутить эквайринг к вот этой хреновине" и до "подружить АТС с нашей CRM"
То есть, конечно, предметная область у каждой задачи была, но они были зачастую вообще не пересекающиеся.
G>>4. Отвечать на средней глубины теоретические вопросы по стеку с примерами (для .NET знать, как работает GC, понимать, что будет, если вылетит Exception в Dispose(). или в ~ClassName()). Иметь понятие о принципах и шаблонах.
KP>т.е. если есть разработчик с опытом в JVM и в той же доменной области, то он все равно никак не подойдет к .NET стеку? А почему?
Не подойдет, потому что даже если он эксперт на других стеках (что, кстати, не тривиально проверить, т.к. я-то — не эксперт), то переучить его на другой стек обойдется компании в копеечку.
Что приводит нас к тому же вопросу: какая может быть доменная область, обучение которой дороже смены стека?
S>насколько я слышал в Австралии люди месяцами не могут найти работу S>в США во время кризиса 2008 года наарод писал тесты на неделю и не возмущался, сам видел
Здравствуйте, $$, Вы писали:
G>>Когда меня хантили мои бывшие начальники на новую работу, никто из них не озадачивал домашним заданием/онлайн тестами/писаниной кода на бумажке. Ибо зачем?
$>Откуда мы знаем про ваших начальников и ваш уровень? Я видел соискателя на позицию техлида, который не мог рекурсию написать на доске.
Не "не мог", а "не видел смысла".
$>Крутой список работ, бак и магистр по компьютерным наукам. Это была бы большая жопа иметь такого у себя начальником.
Здравствуйте, sergey2b, Вы писали:
S>я когда то был фанатом PCTools S>и напросился к ним на собеседование, был редкостный треш, а жаль тк компания когда то была интерестная
Здравствуйте, sergey2b, Вы писали:
S>я когда то был фанатом PCTools
Такая же ситуёвина...
Фанател от DN и The Bat! Ну реально качественные продукты: писал своё по образу и подобию. Но сейчас что? Сейчас в Ритлабсе полторы калеки работают, которые не хотят прислушиваться к пожеланиям пользователей (точнее, к моим пожеланиям) Поэтому фиг им, а не покупка.
Здравствуйте, Gradiens, Вы писали:
G>4. Отвечать на средней глубины теоретические вопросы по стеку с примерами (для .NET знать, как работает GC, понимать, что будет, если вылетит Exception в Dispose(). или в ~ClassName()). Иметь понятие о принципах и шаблонах.
.NET вообще-то управляемая среда, и Dispose() там вызывается только для разрушения неуправляемых обьектов, таким образом к .NET стэку вопрос не относится
G>8. Продемонстрировать умение логически мыслить. Для этого решить или по крайнем мере решить с подсказкой несложную задачку (например, отсортировать массив из миллиарда чисел типа Int16)
алгоритмы не относяться к понятиям "логически мыслить", в .NET стеке алгоритмы не несут в кандидате никакой полезной нагрузки
Здравствуйте, Rhino, Вы писали:
R>Техлид должен программистам объяснять про рекурсию чтоле?! Или я не понял
Техлид должен быть примером для подражания.
R>За весь мой 20+ летний опыт в программировании рекурсию использовал лишь 2 или 3 раза...
Сочувствую.
Здравствуйте, SkyDance, Вы писали:
G>>7. Продемонстрировать умение читать код и рефакторить. Я даю распечатку синтезированного концентрата гов..кода на пол-странички, кандидат должен прочитать
SD>Эк ты сейчас приложил сразу все эти фейсбуки-гуглы-микрософта
SD>И заодно объяснил, почему огромное количество "продукции" (С) оных гигантов столь ужасного качества.
Давно ещё, на собеседовании в одной компании спрашивали по diamond inheritance. Может показаться, давали "синтезированный концентрат говнокода". Но потом я узнал, это был типичный кусок из их кодовой базы. Так что, если лично меня попросят прочитать кусочек отборного г-кода, это будет red flag.
Здравствуйте, SkyDance, Вы писали:
KP>>Я бы вопросы по паттернам закапывал за исключением "почему синглтон это зло?".
SD>Эти слова бы, да всем ФП-разработчикам на лбу высечь, дабы отучились "а мы сейчас это в ETS-таблицу сложим и будет вам shared state".
Это имеет право на жизнь если в таблицу пишет только один процесс, а читают многие (protected ETS) или в каждый ключ пишет свой процесс.
Здравствуйте, SkyDance, Вы писали:
L>>А ты сам-то знаешь, как? (С прищуром) SD>(с еще большим прищуром) а ты? SD>Я несколько лет назад думал, что знаю, а вот сейчас, научившись, уже... не уверен.
Знаю один способ. Несколько радикальный, конечно, но вроде работает.
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, $$, Вы писали:
S>>>Можно пример нескольких вопросов
S>$>Access cost for ArrayList, LinkedList, HashMap, TreeMap. S>А у HashMap это будет O(n) или О(1)? Просто интересно какой ответ ожидается.
ожидается — зависит от числа коллизий (совпадений хеш кодов)
Das Reich der Freiheit beginnt da, wo die Arbeit aufhört. (c) Karl Marx
Здравствуйте, Rhino, Вы писали:
R> Фанател от DN и The Bat! Ну реально качественные продукты: писал своё по образу и подобию. Но сейчас что? Сейчас в Ритлабсе полторы калеки работают, которые не хотят прислушиваться к пожеланиям пользователей (точнее, к моим пожеланиям) Поэтому фиг им, а не покупка.
Здравствуйте, Vlad_SP, Вы писали:
R>> Фанател от DN и The Bat! Ну реально качественные продукты: писал своё по образу и подобию. Но сейчас что? Сейчас в Ритлабсе полторы калеки работают, которые не хотят прислушиваться к пожеланиям пользователей (точнее, к моим пожеланиям) Поэтому фиг им, а не покупка. V_S>Ээээ..... DN еще жифф???
Конечно же нет. Речь про текущую ситуацию, а у Ритлабса сейчас лишь один единственный продукт.
$>Давно ещё, на собеседовании в одной компании спрашивали по diamond inheritance. Может показаться, давали "синтезированный концентрат говнокода". Но потом я узнал, это был типичный кусок из их кодовой базы. Так что, если лично меня попросят прочитать кусочек отборного г-кода, это будет red flag.
ты просто еще не работал в америки
такого говнокода как здесь я не встречал не в РФ ЮАР Китаи
при этом 99% попыток погворить с тимлидером заканчиваеться — я начальник ты мудак, аргументация к авторитетма американского же CS не работает
из личного списка треша
файл больше 50000 строк, VS торомозила так что все операции занимали секунды те нажал кнокпу символ появлися через несколько сек
функции больше 5000 строк, этим здесь многие грешат, особый пипец if for на всю функцию
функция больше 200 параметров тк что компилятор начинает говорить что не может ее скомпилировать
класс больше чем 1000 (почти полторы тыс) функций и мемберов, наазвание класса Rome
серилизация больше 200 лассов в ручную с запретом использования темплейтов и наследования
самописные list и vector которые не доятгивают даже длл 20% их функционала
сборка проекта на VS6 для платформы win xp 32 в 2019 году (старушка используеться через 20 лет после выхода SP6 для нее, я фанат 6 студии но не для десктопных приложений)
Здравствуйте, Rhino, Вы писали:
R>Здравствуйте, Vlad_SP, Вы писали:
R>>> Фанател от DN и The Bat! Ну реально качественные продукты: писал своё по образу и подобию. Но сейчас что? Сейчас в Ритлабсе полторы калеки работают, которые не хотят прислушиваться к пожеланиям пользователей (точнее, к моим пожеланиям) Поэтому фиг им, а не покупка. V_S>>Ээээ..... DN еще жифф??? R>Конечно же нет. Речь про текущую ситуацию, а у Ритлабса сейчас лишь один единственный продукт.
DN стал open source и иногда релизят (я использую когда пишу на tandy 1000)
а VC досихпор продаеться и пусть несколько раз в год но его покупают
вообше оглядываясь назад вовремена DOS и Win 31 продукты были еще относительно простыие и их можно было написать силами 1-3 человек
тееперь к сожалению нет
Здравствуйте, SkyDance, Вы писали:
G>>Конкретно в моем посте был вопрос про специфику работы деструкторов в .NET. Опытный разработчик должен понимать, что будет в случае брошенного в деструкторе исключения. А может быть, он даже ловил такие ситуации на практике. Это вопрос на понимание работы платформы
SD>Так и что будет-то? И эт... а разве сложно нагуглить ответ? Просто если это занимает 5 минут (нагуглить), то вопрос попросту не имеет смысла.
Любой ответ можно нагуглить. Но наверно тяжело делать это в ходе интеревью, не так ли?
А ответ лично я ожидал бы такой:
Мы вообще не контролируем ни время ни поток выполнения деструктора, потому что они выполняются рантаймом в специально выделенном потоке c наивысшим приоритетом. Необработанное исключение в этом специальном потоке может привести к повреждению состояния приложения. И вообще, деструкторы нужно реализовавать редко и крайне осторожно, например, для работы с неуправляемыми ресурсами.
Понимаешь, это всего лишь пример. Можно напридумывать массу других вопросов.
Здравствуйте, Gradiens, Вы писали:
G>Конкретно в моем посте был вопрос про специфику работы деструкторов в .NET. Опытный разработчик должен понимать, что будет в случае брошенного в деструкторе исключения. А может быть, он даже ловил такие ситуации на практике. Это вопрос на понимание работы платформы.
Э... деструкторов в .NET??? Ты платформой не ошибся случаем?
Здравствуйте, Lexey, Вы писали:
L>Здравствуйте, Gradiens, Вы писали:
G>>Мы вообще не контролируем ни время ни поток выполнения деструктора, потому что они выполняются рантаймом в специально выделенном потоке c наивысшим приоритетом. Необработанное исключение в этом специальном потоке может привести к повреждению состояния приложения. И вообще, деструкторы нужно реализовавать редко и крайне осторожно, например, для работы с неуправляемыми ресурсами.
L>Ты, вроде, исключение в Dispose в исходном посте упоминал. А теперь про финализатор почему-то заговорил (который зачем-то деструктором обозвал). Может все-таки стоит сначала самому с терминологией определиться, а потом вопросы задавать?
Сорри, термины попутал.
В исходном посте говорил про обе вещи: Dispose и финализатор.
И вопрос (ну просто один из вопросов который приведен навскидку для того, чтобы проиллюстировать мой субъективный подход) был в том, что произойдет если исключение будет выброшено из Dispose и что изменится если исключение будет выброшено из финализатора.
L>Ты, вроде, исключение в Dispose в исходном посте упоминал. А теперь про финализатор почему-то заговорил (который зачем-то деструктором обозвал). Может все-таки стоит сначала самому с терминологией определиться, а потом вопросы задавать?
Здравствуйте, Gradiens, Вы писали:
G>И вопрос (ну просто один из вопросов который приведен навскидку для того, чтобы проиллюстировать мой субъективный подход) был в том, что произойдет если исключение будет выброшено из Dispose и что изменится если исключение будет выброшено из финализатора.
Если искл. в финализаторе, то срубит приложение. Если Dispose, то смотря какой поток будет его вызывать.
Здравствуйте, Gradiens, Вы писали:
G>$>>Кандидат, надувающий губки на кодерскую задачку, вызывает вопросы, а любит ли он кодить, или научился надувать щёки?
G>Я ничего не писал про надувание губок. G>При чисто прагматическом подходе кандидат пойдет на собеседование туда, где сразу можно говорить о деле. И только, если во всех других компаниях его отшили, потратит время на ваши задачки.
Я думаю давать 1 задачку на 5 строк кода. В литкоде помечена "easy".
Хорошего кандидата (в моём понимании) она не отпугнёт.
Здравствуйте, SkyDance, Вы писали:
KP>>Я бы вопросы по паттернам закапывал за исключением "почему синглтон это зло?".
SD>Эти слова бы, да всем ФП-разработчикам на лбу высечь, дабы отучились "а мы сейчас это в ETS-таблицу сложим и будет вам shared state".
Ну... а если запихать в ETS-таблицу к которой обращается единственный GenServer? Или ты за Агенты? Я к тому, что состояние всяко хранить приходится даже в функциональных языках, а если язык реализует концепт let it crash, то вопрос надежного сохранения состояния как никогда важен. Или речь про давайте класть всё в ETS-таблицу и отовсюду в неё лазить за данными?
Самый ад с синглтонами в C++, где нет гарантии на порядок инициализации статических объектов в рамках разных модулей трансляции. Участвовал в C++ проекте который так густо порос синглтонами, что в конце концов все синглтоны были помещены в убер-синглтон дабы обеспечить гарантию порядка их инициализации
Здравствуйте, Gradiens, Вы писали:
G>Сорри, термины попутал. G>В исходном посте говорил про обе вещи: Dispose и финализатор. G>И вопрос (ну просто один из вопросов который приведен навскидку для того, чтобы проиллюстировать мой субъективный подход) был в том, что произойдет если исключение будет выброшено из Dispose и что изменится если исключение будет выброшено из финализатора.
в нормальном коде никаких финализаторов не будет, неуправляемые ресурсы должны использоваться с using что-бы разрушать их сразу после выполнения необходимых действий, а не висеть в памяти пока класс не подберет GC
Здравствуйте, kaa.python, Вы писали:
KP>Самый ад с синглтонами в C++, где нет гарантии на порядок инициализации статических объектов в рамках разных модулей трансляции. Участвовал в C++ проекте который так густо порос синглтонами, что в конце концов все синглтоны были помещены в убер-синглтон дабы обеспечить гарантию порядка их инициализации
Вот видишь, как плохо, когда разработчики не знают паттерны проектирования. Проблема ведь не в Синглтон, а в неумении его готовить.
Корректный порядок инициализации гарантирует DI. И по устройству DI (какие алгоритмы и структуры данных там применяются) можно поспрашивать. Но много народа слов таких не слышало.
Здравствуйте, kaa.python, Вы писали:
>>>Вот видишь, как плохо, когда разработчики не знают паттерны проектирования. Проблема ведь не в Синглтон, а в неумении его готовить. >>>Корректный порядок инициализации гарантирует DI. И по устройству DI (какие алгоритмы и структуры данных там применяются) можно поспрашивать. Но много народа слов таких не слышало.
KP>Не вижу, так как я описал только одну, самую злобную проблему. Куча других проблем, таких как появление неявных зависимостей, появление дополнительного, внешнего состояния, появление неявной точки синхронизации никуда не деваются. В идеале поведение кода вообще не должно зависеть от состояний, только от входных данных (ага, привет функциональное программирование).
KP>Да и DI ваше тоже говно, зависимости надо передавать явно.
KP>Короче, завалил собеседование
Ты натянул сову на глобус. Понятно, что ООП это плохо, а ФП хорошо. Но ты и другие отметившиеся тут топите, что паттерны знать вредно при ООП. При этом вспоминаешь про ФП. При этом, если чел действительно мыслит категориями ФП, то проблемы написать через рекурсию или развернуть хвостовую рекурсию, у него не должно возникнуть. Как например, и отсортировать массив. Как и написать топологическую сортировку на доске (что лежит в основе корректной инициализации DI).
KP>Ну... а если запихать в ETS-таблицу к которой обращается единственный GenServer?
Это для того, чтобы сильно проиграть в производительности относительно других решений? Мы недавно исследовали 6 разных вариантов, и private ETS далеко не самый быстрый вариант хранения. Не в последнюю очередь из-за более дорогих операций аллокации (ets allocator вместо eheap). Плюс фрагментация, плюс (сюрприз!) locking, плюс если еще и ETS использовать по имени, а не по рефернсу.
KP> Я к тому, что состояние всяко хранить приходится даже в функциональных языках,
Состояние процесса следует хранить в его состоянии А не в базе данных (ETS изначально предполагались быть БД, и, собственно, это в некотором роде так и есть).
KP> а если язык реализует концепт let it crash, то вопрос надежного сохранения состояния как никогда важен.
Стоит изучить очень важную тему — supervision, и там как раз есть все необходимое для понимания, какое состояние нужно сохранять, и как.
KP> Или речь про давайте класть всё в ETS-таблицу и отовсюду в неё лазить за данными?
...но ты прав, речь чаще всего именно про это !!! С этим больше всего бороться приходится.
KP>Самый ад с синглтонами в C++
О если бы. Ответы, которые можно нагуглить, — уровень от силы миддл-левел.
G>Но наверно тяжело делать это в ходе интеревью, не так ли?
Поэтому я и спрашиваю: в чем смысл задавать такой вопрос на интервью? Если ответ легко нагуглить вне интервью, его нет смысла задавать на интервью, потому что когда человек с таким вопросом встретится, он просто нагуглит ответ.
G>А ответ лично я ожидал бы такой:
$>Вот видишь, как плохо, когда разработчики не знают паттерны проектирования. Проблема ведь не в Синглтон, а в неумении его готовить.
Проблема не в том, что "неумение готовить", а в том, что об этом вообще нужно задумываться. Это показатель неэффективности инструмента (с точки зрения промышленной разработки софта).
Здравствуйте, $$, Вы писали:
>> Ты натянул сову на глобус. Понятно, что ООП это плохо, а ФП хорошо. Но ты и другие отметившиеся тут топите, что паттерны знать вредно при ООП.
Ух как копнул! Да само по себе ООП в классическом виде (классы + наследование) вредно И паттерны из ООП лишь утяжеляют код. Посмотри на практически любое Java приложение – оно тормозит что ппц. И ведь совсем не потому что JVM тормозная, а потому что правильный Java разработчик жизни себе без паттернов не мыслит.
>> При этом вспоминаешь про ФП. При этом, если чел действительно мыслит категориями ФП, то проблемы написать через рекурсию или развернуть хвостовую рекурсию, у него не должно возникнуть. Как например, и отсортировать массив.
Да, я могу так же Go без всякой функциональщины взять в качестве примера и сказать тоже самое – синглтоны зло! Ну да рекурсию любой дурак напишет, чего ж там писать-то?
>> Как и написать топологическую сортировку на доске (что лежит в основе корректной инициализации DI).
Кхм, ну вот я единственный раз писал топологическую сортировку когда задачки на ЛитКоде решал и сейчас крайне смутно помню как она там устроена. Само собой человек не задрачивавшийся на тестовые задачки из ФАНГ сольется на таком и подумает что у собеседующего крыша потекла (если, конечно, собеседование не в ФАНГ).
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, $$, Вы писали:
>>> Ты натянул сову на глобус. Понятно, что ООП это плохо, а ФП хорошо. Но ты и другие отметившиеся тут топите, что паттерны знать вредно при ООП.
KP>Ух как копнул! Да само по себе ООП в классическом виде (классы + наследование) вредно И паттерны из ООП лишь утяжеляют код. Посмотри на практически любое Java приложение – оно тормозит что ппц. И ведь совсем не потому что JVM тормозная, а потому что правильный Java разработчик жизни себе без паттернов не мыслит.
Да ладно. Как это так объясни?
Ну некоторые, конечно, пишут класс для инкремента. Но как это влияет на производительность настолько?
Здравствуйте, SkyDance, Вы писали:
SD>$>Вот видишь, как плохо, когда разработчики не знают паттерны проектирования. Проблема ведь не в Синглтон, а в неумении его готовить.
SD>Проблема не в том, что "неумение готовить", а в том, что об этом вообще нужно задумываться.
Ты задумываешься про ETS. Тоже неэффективный инструмент?
Мой пойнт, что паттерн Синглтон- это просто паттерн для хранения единственного экземпляра. То, что какие-то сиплюсники или жависты его используют не по назначению, это следствие их незнания паттернов проектирования.
$>Вот видишь, как плохо, когда разработчики не знают паттерны проектирования. Проблема ведь не в Синглтон, а в неумении его готовить.
$>Корректный порядок инициализации гарантирует DI. И по устройству DI (какие алгоритмы и структуры данных там применяются) можно поспрашивать. Но много народа слов таких не слышало.
Тёма, ты только что доказал, что не работал с мало-мальски сложными проектами с историей на плюсах. Поэтому между тобой и людьми, которые на этом собаку съели, такая пропасть, что им после вопроса про синглтон банально не о чем дальше с тобой разговаривать.
Ты даже не понял, что за проблему KP упомянул.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Да ладно. Как это так объясни?
Объясняю. Вместо классов и наследования в понимании ООП, есть два куда более удачный подхода: чистые функции или, если писать на функциональном языке никак, то интерфейсы (Go или Rust, не Java или C++). Эти концепции позволяют значительно лучше разделить данные с кодом и обеспечить более просто тестирование системы.
CAF>Ну некоторые, конечно, пишут класс для инкремента. Но как это влияет на производительность настолько?
Паттерны вводят довольно большое количество вспомогательных сущностей, зачастую для замены одного простого if/else. Фабрика для одного/двух объектов? Даа! Мы же на Java пишем, вдруг потом (говорить с придыханием) мы захотим расширить систему? И когда такое "вдруг" начинает пронизывать всю систему, она, почему-то, начинает медленно работать
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Да ладно. Как это так объясни?
KP>Объясняю. Вместо классов и наследования в понимании ООП, есть два куда более удачный подхода: чистые функции или, если писать на функциональном языке никак, то интерфейсы (Go или Rust, не Java или C++). Эти концепции позволяют значительно лучше разделить данные с кодом и обеспечить более просто тестирование системы.
Это не про скорость. CAF>>Ну некоторые, конечно, пишут класс для инкремента. Но как это влияет на производительность настолько?
KP>Паттерны вводят довольно большое количество вспомогательных сущностей, зачастую для замены одного простого if/else. Фабрика для одного/двух объектов? Даа! Мы же на Java пишем, вдруг потом (говорить с придыханием) мы захотим расширить систему? И когда такое "вдруг" начинает пронизывать всю систему, она, почему-то, начинает медленно работать
А если перебора такого нет. То как влияет? Можно пример?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Gradiens, Вы писали:
G>>И вопрос (ну просто один из вопросов который приведен навскидку для того, чтобы проиллюстировать мой субъективный подход) был в том, что произойдет если исключение будет выброшено из Dispose и что изменится если исключение будет выброшено из финализатора.
S>Если искл. в финализаторе, то срубит приложение. Если Dispose, то смотря какой поток будет его вызывать.
Ну вот, хороший лаконичный ответ. Можно, понятное дело, копать глубже, но я бы на месте интервьювера перешел к другим вопросам.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>А если перебора такого нет. То как влияет? Можно пример?
KP>Нет? Это как нет? Должно быть как-то так.
А где оценка производительности? Выглядит плохо, но как влияет?
Ну выполняется там в глубине критический кол, оптимизированный jit а почему расходы большие?
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>А где оценка производительности? Выглядит плохо, но как влияет? CAF>Ну выполняется там в глубине критический кол, оптимизированный jit а почему расходы большие?
Да вроде это очевидно. В Java практически всё (или вообще всё? не уверен) является объектом. Весь этот громадный стек ни что иное как нагромождение разных объектов. И каждый объект где-то лежит, его создали, его время жизни отслеживается. Всё это не бесплатно, и расходует память и процессорное время. Ты пытаешься сказать что это не имеет знание?
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>А где оценка производительности? Выглядит плохо, но как влияет? CAF>>Ну выполняется там в глубине критический кол, оптимизированный jit а почему расходы большие?
KP>Да вроде это очевидно. В Java практически всё (или вообще всё? не уверен) является объектом. Весь этот громадный стек ни что иное как нагромождение разных объектов. И каждый объект где-то лежит, его создали, его время жизни отслеживается. Всё это не бесплатно, и расходует память и процессорное время. Ты пытаешься сказать что это не имеет знание?
Хорший вопрос. А в этом дело? Вызовы инлайнятся. Или io или ждут на мониторе?
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Хорший вопрос. А в этом дело? Вызовы инлайнятся. Или io или ждут на мониторе? CAF>>Может пишут тяп-ляп просто?
KP>Не, так скучно. Ты прав, никакой разницы, всем насрать
А разница большая ...
S>>Если не ошибаюсь, то финализатор вызывет Dispose, если он есть, есть ли нет -- то деструктор ~MyClass{} A>~MyClass{} — это и есть финализатор, деструкторов в c# нет. dispose никто сам ниоткуда не вызывает, ты должен делать это руками (если нужно, а нужно не всегда).
Здравствуйте, SkyDance, Вы писали:
G>>Но наверно тяжело делать это в ходе интеревью, не так ли? SD>Поэтому я и спрашиваю: в чем смысл задавать такой вопрос на интервью? Если ответ легко нагуглить вне интервью, его нет смысла задавать на интервью, потому что когда человек с таким вопросом встретится, он просто нагуглит ответ.
Вопрос, впринципе, нормальный, чтобы понять как человек глубоко копал не сколько даже практику, а теорию. Если не ответит, значит нужно попроще, иначе -- посложнее.
Здравствуйте, kaa.python, Вы писали:
CAF>>А где оценка производительности? Выглядит плохо, но как влияет? CAF>>Ну выполняется там в глубине критический кол, оптимизированный jit а почему расходы большие?
KP>Да вроде это очевидно. В Java практически всё (или вообще всё? не уверен) является объектом. Весь этот громадный стек ни что иное как нагромождение разных объектов. И каждый объект где-то лежит, его создали, его время жизни отслеживается. Всё это не бесплатно, и расходует память и процессорное время. Ты пытаешься сказать что это не имеет знание?
Ну и что? Что, в C++ нет обьектов? Или в C нет обьектов? Спринг конечно зло, но это не повод винить паттерны проектирования. Избыток абстракций, может быть более подходящие паттерны решили бы проблему лучше. Подход Clojure как раз подкупает, что изящное решение там, где на ооп со спрингом ад. Но причём тут паттерны? Те, что GoF, так это костыли для OOP чтобы изобразить то, что на FP из коробки.
Тут в треде собралось несколько OOP прогеров с претензией "паттерны зло. а зачем их вообще знать". Да, и сортировку знать не надо- пузырек сойдет Так и получается, что весь код тормозит, неважно написали его на непремиальной жаве, ультра быстром (в эротических фантазиях фанатов) сипипи, или хипстерском эрланге (когда он лезет в лок на каждый чих).
Здравствуйте, kaa.python, Вы писали:
KP>>>Да и DI ваше тоже говно, зависимости надо передавать явно.
S>>А можно развернуть, что тут не так?
KP>Ну даже не знаю... Может быть то, что мы говорим про DI?
Dependency injection is one form of the broader technique of inversion of control.
В настоящее время, когда говорят IoC, подразумевают инжектор. Но суть в том, что DI Framework "автомагически" инициализирует зависимости-сервисы в правильной последовательности. Эти сервисы создаются в единствененом экземпляре на инжектор, т.е. это синглтон в пределах экземпляра инжектора.
Чувакам с C++, налепившим пачку синглтонов в пределах процесса, и не знакомых с DI, лучше открыть для себя этот самый DI.
Здравствуйте, SkyDance, Вы писали:
L>>А ты сам-то знаешь, как? (С прищуром) SD>(с еще большим прищуром) а ты? SD>Я несколько лет назад думал, что знаю, а вот сейчас, научившись, уже... не уверен.
Мне вот всегда было интересно когда такое спрашивают про синглтоны — что именно ожидают в ответ? Простое "закрыть локом" ведь не проканает же? Например, я вбил это в гугл — получил ответы про яву, где никаких локов нет, потому что оии где то внутри классов явы зарыты.
$>В настоящее время, когда говорят IoC, подразумевают инжектор. Но суть в том, что DI Framework "автомагически" инициализирует зависимости-сервисы в правильной последовательности. Эти сервисы создаются в единствененом экземпляре на инжектор, т.е. это синглтон в пределах экземпляра инжектора.
$>Чувакам с C++, налепившим пачку синглтонов в пределах процесса, и не знакомых с DI, лучше открыть для себя этот самый DI.
Мне без разницы. Все зависимости надо определять и передавать явно.
А кому-то стоит сменить ник на нормальный, чтобы цитирование нормально выглядело.
Здравствуйте, aik, Вы писали:
aik>Мне вот всегда было интересно когда такое спрашивают про синглтоны — что именно ожидают в ответ? Простое "закрыть локом" ведь не проканает же? Например, я вбил это в гугл — получил ответы про яву, где никаких локов нет, потому что оии где то внутри классов явы зарыты.
Насколько помню, в C++11 и выше можно ограничиться обычной статической переменной так как гарантируется её атомарная инициализация. Компилятор барьеры напихает в код всё будет пучком.
$>Ты так гордишься, что булькаешься в "проектах с историей на плюсах".
Не знаю, что такое "булькаешься".
Но так уж выходит, что за "проекты с историей" сейчас очень неплохо платят
$>На самом деле конечно, есть проекты где на плюсах и с паттернами всё нормально. Просто ты в такие компании с твоим отношением к этой тематике не пройдешь.
Здравствуйте, SkyDance, Вы писали:
S>>Вопрос, впринципе, нормальный, чтобы понять как человек глубоко копал не сколько даже практику, а теорию. Если не ответит, значит нужно попроще, иначе -- посложнее. SD>Это не "попроще" и "посложнее". Это просто показывает, делал ли человек что-то с этим связанное относительно недавно (так что еще не успел забыть). Для программиста это не главное.
Не соглашусь. Быть может ищут действительно сильного программиста, которые такие детали должен знать. Ну вот нужен сильный программист .net. И если человек
такие вещи не знает, то это уже звонок. Сложная кодовая база, нужно писать новый функционал и т.д. Такие люди иногда нужны.
SD> А главное то, что программист может такую информацию найти на короткое время. Именно это и следует смотреть на собеседовании. Не то, что программист недавно делал (и потому помнит), а то, как он способен разобраться в задаче, которую он еще не делал.
Ну знаете ли, с таким подходмо навыки программирования вообще не нужны. Нагуглит. Глваное, чтобы умел искать инф-ию.
SD>Поэтому я считаю задачу "найти и исправить проблемы в говнокоде" — жизненной. Ибо это как бы не 90% реальности, данной нам в офисе.
Увы, похоже это так. Но код разный бывает. Бывает сложная кодовая база, где используется много продвинутых вещей, знать которые необходимо,
чтобы править и читать.
Здравствуйте, kaa.python, Вы писали:
KP>Мне без разницы. Все зависимости надо определять и передавать явно.
Это в FP ты можешь передать функцию с замыканием. А в OOP нужно работать на его принципах, но паттены OOP спасают.
KP>А кому-то стоит сменить ник на нормальный, чтобы цитирование нормально выглядело.
Так это баг в цитировании.
Здравствуйте, kaa.python, Вы писали:
aik>>Мне вот всегда было интересно когда такое спрашивают про синглтоны — что именно ожидают в ответ? Простое "закрыть локом" ведь не проканает же? Например, я вбил это в гугл — получил ответы про яву, где никаких локов нет, потому что оии где то внутри классов явы зарыты. KP>Насколько помню, в C++11 и выше можно ограничиться обычной статической переменной так как гарантируется её атомарная инициализация. Компилятор барьеры напихает в код всё будет пучком.
Вот что то сомневаюсь что этот ответ активный зачтёт как правильный. Как барьеры помогут если 2 потока одновременно пытаются инициализировать одну переменную?
Здравствуйте, aik, Вы писали:
KP>>Насколько помню, в C++11 и выше можно ограничиться обычной статической переменной так как гарантируется её атомарная инициализация. Компилятор барьеры напихает в код всё будет пучком.
aik>Вот что то сомневаюсь что этот ответ активный зачтёт как правильный. Как барьеры помогут если 2 потока одновременно пытаются инициализировать одну переменную?
https://en.m.wikipedia.org/wiki/Double-checked_locking
У C++ 11 появилась фича. У Oracle JVM неофициально похожая техника (основанная на гарантии атомарности загрузки Class-а) работает, но например у андроида не работала.
Здравствуйте, aik, Вы писали:
aik>Вот что то сомневаюсь что этот ответ активный зачтёт как правильный. Как барьеры помогут если 2 потока одновременно пытаются инициализировать одну переменную?
Без понятия. Но вот стандарт:
such a variable is initialized the first time control passes through its declaration; such a variable is considered initialized upon the completion of its initialization. [...] If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.
Здравствуйте, $$, Вы писали:
aik>>Вот что то сомневаюсь что этот ответ активный зачтёт как правильный. Как барьеры помогут если 2 потока одновременно пытаются инициализировать одну переменную?
$>https://en.m.wikipedia.org/wiki/Double-checked_locking
$>У C++ 11 появилась фича. У Oracle JVM неофициально похожая техника (основанная на гарантии атомарности загрузки Class-а) работает, но например у андроида не работала.
Здравствуйте, $$, Вы писали:
aik>>Какой ответ то правильный на собеседовании?
$>Безопасный- рассказать про паттерн, И потом добавить, что можно ещё проще. А вдруг интервьювер не знает или принципиальный (про трюк с Class loading).
Напомню, вопрос звучит как "По синглтону есть хороший вопрос- как его реализовать для многопоточки". Что именно надо "рассказать про паттерн" чтоб пройти дальше?
Здравствуйте, aik, Вы писали:
aik>Напомню, вопрос звучит как "По синглтону есть хороший вопрос- как его реализовать для многопоточки". Что именно надо "рассказать про паттерн" чтоб пройти дальше?
Рассказать, как его реализовать для многопоточки
Если кандидат дремучий, он влепит лок. Достойный скажет, что надо вот с таким паттерном (вспомнит название) или как питон, расскажет про стандарт C++ 11.
Хотя тут можно прямо попросить рассказать и написать псевдокод про double check locking.
L>>
$>Вопрос архи сложный, понимаю. Уровня Страуструпа, не меньше.
Удивляет не вопрос, а отсутствие четких критериев правильного ответа на изначально размытый вопрос. "Правильный ответ: A или B, а потом C" — "а если сразу отвечу C?" — "незачот".
Здравствуйте, aik, Вы писали:
aik>Удивляет не вопрос, а отсутствие четких критериев правильного ответа на изначально размытый вопрос. "Правильный ответ: A или B, а потом C" — "а если сразу отвечу C?" — "незачот".
Я вот не понимаю тебя. Задан вопрос, как реализовать синглтон для многопоточки. Это что, какая-то экзотика? Ведь жизненная задача.
Простой вопрос, а сколько вещей о кандидате можно узнать.
UPD если ты про использование трюка с загрузкой класса в жаве, то когда мне задавали этот вопрос, интервьювер просто "вываливался" и не воспринимал трюк. Они все, кто задавал, ожидали стандартного ответа. Поэтому самое безопасное, это не выпендриваться, а сначала дать банальный ответ, потом добавить "экстра".
Здравствуйте, Sharov, Вы писали:
L>>Ответ по ссылке подходит тактически. Но стратегически он неправильный. S>В том плане, что стратегически надо синглтонов избавляться?
Для Артемки это пока слишком сложно.
Но даже если не рассуждать стратегически, то вот такой вопрос
Здравствуйте, $$, Вы писали:
aik>>Удивляет не вопрос, а отсутствие четких критериев правильного ответа на изначально размытый вопрос. "Правильный ответ: A или B, а потом C" — "а если сразу отвечу C?" — "незачот".
$>Я вот не понимаю тебя. Задан вопрос, как реализовать синглтон для многопоточки. Это что, какая-то экзотика? Ведь жизненная задача.
Я без понятия — ты от ответа уклоняешься. Я б и "double check locking" засчитал, но ты то явно чего то совсем другого ждешь.
Здравствуйте, aik, Вы писали:
aik>Я без понятия — ты от ответа уклоняешься. Я б и "double check locking" засчитал, но ты то явно чего то совсем другого ждешь.
Я сам ещё не задавал такой вопрос, но мне и при мне его задавали. Ожидался double check locking.
Здравствуйте, $$, Вы писали:
aik>>Я без понятия — ты от ответа уклоняешься. Я б и "double check locking" засчитал, но ты то явно чего то совсем другого ждешь.
$>Я сам ещё не задавал такой вопрос, но мне и при мне его задавали. Ожидался double check locking.
Здравствуйте, aik, Вы писали:
aik>Но сам ты такой ответ не примешь. Я в тупике.
Не приписывай мне, что я не говорил.
Я лишь дал совет, как безопаснее отвечать на этот вопрос- начать с double check locking, и перечислить другие способы.
Здравствуйте, SkyDance, Вы писали:
SD>Не только от синглтонов, но и в целом от "внезапно инициализирующихся данных". Как правильно заметил landerhigh, зависимости должны быть явными (explicit).
Здравствуйте, landerhigh, Вы писали:
SD>>>Не только от синглтонов, но и в целом от "внезапно инициализирующихся данных". Как правильно заметил landerhigh, зависимости должны быть явными (explicit). L>$>Наличие lazy loading зависит от требований.
L>Lazy loading и явные зависимости — совершенно ортогональные понятия.
Зато double checked locking, "внезапно инициализирующихся данных" и lazy loading- связанные понятия.
Здравствуйте, $$, Вы писали:
L>>Lazy loading и явные зависимости — совершенно ортогональные понятия.
$>Зато double checked locking, "внезапно инициализирующихся данных" и lazy loading- связанные понятия.
Здравствуйте, landerhigh, Вы писали:
L>>>Lazy loading и явные зависимости — совершенно ортогональные понятия. L>$>Зато double checked locking, "внезапно инициализирующихся данных" и lazy loading- связанные понятия.
L>Essence of govnokod...
Об этом нужно говорить в философии.
Пока что у меня получается такая картина:
И: перечислите паттерны проектирования, какие вспомните
L: ....
через 30 секунд
L: ...... нууууу
L: Фабрика?
И: хорошо, хорошо. Ещё вспомните? (думает про Builder)
L: Синглтон?
И: Ай молодец!
L: Но я слышал, что Синглтон это такое страшное зло. Антипаттерн. сам SkyDance писал (думая про лок в БД)
И: (думая про DI)- ок, вот вы работали с многопоточкой.
L: о дааа, я работал с многопоточкой
И: А напишите ка, голубчик, синглтон для многопоточки, на доске
L: (берет маркер, сразу пишет лок)
И: Ок, это будет работать. Какие проблемы здесь видите?
L: ....... (слышно скрежет заржавевших шестеренок и видно мучительное напряжение на лице)
И: цена захода в лок велика. Как модно оптимизировать?
L: ....... проходит 5 минут
И: Поставьте переменную, проверяйте
L: поставил переменную, проверяет под локом
И: вы всё ещё под локом, а хотете избежать ненужного входа в лок. И кроме того, пометьте volatile
L: (лампочка тускло загорелась) проверяет не под локом, сохраняет под локом.
И: (смотрит на часы- за отведенный бюджет ни одного годного ответа, 2 вопроса не дождались очереди), — есть у вас вопросы?
L: ..... нет
И: Хорошо. Наша офис менеджер проводит вас до выхода.
Здравствуйте, $$, Вы писали:
L>>Essence of govnokod...
$>Об этом нужно говорить в философии.
$>Пока что у меня получается такая картина:
$>И: перечислите паттерны проектирования, какие вспомните
$>L: ....
Влажные мечты. В общем, ты доказал, что собеседовать специалистов тебе еще рано.
Ну и то, что дела в IT в Австралии уже идут так себе, тоже.
Ну ничего, лет через пять, может, вернусь на 400-500 в час. Приводить в чувство то, что наворотили специалисты по перевороту строк под руководством Артемки, у которого "Зато double checked locking, "внезапно инициализирующихся данных" и lazy loading- связанные понятия"
Здравствуйте, Lexey, Вы писали:
L>Внезапно, явная передача зависимостей — это тоже вариант DI. А говно — это DI через сервис-локаторы и подобную хрень.
Да, с этой точки зрения я что-то не подумал, ты прав.
Здравствуйте, sergey2b, Вы писали:
S>святой человек, а теперь представте у вас 200 кагдидатов а вам нуужен 1-2 сотрудника
Из этих 200 кандидатов сразу по резюме видно, что кандидат ни черта из себя не представляет вообще. Из 200 резюме, которые кинут HR на одобрение, реально имеет смысл приглашать максимум 10 человек. Из этих 10 человек оффер будет выдан двум. Если предложение будет хорошим, оффер примет один из них. Соответственно никаких проблем нет.
последнее я делал вчера, реализовал класс который реализует специальное число (не комплексное но +- похожее)
мне было интерстно сможет ли собеседуюший найти, что я не продумал
Здравствуйте, sergey2b, Вы писали:
S>последнее я делал вчера, реализовал класс который реализует специальное число (не комплексное но +- похожее) S>мне было интерстно сможет ли собеседуюший найти, что я не продумал
Выглядит просто. Imho такие задания- самые опасные: они не составляют труда.
Будет докапываться к комментариям, к названиям переменных, наличию юнит тестов, но не проверять наличие мозга.
$>Здравствуйте, sergey2b, Вы писали:
S>>последнее я делал вчера, реализовал класс который реализует специальное число (не комплексное но +- похожее) S>>мне было интерстно сможет ли собеседуюший найти, что я не продумал
$>Выглядит просто. Imho такие задания- самые опасные: они не составляют труда.
$>Будет докапываться к комментариям, к названиям переменных, наличию юнит тестов, но не проверять наличие мозга.
Например надо было детектировать переполнение
И по возможности исправить ситуацию
Ещё репу пришлось почесать при реализации template
Здравствуйте, sergey2b, Вы писали:
S>>>последнее я делал вчера, реализовал класс который реализует специальное число (не комплексное но +- похожее) S>>>мне было интерстно сможет ли собеседуюший найти, что я не продумал
S>$>Выглядит просто. Imho такие задания- самые опасные: они не составляют труда.
S>$>Будет докапываться к комментариям, к названиям переменных, наличию юнит тестов, но не проверять наличие мозга.
S>Например надо было детектировать переполнение
Про это я не подумал Вот видишь, насколько опасны такие домашние задания. Ну и по UT можно пройтись, проверить что ты покрыл все corner case.
S>Ещё репу пришлось почесать при реализации template
В этом часть фана C++: создать себе сложности на простой задаче и мужественно преодолеть.
S>Но многопоточный синглатон всеравно лучше
Хватит троллить. Я уже понял, что для C++ до 11 это нетривиальная задача. А для некоторых так вообще неприличный вопрос. Причём, это вопрос на собеседовании- нет смысла его давать на дом.
$>Есть мысль давать домашнее задание кандидату перед техническим интервью. Сложное для интервью, но с элегантным решением и легко гуглящееся. А потом по результату порасспрашивать, как он/она сделал и почему.
бесполезная трата времени и своего и кандидата.
Если решение гуглится — то суть интервью проверить умеет ли кандидат гуглить, вы же ищете не Full StackOwerflow разработчика?
А элегантность решения — это ваше субъективное мнение, вы так будете искать разраба который думает примерно как вы, теме же разработчискими шаблонами. 80% за то, что вы отклоните кандидата, который решает задачки как программер-олимпиадник быстро, грубо и эффективно или кандидата который предложит решение выполняющую требования задания но используя совершенно иной продход.
Но скорее всего большенство действительно сильных и грамотных программистов после получения задания — забъют на него и на собеседование то же, так как есть предложения на рынке где не требуют решения ДЗ и ЗП выше.
$>Преследуемые цели:
$>- не устраивать экзамен
Хмммм...
прям представил себе: кандидат, тяните билет
Кстати. Надо на собеседовании над кандидатами поприкалываться.
Здравствуйте, ssp_alex, Вы писали:
_>Если решение гуглится — то суть интервью проверить умеет ли кандидат гуглить,
Если умеет самостоятельно нагуглить оптимальное решение и понять, такой по сути и нужен.
_>А элегантность решения — это ваше субъективное мнение
Это мое субьективное определение оптимального по времени и памяти и корректного для corner cases решения, на любом языке из длинного списка.
_>80% за то, что вы отклоните кандидата, который решает задачки как программер-олимпиадник
Задача отсеять кандидата, неспособного самостоятельно решить поставленную задачу.
_>прям представил себе: кандидат, тяните билет _>Кстати. Надо на собеседовании над кандидатами поприкалываться.
Нужно найти годных коллег, на которых
можно раскидать задачи.
$>Чувакам с C++, налепившим пачку синглтонов в пределах процесса, и не знакомых с DI, лучше открыть для себя этот самый DI.
Конечно это круто, но как ты собираешься прокидывать объект который нужен в разных компонентах? Тот же логер или сборщик телеметрии, например.
Здравствуйте, Kernan, Вы писали:
K>Конечно это круто, но как ты собираешься прокидывать объект который нужен в разных компонентах? Тот же логер или сборщик телеметрии, например.
$>The injector tracks the dependencies for each type and uses bindings to inject them. This is the core of Guice, although you rarely interact with it directly. This "behind-the-scenes" operation is what distinguishes dependency injection from its cousin, the service locator pattern.
$>
Ага, т.е. для service locattor'а я явно запрашиваю интерфейсы и потом конструирую объект,т.е. он выдает тип по интерфейсу, а DI конструирует объект без моего вмешательства, так?
$>DI инициализирует зависимости в правильной последовательности (привет топологическая сортировка) и передает их в конструктор. Единичные явные вызовы интерфейса- точка входа.
Правильная посл-ть задается сигнатурой конструктора, а вот что делать, если у нас два типа реализуют соотв. интерфейс? Как DI решит эту проблему?
Здравствуйте, Sharov, Вы писали:
S>$>DI инициализирует зависимости в правильной последовательности (привет топологическая сортировка) и передает их в конструктор. Единичные явные вызовы интерфейса- точка входа.
S>Правильная посл-ть задается сигнатурой конструктора,
S> а вот что делать, если у нас два типа реализуют соотв. интерфейс? Как DI решит эту проблему?
Поставить на соответствующий аргумент конструктора аннотацию с ключом для DI.
$>Дискас.
Самую тупую и унылую работу в офисе на полный день(с почасовой оплатой, по которой в удачный месяц выходило 40тр), я нашел сделав домашнее задание, а потом успешно пройдя трехчасовое собеседование с около 50 вопросами.
Опыта тогда было 4 года, срочно нужна была работа.
Как бы поступил сейчас, если бы мне дали домашнее задание?
Да просто! Тупо дал бы встречной задание. Я тоже хочу знать, с кем мне придется работать и что за говнокод меня ждет.
И, естественно, их задание не стал бы делать. Если только не пообещают мильены денег.
Мы предлагаем решить задачу на дому, срок не ставим, но по нашим оценкам, человеку с искомыми скилами хватит и часа для ее решения. Задача простая, "прикладная" без требований хитрых алгоритмов и прочих подговырок. Задача дается опционально "Для сокращения времени технического интервью мы можем дать вам задачу на дом." Но. Если человек, взявший решать ее, но не сделавший от слова совсем, отсеивается.
Пришедший с "готовым" решением на собеседовании проходит "Code Review". Задаем вопросы по тестовому покрытию, по производительности и т.п.
Какое-то время отказывались от задач на дому. Кандидаты приходили сильно слабее.
Здравствуйте, Gradiens, Вы писали:
G>Здравствуйте, $$, Вы писали:
G>$>Здравствуйте, Gradiens, Вы писали:
G>$>Спрашивать про аргументы методов imho моветон.
G>Конечно, спрашивать синтаксис — моветон. Кроме того, это абсолютно бесполезно. G>Конкретно в моем посте был вопрос про специфику работы деструкторов в .NET. Опытный разработчик должен понимать, что будет в случае брошенного в деструкторе исключения. А может быть, он даже ловил такие ситуации на практике. Это вопрос на понимание работы платформы. G>И опять-таки, это всего лишь пример. Я уверен, существуют вопросы получше ))
Вопросы такого рода как правило бесполезны (за несколькими исключениями).
Знание платформы (тем более таких gotcha вещей, которые к тому же не особо имеют значение, т.к. оставлять какую-то существенную логику в деструкторе это вообще моветон).
Это все существенно менее важно чем знание алгоритмов, структур данных и способности сдизайнить что-нибудь полезное.
В крупных компаниях людей нередко нанимают без знания определенной платформы, если человек толковый, у него займет несколько месяцев чтобы освоиться в любой платформе.
Исключения — это когда человек нанимается в небольшую компанию и/или стартап, где есть временные или финансовые ограничения, и нужно чтобы он эффективно работал с первого же дня.
Второе исключение — это когда человек берется на позицию типа тех лида в проекте, соотвественно от него ожидается очень хорошее понимание платформы.
Здравствуйте, VladiCh, Вы писали:
VC>Вопросы такого рода как правило бесполезны (за несколькими исключениями). VC>Знание платформы (тем более таких gotcha вещей, которые к тому же не особо имеют значение, т.к. оставлять какую-то существенную логику в деструкторе это вообще моветон).
Вот, этот вопрос как раз и провоцирует подобного рода беседу. VC>Это все существенно менее важно чем знание алгоритмов, структур данных и способности сдизайнить что-нибудь полезное. VC>В крупных компаниях людей нередко нанимают без знания определенной платформы, если человек толковый, у него займет несколько месяцев чтобы освоиться в любой платформе. VC>Исключения — это когда человек нанимается в небольшую компанию и/или стартап, где есть временные или финансовые ограничения, и нужно чтобы он эффективно работал с первого же дня.
По моему опыту — как раз наоборот.
В стартапе нужно быть "и швец и жнец и на дуде игрец". Нужно, чтобы толковый человек умел быстро разбираться на поверхностом уровне с разными технологиями, мог бы скрестить ужа с ежом и занять рынок получившейся колючей проволокой.
А в больших и стабильных компаниях ищут людей на конкретный стек и/или конкретную предметную область.
Вот зачем большой компании брать джависта и переучать его в дотнетчика или наоборот, дотнетчика в джависта? Проекты пилятся годами, резкие изменения маловероятны, и многолетний опыт на стеке является важнейшим фактором при найме.
Если человек толковый, то через пару месяцев он, конечно, освоится. Но все равно его трудоспособность будет много меньше тех, кто работает с платформой годами. На полную мощность человек выйдет +- через год. Ну, и зачем компании его нанимать, если на рынке есть такие же кандидаты, только с опытом на нужном стеке?
Кроме того, структуры данных и алгоритмы явно переоценены. В большинстве мест хватит базовых знаний. То есть понимать алгоритмическую сложность конечно надо, знать как использовать имеющиеся в фреймворке списки, хеш-таблицы надо, но уметь реализовывать 100500 алгоритмов сортировки и вращать деревья — нафиг.
Я за 15 лет ни разу не встретился с необходимостью реализации какого-то классического алгоритма. Все уже украдено написано до нас, проще использовать существующее.
Зато много раз сталкивался с тормозами, где тупо грабли в виде O(n^2) вместо O(n). И для исправления знания алгоритмов как-то не особо нужны. Нужно просто самые базовые знания. А также сталкивался с разными вещами типа съедания приложениям памяти, связанным, например, с тем, что "куча" растет из-за "больших" объектов и после сборки мусора не дефрагментируется. Или с тем, что многопоточное приложение тупит не из-за плохих алгоритмов, а из-за сборки мусора, потому что происходит масса аллокаций памяти. И надо не искать более эффективный алгоритм, а тупо переписать без аллокаций памяти.
Я вот думаю, если меня перекинуть на джаву, код я смогу писать с первого дня. А вот разгребать вышеописанные проблемы — вряд ли. Наоборот, без достаточного опыта я их только создам.
VC>Второе исключение — это когда человек берется на позицию типа тех лида в проекте, соотвественно от него ожидается очень хорошее понимание платформы.
И тут, я считаю, все наоборот.
Ну, то есть тех лид безусловно должен знать свой огород, но также должен быть технически разносторонне развитым. Чтобы принимал взвешенные стратегические решения, а не использовал молоток для забивания шурупов только потому, что молоток — его любимый инструмент.
$>Есть мысль давать домашнее задание кандидату перед техническим интервью. Сложное для интервью, но с элегантным решением и легко гуглящееся. А потом по результату порасспрашивать, как он/она сделал и почему.
$>Преследуемые цели:
$>- не устраивать экзамен
$>- дать шанс освежить в памяти базовые структуры данных. Чтобы не было неожиданностью требование знать bigO notation.
$>Дискас.
Я тут начал такой эксперимент: первый созвон на 20-30 минут — за жизнь, за опыт, про технологии в целом. А дальше — явно спрашиваю у кандидата что он предпочитает — поупражнятся с задачками/дизайном или взять задание на дом, а потом созвониться и обсудить решение/код итп. Пока народ выбирает задание на дом! Задание на дом стараюсь выбрать приближенное к проблемам которые мы решаем, на несколько часов работы, +-.
C опытными спецами с релевантным опытом такое не нужно, это больше для молодежи или "универсальных солдатов".
Здравствуйте, Faland, Вы писали:
F>C опытными спецами с релевантным опытом такое не нужно, это больше для молодежи или "универсальных солдатов".
Это про булькавшихся в болоте устаревших технологий годами, ничего более ниасиливших? Если на поддержку кала мамонта, наверное разумно- нормальный программист заскучает и свалит с такого.
$>Здравствуйте, Faland, Вы писали: F>>C опытными спецами с релевантным опытом такое не нужно, это больше для молодежи или "универсальных солдатов".
$>Это про булькавшихся в болоте устаревших технологий годами, ничего более ниасиливших? Если на поддержку кала мамонта, наверное разумно- нормальный программист заскучает и свалит с такого.
Нет, cкорее так:
Пример: скажем, нам надо (Modern C++/video/streaming) человека. Можно просто сильный С++, если готов разобраться с видео по ходу дела.
Если апплаится чувак с хорошим реальным опытом (Modern C++ / Video) — будем спрашивать по С++ и предметной области. Если он варился в болоте и не развивался — вопросы по Modern C++ и современным видео технологиям быстро выявят правду.
Если апплаится "просто сильный С++, готов разобраться" — тогда надо погонять немного, чтобы понять — а сможет ли разобраться. Ну и к общепрограммистским скиллам уже требования повыше, чтоб скомпенсировать отсутствие доменной экспертизы.
А вообще, не все же сервисы для сайтиков клепают, полно областей где требуется не один год чтоб действительно понимать всю систему и быть способным что-то серьезно менять.
Я например на проекте 4 года, только недавно достиг такого понимания которое позволяет менять архитектуру, переписывать какие-то части полностью итп.
Во многом конечно из-за легаси-говнокода изначального, накуевертили больше миллиона строк на четырех языках, но если бы все писали качественно сначала — проект бы не выстрелил вовремя и текущего отдела вообще бы не было...
Здравствуйте, Faland, Вы писали:
F>А вообще, не все же сервисы для сайтиков клепают, полно областей где требуется не один год чтоб действительно понимать всю систему и быть способным что-то серьезно менять.
Ох как высокомерно. Гугл и Яндекс, например,"сервисы для сайтиков клепает".
Суть вашего фильтра- давать предпочтение кандидатам с недавним опытом по используемым у вас технологиям.
У нас то же самое похоже что предварительный фильтр, а потом на собеседовании вопросы "на кодинг" ставят кандидатов в тупик. Очевидно, нормальных кодеров срезали ещё на просмотре резюме (без N лет опыта на такой-то версии ангулара и CSS).
F>Я например на проекте 4 года, только недавно достиг такого понимания которое позволяет менять архитектуру, переписывать какие-то части полностью итп. F>Во многом конечно из-за легаси-говнокода изначального, накуевертили больше миллиона строк на четырех языках, но если бы все писали качественно сначала — проект бы не выстрелил вовремя и текущего отдела вообще бы не было...
Это обычная история. Сначала непонятно, куда оно всё выедет и что полезно, а что нет.
$>Здравствуйте, Faland, Вы писали:
F>>А вообще, не все же сервисы для сайтиков клепают, полно областей где требуется не один год чтоб действительно понимать всю систему и быть способным что-то серьезно менять.
$>Ох как высокомерно. Гугл и Яндекс, например,"сервисы для сайтиков клепает".
Что-то мне подсказывает что те кто работу каждый год меняют в Гуглах-Яндексах не работают, а если и работали — ничего серьезного там сделать не успели. Да и не про то речь вообще, ты сам первый начал про "болото и сидение на одном месте помногу лет"
$>Суть вашего фильтра- давать предпочтение кандидатам с недавним опытом по используемым у вас технологиям.
$>У нас то же самое похоже что предварительный фильтр, а потом на собеседовании вопросы "на кодинг" ставят кандидатов в тупик. Очевидно, нормальных кодеров срезали ещё на просмотре резюме (без N лет опыта на такой-то версии ангулара и CSS).
При чем здесь определенные версии фреймворков? Речь идет про наличие и отсутствие доменной экспертизы. Но на онсайте код пишут все, если что.
Здравствуйте, Faland, Вы писали:
F>Что-то мне подсказывает что те кто работу каждый год меняют в Гуглах-Яндексах не работают, а если и работали — ничего серьезного там сделать не успели. Да и не про то речь вообще, ты сам первый начал про "болото и сидение на одном месте помногу лет"
Это про мои наблюдения.
F>При чем здесь определенные версии фреймворков? Речь идет про наличие и отсутствие доменной экспертизы. Но на онсайте код пишут все, если что.
Опыт свежего C++, про который ты упомянул, ничего общего с предметной областью не имеет. Из моих наблюдений- поставили вопросы по CSS- в результате десктопных гуевщиков, если такие ещё не вымерли, отсеет.
