Comments 50
ИМХО один из самых главных скилов разработчика — умение поставить себя на место другого. В чем проблема ставить себя на место работодателя? Не так хорошо развит навык?
Тороговцев специально учат: «Не пытайтесь выдумывать за человека, чего он хочет — наверняка ошибётесь».
В психологии есть понятие "проекции".
Если разработчик не имеет соответствующего опыта другой стороны, то предсказать её поведение у него хорошо не получится. И эта статья как раз проясняет дела для автора той статьи и других людей.
В психологии есть понятие "проекции".
Если разработчик не имеет соответствующего опыта другой стороны, то предсказать её поведение у него хорошо не получится. И эта статья как раз проясняет дела для автора той статьи и других людей.
99% людей не понимаю что и как может компьютер, поэтому конкретно для разработчика выдумывать нормально (смотря на работу человека). Возможно я не прав насчет работодателя.
Если бы я спросил у покупателей, что им нужно, они бы сказали: „Более быструю лошадь“
Вопрос не в том, чтобы принять решение за работодателя. А втом, чтобы предложить решение, которое могло бы быть лучше (или потом согласиться с решением).
Из личного опыта, есть программисты, которые будут тупо кодить что написано в требованиях, даже не подумав что это полная ерунда. Ведь бывает, что аналитик просто ошибся, или не до конца знает детали,… ИМХО — это не очень хорошие программисты.
Все от критериев и бизнес-модели зависит, увы. Если менеджер отвечает за делание разовых аутсорс проектов на фикс прайсе, которые получены по субподряду от более успешных аутсорсеров, то для него это не то, чтобы очень хороший программист, а просто лучший. Да, могут вопросы к менеджеру, почему он так себя не уважвет, что таким занимается, но это уже выходит за рамки поста и обсуждения.
Человек «хочет» и «у человека есть потребность» — это разное. Из классики, собственно. Пользователи упорно «хотят», что бы форма загружалась быстрее. Она не может загружаться быстрее по объективным причинам, но пользователи ХОТЯТ. После общения и выяснения причины этой хотелки выясняется, что на этой форме, среди всего прочего тяжеловесного хлама, есть очень маленький, но очень часто нужный чекбокс. То есть «потребность» вовсе не в быстрой загрузке формы, а в быстром доступе к чекбоксу. Продублировали чекбокс на другой более легковесной форме, и хотелка исчезла сама-собой.
Но что с другой стороны? Баги, связанные с алгоритмической сложностью, одни из самых неприятных для бизнеса.
Вы делаете всё ту же ошибку, что и яростные защитники big O в комментариях к прошлой статье: низкая производительность != высокая алгоритмическая сложность.
Для бизнеса проблемой является первое, но никак не второе. Иногда низкая производительность вызвана именно алгоритмами с плохой сложностью, а иногда — совсем даже не ими. Иногда проблема в законах физики (задержки в 300-400ms при передаче данных в противоположную точку земного шара неизбежны), иногда в железе (можно сказать, что алгоритмы виноваты уже и тут, но так глубоко копать вы скорее всего не захотите), иногда — в данных (формирование XML и JSON с точки зрения алгоритмической сложности примерно одинаково, а вот итоговый размер данных может быть очень сильно разным), иногда — в применении инструментов не по назначению (это исследуется с точки зрения big O, но более продуктивно будет всё-таки использовать инструмент по назначению).
Я думаю, посыл автора был в том, что именно низкую производительность можно отловить тестами, условно, вида «нам надо обрабатывать Х операций в секунду, тест на Х проходит, у нас все ОК». В то же время, если ожидается рост, особенно взрывной, нужно понимать, как будет расти функция необходимых ресурсов в зависимости от функции роста Х
UFO just landed and posted this here
А что остаётся делать, если все остальные уволились?
вы будете смеяться, но это бывает гораздо чаще именно там, где этот проект не имеет не только тестов и тестового сервера, но еще и никого из разработчиков кроме вас, а в особо запущенных случаях — вообще без системы версионирования (т.е. вы все ваши изменения сразу в проде и делаете, возможно — предварительно заархивировав текущую рабочую структуру файлов, если на диске есть еще свободное место).
PS: однажды был у меня случай, когда уволили со скандалом одного «бизнес аналитика» — код на проде отличался от кода в репозитории (скрипты tcl\tk), никого из разрабов больше нет, вот это был интересный проект!
PS: однажды был у меня случай, когда уволили со скандалом одного «бизнес аналитика» — код на проде отличался от кода в репозитории (скрипты tcl\tk), никого из разрабов больше нет, вот это был интересный проект!
Был у мужика огромный алмаз, и захотел он его огранить, но ни в одной ювелирной мастерской за это не брались, уж очень велика была цена ошибки. Мужик уже совсем отчаялся, но тут ему посоветовали обратится к старому Рабиновичу — если и он не возьмется, значит никто. Пришел мужик в мастерскую к Рабиновичу, показал старому еврею камень, объяснил проблему. Рабинович покивал, мол да, работа сложная, потом позвал подмастерье:
— Изя, сделай дяде камушек.
Мужик в шоке, как так, такой камень за который не взялись лучшие ювелиры, и — подмастерью! Рабинович в ответ:
— Это ви знаете, что камушек сложный, это я знаю, что камушек сложный. А Изя не знает, он сделает.
— Изя, сделай дяде камушек.
Мужик в шоке, как так, такой камень за который не взялись лучшие ювелиры, и — подмастерью! Рабинович в ответ:
— Это ви знаете, что камушек сложный, это я знаю, что камушек сложный. А Изя не знает, он сделает.
от хорошего программиста в продуктовой разработке часто ожидают эффективного решения всех вышеупомянутых задач.
ну наверное кто-то ожидает, но во-первых, это не значит что это так должно быть, а во-вторых, первые три требования они на самом деле про одно и то же — про читаемый и поддерживаемый код, который как раз и нужно увидеть на собесе (3-й пункт реализуем иммено в том случае когда код нормальный, иначе это лотерея), 4-й пункт это про адекватность, а не про код — нормальный человек понимает что такое разовая задача, хотя давать такие задачи стоит только джуниорам если не хотите терять спецов. 5-й — опять же разовая задача, но для опытного и толкового, который может также не помнить ничего про сложность конкретных алгоритмов, нагалит и решит.
Баги, связанные с алгоритмической сложностью, одни из самых неприятных для бизнеса.
но это не значит что человек должен поняить наизусть сложность всего и вся, он должен знать о самом понятии сложности.
Сюда же относятся и вопросы про ACID
точно также нет нужны помнить расшифровку, надо значить что уровня изорляции бывают разные (не нужно помнить наизусть) и что из этого следует.
Они могут ждать своего часа годами, не напоминая о себе,
Вот когда появятся, тогда их и нужно будет решать, разве нет? Это же пресловутая преждевременная оптимизация.
Ну, вообще говоря, про букву I в ACID вполне есть о чем поговорить на собеседовании.
По пониманию того, как происходит конкурентный доступ в базе данных люди делятся примерно на 3 уровня:
1. «Оно происходит как-то само магически и повлиять на это мы не можем». Если начать допытываться: «А как вы думаете, все-таки как там это сделано?», то можно услышать много интересного. Например «Так а на уровне базы данных нет никакого конкурентного доступа, там все запросы выстраиваются в очередь и выполняются друг за другом» или «Ну, наверное там внутри есть большой мьютекс, который предохраняет данные от порчи». Хотелось бы сказать, что это уровень джуниоров, но, к сожалению…
2. «Оно происходит как-то само магически, но мы можем на это повлиять, если будем использовать правильные заклинания и не будем использовать запретные слова». В категорию запретных слов периодически попадают: триггеры, внешние ключи, джойны. В категорию добрых заклинаний: конечно же «Добавить индексов», но и иногда что-нибудь типа «Отключить транзакции». Тут, в зависимости от набора заклинаний человек может некоторое время мимикрировать под грамотного разработчика, но иногда заклинания устаревают или бывают абсурдными с самого начала.
3. «Я понимаю на высоком уровне, что там происходит и знаю как на это повлиять». Это уже системный подход и сложно себе представить, чтобы человек на этом уровне не смог рассказать о такой базовой вещи, как ACID
В идеальном мире, мне бы хотелось, чтобы с моими деньгами/заказами/данными работали только специалисты 3-его уровня…
По пониманию того, как происходит конкурентный доступ в базе данных люди делятся примерно на 3 уровня:
1. «Оно происходит как-то само магически и повлиять на это мы не можем». Если начать допытываться: «А как вы думаете, все-таки как там это сделано?», то можно услышать много интересного. Например «Так а на уровне базы данных нет никакого конкурентного доступа, там все запросы выстраиваются в очередь и выполняются друг за другом» или «Ну, наверное там внутри есть большой мьютекс, который предохраняет данные от порчи». Хотелось бы сказать, что это уровень джуниоров, но, к сожалению…
2. «Оно происходит как-то само магически, но мы можем на это повлиять, если будем использовать правильные заклинания и не будем использовать запретные слова». В категорию запретных слов периодически попадают: триггеры, внешние ключи, джойны. В категорию добрых заклинаний: конечно же «Добавить индексов», но и иногда что-нибудь типа «Отключить транзакции». Тут, в зависимости от набора заклинаний человек может некоторое время мимикрировать под грамотного разработчика, но иногда заклинания устаревают или бывают абсурдными с самого начала.
3. «Я понимаю на высоком уровне, что там происходит и знаю как на это повлиять». Это уже системный подход и сложно себе представить, чтобы человек на этом уровне не смог рассказать о такой базовой вещи, как ACID
В идеальном мире, мне бы хотелось, чтобы с моими деньгами/заказами/данными работали только специалисты 3-его уровня…
UFO just landed and posted this here
Требование экстенсивного расширения противоречит требованию собирания команд senior уровня.
Все так. Экстенсивное расширение исключительно синиорами — это идеальная картина. В реальности надо идти на компромиссы. Увы, даже пылесос не всегда работает, — многие из тех, на кого он направлен, уже давно уехали в Европу или США.
Если у вас в команде уже есть спецы, то почему бы не взять способных кандидатов, даже если они подходят по-вашему подо все требования?
Если крупными мазками, то мое видение в плане набора программистов очень близко с видением, описанным тут. Перспективных и сообразительных тоже растил, и успешно. Но, сейчас понимаю, что, увы, вариант «медленно задорого и с диким скрипом искать лучших» в долгосроке оказывается даже более быстрым, ведь, при выходе на работу человек сразу начинает выдавать почти пиковый для себя велью без отвлечения коллег (в альтернативных стратегиях до достижения пикового результата надо значительно инвестировать ресурс более опытных коллег + принудительно понижать сложность кода всего репозитория, что можно читать, как использовать мозги членов всей команды на меньший %).
Только одно собеседование кардинально выделялось из общей массы, разговор шел тет-а-тет с техдиром, он распросил с какими технологиями я работал, а потом мы разговаривали про различные проблемы на их проекте и на моих прошлых проектах, и как эти проблемы решались или можно решить.
Из опыта, крайне редко соискатель в состоянии что-то внятно рассказать о предыдущих проектах. Но если получается — да, бывает что сразу видно «надо брать».
То, что на сайте компании (или на аггрегаторе вакансий) доступна вакансия, не означает, что компания ищет одного человека в одну команду.
+1. Пару десятков человек наняли по одному описанию вакансии уже. Технологии и требования одинаковые, проекты похожие.
Глубина и детали
Есть ощущение, не подтверждённое экспериментально, но всё же, что человек который с одной стороны может а с другой хочет разобраться глубоко, будет лучшим программистом, чем тот, который не может и/или не хочет. Не обязательно в произвольно выбранном вопросе, но в какой-нибудь теме — можно взять то, что чаще всего указано в резюме.
Однажды мне коллега пожаловался что завалил собес из всего 3х вопросов. Один из которых «что такое fpie ?»
Меня эта история смутила. Но решив попробовать, оказалось что вопрос весьма репрезентативный. Если на вопрос кандидат четко знает и умеет рассказать, то и на все остальные он тоже ответит, да и работать будет эффективно (статистически доказано).
Если не отвечает, то собеседующему нужно оценивать множество других факторов или же просто подождать кандидата который ответит.
Т.е. я бы это назвал подобный отбор не по «необходимому», а по «достаточному» критерию. Иногда (если воронка кандидатов большая), такой отбор имеет смысл.
Меня эта история смутила. Но решив попробовать, оказалось что вопрос весьма репрезентативный. Если на вопрос кандидат четко знает и умеет рассказать, то и на все остальные он тоже ответит, да и работать будет эффективно (статистически доказано).
Если не отвечает, то собеседующему нужно оценивать множество других факторов или же просто подождать кандидата который ответит.
Т.е. я бы это назвал подобный отбор не по «необходимому», а по «достаточному» критерию. Иногда (если воронка кандидатов большая), такой отбор имеет смысл.
Real-world decision tree classifier, однако. Да ещё и с эффективным прунингом
Загуглил, теперь знаю, потратил 10 секунд. Так бы и сказали, что ASLR :)
Один из ключиков компилятора для генерации кода нечувствительного к адресу загрузки.
Нужен был еще со времен ДОСа для резидентных программ, кодогенерации для эксплойтов до сборки шаред библиотек, а так же необходим для работы некоторых санитайзеров. Может оказывать незначительное замедление кода.
Фактически ответ на этот вопрос показывает пересечение больших кластеров знаний, а именно:
— что бывает машинный код чувствительный и нечувствительный к перемещению
— как работает загрузчик операционной системы
— имел ли разработчик опыт работы с GNU тулчейном
— имел ли разработчик опыт сборки библиотек под GNU
— пользовался ли санитайзером для которого этот ключ необходим
— настраивал ли CI для всего этого
— насколько часто он это делал, что запомнил ключи компилятора
отсюда же можно сделать высоковероятные предположения что кандидат знает также другие ключи которые часто приходится знать, calling conversions, name mangling, несколько систем сборок, с десяток+ *никс программ командной строки…
PS когда то давно подобными вопросами были вопросы про многопоточность. Вроде как, если человек дорос до многопоточного кода, то и фундамент знаний у него серьезный. Но после того, как их начали спрашивать на каждом собеседовании, то ценность ответа — сильно девальвировала до «Обольшого».
Нужен был еще со времен ДОСа для резидентных программ, кодогенерации для эксплойтов до сборки шаред библиотек, а так же необходим для работы некоторых санитайзеров. Может оказывать незначительное замедление кода.
Фактически ответ на этот вопрос показывает пересечение больших кластеров знаний, а именно:
— что бывает машинный код чувствительный и нечувствительный к перемещению
— как работает загрузчик операционной системы
— имел ли разработчик опыт работы с GNU тулчейном
— имел ли разработчик опыт сборки библиотек под GNU
— пользовался ли санитайзером для которого этот ключ необходим
— настраивал ли CI для всего этого
— насколько часто он это делал, что запомнил ключи компилятора
отсюда же можно сделать высоковероятные предположения что кандидат знает также другие ключи которые часто приходится знать, calling conversions, name mangling, несколько систем сборок, с десяток+ *никс программ командной строки…
PS когда то давно подобными вопросами были вопросы про многопоточность. Вроде как, если человек дорос до многопоточного кода, то и фундамент знаний у него серьезный. Но после того, как их начали спрашивать на каждом собеседовании, то ценность ответа — сильно девальвировала до «Обольшого».
сильно девальвировала до «Обольшого»
И почему «Обольшое» не уважаете?) Да, сейчас его знает каждый второй, но вот держать его в голове в момент придумывания алгоритма, увы, могут не многие. Условно, я никогда не спрошу у кандидата «Что означает О большое?», но часто спрашиваю оценку сложности задачи после того, как обсудили решение. Или во время, если кандидат пошел ложным путем.
Хотя бы потому что О(1) для листа и О(1) для вектора это величины отличиющиеся на 2 и более порядка. И если поразмышлять «правильно» на тему О может 9 из 10 разработчиков, то ответить почему последовательный проход по листу оказался в 250 раз медленнее чем по вектору может 1 из 20.
т.е. я не знаю как можно собеседующему интерпретировать то, что человек может оценить сложность быстрой сортировки для лучшего и худшего случая в О нотации. Или как интерпретировать то, что он не знает или не вспомнит вообще эту сортировку (кроме того что недавно читал про неё или вчерашний студент)
т.е. я не знаю как можно собеседующему интерпретировать то, что человек может оценить сложность быстрой сортировки для лучшего и худшего случая в О нотации. Или как интерпретировать то, что он не знает или не вспомнит вообще эту сортировку (кроме того что недавно читал про неё или вчерашний студент)
Условно, я никогда не спрошу у кандидата «Что означает О большое?»
Эээм… Не понимая, что оно значит довольно проблематично оценивать сложность и понимать, что эта оценка значит.
В принципе, справедливо: вот я про position [in]dependent code и загрузчики знаю, но на C/C++ не писал уже лет 15 и ключики не помню (детали вообще быстро забываются, а вот основные принципы помнишь всегда). Так что если бы я решил тряхнуть стариной и переквалифицироваться обратно, меня бы сразу спалили, да :)
UFO just landed and posted this here
clang.llvm.org/docs/ThreadSanitizer.html
«Non-position-independent executables are not supported. Therefore, the fsanitize=thread flag will cause Clang to act as though the -fPIE flag had been supplied if compiling without -fPIC, and as though the -pie flag had been supplied if linking an executable.»
Пользовался ли «именно тем самым нечасто используемым» санитайзером для которого этот ключ необходим.
«Non-position-independent executables are not supported. Therefore, the fsanitize=thread flag will cause Clang to act as though the -fPIE flag had been supplied if compiling without -fPIC, and as though the -pie flag had been supplied if linking an executable.»
Пользовался ли «именно тем самым нечасто используемым» санитайзером для которого этот ключ необходим.
UFO just landed and posted this here
И который его сам добавляет.
Когда очень много зависимостей, прийдется во время линковки лезть в каждую либу и смотреть на флажки что бы ничего не конфликтовало.
Да и не везде CMAKE последней версии. Да и не везде CMAKE. Ручками часто приходится флажками жонглировать.
Он у меня тоже плохо работал… Много было false positive.
Все таки, тестовое задание, — это очень сильная диспропорция по затраченному времени компании и соискателя. Условно, соискатель тратит 3 часа на написание кода + еще 5 на вылизывание и поиск лучших практик в гугле, а представитель компании за 1 минуту дает вердикт.Как я уже писал под прошлой статьёй, прийти к вам в офис на очное собеседование — это тоже дело далеко не 5 минут. В Москве, например, если «повезёт», одна только дорога туда-обратно может занять те же 3 часа.
Да и сам подход какой-то странный. Я не хочу, чтобы компания тратила на меня столько же времени, сколько и я на них. Мне нужно за минимальное время получить максимально релевантный ответ.
Смотрите, тот факт, что собеседование одного кандидата стоит для компании дорого (надо на 2 часа вырвать из процессов лида и ПМа), заставляет как-то оптимизировать процесс, и не приглашать кандидатов с низкой вероятностью прохождения (и тем самым экономить и их время тоже). Для этого часто используют 15-ти минутный телефонный прескрин, например. И от этого выигрывают обе стороны. А в случае тестового относятся так, что "не жалко", пусть тестовое хоть человек с вероятностью в 1% пройти собес делает. Там более, если к тому времени уже закроют позицию, то можно просто все ответы на тестовые выкинуть и не смотреть. Именно из-за этого диспропорция это плохо.
И да, тестовое это ж не вместо, а в дополнение
заставляет как-то оптимизировать процесс, и не приглашать кандидатов с низкой вероятностью прохождения (и тем самым экономить и их время тоже). Для этого часто используют 15-ти минутный телефонный прескрин, например.Гораздо чаще для этого используют зарекомендовавший себя метод «гадания по резюме».
Да и «15-ти минутный телефонный прескрин» — тоже не сильно лучше, за 15 минут вы сможете подтвердить только существование соискателя и актуальность его заявки.
И да, тестовое это ж не вместо, а в дополнениеТестовое (в нормальных местах) идёт, как минимум, вместо загадок про люки и зачёта по сортировке пиломатериалов. То есть, тестовое прошёл — значит по скилам уже подходишь, и остаётся только «поговорить за жизнь» и поторговаться за зарплату.
Да и «15-ти минутный телефонный прескрин» — тоже не сильно лучше, за 15 минут вы сможете подтвердить только существование соискателя и актуальность его заявки.
Мой опыт показывает обратное. Есть ряд вопросов, аналогичных fpie из комментария выше, но для других стеков технологий. Когда таких закрытых вопросов 15 (45 секунд на 1 вопрос + остальное время на возможность кандидату спросить о проекте и команде), то предварительная оценка выходит весьма неплохой.
То есть, тестовое прошёл — значит по скилам уже подходишь
Тут у разных людей разное видение. Но, как минимум, тестовое без последующей перепроверки хард скиллов = возможность сделать его совместно с более опытным товарищем. И на возражение «так через 3 дня реальной работы и так станет все понятно», преждевременно отвечу, что далеко не всегда и не везде. А проваленный испытательный срок — это огромный убыток для компании, ведь потрачено внимание коллег, расширение ресурса затянуто на лишние 2-3 месяца, необходимо двигать обязательства перед клиентами и другими командами, ведь планы считались исходя из непрошедшего тоже.
Del
Условно, соискатель тратит 3 часа на написание кода + еще 5 на вылизывание и поиск лучших практик в гугле, а представитель компании за 1 минуту дает вердикт.
Тут смотря что Вы хотите увидеть в выполненном тестовом задании. Обычно в Интернете встречаю упоминания тестовых заданий в которых соискателю предлагалось изобрести какое-либо алгоритмическое ноу-хау (тянущее на научную работу) или супер вызубренное владение каким-то конкретным инструментом/библиотекой/фреймворком.
Однажды нам потребовались дополнительные руки в нашу маленькую команду. В связи с тем что общаться с людьми в живую не мой конёк, то эту задачу на себя взяли другие подходящие люди, а с моей стороны было подготовлено техническое задание для выполнения тестового задания.
На составления ТЗ я потратил около 3-х дней, на выполнение соискателю давался 1 день, на проверку я тратил не менее 1 часа. Задание не было большим и сложным, так почему же я потратил так много времени на подготовку ТЗ?
ТЗ было составлено так, что бы соискатель смог продемонстрировать такие свои навыки:
- внимательно читать ТЗ
- вникать в предметную область
- абстрагироваться на разных уровнях детализации (система/приложение/класс)
- банальное понимание клиент-серверной архитектуры (особенно когда на разных уровнях взаимодействия клиент и сервер могут меняться местами)
- структурировать дизайн приложения
- структурировать код приложения
- переиспользовать код
- работать с чёрными ящиками (есть детальное описание API другого приложения, но нет его реализации что бы к нему подключиться и интегрироваться последовательностью проб и ошибок)
- прочее
При этом в самом же ТЗ и в сопроводительном письме указывалось что код не будет даже компилироваться и запускаться, было описано что это одно из приложений в микросервисной системе, что это "прототип" но подобию которого будут строится и все другие приложения системы, и прочие "намёки".
Так вот на разработку такого тестового задания и на интерпретацию того что нам присылали соискатели тратиться достаточно много времени, понятно что если соискателей много то суммарно их потраченного времени больше чем нашего, но если сравнивать с временем 1 соискателя, то мы потратили на тестовое задание в разы больше времени и сил.
P.S.: рассматривались соискатели именовавшие себя Junior и Middle — все показывали примерно равные уровни компетенции по тем параметрам что мы оценивали.
P.P.S.: и да, то что соискатель делал в тестовом задании было реально схоже с тем что мы делаем на самом деле, т.е. нужно было написать мини игрушечную версию того что у нас имеется.
Есть же еще вариант дать соискателю реальную задачу из рабочего проекта. И оплатить, если все будет выполнено. Разумеется, нужен предварительный отбор по резюме и подписание NDA
Зачем?
Что именно зачем?
Дать реальное тестовое задание — чтобы нанимать людей, которые готовы выполнить тестовое задание, причем не абстрактное, а реальное, получить за него деньги. А работодатель сразу видит подходит ли ему такой разработчик. Плюс отсев тех, кто не хочет или не может.
Оплатить — чтобы разработчик был заинтересован делать задачи работодателя.
NDA — чтобы не ушел код.
Дать реальное тестовое задание — чтобы нанимать людей, которые готовы выполнить тестовое задание, причем не абстрактное, а реальное, получить за него деньги. А работодатель сразу видит подходит ли ему такой разработчик. Плюс отсев тех, кто не хочет или не может.
Оплатить — чтобы разработчик был заинтересован делать задачи работодателя.
NDA — чтобы не ушел код.
Sign up to leave a comment.
Что такое I в ACID или взгляд с другой стороны