Всё началось, когда автор Ruby on Rails признался миру:
К нему присоединились и другие разработчики:
Один из самых старших инженеров Google сказал, что ни черта не помнит как работает квиксорт:
К концу дня высказались десятки и сотни самых разных разработчиков, в том числе авторы тех продуктов, которыми вы пользуетесь каждый день.
Подобный флешмоб может показаться вам глупостью, но служит он важной цели: продемонстрировать всем и каждому, что ни во что не ставить подобные собеседования — нормально. Это рвёт спираль молчания.
Как появилась эта статья
Для меня, как и для многих других, собеседования регулярно были болью. (А когда-то мне ещё и страшно было на них ходить.)
Я написал этот программный материал прежде всего из собственного опыта: приходилось много собеседоваться в своей жизни (стартапы, переезды). В процессе подготовки статьи много спорил с самыми разными разработчиками по обе стороны баррикад — как с кандидатами, так и интервьюерами. Сейчас я в том числе уже сам собеседую других людей в свои проекты и применяю полученный опыт. У меня сформировалась определённая позиция в этом вопросе, которой я хочу поделиться.
О каких именно собеседованиях речь
- викторины («Какая функция библиотеки X обладает особенностью Y?»)
- головоломки («Вас уменьшили до размеров 5-центовой монеты и бросили в блендер. Ваш вес уменьшился так, что плотность вашего тела осталась прежней. Лезвия начнут вращаться через 60 секунд. Ваши действия?»)
- вайтбоардинг («whiteboarding» — когда код требуется писать на маркерной доске)
- алгоритмические («Разверните бинарное дерево на бумажке»)
Чем вредны подобные собеседования
Проверяют в условиях стресса людей, специальность которых не предполагает работать в условиях стресса
Неудачно выкатились в продакшн, кто-то из разработчиков сорвал сроки, накричал чайка-менеджер. Стресс есть везде, чего уж там.
Однако (если вы не работаете в госзаказе) стресс, как правило, ситуация всё же атипичная. И проверять нового человека именно в условиях атипичной ситуации несколько безумная затея.
Вы же не проверяете новую кровать в Икее, швыряя на неё шкаф? Нет, вы ложитесь и представляете себя спящим на ней. Так почему в случае с собеседованиями вы поступаете ровно наоборот?
Самые замечательные разработчики, которых я встречал — нёрды и гики. Им нужны спокойные условия. Им нужно состояние потока. В лучшие свои времена такой человек за день закодит вам сложнейшую задачу. Если вы всё ещё хотите проверять его на стрессоустойчивость, может, стоит вместо того задуматься, как убрать стресс из своих процессов? (Это даст существенно больше профита.)
Не коррелируют с разработкой
Невероятно, но сами Google признали, что нет корреляции между тем, как кандидат показал себя на собеседовании, и тем, как он прошёл затем перформанс-ревью в процессе работы.
Носят поразительно случайный характер, ставя вас перед риском оттолкнуть талантливого разработчика и взять посредственного
Предположим, вы очень неплохо знаете некоторую тему, и вдруг по ней всплывает какой-то викторинный вопрос. Ответа вы не знаете. Люди замечают это, и, как правило, предполагают, что вы не знаете ничего по всей теме. (Много хуже, если вы поймали не один неудачный викторинный вопрос, а сразу несколько.)
Или, скажем, вы пишете код на доске, а синтаксис вылетел из головы. Как это будет выглядеть со стороны — проблема с памятью или с навыками? Неизвестно.
Судить вас в этом случае будут исходя из предположений, а человеческие предположения — невероятно случайная штука. Базируются они зачастую на полной ерунде (например, если вы пьёте много воды, интервьюер вполне может воспринять это как знак, что вы нервничаете или вообще врёте о своей квалификации.)
Порождают ненужные элитизм и дедовщину
Айти как сфера деятельности по своей природе невероятно подвержена ряду дуростей:
- культ сложности (Если решение недостаточно сложное или мне было недостаточно тяжело, то что-то не так)
- элитизм (Я лучше них, я лучше них, я прошёл все искусственные барьеры!)
- дедовщина (Меня гнобили, и я буду)
Причины здесь разные, и про них можно поспорить. Я рискну сказать, что дедовщина растёт из психологии, культ сложности — из инженерного характера нашего ремесла, элитизм же у айтишников исторический для стран СНГ. Всё это плохие штуки, ведущие к плохим решениям, значит, их стоит выдавливать из себя по капле.
Основные аргументы сторонников Google-style собеседований
«Ведь нужно проверять фундаментальные знания»
Вы так в этом уверены? Кому именно нужно? Здесь всё же не кафедра университета и не олимпиадный кружок, предлагаю вспомнить, зачем вы вообще ищете человека. Правильно. Писать API, проектировать инфраструктуру, рисовать кнопки, чинить баги, понимать задачу из общения с бизнесом, делать продукт дороже и круче. И делать всё это в срок и за деньги.
Способность разворачивать деревья на бумажке никак не поможет ни в одной из этих вещей (даже, собственно, может помешать: уведёт фокус с продукта на «божечки-кошечки, мы потратили неделю и сделали кастомный JSON-парсер, он на 7% быстрее». Я работал с такими людьми.).
«Вообще-то это требуется на практике»
Неа, не требуется. Более того: если я как тимлид увижу в репозитории мёрдж-реквест с наколеночным обходом графа или кастомной реализацией квиксорта, я с вероятностью 95% отклоню такой реквест с пометкой чувак, найди готовую библиотеку. Не говоря уже об истовом стремлении написать свою СУБД.
Что же касается каких-то особенностей языка или фреймворка, документация всегда к вашим услугам. (Для поездок на Кубу давно придумали Zeal/Dash).
Далее должна следовать обязательная ремарка про людей, пишущих поисковое ядро Google / Yandex. Но ваши разработчики в их число не входят (You Are Not Google), и прекрасно смогут прочитать про сложный алгоритм в момент, когда он действительно потребуется. Всё даже ещё интересней: в подобных хардкорных командах часто есть такой специальный парень с PhD по математике, который помогает разработчикам с алгоритмами.
«Если разработчик чего-то стоит, он это умеет»
Это вообще не аргумент в контексте проблемы, а скорее попытка утвердить себя во мнении, что вы хороший разработчик (и человек). Оставьте эту попытку, вы хороший разработчик! (Просто, скорее всего, страдаете от синдрома самозванца.) Идите сюда, я обниму вас ^_^
В минуту уныния рекомендую вспомнить Дэна Абрамова, который в своё время не прошёл во Вконтакте:
и сотни других подобных примеров (флешмоб #меняневзяли в фейcбуке).
Что важнее, все ваши суждения правильный разработчик должен знать XYZ, скорее всего, являются иллюстрацией ошибки выжившего:
«Нам тут не тупо кнопки по вьюшке двигать»
Понимаю. Нам тоже. Но вы действительно переоцениваете значимость и уникальность ваших задач. (Я утверждаю это, даже не зная вашей компании: почти все переоценивают.)
«В нашей компании всё часто меняется, поэтому проверяем универсально»
Давайте будем честны: проверить человека универсально невозможно. (IQ-тест был красивой идеей, но провалился). И знание алгоритмов тут тоже слабо помогает.
Насколько часто и насколько сильно у вас всё меняется? Если ваши сотрудники регулярно и кардинально меняют специализацию, то либо вам это зачем-то требуется (допустим), либо стоит задуматься над процессами. В обоих случаях имеет смысл проверять людей на требуемые навыки, а не на абстрактные. (Если iOS-разработчик вдруг стал секретарём, ничего страшного — проверите его на скорость печати.)
Если же изменения не такие значительные и не такие частые — ну, делов-то, выучит человек новый фреймворк. Он же уже доказал вам за это время, что способен работать и учиться.
«У нас такой поток желающих на трудоустройство, что нужны серьёзные фильтры»
Хорошо, но фильтровать их такими собеседованиями суть подбрасывать монетку.
Можете предложить им пожонглировать — корреляция отобранных в итоге кандидатов с их профпригодностью будет почти такая же, как и в случае с головоломками/вайтбоардингом (но хоть время сэкономите).
«Ты же сеешь невежество! Наверное, это из-за того, что ты не осилил алгоритмы!»
Напротив, я хочу принести вам разумное сомнение вместо слепой веры в деревья как работающий фильтр. Переход на личности с «не осилил» вообще не аргумент, в данной статье я старался разобраться в проблеме по существу.
«Но так было всегда»
… и это ещё вовсе не означает, что существующий порядок вещей правилен.
«Я влёт считаю O(f(n)) и с удовольствием рисую графы на доске. Что же, всё это зря?»
Разумеется, не зря. Никто не отрицает полезность этих знаний. Я лишь утверждаю, что неосмысленно использовать их как интервью-фильтр.
«Но ведь в Google/Facebook/Zalando продолжают так собеседовать, как же туда пройти?»
К сожалению, мир не всегда устроен разумно и целесообразно. Если вы всерьёз хотите уровень благ, который дают крупнейшие технологические компании, вам придётся прыгнуть под жернова их фильтров. А это означает подготовку день и ночь на протяжении долгого времени и годы попыток. Примите решение, стоит ли оно того лично для вас.
«А что же тогда спрашивать?»
Now we're talkin'! Всё просто: спрашивайте те вещи, которые кандидату придётся у вас делать. Попросите разработчика спроектировать тиндер или убер. Обсудите с ним частые проблемы в работе с очередями, сериализацией, сокетами. Разрешите ему при этом использовать те инструменты, которые он привык использовать.
И обязательно смотрите и обсуждайте код, будь то GitHub или нечто, написанное в процессе собеседования.
Кстати, можете добавлять и головоломок/алгоритмов, если очень хочется. Просто учитывайте всё, что написано в данной статье.
Как всё обстоит в EXANTE
Когда я только сюда устраивался, разработчики пригласили меня на продолжительный диалог. Угостили колой, обсудили мои прошлые проекты, подробно рассказали, чем занимается компания. Я задал ряд вопросов по технической части. Было много дебатов на тему «почему в данном случае было такое решение, а не иное». В том числе получил пару вопросов по моему коду в открытом доступе. В конце мне дали задачку из разряда «Как бы вы запроектировали X». Ещё мы периодически смотрели код на ноутбуках.
Всё заняло где-то в районе часа (сравните с мучительными восьмичасовыми собеседованиями одной российской кампании). Собеседования идут в форме неформального общения, а не допроса — даже в тех редких случаях, когда присутствует вся команда (порой хочется понять реакцию на новичка не только тимлида, но и членов команды).
Как видите, никакого стресса и полная возможность показать знания-навыки.
Кстати, мы регулярно ищем людей. А ещё стараемся не терять их из виду, даже если не можем взять прямо сейчас. И можем по-дружески указать на пробелы, а затем пригласить спустя несколько месяцев.
Менять мир нелегко, но необходимо
Даже когда мы обсуждали проблему в твиттере, среди русскоязычной ветки диалога идея данной статьи была в меньшинстве: на её защиту встали лишь я и ещё один финский CTO. (Новые концепции вообще долетают до СНГ с традиционным запозданием.)
Был такой замечательный венгерский врач-акушер Игнац Филипп Земмельвайс. Ему первому пришла в голову мысль, что 30-50% смертность при родах вызвана инфекциями с немытых рук врачей. И он не просто не нашёл признания: его цензурировали, осмеивали, поместили в психушку. Он умер от избиений. Сейчас же Земмельвайс известен как основоположник асептики и «спаситель матерей».
Мир меняется и к лучшему. Вполне возможно, что уже лет через двадцать глупые собеседования будут забыты. Давайте работать на эту цель!
Я хочу, чтобы сегодня вы задумались над тем, как собеседуете.
Материалы для размышления
- В айти господствует мнение, что уровень программиста характеризуется его техническими навыками
- Как мы проводим собеседования в Pivotal
- Why I Don't Talk to Google Recruiters
- Embrace How Random the Programming Interview Is
- The Programming Interview from Hell
- What if companies interviewed translators the way they interview coders?
- Eric Schmidt struggled to answer a Google interview question
- When your entire knowledge gets judged because you didn't know that one random fact
- /g/ has an interview
- Most companies value code cleanness over deep knowledge
KonstantinSpb
nazarov_tech Автор
ну, такое :) Сатира с вашего скриншота она скорее на критику непонятных эйчарских вопросов направлена, а в моём посте про проблемы технических интервью.
fr33z3
Я офигел, когда меня в Германии спросили есть ли у меня права на управление автомобилем… Был несколько удивлен :)
Merkat0r
почему? может вам хотят(или работа подразумевает наличие) выдать корп авто.
olsamurai
На самом деле спрашивают в 90% случаев. Во-первых это некий тест, потому что почти у всех есть права, независимо от пола, вероисповедания и т.д. А если нет, то либо у вас была причина не получать права, либо они у вас были и вас их лишили (пьяная езда, наркотики и т.д.). Во-вторых очень часто нужно поехать на встречу, к клиенту, к заказчику и, обычно, отдельного водителя не выдают.
Areso
Выдают машину? Или не оплачивают такси?
olsamurai
Ну на счет такси я не слышал. Если с вокзала или аэропорта, то такси вариант, но если ехать к заказчику 150 км, то выйдет очень дорого. А так на фирме есть, например 3-5 машин, которые только для этих целей. Взял ключи, карточку для заправки и путевую тетрадь и поехал по делам.
brzsmg
Раз уж вы начали, продолжу:
maxru
Идею про красные труселя и белую капибару записал в книжечку.
Никто не знает, где можно взять белую капибару в аренду?
rinatGimaldinov
Пример того как рассказать, что ты начальник?
ainoneko
"(Царю, чтоб не выглядеть так же, как все,
Приходится часто скакать на лосе)."
(Эйлин О'Коннор, из песни про Хоббита)
maxru
Тоже мне достижение :)
erthad
Вопросы местами дебильные, но моожно ровно эти же ответы сказать нормальным тоном.
С человеком все ясно: конфликтный, смотрим следующего.
Areso
После нескольких десятков собеседований или играешь по правилам, или ломаешь их.
KarasikovSergey
Вряд ли такого нервного и озлобленного типа возьмут работать в коллектив. Смотрителем маяка может?
Myosotis
Почему зачерпывать ложкой к себе это недостаток?
KickingBear
Ждем в комментах лидов из ТОП ру-айти ;)
nazarov_tech Автор
ждём с удовольствием, ибо у меня в том числе цель поднять дискуссию по этой теме )
i360u
Основная проблема любой методологии собеседований — уход от личной ответсвенности через формализм. Чтобы собрать хорошую команду — нужен особый талант, на стыке глубокого технического понимания процессов и психологии, а это чертовски редкое сочетание для рекрутеров и интервьюеров. Встретить подобных людей можно разве что в качестве основателей стартапов с уже имеющимся стартаперским бекграундом (лично проводящих собесеование), но, практически, никак среди сотрудников отвечающих за найм в крупных компаниях.
Koroed
Если человек способен сам человеским языком четко и осозннано рассказать, что он делал на прошлой работе (суть работы, используемые технологии и подходы к реализации), то такого человека можно смело брать.
Другое дело, что большинство не может. Вот попробуйте сами. Только честно. Вслух. Рассказ минут на 5. Вот чтобы сами себя взяли на работу после этого.
Ну а для людей без опыта все равно придется спрашивать что-то из теории. Хотябы выборочно. Возможно даже предложить человеку самому решить про что рассказывать.
khanid
Кстати. Вот в этой части как раз прошу своим языком описать, как человек понимает, что такое X (DNS, например), и как оно работает. И сразу уточняю, что книжное и википедийные определения меня не сильно интересуют, если не знают — можно не напрягаться. Если знают — я не откажусь услышать.
Ну или прошу примерный алгоритм на пальцах, как система отработает при использовании этой технологии.
Человек и так стресс испытывает (первая же работа! У меня ладони были мокрые в первый раз), а вот ещё и чисто теоретическое тут вспомнить может быть проблемой. Не экзамен в универе, всё же.
Mendel
Я очень часто задаю один и тот-же теоретический вопрос. Мне задали его где-то в 1996-м.
Я прошу человека нарисовать блок-схему решения квадратного уравнения. При этом сразу предупреждаю что гуглом пользоваться можно, но я буду наблюдать.
вопрос задаю обычно или юниорам или «матерым».
Вторым скорее для проверки психологического фактора.
Очень многие начинают бычится, мол «это смешно, задавать МНЕ такие простые вопросы».
Ну и потом когда (не если а когда) я найду к чему придраться, то у человека будет вторая возможность провалиться начав спорить что это все не важно, и вопросы у меня тупые.
Если человек напишет без гугла, да еще и без ошибок («идеально»), то я прям даже не знаю что делать. Такого никогда не было. Но пути решения, поведенческие реакции, сообразит ли человек исправить все оплошности после первого наводящего вопроса, или будет кивать головой дальше пока я все сам не назову — это важно, да. Не так важно как практические навыки, и реальные знания (не энциклопедические), но важно.
Это сродни текущему скандалу по «50% женщин». Отличная идея это ваше равенство.
Поощрять талантливых женщин, геев и лесбиянок — выгодно всем, ведь ты получишь ценные кадры которые страдают от предрассудков в другом месте, они получат хорошее место… Но если идею развить до конца, то мы получим «50% женщин-программистов», а это чистый фейл.
Я думаю что все эти олимпиадные собеседования имеют свои корни из таких вот небольших вкраплений теории и викторины. А потом «немножко» выродились в викторину. Плюс рекрутеру проще зазубрить количество пинов у сим-памяти, когда сейчас уже диммы чем научиться определять что рекрутируемый способен без документации разобраться какие джампера нужно ставить для какого процессора (ну какой он есть личный пример, по софту ни разу не собеседовался непрофессионалами).
serg_p
Камент месяца — Супер :)
hoack
Забавный вопрос для собеседования, спасибо!
0xd34df00d
А какой ответ вы ожидаете?
Прямолинейный алгоритм «x_1 = -b+sqrt(b^2-4ac) / 2a», «x_2 = -b-sqrt(b^2-4ac) / 2a » вас не устроит? А почему?
Не проверил, что коэффициент при старшем члене не равен нулю? А если бы проверил? Вы бы придрались, что я не проверил, что для любого i > 2 коэффициент при x^i равен нулю? Кстати, как это сделать на машине с ограниченной памятью? И имеет ли смысл это делать?
Не проверил, что дискриминант не меньше нуля? А у вас в алгебре комплексных чисел нет?
Не проверил, что дискриминант равен нулю, и поэтому x_1 = x_2? Ну давайте обсудим, почему нельзя говорить, что у квадратного уравнения один корень.
SirEdvin
Блок схема — это немного другое.
А приведенное вами решение, например, выдаст ошибку, если вы неправильно дали ответ, потому что в случае комплексных корней у вас x_1 будет равен x_2, так как для комплексных чисел корень работает по другому.
0xd34df00d
Это как это для комплексных чисел корень работает по-другому?
Вы про то, что корень для комплексных чисел — неоднозначная функция? Ну так для корня второй степени корни лежат на pi друг от друга, то есть, как раз минусом и отличаются, и у вас эти два корня просто поменяются местами. Достаточно договориться брать один и тот же корень из всего множества.
SirEdvin
Но вот Вы забыли это указать, а это существенно важно, мне кажется.
0xd34df00d
Так он и для вещественных чисел так же работает. Корней из 4 два: 2 и -2, например.
Mendel
Ответ на этот вопрос, как и большинство вопросов на собеседовании — не подразумевает именно правильного ответа.
Самый простой способ провалиться на этом вопросе — отказаться его делать обидевшись что мол слишком простой вопрос. Чаще всего это были «я ж специалист, я ж курсы окончил!».
Нарисовать блоксхему или не спрашивая «а можно» написать псевдокод? — это тоже показатель того как человек в спокойной обстановке будет оформлять код. Не псевдокод, а накидать общую идею, как у вас (в комменте можно, в задаче на собесе нельзя, но такие тоже были) — давайдосвидания.
Полезет в гугл смотреть «гост оформления блок-схем» — любопытный факт, надо повнимательнее посмотреть что тут у нас: задрот или педант? Ну а озвученными вами типичными вопросами про комплексные корни и деление на ноль — это очень важный водораздел. Вообще не подумать что бывают исключения и писать в лоб — четко показывает уровень человека. Понял после уточнения «вы уверенны что все учли» — другой показатель. Опять таки как именно он будет писать/рисовать, искать, исправлять — ход мысли виден. Корень и деление это такие вещи которые вызывают вопросы автоматом, при написании. Ожидать нестандартного окружения (комплексные числа например) и не озвучить это вслух или в пояснительной записке к решению — гораздо большее зло, чем вообще не подумать о проблемных данных. Решение на тяп-ляп и попытка померяться длиной полового органа с собеседующим. Нафик, нафик. Ну или попытка оправдаться, что тоже жирный минус.
bay73
А вы и в процессе работы блок-схемы рисуете? Или только на собеседовании требуете?
alexeykuzmin0
Далась вам эта блок-схема. Суть вопроса не в ней.
Я вот, например, каждый день сталкиваюсь со всем, что в этой задаче используется: процесс сбора требований, выбор подхода к решению задачи, обсуждение того, какие граничные случаи учитывать, а какие нет, и многое другое. Задача явно проверяет именно это, а не умение «рисовать блок-схемы»
bay73
Ну так автор именно на блок-схемах настаивает. И даже готов поощрять человека, который гостами на блок-схемы интересуется.
Mendel
Поощрять? Где в моих словах про поощрять? Наоборот, возможно «наказывать». Я сказал только что это повод обратить на человека внимание чтобы понять с чем это связано. С хорошими чертами характера, что он думает о деталях и перестраховывается не зная какие у меня критерии даже если заранее с ними не согласен, или ему важнее шашечки и мы с ним не поедем. Я не знаю хорошо это или плохо когда человек ищет гост.
bay73
Ок, значит я ту реплику не понял.
Тогда прошу пояснить, какой из двух вариантов «задрот» или «педант» ассоциируета с «ему важнее шашечки и мы с ним не поедем»
Я просто со своей стороны считаю, что слова «блок-схема» еще более ругательные, чем «сортировка пузырьком». И постараюсь держаться одальше от конторы, где это просят на собеседовании.
Mendel
Все кто спрашивает «а можно псевдокод (код) а то блок-схемы не помню / плохо рисую / не люблю?» получают от меня ответ: «Можно».
bay73
Ну так то же самое можно и на других собеседованиях делать. Вам говорят — напишите код сортировки пузырьком, а вы можете сппросить — а обязательно код на С++ или можно псевдокод? И т.п. В нормальных местах так тоже можно.
А вот лучший способ завалить собеседование с сортировкой пузырьком это «отказаться его делать обидевшись что мол слишком простой вопрос»
Mendel
В жизни блок-схемы рисую редко. И совершенно не помню как их правильно оформлять. Рисую банально прямоугольники с ромбиками и стрелочками, все остальное словами.
Слово «блок-схема» в задаче во многом «дань традиции», ибо я считаю что стал программистом именно с этой задачи. Я тогда пришел к системному программисту на маминой работе с тем вопросом который меня интересовал — я не мог понять для чего в микропроцессоре Z80 регистр R (если не путаю наименование). Вопрос кстати был не совсем уж глупый, и прошло довольно много лет пока я таки на практике понял что регенерация динамической памяти это не такая уж и мелочь, и когда процессор это сам умеет это хорошо… В общем я такой весь умный был, а этот старый еврей меня посадил блок-схему квадратного уравнения рисовать. Оно было сильно обидно когда тебя такое спрашивают в 11-м классе с математическим уклоном…
Вот когда я скрипя зубами нарисовал, и меня ткнули носом в граничные условия и т.п., я да, стал программистом). Не хорошим программистом, плохим программистом. Ничего не умеющим, но уже программистом.
Ну а так то оно не мешает. Кто не помнит что это — может спокойно нагуглить. Кто не может нагуглить — проявит психологические качества которые пойдут ему в минус. Если это будет единственный минус то и черт с ним, подскажу, но если я и так колебался, то даже это может повлиять.
0xd34df00d
А я не понимаю, как тут рисовать блоксхему, если в итоге нет ни одного ветвления. Так что да, лично я бы сразу написал вот упомянутые выше выражения и обвёл их в прямоугольнички (как всегда обвожу ответы в задачках).
Какой? Я не уверен, что корректно улавливаю коннотации.
А какие исключения? Коэффициент при x^2 не равен нулю, коэффициенты при всех старших степенях равны нулю — это определение полинома второй степени. Почему вы предлагаете проверить только одну часть этого условия?
Да и вообще, может, у меня типизация гарантирует, что
aне нулевой. У вас не найдётся минутки, чтобы поговорить о зависимых типах?Что значит «нестандартное окружение»? У меня в математике комплексные числа стандартные, давно придуманные и вполне себе используемые.
Когда задают такой действительно простой вопрос, то понятно, что дурят нашего брата, но вот как именно и что именно вы ожидаете — я понятия не имею.
Впрочем, я понятия не имею, чем вы вообще занимаетесь и какая ваша предметная область. Ожидать одинакового стиля мышления от веб-разработчика, хардкорного эмбеддщика и какого-нибудь теоретика CS — неразумно. Поэтому, например, для CS-теоретика эти несчастные комплексные числа вполне могут быть стандартным окружением. И sqrt у него что надо возвращает.
Совсем, кстати, не обсудили численную стабильность такого решения. А зря, тоже важный элемент.
Mendel
Вот кстати да, посыпаю голову пеплом). Собственно все остальное на фоне того уже не важно.
Rezzet
К примеру прошлая работа была в команде поддержки продукта, основаня работа около правки багов и мелких доработок(а так в любом крупном долгоживущем именитом продукте будет), что в этом случае рассказывать? Причем когда проект состоит из двух сотен библиотект и тонн кода вообще править в нем баги и делать оптимизацию это сильно не простая задача, но в итоге половину просто не поймут, если даже начнешь рассказыать, а половина попадет под НДА, так что рассказывать?
springimport
Можно же рассказать что было на позапрошлой работе.
Не стоит так резко воспринимать это.
myst375
А если не было позапрошлой работы? Я сразу после универа устроился и работал 13 лет в одной конторе. Вот сейчас как раз ищу новую работу (в связи с переездом). И да, почти все интересное подпадает под NDA (в моем случае). Буду пытаться рассказывать так чтобы ничего не «выдать»…
fillpackart
Вообще всё больше склоняюсь к мысли, что идеальный рекрутинг должен выглядеть так:
DrFdooch
что делать, если публичного кода нет?
nazarov_tech Автор
Это штатная ситуация, варианты её решения есть:
sevikl
а как админов собеседуете? у меня живой интерес.
Frimko
наверное они просят собрать свою генту)
Merkat0r
дефолтный emegre world с генкернелом много ума не требует :)
lasc
Амазон дает шелл на сервер и просит поправить косяки по списку.
Adel-S
И не только Амазон.
avost
Возвращаемся к whiteboarding'у пузырька? :) ну, и стоило ли так напрягаться, статью целую писать, чтобы вернуться к простому незамысловатому и лёгкому для анализа способу?
Когда-то давно прочёл, а потом нашёл немало подтверждений, что есть люди которые могут писать код и люди, которые только говорят, что могут. Очевидно, самая первая задача стоит в том, чтобы отделить одних от других. Можно пойти сложным путём и пытаться понять это из пространных размышлений о коммерческом коде в вакууме. Но можно же просто попросить написать на бумажке "пузырёк". Не?
valbok
Отделять одних от других надо как можно быстрее и до того, как пригласить к уайтборду, не?
avost
Если овладеть этой джедайской техникой, то собеседования становятся не нужны. Не?
arcman
Можно предположить, что на собеседовании тогда проверяются не технические навыки, а soft skills.
valbok
Правильно, считаю идеальным, если бы меня брали на работу без собеседований, просто присылают пресс релиз, чем занимается компания, откуда деньги, фотки членов команды, биография тимлида, адреса-телефоны, инвестиционный план развития, бонусы, акции, ну и сразу офер с шестизначным числом в евро.
Готов рассмотреть варианты.
avost
Полагаю, в топменеджеры газпрома примерно так и "берут". Но "у генерала уже есть свой сын" :-D
Mendel
Писать и обсуждать код на собеседовании сидя за компьютером в привычной IDE и при доступным гуглом с стековерфлоу и гутхабом — немного не тоже, что писать код на бумажке/доске.
avost
То есть вы предлагаете притащить на собеседование компьютер? а какой именно? Я, вот, привык к аймаку с клавиатурой микрософт нейчурал 4000 и вертикальной мышкой. Покупаете ради кандидата? Поставить туда любимую иде кандидата, дать ему пол-дня для её настройки под себя и… и попросить написать бинарный поиск? Супер!
Mendel
Стандартная полная клавиатура за семь баксов и мышка, плюс любой иде и любой браузер — достаточный набор для любого айтишника. Да, будешь писать чуть медленнее и тп., но в целом — разберешься.
avost
Ну, вот, видите, вы сделали первый шаг — от комфортного компьютера и привычной иде к абы-какому хламу и первому попавшемуся иде. Следующий логический шаг — для решения примитивной задачи зачем вам иде? Хватит бумажки и ручки. Это достаточный набор бля любого айтишника. Я уверен, вы справитесь. Мои дети в первом классе справляются с этим инструментарием. И вы справитесь. А если не справитесь… ну, тогда, наверное, нафиг вы нужны такой? ;)
Mendel
Во всем нужен баланс).
alexeykuzmin0
Google на собеседованиях выдает ноут: мне предлагали выбрать из Chromebook, Macbook Air и вроде Lenovo какой-то. Правда для кода все равно или google doc, или доска.
DistortNeo
А клавиатуру и мышку к ноутбуку они не предлагали?
Chromebook:
Lenovo ThinkPad X1:
И ладно, я ничего не имею против, когда на 12" ноутбуке компактная кливиатура, но когда на 17" ноут лепят точно такую же клаву, хочется ругаться.
alexeykuzmin0
Нет, не предлагали. Думаю, если попросить, дадут. И всегда можно писать на доске или на бумаге.
Но тут есть такая особенность — все материалы с собеседования будут смотреть и другие люди. Вероятно, код им будет удобнее смотреть в виде google doc, а схемы и таблицы — в виде фото доски или листов, а не наоборот.
Лично я сначала у доски рисовал пару рисунков, объяснял решение и доказывал его корректность и сложность, после чего набивал код на ноуте параллельно с комментариями на тему тестирования, получалось быстро и удобно.
tyomitch
Год назад у них собеседовался, мне ноут не предлагали :-/
Только маркер и доска, только хардкор.
roman_kashitsyn
Скорее всего, зависит от офиса. В Лондоне мне предлагали, в Цюрихе — нет.
Может, уже и вовсе эту практику прикрыли. Мне лично доска показалась гораздо удобнее, чем google doc на chromebook. На ней картинки и формулы удобно рисовать. Не могу я без картинок задачи решать.
tyomitch
Видимо, так и есть. Я был в Цюрихе, там не предлагали.
Так можно же совмещать? Картинки на доске, код в компьютере.
По-моему, так все и работают: картинки рисуют на доске, а код пишут в компьютере.
roman_kashitsyn
Я так и делал, но это оказалось неудобно. Стоишь у доски, объясняешь, потом садишься к компьютеру (ревьюеру тоже надо сесть), пишешь что-то, при этом надо периодически смотреть на доску, иногда возвращаться, что-то дописывать…
Нет уж, код обычно достаточно короткий, чтобы легко умещаться на доске, а использование маркера вызывает меньше дискомфорта, чем клавиатуры непривычной раскладки без емакса.
YemSalat
Попросить кандидата принести свой лэптоп в голову не приходило?
Если у кандидата нет лэптопа — сойдет любой, в любом случае это не то же что писать код на бумажке.
Disclaimer: я не против писания кода на бумажке на собеседовании, но ваш аргумент как-то не очень.
kloppspb
И тут же налетят сотни, тысячи…
copist
Два последних варианта — ревью и шлифовка — это класс! Отличная идея. Честно. Главное код взять хороший, например не по стайлгайдам, KISS и SOLID. Уверен, в любом проекте найдётся. Можно нагавнякать. Или дать что-нибудь из решений кандиатов, не прошедших тестовое задание.
makven
Всегда настораживало утерждение, что для старшего разработчика непозволительно дорого делать тестовые задания.
Как это возможно, что человек ищет работу, но не готов показать свои умения?
kaljan
Человеку невыгодно тратить свое личное время на неоплачиваемую работу, тем более что на рынке есть работодатели без тестового задания
Существует практика оплаты затраченного на тестовое задание времени
spmbt
Там в статье обосновывается положение, что разработчику не только невыгодно бесплатно делать задания, но и даже платно (распыляются силы на неосновную цель).
AllexIn
Нормальные работодатели платят за тестовые задания. Но они — вымирающий вид.
fukkit
Тестовое задание (которых лично я не сторонник) для кандидата, тем не менее — обычная инвестиция, имеющая субъективную ценность. Каждый может оценить (посчитать) её для себя.
AllexIn
Ну так и для работодателя они — инвестиция.
Если я не настолько хорош с точки зрения компании, чтобы оплатить мне доорогу и тестовое задание — стоит задуматься, правильно ли меня оценивают.
seniorcote
Я далеко не старший разработчик, но для меня это тоже дорого. Время — самый ценный ресурс. И даже если тестовое задание выполнено хорошо — совсем не факт что возьмут на работу (сколько было случаев — ни разу не взяли и часто просто тянули время). Но я не говорю про оплачиваемые тестовые задания, если оплачивают — то все ок, конечно же, но такой вариант мне попадался лишь один раз.
В идеале, я бы хотел, чтобы все-все разработчики в мире договорились отказываться от тестовых заданий, но это мечты :D
fukkit
Поддержу ревью.
Менее стрессовый вариант, рефреймящий коммуникацию с экзаменационного шаблона (вы задаёте каверзный вопрос, кандидат подрывается искать ответ) на кооперативный (совместно обсуждаете сторонний код, ответственность за который на кандидате не лежит, он наконец может немного расслабиться, включить голову, раскрыть способности, покритиковав другого показать себя).
Искать недостатки в готовом неидеальном коде эмоционально проще, чем ваять свой идеальный. Для перфекциониста вайтбординг — ад.
Если уж сил нет как хочется проверить стрессоустойчивость, можно дать кандидату в морду. Заодно и свою проверить.
fillpackart
Попросить прислать какой-нибудь код, например.
valbok
Можно ради спортивного интереса сграбить кусок кода из больших популярных опенсорсных проектов гугла или апл,
и в итоге удивиться, какой «некачественный» код прислал.
Daniil1979
А если я в свободное время пишу не код, а фэнтези? Ссылку на раздел Самиздата присылать?
fillpackart
Не скажу за всех, но я бы не хотел работать с людьми, которые не пишут код в свободное время.
Daniil1979
Планета Шелезяка ждёт Вас!
Prokky
А я бы не хотел работать с людьми, которые все свободное время пишут код. По моему опыту, с ними очень трудно общаться.
nonnenmacher
Так всё хорошо в меру ведь. Главное — правильно организовать своё время.
0xd34df00d
О рабочих моментах трудно общаться, или в пятницу после работы?
Prokky
О рабочих конечно не трудно, но ни о чем другом. В пятницу после работы они код пишут дома :)
0xd34df00d
А зачем вам с ними общаться о чём-то другом?
SirEdvin
Потому что есть такие штуки, как тимбилдинг? Без него, например, может расти напряжение в колективе и прочее.
0xd34df00d
Спасибо интервьюверу, что он мне даст знать, что в компании практикуют принудительный тимбилдинг, поможет мне принять верное решение на тему этой компании.
SirEdvin
Дело не в принудительном, но если команда представляет собой разрозненных людей, то ей довольно сложно работать эффективно.
Например, если люди плохо знают друг друга, то они могут стеснятся поднять какую-то важную тему, например, о проблемах проекта и прочее.
DistortNeo
> Например, если люди плохо знают друг друга, то они могут стеснятся поднять какую-то важную тему, например, о проблемах проекта и прочее.
Думаю, это больше от характера зависит.
0xd34df00d
А если люди слишком неформально дружны, то они могут стесняться поднять какую-то вжаную тему, например, о проблемах проекта, потому что вдруг обидят приятеля.
greendimka
Тимбилдинги очень эффективно отпугивают тех, кто предпочитает после рабочее время проводить по своему усмотрению.
А еще тимбилдинги не только уменьшают, но и увеличивают напряжение — зависит от очень многих факторов.
Prokky
Если принудительные — то вы правы, конечно. Но, например, сходить в пятницу в бар с коллегами бывает полезно для того же тимбилдинга :)
Mendel
А давайте делать пьянки в рабочее время. Нет серьезно.
ДРы, корпоративные праздники и т.п. вполне можно и в рабочее время «после обеда» отмечать. При этом обязательно дать возможность асоциальным типам оставаться асоциальными. Ненавижу общения в группах больше трех человек.
Прям физически не могу. Но как руководящий работник делаю над собой усилие.
А тем кто не манагерит, тот должен иметь возможность откосить и не вызывать у окружающих отторжение по этому поводу.
А тимбилдинги в свободное время — зло несусветное. Нет, иногда можно, но лучше уж куда-то на недельку с семьями или еще что-то, чем «пиво по пятницам».
alexeykuzmin0
0xd34df00d
Или вместо того, чтобы посидеть и дома пописать код.
fillpackart
Очевидно, те кто не пишут код в свободное время должны работать с себе подобными, как и те, кто пишут. Интересно, у кого будет лучше код?
greendimka
Я пишу код в свободное время. Но не горю желанием всем его показывать (цель написания — не тщеславие). Мы подобны или нет?
Areso
Можно не показывать код, но показывать результаты его работы.
Или показывать саму программу, но не код.
К примеру, у меня весь код открыт, но он никому не нужен. Мои первые программы шли freeware (без опен-сорса) и количество их загрузок исчислялось десятками тысяч. Мои программы были полезны, а мой код — нет (вероятно, по причине его невысокого качества).
webkumo
Оставьте в комментарии… любопытно почитать. :)
PS ну и ссылку на резюме в инфе об аккаунте стоит держать, никогда не знаешь, где найдёшь человека, которого можно порекомендовать hr-ом компании, в которой работаешь :)
SirEdvin
Я присоеденюсь к комментатору ниже, обычно, с людьми, которые совсем не пишут код в свободное время довольно сложно, так как преславутые 20% компания не выделает.
Так как они выпадают из трендов и как следствие, становятся узкими проектами специалистами и довольно консервативнымы, что напрягает других членов команды.
SAWER
Это уже предубеждение. Часто бывает, что человек просто не в теме новинок в вашей среде, т.к. интересуется другим направлением. Я вот часто узнаю много нового от коллег, но сам редко могу предложить из их интересов в программировании. Но опыт в других направлениях более полезен команде.
А вообще, тренды, как правило, то еще не предсказуемое и малополезное нечто. Они постоянно мрут и становятся бесполезным грузом знаний, либо решают уже решенные проблемы. Другой вариант. Смотрел тренды Java, нужно было подтянуть свой уровень. Многое выглядело для меня просто как дикость и безумие, т.к. проблемы, которые решают трендовые методики просто не существуют в C# dotnet. Так, легко видно людей, которые пишут на новом для себя языке как на старом.
SirEdvin
Мне кажется, вы совсем не поняли то, что я имел ввиду. Если обобщить, то я имел ввиду что-то в духе "Откуда человек будет знать о новой, крутой и очень полезном фрейморке/библиотеке/тулзе X, если в реальном проекте он им не пользуется, а в свободное время вообще не занимается программированием, а значит, у него банально нет времени для того, что бы рости как специалист вне проекта?"
Откуда же человек получает опыт? Если ему повезло работать в крутом проекте, в котором вот применяется довольно большое количество нужных штук, то понятно, но а вот если нет?
Откуда, скажем, человек, который работает на проекте с jQuery будет получать опыт с новыми javascript библиотеками, что бы потом предложить их использовать в проекте?
SAWER
Как раз таки понял. Но не понял, почему вы так считаете о тех, кто дома код не пишет. Попробую по другому. Что мешает просто загуглить и узнать о технологии? Обычная практика — сначала поставить проблему, потом уже её решать. Делать же наоборот — нонсенс.
Писать код совсем не обязательно, чтобы было понимание. И опять таки — все что в тренде может полететь далеко и навсегда. Так было с кучей практик, кучей, уже макулатуры, что когда-то были примерами для подражания большинства программистов той среды. Что для меня попусту потраченное время.
Мне уже давно не обязательно получать опыт пробами для работы с тем, что я уже знаю. Просто потому, что dotNet + Unity + специфика работы железа перекрывает возможности обучения методом проб. Они просто развиваются быстрее, чем это всё можно опробовать. Но есть и +. Всё это можно найти в спецификации, статьях, патчнотах и прочем. Этого достаточно, чтобы изучить всё и знать, что использовать в следующий раз.
Ну и поставим вопрос по другому. Сколько благ вы создали такой деятельностью? Некоторые люди, что продвигают те или иные технологии, дорабатывают их, тестируют, пользуются — полезны. Но какова эффективность? Не лучше найти еще одну работу, раз уж у вас полно сил и времени?
SirEdvin
Это как? Я еще ни разу не видел продукт, на котором было написано "у нас такие то проблемы". Что бы знать, подойдет ли какой-то продукт, фреймоворк или библиотека для решения проблемы — нужно получить с ними реальный опыт, чтение документации — это хорошо, но оно почти не дает точной информации по продукту.
Какие блага? Я делаю такие вещи не для того, что бы создавать блага, я это делаю для развития себя как специалиста и для того, что бы попробовать технологии, которые мне понравились. Вот у себя в pet-project написал бота с использованием rethinkdb и в целом неплохо и удобно, и как оказалось, у rethinkdb в самом деле неплохой кластер. Но и есть ряд проблем, которые оказались довольно внезапными и, которые, пока еще решить мне не удалось, типо того, что иногда все нафиг виснет из-за rethinkdb. Откуда бы я еще об этом узнал?
SAWER
Понимание многих вещей можно получить умозрительно. Хорошая документация + специфика + примеры работы с пояснениями — достаточно для вывода, часто лучшего, чем даже собственный Небольшой опыт. Для лучшего опыта надо работать над этим долгое время, с разными задачами. Не обязательно самому быть первопроходцем. Опыт можно перенимать у коллег и сообщества. Для меня это очевидные вещи.
Да, в первые годы это приносит много пользы, учишься лучшему пониманию языка, набиваешь навык. Но потом это становится всё менее эффективным. С точки зрения понимания различных технологий — есть смысл изучить пару новых языков и программирование именно в их стиле. Большую часть новых фич переносят из других языков, не всегда даже языков программирования.
Касательно популярных вещей, что уже прошли отборку сообществом и теперь хотя бы иногда нужны заказчику. Освоить новую технологию не = написать что-то стоящее. Можно просто опробовать различные части этого проекта и понять как они работают. Это скорее исследовательская деятельность, чем написание чего-то конкретного. Тут просто быстро и полно проверяешь как и что работает. Часто даже более полно, чем когда требуется что-то конкретное.
Сколько у вас ушло только на одну вещь? А ведь их полно. Всё во всей IT среде просто не хватит времени проверить. Как вы будете выбирать, какой инструмент использовать? Только среди того, что пробовали? Это, пожалуй, на 2 месте самых худших способов выбора инструментария.
Любые блага. Даже ваше развитие как специалиста — благо, нет? Чтобы развиваться как программист, не обязательно для этого писать код, тем более «для себя», как и быть в тренде необязательно. Можно решать логические задачи, можно читать книги и справочники, ту же документацию. Даже изучение не языков программирования может принести пользу при правильном подходе.
SirEdvin
А как вы предлагает? У вас, по факту есть два варианта: это hype-driven-development и использование опыта. Откуда вы возьмете людей, которые скажут вам "Да, технология X подходит на наш проект, потому что ..."?
Это довольно странное заявление. То есть программист, который вроде как похож на инженера, не должен быть вкурсе последних новостей своей отрасли? Причем, в отличии от инженера, ему стоит их пощупать, так как у него хотя бы возможность есть.
Это абстрактные логические задачи, которые вам не очень помогут? Или документация, которая, обычно, сильно отличается от практики. Чтение документации о чем бы это не было бесполезно без практики.
Ну так мы же не требует от всех крутые open-source библиотеки. Но, скажем, если я буду изучать какую-то специфическую БД, то почему бы мне не взять в дополнение к этому какой-то новый web-фрейморк на знакомом мне языке (или уже знакомый мне) и не написать на нем какой-то todo лист? Вполне исследовательская деятельность.
SirEdvin
Дополнительно к этому, написание своих проектов позволяет выработать какие-то best practice и прочую мишуру, которую потом можно приности в проект, вроде анализаторов когда, подходов к unit-тестированию и прочему.
Gemorroj
за что минусуют?
сам так делаю, экономит кучу времени, как как соискателя, так и работодателя.
полное отсутствие публичного кода считаю минусом. вероятно, человек не очень любит профессию?
хотя для джунов такое приемлемо (еще не успели), тогда пишут тестовое.
Caravus
Отсутствие публичного кода может так же означать что на непубличный уходят все силы.
0xd34df00d
Зачем так жить? На что ж после работы тогда остаются силы?
Caravus
За всех говорить не могу, но лично у меня остаются силы на физ. активность. Могз вырубается, но телу это не особо мешает :)
0xd34df00d
Ну, у меня почти аналогично. Пришёл с работы, повалялся часик, почитал всякую ерунду и жвачку для мозга, и можно дальше делать что-то разумное.
Archon
Отсутствие публичного кода говорит о том, что человек был занят достаточно, чтобы вся его потребность творить полностью реализовалась за счёт закрытого кода.
Более того, наличие большого количества открытого кода, написанного во время полной занятости (а не между работами и не в отпуске), во многих случаях говорит о том, что работодатель не контролировал нагрузку сотрудника, и он, мягко скажем, скучал на работе. Или забивал болт на работу, потому что она ему не нравилась, и переключался на пиление своей библиотеки. Возможно, поэтому он и ушёл из той организации.
valbok
Открытый код — небольшое, но преимущество (перед теми, у кого нет, конечно). Играет роль, но не главную. Хочешь лучше работу, тогда придется собирать такие «преимущества», ну можно и не собирать, когда ты и так хорош.
DistortNeo
А зачем сотрудника полностью нагружать? Нормальному работодателю должна быть интересна выполненная работа, а не жопочасы.
Когда работодатель нагружает сотрудника так, что у него не остаётся больше ни на что времени, это приводит к тому, что сотрудник теряет возможность изучать новые и интересные вещи. Как следствие — выгорание на работе и потеря квалификации, так как в программировании нужно постоянно изучать новые технологии и расширять кругозор.
Если сотрудник стал выполнять задачи не за 8 часов, а за 4 часа, а оставшиеся 4 часа скучал, это значит, что квалификация работника повысилась и надо что-то делать. И просто давать такому сотруднику больше задач — не вариант
Впрочем, со стороны работодателя, наоборот, рост квалификации сотрудника может быть нежелателен, т.к. для более квалифицированного сотрудника может просто не оказаться задач, и в итоге такой сотрудник уйдёт.
Steed
"Если сотрудник стал выполнять задачи не за 8 часов, а за 4 часа" — эмм, мы о программистах говорим или о грузчиках на складе? Грузчик может быстрее машину разгрузить и пойти отдыхать, пока следующая не приехала. А представить, что у программиста кончились задачи, я лично не могу. Их сотни висит в баг-трекере. Если прогаммист простаивает, это ошибка найма и убытки для бизнеса.
Если программист начал работать продуктивнее, он может делать больше (лучше) и претендавать на большую зарплату.
Саморазвитие — отдельный пункт, который должен либо по договору с работодателем либо планированием самого разработчика занимать N-ную часть рабочего процесса — и это может быть как pet project, так и изучение книг, напрсание статей, рефакторинг проекта… И это не 4 часа из 8, а максимум 1.
AllexIn
А если программист не хочет претендовать на большую зарплату, а хочет свободное время?
Archon
Допустим, условный строитель в день обычно кладёт 5 условных рядов кирпичей. А наш Вася может класть 10, но хочет свободное время, поэтому кладёт те же 5, но за полдня. Что мы получим через месяц? Только то, что вся остальная бригада будет класть по 2 ряда в день, потому что тут можно работать полдня и идти отдыхать.
Если человек хочет свободное время, он работает сдельно. Положил ряд кирпичей, получил деньги.
Steed
Какое же это свободное время, если ты обязан сидеть его в офисе?
Doktorov
Значит он ещё не женат.
YetAnotherSlava
А это низзя-низзя. Это нарушение основополагающей лжи, что якобы «деньги могут заменить всё».
DistortNeo
> Если прогаммист простаивает, это ошибка найма и убытки для бизнеса.
Почему убытки-то? Обоснуйте. Почему медленный программист, выполняющий объём задач за 8 часов выгоден, а быстрый программист, выполняющий тот же объём задач за 4 часа и требующий столько же денег — нет?
> Если программист начал работать продуктивнее, он может делать больше (лучше) и претендовать на большую зарплату.
Да, более эффективный сотрудник приносит больше прибыли, поэтому в интересах работодателя давать ему больше работы, компенсируя это увеличение нагрузки зарплатой. Но это может расходиться с интересами программиста, которому достаточно денег и он не согласен тратить больше времени на работу.
> максимум 1.
За 1 час ничего серьёзного сделать не получится.
Steed
Серьезное вы делаете по основной работе. Если для вас это просто способ заработка и вам не интересен проект (был бы интересен, вам бы хотелось еще что-нибудь улучшить за оставшиеся 4 часа), то может быть стоит сменить работу?
DistortNeo
> Серьезное вы делаете по основной работе. Если для вас это просто способ заработка и вам не интересен проект (был бы интересен, вам бы хотелось еще что-нибудь улучшить за оставшиеся 4 часа), то может быть стоит сменить работу?
Это способ повысить свои знания и применить их на благо проекта. Половину времени решаются текущие задачи. А половину — делаются эксперименты, результаты которых не нужны прямо сейчас, но от которых будет польза в будущем.
> то может быть стоит сменить работу?
Нет. Я не соглашусь на работу, где надо работать по 8 часов в день. Ну ладно, может и согласшусь, но минимум за ~300-400к рублей в месяц.
> Тут у нас, наверное, надопонимание. Я говорил о том, что плохо, когда задач не хватает, чтобы загрузить программистов. Если же ваше «сотрудник стал выполнять задачи» означало «сотрудник стал делать тот же объем работы за 4 часа, а оставшиеся 4 часа филонить при наличии других важных и срочных задач», то тут даже не знаю что сказать. Наверное то, что проект с такими сотрудниками вряд ли взлетит.
В том-то и дело, что филонить не стоит. Наличие срочных задач действительно потребует недельку-две попахать, отложив свои проекту. Но это не должно быть нормой. Аврал — проблема руководства.
Demiurgos
наверное имеется ввиду, что если «в среднем» программисты в фирме за 4 часа делают основную работу и 4 часа простаивают, то можно сократить штат программистов в два раза, и на этом сэкономить :)
ЗЫ если что я сторонник того, что программист работает не 8 часов, а программист работает головой :)
DistortNeo
> наверное имеется ввиду, что если «в среднем» программисты в фирме за 4 часа делают основную работу и 4 часа простаивают, то можно сократить штат программистов в два раза, и на этом сэкономить :)
Ага, сократить штат в 2 раза и поднять оставшимся программистам зарплату в 2 раза.за удвоенный объём работы. Шило на мыло. Но при этом пропадает ещё один важный момент: запас производительности. В случае аврала в первом случае вы можете удвоить производительность программистов, во втором — нет.
fukkit
Типичные грабли, на которых висят истлевшие косточки многих молодых оптимизаторов. Не раз мною виданы случаи, когда Васю с Петей сокращают, потому что их работу смогут сделать Дима с Колей за полторы зарплаты. В случае факапа оказывается, что в сутках всего 24 часа, раз в два дня Диме желательно, все же, поспать, а Коля, вообще, в гробу видал переработки и заявления его осталось ждать недолго.
Idot
Если у Вас два бегуна:
будет верхом идиотизма считать отдых спринтера "убытками для бизнеса".
Это Вам стоит сменить работу по причине Вашей полнейшей профнепригодности в качестве IT-менеджера.
Archon
Возможно, я чего-то не понимаю в современных тенденциях программирования, но вот честно, не могу представить себе ситуации, когда для изучения новой технологии (точнее, возможности применения этой новой технологии) требуется сделать аж целый проект, и более того, отшлифовать его до такой степени, что его будет не стыдно кому-то показать.
Захотелось попробовать какой-то новый язык/фреймворк? Скачали, развернули, почитали про синтаксис, мельком пробежали по стандартной библиотеке, придумали реалистичный сценарий применения, сваяли каркас, написали тесты (и стресс-тесты), погоняли, записали себе в блокнотик мысли о применимости решения и встретившихся на пути ограничениях. Всё. Выкладывать после этого этот каркас на гитхаб, чтобы будущий работодатель посмотрел на это убожество и решил, что я пишу так на всех языках? Извините, но нет.
DistortNeo
> Возможно, я чего-то не понимаю в современных тенденциях программирования, но вот честно, не могу представить себе ситуации, когда для изучения новой технологии (точнее, возможности применения этой новой технологии) требуется сделать аж целый проект, и более того, отшлифовать его до такой степени, что его будет не стыдно кому-то показать.
Чтобы более менее нормально изучить C++, нужно 2-3 года практики.
Чтобы стать спецом по многопоточности и асинхронности, уметь грамотно построить архитектуру приложения и не допускать детских ляпов, тоже нужна практика, хотя бы год.
А шапочное знакомство с новыми технологиями ради строчки в резюме не принесёт практической пользы.
Archon
Если человек хочет изучить С++ ради того, чтобы сменить работу и начать писать на С++, он заслуживает уважения. Просто в моей практике, к сожалению, таких людей не было. В основном приходится иметь дело либо с узкими спецами по паре-тройке технологий, либо с людьми с сильной базовой подготовкой, которые разберутся с чем угодно (в разумных пределах) уже по факту. И ни те, ни другие, чрезмерной тягой к знаниям, не имеющим применения в данный момент, не страдают.
Relrin
Исходя из вашей логики получается, что все те люди, которые в свободное время занимаются pet-проектами/open source и подобными вещами тратят свое время просто зря? А что тогда делать в случаях, когда твоя работа (внезапно!) вполне устраивает, загруженность имеется, но просто есть ряд технологий с которыми поработать не предоставят возможности никак, даже если ты общался с соответствующими людьми (допустим перейти на микросервисную архитектуру; попробовать какую-то хорошую и проверенную временем библиотеку, обсудив с архитектором проекта, но не получив его одобрения)?
То что человек, тратит собственное время на что-то вне работы, говорит не о том, что ему здесь плохо и ему надо срочно уходить куда-то еще. Его вполне может устраивать текущее положение вещей на проекте. Это говорит скорее немного о ином: ей/ему интересны несколько областей разработки; просто чтобы всегда быть «в тонусе» и повышать свой профессиональный уровень гораздо быстрее, нежели его коллеги; иметь потенциальное преимущество перед другими кандидатами, при необходимости поиска работы (например, тебе могут закрыть глаза на необходимость тестовое задание и сразу перейти собеседованию).
П.С. А вообще, я не буду удивлен, если вдруг обнаружится, что человеку который тратил свое свободное время и занимался какими-либо проектами (или может даже поучаствовал в разработке существующих как-либо) получает более «вкусное» предложение о работе.
DistortNeo
Так и есть. Например, я никогда не работал фултайм, работал ровно столько, сколько хотел, а в свободное от работы время занимался своими проектами, которые мне интересны. При этом это был не фриланс, просто работодателям было все равно, как я трачу время, им были важны результаты.
В итоге сейчас мой доход существенно превышает зарплату, которую бы я мог получать при работе на полную ставку с жопочасами.
Kane
Раньше я думал также, но со временем стал находить баги в Open Source продуктах и фиксить их, реализовывать какую-то недостающую функциональность. Открытый код стал появляться сам собой.
0xd34df00d
А если я прихожу домой с работы и пишу свои всякие вещи там, о чём это говорит? Я недостаточно выкладываюсь на работе, что ли?
TheDeadOne
С высокой долей вероятности о том, что у вас нет жены и детей.
0xd34df00d
И правда, нет. А это плохо?
greendimka
Технически — это не является чем-то плохим.
С другой стороны: семья, как ничто другое формирует самодисциплину, умение ценить и оценивать не со своей колокольни, а с практической точки зрения. Семья очень сильно развивает эмпатию. Ну и да — с семьёй вы станете менее «крутым» с технологической точки зрения. Но еще не встречал ни одного такого «менее крутого», который бы жалел о том, что не так «крут».
0xd34df00d
Ну, самодисциплину можно и иными способами развить. Более того, есть основания полагать, что семья у вас разовьёт самодисциплину только в том случае, если у вас и так уже есть задатки, что ещё больше заставляет меня сомневаться в подобной её ценности.
Мне для этого хватило пообщаться с проджект-менеджерами.
Не для всех систем ценности и не для всех целей это важно и полезно.
Ну ещё бы они сказали (и зачастую думали) иначе :)
Я, кстати, встречал людей, которые радовались, что развелись и не создали в итоге семью.
NIKOSV
Господи, какие глупости. Наличие публичного кода как минимум означает наличие у разработчика страсти к программированию. Если у разработчика есть публичный репозиторий и домашние проекты это с очень высокой долей вероятности говорит что это хороший специалист. Я не говорю что те, кому нечего показать плохие разработчики, я говорю что те, кому есть что показать это хорошие разработчики. Они могут чего-то не знать, но они быстро научатся так как любят это дело и посещают ему даже свое свободное время. Так что если у компании 1000 резюме в день и нужно как-то их фильтровать — наличие публичного репозритория будет отличным первичным фильтром.
Idot
А если у меня публичный код никак не соотносится с моей работой?
У меня, например, публичный код на moddb.
Но, вряд ли какой кадровичке понравится такое "несерьёзное" хобби.
Sergiy
А если я последние 5 лет писал NDA код для большой организации? Мне ради вас все исходники выкладывать?
copist
Это боль. Опытный программист с NDA ничем не отличается от джуниора, только просит больше :) Главное что количество лет опыта никакой роли не играет. Приходится урывками нацарапывать решения типовых задач, чтобы гитхаб заполнить якобы ценной ерундой.
Simplevolk
Получается, если нет кода в открытом доступе, то сразу джуниор? А если джун поучаствовал в паре проектов, сделал коммиты, то он уже круче того разраба с NDA?
Вряд ли.
copist
Да и это ломает мозг :(
Когда переходил с проекта на проект, где невозможно показать код и обсуждать технические решения, помогали две вещи: несложные тестовые задания на 1-2 дня и устные технические собеседования. Задания обычно не под NDA и я их с чистой совестью использовал дальше для демонстрации хорошего кода, а некоторые и для своих нужд (например, сокращатель ссылок как тест и для себя)
На тостере дал ответ на такую же ситуацию https://toster.ru/q/449109#answer_1064583
Areso
У опытного программиста есть строчки в резюме, возможно в неплохих компаниях на неплохих позициях. Да, «ведущий программист в ООО Рога и Копыта» это не очень, но ведущий программист в Сбертехе уже звучит лучше, даже если там каждая строчка кода лежала под тремя NDA.
Опять же, рекомендации, общие знакомые, участие в конференциях и т.п., что делает специалиста более заметным в своей сфере.
botyaslonim
Это с какой радости опытный под NDA равен джуниору? Ну просто, из чего это логически вытекает? Разработчику поиска Яндекса в лицо скажете, что он джуниор?
svr_91
А мне вот честно интересно: какой открытый код (да и просто код) охота писать «любящим профессию» людей? Что вам не хватает в существующих решениях? Не придираюсь, может, и для себя что-нибудь интересное найду
Gemorroj
открытый код, это в т.ч. и пулл реквесты к существующим решениям, например.
svr_91
Опять же, что такое «пулл реквесты»? Исправления найденных ошибок? Как часто вы находите ошибки в opensource и после этого находите время, чтобы разобраться в них и исправить? И насколько молодые проекты при этом? И для каких целей нужны эти проекты?
Или «пулл реквесты» — это решение каких-то задач из внутреннего трекера? Что тогда вас мотивирует решать такие (вполне возможно, даже абсолютно однообразные) задачи?
Или «пулл реквесты» — это проталкивание своих идей в проект? Как часто у вас возникают такие идеи? Не боитесь ли вы своей идеей сломать всю идею самого проекта? Как часто ваши идеи принимают?
Kane
Мы фиксирует баги в OS проектах не для развлечения, а потому что сталкиваемся с ними и хотим решить свою проблему.
quasilyte
А вы пробовали? Обычно это приятно, внести свой, пусть и небольшой, вклад в то, что ты используешь. Это может быть любимый плагин к тектовому редактору или библиотека, которая упрощает тебе твою работу.
Не факт, что это универсально и нравится каждому, но трудозатраты обычно небольшие, рисков немного. В небольшие проекты minor изменения принимают достаточно охотно.
Самый простой вид «вклада» — это исправление неточностей в документации.
Обычно их находишь, если внимательно изучаешь документацию.
Какова мотивация их править?
Если ваc эти недостатки в документации заставили потратить лишнее время,
может захотеться сделать так, чтобы другой человек не потратил этого времени.
Такие изменения отклоняют очень редко.
balexa
Не всегда это имеет смысл. Ну вот из недавнего — понадобилось поправить реализацию рассылки эвентов в спринге под нашу задачу и поправить багу, которая воспроизводится при определенной конфигурации. Работы немного, код отделен от прикладной логики, можно ли это влить в спринг? Нет, ибо там достаточно сложная система релизов, а на работе надо получать кучу аппрувов на вливание кода в опенсорс. А у меня на работе хватает чем заняться, кроме того чтобы читать списки рассылки спринга, поверьте.
А в свободное время у меня есть тренировки и девушка. Да и некрасиво как-то втихомолку заливать в гитхаб кода с домашнего компа, сделанный в оплаченное рабочее время.
BOM
К каким именно решениям: @torvalds/linux или @vasyanpro/console-file-deletor?
DistortNeo
Меня всегда удивляет позиция программистов, которые считают, что абсолютно всё уже написано до них.
svr_91
Ну вот я и прошу примеры.
Понятно, что далеко не все написано «до нас». Но действительно ли на это стоит тратить время? Приведите примеры, когда собственная разработка упростила вам жизнь, в отличие от уже существующих разработок
AllexIn
А на что стоит тратить время в этой жизни вообще?
Ну и пример, например. :)
https://habrahabr.ru/post/275447/
Сделал для себя. Альтернативы либо отстой, либо проприетарные.
svr_91
Каждый сам решает.
Да, ваш пример хороший. Напрямую не связан с конкретной рабочей задачей, просто что-то из разряда «захотел и сделал». Хотелось бы побольше таких примеров, возможно от других участников open source
DistortNeo
Пожалуйста.
При поездке к заказчику оказалось, что работающая по HTTP железка формирует расходящийся со стандартом HTTP ответ. Браузер страницу отображает, но HttpClient из C# бросает исключение, типа, ProtocolError. В итоге за 1.5 часа просто написал свой собственный HttpClient. И пофиг, что он поддерживает не всё, главное, что работает с железкой.
Реализация MySql протокола. По какой-то причине родной MySql connector перестал работать (причину уже не помню). За 2 дня по мануалам с офсайта сделал свою реализацию, к тому же с нужными мне свистоперделками, которых не было в оригинальном коннекторе (асихронная работа с сетью).
Собственный кросс-платформенный кооперативный планировщик для тасков в C#. Существующий не устраивал низкой производительностью — низкий IOPS при выполнении операций с сокетами из-за высоких накладных расходов на await и переключений контекста. В итоге увеличил IOPS почти на два порядка, написав обёртку для сокетов и избавившись от переключения контекста.
Заменил tbb::parallel_for на свою реализацию за счёт снижения накладных расходов. Это позволило не думать о гранулярности задач.
и т.д.
svr_91
По первому примеру как я понял, это было нужно по работе (или близко с ней). По остальнвм примерам не понял, где это было нужно.
Видимо, я плохо сформулировал первый вопрос. Вопрос был в том, что вы делаете в отрыве от работы (либо напрямую не связанное с работой, что считать напрямую не связанной — остается за вами), а в том, что делаете для личных целей. Понятно, что все мы на работе пишем код, что-то оптимизируем, улучшаем и т.д. (правда, не все это рискуют выкладывать в open source)
DistortNeo
Всё, кроме первого — примеры задач, без которых можно было бы вполне обойтись.
Я их делал для себя, потому что мне это было интересно, а потом просто переносил в рабочий проект, потому что мог.
YemSalat
Почему собственная разработка должна обязательно облегчать кому-то жизнь?
Варианты «в целях саморазвития» и «для лучшего понимания каких-то концепций» — вы в принципе не рассматриваете?
svr_91
Я просто не верю, что саморазвитие может происходить за пределами продакшена :). Вот реально, я сталкивался с людьми, которые сначала изучают какую-то новую технологию дома за пару дней, говорят, что «все хорошо», внедряют ее в продакшен, а потом все плачут несколько лет кровавыми слезами. Так что умение просто быстро «изучить что-то новое» для меня не является какой либо целью. Если это исключительно в целях саморазвития, то я конечно, не против. Кто-то собирает марки, кто-то модельки самолетов, почему бы кому-то не изучать что-то из программирования. Но если это предполагается использовать в реальной работе, то кроме самой работы никто настоящего фидбэка по технологии не даст. Вспомните например бесконечные холивары на тему функционального программирования. Почти всегда есть те, кто говорит «функциональщина — это круто» и те, кто спрашивает первых «а использовалась ли эта функциональщина где-то в продакшене?»
Другое дело, если действительно идет речь о реально нужных проектах «для себя» или для кого-то еще. То есть, где опыт приближен к продакшену. Но тогда встает вопрос. где взять идеи для таких проектов (и время тоже)
Idot
Не знаю верить слухам или нет…
Но, слышал от нашего тим-лида, что есть люди, которые имеют привычку вместо написания кода гуглить подходящий код, а не найдя его могут глядя в глаза заявить, что "такое написать невозможно".
akzhan
нормальные мидлы без перспективы роста. тоже полезны бывают )
batyrmastyr
Как по мне — это младшие программисты, потому что сами думать не умеют или не хотят.
akzhan
Задачи выполняют не джуниорские, просто перегорели. так что — мидлы.
greendimka
Даже не знаю в чём они хуже — в программировании или в процессе гуглинга :)
Danik-ik
Это вообще-то формальный водораздел между техниками и инженерами. Техник только применяет ранее описанное решение, инженер — ещё и выбирает, создаёт и обосновывает. Что, впрочем, не мешает инженерам применять типовые решения при соответствующем обосновании. Первый читает инструкции, второй, если надо, может написать их.
Просто надо использовать таких людей на соответствующих ролях и грамотно ограничивать их способность к "навредёжу".
mustitz
Ну… понимаешь, основная причина в том, что существующие решения это неинтересно. Кому-то нравиться собирать решение их готовых блоков, кому-то нравиться создавать эти блоки.
Например, мы со знакомым обсуждали написание быстрого покерного калькулятора (5-7 карт). Одно из самых быстрых решений — использовать некоторый конечный автомат в виде массива, чтобы ранг комбинации вычислялся линейным кодом ...fsm[c3+fsm[c2+fsm[c1]]]… Это работало быстро, но массив fsm как-то надо сгенерировать. Можно найти готовое решение для семи карт Texas Hold`em.
Поиск по интернету ничего не дал, с другой стороны я не очень то и искал. Так возник проект yoo-ofsm где я реализовал построение таких конечных автоматов, что было использовано для семикарточного конечного автомата для омахи и 5-7 карточных автоматов для Six Plus Hold`em.
Также, занимаясь вопросами перебора комбинаций я перевёл на битовые операции известный алгоритм Д. Кнута. Получилась статься Битовая магия: получение следующего лексикографического сочетания. Нет, я вполне допускаю, что погуглив, можно найти этот код где-нить в дебрях интернета, но я сходу не нашёл, а самому написать не так чтобы и долго.
lagranzh
Я на своей нынешней работе, выложил пару проектов на гитхаб, с разрешения работодателя, естественно.
Если кусок кода может быть полезен другим, и не является бизнесс-логикой того чем занимается фирма, то почему бы не поделиться?
Idot
А если публичный код — это множество человек в GNU-проекте?
И как быть, если этот публичный код не связан с вакансией?
У меня, например, публичный код на C++ в качестве хобби, но у нас на него нет вакансий и на работе я его не использую.
fillpackart
Если вы говорите, что вы отличный react-разработчик, а я вижу только ваш код на C++ и он мне нравится, возьму без вопросов. (Хотя кого к чертям я возьму, я сам рядовой разраб с фан кодом в паблике)
da-nie
Вы мне лучше откройте секрет, почему куда ни глянь (я про статьи), всем нужны алгоритмы STL и структуры данных. Бесконечные сортировки и оптимизации деревьев. При этом я за 23 года практики (от спектрума до PC через всякие PSP и микроконтроллеры, начиная от бейсика, паскаля, пачки ассемблеров и Си++) твёрдо уверен, что 90% почти любой программы — это интерфейс (то, что обеспечивает работу с основным алгоритмом программы). А основной алгоритм, обычно, очень небольшой. И в нём все эти деревья и сортировки нафиг не нужны. Вот сейчас, к примеру, мне потребовалось по заказу начальника написать некий аналог платного Lider Task — захотелось начальнику раздавать задания по отделу, но не покупать коммерческие аналогичные продукты (redmine не подходит — у нас XP, а ему нужна 7 минимум (да и не работал я с ним, так что не знаю, что он умеет)), а по моему проекту как раз перерыв, и я в целом, свободен месяц. Что я там использовал? MFC+OBDC+вектора+списки+строки (CString — т.к. stl реализации не гарантируют корректную работу при многопоточности). Сортировка всего в одном месте есть — задания по датам. И всё. 90% кода клиента — менюшки, отображение заданий с картинками и поток работы с сервером по сети через обычные сокеты, Ничего больше там просто нет. Сервер тоже не страдает всеми этими «алгоритмами» — поток приёма-передачи и отображение списка пользователей, да плюс работа с базой данных через OBDC. Иными словами, практически ничего из постоянно требуемого в вакансиях на Си++. И вот таких программ у меня дофига и больше — от систем управления комплексами до стендового оборудования с обработкой данных калибровок и испытаний. Вот я и недоумеваю, откуда тогда такая необходимость в этих самых алгоритмах? Что они там непрерывно сортируют и хранят?
roman_kashitsyn
Что означает "при многопоточности", и как именно CString исправляет ситуацию? В документации ничего про многопоточность не сказано https://msdn.microsoft.com/en-us/library/ms174288.aspx
std::string можно использовать в многопоточных программах. Проблемы будут только в том случае, если изменять объект строки из разных потоков без блокировок.
da-nie
std:string может иметь одну пакость — когда я пишу
Я ожидаю, что a и b — два разных объекта. Но stl так может не думать — в целях снижения расходов памяти она может в b приравнять указатель на строку, хранящуюся в a. Если у меня a и b в разных потоках, то меня ждёт сюрприз. Вот тут это описано у Борескова: http://steps3d.narod.ru/tutorials/c-minus-minus.html
Так MFC поддерживает мультипоточность и CString, соответственно, тоже. «The Microsoft Foundation Class (MFC) library provides support for multithreaded applications.» ( http://www.tutorialspoint.com/mfc/mfc_multithreading.htm )
da-nie
Вот у Борескова:
Kobalt_x
Это в каких таких махровых реализациях std::string cow?
DistortNeo
Ну видимо, в 2003 году такие существовали.
da-nie
Они и сейчас существуют с вероятностью около 100%. Вот смотрите, беру я, скажем, QNX 6.3 — а я под неё много пишу (ну ладно, ладно — я там между потоками string не передаю). Почему её, а не последнюю? Потому что дорого последнюю брать. Есть у меня уверенность, что там COW в реализации stl отсутствует? Никакой.
F0iL
Начиная с C++11, COW для std::string официально недопустим согласно стандарту.
Если вы пишете код и компилируетесь под более старые стандарты плюсов — другой вопрос, и это в целом грустно.
da-nie
А вы год выпуска QNX 6.3 посмотрите. :)
DistortNeo
> Я ожидаю, что a и b — два разных объекта. Но stl так может не думать — в целях снижения расходов памяти она может в b приравнять указатель на строку, хранящуюся в a.
Обоснуйте. Такое хранение строк в std::string в принципе недопустимо, т.к. к строкам можно обращаться посимвольно и эти символы менять. И сюрприз будет ждать даже если всё делается в одном потоке.
> Вот тут это описано у Борескова: http://steps3d.narod.ru/tutorials/c-minus-minus.html
String interning — нормальная вещь. Но для мутабельных строк его применять нельзя. Если какой-то компилятор решил это сделать для мутабельных строк, используя игры с флагами и CoW, то таким компилятором пользоваться не стоит. Сейчас так никто не делает.
da-nie
Да, пишут, например, что в CGG такое встречается.
Что именно обосновать? Такое хранение строк использовалось (поищите в инете — найдётся всё) и, как оказалось, и сейчас используется в MFC. Вот когда вы начнёте менять строки, вот тут они и будут разделены. Но не раньше. Теперь следите за потоком: например, потоку сервера нужен введённый в основном потоке порт сервера. Он что делает? Блокирует, скажем, мютексом, общую переменную и копирует строку себе в другую строку. Освобождает мютекст и планирует работать дальше с копией переменной. Но COW просто копирует указатель — строки-то одинаковы с его точки зрения. И тут основной поток убивает строку. :) Сюрприз.
Никогда не знаешь, куда будет портироваться наработанный код.
roman_kashitsyn
Какой в этом случае сюрприз-то? COW не просто копирует указатель, но ещё и увеличивает счётчик ссылок. Строка удаляется только в том случае, если счётчик ссылок стал равен нулю. Причём инкремент в современных компиляторах будет атомарным, если собирать с правильными флагами.
Если у вас версия COW-строк, которая не умеет атомарно увеличивать счётчик, то копирования под мутексом должно быть достаточно для корректной работы.
roman_kashitsyn
Ещё подумал: нет, не достаточно. Потому что при вызове деструктора тоже атомарно нужно счётчик изменять, иначе память утекать будет. В общем, COW строки должны использовать атомарные счётчики ссылок для корректной работы в многопоточной среде.
da-nie
И атомарное разделение. Но std:string такого никогда не гарантировал.
da-nie
Счётчик ссылок хорошо изменять когда объект заблокирован. Но смотрите, поток дальше со своей переменной обращается безо всякого мютекса. Он, этот поток, ведь делал копию строки себе не просто так, а чтобы пользоваться ей независимо от основного потока. А в этом случае получается, что доступ к объекту больше не связан с примитивами синхронизации. Мы думаем, что работает с копией, а на самом деле работаем с самим объектом. Где гарантия, что не произойдёт переключение потоков в момент смены состояния этого самого счётчика ссылок или разделения строк в обоих потоках?
da-nie
Пардон, по ссылке только про организацию потоков.
И что самое обидное, CString всё-таки использует Copy On Write. :( Жаль, я был уверен, что указание использовать многопоточные dll заставит MFC не применять COW.
Придётся переписывать со своим классом строки. Жаль.
F0iL
А зачем свой класс? Судя по упоминаниям в сети, компилятор Visual Studio уже очень давно не использует copy-on-write для стандартных std::string и std::wstring
http://shaharmike.com/cpp/std-string/
В любом случае, это довольно легко проверяется: http://cpp.sh/83s6
da-nie
Не, я уже всё переделал для собственного класса CSafeString. :) Мало ли куда я потом это всё портирую, так чтоб наверняка быть уверенным, что никаких сюрпризов меня тут не ждёт.
valbok
Записывайте, алгоритмы STL + структуры данных нужны чтобы вы когда захотели сменить работу на более «перспективную», смогли бы это сделать.
0xd34df00d
95% программ из тех, что я пишу, вообще не имеют интерфейса, и занимаются этими самыми и алгоритмами. Их кроме сортировок и хранения ещё много.
da-nie
А вот это интересно. А чем именно занимаются такие программы?
Я чего спрашиваю-то, вот есть у меня программа калибровки прибора. Ей нужны около 40 каталогов с данными вращений на стенде в разных плоскостях. Окей, загружаем всё это в память. Дальше эти данные нужно между собой усреднить, найти в них точки ступенек (где стенд делал паузу) и в этих точках усреднить показания по ступеньке, исключая переходный процесс между ступеньками. В результате получаются точки калибровочной кривой. По ним строится модель погрешности, по которой вычисляются отклонения от идеала и делается общая оценка качества калибровки. Вот и всё. Данных обрабатывается дофига и больше, но почти ничего вот из этого там нет и в помине. И вот ни разу не требовалось, как ни странно.
0xd34df00d
Компилятор. Некоторая хитрая система классификации текста. Всякое такое.
da-nie
О! Для компилятора алгоритмы, действительно, пригодятся.
F0iL
Из недавнего:
Проект в сфере мультимедиа (немного обобщенно, чтобы не сболтнуть лишнего).
На вход нам приходит XML-документ, он парсится, и в нем мы получаем огромную кучу блоков с полями вида «время начала», «время окончания», «некие данные». Временные метки могут идти в любом порядке (стандартом не регламентировано), временные диапазоны могут как угодно пересекаться.
Нам же на выходе нужно сгенерировать такие блоки, чтобы временные метки были в определенном диапазоне и не пересекались, а каждый блок содержал именно те «некие данные» (сохранением изначального порядка относительно друг друга), которые относятся к этому диапазону времени, и добавить их к уже существующим (распарсенным ранее).
С помощью STL-алгоритмов эта задача решается очень просто и с удовольствием:
— c std::transform и лямбдой-функтором выбираем только все (и начальные и конечные) временные метки из объектов в новый deque
— c std::remove_if и лямбдой-предикатом выкидываем те, которые не относятся к требуемому диапазону
— с std::sort сортируем метки по времени
— с std::unique оставляем только неповторяющиеся
— resize'им/shrink'аем наш deque до нового размера с std::distance
— с std::merge сливаем новые временные метки с теми что уже были ранее
— с std::for_each для в итоге для всех полученных и старых временных меток выбираем с std::find_if «некие данные» которые попадают под конкретный диапазон и генерируем новые блоки.
Опять же, это действительно реальная (с небольшими допущениями) реализация задачи, с которой пришлось столкнуться на практике.
vt4a2h
С boost::range, а лучше с range-v3, всё должно существенно красивее получится, чем с просто STL :)
F0iL
Вроде в 2020-м году ranges обещают в стандарт принять :)
da-nie
А разве нельзя всё это сделать за один проход, совместив почти все эти операции? Просто у вас получается последовательности: выбрали, отсортировали, выкинули, слили. В этом случае stl просто не применяется, программа становится сложнее, но скорость работы выше. Я всегда шёл именно таким путём, если оператор не согласен подождать, пока файлы обрабатываются (я обрабатывал когда-то телеметрию со спутника — там похожие обрывки с временем и битой информацией).
alexeykuzmin0
Зато читабельность кода выше.
da-nie
Конечно, выше — с этим не поспоришь.
F0iL
А как вы себе представляете все это за один проход, можете чуть подробнее расписать идею?
В целом в замечании вы правы, как я выше сказал, пример обобщенный и с допущениями для большей наглядности и демонстрации «для чего оно может пригодиться» — по факту же алгоритм был оптимальнее, выборка меток происходила сразу вместе с фильтрацией, сортировка и дедуплицирование были уже на контейнере всех накопленных значений (без merge), и т.п.
Без STL'ных алгоритмов в любом случае не обошлось, да и код понятный и помещается в десяток строчек, как уже отметили ниже :)
da-nie
Да в общем-то примерно так, как вы расписали я и представляю. :) Скажем, чтобы не убирать повторяющиеся, я бы их просто не добавлял бы. Ну и так далее. Я же специфики задачи вашей не знаю; я просто предположил, что это возможно. :)
gramotnii
Классная статья. Попасть на такой собес мне было бы приятно, но увы… пока не попадались
phillennium
«Всё началось, когда автор Ruby on Rails признался миру...»
Насколько могу судить, всё началось с блог-поста yegor256, а Дэвид подключился уже потом.
nazarov_tech Автор
спасибо, интересное замечание! Вполне допускаю, что так и было.
Но именно пост dhh стартанул вдохновивший меня tweet storm, поэтому я привёл его в эпиграфе. Пост Why I Don't Talk to Google Recruiters тем не менее указан в материалах для чтения.
moonster
Чтобы понять, хорош ли ли человек в работе, нужно с ним поработать. Другого надежного способа нет.
SADKO
… дорогое удовольствие, однако
greendimka
Еще дороже выходят заваленные проекты от тех, кто хорошо сортирует пузырьком… ну и на этом знания заканчиваются, если утрировать.
SADKO
… а я и не утверждаю что сорт, хороший индикатор, у меня свой набор методов, и предложить человеку сорт, мне даже в голову не придёт именно по той причине, что эта задача избита, сознательно или не осознанно человек может тупо знать решение… Так что даже в качестве задачки «на посмотреть» сорт не канает…
Кроме того, когда я задаю задачки, они обычно совсем простенькие, по теме вакансии, но при этом меня не разу не интересует правильность ответа, но это всё магия и колдунство профайлинга.
x67
Заговорили про заваленные проекты и что-то вспомнился один вопрос на тостере) Хотя тут больше про эффективный менеджмент, нежели про сортировку
seniorcote
Ну так это бизнес, кому сейчас легко? А скупой, как известно, платит дважды.
copist
Массовые наймы?
Первым этапом не код писать, а парами-тройками разбирать постановку задач и декомпозировать для других команд.
Вторым этапом обсуждать между командами постановку, декомпозицию и прикидывать решения
Третьим — решать.
Получается технические навыки на втором этапе (частично) и третьем. Возможно отсеивание кандидатов, не способных понять задачу, согласовать между коллегами, выбрать решение — это важнее самого решения.
GarryC
Ну не знаю, я как то не уверен, что корреляция с умением жонглировать будет столь же значимой в определении способностей к программированию, как и знакомство с алгоритмами.
И и тестом на IQ не все так просто — да, в каждом конкретном случае он может давать сбой, но корреляция налицо и если Вы сможете предъявить высококлассного интеллектуала, который даст на тестах меньше 120, я буду крайне удивлен.
Так что резюме — ректрутингу нужен какой то формальный показатель, и лучше, чтобы он был связан с профессиональной деятельностью. Не знаю, как у Вас, но у меня нет времени час беседовать с каждым кандидатом и угощать его колой, наверное, мне просто меньше повезло в жизни.
rmpl
Самое страшное, что можно сделать – нанять в команду неподходящего человека. Час – очень короткое время для хорошего собеседования, круто, что автор поста успевает :)
valbok
Сперва надо сделать скрининг и допустить до собеседования только «адекватных» претендентов, на них и можно/нужно тратить время.
Doktorov
Тесты на IQ придумали в начале 20 века только с одной целью, что бы понять освоит работник станок или нет. В 21 веке это рудимент прошлого.
copist
Горький опыт показывает — не потраченный оплаченный час или два на собеседовании (с колой и фруктами) стоит компании килобаксы на зарплату неподходящего кандидата.
terrier
Ну, тема давно уже пережеванная и сложно предполагать, что прямо сюда придут тимлиды Яндекса и будут заливаться слезами раскаяния, с криками «А ну, вот теперь-то мы поняли, что наше интервью плохое, спасибо, что научил нас, мистер ноунейм». Результат критерий правильности курса. Вот если ваша компания за счет своего передового процесса найма сможет создать потрясающий IT-продукт, то значит верные мысли излагаете, а нет — возможно где-то закралась ошибка.
Отдельно однако, рассмешил скриншот в пункте «Вообще-то это требуется на практике». Почему чуваку кажется, что CAP-теорема нужна только для создания своей базы данных? По большей части она применяется для анализа уже существующих распределенных систем. Или ему кажется, что хоть CAP, хоть создание собственной СУБД, хоть монадные трансформеры — это все одинаковый космос и выдумки очкариков, чтобы отвлечь айти-работяг от эпической битвы реакт вс ангуляр?
По зрелому размышлению вопрос в открытой формулировке «А что вы думаете о CAP-теореме?» вполне нормальный для человека, который будет проектировать хоть что-то распределенное. Хотелось бы узнать читал ли кандидат хоть какую-нибудь теорию по предмету. К сожалению, парней «от сохи», осваивавших предмет методом тыка в проектировании распределенных систем ждет много неприятных сюрпризов
nazarov_tech Автор
спасибо за чёткую критику!
Тема безусловно пережёванная, но воз и ныне там, отсюда и статья. =)
На Яндекс я повлиять не рассчитываю. В конце концов, у них очень свои кейсы и своя атмосфера. Я скорее пытаюсь сказать людям, что «вы — не Яндекс».
Ситуация с CAP-теоремой двоякая: с одной стороны — да, из этого можно приготовить интереснейший диалог про подкапотности баз данных. С другой стороны — зная, как интервьюеры обычно используют такие вопросы… (фигово используют, обычно даже бинарно: ты либо ответил, либо нет).
maxru
Ну тогда вопросы не к вопросам, а к интервьюерам?
Как в анекдоте про стеклянный хрен.
teux
> что «вы — не Яндекс»
Среагировал на фразу. Вообще Яндекс тоже не во всем Яндекс ) Их успех заложен в 2000-х годах. И с тех пор они мало полезного дали миру разработки, в отличии от того же Фейсбук. Хотя попытки были, да.
Мне больше интересен взгляд соискателя. Так вышло, что профессионально проходить собеседования научился раньше, чем стал разработчиком. Вы и сами знаете, что хитрые задачки не ставят целью получить правильные ответы. Банальное «оценить способность к рассуждению» часто является целью.
Но бывают наниматели, которые меряют соискателей по себе. Имею в виду технических лидов. Причем, подготовившись и зная ответы на свои хитрые вопросы, они оценивают соискателя на предмет «достоин ли предстать их светлы очи».
Пусть они умны, но такие ожидания, имхо, от недостатка жизненного опыта. Ты берешь человека, и скорее всего, будешь растить спеца под свои специфические потребности. То есть тебе нужна способная заготовка. Или тебе нужен универсальный специалист? Тогда при чем тут хитрая задача? Поменяйтесь местами с соискателем, и он задаст две подобных задачи, на которых у нанимателя не будет ответа.
Справедливости ради, я не часто встречал такое отношение, и оно не раздражает в случаях, если:
— вижу, что на позицию действительно требуются специфически подготовленные по теме люди. Например, это могли бы быть исследования в части поиска Яндекса, или тестирование безопасности у Касперского.
— компания столь шикарна, что за дверями очередь супер-профи соискателей. Но HR любой топ-компании скажет, что такой очереди нет.
— Хороший тимлид ищет человека, очень совместимого с ним. Позицию не разделяю, но понимаю.
В остальных случаях скорее сочту, что менеджмент в компании гниловат, и, вероятно, досрочно закончу собеседование (соискателя никто не лишал такого права).
copist
Люди ищут окружение с совпадающей точкой зрения и похожим уровнем компетенции. С сомнением смотрят на тех, кто лучше (можно ли мне у него научиться быть лучше?) и на тех, кто хуже (способен ли он научиться быть как я?). Ну не все конечно. Есть открытые для улучшения и есть готовые улучшать других.
В книге Tribal Leadership хорошее объяснение с примерами.
VovanZ
Именно так им всем и кажется. А потом появляются
kolu4iy
Знаете, плохо так писать, но моё субьективное впечатление — после смерти Сегаловича яндекс перестал быть торт. Медленно, но неотвратимо он становится еще одной конторой по зарабатыванию денег, а не вершиной российской ИТ-мысли.
Подтверждение — продукты. Которые раньше хотелось использовать, а сегодня они скорее навязываются. Яндекс-карты/навигатор — пробки стали врать сильно, зато подсели таксопарки, яндекс-маркет — кнопка «купить», а ассортимент сужен и развития в фильтрах (которые как раз и нужны для адекватного выбора) — нет, и т.д.
dimm_ddr
Вы видимо забыли засилье яндекс бара. И чут ьпозже в 9 из 10 софтин галочку для установки чего-то еще от яндекса. В плане навязчивости нынешний яндекс это намного лучше того что было. В остальном, впрочем, не спорю.
DistortNeo
Ну с Яндексом всё просто. Туда по инерции ломятся сильные выпускники лучших вузов, стремящиеся работать в "самой крутой" компании в стране.
Как следствие — они находятся в конкурентной среде таких же талантливых работников, что занижает ЧСВ работников и усиливает ЧСН (чувство собственной некомпетенции). Это сдерживает зарплатные ожидания работников. Крытые программисты в мелких компаниях вполне могут зарабывать больше.
Ну и ещё один момент: большинство программистских задач — рутина, и Яндекс здесь — не исключение. Это пример того, как ожидание не соответствует реальности.
VovanZ
Как будто что-то плохое.
Aingis
До изобретения Директа Яндекс, внезапно, такой не был вообще. Да и после на первом месте в приоритетах стояли пользователи. Сейчас это тоже декларируется по инерции, но по факту два года назад пошёл тренд на экономию. Цели ставятся соответствующие — заработать больше денег.
Закрыли и заморозили побочные проекты. (Видели ужасную схему метро? Ей никто не занимается.) Курс доллара вырос — затраты на технику выросли, а зарплаты — нет (за исключением некоторых «ключевых» сотрудников по слухам). И та зарплата, что была ещё более-менее до конца 2014 года, стала уже не очень впоследствии. Многие свалили, кто за границу, кто ещё куда.
vt4a2h
Занимается, к сожалнью. Вот с год назад, кажется начали… Там теперь есть реклама и периодически предложение скачать яндекс браузер! Лучше бы не трогали схему метро)
Aingis
Это эксперименты над монетизацией мобильных приложений в принципе. Схема остаётся той же, разве что ) добавляются станции разработчиком. (Даже не дизайнером!) Реклама, вроде, отключается в настройках.
VovanZ
Кажется, вы не понимаете, как работает капитализм.
Aingis
А вы? Капитализм — это конкуренция, а с таким подходом в XXI веке конкуренцию не выиграть. (Впрочем, Гугл примерно такой же, с поправкой на масштаб.) В лучшем случае будет прозябание на лаврах. Это как Нокия выпускала пресс-релиз: «зато мы выпустили первый телефон без антенны» в век айфона.
xom9lk
Вспоминаю собеседование в ТОП ру-айти компанию — белая доска, задачи на время.
И, блин, просто убило:
-Я: Можно сначала я хотя-бы на листочке, на достке вообще не комильфо — шея затечет, рука устанет?
-Разраб ТОП ру-айти компании: Нет!
P.S. Еще и ЗП низкая.
maxru
Потому что это честь — работать у них!
UPD: Я не справился с тегом sarcasm :(
wataru
Ну это прямо идиотизм какой-то. В гугле, вон, уже давно дают ноутбук и печатай на нем. Правда, без подсветки и автодополнения, но и компилировать не просят. Просто удобная замена доске.
xom9lk
Там и ноутбук давали, просто один из этапов — доска. Не знаю, принято ли так в компании или это инициатива разработчика.
DandyAndy
Какие странные у программистов собеседования. Инженером устраивался, по специальности, после предварительных вопросов на «в теме» или нет, диалог:
— Ок, остался тест на 180 вопросов.
— Ха, не, не хочу.
— Ну и ладно, когда сможете приступить к работе?
noktigula
Как-то собеседовался в банк, последним пунктом шел похожий тест. Я согласился, прошел и спокойно пошел по своим делам. Минут через 20 перезвонила HR и стала уговаривать пойти к ним. Я тогда еще долго удивлялся, как так быстро результаты получили… А ларчик, видимо, просто открывался — я наверное был единственный, кто согласился тот тест пройти =)
P.S. Банк был хороший, работать я к ним не пошел, конечно
maxru
А что, если цель всех этих вопросов про деревья и алгоритмы сортировки (подставить нужный вариант) не для того чтобы проверить формальное знание алгоритмов, а просто для выяснения, есть ли математическая "соображалка" хоть какая-то и оценить ход мыслей, формализацию задачи и т.д.?
А, нет, показалось.
nazarov_tech Автор
цель именно такая, но не работает же.
Нет материалов, показывающих корреляцию таких вопросов про деревья с тем, как человек у вас потом будет перформить. (Зато есть материалы, показывающие, что такой корреляции нет — я даже в статье привёл).
naething
Так что, я не думаю, что из этого ислледования можно сделать вывод, что собеседование никак не предсказывает будущую производительность труда.
bfDeveloper
Ну вот опять 25. Почему все постоянно пишут, что алгоритмы никому не нужны. Если они не нужны вам, чтобы делать сайтики, то это не значит, что они не нужны никому. Я вот ни за что не возьму на работу человека, у которого есть высшее профильное образование, а он не знает, как оценить сложность алгоритма сортировки. Или высшее математическое без умения перемножить две матрицы на доске. Оба этих навыка мне нужны примерно раз в месяц, то есть постоянно. Отсутствие базовых навыков говорит о полном нежелании разбираться в том, как всё устроено.
Ну и логические задачки тоже могут быть полезны. Далеко не всем и не везде, но обычно в команде нужен хотя бы один круто соображающий человек для решения нестандартных проблем. Дебаг редко воспроизводящегося бага — очень сложная логическая задача, иногда нужны не инструменты и опыт, а просто мозги. Разумеется опыт первичен, а алгоритмы и логика вторичны, если вам нужен работник прямо сейчас. А вот для джунов всё наоборот — можно научить умного интересующегося человека, но раскачать логику «опытному» программисту на грани невозможного.
DrFdooch
об этом же и написано в статье — если у вас в проекте перемножают матрицы — спрашивайте об этом. если не перемножают — не спрашивайте.
и большинство («все» в вашей терминологии) действительно делают сайтики. что поделать.
bfDeveloper
Видите ли в чём дело, обычно не перемножают. А того, кто этим занимается каждый день, нужно спрашивать более сложные вещи. Проблема часто не может быть решена на том уровне, на котором создана. То есть квалификация кандидата должна быть выше, чем уровень повседневных задач. Кроме того это индикатор общих и частных знаний — насколько глубоко человек погружается в ту или иную тему, на сколько интересуется смежными. Умножение матриц действительно считаю минимальным возможным знанием в геометрии и алгебре. Так же как и геометрический смысл и идею аффинных преобразований. Неспециалисту не надо влёт писать матрицу хитрой трансформации, но хотя бы представлять, как это работает.
С большинством проблема — оно создаёт стереотипы и ожидания. И такие вот статьи укрепляют стереотипы, что можно особо не учиться и пойти работать, обесценивают высшее образование и тд и тп. Может вместо выкидывания вопросов из собеседования лучше просто поднять общий уровень и научить решать эти задачи? Может так мы поднимем общее качество софта, которым пользуемся?
nazarov_tech Автор
не поднимем.
Потому что плохое качество софта много чаще вызвано иными проблемами:
Высшее образование тут тоже не поможет, к сожалению, хоть многие на него и уповают. Разработка сугубо практическое ремесло, да ещё и устаревает с адской скоростью.
valbok
Все эти проблемы влияют на бизнес в целом или на продукт в частности, но как это отменяет качественное инженерное решение конкретной задачи? Для которой требуется достаточная квалификация.
webkumo
Ну вот так и влияет: на одну задачу времени хватило для грамотного решения, а для второй — уже срок горит. И лепится костыль, или тестирование задвигается глубоко в ...
DrFdooch
но качество софта не связано с теоретической подготовкой в математике. или в другой «большой» науке. даже недостаточную подготовку по алгоритмике и железу я не могу назвать Главной Проблемой, Которую Надо Решать.
проблема в том, что нет именно инженерных дисциплин разработки софтверных систем. есть теория, которая простирается от высшей математики до конвейеризации вычислений. и есть миллионы программистов, пишущих плохой код (и создающих плохие системы). и между этими явлениями нет связующего звена. нет того, что позволяет однозначно ответить на вопрос «как решить мою задачу с вот этими параметрами?». из этого все сложности с наймом.
и это естественно, это из-за молодости всей сферы. я даже сходу не могу придумать какую-то другую сферу деятельности, в которой у человечества было бы настолько мало опыта. только понимая это, можно адекватно оценивать всё происходящее: рандомный найм, чехарду технологий, громоздкую архитектуру, пахнущий код, падающие приложения и сервисы…
Rezzet
Дружище, сам лично писал перемножение матриц и не один раз для разных проектов, беда в том что это было последний раз 10 лет назад, сейчас не уверен что вспомню как это правильно делается, не говоря о том что смутно помню что такое векторное и скалярное произведение, хотя четыре года назад писал физику для шутера типа квейковского, сам своими руками делал алгоритмы пересечения, расчета расстояния между разными геометрическими примитивами и трасировку луча к ним, могу даже коммиты показать в репозитории. И что меня вот вы бы не взяли? Уверен что не взяли бы. Только вот вопрос в том что уже на практике доказал свою способность писать такого рода алгоритмы, просто со временем мы все забываем и помним только актуальное, и сейчас для меня это не алгоритмы пересечений.
AllexIn
Ну я вот последний раз умножал строчку на столбик лет 10 назад. Когда написал мат либу для своего графического движка. С тех пор не доводилось.
Если я попаду к вам на работе и там надо умножать строчку на столбик каждый месяц — через пару месяцев я буду делать это свободно без гугла.
Но я не попаду к вам в компанию, потому что не пройду собеседование, т.к. не вспомню что матрицы умножаются строчкой на столбик.
0xd34df00d
Это можно вывести, если вспомнить алгебраический смысл матриц и их умножения.
Хотя требовать этого на собеседованиях несколько жестоко, и обычно люди под линейной алгеброй всё-таки понимают всю эту матричную ерунду и «матрицы умножаются строчка на столбик потому, что я так сказал», а не настоящую красивую, собственно, алгебру.
AllexIn
Мало того, что люди чаще всего не воспринимают полностью исзодный смысл.
Так еще и большинство школ с ВУЗами этот смысл не преподают, а отдают в виде «вот вам строчка на столбик».
Поэтому ждать, что соискатель на программиста сможет объяснить истоки матриц или кватернионов — бессмысленно. Большая часть не сможет. Даже те, кто регулярно использует.
0xd34df00d
Ну, да. У меня в не самом последнем вузе страны (а скорее наоборот, ибо физтеховский снобизм же!) было весьма унылое матричное исчисление с широко известным в узких кругах Беклемишевым.
Уже после окончания вуза при самостоятельном чтении Шелдона Акслера ради интереса я начал как-то что-то понимать, а почему и зачем оно вообще вот именно так сделано и работает.
dimm_ddr
Вы вот об этой книге? Давно хочу добраться до чего-то с нормальным объяснением того, что проходил в ВУЗе, но найти что-то достаточно понятное и не занудное чтобы не бросить на первых страницах пока не получалось.
0xd34df00d
Да, она самая. Она офигенная, как по мне.
r-moiseev
Не подменяйте понятия, знание алгоритмов не равно алгоритмическое мышление.
bfDeveloper
А я нигде и не писал про знание алгоритмов. Алгоритмические задачки они именно про мышление, а не знание. Чтобы написать бинарный поиск или какую-нибудь сортировку нужно именно мышление. А за одно и проверка опыта обработки краевых случаев, знания известных проблем (все возможные переполнения и выходы за границу). Такие алгоритмы выявляют массу проблем, которые будут встречаться в коде.
r-moiseev
Нет не нужно. Можно заучить кучу алгоритмов, и даже их реализацию. Чем собственно и занимаются девочки-зубрилочки в ВУЗе. И что непременно сделает кандидат при подготовке к собеседованию на котором точно спросят.
valbok
На собеседованиях «чуть сложнее», так как вопросы обычно не афишируются перед екзекуцией, ну и совсем не сложно отличить «зубрилочек», от тех, кто соображает «находу».
r-moiseev
При устройстве в компании имя которых мы не будем называть всё всем известно, что и как спрашивают.
В компании попроще список технических вопросов предсказуем, по моему скромному опыту спрашивают везде примерно одно и то же.
Насчет отличить зубрилочек, у многих даже не стоит такой задачи. Если пошли вопросы в таком духе, интервьюер с высокой вероятностью и ожидает ответа по учебнику.
valbok
Приятно слышать, что известны задачи до собеседований. И если кто-то может их решать, хотя бы просто дома — приятная новость, является инетересным-перспективным-желанным кандидатом. Даже если зазубрили, это ж основное правило программистической карьеры — имитация и мимикрия, что щедро оплачивается.
Color
А либы, либы то на что?
Как по мне, так более важной проблемой является как раз незнание/непонимание более абстрактных сущностей (специфичных для программирования), как принципы и подходы (GRASP/SOLID/<подставьте нужное>), зачем нужен рефакторинг, зачем бить проект на модули и пр.
Потому как если нужно перемножить матрицы, человек может почитать вики и научиться этому за час (а лучше подключить либу). А если нужно понимание, зачем нужна высокая модульность и почему не нужно всю логику лепить в один объект, то на это может уйти год и более.
Для программиста на первом месте не знания, а умение эти знания получать.
DistortNeo
Если внутри проекта вам нужно это сделать только один раз, то вы потратите гораздо больше времени на поиск и подключение этой либы, чем на написание и тестирование кода, если вы знаете, что такое матрицы и как их перемножать. Плюс лишняя зависимость — плохо.
Ну и в моей области (обработка изображений) практика показывает, что человек, который умеет жонглировать OpenCV, scipy и т.д, но не способен самостоятельно написать велосипед, профнепригоден. Он не понимает, как устроены эти функции под капотом и не способен решить нетривиальную задачу.
Color
Зависит от задачи, никто не спорит. Речь шла про проект, где такие задачи возникают раз в месяц… а может вообще никогда. А вы приводите пример про обработку изображений. Понятно, что если ты каждый день работаешь с двумерными массивами, то подобные знания реально нужны.
И опять же, говоря про либы, я, конечно не говорил про OpenCV, драйверы и прочую "низкоуровщину". Умение сделать элегантный костыль или построить эффективный велосипед одинаково поощряется на низком уровне (абстракции) и порицается на высоком.
0xd34df00d
Если внутри проекта мне вообще нужно перемножать матрицы, скорее всего, я пишу что-то более-менее наукоёмкое, и, скорее всего, писал что-то похожее и ранее (а не вчера только из битв об ангуляре против CSS вылез), значит, у меня в арсенале уже есть знание, какие библиотеки способны мне дать такие базовые и широко используемые вещи, как умножение матриц.
Чего там подключать больше 10 минут в каком-нибудь dlib, MKL или вроде того?
Чем?
Так умение решать тривиальные задачи ничего не говорит об умении решать нетривиальные задачи.
bfDeveloper
Без знаний вам даже в голову не придёт, что вам нужно умножать матрицы. Я видел код, где из двух матриц трансформации вытаскивались компоненты сдвига и скейла, чтобы просуммировать руками и создать из них матрицу. В то время как надо было просто перемножить исходные. Это проще, это быстрее писать, быстрее работает. Или поиск минимума через сортировку массива. Такое сплошь и рядом, но это же полный бред. С точки зрения абстракций всё хорошо, так как очень мало кто включает алгоритмическую сложность в свой интерфейс.
Абстракции это очень важно, но это два ортогональных навыка: абстракции программирования и математическая подготовка.
Color
Зависит от задач, вестимо. Если векторная алгебра и есть предметная область вашей программы, то наверное разработчику будет неплохо ее знать. Уж точно это не будет минусом.
А в приведенном вами примере это именно отсутствие умения получать знания, о чем я писал выше. Встретив непонятную задачу, человек поленился разобраться в предметной области, а написал велосипед на основе того, как понял. Даже знай он ответ именно на этот вопрос, накосячил бы в другом месте так же.
А в этом случае даже беглое гугление дало бы ответ, как это сделать правильно. То есть, как правильно умножать матрицы, или какую либу для этого использовать.
Idot
На любимом тут Функциональном Программировании без хорошего знания математики, а именно лямбда-исчисления и всего с ним связанного, ничего толкового не напишешь.
Работать с готовой базой данных можно и без знания реляционной алгебры, но вот архитектору проектирующему базу её знание — крайне полезно.
0xd34df00d
Зачем нужно хардкорное лямбда-исчисление вне эта-абстракции и бета-редукции (обе весьма интуитивны)? Вы там каждый день комбинаторы неподвижной точки пишете, что ли, или обсуждаете, почему Hask is not a category и что в присутствии undefined и seq при некотором определении денотационной семантики языка эта самая эта-абстракция не выполняется?
valbok
> нужно перемножить матрицы, человек может почитать вики и научиться этому за час
тут скорее наоборот, проследите за собеседованиями в «топ-100» компаний. Умение разбивать на модули, и прочим архитектурным решениям, можно научить, и учат.
А вот есть «что-то такое»*, чему учить сложно, а может и дорого.
* Научить учиться, например.
Color
Я про это и написал же
valbok
Если вы про гуглеж, к сожалению, это не совсем так, хотя хотелось бы.
Color
Не совсем про гуглеж, но отчасти и про него.
Я про то, способен ли человек, встретив новую для себя задачу, самостоятельно разобраться в ее предметной области и выбрать подходящее решение. Гуглеж здесь — только инструмент для получения информации. Вопрос еще и в том, сможет ли человек эту информацию грамотно использовать, а также сможет ли заглянуть "за рамки" задачи, чтобы решение было гибким и устойчивым, а не "в лоб".
А то бывают люди с отличной теоретической базой, но как доходит до чего-то нестандартного, так сразу ступор и "нас этому не учили".
Sergiy
Вам шашечки или ехать? На работе зарабатывают деньги, нет никому дела до высоких материй. Если решение гуглится быстро и применимо на практике, так тому и быть. А «решать самостоятельно» этим можно заниматься от делать нечего.
Color
Зависит от контекста
valbok
Тогда не «умение знания получать», а «умение находить решения», причем еще добавляют, доступными средствами. Но чаще бывает, что даже со всеми средствами, поиск адекватного «решения», довольно сложный и трудоёмкий процесс.
И вот отсюда вопросы на собеседованиях, сможет ли человек «дойти» до решения сам, без помощи зала. Хотя пускай и с залом, но сам.
Фух, пришлось спалить контор, а то некоторые соискатели могут думать, что такими нерелевантными вопросами проверяют их память и насколько хорошо они когда-то зазубрили.
Color
Да, ваша формулировка гораздо точнее описывает то, что я хотел сказать.
Тогда и вопросы на собеседовании и можно разделить на в. про "знать решения" и в. про "уметь находить решения". Первое, по-идее, требуется компании для получения краткосрочных выгод в ущерб долгосрочным, второе — наоборот.
valbok
> вопросы на собеседовании и можно разделить
Не знаю открою ли я опять тайну, сказав, что опытные компании комбинируют оба подхода на проверку знаний и навыков, а еще есть общие вопросы про «жизнь», которые бывают важнее технической части. Ну и еще важным этапом собеседований — это референсы, может конечно не у нас, не знаю к сожалению ли.
bychok300
жиза, но вот жаль никто из HR так не рассуждает, все работают по старинке и реальные талантливые парни и девченки не проходят
nazarov_tech Автор
только здесь зона ответственности тимлидов и CTO, а не HR. Это же технические интервью.
teux
За них не волнуйтесь — алмаз в пыли не заваляется )
river-fall
Невозможно объять необъятное.
Количество специфических знаний растёт, сложность продуктов тоже. Сужается специализация.
Ко всему прочему последние 25 тысяч лет еще и мозг уменьшается.
Использовать готовые решения других людей — это ключ к прогрессу, который идет последние 10 тысяч лет. Знающие всё, но по чуть-чуть универсалы на рынке никогда не в цене.
Ну и известный факт того, что даже если взять такую простую вещь, как карандаш, то никто на фабрике, включая CEO, не знает, как от начала до конца произвести готовый продукт.
SADKO
… это потому что они там закупаются, а не продаются :-)
copist
Спросили как то меня, что нужно чтобы построить дом. Я перечислять устал.
Про карандаш — некорректный пример. Знает как минимум технолог, возможно тех директор. Это же ежедневный процесс, он всегда на виду, всегда мониторится.
river-fall
Технолог карандашной фабрики мало чего смыслит в лесоповале, станкостроении или добыче угля, не говоря об доставке электроэнергии или строительстве здания для фабрики.
greendimka
Из давнего опыта:
gosoo
Новый американизм подъехал. Уже не в первый раз вижу слово «токсичный» на хабре, раньше только у англоязычных встречал.
nazarov_tech Автор
ну он не слишком новый: википедия упоминает это слово из книги аж 1966 года. Подсказываю, много нахальней с моей стороны было употреблять слово «вайбоардинг» ^^
greendimka
gosoo имел ввиду то, что раньше слово «токсичный» употреблялось в качестве характеристики вещества, а теперь в качестве характеристики человека либо отношений в обществе. Это действительно американизм.
Gemorroj
почему американизм, а не англицизм?
тоже новояз какой-то?)
greendimka
Потому-что образованный британец скажет: rude, annoying.
Gemorroj
мне кажется, слово «англицизм» применяется не по государственному признаку, а языковому.
gosoo
Потому, что встречал у североамериканцев.
greendimka
Англицизм — использование английского слова в другом языке. Не путать с интернациональными словами. Встречается чаще всего в московской айти коммьюнити при оффлайновом и онлайновом коммьюникэйшене. В целом по России часто используется при выражении респекта и уважухи. Для человека, знающего английский, но не кичащегося этим — оба варианта признаки идиотизма.
Американизм — американский сленг, кочующий в другие языки.
batyrmastyr
В словарях уже давно стоят пометки, что это слово — из американского английского, а это — из британского и всё идёт к появлению меток для «австралийского», «международного» и «китайского» английского.
Так что деление как раз по языковому признаку.
Xandrmoro
Почему бы и нет, если слово характеризует явление точнее, чем существующие синонимы?
killik
Точнее это явление характеризует слово «вонючие», а «токсичные» это толерантный вариант, скорее всего )
dimm_ddr
Не соглашусь. Вонь можно перетерпеть, к ней можно привыкнуть, объективно она не страшна. Токсичность же уничтожает то, чего касается, обычно подразумевается что медленно, но верно. Ее неправильно терпеть, от нее нужно избавляться пока повреждения не слишком велики. Синонимом могла бы быть кислотность, но в таком смысле это слово я не встречал ни разу, никто просто не поймет.
И в данном случае предполагается именно мой вариант — подразумевается, по крайней мере я так понял идею автора, что такие практики собеседований не просто некрасивы или вызывают раздражение, но и наносят реальный вред.
killik
«Всё есть яд, и ничто не лишено ядовитости; одна лишь доза делает яд незаметным». Кому наносится реальный вред? Кандидату — ну так найдет другое место, с вменяемыми требованиями, и будет радоваться, что в это болото не засосало. Компании, теряющей годного сотрудника — туда и дорога, сами себе злобные буратины. Безмозглые дети начальников в HR — первый признак загнивания бизнеса, но проматывать наследство, добытое упорным трудом гениальных предков, с древних времен повелось. И это правильно, дряхлые дубы должны уступать место под солнцем.
dimm_ddr
Прямой вред компании, и косвенный, за счет уменьшения доступных мест — работнику. С одной стороны для работника это меньшая проблема, но при определенных условиях это все-таки проблема. Например если у кандидата нет опыта — большая часть компаний которая готова его взять будет так себе.
Ну и вообще раздражает же терять время на собеседования в таких компаниях. Если есть шанс изменить ситуацию, то почему бы не попытаться? Насколько я понимаю пост именно поэтому появился.
Но все-таки — вы согласны что слово "токсичные" здесь может подходить лучше чем "вонючие"?
RicoSam
«Как видите, никакого стресса и полная возможность показать знания-навыки.» — у меня опыт собеседования в exante самый негативный из всех. Сначала просто месяц ничего не отвечали, потом сроки постоянно затягивались: «мы вам ответим до конца недели», на деле ответ дали в конце следующей недели, после прямого вопроса. HR спрашивала по листочку технические вопросы. Никакого даже минимального фидбека компания компания не дала (не по 2м собеседованиям, не по тестовому заданию), отказали по причине того, что не могу перехать в Москву, хотя я рассматривал только удаленную работы и в вакансии была указана возможность удаленной работы.
nazarov_tech Автор
хм, вообще у нас есть негласное правило давать фидбэк всем, это даже во внутренней полиси («we're the good guys») было где-то прописано. Сейчас поглядим, что там произошло.
SADKO
Ну не знаю, на сколько такие компании как exante (офшорная без пяти минут кухня) в принципе могут быть «good guys»…
… вы уж определитесь, мальта вы или кипр, а если вы действительно такие good guys, вам бы регулятора по серьёзней, ибо конкурентные преимущества то вроде бы есть, но 10k$ слать на кипр как-то стрёмно…
EXANTEbrokerage
Не совсем понятно, почему вы считаете, что у нас несерьезный регулятор. Да, в дополнение к мальтийской мы действительно получили еще и кипрскую лицензию и теперь предлагаем клиентам два варианта. Но с лицензией мы получили +1 европейского регулятора, который еще пристальнее следит за нашей деятельностью. Теперь мы подчиняемся и MFSA, и CyCES.
Сейчас объясним, зачем все это нужно. Набор и стоимость услуг для двух вариантов абсолютно одинаковые и не зависят от юрисдикции. Однако при открытии счета с минимальным депозитом мы предоставляем клиенту юрисдикцию на Кипре, поскольку она предлагает страховку до 20 тысяч евро. Мальтийская юрисдикция не дает подобной страховки, поскольку для открытия счета необходима категоризация клиента как professional, а это в свою очередь предполагает более строгие требования к клиенту.
Так что, как видите, нет никаких поводов опасаться за средства, когда они застрахованы надежным европейским регулятором. Если есть еще какие-то сомнения, вы всегда можете пообщаться со своим персональным менеджером, задать вопрос в нашу поддержку или почитать FAQ.
nazarov_tech Автор
Константин, простите, вы не ответили в личке про фамилию, но вроде нашли вас и так.
Ответ от HR:
Бывает так, что в процессе подбора условия меняются (разработчики и сами наверняка с таким сталкивались). Увы, Константин как раз попал в один из таких этапов. HR извинялась за долгую обратную связь. К сожалению, не всё проходит идеально, но мы работаем над тем, что бы прокачать процессы в этом плане. Постараемся больше не вызывать подобного опыта у соискателей.
Sergiy
Типичная отмазка
nazarov_tech Автор
эй, don't shoot the messenger =)
varnav
95% компаний вообще не дают фидбек.
Те, которые дают, никогда не пишут «ну, мы взяли парня который оказался чуть получше, собеседовался за час до вас».
Обязательно напишут… Что-то вроде того что выше.
dimm_ddr
Мне как-то написали. К той компании у меня после этого претензий не было никаких.
varnav
Мне один раз позвонила начальница отдела, которая организовывала техсобеседование, и сказала что я не подхожу. Был крайне удивлён.
Nartis
Я один раз написал где-то 10 кандидатам письма с отказом и причинами. От одного из них потом получил два письма и один раз он звонил с просьбами передумать и доказыванием, что он на самом деле все знает и просто затупил. От одного письмо было с ехидным «не больно-то и хотелось, все равно я у вас работать не стал бы». После этого подобным писем больше не пишу, да и сам никогда не жду их
greendimka
Из-за 20% незрелых кандидатов вы портите себе репутацию. Вряд ли на вашу следующую вакансию откликнутся те, кому вы не удосужились сообщить об отказе.
Nartis
Получив формальный отказ без объяснения причин они тоже вряд ли откликнутся. Расписывать причины для этих десяти человек было моей инициативой, а не политикой компании.
Мне кажется наиболее правильным описывать причины отказа только кандидатам, которые заинтересовали вас и которые чуть хуже того, кто прошел
greendimka
Откликнутся. Практика показывает, что откликаются и весьма активно.
Что за дискриминация?
Соискатели могут отказываться от других должностей по той причине, что ждут вашего ответа.
Элементарный ответ «Извините, вы нам не подходите, желаем удачи в дальнейших поисках.» — это всё, что требуется. Нет надобности расписывать причины. Но сообщить кандидаты, чтобы он дальше мог планировать свою карьеру — это просто вежливость.
irezvov
Да, тоже как увидел что статья в блоге Exante решил почитать. В далёком 2013 был на собеседовании, хотел засвитчиться из форнта в Erlang(до этого в Яндексе уже пару лет поработал). Было 3 из 4 (викторины, головоломки, алгоритмические), потом долго тянули с фидбеком.
ToSHiC
Регулярно встречаются кандидаты, которые не в состоянии написать Fizz Buzz на листочке/доске на том языке, на котором они пишут, по их словам, каждый день. Вы правда считаете, что их всё равно нужно нанимать? Что написать 10 строчек кода без помощи IDE — это прям невероятный подвиг?
nazarov_tech Автор
Отличный вопрос!
Я лично считаю, что FizzBuzz как раз-таки на удивление неплохой тест для начала диалога. :) Почитайте Джеффа Атвуда про это:
Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".
Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes. Want to know something scary? The majority of comp sci graduates can't. I've also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.
https://blog.codinghorror.com/why-cant-programmers-program/
mike1
А почему они не могут написать? Тут можно четвертью мозга написать. Цикл от 1 до 100 включительно. Если число делится на 3 (то есть остаток равен 0), то выводим в stdout Fizz. Если делится на 5, то Buzz. Если ни то, ни то (ну тут нужно небольшое напряжение мозгов, чтобы как-то разрулить, что ни то, ни то — bool что ли какой-то заводить), тогда просто выводим число.
AllexIn
Может быть руководители проектов и прочие архитекторы уже не мыслят синтаксисом языка и поэтому не могут на доске такое написать.
Уверен алгоритм они напишут легко.
greendimka
Лично я без подсказки IDE никогда не помню что стоит на втором и третьем месте в конструкции for — где условие, а где изменение счётчика. Путаю постоянно. По этой причине с вероятностью 99,99% валю написание кода «на бумажке».
Правда я отлично проектирую и делаю распределённые нагруженные системы. Но вот первую линию обороны, где есть for — я не прохожу…
greendimka
Поясните, пожалуйста, столь негативную реакцию на небольшую дислексию.
background_space_jpg_no-r
тут сидят злые человеки. только, т-сс, никому не говори)
SAWER
У меня то же самое. Причина проста — куча языков, с разным синтаксисом. И это касается не только for, а вообще всего. Часто ошибаюсь. Когда уже пишу код, даже не задумываюсь о правильном написании. Просто пишу код и думаю о задаче. Это как слепой набор текста.
fukkit
Первым делом никто не станет делить там, где можно складывать и сравнивать. Ну и дальнейшие преждевременные оптимизации буйная сеньорская фантазия подскажет.
AllexIn
Читабельность кода — важнее производительности. Особенно, если с производительностью нет проблем.
greendimka
Не важнее, если производительность важна. Для сложных моментов в языках специально существуют комментарии. Сделал как-то особенно вместо читабельного — обязательно прокомментируй, почему выбран такой подход и какова логика.
dimm_ddr
Да, но в условии задачи производительность не требуется. Придумывание самому себе в задаче дополнительных сложностей — отдельный и очень интересный факт о кандидате.
greendimka
Факт, который говорит о том, что кандидат отлично видит те проблемы, которые были пропущены другими, смотрит в будущее. Для того, чтобы кандидат не уходил в дебри во время работы — к нему просто приставляется менеджер, следящий за тем, чтобы работа шла в нужном направлении.
Такие кандидаты редкость и обычно результат их работы (в купе с менеджером) — это из коробки работающая система, поражающая точностью и скоростью, не требующая допилов.
Mendel
Один мой знакомый ПМ когда отдает часть задач на аутсорс фрилансерам без дальнейших объяснений прекращает сотрудничество с исполнителем если тот не задаст ему пару уточняющих вопросов. Не то чтобы это было совсем верно, но уточнить у собеседующего — вам скорость, память или читабельность — вполне уместно.
greendimka
Я уже представил себе ситуацию: фрилансер пишет письмо с вопросом, когда ему в ящик падает «Ты уволен! Больше не звони мне!» (юмор)
Mendel
Ну там такое не пройдет, ибо я имел ввиду что-то вроде:
ПМ: Нужно сделать синхрофазатрон, только с перламутровыми пуговицами
Фрилансер: Ок, понял, через неделю ждите результат
ПМ: Ты уволен! Больше не звони мне!
***
Idot
Из-за такого подхода и виснут постоянно интернет-браузеры — потому что каждый "умник" считает, что "производительность не важна" :(
PS Мне в прошлом году пришлось с матами разгребать несколько тысяч строк тормозного кода, который выглядит очень красиво и читабельно, но жутко тормозит. После оптимизации запрос исполнявшийся около часа, стал выполняться за пару минут.
webkumo
Это значит "красивый" код был неправильным. Это не значит, что нельзя было написать правильно и красиво.
fukkit
Не всегда обязательно жертвовать читабельностью
Вот такое было недавно
AllexIn
Чем это лучше вывода предзаполненного массива?
Постойте — это и есть вывод предазполненного массива.
fukkit
как будто это что-то плохое
nonnenmacher
fukkit
Я приводил его не в качестве идеального.
А что именно вам «пахнет»? (мне интересно).
nonnenmacher
В части строк нет пробелов, в части есть, по конвенции пробелы должны быть:
for(let num = 1; num<=100; )
for(let i = 0; i < 15 && num <= 100; i++, num++)
Здесь:
console.log( pattern[i]? pattern[i]: num );
наоборот лишние пробелы внутри скобок. Рекомендуется делать так:
console.log(pattern[i]? pattern[i]: num);
Так же по конвенции любой цикл, даже с однострочным телом, рекомендуется брать в фигурные скобки. Соответственно, из-за отсутствия скобок внешнего цикла нет отступов во внутреннем.
Кроме того, плохим тоном считается инициализировать переменные в одной строке, как то:
const f = 'Fizz', b = 'Buzz', fb = f+b; — тут опять нет пробелов вокруг '+'.
Возможно, Вам мои замечания покажутся придирками, но, как правило, это стандартные требования к оформлению кода.
Конвенция JS совпадает с конвенцией Java.
fukkit
Спасибо, я понял.
Насколько существенны были бы эти нарушения, если бы вы вели собеседование и принимали решение о приёме на работу?
nonnenmacher
Я думаю, это не критично, если построен процесс Code review и кандидат готов принимать замечания и в следующий раз делать лучше.
spmbt
kaljan
скобки забыли
fukkit
а зачем 100 раз сплитить строку?
JekaMas
Странно, но однажды ответил, что потребуется обучающая выборка в 50-70 элементов, сделаем пару признаков (третий линейно зависим) и одного перцептрона нам хватит, то сказали, что я неверно решил задачу…
mike1
А подумали, что издеваетесь, overqualified или в другой области работаете.
dzugaru
Этому комментарию не хватает апвотов.
JekaMas
меня на эту мысль натолкнул репозиторий с tensor flow fizzbuzz )
fukkit
перцептронов
nazarov_tech Автор
Caravus
Давайте применим совет из статьи: Как часто вам в работе приходится писать код «на листочке/доске»?
ToSHiC
Подобный псевдокод иногда приходится писать на доске или на бумажке, для пояснения своих мыслей коллегам. Ещё чаще приходится схемки рисовать. А вы как передаёте подобные мысли? Формальными описаниями на русском языке?
И да, если уж вам не нравится физз-базз писать, то ответьте на вопросы из моего комментария. Как ещё вы можете проверить, что человек умеет писать код, если он не будет при вас писать код?
Caravus
Таки да, когда я разговариваю с людьми я пользуюсь человеческими языками :) Если нужно что-то пояснить до уровня «как оно работает» — простенькие блок-схемы да доске/листочках, но уж точно никак не код.
Я не имею ничего против написания кода, я только против написания его там где никогда его не пишу и не буду писать за пределами собеседований. Откуда у меня появится навык писать код на бумажке если я этого никогда не далал? Относится это не только к доске/бумажке но и к предложениям писать его в виндовом блокноте, например.
tyomitch
В конторе, где я проработал четыре месяца, был формальный запрет на комментарии в коде на человеческих языках.
Типа, фразы на человеческих языках имеют склонность толковаться неоднозначно, особенно — если язык комментариев неродной для программиста. ЯП же однозначен и заведомо знаком программисту не хуже родного.
Caravus
В оригинальном комментарии идёт разговор именно про общение, а не про комментарии в коде, но я понимаю о чём вы. Вот пример из собственной практики — было указание чтоб всё письменное общение (трелло, комментарии в коде, коммиты) — на английском языке, чтоб значит иностранные сотрудники могли понимать. Никакие иностранные сотрудники при этом не имели доступа к этим текстам…
Это просто самодурство начальства. То как разработчикам удобно делать свою работу должны решать разработчики, как максимум — те из начальства кто сам с ними этим занимается (ведущие разработчики, тимлиды).
Про однозначность ЯП могут утверждать разве что люди которые никогда не программировали (чего-то сложнее hello world). Точно так же — если человек программирует на ЯП много лет, вовсе не значит что он его поймёт так же как его понимают все остальные, передаю паменный привет нашим индийским коллегам…
Shifty_Fox
Я напишу, но он не скомпилируется или неправильно отработает, и это абсолютно нормально. Мне не нужна ide, но нужно средство запуска для тестирования. С третьей, четвертой правки все будет отлично работать. Бумажка и доска не дает возможности отладить код.
maxvipon
Отладить код FizzBuzz?
nazarov_tech Автор
отладить?.. о_0 Эти шесть строчек проще с нуля переписать.
AllexIn
Ну если бы речь шла о каких-то специфичных вещах… Ну, скажем, я не помню в точности до запятой как объявляется шаблон. Просто в силу редкости использования. Хотя, предполагаю что смогу написать объявление с первой попытки правильно. Но денег на это не поставлю.
Но в случае с FizzBuzz там же самые основные конструкции языка используются. Не должно быть никаких пробелм. Вы же цикл, например, без всяких IDE сразу синтаксически верно пишите? Так зачем вам IDE.
Shifty_Fox
Понимаю что решение приходит в голову с первой попытки, просто никто не застрахован от ошибок по невнимательности, а именно они на доске как камнем высечены. Вот я попробую с первой попытки написать этот код в комментарии на js. А потом вставлю в интерпретатор. Получится — хорошо, не получится — ладно.
for (const i = 0; i < 100; ++i) {
if (i % 3 === 0) {
console.log('Fizz');
} else if (i % 5 === 0) {
console.log('Buzz');
} else if…
}
здесь я замечаю что что-то идет не туда, и начинаю зачеркивать на бумаге. А еще, ну какой const i? Конечно же let. Да и нумерация должна начаться с 1 а не 0. (Я потратил всего 15 секунд, не страшно)
Вторая попытка
for (let i = 1; i <= 100; ++i) {
let a = i % 3;
let b = i % 5;
if (a === 0 && b === 0) {
console.log('FizzBuzz');
} else if (a === 0) {
console.log('Fizz');
} else if (b === 0) {
console.log('Buzz');
} else {
console.log(i);
}
}
Пробуем…
Получилось.
spmbt
У Яндекса вполне понятный фильтр работает — через ряд интервью проходят те, кто умеет работать в ущерб себе, но в пользу компании. Потому что уже на 2-3-е интервью Яндекса велика вероятность получения конкурирующего предложения по интервью в других компаниях и с лучшими условиями (если вы не работник с мировым именем, к которым вероятнее другой подход).
selivanov_pavel
Прошёл в 2015 в Яндекс после первого же живого интервью в Москве, до этого ответил на вопросы в анкете и по-моему один раз пообщался по скайпу. Правда я админ, а не девелопер.
Goury
Отлично, как нанимать сотрудников решили.
Следующий шаг — перестать работать на результат.
nazarov_tech Автор
перестать работать на результат? нет пути! :)
retran
Все-таки надо различать «я изучал и примерно ориентируюсь в теме, но не смогу воспроизвести на доске» и «я никогда не изучал и не собираюсь, потому что в работе не нужно». Подобные вопросы задают чтобы аккуратно отделить первых от вторых, а не потому что считают что программист обязан помнить все алгоритмы сортировки.
Ну и на тему «мне это не нужно в работе» не хватает ссылки на статью Джоэля о текущих абстракциях.
UPD Ссылка на Козулю — это прекрасно, конечно
nazarov_tech Автор
вы про вот эту? https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
retran
Да.
beeruser
Для этого более чем достаточно спросить какие бывают основные алгоритмы сортировки и их основные свойства.
AllexIn
Зачем?
ЗА 15 лет в программирования я ни разу не видел, чтобы кто-то писал свой алгоритм сортировки.
Сам писал чисто ради интереса. Практической надобности никогда не было.
Про алгоритмы сортировки я знаю только потому, что шерстил эту тему когда готовился к собеседованию на интересный мне проект…
copist
Скорее пишут сортировочные функции для сложных случаев сортировки. Ну там, по коэффициенту массы тела, имея только пол, возраст, рост и вес. Это навскидку.
dzugaru
Сложные сортировочные функции — это вы имеете в виду метод compare переопределить? :)
phprus
Это еще простые случаи. Хуже, когда необходимо переопределять swap.
Обычно, стандартные реализации такого не позволяют, а бывают случаи, когда необходимо сортировать несколько массивов, где ключи в одном массиве, а данные в нескольких других (такой вывернутый на изнанку формат хранения может очень упростить векторизацию кода и дать существенные преимущества по скорости). Общего то итератора у них, понятное дело, нету, как и тривиального swap, поэтому стандартные реализации тут не применимы.
Пожалуй, необходимость сортировки такой структуры — это единственный (из тех, что я помню) случай в моей практике, когда мне пришлось модифицировать код сортировки, а не использовать стандартный std::sort.
AllexIn
Ну я бы в таком случае не стал писать свою сортирку, а выдрал бы из STL и подправил как мне надо. Это не потребует самого понимания алогоритма сортировки.
phprus
Так я тоже не стал сам писать, а выдрал ее из уже не помню какой библиотеки с подходящей лицензией (выдрать сортировку из STL задача скорее нетривиальная из-за стилей написания стандартных библиотек).
Но, чтобы найти подходящую для модификации сортировку все-таки лучше иметь представления о существующих вариантах, чтобы случайно не взять пузырьковую :)
Кстати есть еще ситуации, когда понимание алгоритмов будет полезно. Есть алгоритмы не основанные на сравнениях — поразрядные сортировки (radix sort) и они могут работать за линейное время, что эффективнее традиционных сортировок на сравнениях (правда у них может быть больше константа, по этому на маленьких наборах данных поразрядная сортировка может проигрывать).
По этому, если мы имеем подходящие данные, то зная об этом можно попробовать взять поразрядную сортировку и получить прирост производительности ничего не меняя в основном алгоритме.
roman_kashitsyn
Можно сделать массив индексов
[0, 1, ..., n - 1]и сортировать его специальной функцией compare, которая смотрит в другие массивы. А потом применить полученную перестановку во всех остальных массивах.roman_kashitsyn
Судя по минусу, не все поняли, о чём речь. Вот пример реализации идеи:
roman_kashitsyn
Это, конечно, неправильно. Хотел сделать стабильную сортировку, должно быть так:
phprus
Да, если есть возможность хранить дополнительные индексы, то это хороший способ.
В нем даже не обязательно переставлять данные реально, если это не требуется, а можно использовать массив перестановок для получения реальных индексов данных.
P.S. Мне кажется или предложенный Вами алгоритм перестановки имеет квадратичную сложность?
roman_kashitsyn
Нет, сложность линейная, это довольно просто показать: ни из одной позиции своп не происходит больше одного раза благодаря массиву visited. Каждый раз, когда мы входим в цикл while, из перестановки вычёркивается один цикл.
mike1
Лямбду подать в std::sort.
beeruser
А я не говорил что вы их будете писать. Нужно знать когда и где конкретный алгоритм лучше использовать.
Чтобы закручивать шурупы нужна отвёртка, а забивать гвозди — молоток.
Я предпочитаю работать с упорядоченными данными. Редко когда нужно вызывать sort(anything).
retran
Именно так. Я не зря упомянул про протекающие абстракции.
mustitz
У меня было, когда из выборки в несколько миллионов надо отдать на клиент по некоторому критерию стопятидесятую страницу. Нет, возможно где-то есть готовое решение, но мне проще было написать быструю сортировку с выходом в случае, если сортитуемый диапазон никак не пересекаеться со стопятидесятой страницей.
svr_91
Как я понимаю, в случае с c++ тут подошел бы std::partial_sort
mustitz
Если страница где-то вначале, то подошёл бы. А если последняя?
svr_91
Видимо, я просто не понимаю задачу
mustitz
Ок, 1 000 000 элементов, 200 элементов на странице, итого 5 000 страниц, надо вывести страницу 2500, т. е. диапазон 500 000 – 500 200. partial_sort(begin(), begin()+500200, end()) всё-таки некоторых оверхед (нам не требуеться, чтобы элементы 0 — 500 000 были отсортированы.
svr_91
Ок, можно попробовать так:
n_th_element(begin(), begin() + 500000, end()) — Тут элементы 500 000 – 500 200 гарантированно будут справа
partial_sort(begin() + 500000, begin + 500200, end())
mustitz
Да, так можно.
mustitz
Единственное, что у меня нет уверенности в том, что этот код не создаёт оверхеда. Опять же, ИМХО, для того, чтобы оперировать такими вещами, надо хорошо себе представлять принцип quicksort.
svr_91
Попробуйте. Напишите, сравните. Может, даже статью на хабр выкатите :)
А что за алгоритмом Вы пользовались, если не секрет?
mustitz
Обычный quicksort, в котором вначале добавлена проверка на то, пересекаеться ли интервал с нужным нам или нет.
roman_kashitsyn
nth_elementобычно использует вариант quickselect, которых относительно хорошо (O(N log N)) ведёт себя на патологических входах. Я бы предпочёл его наколенной реализации.partial_sortиспользует сортировку кучей, Для первый M результатов достаточно (M * log N + N) операций.DreadKnight
Не стоит тратить время на тесты во время собеседования.
Справедливо для обеих сторон.
Тесты в Яндексе работают в качестве фильтра от дурака, а так же проверки на заинтересованность.
KeMik
Спасибо за статью, согласен по всем пунктам.
За время своей работы так же пришел к тому что важно вопросы на собеседовании приблизить к повседневным задачам на проекте, по этому считаю что человека нужно собеседовать на проект а не «проверять универсально».
Обычно я ещё даю кандидату небольшое тестовое задание (от силы на пару часов работы) максимально приближенное к реальному проекту. И прошу его сделать в течение недели. Оставляю ему свою электронную почту куда он может слать вопросы по мере выполнения задания. Этим я убираю стресс, так как человек работает в удобной для него обстановке в удобное для него время. Обычно по вопросам присылаемым мне на почту уже можно многое сказать о кандидате. Потом, если он все таки сделал задание (кстати тут отсеивается сразу процентов 50 кандидатов), мы беседуем с ним по его коду, он рассказывает почему реализовал все так а не иначе, что новое изучил в процессе выполнения задания.
Пока ещё (тут я стучу по дереву) все принятые мной кандидаты оправдали возложенные на них надежды и даже превосходили мои ожидания
nazarov_tech Автор
ура! :) приятно встретить единомышленника.
KeMik
Взаимно. Расшарю вашу статью коллегам. У нас тут какраз недавно дискуссия по схожей теме шла, а тут будет ещё один аргумент в поддержку моих доводов)))
kolu4iy
50%? Вам везёт. У нас 70-80%…
Gemorroj
Что скажете про «адекватность» задачек из заметки https://habrahabr.ru/post/332088/?
Как по мне, как раз пример неадекватности, на которую сетуют в этом теме.
nazarov_tech Автор
классические головоломки, да :) Корреляция с девелоперскими навыками не показана.
SergeyGrigorev
Я когда устраивался в Exante, то в первый раз на позицию Scala Swing разработчика. Но мне она не очень нравилась, поэтому я сообщил об этом на собеседовании, что максимум через год буду проситься перейти в backend-разработку. Тянули достаточно долго с ответом, и примерно через месяц только ответили, что взяли другого. Правда еще через 2-3 месяца написали еще раз уже с предложением интересной мне позиции на backend. Ничуть не жалею, что не взяли на swing )))
semenyakinVS
Люблю когда компании дают тестовое домашнее задание перед собеседованием. Можно написать красивый код в спокойной обстановке, показать чего умеешь и вообще — ощущаешь что показываешь себя как ты есть. На самом собеседовании кодревью, вопросы в контексте реальной задачи (а не квизов на синтаксис языка) — и все довольны. Общался со многими знакомыми: всем нравятся такие вступительные задания.
AllexIn
Большая часть компаний не готова оплачивать тестовое задание.
Большая часть специалистов не готова бесплатно писать тестовое задание.
spmbt
Платно писать ТЗ тоже невыгодно, даже если бы платили по двойной цене — отвлекает от основной задачи поиска, к тому же, не знаешь, примут ли тебя. Есть смысл иногда самому первые 2-3 дня поработать условно бесплатно: не устроит — уходишь без расчёта, но устроит — гаранированно возьмут и оплатят эти дни.
balexa
За первые 2-3 дня невозможно понять ни проект, ни качество работы в компании, ни уровень программиста.
Bojczuk
Всегда считал наоборот. Я ещё толком ничего не знаю про компанию, а она уже мне тестовое присылает. Особенно эпично, если ещё не я им отклик оставил, а звонит сразу эйчарка и предлагает сделать задание. Очень мотивирует.
Про то что у многих людей нет времени на тестовые ни дома ни на работе, я уже и не говорю.
valbok
Поэтому у «взрослых» компаниях сначала идет скрининг кандидатов, а потом уже тестовое задание. И да, если кандидат потенциально достоин работать, то хотелось бы наверное сперва поговорить про позицию, задачи, условия, перспективы.
Хотя есть компании, которые решили делать скрининг именно тестовым заданием на первом этапе, чтобы не тратить время технарей.
Juiceee
Я вспоминаю собес, где спрашивали про различия кошки и компьютера :-)
spmbt
У них больше общего.
lega
Мне больше всего понравилось как меня приняли на работу:
1) 5-10 минутный звонок, общались о погоде, спорте и т.п, чисто что-бы составить общее впечатление и проверить знание языка (компания из европы). Программирования не касались, ибо зачем если список кейвордов есть в моем CV.
2) Мне дали необходимый доступ, к коду и списку задач, я начал работать за деньги (полный оклад), выполнил несколько задач включая одну/две из списка нерешаемых/сложных.
3) Через неделю от старта меня начали оформлять в компанию.
Итого, минимум потеря времени (и денег) с обеих сторон, нет глупых голоболомок и т.п.
nazarov_tech Автор
это интересно, но не панацея. Что если вы бы не согласились выходить на работу, например? Вы же о конторе ещё тогда ничего не знали толком.
dimm_ddr
В любом случае он выполнил какую-то работу для компании, это гораздо выгоднее других вариантов так как и компания деньги не зря потратила и человек рабочие задания пощупал и понял что ему делать будет нужно.
valbok
Знакомому как-то пришлось брать отпуск, ехать в Европы за счет приглашающей компании, чтобы пройти двухнедельный испытательный срок, неоплачиваемый, после множества собеседований. Но зато кормили, по ресторанам водили. Считаю негативным опытом. И отпуск потратил, денег не заработал, хотя Европы посмотрел.
dimm_ddr
Оплата выполненной работы — достаточно принципиальное условие на мой взгляд. Так что ситуация сильно отличается. А как знакомый то считает? Достаточно что то, что со стороны выглядит не очень лично воспринимается на ура.
acmnu
Я вот не пойму. Неужели концепция сортировки пузырьком настолько сложна, что забывается так быстро? Там ведь всего один if. Я это прочитал ещё в детстве и не забыл до сих пор, хотя реально писал сортировку последний раз лет 20 назад.
Или алгоритм Дейкстры для нахождения пути в графе. Там такой примитив в основе, что забыть это невозможно, хотя разумеется можно забыть само название.
Туда же разворот списка в памяти: если вы знаете что такое односвязный список, вы сможете его развернуть — это не рокетсаинс. И если у вас в резюме написано, что вы знаете C/ASM, но не можете сказать что такое односвязный список, то это как-то странно.
Обычно я такие вопросы задаю, чтоб начать разговор, зацепиться за общие знания (я ведь тоже не все алгоритмы знаю). Единственно я никогда не прошу писать код на бумажке (да я сам не напишу). Просто словами, знаками, иероглифами прошу рассказать алгоритм.
dimm_ddr
Нет она просто настолько бесполезна в реальной работе. Это нормально забывать то, чем не пользуешься.
Не уверен про С, но за все время программирования на АСМе я ни разу не писал ничего похожего на связный список. Конечные автоматы, что-то еще, но связный список то в нем зачем? Что это такое я конечно знаю, но точно не из АСМа
acmnu
Ну да, асм-асму рознь. Если контроллеры программируешь, то со структрами за пределами стека скорее всего не столкнешься.
dimm_ddr
Ну в целом я признаю что придрался к некой категоричности. В целом программист, на мой взгляд, в любом случае должен иметь представление, хотя бы общее, об основных структурах данных.
lega
acmnu
Помнится в те годы чтоб победить в зоналке достаточно было знать как ТурбоПаскаль запустить. Интересно какие там сейчас задачи.
Как мне было обидно, что я упустил призовое место на краевой из-за того, что у меня этот паскаль заглючил и генерил не верный код....
AllexIn
Паскаль заглючил и генерил не верный код? Сложно поверить…
Провел в паскале годы — и ни с чем таким не сталкивался.
Расскажите подробнее?
acmnu
Я тогда был молодым и глупым и не умел пользоваться дебагером (паскаль пользовал 3 месяца как, а до этого басик). Ну в общем вижу программа не работает так как ожидается, хотя она простенькая строк так в 300, со всеми отступами. Начинаю дебажить: код паршивый, как пользоваться дебагером не знаю, ну и вставляю writeln через строчку. Нахожу замысловатое условие, которое даёт false, а должно true. Сто раз пересчитываю на бумажке, сверяюсь — ничего: на бумажке тру, в паскале false. Пытаюсь разбить условие, чтоб понять какая его часть не сходится с ручным расчетом: выкидываю условия которые совпадают с бумажкой, оставляю, то что дает не верный ответ. Прихожу к парадоксу: условие типа a>3 даёт false при a:=4
Вот прям такой код (за синтаксис извинйте, я уже непомню его)
Дает на выходе
Я как умная Маша сначала решил, что это я отлаживаю через задницу и просто что-то не так (ну не может же turbopascal врать). Короче трачу ещё минут 20 и осознаю, что все же нет, дело именно в условии. Ну дальше подход опытного школьника: выключить-включить. И о чудо, заработало! Я потом в документации к TP 7.1 нашел какие-то упоминания об ошибках в IDE сильно похожих на мою ситуацию (на краевой был TP7.0), но за давностью лет уж не помню подробности.
А беда в том, что на все эти изыскания я потратил время (порядка 40 минут), которого мне не хватило на заведому известную мне задачку.
Germanets
Сталкивался с подобными вещами, дейсвтительно имели место быть… И тоже в тот момент был совершенно молодым и зелёным, долго и упорно дебажел write'ами и не мог понять, как же так) Весёлые были времена)
GRaAL
У всех, наверное, по-разному, но у меня все забывается очень легко. Просто вытесняется более актуальными вещами.
Раз в год я участвовал в мейлрушном AI Challenge, и каждый раз приходилось вспоминать разницу скалярного/векторного перемножения векторов (а так же кто из них dot, а кто cross). Я хорошо помню зачем оно мне надо — чтобы рассчитать взаимодействие движущихся объектов исходя их векторов их скоростей (отталкивание, притягивания, столкновения и пр) и помню что это делается через «произведение векторов». Через 5 минут «освежения памяти» я все это вспоминаю и использую. А вот так вот спроси меня посреди рабочего дня — растеряюсь и не вспомню.
И так со многими вещами. Не кодил год на Си — подзабыл синтаксис typedef для функций. Быстро посмотрел примерчики — вспомнил. Долго java не использовал — подзабыл формат pom.xml. Не писал ничего околоигрушечного — подзабыл геометрию (формулы расстояния от точки до прямой и т.д.). Но могу в сжатые сроки «восстановить» свопнутый контекст.
valbok
Все ваши плюсы и заслуги сразу будут видны на собеседованиях, даже если вы вдруг «забудете» ответы на такие вопросы.
GRaAL
Надеюсь. Давно не ходил :) Когда-нибудь может быть придется, обидно будет из-за такой ерунды засыпаться.
acmnu
Ну спроси я вас на собеседовании перемножение вектов и получи примерно вот такой ответ, как выше, мне бы этого хватило ибо вы явно понимаете о чем речь, хоть и не помните.
OlegMax
А что если я скажу тебе, что в компаниях, которые на собеседовании спрашивают сортировки, графы и О-большое, на работе придётся* заниматься сортировками, графами и О-большим?
* Так же часто, как аналогичному разработчику в EXANTE приходится проектировать аналоги тиндер или убер.
valbok
Так речь же про то, что компании «злоупотребляют» такими вопросами, что никак не коррелирует с последующей работой. Если нужны на работе алгоритмы, тогда и их надо спрашивать. Если нет, тогда зачем?
* мнение автора комментария может не совпадать с мнением ТС.
OlegMax
Если допустить, что цель статьи — не просто собрать лайков на больной теме, то логично было бы увидеть общедоступное решение этой проблемы. И что-то как-то не очень. Вы вот вправду предпочли бы чтобы на собеседовании в Гугл вас бы спросили о частых проблемах систем, которыми пользуются миллиард пользователей? Или о типичных подходах к созданию автономных автомобилей? Или какие способы экономии памяти вы использовали в вашей ОС для мобильных систем? Или все-таки проще поболтать о старых добрых алгоритмах, о которых вы хоть одну книгу прочитали?
valbok
Мне вот кажется, что шанс попасть на такое собеседование довольно невелек без релевантного опыта, или надо иметь «другие значимые» заслуги.
Я воспринимаю посыл статьи, как неадекватность компаний в технических интервью. Хотя на моем опыте не сталкивался с такой «неадекватностью», всегда приятно поговорить о вечном.
OlegMax
То есть вы думаете, что работающие сейчас десятки тысяч разработчиков Андроид на предыдущем месте работы тоже разрабатывали мобильную ОС? Ну ок.
valbok
Так статья не про то, как в хорошую компанию нанимают хороших специалистов, а про то, как компании _думают_, что они настолько хороши, что могут себе также позволить «стандартные» практики найма как для хороших компаний.
Не, но кандидаты страдают тем же, думая, что они настолько хороши, что могут себе позволить собеседоваться в хорошие компании, в надежде, что их оценять их личные качества, амбиции и желания. Чем черт не шутит.
dimm_ddr
Если бы я пришел в гугл на позицию инженера высоконагруженных систем — да. Точно лучше обсуждения книги по алгоритмам, которую я прочел на первом курсе универа и никогда не использовал. То же и про автономные автомобили. А если вы туда пришли на позицию джуна, студентом на стажировку например, то решать вы будете все равно более простые задачи и обсуждать тоже стоит именно их.
OlegMax
Вы, как и автор статьи, не понимаете, что опыт найма на позиции типа «нужен бэкендер/Java/Hibernate/MySQL/Redis/...» не масштабируется на Гугл (и даже на Яндекс) от слова никак. Потому что в Гугле вы будете разрабатывать сами ГуглHibernate, ГуглSQL и ГуглRedis. Если искать только разработчиков с опытом, например, разработки SQL движка, то все позиции будут закрыты примерно никогда.
dimm_ddr
Да нет же, конечно я это понимаю. Это вы почему-то считаете что предлагается проверять конкретные очень специфические вещи. Правильно — взять реальную задачу, выкинуть из нее специфику, присущую конкретно работе здесь и обсуждать ее. Впрочем можно даже специфику не выкидывать — проверяется не опыт в решении именно таких задач, а подход человека к их решению.
Поэтому я могу не знать конкретных подводных камней в разработке конкретно гуглHibernate, но я должен иметь представление об области и понимать с какого края подходить к задачам, с которыми я буду сталкиваться. В идеале я должен знать хотя бы о части подводных камней, но это, конечно не всегда возможно. Иначе я бесполезен для данной компании.
Если я прочитал книжку об алгоритмах и могу их рассказать, то это совершенно не значит что я в состоянии придумать алгоритм решения задачи. Это даже не значит что я в состоянии вспомнить нужный алгоритм, если мне придется это делать (придется ли?). А вот если я могу рассказать как начать решать конкретную задачу, то я однозначно могу начать эту задачу решать, просто по определению.
bay73
Реальные задачи всегда требуют очень широкого контекста. За полчаса этот контекст не объясняется.
А если вы попытаетесь совсем выдрать задачу из контекста и сформулировать в простом и наглядном виде, то и выйдет та самая стандартная задача на алгоритмы, которую дают в Фейсбуке или Яндексе.
dimm_ddr
Не всегда. Не случайно один из важнейших принципов в программировании — декомпозиция. Разбить большую задачу на мелкие подзадачи с набором условий возможно почти всегда, а когда невозможно, то появляются подозрения в ошибках архитектуры. Что тоже возможно, и иногда с этим приходится работать, впрочем. А раз возможно декомпозиция, то вполне нормально взять одну из таких мелких задача, немного обезличить ее чтобы не попасть под НДА, если это актуально и задать ее. Ну да, это делается не за 15 минут, к собеседованию интервьюверу нужно готовиться не меньше, а то и больше чем кандидату, но во всех областях и продуктах с которыми я сталкивался это было возможно.
Да, какой-то контекст нужен, бесспорно. Но, если собеседуется не джун без опыта, то обычно это человек, который уже имеет опыт в предметной области и ему знакомые базовые понятия и принципы. Что, кстати, и проверяется такой задачей в том числе. Если же человек утверждает что у него 6 лет стажа, но при этом не понимает стандартных вещей из предметной области, то что-то тут не так, не находите? Даже если у него были очень специфические и узкие задачи в весьма необычном коллективе, то это уже как минимум значит что он не интересуется индустрией в целом, что наводит на какие-то мысли. Хотя, конечно, могут быть исключения и только по этим признакам судить нельзя.
bay73
Ну так при такой декомпизиции и получается типовая гугловая задачка по алгоритмам или проектированию, которые тут так нешадно критикуют.
dimm_ddr
Во-первых, критикуют викторины, которые к типовым задачкам не относятся. Во-вторых, уайтбоардинг написание пузырька не получается при декомпозиции ни одной из задач с которыми я сталкивался в работе. А критикуют именно его. Также не получается разворачивание дерева или поиск зацикленности в односвязном списке, которые тоже любят спрашивать. Не получаются стандартные задачи, особенно, если учитывать бэкграунд. Еще раз — если я приду на позицию инженера высоконагруженных систем, то я однозначно должен знать хоть что-то об этой области. И это можно учитывать при постановке задач.
bay73
А где дают викторины? В каком месте сортировку пузырьком спрашивают?
dimm_ddr
Вы статью вообще читали, которую комментируете?
alexeykuzmin0
Эта классификация плоха тем, что алгоритмические задачи, на самом деле, дальше делятся еще на два типа:
Вот по моему опыту, как раз всякие Google, Яндекс и иже с ними задают обычно алгоритмические задачи второго типа, а мелкие фирмы, пытающиеся просто следовать за трендом без понимания сути — первого.
bay73
Я статью читал, в ней такие собеседования названы Google-style, хотя как раз в Google таких собеседований нет. Поэтому я и спрашиваю, где именно сортировку пузырьком спрашивают.
dimm_ddr
Ну замените сортировку на разворачивание бинарного дерева из знаменитого твита (поправьте меня если перепутал алгоритм). Это много поменяет? Или вы не верите создателю Homebrew что его именно это на собеседовании в гугл спрашивали? Ну и викторины в гугле тоже были. Сейчас вроде уже нет, но были точно.
bay73
Да, разворачивание дерева — отличная задачка, которая позволяет узнать очень много о кандидате. Сортировка, как вопрос, годится только для первокурсников, а разворачивание бинарного дерева уже вполне нормально для инженеров вплоть до миддла или сеньора.
Ну а создатель Homebrew может быть отличным менеджером или визионером, но средним инженером. Видать не на ту позицию он в Google хотел.
0xd34df00d
Эм, а что подразумевается под разворачиванием дерева?
Это? На синьора?
bay73
Ну как видим куча народу таких задач боится и написать не могут. Так что на вполне годится.
Ну и главное понимать, что само решение задачи никого не интересует. Задача — лишь повод обсудить разные темы.
alexeykuzmin0
Дополню уважаемого bay73. А откуда известно, что его не взяли именно из-за того, что он не решил задачу? По моему опыту (100+ собеседований, в том числе и в крупные компании, в частности, в тот самый Google) на собеседовании важно показать, что ты умеешь думать, а решить или не решить задачу — дело десятое. И далеко не всегда можно самостоятельно определить, насколько хорошо ты себя показал на собеседовании.
bay73
Ну это-то как раз не невероятно, а ожидаемо. У входного собеседования и перфоманс-ревью совершенно разные задачи и разные критерии для оценки.
alexeykuzmin0
А почему разные-то? У интервью — оценить, насколько хорошо кандидат сможет работать в компании, у perfprmance review — оценить, насколько хорошо работник работал в компании в последний период. Или я что-то упускаю?
bay73
Performance-review нацелено больше на повышение по службе и выискивает не совсем те качества, которые нужны программисту.
alexeykuzmin0
Не то, чтобы я не верил, но это совершенно не очевидно. От результатов performance review ещё бонусы зависят
YetAnotherSlava
К сведению — бухгалтерия и прочее такое в Гуглах сделано не на, прости господи, map-reduce, а на обычном, таком совершенно не хипстерском оракле. Который за деньги куплен. И Hibernate там самый обыкновенный.
pm_wanderer
Однажды спорил с одним пожилым тимлидом, который сокрушался, что нынешнее поколение программистов не знает физику: «А вдруг понадобится написать программу для расчета силы тока, необходимой для передачи сигнала по медному кабелю с определенным сечением?»
Я ему возразил: «А вдруг понадобится рассчитать длину цепочки ДНК? Получается программист должен и биологию знать?»
Мне кажется, все эти вопросы по высшей математике или о внутреннем устройстве алгоритмов спрашивают только те, кто потратил время на их изучение и теперь ищет куда приткнуть полученные знания, демонстрируя кто здесь Альфа-программер: «Этот новичек даже второй закон Кирхгофа не знает… а вдруг завтра понадобится?»))
Idot
Это фундаментальные знания, которые в отличие от очередного новомодного фреймворка не устареют.
Вы из тех кто на собеседованиях устраивает допрос про доскональное знание очередного фреймворка?
Вроде, одного человека не придумавшего ничего лучше, чем устроить, в своё время, допрос на доскональное знание MFC (Microsoft Foundation Classes).
Это означает, что он изначально был электронщик, переквалифицировавшийся в программиста. Для электронщика — это важно.
Если бы у нас были биологические компьютеры, то для аналога электронщика — это было бы действительно крайне важно.
pm_wanderer
В этом и дело, что зачастую спрашивают не то что важно по работе, а то что важно лично для вопрошающего)
Для меня важны паттерны и читабельность кода, но эти вещи напрямую связаны с программированием. Если стоит задача написать биржевого робота, то понимание всяких свечек, спредов и прогнозирование цены уж точно не должно входить в обязанности программиста. Для этого есть экономисты, которые консультируют программистов и помогают им перевести эти алгоритмы в программный код. Это мое личное мнение и я не претендую на то, что так должно быть везде. Мне просто кажется это самым адекватным подходом.
Idot
Математика — это не узкая предметная область, математика — это абстрагированные знания, которые можно использовать применив к конкретной предметной области.
Алгоритмы — это не то, что нужно тупо вызубрить, алгоритмы — это то, что программист должен уметь понимать и применять.
Idot
Они имеют такое же практическое отношение к работе как и знание алгоритмов — вполне можно успешно писать рабочий код не зная ни одного паттерна (лет десять назад я и термина такого никогда не слышал).
=> так что вопрос на знание паттернов по сути ничем не отличается от вопроса на знание пузырьковой сортировки.
PS алгоритмы — тоже напрямую связаны с программированием, потому написание программы на императивном языке программирования — это есть ничто иное как запись алгоритма на языке программирования.
pm_wanderer
Сейчас заметил, что пропустил одно слово в своем первоначальном ответе. Я имел ввиду «внутреннее устройство алгоритмов сортировки». Разумеется, паттерны и алгоритмы близки по смыслу и знание алгоритмов тоже необходимо (где какой можно использовать). Но помнить точную реализацию сортировки… пожалуй нет)
Idot
Зачем заучивать реализацию?! O_O
Достаточно понимать принцип её работы.
pm_wanderer
Возьмем к примеру функцию из JS — Math.min()
Что будет являться достаточным пониманием принципа ее работы?
1) Она возвращает минимальное число из предоставленных аргументов;
2) Она возвращает минимальное число, действуя по алгоритму (далее идет описание алгоритма)
grossws
Ни 1, ни 2 не достаточно (в предположении, что описан алгоритм, а не реализация). Достаточное описание должно содержать контракт в том или ином виде (граничные условия на параметры и результат), описанное поведение при неверных параметрах.
pm_wanderer
Согласен, знание о допустимых параметрах можно добавить к пониманию принципа, но как по мне, достаточно всегда отправлять на вход функции верные аргументы (которые описаны в ее документации), а что произойдет в случае ошибки — это уже не важно, ибо это будут последствия нарушения интерфейса.
Примерно так это можно делать, эмулируя проверку типов/интерфейса в JS:
PS: лично я не понимаю вопросы типа «а что будет если функцию вызвать с неверными аргументами?». Неважно что будет. Надо просто ее вызывать правильно)
alexeykuzmin0
Функции бывает дико удобно вызывать с неверными аргументами.
Например, я ищу корни квадратного уравнения, с использованием функций арифметических операций. Я хочу, чтобы моя функция, получив неверный вход (например, один из коэффициентов равен NaN), выдала в качестве ответа NaN как флаг ошибки (ну вот удобно мне так). Если бы я не знал, что арифметические операции, получив на вход NaN, тоже выдают NaN, я бы написал что-то вроде
Но поскольку я знаю, как себя ведут арифметические операции, получив на вход NaN, я могу эту проверку просто опустить, получив более читаемый код.
Точно так же, если, например, я знаю, что функция для некорректного входа выкинет исключение, я могу никаких проверок перед вызовом не делать — оно поймается или приложение упадет, все довольны (ну, если я использую исключения в этом проекте). А вот если она выдает undefined behavior, проверка 100% необходима.
0xd34df00d
А если бы это было выражено на уровне типов, то даже знать не надо было бы.
tyomitch
Более читаемый для того, кто тоже с ходу помнит, как себя ведут арифметические операции, получив на вход NaN.
Второе правило Zen of Python гласит: «Explicit is better than implicit.»
alexeykuzmin0
Все проверки в простой функции могут занимать гораздо больше места, чем реальный функционал. Не стоит размазывать их по всем функциям, тем самым сильно снижая читаемость. Да, можно куда-нибудь вынести, но во многих случаях, их можно просто опустить — что может быть проще?
dimm_ddr
Не совсем. В отличие от конкретных алгоритмов паттерны применяются значительно чаще в разных местах. Знание описания паттернов значительно увеличивает эффективность коммуникаций в команде — не нужно расписывать как ты что-то сделал или как предлагаешь сделать, достаточно сказать название паттерна и все в целом получили общее понимание. Естественно этого не всегда достаточно, но уже это способствует эффективности коммуникаций. Так что вопрос про известные паттерны — это фактически попытка понять насколько эффективно можно с этим человеком общаться в команде.
hssergey
Только недавно была тема про собеседование для фронтэндщика на JS, и там полно было достаточно комментариев вида:
Только вот комментирующие забывают, что способность думать и решать проблемы сильно зависит от окружения и эмоционального состояния. Многие программисты — интроверты. И в условиях стресса покажут гораздо ниже результат, чем то на что способны. Так что я полностью согласен с автором статьи.
alex4Zero
Устраиваем с кандидатами тестовый день рабочий. То есть они реально приходят на 1 день поработать в команде, в паре с кем-то из разработчиков в компании. Это как раз для того, чтобы разделить навыки прохождения собеседований от рабочих моментов.
Prokky
А как с кандидатами, которые работают полный день? Просите их взять отгул?
valbok
Главное не забыть покушать вместе (с)
roman_kashitsyn
Мне лично нравятся собеседования, на которых спрашивают алгоритмы и просят писать код. При этом я совершенно не считаю себя экспертом в алгоритмах, уж больно область широкая.
Мне кажется, критикующие неправильно понимают, что именно проверяется на таких собеседованиях. Проверяется вовсе не знание конкретных алгоритмов, а умение решать нестандартные задачи с помощью компьютера и писать простой понятный код.
Никто не ожидает, что вы решали задачу раньше или даже сходу знаете, как её решать, скорее наоборот. Интересно понять, как вы приходите к решению, как вы размышляете, как структурируете код, как его проверяете. Для решения большинства задач нужно знать лишь базовый минимум (сортировка, простейшие структуры данных, хэширование, обходы графа и бинарный поиск).
Является ли знание конкретного фреймворка важным? Я в этом сомневаюсь. У меня есть друг, которого я считаю очень умным парнем, и который очень переживал, когда устраивался моим коллегой. Потому что он никогда не работал с языками и базами данных, которые у нас использовались. Думаете, это повлияло на его продуктивность? Нет, он очень продуктивен, потому что он быстро учится (в частности, на код ревью) и логически подходит к решению новых проблем.
Запись кода на доске, а не в IDE, тоже имеет смысл: я лично чаще читаю код в браузере (например, код ревью чаще всего проходит в браузере). Безусловно, современные инструменты сглаживают разницу, но умение понимать код и пользоваться "внутренним интерпретатором" (а не внешним отладчиком IDE) я считаю очень важным для программиста.
P.S. На мой взгляд, создатель Homebrew сильно переоценивает значимость своего проекта в инфраструктуре Google.
Sergiy
Вы не замечаете разницу между «читать» и «писать» на доске?
Да и «Google: 90% of our engineers use the software you wrote» в инфраструктуре — да, а вот ведь пользуются.
Sergiy
PS: его взяли в Apple
Sergiy
Года два назад пригласили в стартап в Германии и это было самое веселое собеседование. Вместо всякой тех. мишуры и дурацких вопросов, мы два дня провели вместе c CEO, HR и глав. программером на вело-прогулках и посиделках в барах и пикнике обсуждая тех. вопросы по различным проблемам и травя анекдоты. И даже через столько времени работаем вместе и проводим время точно также, всей командой.
Надо искать не «знающего-модный-фреймворк» специалиста, а гибкого, умеющего подстраиваться и работать в команде.
nazarov_tech Автор
никогда не забуду рассказ своего друга, который сейчас iOS-тимлид в Хельсинках.
Один из вопросов, который ему задали на интервью, звучал как «are you an ass man or a boob man». =)
Sergiy
Да, нечто такое тоже присутствовало. Еще до приезда, был вопрос как у меня с алкоголем и как отношусь, мол компания любит проводить время за совместными посиделками и не хотелось бы дискриминировать…
KonstantinSpb
Да, тут и юморнуть можно: If woman in doggy-style, I'm an ass-man, if she lays on her back, I'm a boob-man
Гибкий еврейский ответ с юмором, устраивающий любую из сторон :)
nazarov_tech Автор
на самом деле нет =)
Такой вопрос он не столько про конкретный ответ, сколько про реакцию.
Если вы, например, устроите кипиш на тему сексизма (у вас есть такое право), контора может решить, что вы не впишетесь в их коллектив (у них есть такое право).
valbok
Представляю на сколько человек хочет работу, раз «устраивает кипиш на тему сексизма»…
nazarov_tech Автор
ну, кому-то действительно важны проблемы сексизма, кому-то — экологии, и т.д. Кто-то ничем не заморачивается и просто бороздит рынок в поисках денег. Почему нет, люди разные :)
dimm_ddr
Ну, вполне возможно что человека вообще рекрутер нашел, а не он сам написал. Не факт что эта компания ему вообще нужна, но послушать что она может предложить — почему нет, может и зацепит.
copist
Думаю, эти стартаперы искали точки душевного соприкосновения, единство целей и интересов. Уверен, на посиделки они пригласили не на первый этап, а ещё в remote режиме предварительно уровень компетенции проверили.
daron666
У меня обратный опыт с вашей компанией, где то на втором часу прогонов по стандартным java коллекциям на scala позицию, и про вопросы вообще про все кишки jvm, на вопросы про сложность алгоритмов в О нотации, меня спросили есть у меня опыт с нетти или аналогами. Я ответил что нет, и мне сказали что «oк вы нам не подходите». И это реально на втором часу вопросов про сложность хэш-мапы. Я конечно тоже не идеально все это знаю наизусть, но блин ваш пост это реальная противоположность моего опыта устройства к вам. Выходит где-то кто-то приукрашивает.
nazarov_tech Автор
ну что тут сказать. Видимо, им такое всё-таки действительно надо, компоненты у них сложные :) Я сам в Python-департаменте, мы делаем веб и спрашиваем иначе.
daron666
Ну выходит, что такое примерно собеседование только в один определенный отдел? Просто собес с вашими ребятами на моем опыте самый «токсичный», а вы знаете, в скала сообществе слово токсичный просто так на ветер не бросают. Удачи и всего хорошего.
Jesting
Ну если ты два часа на вопрос про сложность хеш-таблиц отвечал то да, ничего удивительного что тебе в итоге отказали.
daron666
Мой комментарий касался формы, а не содержания собеседования. Понятно, что если отказали, то я оказался ниже предела ожиданий, но по форма данное собеседование было весьма токсично.
valbok
Причина отказов — это темный лес, часто недоступный для понимания даже для собеседующих.
Так что не обязательно, что _ниже предела ожиданий.
daron666
Да я все прекрасно понимаю, просто не моё оказалось. Бывает такое. Не отказывают только тому, кто не проходит собесы.
Mendel
Ну тут одномерная оценка не применима в принципе.
При собеседованиях в крупных конторах решение принимается коллегиально и/или многоуровнево.
Помню когда работал в гос.структуре, то народ принимали по простой схеме:
1 — я должен был найти кандидатов, кадровики мне помогали, но толку было мало.
2 — я предварительно с ними общался по скилсам, озвучивал вопросы по документам и т.п. (бюрократия мне была важнее скилсов, мне проще было человека подтянуть чем согласовать изменение в ДИ через министерство/главк). Общение буквально минут пять, на ходу.
3 — приводил кандидатов в отдел кадров, зав.кадрами (тетка умная, хоть и вредная) с ними общалась. Если она людей зарубала, то я говорил «мы вам позвоним», и провожал, если нет, то вел в отдел, наливал чай-кофе, конфетки, и болтал на профессиональные темы.
4 — когда набирался пул тех кто не был забракован, мы с кадровичкой садились и пересматривали анкеты оставляя 2-5 человек с нашими пометками, которые уже шли со мной на примем к начальнику. Реально это была уже формальность ибо по факту ни один начальник ни разу не завалил того кто подходил и мне и кадровичке, максимум спрашивал «ты точно уверен что _девочка_ справится?», но теоретически тоже могли бы валить. Но по честному мы учитывали систему ценностей конкретного начальника, так что вероятно это хорошая работа кадровички а не «сговорчивость» трех начальников.
Я собственно к чему? Конкретный кандидат должен попасть под ожидания ТРЕХ разных человек. И в реальности если человек будет исключительно хорошим кандидатом в моих глазах, то 99% что Борисовне он не понравится. И наоборот. Так что проходили только те кто был средним по всем трем шкалам.
Сам помню проходил собес аналитиком в банк. Текучка там была страшная. Первым этапом устраивали викторину. В целом оно было уместно — загнали 50 человек в зал, зачитывали вопросы (или тесты выдавали, не помню) — урезанный IQ плюс упрощенный жираф в холодильнике (не совсем, но тоже еще тот Перельман). Отфильтровывали не слишком жестко, на второй этап проходили примерно половина. Тут уже нач.отдела общалась, совсем бегло. Вылетело еще человек пять, остальных двадцать повели на собес к зам.управляющего, где были тоже кадровик и нач.отдела (моя будущая начальница). Вопросы были на коммуникацию и по предметной области по работе. Викторин больше не было.
Но опять таки — ни один с высокими способностями хоть в чем-то, через это сито не пройдет, ибо надо сразу кучей качеств обладать. Собственно те кто прошел — самые толковые все равно ушли.
Я свалил через два месяца во фриланс, и за это время все крутые спецы ушли или в другой банк или вообще в ЕБРР. Вот честно — на их месте, с сегодняшним опытом, я бы сам себя бы не взял. У меня на лице было написано что я очень быстро свалю. Вероятно их подкупил «лучший результат теста за время его существования»… нафик такие олимпиадники…
nazarov_tech Автор
ну, не переходите на личности, пожалуйста :) Человек задал вполне здравый вопрос.
alexeykuzmin0
Напротив. Если человек настолько глубоко знает, как работают современные хеш-таблицы, что может про них два часа рассказывать, это очень здорово.
kloppspb
IMHO, проблема в том, что каждый начинающий начинает считать себя
maksyms
Спасибо, понравилось, в принципе. Но, все же, в статье есть противоречия. Например:
Вам не кажется, что для того, чтобы «увидеть» в репозитории наколеночный обход графа или квиксорт, ну просто необходимо представлять, как они выглядят, как алгоритм?
Я полностью поддерживаю подобный подход к собеседованиям и наша компания его активно использует, но! Мне кажется, нужен баланс, и если для работы хорошо бы представлять, чем одна сортировка лучше другой, то ничего страшного, если на интервью дали практическую задачку на понимание.
Из опыта: у меня работали, давно уже, товарищи, которых, когда попросили проимпортировать два здоровенных CSV файла со связанной информацией в БД, рисовали алгоритм O(N^2), а потом ну очень долго удивлялись, почему же за 12 часов работы только половина проимпортировалась. И для них просто «вау!» было, когда на следующее утро показываешь, как можно сделать O(N) алгоритм (конечно, не используя O-large notation, чтобы не тянуть за собой всю теорию), который всю задачку сводит к каким-то 6 минутам пыхтения жесткими дисками… И, конечно, вопросы: «а как ты это придумал???» Ну вот, сейчас этому, говорят, и в школах учат…
Были, конечно, и обратные примеры, когда computer science PhDs воротили подобие Aho-Corasick поиска с пре-компиляцией регулярных выражений в задачке, в которой ообычный exec и grep отрабатывали за доли секунды.
Так что, фокусироваться, конечно же, нужно на практике. Если человек с «крутым» образованием, важно проверить, что он не усложняет решения и, грубо говоря, пользуется grep когда это работает. Если с «менее крутым» — то что не начнет изобретать неоптимальные вещи и реализовывать руками примитивный пузырьковый сорт, когда под рукой какой-то boost лежит…
nazarov_tech Автор
вообще очень согласен: нужен баланс, и каждой конторе свой баланс.
Статья вышла радикальной просто поскольку целью я ставил сдвинуть вашу точку зрения, заставив задуматься. Здесь работает правило «чтобы огромный зал услышал вас со сцены, вам стоит кричать».
SAWER
«дали практическую задачку на понимание»
Такую задачу и именно для таких целей можно решить мысленно. Таких задач можно задать целых десять за пол часа-час собеседования и быстро оценить примерный уровень и даже знание стека технологий в разных направлениях. Пару раз был на таких собеседованиях. Это интересно и, что немаловажно, если получится включиться в задачи, то уже ничего не мешает.
С досками или кодингом за это время оценить что-то значимо нереально.
usharik
Недавно столкнулся с оффлайн заданием на коддинг с ограничением по времени (3 часа). Причем задача дается такая, что решить её в указанное время практически не возможно. Результатом должна быть работающая часть задания, покрытая тестами (юнит и интеграционными).
valbok
Задач бояться — на собеседования не ходить. К вашему счастью «адекватные» компании не делают корреляцию между таким тестом и вашими способностями. Даже проваленные такие тесты не гарантируют отказов. Хотя смотря как провалить.
usharik
Так я и не боюсь)) Но с подобной столкнулся впервые. Вообще тестовые задания тема не менее интересная чем вопросы собеседований. Честно говоря, даже жалею, что такой вариант проверки кандидата встречается довольно редко. Даже «заваленное» тестовое задание, как правило давало интересный опыт.
valbok
Так переходите на следующий уровень и получайте удовольствие от мозгоправных задачек на алгоритмы+структуры данных на очных собеседованиях перед белой доской в течении несколько часиков. Дзен близко.
mortimoro
Я считаю, что абсолютно неважно какие технические вопросы задавать на собеседовании.
Когда вы даете объявление о вакансии, на него откликнется около 50 человек:
Вот и выходит, что даже если вы сыграете в рулетку с последними 30 кандидатами, вы все равно получите правильный для себя результат, а про остальных просто забудете. В любом случае, вы никак на собеседовании не узнаете, как этот человек поведет себя через пол года и насколько эффективным будет его труд все эти пол года — от лени не застрахованы даже специалисты экстракласса. Так что какие бы вопросы вы не задавали, выбор все равно будет сделан на основании личных предпочтений/измышлений/предрассудков и в 99% случаев он будет правильным.
mike1
Фатально не мог никогда проходить никакие собесы: душа в пятки, весь мокрый и трясущийся. Не понимаю смысл обращенных ко мне слов интевьюирующих, создавая впечатления адского тормоза. Патологически не могу вывести из того, что они говорят то, что они имеют в виду и хотят от меня услышать. Сам же более двух предложений подряд сказать не могу.
К тому же интервьюеры иногда бесят, задавая вопросы про регулярные грамматики и SOLID в мелкосошных конторах, которые никогда не занимались, не занимаются и не будут заниматься разработкой продвинутого софта. Встречаются и люди, которые слишком много о себе мнят и сами красуются вместо того, чтобы выяснять мой уровень знаний. Дико бесят.
Результат: работаю там, где «собеса» почти не было — так, посмотрели, спросили что-то. Я невнятно ответил. Дали задачу. И задачу я не решил! Но господа почему-то заинтересовались и взяли (о чудо!).
Но: в спокойной обстановке на вайтборде могу написать bubble sort и внятно рассказать о quicksort, когда расслаблюсь за кружечкой пива. В этом состоянии могу даже сказать связно более 2 предложений последовательно. Целых 3! Да, в 3 предложениях о quicksort! Pivot choosing, partitioning, recursion.
Проблема эта меня настолько взволновала, что я написал об этом в хабр: Нелегкая карьера программиста или чего хотят работодатели
copist
da-nie
Очень знакомая история. У меня ровно те же проблемы, что и в вашей статье — этот самый computer science при тоннах написанных рабочих программ. :)
mike1
Причем, computer science мне в итоге пришлось все же узнать, чтобы пройти через какие-то рекрутинговые фильтры. Иначе бы совсем бы был за бортом. Приходится подстаиваться под «визовые центры».
Это мне напоминает «обман» визового центра с помощью бронирования апартаментов на букинге, а потом за день до поездки их отмену. Чтобы пройти в дамки, то есть попасть за границу.
Нечестная какая-то игра. Мы знаем ваши вопросы, а вы знаете правильные ответы. Ни то, ни то не используется в повседневной работе, но надо типа. Правила игры такие… SOLID, ACID, банда четырех…
mortimoro
Приходите на собеседования с пивом и уже слегка поддатым ;)
mike1
Подумают, что соискатель — алконавт и не то, что не возьмут — не пустят на порог.
Wan-Derer
Видимо, надо было дерябнуть до… и усугубить во время… :)
Terminal
nazarov_tech как автор упомянутого твитта, позволю себе высказаться.
Даню не взяли в команду еще Павла Дурова, куда он действительно не подошел. Там нужен был определенный профиль людей, которые умели решать задачи поставленные в том числе на интервью. То что Даня под этот профиль не подошел не говорит, ни о чем. Ни о том, что процесс отбора в ВК был неправильный, ни о том что Даня плохой разработчик. Насколько мне известно, костяк команды Telegram все еще составляют люди, который могут и интерфейс запилить, и с хайлоадным бэкендом работат. И кажется, эти ребята прекрасно себя чувствуют.
Что касается, современной команды ВК, то Даня бы отлично к нам вписался. И мы, конечно, не задаем вопросы фронтам на собеседовании «как определить страну по IP». Так что мне кажется, что вся та дискуссия вырвана из контекста. Хотя я и не скажу, что наше собеседование просто пройти.
А если вы считаете, что конкретная команда кому-то что-то «должна», в плане выбора профиля/специализации людей, которых она ищет, то зря.
nazarov_tech Автор
о, привет! :) а я даже подписан в твиттере и мы там с вами в DM общались.
Нет, я вовсе не считаю, что конкретная команда чего-то должна.
Твит был приведён исключительно как утешающая иллюстрация: даже если человек не прошёл фильтр конкретной компании, на которую ставил все карты, очень вероятно, что успех ещё ждёт его впереди. (Просто не с этой конторой, а с другой.) Выбрал я этот твит, потому он яркий и потому что недавно попался мне в ленте. (Ну и ещё потому, что об Абрамове сейчас говорят даже гопники в подворотнях.)
Надеюсь, что теперь недоразумение улажено.
AllexIn
Я вот немножко попробовал погуглить Дэна. Но так и не понял чего он добился такого, что о нем даже гопники говорят…
nazarov_tech Автор
он автор редакса и один из самых известных фронтендеров мира.
Допускаю впрочем, что фронтенд съел остатки моего мозга и я не слишком удачно про него пошутил )
3draven
У меня завтра утром собеседование. Я сейчас волоку проект в котором пять серверов, мобильные клиенты, навигация, вебсокеты и прочее (фулстэк в одну харю… но мне пока нравится) и делаю с нуля еще один, мелкий с электронной очередью. Завтра меня начнут спрашивать как квиксорт делать :)
Правда я уже передумал уходить, так как работодатель меня на удаленку сплавил «когда хочешь». Но пойду, пособеседуюсь.
nazarov_tech Автор
ой, а попробуйте ещё куда-то пособеседоваться!
Контор много разных и хороших, и вы наверняка с вашим опытом найдёте нечто покруче текущего места (даже под соусом удалёнки).
3draven
Вот завтра и попробую :)
vms2k
Чисто поддержать холивар «теоретиков» и «практиков» с целью поднятия рейта автора статьи.
Личная статистика — 80% кандидатов на позицию сисадмина или сетевого инженера не могут ответить на вопрос что такое сетевая маска и зачем она нужна. Ни своими словами, ни чужими, ни примерами. С программистами еще хуже (я про Россию если что). Так что хватит ныть и вперед работать!
AllexIn
Я как программисто тоже в деталями не смогу ответить для чего нужна маска, кроме как для роутинга(подробностей не знаю). Так что соглашусь, с программистами беда — и таких очевидных вещей не знают.
grossws
С программистами тоже беда. Утверждают, что пишут на каком-нибудь пайтоне, джаве и т. п. последние несколько лет, а fizzbuzz не осиливают
dimm_ddr
У меня несколько человек, говоривших о знании питона, на собеседовании не смогли даже for по списку написать. Как впрочем и самостоятельно сказать что же такое list в питоне. А это даже не fizzbuzz еще.
grossws
Написать fizzbuzz проще, чем нормально рассказать, что такое list в пайтоне и как он реализован. Если, конечно, не ограничиваться банальностью типа "динамический массив".
dimm_ddr
Меня вполне бы устроила банальность "динамический массив". Но по реакции человека было очевидно, что он не знает даже этого. Да меня даже ответ "массив" бы устроил, это был банальный фильтр как раз от таких людей.
mike1
А как он, кстати, реализован? Видел сорсы, но давно и забыл уже… вдруг кто-то спросит…
grossws
Как обычный array list, см. https://hg.python.org/cpython/file/tip/Objects/listobject.c
mike1
Да, спасибо, все ясно.
tyomitch
Мне питонисты недавно попеняли за ссылки на hg.python.org — мол, проект уже полгода как переехал на гитхаб, а hg.python.org держат только для таких лентяев, как я и grossws :-)
grossws
А не разработчик CPython'а и не мейтейнер базовых python'овских пакетов в каком-либо дистрибутиве. Мне вполне простительно не знать, что они переехали) А в гугле у меня вообще по запросу cpython list первая ссылка на svn, но это в порнорежиме браузера xD В нормальном режиме уже на их repo на github'е.
Мы в Apache Tika, например, переехали на github как основной репозиторий с синхронизацией в git-wip-us.apache.org, но человеку не читающему dev@tika.a.o это знание не сказать, что сильно необходимо, патчи в jira спокойно принимаются ,)
Vadimyan
>> Хорошо, но фильтровать их такими собеседованиями суть подбрасывать монетку
Как-то предлагал вместо утомительных распросов о «поиске подмассива с заданной суммой элементов» и «разворота односвязного списка» отбирать людей по росту — брать только тех, кто выше 180см., так как корреляция такая же очевидная. Не прижилось.
yury-dymov
Я собеседовал немало людей, который отлично мне на high-level рассказали, как они красиво бы запроектировали и слова говорили правильные, а когда начинали писать код, то там была жуткая императивщина, забытые пограничные условия и весьма трудночитаемый код — 15-20 строк хватает, чтобы понять, что человек писать умеет плохо.
Да, в начале проекта будут бездумно копи-паститься решение со StackOveflow и будет казаться, что все хорошо, но потом полезут баги, а поддержка проекта будет очень сложной и дорогой.
Все это не противоречит тому, что многие интервью проводить не умеют. В whiteboard не вижу ничего плохого, и если кандидат не может вспомнить название функции — это вообще не проблема. А вот если у него код на 5 строк и там есть ошибка с выходом за пределы массива и он сам ее не находит даже после подсказки, то упс.
nazarov_tech Автор
всё так! Поэтому у меня ещё там стоит указание «и обязательно смотрите и обсуждайте код».
MaxEdZX
У меня тут знакомый собеседовался к одним японцам (в Японии). Они разрешили ему взять свой ноут, и оставили одного на час в комнате без Wi-Fi, и в таком режиме ему надо было решить 4 задачи. То есть, сиди, компилируй, пиши тесты — всё сколько хочешь, и в своей любимой IDE, а не на бумажке, или, упаси господи, на доске. Задачки, правда, всё равно абстрактные, не из жизни, что лично я считаю минусом, но по крайней мере, их позволили выполнять в более комфортные условиях — уже шаг вперёд.
Ну и ещё вот моё личное мнение — я бы давал задачи на отладку. Потому что писать квиксорт по памяти — дело дурацкое, а вот искать, где в логике программы ошибка, из-за которой один раз в 10 дней всё падает к чертям — это задача гораздо более частая. Причём примеры можно прямо из кодбазы компании, из недавних факапов понабрать (если жалко показывать человеку без NDA продакшен-код — анонимизировать кусочки немного, свести до минимального примера). Даже джуниор должен хотя бы что-то знать о простейших техниках отладки и уметь читать чужой код хоть немного, а уж скажем лид — должен всегда быть готов прибежать спасать положение, когда на поиск ошибки джуниором уже два дня потрачено без видимых результатов.
А ещё важно умение задать Гуглу правильный вопрос, и среди тон хреновых ответов со StackOverflow найти нужный. Не знаю, как где, но в мобильной разработке из этого, кажется, 90% труда состоит — из выяснения, почему Андроид опять несёт чушь, хотя ты код чуть ли не из официальных туториалов брал. Причём по каждому вопросу на SO будет 50 ответов, и из них ровно 1 подходящий именно к твоей ситуации (это в хорошем случае). Чаще всего, это будет не первый ответ, а 4ый коммент к 5ому ответу в 3ей реинкарнации этого вопроса. Что удивительно, не каждый кандидат в программисты умеет искать и находить оные ответы! Вот это бы тоже неплохо проверять, правда, не особенно понятно как.
nazarov_tech Автор
два чая этому милорду :)
copist
И тот, что решает конкретно твою беду, будет иметь 0 голосов «за» :)
dimm_ddr
А в комментах будет описано почему он не работает. При этом у тебя он будет реально решать твою проблему.
BalinTomsk
у меня так было в Амазоне. Но у меня телефон с датой, я быстро раздал wifi ноуту и поискал все что нужно :)
tyomitch
У меня так было в одной мелкой фирме. Я не только залез в инет через 3G, но ещё и вставил в свой код ссылки на SO, откуда скопипастил нужные мне куски :-)
Но собеседователи такой прыти не оценили, и больше я от них ничего не слышал.
gnkoshelev
«Не всё так однозначно». ©
Это в контексте «вайтбординга» и алгоритмов.
Из рассмотрения выпали самые массовые группы разработчиков:
По опыту проведения собеседований, как раз на интервью с кандидатами из указанных групп на ура заходят задачи на алгоритмы и «вайтбординг». И польза от этого определённая есть, поскольку по ним можно оценить обучаемость и умение формулировать свои мысли.
Единственно, под «вайтбордингом» я больше понимаю псевдокод, схемы и рисунки, чем настоящий код.
ogoNEKto
По статье — после 15 лет периодических собеседований подпишусь под каждым словом. Встречалось все описанное, и даже больше. Устраивался, как ни странно, туда, где «этого» было минимум.
Из наиболее востребованных качеств любого разраба добавил бы:
* умение находить общий язык с коллегами и общий уровень эмоционального интеллекта больше нулевого
* способность следовать принятым правилам вместо «я все равно знаю как лучше»
При достаточном уровне интеллекта и наличии мотивации, ответ на *любой* вопрос из упомянутых викторин гуглится/находится адекватным человеком за пару часов. Так что знание подобных ответов «на память» никак не показатель крутости кандидата. А незнание просто подтверждает факт, что память человека не безгранична.
mike1
А интересно, что не ценится в командах хорошая память, алгоритмическое мышление и «суперзвезды», которые могут в памяти держать сложнейшую систему целиком во всех нюансах и в динамике, проектировать гениально и имплементить не менее гениально, остаются не у дел. Зачем суперзвезды? Нужны средние разработчики. Гугление никакое не поможет сделать свою работу.
И неужели «способность следовать корпоративным стандартам» важнее способности делать свою работу?
Сорри, наверное, пропустил какой-то список важных качеств, который выше где-то был…
Mendel
Вы не поверите но да.
Суперзвезду можно заменить только суперзвездой. Или восемью посредственностями.
При этом пока ты его заменишь — замучаешься восстанавливать то, что он «держал в голове со всеми нюансами», ведь как мы уже определились — «следовать корп.стандартам» он не умеет или не любит.
Я очень хочу себе суперзвезд которые сами работают так, чтобы их было легко заменить восемью посредственностями, но к сожалению я таких не смогу себе позволить оплачивать.
Времена когда эффективность была важнее поддерживаемости уже прошли.
ganqqwerty
У меня такая гипотеза.
Алгоритмы задают на интервью не потому что алгоритмы важны в работе. Их задают потому что из 100 кандидатов надо выбрать одного. В этом случае нужно использовать статистические методы. Вот есть у нас 100 человек, и 49 из них знают алгоритмы, а 51 нет. В первом множестве вероятность того, что случайно выбранный разраб будет хорошим выше, чем во втором множестве. Цена false negative невелика — ну отсеял ты хорошего разраба, ну и фиг с ним. Из сотни надо только одного.
Строго говоря, можно кроме алгоритмов взять другой критерий — ну например, отсеять людей без профильного образования. Или негров! Не потому что они плохие, а потому что среди них меньше вероятности найти хорошего разраба, а мы хотим искать в множествах с большими вероятностями.
dimm_ddr
Когда 100 человек на место — да, можно и так. Часто такие компании встречаются?
ganqqwerty
ну вот поэтому гуглу и можно так делать, а условному Сперасофту — нет
dimm_ddr
Но при этом именно гугл сказал что это неэффективно и нужно делать что-то еще.
valbok
И продолжает практику изнурительных, утомительных, продолжительных, сложных интервью…
ganqqwerty
вроде не сказал, неделю назад друг собеседовался и рисовал какие-то деревья
bay73
Когда Гугл это сказал?
dimm_ddr
В 2013 году. Вот статья. В обсуждаемой статье есть эта ссылка.
tyomitch
Это они перестали загадывать головоломки из серии «сколько пианистов в Чикаго?» или «как в темноте вытащить два одинаковых носка?»
Алгоритмические задачки они как задавали, так и продолжают задавать.
dimm_ddr
Да, моя ошибка, я не разобрался в вопросе ко мне.
oldbay
Знаю я эту компанию :)) и её многоэтапные бесконечные собеседования: особое удовольствие получил от написания кода в дурацкой вебморде без интерпретатора.
Krypt
Ловил себя на мысли, что я *не знаю* сортировку пузырьком. Не «не помню», а именно «не знаю». Видимо в этот момент на лекции АСД я спал. При том, что квинксорт и сортировку бинарными вставками я вполне себе помню.
Idot
Важным является то, способен ли ты её понять и написать работающую реализацию.
Krypt
> написать работающую реализацию.
Зачем? Зачем мне писать реализацию сортировки пузырьком, если я могу взять готовую сортировку из используемого фреймворка?
И даже если мне уж очень понадобится самописная сортировка, я скорее всего пойду искать оттестированую реализацию квиксорта (просто из-за того, что моя собственная оттестированной не будет)
Idot
То есть это:
получается, что в точности про Вас!
Krypt
Ну почему же. Если есть возможность взять код, который лежит на каком-нибудь stackoverflow, который перепроверен и использован десятком человек, а так же, даже если и нет, его перепроверю я (уже две пары глаз вместо одной) — есть смысл это сделать. Это уменьшает шансы появления ошибок.
mustitz
Ок, а если, допустим, надо отсортировать массив из миллиона элементов и вернуть записи с 500 000 до 501 000?
Krypt
В худшем случае пузырёк всё равно даст N^2: когда в неотсортированной последовательности первый элемент оказался последним.
Думаю в таком случае всё же лучше подойдёт модификация квиксорта: можно не сортировать предварительно отсортированные диапазоны, вышедшие за требуемый лимит.
И всё равно я попробую сначала найти готовую реализацию этой идеи перед тем, как писать свою.
svr_91
Я попробовал набросать свой вариант. Надеюсь, правильно
https://habrahabr.ru/company/exante/blog/335096/#comment_10354038
Krypt
Я не знаком с библиотеками C++ во всех подробностях (просто потому, что стараюсь избегать этот язык всеми доступными средствами — он бессмысленно сложен). Так что ничего не скажу по поводу правильности.
Но это отличный пример, почему всегда нужно искать решение какой-то новой задачи: вы можете найти решение проще, чем придуманное вами.
mustitz
Модификация qicksort мне тоже пришёл в голову первым, но для этого его нужно таки знать. Более того, это знание может помочь даже в поиске.
Krypt
Ну в общем-то да, с этим я соглашусь. Но конкретно в этом топике мы говорим про целесообразность знания сортировки пузырьком. Что могу сказать по поводу. Баблсорт мне пригодился… НИ. КОГ. ДА. Даже на собеседованиях не спрашивали. А если бы copist не описал его в соседнем комментарии — из моего сообщения выше исчез бы всего один абзац про сложность.
Idot
Пузырьковая сортировка — это просто простейший индикатор того учил ли человек алгоритмы вообще. И задав этот вопрос с вероятностью свыше 90% можно ответить изучал ли этот человек алгоритмы или нет.
И да, это вопрос на позицию джуниора :)
Когда приходит к тебе некто без опыта работы и показывает диплом, а ты пытаешься его проверить, что он вообще умеет и знает.
Задавать этот вопрос опытному разработчику, так же бессмысленно как спрашивать у математика таблицу умножения, которую он учил в первом классе.
PS бравировать незнанием этой сортировки — ещё глупее, чем задавать этот вопрос опытному разработчику.
Mendel
Пфф. Инженер это не тот кто знает все что должен знать, а тот кто знает где это прочитать.
Зачем оно мне? Я изучал все эти алгоритмы сортировки в конце девяностых.
Не помню я их.
Помню что есть варианты экономящие память, есть варианты экономящие время работы… Если меня спросить — напиши любой алгоритм сортировки, то я напишу пузырьковую, ибо как самая простая она первая в голову приходит. Но то что это именно пузырьковая я сейчас знаю только потому что прочитал это в данном топике, и через неделю опять забуду.
А еще я не помню синтаксис запросов CREATE/ALTER и даже UPDATE/INSERT.
Более-менее помню Select, и то UNION буду подглядывать.
Не потому что я тупой, просто если я оказываюсь в голом коде, без фреймворка, то первым делом я открываю документацию по нужной мне СУБД и пишу ORM. Ну а при ручном просмотре инструмент просмотра имеет мышередактор для базовых запросов, и мы их видим только постфактум, уже при выполнении.
Об архитектуре СУБД со мной можно пофилософствовать. Парсинг запроса, структура индекса, блокировки — худо-бедно, но сходу что-то расскажу. А запросы? Вот буду через год писать драйвера для тех СУБД которых нет в текущем моем ORM, тогда и прочитаю.
И забуду через неделю.
Нужна будет сортировка — забью в гугл «Алгоритм сортировки», перейду в википедию и узнаю все что мне нужно, включая то какое отношение имеет к обсуждаемой теме вот эта картинка:
А если заказчик захочет поэкзаменовать меня на знание сортировок, то специально для него, прямо в википедии возьму готовый алгоритм сортировки, и залью ему на продакшн.
int correct( int *arr, int size )
{
while (--size > 0)
if (arr[size - 1] > arr[size])
return 0;
return 1;
}
void shuffle( int *arr, int size )
{
int i;
for (i = 0; i < size; i++)
swap(arr + i, arr + (rand() % size));
}
void bogoSort( int *arr, int size )
{
while (!correct(arr, size))
shuffle(arr, size);
}
Idot
А зачем Вам помнить их все?! O_O
А Вы кто? Джуниор?
Вы кроме самого себя любимого читаете кто что пишет?
Я вот тут https://habrahabr.ru/company/exante/blog/335096/#comment_10354490 прямо в сообщении, на которое Вы, прямо тут, не читая ответили, написал:
PS если Вы и на это сообщение продолжите отвечать на то, что Я НЕ ПИСАЛ!
То извините, Вам с Вашей манией величия и голосами в голове с которыми Вы разговариваете — к доктору => https://geektimes.ru/post/288084/ & https://geektimes.ru/post/289069/
Mendel
А чего истерить?
Таблицу умножения математик, да и просто грамотный человек вам в любом возрасте расскажет. Я половину таблицы не помню, но что не помню — мысленно добью сложением. А вот пузырьковую сортировку я не помню. Вернее помню что это словосочетание означает один из популярных алгоритмов, но какой именно — не помню.
Далее. По юниору.
Я буду сильно ругаться если у меня юниор будет из головы писать какую-то сортировку, даже если правильно. Или взять готовое из сети и подправить, или лучше не надо. Если интересно почему я против, то приведите мне блоксхему решения квадратного уравнения (гуглить можно), и тогда я отвечу.
Idot
=> то есть Вы тоже вот такой:
После Ваших слов я твёрдо укрепился в мысли, что джуниоров нужно проверять на умение мыслить самостоятельно, а не надеяться как Вы на умение у кого-то списать, потому что может попасться ситуация когда списать не у кого.
И да, вопрос к джуниору не "напиши алгоритм сортировки пузырьком", а "отсортируй массив не обращаясь к стандартной библиотеке".
Просто "пузырёк" это самое простейшее из того, что может придти в голову.
Mendel
Ок, я отброшу излишнюю вежливость:
1) вы не умеете внятно и однозначно высказывать свои мысли, что является плохим качеством для технаря
2) вы не способны провести элементарный дебаг собственных слов, даже после того как вас ткнули носом в вашу ошибку
3) вы истерически реагируете на замечания.
В принципе этого достаточно чтобы не продолжать разговор, но раз уж вы не поняли с первого раза то я разжую.
Любой математик ЗНАЕТ таблицу умножения или если даже что-то забыл то это не помешает ему ее назвать вслух мысленно заменив сложением. Это НЕ ЭКВИВАЛЕНТНО случаю когда опытный программист не помнит названия сортировок и тонкости классических алгоритмов в связи с тем что за те десятилетия что прошли с того времени как он их изучал.
На этом месте (а именно на различности этих примеров) крашится ваш концепт о том, что я опровергаю то чего вы не говорили.
Но дело даже не в этом. Главный посыл — юниору под страхом увольнения нельзя решать задачи требующие написания своего кода сортировки а не использования готовых методов языка. Это для вас первое что в голову приходит — пузырек. Мне первое что в голову приходит:
Ну да, у него квадратичное время и двойная память, но для небольших массивов вполне себе допустимо. Код в принципе читаемый, прилагаемый тест проходит. Просим оформить по-человечески и в продакшн? Или я на ревью должен потртатить примерно столько же времени сколько юниор писал такой код, чтобы его тщательно изучить? Нет, конечно я могу написать другие тесты и на других фикстурах оно может выглядеть иначе. Но не кажется ли вам, что лучше пусть тесты научатся писать чем велосипеды изобретать?
ПС: кстати вот еще одна задачка для собеса получилась — «сделать ревью для приведенного мною кода, после чего доработать этот код в соответствии с вашим ревью». ИМХО это прекрасный практический пример. Не сложный, и не слишком викторинный.
alexeykuzmin0
Блок-схемы очень уж неудобно сюда писать.
Я бы, получив такой вопрос на собеседовании, первым делом спросил бы, что делать в случае, если нет корней, если корни совпадают и если уравнение не квадратное, нужно ли проверять равенство коэффициентов нулю точно или с какой-то погрешностью (абсолютной или относительной?). А также в каком виде мы получаем входные данные и выдаем выходные — нужно ли их читать/писать в консоль, скажем.
Предположим, интервьювер дал ответы «выдать пустой массив», «выдать только один корень», «ну стандарт говорит, что в floating point типах не только числа есть», «проверяй точно», «пусть будет функция с тремя аргументами». Тогда я написал бы такой код:
Сразу после написания я бы еще сказал, что в реальном коде, вероятно, я бы разбил функцию на несколько: отдельно решение общего случая линейного уравнения, отдельно квадратного, отдельно проверки (не факт, подумать надо), отдельно вырожденный случай, чтобы не нарушать S.
Выше вы писали, что можно неплохо придраться к любому решению. Мне очень любопытно, что в этом не так.
Mendel
Не так в нем то, что то не блок-схема.
Нет, я конечно шучу, но не совсем.
В целом решение в данном случае закончилось бы на списке вопросов, дальше можно не идти. Однако придраться все равно есть к чему.
Вы сказали что блок-схему вы сюда не приводите потому что тут это не удобно (Чем неудобно я не знаю, ведь в гугле на первой странице в поиске картинок есть правильная блок-схема, пусть и не первая, ну ладно, ок, неудобно так неудобно).
Но вопросы вы задаете уже с учетом конкретной реализации в код, а не в контексте блок-схемы.
Но это так, придирка ради придирки, раз уж вы ловите меня на слове.
Krypt
> Это просто простейший индикатор того учил ли человек алгоритмы вообще.
Печальный факт состоит в том, что из всего университетского курса в профессиональной деятельности мне пригодилась только оценка сложности алгоритмов. Иии… всё. В общем, чему-то не тому у нас учат.
> PS бравировать незнанием этой сортировки — ещё глупее, чем задавать этот вопрос опытному разработчику.
Поздно. Теперь я буду бравировать тем, что знание сортировки пузырьком мне пригодилось всего раз в жизни: в споре о необходимости знания сортировки пузырьком.
Wan-Derer
Потому что это собеседование. Цель — проверка умений. Типа экзамена. На экзамене тоже дают задания, решённые тыщу раз.
Здесь цель проверить как ты умеешь перевести ТЗ в алгоритм, а алгоритм в код. Легче всего это сделать на ранее решённой задаче и сверить твоё решение с прошлым.
copist
Повторять обход с самого начала, пока таких перестановок не встретится.
Krypt
Что вы наделали, теперь я её знаю :D
acmnu
В том то и соль. Это не возможно развидеть :) Если когда-нибудь читал, то точно помнишь.
DistortNeo
Я бы написал ещё проще, одним предложением:
Обойти массив чисел N раз, попарно сравнивая два рядом стоящих a[i] и a[i+1] и меняя их местами, если a[i+1] < a[i]
Зачем ставить лишнее условие «пока таких перестановок не встретится»? Массив гарантируется отсортируется за N — 1 проходов в худшем случае. Меньше условий — проще код.
Ну и ещё можно докопаться, что обходить массив нужно «треугольником», то есть так:
Но по факту — плевать. На O-нотацию это не влияет, а ошибку допустить легко.
acmnu
А в лучшем случае он отсортируется за один проход. В таком случае вы сделает N-2 холостых проходов. И O(N) превратится в O(N2)
DistortNeo
> А в лучшем случае он отсортируется за один проход.
Ну и что? В общем случае, вероятность лучшего случая близка к нулю (от задачи зависит, на самом деле). Нет смысл здесь делать оптимизацию.
> В таком случае вы сделает N-2 холостых проходов.
Да ну и хрен с ним.
> И O(N) превратится в O(N2)
O-нотация всегда рассматривает наихудшие случаи.
acmnu
Но это не значит, что надо писать заведомо под худший случай.
DistortNeo
Да, про наилучшие/средние оценки я немного протупил.
Но в конкретном случае это роли не играет. Средняя оценка количества операций для пузырька тоже равна O(N^2), поэтому оптимизировать пузырёк под частные случаи нет никакого смысла.
alexeykuzmin0
Вот только у нас время работы алгоритма зависит не только от размера входных данных, но и от самих данных, поэтому мы можем рассматривать разные случаи оцениваемой функции f(x):
Все эти оценки являются О-нотацией, и все находят реальное применение на практике (первый попавшийся пример).
Именно поэтому нужно писать «сложность алгоритма в худшем случае O(f(n))» или «сложность алгоритма в среднем случае O(f(n))». Когда не указано, какой случай рассматривается, обычно предполагается, что это понятно из контекста. Вот мне, например, из комментария выше очевидно, что рассматривается случай уже отсортированного массива. Так что здесь действительно O(N) превращается в O(N^2). Если у пользователя достаточно много отсортированных (или почти отсортированных) массивов, это будет очень неэффективно.
DistortNeo
> Если у пользователя достаточно много отсортированных (или почти отсортированных) массивов, это будет очень неэффективно.
А давайте не будем усложнять задачу и додумывать условия, которых изначально не было? К тому же, для частично отсортированных массивов существуют более эффективне решения.
Doktorov
Как то на собеседовании на должность разработчика по C# первый вопрос который мне задали это предложили обсудить какую-то главу из третьего тома Кнута(sic!?). Естественно я ничего не ответил. А вот мой последний проект на ASP.NET 5, часть которого я им выслал для ознакомления не оценили, потому-что он не запустился!!!
Другие товарищи предложили мне написать свой дженерик, как тестовое задание. Тут уже я отказался, предложив им с такими заданиями набрать студентов.
MATov
После прочтения сразу вспомнилась нашумевшая в своё время статья "Интервью глазами пострадавшего"
lookid
А что в нём не так? Просто вопросы. Я понимаю, что "Написать нахождение 2х ближайших точек за NLogN" может быть уже черезчукр. Хотя его дают на 30 минут в DICE LA. Вообще все эти срачи похожи на нытьё неосиляторов. Люди, которые идут в программирование порой и не догадываются о том, как много нужно будет делать. Программист APi-колов, который не задумывается о сложности не напишет гугл. Вот и всё.
MATov
Всё в нём так, но когда шумели обсуждения — многие называли такой подход словами аля «токсичный», что и заставило вспомнить эту статью после прочтения текущей.
nazarov_tech Автор
прочитал тоже. Ну да, там довольно суровый чувак :)
Но если это для него хорошо работает — почему нет? Вопросы-то все непосредственно нужные для геймдева, насколько я могу судить.
vasily-v-ryabov
Раз уж это перевод или русская версия, то хотелось бы ссылку на оригинал. И ссылки на вики русифицировать можно для полноты и удобства. Спасибо за статью!
nazarov_tech Автор
это не перевод, статья моя.
Что насчёт ссылок на вики — вроде там всего одно место, где вики английская, и это намеренно (мне не понравился русскоязычный вариант, он с искажениями смысла).
lagranzh
Помоему, это называется selection bias. Google наблюдал за результатами работы только тех програмистов, что прошли интервью. Другими словами, из того что среди прошедших интервью — 50% хорошиx работников, не следует что такой же процент будет среди не прошедших интервью.
dimm_ddr
Я конечно не могу этого гарантировать, но я уверен, что спецы гугла знакомы с понятием АВ тестирования и в состоянии применить его для процесса отбора кадров. А с их количеством желающих, скорее всего, возможно даже нормальную точность получить.
hoack
По поводу писания кода на доске — я всегда прошу сделать это в начале разговора. Задачу предлагаю примитивную, с очевидным алгоритмом, и ни в коем случае не придираюсь к синтаксису и мелким огрехам. Например, я прошу написать функцию Fib (n), которая будет возвращать n-ое число Фибоначчи. При этом я охотно напоминаю определение чисел Фибоначчи. Почему я это прошу? Да потому, что я считаю, что преобразование алгоритма в код — это основное умение программиста. Человек, который не в состоянии, получив определение чисел Фибоначчи, написать функцию, их вычисляющую, вряд ли будет способен нормально программировать.
По поводу теоретических вопросов — большое О и так далее. У программиста должна быть теоретическая база, должно быть представление об алгоритмах, их сложности и т.п. Понятно, что в наше время все можно погуглить и найти — так вот, программист должен понимать, что именно гуглить. Я не считаю, что программист обязан уметь определять сложность алгоритма; но иметь представление о том, что это такое, понимать, что логарифмическая сложность лучше линейной, и чем чревата квадратичная он обязан.
botyaslonim
В один модный-стильный-молодёжный банк не берут тех, чьи родственники имею судимость. Информация из первых рук
vgoloviznin
Не вижу в этом ничего необычного
Idot
Необычно то, что речь о родственниках.
Это что, если у человека родственник живёт за границей с него тоже нужно справку о не судимости?!
greendimka
Всё обычно — убирают риски. Никому не нужен работник, у которого такой родственик выкрадет пароли-явки, условно говоря, ради получения небольшого барыша, и сдаст их конкурентам.
Утрирую? Отнюдь. Когда нужно влезть в систему конкурента — ищут самые слабые места. Первым делом прощупывают работников. Есть уйма способов надавить на сидевшего человека. Поэтому такой родственник — слабое звено.
botyaslonim
Но это ужасно, по сути. Родо-племенная ответственность
vgoloviznin
С этим я не спорю, но такое практикуется не только в банках, и, как написали выше, риски достаточно велики
Areso
Как они это проверяют? В нарушение законодательства?)
dimm_ddr
Не то чтобы в РФ это сильно неожиданно. Всем известный же факт, что в крупных конторах есть специальный отдел, который проверяет все что сможет найти про человека. С учетом легкости покупки слитой базы чего угодно в нашей стране тут даже какими-то специальными навыками обладать не нужно.
nonnenmacher
Так там работают бывшие сотрудники органов со связями. Им и базы слитые не нужны. Работал в подобной организации. Под видеокамерами как-то возле дома мой автомобиль кто-то царапнул и скрылся с места ДТП. Я раздобыл с видеозаписи номер и марку автомобиля, сходил к нашим безопасникам, и через полчаса знал ФИО, телефон и адрес виновника.
AKiNO
В любой банк не возьмут, т.к. есть формальный фильтр в виде службы безопасности. Более того, даже плохая кредитная история может помешать, даже если руководитель разработки очень хочет нанять кандидата.
manny21
Думаю, всё это нытье про глупые вопросы и токсичные интервью идет от той боли, которую испытал человек заваливший интервью.
Все эти разговоры не об интервью на самом деле, а о любимом себе, который «вы нам не подходите» услышал как «ты кретин», как оскорбление, унижение.
И решение искать нужно именно здесь, в себе. А не «пусть весь мир перестроится под умного-достойного меня», «это не я дурак, а интервьюер».
Есть подозрение, что если оскорбленному вдруг когда-нибудь придется искать исполнителя, которому платить надо будет свои кровно заработанные, разговоры о правильных интервью кардинально изменятся. :)
AKiNO
1. В статье само собой подразумевается, что речь идет о компаниях, которые делают свой продукт/сервис. А вот, например, мне, работая в аутсорс компании, часто приходится собеседовать людей на абстрактную позицию «Java Developer» (т.к. аутсорсовой компании нужно всегда иметь примерно 10% «свободных рук» для того, чтобы безболезненно стартовать новые проекты). И я заранее не знаю, пригодится ли нам завтра специалист по Cassandra или мастер разработки десктоп-приложений на Eclipse RCP. В этом случае предпочтение логично отдается как раз тем кандидатам, у кого стандартная библиотека Java от зубов отскакивает и нет проблем с базовыми алгоритмами и со структурами данных.
2. Еще стоит акцентировать внимание на том, что собеседование, оно не в первую очередь, для того, чтобы выяснить «насколько крут» кандидат (хотя это тоже важно при сравнении). Оно в первую очередь для того, чтобы взять на работу человека, с которым будет комфортно работать *мне* (и любому другому члену моей команды). Т.е. он должен не отравлять неформальную корпоративную культуру, которая исторически сложилась в компании. И если в абстрактной конторе всем нравится рисовать сортировки маркером на доске, то они будут искать тех, кому тоже нравится рисовать сортировки маркером на доске.
botyaslonim
Забавно, что этот твит Дэвида снова фигурирует как стартовый тезис для топика на Хабре. Вот прошлое обсуждение: https://habrahabr.ru/post/323188/
От себя теперь, в связи с получением нового опыта, могу добавить следующее.
Самое страшное собеседование не там, где просят карандашиком написать алгоритм обхода бинарных деревьев. И не там, где спрашивают редко используемые методы каких-нибудь библиотек.
Самое плохое интервью там, где врут насчёт условий и характера будущей работы.
Пример: вы приходите к одному очень крупному (прям самому крупному в России) IT-работодателю, успешно проходите техническую часть интервью, далее будущий руководитель проекта буквально упрашивает вас выйти на работу, потому что в ваших услугах очень нуждаются.
Вы принимаете положительное решение, проходите бесконечные проверки (ведь это же самый крупный в России IT-работодатель!), даже сдаёте кровь и делаете флюорографию. Наконец, через месяц, вас готовы видеть в офисе. Вы выходите и прям с первого же дня понимаете, что вас тут не ждут. Вот прям буквально. Вы бэкенд, а тут нужен сильный фронт-енд. Или девопс. Или вообще наоборот. Но факт в том, что характер работы никак не соответствует вашей специализации и вашим ожиданиям. Вам либо надо очень быстро переучиться, либо искать то, что было нужно изначально.
Соответственно, впустую потраченные 2-3 месяца, впустую пережитый стресс от выхода на новое место, потери в зарплате и новый цикл поиска работы. А тот руководитель, который вас упрашивал выйти именно к ним в подразделение, в глаза вам говорит, что он вообще не понимает, кто вас нанял.
Вот это настоящая жесть.
Adel-S
У меня было нечто похожее (правда в чуть более лайтовом варианте). И знаете что? Я быстро переучился и вытянул проект. И не считаю это время зря потраченным. Опыт — это всегда хорошо. Его потом всегда можно сконвертировать в деньги (или в новый опыт).
dimm_ddr
Это все-таки не всегда правильное поведение. Просто из-за косяка собеседующего менять область работы на другую так себе идея. Особенно если область неинтересна. Я вот не горю желанием уходить во фронтенд например, даже на большую зарплату.
Перечитал и понял что получилось достаточно агрессивно, извините. Такой вариант вполне может быть и нормальной реакцией, зависит от ситуации конечно.
houk
Автор — ты просто сделал весь мой день и вдохновил все мое будущее! СПАСИБО огромное!
houk
Прощу прощения за фамильярность (ты), конечно же Вы, но если честно. я до сих пор нахожусь под впечатлением!