Сначала о том, как 5 месяцев назад я проходил собеседование на работу. Меня посоветовал друг, и прошло уже немало времени, с момента как я ответил рекрутеру. Я был поражён, как сильно весь процесс изменился за последние 5 лет.
После первичного созвона меня отправили на сторонний сайт (HackerRank), чтобы я решил три небольших задачки за 1 час. Для меня это был первый подобный опыт. Первые две задачки были простыми, но третья оказалась посложней. Когда время подошло к концу, моё решение не проходило все тесты, а только где-то 8 из 10 необходимых.
Уже на данном этапе оказалось, что я отфильтрован из списка потенциальных кандидатов. Нет худа без добра, так как чуть позже я серьёзно заболел и, пройди я собеседование успешно, просто не смог бы нормально добираться до места работы. Полученный опыт, однако, заставил меня серьёзно задуматься. Я решил подготовиться на будущее и делал по одной задачке с того сайта каждую неделю.
Задачки Повсюду
Мой хороший друг сейчас ищет свою следующую работу, будучи кандидатом наук в Информатике с более чем десятилетним практическим опытом. Почти каждый раз его просят решить какие-нибудь задачки — очно или на стороннем сайте. Он приобрёл Cracking the Coding Interview (в России книга издана как «Карьера программиста» — прим. перев.), чтобы шагать в ногу с рынком труда, но развитие любого навыка занимает время. А несколько отличных вакансий уже прошли мимо.
Проблема всплыла в обсуждении на Megamaker (закрытое англоязычное сообщество для разработчиков и стартаперов — прим. перев.) и один из участников поделился наболевшим:
Скоро мне стукнет 45 и свой стартап (где был CTO) я покинул в декабре. С тех пор я завалил не меньше 10 тестов и интервью на программиста. Пишу код при этом я уже почти 20 лет, включая создание прошивок (по образованию я инженер-электронщик) и полномасштабные распределенные веб-приложения с интеграцией IoT. Я с нуля создавал ПО для крупных специализированных производственных объектов по всему миру. Тем не менее, я просто не могу устроиться программистом, потому что постоянно проваливаю эти тестовые задачки.
А этот твит Макса Хауэлла пошёл в массы несколько лет назад. Это и смешно, и грустно, и одновременно правда.
Факт: для многих Senior Developer'ов, когда они начнут искать другую работу, следующее собеседование может оказаться неприятным сюрпризом.
Разработчики Ненавидят Задачки
Некоторые программисты отвечают…
Я обычно заканчиваю интервью, когда мне предлагают что-то подобное.
или
Способность решить эту задачку ничего обо мне не скажет. Могу ли я общаться с клиентами? Могу ли развернуть работающее веб-приложение? Могу ли нагуглить всё необходимое? Могу ли обучаться на лету? Вот что важно, а не способность написать сортировку пузырьком.
Контраргумент заключается в том, что задачки нужны, чтобы быстро отсеять явно слабых кандидатов. Хотя, конечно, и опытный разработчик может не захотеть их решать, если у него вагон предложений.
Я тоже думаю, что эти задачки ничего не скажут о способности кандидата справляться с настоящей работой. Формулировка часто хромает, а информации недостаточно (или нельзя сделать однозначный вывод о её достаточности). В большинстве случаев задачки на самом деле относятся к миру математики. Так что, кстати, наличие профильного образования будет преимуществом.
Рекрутёры почти гарантированно завернут кандидатов, которые могли бы стать ключевыми в компании. Так например, когда Даниэля Бухмюллера не приняли в Netflix…
Компании Любят Задачки
Чтобы понять, откуда появились задачки, нужно понять как изменился мир вокруг: доля работающих удалённо постоянно растёт, а международные команды становятся нормой.
Но вместе с ростом пула удалённых разработчиков растёт и количество заявок, которые нужно обработать, чтобы найти подходящего сотрудника. Можете представить себе работу с 500 откликами на одну вакансию?
К тому же я слышал о собеседованиях, где кандидат вообще не умел программировать (не мог написать программу типа hello world). Тратить время десятки таких собеседований не хочет никто.
И задачки в качестве средства первичного отсеивания решают обе проблемы. Компанию устраивает риск потери пары крутых кандидатов ради значительного ускорения всего процесса. Теперь с почти неограниченным пулом претендентов они могут себе это позволить. Сухая статистика показывает, что конвейер выдаст больше хороших специалистов в единицу времени.
Поэтому я считаю, что задачки на собеседованиях — всерьёз и надолго, и их роль будет только расти.
Потребность в программистах велика как никогда и тем более в Senior Developer'ах. Вот только не рассчитывайте, что годы опыта купят вам беззаботное трудоустройство. Готовьтесь к решению тестовых задачек, пока время не поджимает.
Комментарии (774)
habradante
22.07.2019 16:36Если компании требуется писать ПО основанное на умении решать подобные задачки, то, может, им и не нужен никакой senior? Если ведущего программиста можно определить по умению решать задачи, то, по логике, любой, кто решит такую задачу — ведущий программист.
Просто изначально верная задача «отсеивать неподходящих кандидатов» неверно решается. Вводя формальные признаки фильтрации надо понимать, что искомая выборка характеризуется этими признаками. И вот на этом этапе облом, потому что искомая выборка «ведущие программисты» не обладает признаком «умеет решать алгоритмические задачи».masterspline
22.07.2019 19:21+6> задача «отсеивать неподходящих кандидатов» неверно решается
IMHO, изначально решается задача «найти подходящих кандидатов». И неважно, сколько гениев будет отсеяно вместе с остальными неподходящими. Компании, скорее всего, нужна команда взаимозаменяемых квалифицированных спецов. Возможно, они даже умышленно отсеивают уникумов с уникальными запросами.
Если ты неординарный разработчик и отсеиваешься на таком конвейере — тебе нужно искать другой вход в компанию. Например, как-то проявить себя, чтобы к тебе изначально было особое отношение при найме. Но для этого нужно действительно быть особенным, а не просто считать себя таковым. И сколь бы ты ни был уникален, тебе при любом раскладе нужно быть командным игроком.
Ну, или эта контора тебе не подходит и не нужно даже пытаться туда попасть и тем более жалеть, что не удалось в нее пробиться.
cross_join
22.07.2019 16:40Альтернатива задачкам — работа в консалтинге. Доверие фирме распространяется на ее консультантов, поэтому обычно речь идет об одном собеседовании. По прошествии некоторого периода, если работа консультанта оказывается полезной, его приглашают в штат. Плюсы и в том, что токсичное место работы (у клиента) проще сменить, не прерывая при этом работу в консалтинговой фирме.
time2rfc
22.07.2019 17:14Очень редко пишут про работу в консалтинге, интересно что это за зверь такой. Можете пару слов писануть — как это работает, есть ли такие компании в России, правда ли что там авральный режим но огромные зарплаты и периоды безработья ?
cross_join
22.07.2019 17:50О, это длинная история, я к ней подступался в «Дефрагментации мозга», но уже 6 лет прошло.
С российской спецификой консалтинга знаком поверхностно, однако автор текста тоже не в РФ работает.
Если коротко, то консалтинговая фирма сосредотачивается на технической и/или функциональной компетенции сотрудников, продавая их клиентам на проекты по дневной ставке на несколько месяцев. Миссии экспертизы/аудита более короткие, от нескольких дней до недель. Клиент доверяет фирме, поэтому на короткие миссии вообще никаких собеседований не происходит, на длинные — одно-два, обычно совмещенные. Зарплаты немного выше, чем на постоянных позициях, но не в разы, конечно. Неудобство разве что в сильной динамике среды. Тем, кто привык годами «пилить» одно и то же с теми же и на том же будет трудно.
Dolios
22.07.2019 19:57+12В рунете подобные фирмы называются галерами и отношение к ним неоднозначное.
cross_join
22.07.2019 22:20Как я уже сказал, с российской спецификой знаком мало, в основном сталкивался с отсутствием культуры работы с консультантами, когда месяцами ищется свободный специалист на рынке. Исключение — внедрение ERP, там это хорошо работает с 1990-х.
Консалтинговая фирма по определению небольшая. Когда она растет, то либо начинает брать заказы, проекты себе, либо превращается в «галеру» (бодишоп в США, продавцы мяса во Франции) и перестает быть консалтинговой — в крупной фирме нельзя удержать экспертов, большая текучка, уровень компетентности быстро падает.
foal
23.07.2019 00:22-1Хм… PwC (pricewaterhousecoopers) это небольшая? А Java програмисты там работают, в основном, как консультанты — на краткросрочных проектах.
cross_join
23.07.2019 10:59PwC — хороший, но единичный пример (и специализируются они совсем не на Яве и ИТ). Несмотря на размер они прилагают массу усилий для поддержания уровня компетентности «выше среднего по больнице». Начиная с пяти собеседований для отсева кандидатов.
В крупной фирме это дорого и хлопотно, поэтому их единицы, тогда как типовая консалтинговая фирма оптимального размера — 50-150 человек.
P.S. Минусовал не я, не люблю это дело. Только «лайки», LinkedIn рулит :)time2rfc
23.07.2019 11:32Сколько времени может занимать консалтинг на одном проекте и когда это перестает быть уже консалтингом и становиться аутстафингом ?
cross_join
23.07.2019 11:53Обычно недели и месяцы (необязательно на полную неделю). Например, до ввода в эксплуатацию, далее — точечные заходы.
Но дело не столько во времени, консультант должен привносить навыки и умения, отсутствующие в данный момент на проекте. Их и аккумулирует фирма, продающая услуги.
Если сотрудника просто послали на неделю пятым сишарп-программистом, чтобы заткнуть «дыру», то это чистый аутстаффинг.time2rfc
23.07.2019 15:42Спасибо! Звучит очень интересно, пойду гуглить где такие специалисты нужны.
cross_join
23.07.2019 15:59Видимо для РФ типовой консультант это внедренец ERP (SAP, Dynamics, 1С...), специалисты Microsoft (MSPD...), Oracle, программисты с финансовым бэкграундом (банки).
Успехов вам!
DrunkBear
23.07.2019 16:06Дополнительно вам пригодится знание предметной области, разговорный английский и понимание индусского разговорного английского.
Ну и широкий кругозор — часто после внедрения системы Х будут спрашивать, что лучше внедрять и интегрировать к ней, продукт Y,Z или что-то ещё и если вы знаете о них, а лучше — и о подводных камнях этих систем, ваш контракт продлевают и расширяют.
dimm_ddr
23.07.2019 16:10+1Российская специфика тут только в отношении, сами-то компании вполне себе международные. Я даже добавлю что неоднозначное отношение к таким галерам есть, пожалуй, во всех странах. Кто-то доволен — адекватные зарплаты и постоянно новые проекты, интересно. Кто-то жалуется — зарплаты могут быть и меньше чем у других компаний на рынке (зависит собственно от страны), вовлечения в проект нет никакого, каких-то бонусов вроде корпоративов обычно толком нет, ну и так далее.
vladkorotnev
24.07.2019 03:51Смотря откуда сотрудник и какие у него взгляды. Работаю в чём-то подобном в Японии и вижу полный спектр эмоций — кто-то доволен чисто потому, что в Японии; кто-то недоволен из-за того, что не дома; кто-то вообще на седьмом небе ибо палкой не бьют и хорошо.
Понятно, что у мьянмийца, который приехал с зарплаты в 70 баксов, будет кайф и стремление удержаться, а у кого-то типа меня наоборот — ибо платят меньше, ходить в офис надо, монитор мелкий, клавиатура из говна, мышка в руке теряется, вместо кода спагетти и вообще шавухи купить негде :-)
vershinin
22.07.2019 20:14+1Ниже не про консалтинг. Консалтинг, это когда ты сам делаешь себе фирму, и сам платишь себе зарплату, выставляя клиенту счет за услуги: это может быть тюнинг виртуальной машины, оптимизация производительности, ускорение базы данных, перевод на новую платформу, а может быть и обычное программирование. Суть в том, что репутация работает на вас.
cross_join
22.07.2019 22:15+2Когда «ты сам делаешь себе фирму» это называется фриланс или ЧП. При этом можно быть консультантом, а можно и не быть.
vershinin
23.07.2019 12:14Да, так лучше. Однако, консультанты обычно фрилансерят, а не гребут на галерах.
morozko
23.07.2019 14:47Консалтинг — это практика продажи знаний и экспертизы, т.е. консультирование. Консалтинг бывает в самых разных сферах. Компания-клиент может заказать консалтинговый проект по разработке бизнес-стратегии, по оптимизации бизнес-процессов, по выбору или внедрению информационной системы, по диагностике предприятия.
К консультантам обращаются, когда либо не хватает собственной экспертизы, либо нужно подтвердить уже разработанное решение именем известной компании.
В России консультантов на любой вкус. Размер зарплаты зависит от конкретного вида консалтинга, загруженность — от того, насколько хорошо дела идут у компании.
AWSVladimir
23.07.2019 23:22Альтернатива задачкам — работа в консалтинге
Для меня альтернатива задачкам сделать рабочий, оплачиваемый мини-проект перед устройством на работу. За это время познакомишься с командой, постановкой задачи, внедрением и другими важными подводными камнями и тараканами.
Там где спрашивают про задачи не работал, не сложилось, но 2 компании где делал тестовые проекты, перед устройством, самые классные (тфу-тфу-тфу).
Это была лично моя инициатива проверить компанию и что бы компания проверила меня.
Я уже описывал свои критерии выбора работодателя, повторятся не буду, может кому будет интересно habr.com/ru/post/423953/#comment_19142917"
irsick
22.07.2019 16:42-4Бедняга, это он ещё тилидом не был. На следующих этапах собеседования превратятся в допрос с пристрастием в стиле «а кто ты такой, пришёл тут с улицы руководить МНОЙ?».
Автор находится на самом начале пути, в стадии отрицания. Очевидно, что его 5-летний опыт не релевантен рынку, т.к.:
а) Он не менял работу и начал профессионально деформироваться (в компаниях редко бывают разнообразные проекты, если только это не consulting). Скорее всего, рынок ушел сильно вперёд.
б) 5 лет без собеседований. Крышки люков и автобусы теннисных мячиков постепенно уходят в прошлое, большое О и красно-черные деревья остаются, набирает популярность код в прямом эфире, тестовые задания больше походят на реальные проблемы.
в) Зона комфорта, высокомерие и тонкокожесть. Автор очень болезненно переживает стадию «окунания в г*но» на собеседованиях, возможно заболел по этой же причине. Лечится работой над собой и своими навыками: codewars.com, фильмами про Рокки, Karate Kid и тд.
г) Senior в одной компании != senior в другой. На новой работе выслуга лет и опыт работы с конкретными людьми над определенным продуктом могут обесцениться практически полностью. Остаются только эмпирический опыт и computer science.ukt
22.07.2019 19:31+1a) — не совсем понятно
б) устраивался в одну международную контору, они меня своими задачками три часа мучили, меня это откровенно на втором часуподзнадоело, и спрашивали всякую ересь, вот никак не связанную с реальными задачами. Другая контора, тоже межграничная, спрашивала, а вы знаете map'у, я откровенно отвечаю поясните, что вы имеете в виду (хэшмам, тримап, редусемап, или объект из js фреймворка, отвественного за отображение граф данных), вместо пояснения галочка в опроснике… Ну и на кой писать реализацию какой то мапы, изобретая велосипед? Каждый день их писать что ли?)
в) окунание в гогно — это эдакий способ сбить цену работнику, так себе, если с ходу, незнакомого человека макают в гогно — лесом товарищей.
г) сеньор это таки не совсем про опыт, хотя он тоже важен, он скорее про способ мышления.irsick
22.07.2019 21:53Благодарю за развернутый ответ. Все вышесказанное основано на собственном опыте на рынке США. На прошлой неделе, наконец, закончись мои собственные «хождения по мукам», поэтому тема оригинальной статьи особенна близка и свежа в памяти.
а) Пять лет — целая жизнь по меркам технологий. При найме человек, как правило, более-менее соответствует требованиям рынка, но со временем начинает отставать, тк бизнес ориентируется на проверенные временем, часто «уже не модные» решения.
Исключения тоже есть. Из моей практики это либо консультанты (у них каждый проект может быть уникальным, надо постоянно быть в тонусе), либо AAA-компании в авангарде индустрии (Google, Facebook и тд)
б) В последние разы меня просили написать более-менее реальные CRUD приложения, а один раз просто дали кусок продакшена и попросили запилить фичу, попутно разобравшись с их архитектурой кода.
в) Под «окунанием» я имел в виду сам процесс прохождения собеседований со стороны соискателя, особенно без знакомств. Не думаю, что кто-то наслаждается процессом общения с незнакомыми (часто неприветливыми) людьми, пытаясь доказать, что «не верблюд». На это уходит много нервов и сил, а результат неизменно непредсказуем.
г) Я использовал в контексте должности. Senior в ООО «Рога и копыта» != Senior в Google.
На определенном этапе карьеры должности перестают значить так много, как вначале. Иногда имеет смысл перейти работать на меньшую должность (и ответственность) и большие деньги в более высокотехнологичную компанию (win-win), а потом еще и получить там повышение (еще один win).sshikov
22.07.2019 22:40>а) Пять лет — целая жизнь по меркам технологий. При найме человек, как правило, более-менее соответствует требованиям рынка, но со временем начинает отставать, тк бизнес ориентируется на проверенные временем, часто «уже не модные» решения.
Совершенно не обязательно. Я неоднократно менял проекты в пределах компаний, и это был не консалтинг. Особо модных решений может и не было, но одинаковых все пять лет не было тоже.irsick
23.07.2019 00:14Мне тоже приходилось паять и программировать SoC, (де)нормализовывать базы и рисовать дизайн — все это в разных проектах одного и того же стартапа. А потом 4 года воевать в суровом энтерпрайзе с legacy на Mootools в 1M LOC.
По моему личному, субъективному, не претендующему ни на что 14-летнему опыту — интересные и актуальные решения на продакшене в энтерпрайзе встречались в 10% случаев.sshikov
23.07.2019 07:35Если что, я отвечал вот на эту фразу:
> (в компаниях редко бывают разнообразные проекты, если только это не consulting)
Я и не спорю с вашим личным мнением. Я только уточняю, что исключения в этом пункте — не обязательно консалтинг. Это, к примеру, крупные и очень крупные банки. А таких видел не меньше трех.VolCh
23.07.2019 10:41Да даже в рамках довольно небольших и даже не ИТ компаний часто бывает куча разнообразных проектах на разных стэках (ну или выбираешь стэк сам). Как минимум внутренние системы и внешние публичные "витрины"
JustDont
22.07.2019 16:55Готовьтесь к решению тестовых задачек, пока время не поджимает.
Никогда не понимал, зачем. Потребность в программистах, а особенно в таких, кто реально может решать задачи, которые нужно решить — огромна, и пока что всё только растёт.
В таких условиях реагировать на попытки дрессировки тебя неумелыми нанимателями (через решение задачек, через вопросы о круглых люках, и прочую байду) — совершенно излишне. Просто идите к тем, у кого на собеседованиях нет повышенного градуса неадеквата, а от остальных немедленно уходите, встретив первые признаки неадеквата.
dss_kalika
22.07.2019 17:00+1Когда ты чего то стоишь — покупатель найдётся.
Когда не очень — … тогда придётся учиться проходить собеседования.JustDont
22.07.2019 17:03Сейчас состояние рынка труда в ИТ такое, что чего-то стоит практически любой, кто вообще хоть какой-то код может писать и адекватно общаться с окружающими. И края этому не видно.
dss_kalika
22.07.2019 17:10ну да.
Но таких людей — единицы, среди безбрежного океана странных личностей.
Я в разное время видел много соискателей… и это грусть-тоска. =)
Я уже не говорю про то, что потом за ними в коде остаётся.
Так что — первых разбирают достаточно бодренько (по крайней мере, больше 3-4 собеседований они редко проходят, что бы не получить оффер), а последние — учатся проходить собеседования.
dvenum
23.07.2019 07:04Мой опыт также говорит, что «риск потерять двоих кандитатов из пула стоит сэкономленного времени», это странное утверждение. Из 500 заявок как раз двое и будут, которые вам нужны. Ну еще наберется человек 50, которые продержатся месяц или два, а нанять кого-то из них, это куда большие потери, чем повнимательнее поискать.
glestwid
23.07.2019 13:02Расскажите это тем, кто например устраиваетсясейчас в KPMG во Франкфурте, где хрюша проводит каждый день по 5 собеседований и где на вакансию претендует порядка 20 человек, причем с хорошим английским и ненулевым немецким.
Kanut
23.07.2019 14:06Вы мне сейчас действительно хотите рассказать что в Германии стоит очередь в 20 человек на какое-то айтишное рабочее место, да ещё и в контору типа KPMG, где не особо новых технологий не используют, ни условия труда идеальными назвать нельзя, ни звёздочки на кунуну особого впечатления не производят? :)
Лично у меня опыт просто противоположный. Да просто сделайте профиль среднего сениора на степстоне или монстере и посмотрите сколько предложений вам придёт в течении первого дня :)glestwid
24.07.2019 10:15Вы мне сейчас действительно хотите рассказать что в Германии стоит очередь в 20 человек на какое-то айтишное рабочее место, да ещё и в контору типа KPMG, где не особо новых технологий не используют, ни условия труда идеальными назвать нельзя, ни звёздочки на кунуну особого впечатления не производят? :)
Именно так. Потому как это мой свежий личный опыт с небольшим инсайдом + опыт коллеги, подававшегося туда же месяц назад. Просто они могут себе позволить хантить со всего ЕС + привет Brexit, подкинувший до фига народа из Англии на рынок во Франкфурте. По слухам, в Commerzbank ровно такая же картина — конвеер на сотни кандидатов.Kanut
24.07.2019 11:49Ок, я могу себе представить что конкретно сейчас и конкретно во Франкфурте для айтишника с определённым стеком технологий стало сложнее найти работу. Но в очередь в 20 человек на место я всё равно не верю.
Druu
24.07.2019 15:03Но в очередь в 20 человек на место я всё равно не верю.
Если под "очередью из 20 человек" понимать каких-то 20 человек, а не тех, что нормально подходят — то вполне реально, может и все 100 быть.
Fedorkov
24.07.2019 13:39привет Brexit, подкинувший до фига народа из Англии на рынок во Франкфурте.
А как именно брексит привёл к этому?
dimm_ddr
23.07.2019 16:12Конечно. Но вот зарплата у тех кто стоит немного но натренирован проходить такие собеседования может быть выше чем даже у того, кто знает больше, но прыгать через обруч не хочет. Так что если вы не рок стар, то вам придется расставлять приоритеты — деньги или адекватность нанимателя.
Acuna
22.07.2019 22:04+1Увы, но не все так просто. Сверхпрофессионалы даже чаще не могут найти работу чем студенты: большинство компаний понимают что могут не потянуть таких специалистов, либо считают что ему у них будет со временем тесно, ибо они не смогут ему гарантировать расширение круга интересных задач, а так же плюшек для удержания, ибо он больно крут для такого места, но понятно что свою крутизну при этом скрывать не выход, ибо лгать в резюме нехорошо, особенно когда вскроется, что ты работал в условном Яндексе. Зарплатные ожидания понижать тоже не выход, мой знакомый рекрутер рассказывал, что нередки случаи когда на собеседования являются рок-звезды на зарплату 30 тысяч, таких обычно они отсеивают, потому-что непонятны мотивы почему человек в возрасте со знаниями на 300 000 идет на 30 000, ибо это явно не тот предел для такого специалиста.
JustDont
23.07.2019 08:45+2таких обычно они отсеивают, потому-что непонятны мотивы почему человек в возрасте со знаниями на 300 000 идет на 30 000, ибо это явно не тот предел для такого специалиста.
А открыть рот и словами спросить человека, почему он так делает — не? Слишком сложно?
Mirn
23.07.2019 09:22причин такого много:
1. на куда джуна проще пройти если до этого программированием почти не занимался, например раз в неделю (электронщик или админ) или
2. или есть желание просто попробовать новую отрасль без заморочек со всеми этими свистоплясками с 5-10 собесами и цирком у доски. или просто хочешь обучиться чему то нахаляву да ещё на кофе заработать (почему бы и нет?).
3. есть очень хорошие компании которые совершенно не умеют искать и собеседовать людей и поэтому проще уйти на минимальную должность (умолчав что ты спец в искомой ими области с 20летним стажем) и быстро получить повышение, тем-более если финансовый жирок позволяет.
4. Я знаю одного человека который тусил по компаниям которые пользовались трудом неопытных студентов с ставкой в 20-30тр и в свой стартап набрал оттуда сливки — команду крепких разрабов которые остальных тащили и задалбывались, в итоге стартап выстрелил в тех плане.JustDont
23.07.2019 09:27Да я знаю, что причин много. Мне непонятен вывод «таких обычно отсеивают, потому что нам непонятно, как вообще так». Непонятно? Так спросите.
Dolios
22.07.2019 19:59+3Если вы хотите в фейсбук, амазон или "неадекватный" гугл, задачки решать пртдется научиться.
sshikov
22.07.2019 20:02+8А если не хотим?
nlog
23.07.2019 20:08+1Но виллу в Испании хотим, так что придётся в гугл :)
sshikov
23.07.2019 20:48Пардон, а кто вам обещал виллу? В смысле, покажите мне реальные проекты, на которые гугль берет, очень хочется посмотреть.
Я поясню, почему скажем я совершенно не хочу в фейсбук. Для начала — на мой взгляд, все их видимые снаружи продукты — полное г. Я не утверждаю, что мои продукты скажем лучше — просто у меня не возникает желания ассоциироваться с этим. Иначе говоря, доверие к компании — на нуле. Гугль… ну это другое, но не сильно лучше. Наверное, в дебрях алфавита можно найти очень интересные проекты с высокой зарплатой, но вот так чтобы бежать туда ради виллы в Испании?
Охотно верю при этом, что могут быть и другие взгляды на это, в данном случае это всего лишь мое лично мнение.
Mirn
24.07.2019 03:42к сожалению там где можно заработать на виллу в Испании, порой приходится отдавать две-три таких «виллы» за аренду жилья, так что есть некоторые сомнения, что по итогу, можно заработать на «виллу».
JustDont
22.07.2019 20:58Если вы сами куда-то хотите — то разумеется, пляшите так, как потребуют в том самом месте (если вам после этих плясок туда не расхочется, разумеется).
А если нет?sshikov
22.07.2019 21:57+2Так самое смешное в том, что при этом со стороны нанимателя это почему-то выглядит одновременно как:
>Теперь с почти неограниченным пулом претендентов они могут себе это позволить.
и
>Потребность в программистах велика как никогда и тем более в Senior Developer'ах.
Когда я бывал на стороне нанимателя, я ни разу не видел живьем этот «почти неограниченный пул претендентов». И даже не слышал про такой. Только второй вариант имеет место — большая потребность, и малый выбор кандидатов. И даже не на синьорские позиции иногда.
А то, что я вижу, будучи кандидатом (особенно в случаях, когда не ищешь работу, а просто анализируешь поступающие самотеком предложения), как раз выглядит так, будто наниматель (не обязательно условные фейсбук и амазон, но и они тоже) вообще никакой потребности не ощущает.
>если вам после этих плясок туда не расхочется, разумеется
Очень может быть, что и до них.Nalivai
23.07.2019 16:08Неограниченный пул — он у гуглов. Просто проблема в том, что все хотят быть гуглом, оттого и культ карго. В майкрософт 400 человек на место, значит программистов неограниченно, они и в мой ооо вектор пойдут.
sshikov
23.07.2019 19:41>Просто проблема в том, что все хотят быть гуглом
Проблема в том, что не все. Я вот например не хочу. Причем давно. И не столько потому, что задачки не хочется, сколько потому, что хрен их поймешь, в какой проект тебя засунут в итоге. И именно гугли с фейсбуками этим как раз страдают в большей степени.
Впрочем, если сравнивать с любой другой типовой конторой — то да, у некоторых практически неограниченный. Ну и так, просто на заметку — из текста вроде бы не следует, что речь конкретно о гугле. Оно там как-то неявно очень сильно обобщилось.
blind_oracle
23.07.2019 03:00-1Гугл звонит и пишет раз-два в год.
И каждый раз я у них спрашиваю: мне все еще придется у вас 5 часов рисовать на доске фломастером всякие квик-мерж-хип-сорты, жонглировать красно-черными деревьями и считать О-большое?
Говорят — придется. До свидания.
0xd34df00d
23.07.2019 03:07+2А я сходил. Прикольно, ничего сложного, с тремя из пяти интервьюеров было время играть в гляделки после того, как я ответил на все вопросы, это было забавно. Потом какой-то вялотекущий team matching, это уже менее забавно.
Но хрен с деревьями этими, у них же по личным занятиям в свободное время политика драконовская.
vladkorotnev
23.07.2019 03:49А что именно за политика?
0xd34df00d
23.07.2019 03:57+1Весь ваш интеллектуальный труд принадлежит им (по крайней мере, в США и конкретно в Нью-Йорке, здесь законы позволяют такие рабочие контракты, в Калифорнии может быть повыгоднее для работника). Ну, кроме, возможно, книг по садоводству, если вы вдруг решите таковые писать.
Хотите в свободное время по вечерам и выходным делать свой проект на гитхабе? Фигушки, согласуйте, запрашивайте разрешение, ставьте копирайт (или авторство, хз) гугла. Можно и без этого, но это сложно и с существенно меньшей вероятностью разрешения. И если ваш проект вдруг противоречит их интересам (ну там, движок для адблокера захотите написать, клиент для Телеграма, или JS-компилятор, хз), то вам им спокойно заниматься не дадут. А интересов у гугла много.
Днём пишете опердни на Java, а хотите в свободное время писать статьи по теории типов? Согласуйте, это слишком близкие области.
В свободное время помогаете людям на SO? В примерах кода, которые вы там пишете в ответах, ставьте копирайт гугла.
vladkorotnev
23.07.2019 04:31+1Понятно, ну его нафиг тогда.
Всегда предполагал, что все эти цветные офисы со столами для пинг-понга лишь для создания иллюзии уюта, а по факту большинство как на обычной галере торчит по 12 часов на работе и ничем этим не пользуется.0xd34df00d
23.07.2019 04:48+1Ну, кстати, зависит.
В больших компаниях как раз очень просто либо имитировать бурную деятельность, а на самом деле не делать нихрена (в смысле того, что на выходе этой бурной деятельности), либо тихо сидеть в сторонке с 9 до 5, не отсвечивать и заниматься своими делами (которые вполне могут быть связаны при этом с самопрокачкой, да).
Я бы даже сказал, что большие компании к этому стимулируют.
vladkorotnev
23.07.2019 07:00У нас в японской компании де-юре самопрокачка запрещена в силу белого списка софта и отгороженного политиками интернета.
Де-факто наш офис какой-то "удалённый" и поэтому имеет обычный неограниченный интернет, поэтому SSH с иксами домой в РФ и оттуда можно делать что хочешь.
Отстрелялись с релизом, клиенты ещё не пришли в себя от празднования, делать нефиг всё равно, так можно Rust покурить :-)blind_oracle
23.07.2019 09:45Дурь какая. Закрывать разработчикам доступ везде? А зачем вы там работаете?
vladkorotnev
23.07.2019 09:52Работаю, чтобы накопить на перевозку крупногабарита и уехать домой, ну и параллельно по концертам всяким походить :-)
Здесь-то ограничений на сети нету, но на не-своём компе логиниться куда-то в свои аккаунты не хочется, поэтому удалённые иксы и только.
А до того сидел в компании, принадлежащей одному автопроизводителю, там да, был интернет через прокси и с кучей лимитов (в том числе отрублен habrastorage). Зато там видели моё собеседование и поэтому забивали на то, что я в свободное время пишу что-то своё, и игнорирую вайтлист, лишь бы не сбежал :-)
В локалке нашелся установочник макоси, засунул в виртуалбокс и вспоминал былое в икскоде.
А код в обход всех их изощрений прекрасно дёргался на гитхаб протоколом Git-over-GoogleMaps :-)
Впрочем, у них изощрения как раз были оправданными, ибо там серьёзные данные на машины, которые конкурентам были бы мягко говоря интересны. Что не отменяет того, что отношение удручает — ты NDA подпиши, но зондов мы тебе всё равно напихаем.
Fedorkov
23.07.2019 11:36А код в обход всех их изощрений прекрасно дёргался на гитхаб протоколом Git-over-GoogleMaps
Вы имеете в виду Git over Google Translate?vladkorotnev
24.07.2019 04:03+1Нет, именно мапсы.
Краткий гайд по выживанию в анально отгороженной средеТянем репу зипом с гитхаба (ибо git не алё). Распаковываем, создаём внутри репозиторий гита. Уходим на бранч develop.
Работаем с кодом. Делаем коммиты как обычно.
В конце рабочего дня делаем (Cygwin)
git format-patch master --stdout | gzip --best | base64 > /dev/clipboard
Опционально можно добавить шифрование.
Идём в гугловский My Maps, ставим пин на любимую кафешку, в описание делаем Ctl-V, чуть-чуть ждём и сохраняем.
Придя в безопасное окружение открываем мапсы, копируем то, что насохраняли и делаем (Cygwin)
cat /dev/clipboard | gunzip - | base64 --decode | git apply
Вуаля, коммиты из закрытой среды перетекли в открытую. Пушимся, на следующий день повторяем. Если из дома не работать, а только пушиться, можно зип не тянуть каждый раз (в моём случае было актуально для репы под 300 метров).
Можно было, конечно, всё заскриптовать, но больно сложно для пары раз.
В теории так выносятся любые файлы, как показала практика, емнип до 25 мегабайт (до закодирования) влезало в один пин спокойно, лишь бы браузер не грохнулся.
Заносить было проще, на крайняк приклеиванием хедера и куска от PDF к зашифрованному tgz с последующей выкачкой.
Что как бы намекает на всю эту "безопасность" без эиргапа...
vvbob
23.07.2019 08:57У нас сейчас тоже все эти пинг-понги модными стали. Где бы ни работал никогда не понимал — откуда брать время на всю эту пинг-понговую хрень, я обычно все рабочее время довольно интенсивно, блин, работаю, у меня нет ни времени ни желания торчать во всех этих игровых комнатах. Я лучше с делом быстрее разберусь и пораньше домой уеду, я на работе деньги зарабатываю а не в игры играю.
VolCh
23.07.2019 10:45Часто поуплрны пинг-понги всякие, когда пораньше уйти домой, получая те же деньги, нельзя
vladkorotnev
23.07.2019 11:35И в такой момент задаёшься вопросом, стоит ли такая компания того, чтобы тупо продавать ей впустую время своей жизни за деньги?
Nalivai
23.07.2019 16:16Кому как, я 8 часов без перерыва работать не могу, не хватает. Раз в пару часов встать, прогуляться, чайку-кофейку, на турничок, глядишь и силы появились.
vladkorotnev
24.07.2019 04:05Опять же, это если отталкиваться от условия, что надо работать 8 часов, а не по мере решения проблемы/задачи :-)
RedTalon
24.07.2019 08:43Это вам даже не эффективных менеджеров, а нейробиологов пинать нужно. Это они, стервецы, удумали, что умеренная физическая активность позволяет мозгу лучше работать. При чём и в краткосрочной, и в долгосрочной перспективе. Так что, если вы не ночной сторож, которому платят за часы, а не за результат мозговой деятельности, то работодатель действует в собственных интересах, соблазняя вас всякими пинг-понгами.
vvbob
24.07.2019 09:09Я лучше проведу на работе часа четыре, если важен именно результат, а не затраченные часы, а оставшимся временем распоряжусь по своему желанию, чем буду торчать на работе по 12 часов, убивая скуку на всяких пинг-понгах.
О пользе физической активности я в курсе, обычно хватает короткой прогулки, полезно для организма и дает возможность оторваться и подумать.
dominigato
24.07.2019 13:10А я хотел бы в бильярд поиграть в перерыве, пинг понг требует подготовки и так сразу в него не поиграешь. А бильярд — просто и прикольно. Заодно помогает сконцентрироваться и отвлечься, потом можно вернуться к работе со свежей головой. Заменяет любой mindfulness))
blind_oracle
23.07.2019 09:45+2Ну, кому что нравится.
Если меня припечет работать именно в Гугле (или прочих буквах FANG) — пойду, конечно, обратно вспоминать все эти сортировки и прочее, которые мне пока в реальной работе пригодились примерно ноль раз. Поэтому я считаю что это бесполезное занятие на собеседованиях, в отличии от того же Distributed Systems Design который у них есть на SRE.
Но хрен с деревьями этими, у них же по личным занятиям в свободное время политика драконовская.
В Европе, вроде, такое невозможно. Представляю себе что тут начнется если работодатель начнет мне указывать чем в свободное время заниматься… дикость. Минус 1 балл к переезду в US :)0xd34df00d
23.07.2019 15:06Если меня припечет работать именно в Гугле (или прочих буквах FANG) — пойду, конечно, обратно вспоминать все эти сортировки и прочее, которые мне пока в реальной работе пригодились примерно ноль раз.
Так это не обязательно же ж. Они там, конечно, высылают что-то вроде буклетика и ссылок на видео для подготовки перед интервью, но я забил и ничего этого не смотрел и не делал.
В Европе, вроде, такое невозможно. Представляю себе что тут начнется если работодатель начнет мне указывать чем в свободное время заниматься… дикость. Минус 1 балл к переезду в US :)
Ну, это вопрос выбора и конкретного контракта. Моему текущему работодателю плевать вот, например. А куче других людей плевать на все эти внеклассные активности, судя по тому, как они хотят в Гугл. Хорошо, когда есть выбор!
wataru
23.07.2019 12:07Уже давно, вроде как, можно писать код не на доске, а на предоставляемом ноутбуке. Да, в примитивном текствовом редакторе, без автодополнения и подстветки синтаксиса, но никто и не смотрит на интервью, если вы опечатаетесь где-то или порядок аргументов в библиотечной функции перепутаете.
kashtan404
23.07.2019 11:12Не все так плохо. Могу сказать со стороны их поиска на позиции SRE. В Амазоне да, привет hackerrank. В Гугле, техническое интервью представляет из себя общение с сеньором/лидом на технические вопросы и последующее решение задачки, но онлайн и без привязки к синтаксису (хоть псевдокодом), лишь бы логика была верная. Конечно, вы скажете что, «да один фиг олимпиадные задачки решать», но по-моему мнению, это намного проще, когда есть живой диалог. Как минимум видно, что потенциальному нанимателю не все равно.
blind_oracle
23.07.2019 12:34В Гугле, техническое интервью представляет из себя общение с сеньором/лидом на технические вопросы и последующее решение задачки, но онлайн и без привязки к синтаксису (хоть псевдокодом), лишь бы логика была верная.
Так это первый, удаленный этап же. Потом ты топаешь к ним в офис и имеешь 4-5 интервью по часу с разными людьми и вайтбордом. Может вайтборд уже и позволяют заменить на ноут, как указали выше, но это не делает процесс более полезным на мой взгляд.kashtan404
23.07.2019 14:52Да, согласен с вами. Спрашивал у HR, про все этапы которые будут. Ответ был такой: есть несколько команд которые заинтересованы, поэтому на очном интервью, будут этапы с каждой из них. На что я попросил краткое описание стэка и задач, которые использует каждая из команд, чтобы сузить выборку. Оказывается так можно. Потенциально я снизил свои «шансы попасть в Гугл», но это и не является моей целью. Важно найти интересное место, а не громкое имя, имхо.
blind_oracle
23.07.2019 15:35Ответ был такой: есть несколько команд которые заинтересованы, поэтому на очном интервью, будут этапы с каждой из них
Нет там команд в контексте интервью. Каждое из них с отдельным человеком — он потом пишет отзыв в Hiring Committee, который уже по совокупности отзывов от всех интервьюеров решает брать тебя или нет. И вот уже после этого только возможен выбор команды.
Это насколько я понял как раз один из их способов избежать предвзятости при найме. Сомнительный, как по мне…
grinCo
23.07.2019 04:18В СНГ все легко и просто с работой. В бей эрия решения задачек не хватит для сеньера.
vav180480_2
22.07.2019 16:56Меня однажды мой бывший руководитель (с которым я проработал несколько лет) лично рекомендовал в ЕПАМ (он там уже лет 5 работал), сказал собеседование плевое, можешь не готовиться. Я после работы прибежал на собеседование, красный, запыхавшийся (была весна, утром холодрыга, я был в теплой одежде, а днем уже жара — я вспотел пока бежал). Меня очень хотели завалить и таки завалили, я нервничал еще (первый собес за 10 лет). В итоге собеседование прошел другой мой коллега, лет на 10 младше, с гораздо меньшим опытом, но он готовился:) Мой бывший руководитель был удивлен не меньше меня, а еще сказал что я на интервьюирующих произвел впечатление больного человека (красный, потный и все такое:)) и я там вообще в черном списке теперь. Во как бывает. Хотя мобыть и к лучшему:)
vvbob
22.07.2019 22:10+1Лет пять назад собеседовался в ЕПАМ, меня там заставляли рисовать домики (после успешного прохождения техинтервью) и доскребывались почему я этот домик именно так нарисовал, а не как-то по-другому. Ну и еще всякая лабуда типа оценить сколько было продано бензина на ближайшей заправке, еще что-то там… А еще постоянно намекали что работать там придется по выходным и сверхурочно и скорее всего задаром.
В итоге я тоже на эти галеры не попал, о чем нисколько не жалею.arheops
23.07.2019 02:04+2Может это был тест на то, спросите ли вы «зачем» или нет
vvbob
23.07.2019 09:02Может быть. Но у меня больше сложилось ощущение что человек просто надергал в сети «заковыристых задачек» из статей — «как стать профессиональным психологом за полчаса и три урока» и решил тут-же, не отходя от кассы их применить.
В любом случае я давно уже не связываюсь с местами где неоплачиваемая работа в выходные считается нормой рабочего процесса, поэтому ни о чем не жалею.Mirn
23.07.2019 09:12эхх еслиб они ещё эти уроки делали и статьи читали, как то на вакансию разраба электроники автооборудовния, на полном серъёзе, попросили заполнить анкету, в которой часть вопросов была связана с гос тайной а часть что то там про звания и устав. Погуглив понял что это взято из военного опросника в случае если человек с секретностью хочет забугор и это не первая а N ая анкета в случае… итд
vvbob
23.07.2019 09:42Часто эти собеседования просто вешают на какого-либо человека, особо не интересуясь его желанием всем этим заниматься, а он идет по пути наименьшего сопротивления, «наотлюбись». Вот и имеем, то что имеем. Хорошие кандидаты отсеиваются, на фирме дефицит специалистов да еще и рабочее время проводящих интервью оплачивается впустую.
VolodjaT
23.07.2019 00:03А в черный список за что?
Mirn
23.07.2019 03:42+1Да чёрные списки скорее всего существуют, например, украинский чёрный список на весь инет прославился. Ну а я умудрился попасть в чёрный список Яндекса, и сразу рекрутеров со всех галер типа датаарта и епама как рукой сняло, они после этого даже прервали диалог который вёлся. А попал забавно — им нужно было сделать ускорение нейронок на FPGA причём скорее аппаратную часть, забраковали меня после теста на веб программирование с формулировкой «не ИТшник а мошенник какой то, в чёрный список тебя!» после того как я честно признался что на JS дерево не могу развернуть и не знаю что за грязные хаки мне на задание выдали (а там судя по исходникам просили объяснить смысла такого трешака за который в нормальных фирмах сразу увольняют, я потом на разных сайтах просил растолковать их «примеры» извиняюсь за ругательство — все плювались от быдлокода).
А раз чёрные списки скорее всего существуют, то проблема в статье ещё сильнее усугубляется: Даже если предположить что только часть компаний их придерживается, то при невезении всего с одной все остальные лишаются специалиста. И наверное поделом им.vvbob
23.07.2019 09:07Когда последний раз искал работу, на меня выходили вербовщики от яндекса, предлагали пособеседоваться, сразу честно сказали что процесс займет недели три (там что-то то-ли четыре, то-ли пять собеседований по несколько часов). Так-как у меня уже были на руках два хороших оффера, то я вежливо отказался. Я, конечно, понимаю, это одна из самых известных российских IT фирм, но такой формат поиска спецов от них многих отпугивает. Это нужно ну очень сильно хотеть работать у них, что-бы такой марафон пройти.
blind_oracle
23.07.2019 09:53Я, помнится, в свое время ходил в Я раза три в течении лет 5 на должность админа. Проходил каждый раз по паре-тройке собеседований и потом меня отбраковывали по какой-то загадочной причине, которую они не называют.
После этого решил на зазывания их рекрутеров забить, только время тратить без обратной связи нормальной.coolkimchi
23.07.2019 12:29ну, это известная своими программистами контора. Как-то я проходил интервью на Python разработчика и интервьюер спросил в чем разница:
a = 1
b = a
a == b vs a is b
Я ответил, что в данном примере разницы нет и оба True и даже попытался объяснить ему почему Python не C/C++. В итоге интервьюер надменно «очень удивлюсь если это действительно так». Через HR я попросил передать ему книжку Python для чайников и больше не писать мне.Debug_all
23.07.2019 15:48a = 1
Не могли бы раскрыть свою мысль и направить в документацию в правильном направлении?
b = a
a == b vs a is b
Я ответил, что в данном примере разницы нет и оба True и даже попытался объяснить ему почему Python не C/C++.
На мой, не специализирующийся на Python, взгляд, вопрос имеет под собой почву:
И в случае с мутабельными объектами разница может быть:a == b # сравнение по значению a is b # сравнение по object id, на который ссылаются переменные
a = [1, 2, 3] b = a # произойдет присвоение по ссылке с = a.copy() # произойдет присвоение по значению d = a[:] # произойдет присвоение по значению # Значения всех трех переменных равны: a == b # True a == c # True a == d # True # Но переменные a и b ссылаются на один и тот же объект списка: b is a # True # А переменные c и d ссылаются на отдельные объекты: c is a # False d is a # False # Модифицируем данные: a.append(4) b.append(5) c.append(6) d.append(7) # И получим: a == b # True a == c # False a == d # False b is a # True c is a # False d is a # False # Через переменные a и b был поочередно модифицирован один и тот же объект. # Значения этих переменных по-прежнему равны: a # [1, 2, 3, 4, 5] b # [1, 2, 3, 4, 5] # А для переменных c и d - нет: c # [1, 2, 3, 6] d # [1, 2, 3, 7]coolkimchi
23.07.2019 16:04>>в данном примере разницы нет
Небольшие integers (кажется, до 16 но не ручаюсь) существуют в памяти Python программы как синглтоны и все ссылки указывают на один и тот же объект в памяти.Fedorkov
23.07.2019 17:26Вы, должно быть, путаете с интернированием строк.
Если размер переменной меньше, чем указателя, её таким образом не оптимизируешь.coolkimchi
23.07.2019 18:03+3О, а вы, видимо, из Яндекса :)
Нет, я не путаю с интернированием строк. В этом и суть плохого интервьюера: свои рассуждения ставить превыше знания того, как работает интерпретатор. Все прекрасно оптимизируется, только не так, как вы думаете.
docs.python.org/2/c-api/int.html
В памяти хранится весь массив int в пределах, который попадает под оптимизацию.
Debug_all
24.07.2019 12:08Вопрос к сообществу и заминусовавшему в частности.
В чем в примере выше ошибка по существу?
Был бы признателен за конструктивную критику.
vav180480_2
23.07.2019 06:49Мне после первого собеса сказали подготовиться и попробовать снова, я подготовился и попробовал снова, мне почему то написал мой бывший начальник, его даже попросили (видимо чтобы ответственность не нести, мало ли что) и сказал что я там плохое впечатление произвел (больной или болезненный что то такое) и мою кандидатуру теперь не рассматривают в принципе, если это не ЧC, то что?
monah_tuk
23.07.2019 09:12По поводу, "больного", запыхавшегося. Я бы сходу выдал что-то подобное: "так к вам спешил, что аж дыхание сбил, да и погода внезапно намекнула, что одеться нужно было полегче". Имхо, много бы вопросов сняло :) Я, бывает, вставляю словечки, которые актуальны для игроков в онлайн PRG, так меня с опаской сразу спрашивают — в онлайн игры играете? Приходятся говорить, что любимая RPG — Fallout 2, разок в год-два пробежаться. В общем, тут скорее вопрос коммуникации. Честно, каким бы мегаграмотным не был бы человек, с ним ещё общаться нужно.
vav180480_2
23.07.2019 11:09Это был мой первый собес за 10 лет, возможно я не придал значение такой мелочи (с моей точки зрения, сейчас понятно что это реально не мелочь, потому как не просто спеца, а человека берут), все-таки это кое чему меня научило, к любому собесу надо готовиться, хотя-бы морально:) внешний вид и состояние тоже имеют значение. Опять же, оно и к лучшему, я соскочил с PL/SQL на более популярный стек, проблем с работодателями стало на порядок меньше и лишний раз понял что крупные компании это не моё (были еще Неткрекер и Куйбышевазот) — непонятная шестеренка которая непонятно что и для кого делает, на входе это, на выходе то, почему и зачем? — так в документации, мне как то поближе к человеку хочется.
mopkob
23.07.2019 11:37+1Прочел статью. Закрыл хабр. Вернулся.
Ваша реплика про опыт в ЕПАМ укрепляет меня в догадке, что уже даже среди программистов подбор персонала стал «не про специальность» (ну и градации, в зависимости от компании, от «совсем не про специальность» до «не совсем про специальность»).
Про «нравишься» и «не нравишься», про возраст (скоро стукнет 45), про рынок труда который отдельные представители HR так структурировали (есть примеры корпораций и компаний), что приходящие вновь команды не могли не то, что специалиста нанять… На интервью никого затащить. При весьма конкурентных предложениях, ведь в кругу нужных специалистов 3% слила одна из предыдущих команд, 15% побывали на интервью и были растоптаны.
И в этом контексте желание научится решать задачки выглядит довольно мило.
Их обязательно нужно уметь решать. Однако это сомнительный гарант устройства на работу.
А потребительское отношение к кадровому ресурсу — короткая дорога, оканчивающаяся тупиком.
RPG18
22.07.2019 16:59Хорошо если 1 час. В некоторых компаниях приходится проходить N собеседований по часу, на которых решаешь задачки. Где N зависит от количество команд, в которых открыты вакансии. Может быть 5, а может 11.
snuk182
22.07.2019 17:17А если в итоге прошел, остаток жизни приходится жевать сопли на бесконечных митингах, где менеджеры, дизайнеры, тестировщики и разработчики спорят, в какой цвет красить кнопочку.
Mirn
23.07.2019 03:58+1Как то взяли разработку пищалки которая пикает прерывисто когда у грузовика включается задняя передача, всё именно так и было: десятки скайп совещаний с полсотней менеджеров и директоров разных там газмяс-альф и бетт, почта превратилась в вообще Re:Re:Re:Re:… теперьточноокончательная версия(2197) с почти стократным вложением. Кое как вытянул проект и уговорил их взять готовый именно для этого предназначенный и сертифицированный на всякие морозы и IP69 компонент с защитами от всего, генертором и динамиком, из новоразработанного только крепление и корпус был.
Хотя изначально надо было просто узнать форму корпуса и чёртёж посадочного места что обычно делается за пару бесед с адекватным бизнес процессом не нацеленным на оправдание завышенной стоимости. Да они потратив миллионы рублей на совещания потом ещё тянули до последнего с оплатой несчастных 50тр.
TheKnight
22.07.2019 22:56+1Где вы такую жуть встретили? В Яндексе?
Whuthering
23.07.2019 01:21+1У меня такое в Яндексе было, да.
Mirn
23.07.2019 04:02+2в Японском аналоге Яндекса есть ещё круче: там после кучи собеседований нужно прочитать всю книгу-автобиографию основателя компании ну «очень скромно» названную «моя великая борьба» и написать изложение по ней во время спец экзамена без инета и под надзором, ну и конечно всё это на японском.
vladkorotnev
23.07.2019 04:33+2Это у ракутена такие приколы?
Помню, они пытались меня схантить, видимо хорошо, что не поддался :-)baton4iik
23.07.2019 05:36+2Ракутен. 3 месяца собеседований. 4 интервью. В конце попросили написать эссе на книги основателя, но, благо, можно было писать дома и на английском. Похоже, если не боготворить митера Микитани, то в ракутен не попасть.
monah_tuk
23.07.2019 09:17А что… Пишешь эссе с названием "Моя (не)великая борьба" где просто стебёшься над тремя месяцами собеседований. Да ну его нафиг, им специалист или жополиз нужен?
siziyman
23.07.2019 13:47Сейчас Ракутен очень (слишком!) легко набирает на работу выпускников российских вузов без всяких подобных извращений.
Оффер получил, не поехал.
lanseg
23.07.2019 08:57+1О, я тоже в Ракутен собеседовался, мне тоже дали книжку. Я прямо спросил "Это обязательно? А то я не люблю весь этот успешный успех", мне ответили "Ну не хотите — не читайте, положено предлагать, а дальше дело ваше. Всё равно, никто не спрашивает."
monah_tuk
23.07.2019 09:18+1"А что, так можно было!?" :)))
lanseg
23.07.2019 10:01Видимо, можно, оффер-то мне выдали. Я даже думал его принять — всё же, Япония, экзотика, пару лет вполне можно поработать, но огорчил отпуск — 11 дней и нельзя выбирать самому даты. Даже с учётом золотой и серебряной недели это слишком мало.
RPG18
23.07.2019 11:16Верно угадали. Приятель проходил два года назад, он забил после 11 собеседования. Я проходил этот квест в июне было 5. Никаких вопросов про паттерны, языки программирования, базы данных и т.д. Тупо решаешь задачки.
neurocore
22.07.2019 17:02Я люблю задачки, особенно на собеседованиях. Одно расстраивает — это совсем не коррелирует с тем, чем ты будешь заниматься в компании.
nochkin
22.07.2019 19:21+1Я тоже люблю задачки, всегда интересен процесс и обсуждение выбранных методов.
Но проблема в том, что многие интервьюверы считают решение задачек чуть ли не единственным критерием адекватности нанимаемого. Бывают даже забавные моменты когда проводящий интервью знает меньше по теме и поэтому любое отклонения от его (не совсем верного) ответа считает полным провалом.
Или отсутствии корреляции с тем, что надо будет делать на новой позиции как верно подмечено.
То есть, если очень уж хочется задачки, но их надо считать больше дополнением, а не основной темой собеседований на работу.
Izulle
22.07.2019 17:13Я люблю решать задачки, но мне их далеко не на каждом собеседовании задают. Более того, туда, где я все задачки решила, меня не взяли. Даже 2 раза. Зато взяли туда где никаких задач не задавали.
Однако обижаться не стоит. Просто цена ошибки при найме довольно высока, а нормальных способов оценки кандидатов нет.JustDont
22.07.2019 17:38+2нормальных способов оценки кандидатов нет
Есть. Но они требуют наличия собственных профильных специалистов уровнем как минимум не хуже. Если таких нет — то всё сложно, да. Либо устраивать конкурсы олимпиадников и в итоге нанимать профессионального проходителя собеседований, либо пытаться просто по человечески пообщаться, и нанять того, кто не может работать, но может навешать достаточно лапши.
Если же собственные спецы есть, то просто разговор «по душам» о прошлом опыте и сложных случаях из жизни плюс минимальная проверка способности писать код (не олимпиадные задачи на время, а что-то уровня FizzBuzz), чтоб исключить профессиональных обманщиков — вполне достаточна.siziyman
23.07.2019 13:59+1разговор «по душам» о прошлом опыте и сложных случаях из жизни
Может быть проблемным, если много что под NDA.JustDont
23.07.2019 14:01+1NDA — это не гостайна. От важной для бизнеса конкретики можно абстрагироваться примерно всегда, и обсуждать алгоритмы и подходы в более общем виде.
siziyman
23.07.2019 14:13+1Я встречал задачи, рассказ о которых вне бизнес-конкретики абсолютно лишает разговор смысла.
PsyHaSTe
25.07.2019 00:34Вряд ли NDA защищает диаграмки вида "вот тут у нас сыпались сообщения в очередь, сервис разбирал и писал в эластик, а вот тут фронт оттуда читает"
siziyman
25.07.2019 01:39Я не сказал, что не существует задач, которые невозможно обсуждать, если проект закрыт NDA.
Я сказал, что есть задачи, к которым очень сложно задать разумные вопросы, и от которых совершенно невозможно отойти вправо-влево и развить беседу, если не понимать бизнес-задачи проекта, которые могут быть закрыты NDA.PsyHaSTe
25.07.2019 02:30Формально есть, вопрос, в том ли ареале, где живет большинство разработчиков. Я лично думаю, что нет.
smarthomeblog
22.07.2019 17:48Олимпиадные задачки ведь тоже гарантии качества разработчика не дают. Тем более, сеньера. Тогда зачем они?
ingvarwolf
22.07.2019 17:20В Монреале есть одна компания, у которой процесс найма на работу занимает очень продолжительное время. Самый короткий срок от первого собеседования по телефону до контракта, который я знаю, занял 6 недель. Самый длинный — 18 месяцев. Как правило они проводят несколько интервью по телефону и несколько личных встреч. Всегда на первом интервью задают вопросы о том как работает сборщик мусора, как там всё устроено. Ни один из проводивших интервью не смог мне внятно привести примеры из их реальных проектов, когда эти знания помогли или были по-настоящему необходимы.
Я спрашивал нескольких разработчиков, которые работали в этой компании, как им приходилось использовать эти конкретные знания в работе. Самый лучший ответ: «Знание о том, как работает сборщик мусора, нужны чтобы пройти интервью. Больше они не нужны.»
AllexIn
22.07.2019 18:42Для меня ваше сообщение выглядит очень странным.
Знание как работает GC нужны, чтобы понимать когда объект будет удален, чтобы понимать что если мы только что освободили большой объект и хотим сразу создать еще один большой объект, то нельзя расчитывать что память уже есть, её вполне может не быть(правда тут надо смотреть на конкретный GC, потому что есть такие, которые увидят что памяти не хватает и грохнут ранее освобожденный объект, а есть такие, которые так не делают. и это надо знать).
В общем и целом, такие особенности рабочего окружения знать надо.
Если ваши коллеги и вы живете без этого знания, скорее всего вы либо пишите мелкий софт, либо плохой.snuk182
22.07.2019 18:58+2Как часто вы создаете объекты размером со всю доступную VM память?
Как часто вам встречаются бизнес задачи, требующие создания объектов размером со всю доступную память?amaksr
22.07.2019 20:59+2Как часто вы создаете объекты размером со всю доступную VM память?
Это и не нужно. Достаточно в цикле читать и обрабатывать какую-нибудь таблицу (или запросы). Если в этом цикле используются любые ресурсы ОС, то забыть закрыть ресурс (а с ним и все связанные объекты) очень даже легко. И даже если не забыть, то не факт, что сборщик будет чистить так, как вам бы хотелось. Мне как-то довелось оптимизировать память процессу на яве. Поставил явный вызов GC, хоть во всех мануалах пишут, что это делатьне надо. Коллеги на ревью удивились, но после демонстрации уменьшения памяти на 50% смеяться перестали. Так что всяко бывает, а памяти всегда мало.snuk182
22.07.2019 21:13+3забыть закрыть ресурс
Это не "объект размером с память", это баг.
не факт, что сборщик будет чистить так, как вам бы хотелось
Для этого придумали пулы объектов.
Поставил явный вызов GC
Вам сильно повезло. Обычно жор памяти в Java = утечка. С множеством короткоживущих объектов GC справляется без полной остановки, чисто за счет Эдема.
amaksr
22.07.2019 22:49Вам сильно повезло. Обычно жор памяти в Java = утечка.
Вот код без утечек, только-что запускал:public class MyTtest { public static void main(String argc[]) { while(true) { List<String> arr = new ArrayList<String>(); for(int i=0; i<10000000; i++) arr.add(new String("abc")); System.out.println(new java.util.Date()); System.gc(); } } }
Запустил без строчки с GC, процесс быстро набрал 2GB оперативки, CPU циклично скакал от 25 до 90%,
лог выглядел такMon Jul 22 15:39:31 EDT 2019
Mon Jul 22 15:39:34 EDT 2019
Mon Jul 22 15:39:34 EDT 2019
Mon Jul 22 15:39:35 EDT 2019
Mon Jul 22 15:39:35 EDT 2019
Mon Jul 22 15:39:37 EDT 2019
Mon Jul 22 15:39:37 EDT 2019
Mon Jul 22 15:39:39 EDT 2019
Mon Jul 22 15:39:39 EDT 2019
Mon Jul 22 15:39:42 EDT 2019
Mon Jul 22 15:39:43 EDT 2019
Mon Jul 22 15:39:43 EDT 2019
Mon Jul 22 15:39:46 EDT 2019
Mon Jul 22 15:39:46 EDT 2019
Mon Jul 22 15:39:47 EDT 2019
Mon Jul 22 15:39:50 EDT 2019
Mon Jul 22 15:39:50 EDT 2019
Mon Jul 22 15:39:51 EDT 2019
Mon Jul 22 15:39:51 EDT 2019
Mon Jul 22 15:39:51 EDT 2019
Mon Jul 22 15:39:53 EDT 2019
Mon Jul 22 15:39:53 EDT 2019
Mon Jul 22 15:39:54 EDT 2019
Endeavour
22.07.2019 23:03В зависимости от GC, вызов System.gc() может быть заимплеменчен как угодно, в том числе и nop.
snuk182
22.07.2019 23:25+1Резюме: так писать не надо, и вот почему:
- с добавлением ноликов в условие цикла разница будет все менее заметной
- в многопоточном приложении вы получите паузы во всех потоках, и это не обязательно то, что вам позволено
- более того, явный вызов GC совершенно не гарантирует запуск GC, это зависит от множества факторов и малопредсказуемо в общем. Например, в моем случае (openjdk-11/i7-8750H/16G) в данном примере постоянный вызов GC жрал те же 100% проца и вдвое больше оперы, чем без явного вызова. Зато замена GC на Thread.sleep(500) успокоила процессор в прежних пределах памяти.
- если придираться: конкретно в этом случае стоит использовать пул. Думаю, это понятно и так, просто сделано в угоду постоянному выделению большого куска памяти, но на практике такое даже джуны себе не позволяют. Кейсы с массивным выделением памяти обычно предсказуемы и предусматриваются архитектурой приложения в особом порядке.
amaksr
23.07.2019 00:18с добавлением ноликов в условие цикла разница будет все менее заметной
вообще-то, если добавить нолик, то у меня программа без GC просто падает достигнув 2GB RAM (java se 1.8 под виндой). А с GC работает.
в многопоточном приложении вы получите паузы во всех потоках, и это не обязательно то, что вам позволено
не факт, ведь я же не получаю паузы в одном потоке, даже наоборот — в данном однопоточном быстодействие с GC в разы выше.
более того, явный вызов GC совершенно не гарантирует запуск GC
здесь полностью согласен, нужно экспериментировать
если придираться: конкретно в этом случае стоит использовать пул
я список сделал такой большой чтобы сразу было понятно чем занята память процесса — надо же чем-то заполнить пару гигов. Но при других значениях счетчика я получил похожий результат, что с GC работает лучше: видимо моя имплементация GC прислушивается к советам, и это позволяет оптимизировать программу.
Вобще всему этому есть объяснение: только программист может знать когда в его программе лучше сделать сборку мусора, так как это зависит от множества факторов, которые из кода и рантайма вычислить или невозможно, или слишком сложно, и поэтому такая задача сборщику может быть в принципе не под силу. Поэтому хотелось бы, чтобы со сборщик перестал быть черным непредсказуемым ящиком.
Source
23.07.2019 00:26+4только программист может знать когда в его программе лучше сделать сборку мусора
…
Поэтому хотелось бы, чтобы со сборщик перестал быть черным непредсказуемым ящиком.В чём проблема? Пишите на Rust.
snuk182
23.07.2019 00:31программа без GC просто падает достигнув 2GB RAM (java se 1.8 под виндой). А с GC работает.
Что вообще-то ненормально — разница всего лишь в явной рекомендации вызова мусорщика. При тесной физической памяти мусорщик должен вызываться и без запроса.
ведь я же не получаю паузы в одном потоке, даже наоборот — в данном однопоточном быстодействие с GC в разы выше.
Я не о том. В случае сервера приложений вам прямо запрещено так вызывать мусорщик — будут остановлены все потоки, которые заняты неизвестно чем и насколько важным для пользователя.
Поэтому хотелось бы, чтобы сборщик перестал быть черным непредсказуемым ящиком.
В языках, предусматривающих высокие нагрузки, это не просто не черный ящик, это хрень с кучей параметров и ручек для тонкого тюнинга под конкретные задачи, требующая отдельных скиллов. Даже у нас здесь получились противоположные результаты, хотя язык один и тот же.
user_man
23.07.2019 12:50>> В случае сервера приложений вам прямо запрещено так вызывать мусорщик — будут остановлены все потоки
А с чего вы это взяли? Или про nop не читали? И да, вот это ваше — «это не просто не черный ящик, это хрень с кучей параметров и ручек для тонкого тюнинга под конкретные задачи» тогда как понимать? Ну и для полноты — вы в курсе как ведёт себя GC при наличии нескольких class loader? С учётом кучи параметров и ручек для тюнинга, разумеется.snuk182
23.07.2019 13:34- Несмотря на то, что GC в JVM постоянно улучшается, энтерпрайзные заказчики крайне неохотно перелезают даже на Java 8, не говоря уже о более поздних версиях. И я не слышал о полном отказе от stop-the-world тактики в худших случаях GC даже с Java 11, такое умеет (умел?) только Azul — то есть всегда есть шансы получить StW, которые возрастают при ручном вызове
gc(). Может если порыть офдоку, где-то найдется явное упоминание StW независимо от количества потоков приложения (я не задавался целью найти), но просто по логике — общая куча + Full GC + старые не ThreadLocal-данные = хороший повод для StW. - Количество класслоадеров влияет на мусорщик только в том плане, что для деинициализации объекта нужен соответствующий его классу лоадер. В старых джавах была проблема чистки пермгена в случае нескольких лоадеров, потому что пермген в силу своей природы херово чистится. Сейчас с общим метаспейсом проблем мусорщика, связанных с класслоадерами, нет или мало (исключая случаи кастомных класслоадеров, но это еще более отдельная тема). Но я говорил о потоках, а не класслоадерах, а если потоки шарят общую кучу, StW вполне реален.
- Я вам не отвечку про настройки GC, потому как последний раз явно касался этого еще при Java 6, с коих пор прошло достаточно времени и изменений JVM, о которых знаю лишь в теории. В большинстве случаев вопрос о тюнинге памяти встает только после проблем с производительностью, и решение этого вопроса очень индивидуально.
user_man
24.07.2019 13:24Вы упираете на остановку всей java-машины, но сами отлично понимаете, что это явление редкое, случающееся только тогда, когда уже ничего не помогает. Соответственно — если ситуация не находится в состоянии «всё безнадёжно», то явное указание на сбор мусора машина может воспринимать очень по разному, включая отсутствие каких-либо действий. Ну а если «всё плохо» всё же наступило, то запустите ли вы gc сами, или это сделает машина — без разницы, ибо мир всё равно остановится. При этом, как вы сами знаете, толстые конторы никогда не спешат с модернизацией парка серверов по первому писку очередного малолетнего гения, а потому там есть весьма стабильная среда на какой-нибудь веб-сфере 7.0, где всё прекрасно можно отладить один раз и далее годами ни о чём не беспокоиться, ну а за эти годы, как известно, либо ишак, либо падишах. Поэтому с практической точки зрения ваше желание быть осторожным ведёт лишь к бессмысленному повышению сложности в и без того сложном толсто-корпоративном мире.
Ваш подход аналогичен (да, немного утрировано, но...) написанию всего на ассемблере — быстро, не зависит от сборщиков мусора и т.д. Но только крайне дорого.snuk182
24.07.2019 13:42Да, здесь вступает уже личный опыт работы в финтехе. После нескольких случаев остановки сервера на переваривание хипа, только потому что кто-то не очень умный загружал сразу все данные без оглядки на их количество, а потом, видимо, наткнувшись на тормоза в стресс тестах, добавил gc() для успокоения совести, уже на наличие этой строки смотрится с двойным подозрением. Можно сказать, повезло, что эта строка там была, иначе ловить нам уже не тормоза, а падающий энв.
user_man
24.07.2019 15:19В целом я бы не рекомендовал безапелляционно запрещать что-либо, хотя согласен с тем, что необходимо указывать на недостатки такого выбора. Но разумно применять не идеальные решения всё же стоит.
snuk182
24.07.2019 21:47Не спорю. Но в случае спорных решений — они должны быть обсуждены и оправданы. И документированы.
- Несмотря на то, что GC в JVM постоянно улучшается, энтерпрайзные заказчики крайне неохотно перелезают даже на Java 8, не говоря уже о более поздних версиях. И я не слышал о полном отказе от stop-the-world тактики в худших случаях GC даже с Java 11, такое умеет (умел?) только Azul — то есть всегда есть шансы получить StW, которые возрастают при ручном вызове
balexa
23.07.2019 14:42Что вообще-то ненормально — разница всего лишь в явной рекомендации вызова мусорщика. При тесной физической памяти мусорщик должен вызываться и без запроса.
Вы все верно говорите. Но в реальности, мало кого интересует, что должен делать GC, как должен оптимизировать компилятор, и т.д, можно ли создавать объекты в цикле.
А интересует, как это все работает. И да, черный ящик то черный, но он имеет вполне конкретное устройство. И зная это устройство можно писать более производительный или менее требовательный к памяти код.
. В случае сервера приложений вам прямо запрещено так вызывать мусорщик — будут остановлены все потоки,
Да с чего вы решили что явный вызов GC == stop world?snuk182
23.07.2019 14:57Я имею в виду, что что шансы StW сильно повышаются при явном вызове. И про черный ящик я не говорю, наоборот опровергаю — высокая нагрузка требует понимания внутренностей и подгонки их под конкретный случай, а это должно быть позволено языком/VM и документировано. Но я бы не спрашивал о тонкостях управлением GC на интервью, разве что позиция напрямую требует.
Source
23.07.2019 00:23+4Явный вызов GC — это скорее симптом того, что у вас что-то не в порядке с самим алгоритмом. Как правило, в таких случаях достаточно несложно переписать так, чтобы, в принципе, минимизировать аллокацию памяти.
amaksr
23.07.2019 00:32-1С алгоритмом все было нормально до тех пор, пока не появилось несколько крупных клиентов, под которыми было на порядки больше дочерних записей, чем обычно. Тут встал выбор: или переписывать кучу модулей, или вставить 1 строчку в конце обработки клиента с вызовом GC.
Source
23.07.2019 01:34+2Это звучит примерно как: нас устраивало O(n?3), и всё было нормально до тех пор, пока n не начало расти.
balexa
23.07.2019 14:48+1А что тут такого? Вполне нормальный подход.
Более того, алгоритм n^2 бывает значительно быстрее чем n log n. Для примера взять реализацию той же сортировки почти во всех библиотеках всех языков.alex_zzzz
23.07.2019 15:23На небольших n И/ИЛИ маленьких константах и n^3 может быть вполне нормально, т.к. всё равно быстро, а напишется за минуту в 4 строчки, скорее всего.
O() само по себе, в отрыве от значений констант и практических значений n, не несёт большого смысла. Вот когда n стремится в бесконечность, когда да, несёт, а так — нет.
PsyHaSTe
25.07.2019 00:57Ну все хорошо, пока поведение гц такое. А учитывая что с любым апдейтом это может сломаться решение довольно хрупкое. Чтобы закостылить падающий прод еще норм, а вот оставить на постоянку такое. С такими приколами никто никогда не сможет обновить ни версию рантайма, ни сменить гц на альтернативный, потому что приложение внезапно начнёт странно падать.
amaksr
25.07.2019 02:27У нас в конторе (вернее сказать, у нашего клиента) видел только один апгрейд VM за 5 лет. Причина проста: на нескольких серверах крутится около сотни приложений и сервисов, и при любом апгрейде нижележащих компонент приходится регрессивно тестировать всё. А суппорта на Java-приложения всего 8 человек…
Поэтому, посмотрев на результаты тестов, посоветовавшись внутри команды, и, естественно, с клиентом, коллегиально был сделан выбор вставить строчку с GC в код, а не переписывать кучу legacy-кода.
Клиент был очень доволен, так как этот вариант позволил решить проблему минимум на пару лет, а там условия и требования скорее всего опять изменятся.Endeavour
25.07.2019 11:07Клиент был очень доволен, так как этот вариант позволил решить проблему минимум на пару лет, а там условия и требования скорее всего опять изменятся.
Можно так сказать. Пофиксить умирающий прод действительно сойдет.
А можно сказать — «накинули еще тыщу техдолга в общий котел», если после фикса на эту строчку все благополучно забили.
Druu
23.07.2019 05:20Явный вызов GC — это скорее симптом того, что у вас что-то не в порядке с самим алгоритмом.
На самом деле нет. Учитывая особенности работы перемещающих сборщиков, сдвинув время вызова gc, можно на десятичные порядки снизить затраты на этот gc. Потому что сам по себе сборщик не знает, когда у вас достижимые объекты дают локальный минимум.
Source
23.07.2019 12:18Я про то, что сначала стоит задаться вопросом: как избежать создания большого кол-ва объектов на ультракороткий срок? А не сразу переходить к вопросу: как побыстрее собрать мусор?
Чисто не там, где убирают, а там, где не мусорят )))Druu
23.07.2019 23:29Я про то, что сначала стоит задаться вопросом: как избежать создания большого кол-ва объектов на ультракороткий срок?
Это как раз не вопрос, т.к. данный кейс нормальными сборщиками отрабатывается наиболее оптимально, в этом случае сложно заставить тормозить, а не наоборот :)
Так что избегать создания объектов на ультракороткий срок, обычно, не надо.
Проблема возникает в объектах со средней продолжительностью жизни — когда у вас етсь некоторая задача и выделяемые объекты нужны до окончания ее работы. И, конечно, зачастую можно справиться перереботкой алгоритма и ворохом микрооптимизаций. Но нередко одна строчка с вызовом гц даст значительно больший эффект.
Очень печально, конечно, что в той же jvm вызов гц по ручной команде не обязателен.
Вообще, жаль, что обычно программисту не дают способа локального тюнинга гц "изнутри" программы. Вроде как "вот на этом участке гц не вызывай" или "сделай мне здесь nursery размером Х" и т.п. вещи.
ofigenn
22.07.2019 23:07Как раз на днях конвертил ~100Gb видео потока. Немного ошибся с реализацией стрима и бац) Но я смог)
snuk182
22.07.2019 23:33Круто :) А как с производительностью? Неожиданное применение языка с автоматическим управлением памятью, если честно.
ofigenn
22.07.2019 23:51+1Я вам страшную вещь сейчас скажу: я на JavaScript написал обертку, а само сжатие я делал через ffmpeg)
Главное получилось и быстро) Просто разовая задача)
playermet
22.07.2019 20:14+7Знание как работает GC нужны, чтобы понимать когда объект будет удален
При этом сама концепция GC создавалась, чтобы программисту не приходилось заморачиваться тем, когда объект будет удален.AllexIn
22.07.2019 21:00Создавалась, да. Но при этом существование GC всё равно надо учитывая в процессе разработки, так или иначе.
Весь гугл в своё время был завален обсуждением Android bitmap recycle.
И это только одна тема, где играю особенности GC. А так — GC везде очень активно обвешан костылями и особенностями.snuk182
22.07.2019 21:19Android bitmap recycle
Только потому что очистка битмапов требовала явного вызова в версиях ведра до 3.0, из-за странной архитектуры контрола и бажной имплементации.
AllexIn
22.07.2019 21:31А какое значение имеет причина?
Факт есть факт — просто принять «у меня GC» и больше не думать о том, что так под капотом — не получается почти никогда.snuk182
22.07.2019 21:36Так это баг АПИ, документированный и впоследствии исправленный. Конечно же, документация открывалась после первого ООМа. А сейчас уже вполне можно следовать заповеди "у меня GC", с текущими-то гигабайтами оперативки в смартфонах. Чем разработчики невозбранно и пользуются — приложения жрут все больше и больше.
AllexIn
22.07.2019 21:39Разработка не ограничивается смартфонами.
Ну и в целом это лишь пример. Таких примеров — вагонами.snuk182
22.07.2019 22:31Насчет вагонами — очень спорно. В случае широко известных приколов, где GC не работает, как выше, вопросы задаются конкретно под них. Еще меня бывало спрашивали про ключи JVM, имеющие отношение к управлению памятью, но это было собеседование внутри компании на сеньорность после релиза проекта, где нужно было нестандартно тюнить кучу и GC.
depadep
23.07.2019 13:45+1Около десяти лет назад так рассказал о .Net GC на собеседовании, что после офера меня отдельно спросили откуда я всё это знаю.
С тех пор эти знания на практике не пригодились ни разу, даже на проекте с очень активной работой со всей доступной оперативной памятью.
Похожая ситуация с сортировками и бинарными деревьями (но пару раз пригождались, как и знание О большого разных алгоритмов).
А вот знание принципов проектирования, рефакторинга, тестирования — требовалось на каждом проекте. Теорвер, мат. логика и работа с координатами реже, но тоже бывало.
gudvinr
22.07.2019 22:45+2Одно дело — понимать, как работает GC и не заморачиваться потому, что многие подводные камни он помогает решить и об этом не надо думать в процессе написания кода.
Другое — когда вообще нет знаний о том, как хотя бы примерно работает сборка мусора в используемом языке.
Это действительно средство от человеческого фактора — невнимательности, а не от нежелания разбираться с инструментом, которым пользуешься. GC всё-таки инструмент, которым может либо помочь что-то хорошее созидать, так и наговнокодить рано или поздно, если не знать про особенности.
PsyHaSTe
25.07.2019 00:40Единственный раз когда мне понадобилось понимать устройство гц — когда у меня приложение падало с ООМ и я лазил по дампу, пытаясь понять, какая строчка кода вызывает эту хрень. В остальных случаях можно спокойно считать волшебными гномиками, которые объекты удаляют. Ну и разве что для общего развития можно покопаться, что внутри.
dominigato
22.07.2019 20:54-2Если вы заморачиваетесь насчет GC и когда он там память убирает, то это именно вы пишете плохой софт.
ingvarwolf
23.07.2019 01:53+1Я не писал, что не знаю, как работает сборщик мусора. Я написал, что одна фирма отсеивает множество кандидатов на первом интервью такими вопросами и при этом ни один из собеседовавших меня людей не смог мне внятно привести пример как им это помогло в работе. Я знаю какие у них проекты, и они не маленькие. Качество — уж простите, не проверял.
Я не писал, что не прошёл такое первое интервью. Я просто получал оффер из другой компании раньше, чем эта компания звала меня на следующее интервью, у них очень длительный процесс найма.
Мне приходилось проводить технические интервью, то есть я был по обе стороны в процессе найма на работу. Я готовил вопросы на темы, которые плотно используются в проекте, на который мы искали кандидата. Время интервью ограничено и сроки поиска нового программиста в команду тоже не резиновые. Поэтому лучше уж спрашивать знания того, что конкретно используется в проекте, чем знания о внутреннем устройстве Java, которые при достаточно прямых руках могут и не понадобиться.
Я знаю лично много программистов, которые затрудняются объяснить устройство сборщика мусора, но при этом пишут нормальный код с минимальным количеством проблем. И знаю также программистов, которые идеально расскажут как устроен сборщик мусора и как работает память в Java-приложении, но при этом пишут вот такой код:
class SomeClass { private String someValuableData = "Most Valuable Information"; /* Getters and Setters are ommitted. */ public void updateData(String newData) { this.setSomeValuableData(this.getSomeValuableData()); } }
Пример утрированный конечно, но суть проблемы демонстрирует. Реальный пример из реального проекта.PsyHaSTe
25.07.2019 00:43"Такой код" демонстрирует опечатки, написание бесполезных дублирующих сеттеров или что-нибудь еще? Затрудняюсь понять, что является частью примера, а что упрощением для читателей.
Neikist
22.07.2019 19:16Я бы скорее предположил что вопросы по работе GC это из разряда вопросов на эрудицию, интерес к теме, широту этих самых интересов.
truebest
22.07.2019 17:40+2Скоро мне стукнет 45 и свой стартап (где был CTO) я покинул в декабре. С тех пор я завалил не меньше 10 тестов и интервью на программиста. Пишу код при этом я уже почти 20 лет, включая создание прошивок (по образованию я инженер-электронщик) и полномасштабные распределенные веб-приложения с интеграцией IoT. Я с нуля создавал ПО для крупных специализированных производственных объектов по всему миру. Тем не менее, я просто не могу устроиться программистом, потому что постоянно проваливаю эти тестовые задачки.
Тем-же занимаюсь по сути, и кодингом и железом, iot и все что с ним связано, также есть крупные реализованные проекты, есть свой стартап, но переодически уделяю время прохождению интервью, хоть и работать там как правило не собираюсь. Очень нравятся собесы по Skype и тп. Для меня обычно выглядит так, 2-3 интервью проваливаю, потом есть предложение и я отказываюсь. Вопросы на 1-3 интервью практически однотипные, и по факту на повторение. Некоторые вещи, которые никогда не применяю, да и в здравом уме они не нужны, просто записываю, и потом на следующем интервью отвечаю.
С этого года ноу-хау добавилось, спрашивают часто про контроль версий, про управление задачами, проектами, и другие инструменты, ну и вообще как ты придумываешь, как и куда записываешь, с кем обсуждаешь и как реализуешь.
Все это превратилось уже даже не в решение тестовых задачек, за решение которых тебя все равно не возьмут, тк ты не знаешь jira или еще какой инструмент, а в банальные как нужно отвечать и как не нужно отвечать. Психопатия. Это и называется навыком прохождения интервью.
pvsur
22.07.2019 17:45+5Анекдот в тему:
Работают два HR, опытный и молодой. Приходит стопка резюме на должность топ-менеджера. Опытный сразу берет и половину стопки отправляет в корзину. На удивленный взгляд молодого коллеги коротко отвечает: — А зачем нам топ-менеджер — неудачник ?!
smarthomeblog
22.07.2019 17:46Столкнулся с подобным сам, когда искал работу. Такое ощущение, что идет поиск не сеньера, а участника игр «Что. Где. Когда». Разнообразие задачек ограничивается только фантазией нанимателя. Тут тебе и веселые шарады, и вопросы про паттерны (куда же без них родимых), и алгоритмы. А потом откроешь проект, а там — контроллеры с методами по 4-е экрана! Тестов нет и деплой по FTP. И вот назревает вопрос — для чего все это? Чтобы потешить свое самолюбие? Плюс ко всему, большая часть задач может быть решена больше, чем одним способом, как говаривал незабвенный Ларри Уолл.И не факт, что человек, проверяющий задание, имеет наиболее оптимальный вариант решения. Несмотря на то, что сам ее сочинил :)
snuk182
22.07.2019 17:51+3Вероятно, айти придет к способу найма специалистов по принципу врачей — рекомендацией проверенных знакомых. Никаких олимпиад на скорость, максимум разговор по душам.
smarthomeblog
22.07.2019 17:55В общем именно по рекомендациям в основном получалось устраиваться — без олимпиадных задачек как-то все получалось. И работодатели не жаловались :) И сам собственно нанимал нескольких людей просто по результатам беседы по теме. И нескольких с тестовым заданием, но без извращений. Просто чтобы оценить уровень. Тут из 4-х человек, три оказались на высоте, один — так себе. Но поняли это только по истечении пары-тройки месяцев.
snuk182
22.07.2019 18:03В моем случае могу даже больше сказать — если на горизонте маячит любая задача на время, результат собеседования предсказуем. За последние три года таких было около десятка, что субъективно подтверждает сказанное в статье.
В противовес: один раз получил оффер после парного программирования с будущим архитектором, один раз выполнил довольно разумное тестовое задание по совершенно незнакомым мне ранее технолониям. Пару раз мне вообще задавали только вопрос вида "ну ты ж шаришь, да?" (да, оба раза по рекомендации).
urtow
22.07.2019 18:33Последние два раза устраивался работать по рекомендации.
Интервью больше напоминало обсуждение тенденций в современном IT и обсуждение применимости стандартных решений/библиотек.
deitry
23.07.2019 14:31На текущую работу устраивался без рекомендаций, без корпоративного опыта (программировал только для себя и в аспирантуре в рамках коллектива из полутора человек). Уже прошёл собеседование в другое место, но тут вдруг позвонили, сказали, что заинтересовал, и дали тестовое задание, на которое я успешно забил. Через пару дней предложили хотя бы просто поболтать, и после того самого разговора по душам (ну и небольшого теста по языку на проверку адекватности) дали оффер. Всегда бы так.
mapron
23.07.2019 02:31А что не так-то? В компании не было знающего человека, они его нанимают, чтобы пришел и все сделал по-человечески (тесты и код по паттернам) :) если в требованиях вакансии это отражено — в чем проблема?
smarthomeblog
23.07.2019 09:30Вероятно я не правильно выразился — я имел ввиду, что даже с приходом знающего человека, все остается так, как было. Ибо менять что-то уже работающее — дорого и с бизнесовой точки зрения не сильно выгодно. Но тем не менее в вакансиях указываются все последние тренды разработки :)
mapron
24.07.2019 06:49Если расклад такой да, смахивает на лицемерие. Но это можно попытаться узнать на этапе собеседования вопросами «а чем вы планируете меня занять на новой должности?»
если будет какое-то монотонное «поддержка ХХХ… сопровождение YYY...», то должно напрячь) можно спросить «а зачем указан в вакансии С++42, где он у вас там применяться планирует?» Я когда на работу устраивался, спрашивал как применяются указанные в вакансии технологии, мне вполне без утайки все сказали.
Опять же странно если начнут отмазываться корпоративными секретами, ибо всегда можно найти способ как не сказать слишком много)
bodqhrohro
23.07.2019 15:24откроешь проект, а там — контроллеры с методами по 4-е экрана
для чего все это
Возможно, как раз для того, чтобы преемники не писали такой говнокод, а то и старый в порядок привели?
Ketovdk
22.07.2019 17:48Дело не только в отсеве кандидатов. Просто часто бывает такое, что в коде есть явные алгоритмические ошибки, которые сразу же бросаются в глаза задачколюбам, но незаметны даже для людей с 15-тилетним стажем, которые являются отличными программистами, разбираются в архитектуре, патернах, чем угодно. И в итоге в месте, где должно работать за O(n) или O(log(n)) вылезает квадрат, который можно обнаружить уже только на проде или ближе к нему. Ну как обнаружить, просто все начнет валиться по тайм-ауту
Naglec
22.07.2019 18:44Нагрузочные тесты на что?
Ketovdk
22.07.2019 19:51ну обычно подобные недочеты лежат где-то глубоко в системе, например на ДЛ уровне, и когда от нагрузочных тестов (если даже допустить, что нагрузка была правильно оценена) время отдачи начинает просядать, то в лучшем случае приходится профилировать и находить эту ошибку (если посмотрит человек, который алгоритмы знает), либо же добавлять какое-нибудь кэширование и ждать, пока она всплывет снова.
Я не хочу сказать, что это главное, что есть в разработчике, но и забивать, делая вид, что это никогда не пригодится не стоит. Может пригодиться. Причем обязательно там, где не ждешь (и даже не в самой большой системе)Naglec
22.07.2019 20:01+2Я утверждаю, что хардкорный скилл автоматического поиска наиболее оптимального решения, в общем случае, не нужен, потому что реальные проблемы с производительностью вскрываются код-ревью + нагрузочными тестами и до прода доходить не должны.
Это не отменяет необходимости понимания, что полный перебор — плохо, а кэширование — хорошо.
В реальном мире, когда у нас есть performance-critical часть приложения, то у нас есть и время все обдумать, почитать, посоветоваться с коллегами, и нет никакой необходимости решать такую задачку на доске за 15 минут.
slonopotamus
22.07.2019 20:34+1реальные проблемы с производительностью вскрываются код-ревью
Звучит как "это ок что я не умею искать оптимальное решение, пусть за меня мой коллега-ревьювер его ищет".
Naglec
22.07.2019 20:38Это звучит как «если я что-то недоглядел/не знал более удачное решение, то увидит кто-то другой или авто-тесты». В этом треде мы обсуждаем риск попадания неоптимального решения в прод, если что.
Ketovdk
22.07.2019 19:54+1и я не говорю о каких-то хардкорных оптимизациях с построением Ахо-корасика или дирамид, но если где-то можно легко и непринужденно поднять с O(n*n) до O(n) просто использовав хэш-таблицу, вместо кучи избыточных linq, делать это автоматически (а не когда начнет подгорать) вполне полезно
dbelka
22.07.2019 17:5814 лет общего стажа в веб-разработке в достаточно крупных фирмах (где хайлоад и всё такое).
Помимо основного неплохо знаю C++, писал расширения для PHP, решал задачи по ML и много чего ещё.
Не собеседовался только уже как лет 7. Два собеса я уже не прошёл :-)
Hydro
22.07.2019 18:10+1Ох, да это же мой кейс.
Много чего делал за 8 лет разработки и буквально недавно не прошел лайвкодинг на проверке открывающих закрывающих скобочек в потоке.playermet
22.07.2019 20:25+2Так это же совсем просто. Делаем счетчик, ставим ему 0. Если встречаем открывающую — прибавляем 1, закрывающую — отнимаем 1. Если счетчик в любой момент становится меньше 0, или больше 0 по завершению потока — значит ошибка. Или я не так понял задачу?
Hydro
22.07.2019 22:25-2Все-так)) На с Ваши решением следующие строки тоже будут валидны:
}{, ][, )(
Ожидается такой поток: {[<()>]}, и проверять нужно было именно правильность открытия-закрытия))
В любом случае, я получил оценку «procedure inefficient» за реализацию и был послан hr далеко и надолго)siziyman
22.07.2019 22:32+2Во-первых, нет, если внимательно вчитаться.
Во-вторых, для разных вариантов скобок за 5 минут делается примитивный стэк.Hydro
22.07.2019 23:39Да, Вы правы, читать было лень. Видимо поэтому и пролетел))
siziyman
23.07.2019 00:12То-то ж и оно. Вы извините конечно за прямоту, но если вы базовую задачу (а это базовая задача) на алгоритмику не решили — ну, это не собеседующие плохие, это вы головой очерствели там, где, может быть, вам и не надо было на работе, но где стоило ожидать, что спросят.
Hydro
23.07.2019 06:30В том то и дело, что я ее решил) Пусть и не самым оптимальным образом.
Да и я ведь, вроде, не утверждал, что собеседующие плохие?..
Я поддерживаю идею топика, что нерешение базовых задач на алгоритмику не обнуляет скилы программиста)) И уж точно нельзя отсеивать по такому признаку.
Razoomnick
22.07.2019 22:52+1Заводим стек, начинаем обрабатывать поток. Открывающие скобки добавляем в стек. Удаляем элемент из стека, если в потоке встретилась закрывающая скобка. Если при удалении тип скобок не совпал — ошибка. Попытка удалить элемент из пустого стека — ошибка.
Hydro
22.07.2019 23:22Все так и было сделано)
ainoneko
23.07.2019 09:02Все так и было сделано)
Эээ… А что тогда у них считается эффективным?
VolCh
23.07.2019 10:53Ну, например, найти решение, когда поток (вернее уровень вложенности скобок) на порядок больше объёма доступной памяти.
JustDont
23.07.2019 11:01Принципиальное решение будет другим только тогда, когда вид скобочек строго один. В противном случае учёт порядка следования скобок (то есть стек в том или ином виде) — обязателен, вопрос с памятью варьируется только в том, сколько бит вам нужно для записи одной скобки. Алгоритмически это всё равно остаётся работой со стеком.
ainoneko
23.07.2019 12:43К каждой скобке в стеке добавить счётчик?
(А потом ещё проверять, помещается ли количество скобок в этот счётчик??
(Так и до числа Грэма дойти можно.))JustDont
23.07.2019 13:10+1Счётчик не поможет, важен порядок. Иначе будут проходить потоки типа "{([}])" — что, конечно, по условиям задачи могло бы быть допустимо, но «в жизни» такое обычно никому не нужно.
ainoneko
23.07.2019 20:07К каждой скобке в стеке добавить счётчик?
Счётчик не поможет, важен порядок.
Почему не поможет-то? К каждой скобке:
"{((([[(..." — здесь в стеке:
("{", 1), ("(", 3), ("[", 2), ("(", 1).
При появлении такой же (или парной) скобки, как в вершине стека, — увеличивать счётчик в вершине стека (соответственно, уменьшать (и выбрасывать при достижении нуля)).
Иначе будут проходить потоки типа "{([}])"
Как это получится?JustDont
23.07.2019 20:21А, вы в этом смысле. Ну а где тут особая экономия-то? Вот скажем, если у нас 2 вида скобок, то нам хватит 1 бита на каждую, а если вы рядом с каждым битом будете дописывать да даже 8 бит на количество, то расход памяти едва ли убавится — зависит от кейсов, конечно. Если ожидаются сотни одних открывающих скобочек — то наверное какая-то экономия будет. Если нет — то едва ли.
ainoneko
23.07.2019 20:44Если ожидаются сотни одних открывающих скобочек — то наверное какая-то экономия будет. Если нет — то едва ли.
Если нет, то при формулировке
«например, найти решение, когда поток (вернее уровень вложенности скобок) на порядок больше объёма доступной памяти.»
задача становится немного слишком сложной.
(Можно, конечно, пытаться, например, использовать код Хаффмана или ещё что-нибудь для сжатия стека, но это уже извращения начинаются (мой вариант был "RLE-encoding", как в некоторых старых форматах картинок).
Или ваш вариант — упаковка в битовые поля (для трёх-четырёх видов скобок уже нужно по 2 бита — не очевидно, хватит ли памяти, если " уровень вложенности скобок на порядок больше объёма доступной памяти" (что бы это ни значило) ))
PsyHaSTe
25.07.2019 00:55С трудом себе такое представляю. Разве что гигабайтные потоки скобочек разбирать на 512 байтах памяти.
Spaceoddity
23.07.2019 01:57+1{][}
Такой пример ваш валидатор пропустит?
<div<span>>
А такой?siziyman
23.07.2019 09:56+1Первый пример — нет, второй пример — правильная скобочная последовательность, заданием было не написать парсер HTML.
Spaceoddity
23.07.2019 11:55А, ну т.е. задачи фильтровать такие варианты как {[}] не стоит? Главное просто посчитать кол-во открывающих и закрывающих? Нормальное задание для сеньора.
siziyman
23.07.2019 13:39Про это я писал выше в другом комментарии в 00:12, почитайте тред до того, как комментировать, уважайте собеседников, пожалуйста.
Указанная автором комментария формулировка задания оставляет простор для интерпретации. На сложность задания это влияет весьма условно.
Kodiak
24.07.2019 20:46+1Ещё скажите, что такое должен не пропускать.
std::vector< std::vector< int > >
Разве что по поводу отсутствия пробела между ">" варнинг выдавать.
usharik
22.07.2019 18:13+1Мне всегда казалось, что подобные работодатели предполагают, что умеющий решить три алгоритмических задачи за час будет в состоянии разобраться с любым скриптом докера, да и вообще с чем угодно.
Hydro
22.07.2019 22:27Да, только это не гарантирует адекватную работу в команде, правильную декомпозицию задач, понимание требований заказчика и прочие синьорские софт-скилы. А также общую управляемость, адекватность и профессиональное чутье.
0xd34df00d
23.07.2019 02:35А эти работодатели удивляются потом, когда для скриптов докера наворачиваются ахо-корасики и прочие препроморфизмы?
lyadnov
22.07.2019 18:14Я смирился с тем, что все эти собеседования — рулетка.
5 раз тупые шарады и конкурсы, на которых тебя отсеют, потому что «вспотел через чур».
А 1 раз, с тобой поговорят по душам и не проверяя реальных знаний возьмут на тестовый срок.
Вот на тестовом сроке ты и показываешь на что способен.
Yago
22.07.2019 18:16Чем крупнее компания, тем больше вероятность нарваться на задачки и вопросы, ответы на которые никак не расскажут о тебе как о специалисте.
С одной стороны понятно: поток резюме от разных проходимцев и людей, которые хотят войтивайти у таких компаний огромен. И для упрощения процедуры фильтрации этого потока делается эта стандартизация с однотипными вопросами и задачками, которые бессмысленны по своей сути. С другой стороны, у людей с достаточным опытом в сфере это чаще вызывает негатив, потому что они знают процессы и то, что задачки им не пригодятся в дальнейшем, а нужны лишь для прохождения собеседования.
У компаний поменьше размером такое встречается реже, но бывает. Там больше вопросов из теории и практики современных подходов к разработке. Они в целом гибче относятся к найму. И там очень много горячих предложений для сеньоров с менее изматывающим процессом найма.
Тут нужно понимать, на какую компанию нацелен кандидат. Крупные корпорации с их подходами к собеседованию могут не меняться годами. А более гибкие и шустрые не так стабильны. И если вы выбрали крупную рыбу, то будьте добры играть по ее правилам.PsyHaSTe
25.07.2019 00:59Я никогда не собеседовал, только собеседовался, но неужели так трудно отличить человека с опытом от проходимца? Спросите про последний проект, что было сделано так, что не так, что бы поменять хотели, и как именно.
Дайте задачку на проектирование простенького модуля (если речь про сениора). Ну там "как бы вы сделали логирование с разных модулей", "а вот теперь нам хотелось бы трекать время выполнения запросов", "а вот у нас куча IO-bound задач на сервер валится, а он не справляется, что это может означать?"...
Yago
25.07.2019 11:21Тут вопрос в том, насколько гибкими собеседования будут для компании. Например, мы задаем задачки про алгоритмы и структуры данных. Это самый низкий уровень, который не имеет отношение к специфике разработки, сфере деятельности компании, предыдущему опыту работы. Соответственно, проводить подобные собеседования может большее количество людей. Это более масштабируемая схема найма, хотя и не коррелирует с реальными навыками людей программировать серьезные проекты.
Я предполагаю, что большим корпорациям часто не столь важен специфичный опыт. Им удобна стандартизация. Вопрос про проектирование модуля очень сильно может быть привязан к специфике языка, его инструментов (у корпораций свое море внутренних библиотек), и в целом отношения к проектированию и кодированию в компании (например, в одной допустимы небольшие нарушения инкапсуляции для общения между модулями, а в другой за этим строго следят и не допускают их). Потому и задают вопросы, которые имеют отношение к программированию в целом, но не имеют отношения к реальным проектам.
И да, многие сеньоры могут не подходить большой компании именно по причине своего специфичного опыта и некоторой закостенелости в плане сформировавшегося вкуса к написанию кода, потому что им будет сложнее переучиться на иные подходы к разработке, которые сформировались в этой компании.PsyHaSTe
25.07.2019 15:37Для меня персонально "закостенелый" и "разработчик" это очень плохо дружащие факторы.
dss_kalika
25.07.2019 15:42Если работать в одном стеке 15-20 лет (причём — если стек при этом и сам не меняется), то не вижу ничего что можно было бы особо нового в нём найти и не быть «закостенелым».
PsyHaSTe
25.07.2019 15:5820 лет писать на одном стеке, звучит как-то грустно.
У меня за 9 лет произошел переход сначала от процедурного к ООП, сейчас вот от ООП к ФП, дальше наверное можно будет к формальным доказательствам двигаться, когда языки соответствующие подрастут.
А с другой стороны человек, Который десятилетиями пишет одно и то же на одном языке, знает все подводные камни, но все равно периодически забывает/ошибается просто потому, что он не робот. Поискать что-то что кардинально решает проблему ему не хочется, максимум находит какие-нибудь средства в рамках существующего стека, чтобы чуть-чуть облегчить себе жизнь.
dss_kalika
25.07.2019 16:04Ну, если за это платят и это неплохо получается — почему бы и нет? Кто то же, в конце концов, должен. (поддерживать и развивать системы созданные в прошлом тысячелетии).
Вы молодец, вы меняли стеки. Но не у всех есть такое желание. =)
Поискать что то, кардинальное? Переписать проект с дикого размера кодовой базой и без документации?
… и, да — ничто не защитит от ошибок из разряда «он не робот».PsyHaSTe
25.07.2019 17:54Ну, если за это платят и это неплохо получается — почему бы и нет? Кто то же, в конце концов, должен. (поддерживать и развивать системы созданные в прошлом тысячелетии).
Ну да, люди получают деньги за боль, а потом пишут разгромные статьи про выгорание.
Вы молодец, вы меняли стеки. Но не у всех есть такое желание. =)
Кмк это желание любого разумного автоматизатора: работать меньше, получать результата больше.
Поискать что то, кардинальное? Переписать проект с дикого размера кодовой базой и без документации?
- не все проекты такие
- есть хорошие книги по тому, как приводить легаси в адекватное состояние.
У меня были проекты, где старожилы говорили "Да зачем тебе надо его трогать? Ну да, говно, но у нас же вон в кроне таска настроена чтобы перезапускать, а твой фикс конечно работает, но тестировать его мы не хотим, да и дифф за 200 файлов читать лень".
dss_kalika
25.07.2019 18:47Ну да, люди получают деньги за боль, а потом пишут разгромные статьи про выгорание.
Почему за боль? Работать в привычной среде и привычными инструментами? о_О
Выгорание — это о неправильно поставленном рабочем и жизненном процессе, а не о том, что он не меняет стек и работает там и так как ему нравится.
Кмк это желание любого разумного автоматизатора: работать меньше, получать результата больше.
Что если за эту работу платят достаточно неплохо и нет альтернатив работать меньше, а получать больше? Редкие и узкие специалисты по старым стекам частенько получают совсем неплохие деньги.
не все проекты такие
есть хорошие книги по тому, как приводить легаси в адекватное состояние.
У меня были проекты, где старожилы говорили «Да зачем тебе надо его трогать? Ну да, говно, но у нас же вон в кроне таска настроена чтобы перезапускать, а твой фикс конечно работает, но тестировать его мы не хотим, да и дифф за 200 файлов читать лень».
Крупные проекты на старых стеках обычно именно такие.
Особенно которые живут в состоянии перманентной доработки и развития, а не рефакторинга и избавления от техдолга. (ну правда, попробуйте обосновать необходимость удвоения штата для переписывания всей системы и одновременного поддержания и развития существующей)
А про книги… читал я несколько. Но ничего что могло бы помочь переписать за разумный срок проект на, к примеру, Delphi/SQL, который жил и развивался 15 (или уже 20?) лет, включая динамический sql, динамическое создание dfm-ок, отсутствие тестов и документации я что то там не заметил. Особенно — без увеличения свободных ресурсов программистов.
pprometey
25.07.2019 18:50Это ужасно, и страдает в целом бизнес в перспективе. Я вот устраивался в одну такую контору пол года назад. Там до сих пор стек с 2003-го года где-то.
И они довольно успшно таки пилят с предсказуемыми сроками и качеством решения. Вот только их качество уже во многом проигрывает тем молодым компаниям, кто пилят решения на каком-нибудь новом стеке.
Это какой-то ремесленеческий подход, который уже давно умер, еще в эпоху ренесанса.dss_kalika
25.07.2019 18:58Качество — по каким критериям?
pprometey
25.07.2019 19:02Ну даже с точки зрения пользователя. Сравни хотя бы ASP .NET WebForms и SPA на Angular c бакендом на ASP .NET Core 2. (ну либо JEE). А еще стоимость лицензий и поддержку устаревший решений?
dss_kalika
25.07.2019 19:03И в чём будет разница с точки зрения пользователя?
pprometey
25.07.2019 19:15А ты попробуй. И таких вопросов не будет.
В чем разница между жигули копейкой и теслой? И та и та везет ведь.MacIn
25.07.2019 19:26Ну, в наших условиях стоимость содержания копейки (учитывая возможные ремонты) может оказаться более приемлемой…
Igor_O
25.07.2019 22:05Если ты по каким-то причинам не можешь жить в солнечной Калифорнии, ну или во Флориде или, на худой конец, в Техасе, то чтобы пользоваться Теслой нужно потратить еще две-три цены Теслы на организацию ее зарядки. И еще иметь жигули копейку, чтобы ездить за 10 км до паркинга, в котором согласились подключить Теслу к розетке… Ну и да, еще жигули копейка пригодятся в морозы, когда пробег Теслы внезапно сокращается в 3-5 раз… Ну или в сильную жару, когда каждая поездка съедает год ресурса аккумулятора.
Это я все к чему? «Жуткое легаси» очень часто — это очень хорошо для бизнеса. Работал я как-то в одной конторе. Там ядро всего бизнеса крутилось на 15-летнем мэйнфрейме. Это был жуткий антиквариат. Но. Сколько думаете было суммарное время простоя этого ядра за 15 лет эксплуатации? Единицы минут! И то, уже ближе к 15-му году эксплуатации, когда электролиты на некоторых платах совсем уже пересохли.
И да, вокруг были обернуты всякие новомодные тогда веб-морды, импорты-экспорты из экселя, и прочие выдачи отчетов. И вот тут-то и возникали время от времени письма от админов: «Веб-морда поломалась, мы ее скоро починим, если что-то срочное — го в терминал с командной строкой, там все работает.» И были старожилы, которые застали еще время до веб-морд, которые делали все то же, что и через веб-морду, но в два-три раза быстрее…
Да даже элементарно. Вспоминая обучение «юзеров» во времена ДОСа и до них и обучение «юзеров» после появления виндоузов. С ДОСом и раньше — «вот тебе команда чтобы сделать это, вот тебе команда чтобы сделать то. Если что-то пошло не так и на экране не показывают :> с моргающей „|“ после — нажми „Esc“, если не помогает — то „Ctrl-c“. И человек мог через час продуктивно работать! Потом появился виндоус… И просто на то, чтобы человек мышкой попадал в кнопки и умел опознавать ситуацию, когда у него поверх всего диалоговое модальное окно, в котором что-то надо сделать — уходило по неделе и больше…
Вспоминается история из промежутка между чистым ДОСом и Виндоус. Когда уже появился NC… Вызывают моего друга бороться с вирусом. Приезжает. Просит продемонстрировать проблему. Дама достает тетрадочку. Открывает на правильной странице, щелкает тумблером на корпусе. Ждет синих окошек. Дальше по тетрадке: „7 раз вниз, энтер, три раза вниз, энтер, 15 раз вниз, энтер“. Дама тщательно отсчитывает нажатия и тщательно жмет энтеры. На экране все те же окошки, ничего не запустилось. Друг начинает разбираться. Оказывается на днях кто-то поставил новую программу на компьютеры бухгалтеров. И теперь, чтобы все работало, нужно начинать с „8 раз вниз“… Дали бы ей „набрать на клавиатуре cd С:\buh\base\ нажать энтер, набрать buh.exe нажать энтер“ — »вирус" бы никто не заметил…
PS: яркая демонстрация проблемы сейчас произошла у меня в предпросмотре коммента. Все кавычки съехали. Там где должны были быть "«" вдруг стали "»" а вместо "»" появились “. Но пока писал PS страница почему-то перерисовалась и большая часть багов пропала… Но остался »вирус" в конце…MacIn
25.07.2019 23:20Весьма странная точка зрения.
С тем же успехом после каких-то изменений могло не видоизмениться меню, а, скажем, программа была бы перемещена из \buh\ в другое место, или перестала бы работать еще из-за чего-то. И получившуюся ошибку пользователь точно так же не смог бы разрешить.
Ну, а то, что он вместо семантики (выбор чего-то из меню) записал последовательность нажатия клавиш — это либо о его умственных способностях, либо о способностях обучающего, говорит нам нехорошее.
В наше время (да и по правде, почти с самого начала так было, просто мало кто этим пользовался) вы можете выкинуть стандартную оболочку и сделать нужную вам программу единственно доступной.
pprometey
26.07.2019 05:15Что-то я не видел, чтобы таксопарки активно пересаживались на копейку. На худой конец выбирают у нас лично — шкоду.
dss_kalika
26.07.2019 11:38— Легаси плохое, модное — хорошее!
— Почему?
— А ты попробуй!
=))
Может всё-таки сформулируете чем лучше то для пользователей, раз уж взялись это утверждать?pprometey
26.07.2019 13:19Ну скажу так, «модные» технологии не на пустом месте ведь берутся. А как ответ на технологические вызовы и проблемы существующих решений. Прочитайте про технический долг. Не вижу смысла что-то доказывать.
dss_kalika
26.07.2019 13:37-1Т.е. вы даже сами не можете сказать чем лучше?
Круто-круто.Kanut
26.07.2019 13:44Вы хотите увидеть ответ, которые описявет преимущества любых абстрактных «модных» технологий, над любыми абстрактными «легаси»-технологиями? Тогда я могу вам предложить одно преимущество для, которое применимо в большинстве случаев: цена разработки и самое главное сопровождения продукта. Всё остальное надо смотреть на конкретных примерах.
dss_kalika
26.07.2019 13:50-1Цена полной переписки продукта развивающегося уже 15 лет — колоссальна и не сопоставима с ценой поддержания.
Более того — не факт, что поддержка нового продукта будет дешевле, кстати, учитывая размер проекта.
Нет, я хочу увидеть ответ на
И они довольно успшно таки пилят с предсказуемыми сроками и качеством решения. Вот только их качество уже во многом проигрывает тем молодым компаниям, кто пилят решения на каком-нибудь новом стеке.
Качество — по каким критериям?
Человек же явно уверен, что раз они пилят на модных фреймворках, то качество выше. Иначе я не вижу логики в этом высказывании )
Вот мне и стало интересно — чем таким эти фреймворки ДЛЯ ПОЛЬЗОВАТЕЛЯ (как утверждает тот кому я это вопрос задал) лучше.
Вопрос то простой (раз всё так очевдно), но почему то ответа на него нет.
К примеру — классические легаси проекты на делфи/sql. Учёт там какой-нибудь, отчётики, гридочки и прочая классика. Чем так пользователям будет лучше на новых / более модных фреймворках? )Kanut
26.07.2019 13:55Цена полной переписки продукта развивающегося уже 15 лет — колоссальна и не сопоставима с ценой поддержания.
Практически всегда наступает момент когда переписать оказывается дешевле чем поддерживать.
Человек же явно уверен, что раз они пилят на модных фреймворках, то качество выше.
И я пожалуй готов с этим согласиться в том плане что «модные» фреймворки дают более высокое «базовое» качество. Естественно криворукие программисты могут загубить любой фреймворк, но в среднем продукты сделанные на новых технологиях и с новыми подходами пожалуй будут качественне чем «легаси»-аналоги.dss_kalika
26.07.2019 14:00Практически всегда наступает момент когда переписать оказывается дешевле чем поддерживать.
Если проект активно развивается — стоимость его переписывания точно так же растёт со временем, как и стоимость поддержки. =) А если не развивается — зачем переписывать?
И я пожалуй готов с этим согласиться в том плане что «модные» фреймворки дают более высокое «базовое» качество. Естественно криворукие программисты могут загубить любой фреймворк, но в среднем продукты сделанные на новых технологиях и с новыми подходами пожалуй будут качественне чем «легаси»-аналоги.
И снова — что значит «качественнее»? И как это зависит от фреймворка, а не от архитектуры и подхода к разработке? )Kanut
26.07.2019 14:05Если проект активно развивается — стоимость его переписывания точно так же растёт со временем, как и стоимость поддержки.
Не согласен. Растёт и то и другое, но стоимость поддержки по моему опыту всегда растёт быстрее.
И снова — что значит «качественнее»?
В данном контексте «качественнее» для меня означает менее подвержено багам и критическим ошибкам.
И как это зависит от фреймворка, а не от архитектуры и подхода к разработке? )
Это зависит и от того и от другого. Естественно архитектура и подход имеют большее значение, но и «инструменты» играют свою роль. Если бы это было не так, то до сих пор все бы писали исключительно на ассемблере или даже на перфокартах.:)
VolCh
26.07.2019 14:17Стоимость к качеству обычно отношения не имеет. Смотрят как раз на соотношение цена/качество, если качество нужно, но не любой ценой
pprometey
26.07.2019 13:51Могу, но не хочу и не буду. Это мой личный выбор. Не вижу смысла «распыляться». Вот именно по отношению к тебе лично и твоим вопросам. Имею право. Без обид. Еще раз, прочитай что такое технический долг, как он может обрастать процентами. Если все же хочешь действительно для себя себе ответить на этот вопрос.
dss_kalika
26.07.2019 13:58-1Ну что ж. Раз сам не можешь объяснить — значит сам не понимаешь.
В следующий раз когда захочется какие то оценки порядка «качественнее-не качественнее» давать — стоит разобраться в том, как это оценивать.
Спасибо, что прояснил это )
ЗЫ: и, да — «техдолг» — понятие не связанное с фреймворком. =)pprometey
26.07.2019 14:02Вот в том числе из-за такого провакативного способа ведения диалога, нет вообще никакого желания тебе что-либо объяснять и «напрягаться».
Вижу больше с твоей стороны попытку самоутвердиться, чем достичь истины.
Можешь считать, что я не знаю как объяснить, если тебе будет так легче жить. Ради бога, ни в чем тебя переубеждать не собираюсь. И так много времени потратил впустую на разговоры с тобой.dss_kalika
26.07.2019 14:10Извини, просто тяжело общаться с человеком, который просто утверждает что что то «качественее» просто потому что он так сказал. А потом ещё всячески уходит от попыток как то это обосновать.
Ну раз попытки узнать, откуда информация про «качественность» в твоих постах — самоутверждение, то пусть будет так.
И так много времени потратил впустую на разговоры с тобой.
Не насилуй себя )
Mox
22.07.2019 19:06+4Это про США, в России нет неограниченного пула кандидатов.
sshikov
22.07.2019 19:58Значит, не только я вижу тут противоречие. Кстати, откуда у них пул кандидатов? В США большая безработица среди синьоров?
DenisTrunin
23.07.2019 07:29В Австралии рассказывают что при открытии вакансии почтовый ящик часто переполняется от резюме(думаю в США так-же). А если компания еще готова предложить визу, то это вообще будет вал. Плюс босс рассказывал что ему каждую неделю названивают рекрутеры и предлагают кандидатов
andersong
23.07.2019 12:42в России нет неограниченного пула кандидатов
В России это называют очередью за воротами))))
vsantonov
22.07.2019 19:24+1Проходил несколько раз подобные тесты, в том числе на HackerRank по специфике Sysadmin/Devops, были довольно практические задачи, например отсортировать скриптом файлы по расширению в папке. Однажды тест был вообще повторением экзамена одной красношляпой компании, где удаленную машину нужно было настроить в соотвтетствии с требованиями. Почему программистам не могут сделать так же? Может просто гугл задал этот идиотский тренд и все слепо повторяют?
snuk182
22.07.2019 20:39Почему программистам не могут сделать так же?
Потому что реальные задачи старшего разработчика: а) не решаются однострочником, б) не описываются одной строкой, в) очень часто нелинейны и не решаемы без обратной связи с заказчиком/БА/менеджером.
vsantonov
22.07.2019 21:24+1Почему сразу однострочник, одно задание я выполнял честный час. Там было кучу проверок знаний в разных областях, в том числе и на внимательность. Мои фантазии, например, дается кусок кода, задача уменьшить время исполнения в два раза, чем не практическая задача?
Source
23.07.2019 00:41например, дается кусок кода, задача уменьшить время исполнения в два раза, чем не практическая задача?
Кстати, очень хороший вариант. Можно даже без уточнений во сколько раз… просто ускорить. Кто сильнее ускорит, тот и больший молодец :-)
arheops
23.07.2019 02:12А не получится.
Без запуска в реальном окружении практически невозможно сказать, какой из двух вариантов для более-менее сложной задачи выполняется быстрее.
Ну например один выполняется лучше если у процессора быстрый кеш, а второй — если SSD чуть быстрее.snuk182
23.07.2019 10:33Оценка алгоритмической сложности. Кстати, хороший вариант задачи. К тому же жизненный, если зовут на рефактор проекта, изначально написанного и оплаченного по количеству строк кода.
PsyHaSTe
25.07.2019 01:03+1Но бесполезный, если на проекте пофиг на время выполнения кода, то есть в 99% проектах. По-моему опыту либо на проекте производительности даже питона за глаза, либо с производительностью проблемы, но все они IO bound и нужно уметь запросы в базу писать да шардирование настраивать, а не сортировки бенчить.
snuk182
25.07.2019 12:18Ох, вы не знаете, пофиг или нет, если проект изначально написан антисанитарами, где в критических ситуациях впилен крончик "в случае неотзывчивости сервера просто прибей его и запусти заново".
Source
23.07.2019 12:29Ну, не многие конторы пишут софт под конкретное железо. Можно изначально рассчитывать на SSD и более-менее современный проц, но жёстко оптимизировать под конкретные модели — это слегка перебор в большинстве случаев.
А так, можно и тестовый стенд выделить, чтобы все решения в одних условиях сравнивать. Во всяком случае, это достаточно реалистичная задача, которая позволяет отличать сеньоров от джуниоров.michael_vostrikov
23.07.2019 20:30А так, можно и тестовый стенд выделить, чтобы все решения в одних условиях сравнивать.
Нельзя. Это будет вариация анекдота про выкидывание половины резюме в корзину. Кому повезло угадать с железом, тот и победил.
Source
23.07.2019 21:48Эм, а конфигурацию выписать и приложить к заданию сложно что-ли? Зачем гадать? Да и, по факту, не упрётесь вы в железо в рамках тестового задания. Что вы там собрались оптимизировать за 1-2 часа, чтобы модель процессора влияла на место вашего алгоритма в общей таблице результатов?
michael_vostrikov
23.07.2019 22:24Ну так разговор же про "один выполняется лучше если у процессора быстрый кеш, а второй — если SSD чуть быстрее". Угадать в смысле выбрать код, который на этом железе будет работать быстрее. По конфигурации нельзя понять, какой вариант из них имеет место, надо брать оба и измерять результаты.
Source
24.07.2019 11:50Это не разговор, это фантазии arheops. Вы такой код (завязанный на характеристики конкретных моделей железа) за пару часов не напишете, а если и напишете, то это будет говорить о вас с негативной стороны, если речь не идёт о разработке под микроконтроллеры.
По конфигурации нельзя понять, какой вариант из них имеет место
Можно. Характеристики конкретных моделей никто не скрывает.
michael_vostrikov
24.07.2019 12:21Вы такой код за пару часов не напишете, а если и напишете, то это будет говорить о вас с негативной стороны
Так я говорю о том, что один так написал, другой по-другому, алгоритмы примерно одинаковые, но первый на тестовом железе выполняется быстрее из-за того, что лучше ложится на такое железо. Случайно, а не специально.
PsyHaSTe
25.07.2019 01:08Что делать на проектах где важна произвотельность кода? Ну вот например у меня как-то MS SQL построил план на триллион строк, потому что оптимизатор решил что будет циклами джойнить, хотя если сначала через хэш мерж склеить две других таблички, то время выполнения с 3 минут падало до скольких-то миллисекунд. И никто не знает, почему.
В итоге я день потратил на поиски принципов, по которым оптимизатор определяет такой порядок, и еще сколько-то времени пытался понять какой вид запроса поможет ему сделать правильный вывод. В результате выход нашелся, добавил в order by фейковое условие, которое пустило оптимизатор по нужному следу.
Проблема в том, что в реальном проекте почти всегда будет вопрос к БД, и почти всегда каждая проблема будет уникальна. В другой раз я, например, пытался понять, почему парсер того же SQL Server ломается, если в контенте XML колонки встречаются значения с ведущими пробелами.
Ну и все в таком духе. Как это проверять?
Source
25.07.2019 11:14Если что, ветка про тестовое задание на оптимизацию, как альтернативу тупым задачкам. Или вы ожидаете, что кандидаты будут решать реальные проблемы вашего продакшена за 1 час?
В принципе задание на оптимизацию конкретной выборки — это тоже вариант. Даёте доступ к БД, медленный запрос и задание ускорить выборку. Но если Вы сами потратили 2 дня, то странно будет ожидать, что другой человек справится за 1 час. А если справится, компания готова ему платить в 10-15 раз больше, чем Вам?
В результате выход нашелся, добавил в order by фейковое условие, которое пустило оптимизатор по нужному следу.
Как-то костыльно и хрупко выглядит, где гарантия что после обновления минорной версии MS SQL сохранит нужное вам поведение? Я бы попробовал "сначала через хэш мерж склеить две других таблички" в подзапросе, чтобы у планировщика не было выбора, а потом уже поверх него добавить всё остальное.
PsyHaSTe
25.07.2019 15:43Если что, ветка про тестовое задание на оптимизацию, как альтернативу тупым задачкам. Или вы ожидаете, что кандидаты будут решать реальные проблемы вашего продакшена за 1 час?
Да, я ожидаю. Конечно, нужно упростить, чтобы реально было решить за час, и это не требовало конкртеных знаний конкретной страницы мануала, но в целом реальные задачи тем и хороши, что во-первых показывают уровень проблем проекта, а во-вторых позволяют оценить решение со всех сторон, т.к. вы долго над ним думали, прежде чем пришли к текущему.
Как-то костыльно и хрупко выглядит, где гарантия что после обновления минорной версии MS SQL сохранит нужное вам поведение? Я бы попробовал "сначала через хэш мерж склеить две других таблички" в подзапросе, чтобы у планировщика не было выбора, а потом уже поверх него добавить всё остальное.
Подзапрос не помогает. Фишка еще в том, что запрос формируется не в SQL, а через ORM, и те же хинты использовать не получится (ORM их не поддерживает). Собственно, задача была именно в том, чтобы придумать как через имеющийся апи сделать, потому что к хранимкам на проекте относились хуже, чем к таким костылькам. На SQL можно было просто влепить
left hash joinв нужном месте и все бы отработало как надо.
Хотя сейчас я наверное какой-нибудь даппер взял и прямой запрос написал. Просто этот подход плохо дружит с паттерном query builder, который используется чуть менее чем везде.
PashaNedved
25.07.2019 15:52Кандидатам не дают реальные задачи из юридических соображений.
PsyHaSTe
25.07.2019 15:59В чем юридическое соображение запрета задачки вида "у вас есть три таблички с такими-то записями, и вам нужно их поджойнить через общеизвестный фреймворк"?
PashaNedved
25.07.2019 16:36Кандидат предлагает решение задачи, так как у вас нет с ним договоренностей, то право собственности на предоставленное решение принадлежит ему.
PsyHaSTe
25.07.2019 17:55И что?
PashaNedved
26.07.2019 01:25Вы не можете просто так взять и использовать, то что вам не принадлежит. А кандидат может претендовать на результаты деятельности вашего бизнеса, даже в случае совпадения предоставленного им решения.
Druu
26.07.2019 02:32Вы не можете просто так взять и использовать
Так не используйте.
А кандидат может претендовать на результаты деятельности вашего бизнеса, даже в случае совпадения предоставленного им решения.
Не может.
PsyHaSTe
26.07.2019 03:03Вы правда думаете, что люди побегут рабочее решение (которое давно внедрено) перепиливать под идею которую озвучил рандомный кандидат на собеседовании? Особенно учитывая, что задачку отрафинировали, выкинув всю специфику чтобы не грузить ненужными подробностями?
PashaNedved
26.07.2019 04:06в целом реальные задачи тем и хороши, что во-первых показывают уровень проблем проекта
Вы правда думаете, что люди побегут рабочее решение (которое давно внедрено)
Я думал, что у вас есть проблемы, а они уже решены оказывается.
Конечно, нужно упростить, чтобы реально было решить за час, и это не требовало конкртеных знаний конкретной страницы мануала,
Особенно учитывая, что задачку отрафинировали, выкинув всю специфику чтобы не грузить ненужными подробностями?
Выбросите всю специфику — это реальная задача? Чем она будет отличаться от задач из мануалов.
Сколько времени вы будете тратить на составление одной задачи рассчитанной на один час времени кандидата? Я думаю, минимум рабочий день. Сколько подобных задач вам понадобится составить за 1 год?
Бизнес не стоит на месте, возникают новые проблемы в проектах, их тоже нужно учитывать. Задачи, как и код — их нужно поддерживать, устраняя неточности и противоречия. И в любом случае, срок годности ваших задач будет истекать довольно быстро.PsyHaSTe
26.07.2019 04:56Я думал, что у вас есть проблемы, а они уже решены оказывается.
Реальные проблемы просто источник хороших вопросов. Понятное дело, что чтобы оценить решение кандидата нужно уже самим сделать, сравнивать-то с чем-то надо.
Выбросите всю специфику — это реальная задача? Чем она будет отличаться от задач из мануалов.
Сколько времени вы будете тратить на составление одной задачи рассчитанной на один час времени кандидата? Я думаю, минимум рабочий день. Сколько подобных задач вам понадобится составить за 1 год?на одном из собеседований меня попросили спроектировать сервис коротких ссылок. Ну там с изменением требований и т.п. Сколько по-вашему должно пройти времени прежде чем этот вопрос устареет?
И в любом случае, срок годности ваших задач будет истекать довольно быстро.
Срок годности таких задач в пределах времени жизни фреймворка или технологии, для которой его сделали. Вопрос по грамотному проектированию индексов в SQL будет например актуален для любой версии любой реляционной бд.
PashaNedved
26.07.2019 06:50на одном из собеседований меня попросили спроектировать сервис коротких ссылок. Ну там с изменением требований и т.п. Сколько по-вашему должно пройти времени прежде чем этот вопрос устареет?
Написать сервис коротких ссылок — это распространенное тестовое задание для мидлов, 3 часа — 1 день. Видимо у нас с вами разное представление о сеньорности.
Вопрос по грамотному проектированию индексов в SQL будет например актуален для любой версии любой реляционной бд.
Это вопрос знания технологии, можно обсудить устно, вы собираетесь усложнить его конкретикой, что бы дать в качестве тестового задания? Да, возможно получится хорошее задание, но…
VolCh
26.07.2019 07:36Вопрос по грамотному проектированию индексов в SQL будет например актуален для любой версии любой реляционной бд.
Ох не факт. Даже в разных версиях одной рсубд грамотное проектирование индексов будет отличаться. Особенно если мажорное обновление сделало совсем новых типы индексов типа функциональных или частичных.
VolCh
26.07.2019 07:31Был такой случай:
- иду на собеседование
- хорошо так поговорили о способах решения абстрактных проблем с их техлидом, обсуждали плюсы и минусы двух подходов к проблемам консистентности, приходим к некоторому консенсусу, кроме одного пункта
- офер сделали, но отказался
- пошёл в другую компанию, прямого конкурента
- через год где-то вторая компания (вернее вышестоящий холдинг) покупает первую, дружественное слияние по отношению к топам, недружественное к персоналу, в частности всех программистов в ней увольняют "по собственному", большинству говорят две недели фактически не отрабатывать, но зарплату получат, нескольких просят "передать дела" нам и только потом на тех же условиях писать заявление, плюс свободный график чтоб собесы проходить и т. п. Почти все соглашаются в том числе тот техлид
Ну и в процессе передачи в одном месте говорит что-то вроде "ну вот тут сделано как мы с тобой тогда обсуждали, я дня три думал и решил это сделать как ты предлагал".
Мне просто приятно было и прикольно. Но кто-то на моём месте мог и по другому поступить. А техлид мог бы быть свидетелем истца, поскольку лояльности к его по сути бывшему начальству было меньше ноля после сделки.
vvbob
26.07.2019 09:08недружественное к персоналу, в частности всех программистов в ней увольняют «по собственному»
И нафига они соглашались? Пусть сокращают по закону, со всеми положенными выплатами.
Source
26.07.2019 12:10Фишка еще в том, что запрос формируется не в SQL, а через ORM
Ну, это так себе фишка. Нет никакого оправдания городить днями костыли в угоду ORM для случаев, которые нормально решаются на SQL. Большинство ORM позволяют выполнить raw SQL или использовать его фрагменты в нужных местах. Если ORM этого не позволяет, то следует его отправить на другие 3 буквы ещё до старта проекта.
AlexeySoshin
25.07.2019 18:02Так тестовые задания кандидаты тоже отказываются решать, «долго», «не хочу время тратить», «вы мне за это заплатите» :)
Source
26.07.2019 12:13Так это не типовое тестовое задание. Тут уже есть код, который можно запустить без доп.настройки на готовом сервере. И 1-2 часа, чтобы ускорить этот код. Что успел ускорить, то успел. Поэтому долго не будет.
gohan
23.07.2019 04:22-1Там было кучу проверок знаний в разных областях, в том числе и на внимательность
«было кучу» — тоже проверка на внимательность? Эти слова склоняются не так сложно, вроде.
helions8
22.07.2019 19:53+1Вопрос, мне кажется, не в задачках – они бывают разные, не только на алгоритмы. Вопрос в том, что собеседование зачастую не отбирает кандидатов, реально необходимых требуемой позиции. Нанимающая сторона зачастую не знает, как отобрать нужных им людей – мне кажется, что именно поэтому возникают негативные ощущения от собеседований. Мне очень понравилось мое же недавнее собеседование в большой банк, которое я не прошел, но было сразу понятно 1) кто им конкретно нужен 2) чем они занимаются 3) почему ни я им, ни они мне не подходят. А вот когда мелкий «стартап» начинает устраивать Google-style interview, говоря, что раз вы с задачками справитесь, то и с остальным точно справитесь, то вот тут уже возникают вопросы. За прошлый год я провел 50+ собеседований, как интервьюер, и для меня самой важной задачей было выяснить 1) проверка минимально необходимого нам уровня (ну должен он знать про хеш-таблицы) 2) границы опыта 3) хотел бы я с таким человеком работать 4) если кандидат нормальный, то дать задачку, чтобы порассуждать. Процесс постоянно надо менять и подстраивать, нужны итерации… Хороший найм и проведение собеседований — это сложно и утомительно.
The_Vlad
22.07.2019 19:54-17Синьеришки по гуглению, не могут решить элементарных базовых задач по компьютер сайнс и по этому жалуются на habr. Ай-яй-яй какой ужас. Бедные синьеришки.
knotri
24.07.2019 13:27Так если бы это было собеседования на синьер комьютер саинз специалиста — вы правы.
Но речь то про синьер перекрашивателя синей кнопки в красную — где нужные скилы лежат достаточно далеко от компьютер саинз, и как раз ближе к навыкам гугления, опыта, софт скиллов и так далее.
hoack
22.07.2019 20:21+1На самом первом собеседовании я даю задачку на HackerRank и смотрю, как кандидат ее решает. Задачку даю простую, чуть-чуть сложнее, чем FizzBuzz. Зачем? Для того, чтобы убедиться, что кандидат умеет программировать, то есть может, получив практически чистое описание несложного алгоритма, взять и закодировать его на том языке, который он выберет сам. И да, я периодически встречаю кандидатов, у которых 10 с лишним лет опыта работы, все резюме заполнено крутыми технологиями, но закодировать простой алгоритм они не в состоянии.
SergeyVin
22.07.2019 21:40+8Если отсечь откровенный обман, что тоже бывает, получается, что кандидат 10 лет не писал ни строчки, получал за это какие-то деньги, а только вы спустя 10 лет раскрыли этого сукиного сына.
Что-то мне кажется, что это проверка не на умение писать код, а на умение работать под прессингом. Это тоже важно, не спорю. Но не лучше ли спокойно пообщаться, а потом уже разбираться: если сотрудник стрессоустойчив — будет работать с заказчиками, если нет — ну ок, оградим его от стресса, будет пилить свой модуль. Зачем людьми сразу разбрасываться? Тем более «борзый» и «стрессоустойчивый» с более высокой вероятностью кинет вашу компанию, как только получит поинтересней офер. Спокойные же разрабы будут лояльней.gohan
23.07.2019 04:36Если отсечь откровенный обман, что тоже бывает, получается, что кандидат 10 лет не писал ни строчки, получал за это какие-то деньги, а только вы спустя 10 лет раскрыли этого сукиного сына.
А вдруг он «читерил»? Вдруг в гугл лазил всё это время, а надо без него уметь! Как вот прочитал тут недавно где-то в интернете байку, типа разработчик из дома работает, ну кодит и постоянно гугл открывает, что-то ищет нужное. Жена ему говорит: «А разве ты не жульничаешь? Ты же дожен сам всё это знать, а ты в гугл лазишь!»smarthomeblog
23.07.2019 09:3799% кода уже написано давно. Нужно просто его найти и адаптировать для своих нужд. И да, для этого нужен и Гугл, и StackOverFlow. И ничего зазорного в том нет. ИМХО гораздо хуже, когда изобретается велосипед, который по всем параметрам хуже уже готовых аналогов, и кроме геморроя с дальнейшей поддержкой ничего не принесет.
Whuthering
23.07.2019 11:15Мне кажется у комментатора выше был сарказм)
gohan
23.07.2019 21:16Сарказм, сарказм. Я ж там специально написал историю про жену программиста. Увы, походу, чуток переоценил интеллект хабраюзеров.
GreenBee
23.07.2019 12:25А в чем проблема в использовании гугла?
Если ты еще не решал данную задачу — логично погуглить, чем изобретать велосипед.
На том же SO можно по некоторым вопросам увидеть прямо «изобретение поезда»: вопрос задан, кто-то на него ответил, вроде даже правильно, потом в комментариях оказалось, что есть нюансы, потом оказалось, что эту задачу можно решить совершенно по-другому, потом, через пару лет, еще появился ответ с использованием каких-нить новых фич языка/инструментария.
Умение применять существующие решения, а не изобретать свои — очень хороший навык.
hoack
23.07.2019 18:59Нет-нет, я не говорю про обман. Я имею в виду ситуацию, в которой человек, работая, не программирует, а модифицирует/адаптирует/клонирует чужой код. Где взял уже написанное, где на Stack Overflow сходил… Так можно очень долго работать, и даже вполне результативно. Моя цель на этом этапе совсем не вызвать стресс, поэтому я даю очень простые задачи. Ну, например, одно время давал вот такую:
«Определим последовательность Трибоначчи как последовательность, первые 3 элемента которой равны 1, а каждый последующий равен сумме трех предыдущих. Написать функцию trib(n), которая будет возвращать n-ный элемент последовательности.»
С моей точки зрения, человек, имеющий минимальный опыт программирования, должен без труда справиться с этим заданием меньше, чем за двадцать минут. Я даю на это до 45 минут, при этом сразу говорю, что основное задание — написать работающую программу, пусть даже она не оптимальна. Разве это стресс?
Kwisatz
24.07.2019 00:09+1Конечно стресс:
— Сам факт экзамена
— Все эти игры с простыми/сложными задачками и кусками кода привели к тому, что не поймешь толи правда элементарщина, толи где то заныкали заковыку
— Этот код никогда не увидит жизнь, у меня например при этом мозг начисто отключается
— Разные критерии оценки: мне важно оформление кода и читаемость, вам оптимальность, 3ему обязательно нужно чтобы это было обернуто в класс, 4му знание математических формул и теорем, 5му знание встроенных функций языка, 6му знание плугинов/фреймворка, 7му слабодокументированных хитростей языка. И во всех этих случаях есть очень высокий шанс того, что вместо разговора двух профессионалов это превратиться в: Как, вы незнаете?!!! А вот это вы тоже не знаете? *мерзкий тон, осуждающий взгляд*. Это очень неприятно знаете ли.
— многим, в тч и мне не нравиться писать на листочке. Нет автодополнения, писать нужно ручкой (чего многие годами не делают), текст уползает (хоть кто бы дал листок в клеточку/линеечку) итд
ЗЫ ну вот я накидал примерчик, по-моему минуты 4 ушло, еще столько же пробелы расставлял, затолкал его в класс от нефиг делать, прописал нормальное имя (нам же читаемый код нужен, правда?), переименовывал функции чтоб читалось лучше(на листочке, ага), загуглил как пишеться Трибоначчи(«ааа, незнаете», помним, да?))
class TribonacciSequence { public static function getElement($elementNumber) { $sequence = [1, 1, 1]; if ($elementNumber >= 4) { return self::extendSequence($sequence, $elementNumber); } else { return $sequence[$elementNumber - 1]; } } private static function extendSequence(&$sequence, $targetElementNumber) { $elCount = sizeof($sequence); $newElement = $sequence[$elCount - 1] + $sequence[$elCount - 2] + $sequence[$elCount - 3]; $sequence[] = $newElement; if ($elCount + 1 < $targetElementNumber) { return self::extendSequence($sequence, $targetElementNumber); } else { return $newElement; } } } echo TribonacciSequence::getElement(10);
Осталось 34 минуты, вспотел, переписал:
function trib($n) { $sequence = [1, 1, 1]; return $n >= 4 ? extendSequence($sequence, $n) : $sequence[$n - 1]; } function extendSequence(&$sequence, $n) { $elCount = sizeof($sequence); $newElement = $sequence[$elCount - 1] + $sequence[$elCount - 2] + $sequence[$elCount - 3]; $sequence[] = $newElement; return $elCount + 1 < $n ? extendSequence($sequence, $n) : $newElement; } echo trib(10);
Осталось 32, еще переписал
function trib($n) { $first = 1; $second = 1; $third = 1; for ($i = 3; $i < $n; $i++) { $curr = $first + $second + $third; $first = $second; $second = $third; $third = $curr; } return $curr; }
Еще 30… Да пока 45 прошли я бы в ужасе был, честно говоря)Source
24.07.2019 12:04У вас в финальном варианте $curr не определён при
$n <= 3, и нет проверки что$n > 0
Ну и мемоизацию не помешало бы докрутить, а то нафига всю последовательность пересчитывать при каждом вызове xDKwisatz
24.07.2019 12:46А я в курсе) Я специально убрал, чтобы было до чего докопаться. А в третьем варианте в угоду минимальному коду)
И про последовательность само собой разумеется, именно поэтому в первом примере есть статический класс. Но у этого и обратный эффект есть, большой расход памяти.
hoack
24.07.2019 15:55А ждать до 45 и не пришлось бы :) Этот этап интервью у меня идет онлайн, и как только появится первое рабочее решение, можно будет двигаться дальше. Мы бы обсудили оптимизацию, и многое другое — но главная цель была бы достигнута, я бы пригласил вас на интервью в офис.
Так вот, как минимум 30%, а то и больше, кандидатов НЕ МОГУТ за 45 минут написать хоть как-то работающее решение.Kwisatz
24.07.2019 16:43В таком случае любой пример уровня (но не он сам) FIzzBuzz по идее должен показать ровно такой же результат. Хотя ваша тоже не сложная, если не на листочке, то вообще без проблем. Хотя разработчик, меняющий работу второй раз в жизни может очень сильно растеряться при определенной манере ведения допроса.
Кроме того поймите, вот вы вроде адекватен, были бы на месте, мы бы с вами обсудили. Очень часто это заканчивается не так. Либо уже на первой задаче: «а вы знали что тут можно very_rare_function_name? Как нет?» И таким тоном, что поневоле начинаешь себя чувствовать идиотом, тем более что все это знаешь же. Либо задачи сменяют друг друга до тех пор пока не возникнет такой момент.
Однако, все еще зависит от постановки вопроса. Ну например «какие индексы бывают в PostgreSQL». Простой вопрос? По идее звучит просто, но на практике большинство разработчиков кроме b-tree в жизни своей ничего не использовали. Ну некоторые вспомнят GIN/GIST, возможно даже hash (хотя он редко упоминается во всевозможных гайдах да и пользоваться им ну очень редко кому приходится), BRIN не вспомнит никто (если вы недавно не читали документацию и то врядли). Да и сама постановка вопроса ставит в тупик: что значит какие? многоколоночные, уникальные, частичные, функциональные. Вот только часто разговор двух профессионалов и будущих коллег больше похож на допрос и тут прям простор для фантазии. А это всего лишь один простенький вопросик, к задачам еще может добавиться отсутсвие обратной связи, неочевидный синтаксис (ой а какие прелести можно вытворять с использованием магических методов в php) и разные критерии оценки.
Посему если собеседование начинается с задачи то сразу нет. Тем более если на листочке или на н часов.VolCh
24.07.2019 18:12Вот, кстати, да. Вопросы "Какие… вы знаете" в принципе нормальные. И когда я задаю подобный вопрос, то или предельно чётко, надеюсь, формулирую типа "типы данных в PHP" или ожидаю уточняющих вопросов по каким измерениям делить. Хотя вот тут сам попался на вопрос "какие виды репликации знаете" и начал говорить про бинарную, стейтмент, смешанную, синхронную и нет, а имелось в виду мастер-слейв и мастер-мастер. Вот как-то совсем из головы вылетело.
Kwisatz
24.07.2019 22:08Такие вопросы вполне нормальны, когда цель собеседования — найти коллегу/подчиненного. И становятся сущим адом если вы попали на допрос к человеку с желанием вас унизить.
С другой стороны: очень хорошо, что это видно на собеседовании а не позже.
Одно из самых разрывающих в клочья собеседований (а оно ли это, работу я не искал, просто пришел послушать что скажут) вроде было в крупной компании, достижения и методы очень впечатляли (хотя офис — нет). Основной собеседующий не представился, очень удивился когда я попросил рассказать о компании (еще более когда услышал, что я их оцениваю в той же мере, что и они меня), выражал крайнее нетерпение, выдавал аргументы в стиле «это говно» и вишенкой на торте: когда я попросил стакан воды прям так закатил глаза как будто я икры намазать попросил. Как представлю, что я сними работаю, брррр.
Хотя второй был приятен, улыбался, говорил интересные вещи. Полагаю первый был нач отдела, второй тимлидом.
symbix
24.07.2019 20:12За Whitesmiths coding style я бы сразу не взял.
Если человеку это нравится, он очень странный!
Kwisatz
24.07.2019 21:58Не переживайте, я бы вас тоже не взял с таким уровнем аргументации)
Очень странно когда компания переживает не о том насколько оптимальным/читаемым/etc будет код, а о том как будут расставлены скобочки и пробелы)
The advantages of this style are similar to those of the Allman style. Blocks are clearly set apart from control statements. The alignment of the braces with the block emphasizes that the full block is conceptually, and programmatically, one compound statement. Indenting the braces emphasizes that they are subordinate to the control statement. The ending brace no longer lines up with the statement, but instead with the opening brace.
Whitesmiths, along with Allman, have been the most common bracing styles with equal popularity according to the Jargon File
Давным давно, когда я еще был маленький, отец меня учил C++ и я усердно читал книжки с листингами сишного кода, вот как раз в таком стиле. Потом были Basic,Pascal, PHP, Java, SQL etc и большая часть кода с которым работал была написана в таком же стиле. Конечно, когда я дописываю библиотеку или участвую в проекте с другим стилем я копирую его в точности, кроме жуткого легаси, где давно всем плевать.
Вот что кстати забавно, begin/end никто не ставит на ту же строку, а вот скобочку уже очень всем хочется. Но вообще то совершенно все равно, код, кроме всего прочего, можно форматировать единым стилем при комите. А вот именование в стиле i,j,k,x,y,z уже не пофиксишь, mont/mons/mesyac уж тем более, говнокод тоже никуда не денется.
Хотя форматирование SQL единой простыней заслуживает порицания. Ибо я не верю, что это вообще можно прочесть.
ЗЫ Вы знаете, за 20 лет вы первый кто поднял этот вопрос)symbix
24.07.2019 22:37Да я вообще пошутил скорее. :)
Но, как говорится, в каждой шутке есть доля шутки. Whitesmiths style не используется примерно нигде, и человек с опытом работы в команде давно бы уже отвык, потому возникает подозрение, что кандидат "не такой, как все" и будет вечно спорить по ерунде вместо того, чтобы сделать "как тут принято". Разумеется, это проверяется провокационными вопросами, ну вот как щас :-)
Kwisatz
24.07.2019 22:45А почему нет? Читается легко)
Нести свет у меня нет никакого желания уже давно. Фреймоврк? Да пофигу какой, код стайл? Ссылочку. Хотя… давайте зарежем ваши богомерзкие недоБД и воткнем постгрес, да и вместо монги тоже)
А ну еще могу по UX попрыгать)
ЗЫ вообще отвыкать причин не вижу, даже после продолжительного времени работы в другом стиле мне все равно нравиться так. Кроме того у меня есть свои плюшечки, которых очень много, кстати.
PsyHaSTe
25.07.2019 01:16Какая вам разница, как написан пример? В нормальном проекте у вас есть editorconfig/gitattributes/…, который форматирует весь код всех участников единообразно. Предъявлять человеку что у него другой стиль это… Такое.
Можно разве что спросить "у нас на проекте используются табы, а не пробелы, вам ок?" и дождаться логичного "да мне пофиг, лишь бы единообразно".
За редкими исключениями, конечно
Igor_O
24.07.2019 22:00Третий вариант красив, но не работает — для N = 1, 2 и 3 выдает неопределенное значение. Нужно еще добавить в начало функции $curr = 1;
Проверка на граничные условия — первое, что в нас пытались вдолбить на программировании на первом курсе в 1987-м году…
Ну и да, переменные объявлять и инициализировать тоже руками приходилось в те времена, обычно…
Причем, в первых двух вариантах вы выполнили проверку… А в третьем — почему-то проигнорировали.Kwisatz
24.07.2019 22:15Потому что достаточно громоздко получится. $curr=1 подойдет только в том случае, если первые 3 равны (в этом плане в первом варианте все красиво, не хватает только проверки на >0, которую убрал намерено, чтобы посмотреть только ли это может быть причиной обсуждения). В 3 хотел специально сделать поменьше, можно еще инициализацию в одну строчку собрать но это уже перебор.
Igor_O
24.07.2019 23:02Ну, как выяснили уже опытным путем — не только это. (Хотя способ форматирования… Об этом холиворы были как раз когда я учился — программисты в СССР более-менее массово начали, наконец, переходить с ФОРТРАНа, Ассемблера и Бэйсика на C и Паскаль. И шли споры начиная от «пробелы против табуляции», и до «сколько пробелов нужно добавлять для следующего уровня» и «нужно ли в программистском редакторе автоматически дописывать пробелы до количества в предыдущей строке»...)
$curr=1 подойдет только в том случае, если первые 3 равны
Ну они равны по условию задачи. Без этого придется передавать первые три значения и номер в последовательности в качестве аргумента…
В любом случае, хоть я уже и не занимаюсь кодингом 25 лет как, но про такую базовую проверку… Я когда первокурсникам помогал на лабах, в таких случаях просил их показать мне устройство чтения мыслей в компьютере и где у них в программе обращение к устройству чтения мыслей.
можно еще инициализацию в одну строчку собрать
… но у нас уже исходник не на перфокартах, где каждая лишняя строчка — лишняя перфокарта, которая может не прочитаться.Kwisatz
24.07.2019 23:55… но у нас уже исходник не на перфокартах, где каждая лишняя строчка — лишняя перфокарта, которая может не прочитаться.
И тем не менее народ упорно сокращает имена всего и вся, использует неочевидные приемы и сокращает код так, что не поймешь толи это набор смайлов толи regexp толи обработка данных.PsyHaSTe
25.07.2019 01:20Ну тогда объясняете человеку, что его код не будет понятен коллегам, и что вам не по пути.
PsyHaSTe
25.07.2019 01:19Если внимательно посмотреть, можно увидеть, что curr это и есть third, кроме случаев от 0 до 2, когда он с ними совпадает по значению.
Поэтому можно просто заменить на return third. Нужно только чуть-чуть поправить цикл, чтобы он учел это изменение.
jakobz
22.07.2019 20:27+20Ну вот я всегда когда нанимаю — прошу открыть IDE, и мы начинаем писать код. Начинаю с супер-простого. Например есть массив городов, есть строчка от пользователя. Давай найдем в ней все города. Уточнаю что все просто и без подвохов. Пишет String.Split(" "), цикл, String.Find() — пойдет. Дальше давай предположим что массив большой, какая сложность алгоритма? Ну типа сколько сравнений будет если 1000 городов и 100 слов в строке? Как ускорить? А давай сделаем поиск case insensitive. И запятые обработаем. А как бы ты ускорял поиск, если бы табличка городов была в БД?
Такой подход позволяет сразу получить работающий код без стресса. Ну, кроме случая когда человек ну вообще программировать не умеет — бывают на первом шаге отлетают. И постепенно дойти до тонкостей — dictionary vs. hash, как устроены деревья. Ну и вообще посмотреть вживую как человек пишет — видно же сразу набита рука или нет.
Просить писать красно-черные деревья — перебор. Спрашивать как работает garbage collector — бред. Но и не просить писать код — это тоже же глупость, так реально нанять человека, который вообще не умеет код писать.Source
23.07.2019 00:54+5Таким подходом хорошо нанимать джунов, но не сеньоров же. Сеньор должен вас зае**ть на первом же этапе кучей вопросов. Почему города хранятся в массиве? Как часто возникает задача поиска городов? Проходит ли ввод от пользователя валидацию формата? Зачем мы даём пользователю вводить несколько городов в одно поле? Какую пользовательскую задачу мы вообще решаем? Какие SLA есть к этой задаче? И если вы вразумительно не сможете ответить на все эти вопросы, то контрольный: Нафига вы меня спрашиваете такую дичь?
Но и не просить писать код — это тоже же глупость, так реально нанять человека, который вообще не умеет код писать.
Ну конечно, как минимум 5+ лет работал программистом и не умеет писать код.
Работа сеньора состоит в том, чтобы сначала думать, а не бросаться кодить. Поэтому всякие учебные задачки и перестают работать. Если у задачи нет никакой практической пользы, то она может поставить в тупик лучших специалистов. Ведь их прямая обязанность — избегать решения подобных задач, т.к. решать любую бесполезную задачу — это прямые убытки для бизнеса.jakobz
23.07.2019 19:14Ну, сеньер тоже должен уметь писать код. Он просто сделает задачку быстро и четко, можно придумать доп. требования посложнее — если видно что умеет. Ну, или можно вокруг этого кода разговор продолжить. Или просто перейти к моему любимому «расскажи что-нибудь интересное из того что в последнее время сделал».
Я вообще раньше сеньеров кодить не просил. Ну типа как-то неудобно — чувак с 10 лет опыта, а я его тупую задачку из института прошу делать. Но один раз пришел товарищ, который умел что-то там по теории рассказать, но не мог писать код вообще. Ну типа вот эту самую задачку — не смог. Типа «ну понимаешь, я лидил, забыл уже что там как». С тех пор, обязательно сначала исключаем волчанку.Source
23.07.2019 21:01Он просто сделает задачку быстро и четко
String.Split(" "), цикл, String.Find()Вы это в контексте данной задачки считаете решением?
Она же изначально сформулирована не как задача, а как проверка "конформизм vs профессионализм": прогнётся ли человек под вас в стрессовой ситуации, поступится ли профессиональной этикой, начав писать то, что вы просите?jakobz
24.07.2019 16:20+2Ну, элитные нон-конформисты с профессиональной этикой, которые будут в уши ссать часами, вместо того чтобы написать тупо что сказано написать — мне не очень нужны.
У этих прекрасных парней есть великое будущее без меня. Кто-то из посадит на золотой трон, вокруг которого стоят негры с опахалами, и приходят просители, и просят написать код, а они им объясняют что код этот писать не будут, и просителей казнят. А тут я такой — взял их, и принял! И это прекрасное их будущее прошло мимо них. Я же от совестливости сопьюсь и повешусь — великую жизнь большому человеку так бездарно испортить.
Так что я все-таки спрошу всех код написать, а если кто мне плюнет в лицо — сотру специальным платочком, его положу в сейф, и потом продам плевок великого Стива Джобса 2 за миллион денег. И всем хорошо будет.
AlexeySoshin
25.07.2019 18:18Решать задачи на интервью — это уже нарушение профессиональной этики? :)
AlexeySoshin
25.07.2019 18:16На самом деле, вопросы от кандидата — это хорошо и позитивно, много о нем можно узнать.
Из где-то сотни кандидатов, что я интервьюировал за последние года три, один или два получили оффер вообще не написав ни строчки кода. Но это скорее исключение из правил.
MRDjeko
23.07.2019 07:32Вы же описали процесс найма на позицию джуниора? Или у сеньоров такие же задачи и вопросы?
AlexeySoshin
25.07.2019 18:19Задачи одинаковые, потому что в итоге все должны писать код. Отличается время на решение задачи, и ожидаемое качество.
Kwisatz
24.07.2019 00:38Если бы табличка была в бд, то вы бы построили по ней индекс и не задавали таких вопросов.
AlexeySoshin
25.07.2019 18:21Задавал бы :)
- Как эта таблица будет выглядеть?
- А какой бы индекс построили?
- А как вообще индекс в БД в целом можете рассказать?
Задача должна быть предлогом пообщаться с человеком.
Kwisatz
26.07.2019 08:41А как бы вы собственно на них ответили?)
Зы формулировка 3 более чем странная
sergey-b
24.07.2019 02:17Я так попробовал и мне не понравилось. Очень трудоемко и требует много времени. И я тороплюсь, и мой собеседник торопится, переговорка на час забронирована, и т. п. Я решил, что буду так делать, когда есть настроение, и я уже точно вижу, что этого человека я беру, т. е. на него потратить силы не жалко.
ainoneko
24.07.2019 06:53Уточнаю что все просто и без подвохов. Пишет String.Split(" "), цикл, String.Find() — пойдет.
А «Великий Новгород» в массиве есть?
А надо ли находить «Петропавловск» в «Петропавловск-Камчатский»?
(И «Ростов» в «Ростов-папа»?)
JediPhilosopher
22.07.2019 20:35-1Очередной тред боли на тему того, как бедных айтишников унижают мерзкие эйчары и прочие негодяи. Такие темы всегда хорошо заходят, так как, думаю, у любого есть хотя бы одна история неудачного собеседования. А уж представлять себя Д'Артаньяном, недооценненым нехорошими людьми, так и вовсе каждый первый любит.
А я вот тоже на собеседованиях даю простую задачку. И мой опыт найма программистов, хоть и небогатый, но однозначно показывает: тот кто не способен написать на собеседовании что-то типа FizzBuzz — тот и в реальности программировать не способен. Пусть хоть 10 лет опыта и стопицот дипломов и регалий — этот человек будет очень медленно решать простые алгоритмические задачи, которые регулярно всплывают тут и там. Он будет адово тупить и зависать на любых задачах сложнее чем "сконфигурировать что-то по шаблону" и "переложить объекты из одного апи в другое".
Fedorkov
22.07.2019 22:01+1По вашему опыту, какой процент потенциальных мидлов/синьоров не способны написать FizzBuzz?
JediPhilosopher
22.07.2019 22:17+4Я скорее джунов-миддлов собеседую, среди них примерно половина из тех, кто приходит на собеседование.
Я обычно даю задачку — обратить массив. Это простейший пример на понимание работы с циклами и индексами. Сразу предупреждаю, что не надо изобретать сложных алгоритмов, никакого подвоха тут нет и любое простое решение сойдет, даю настроенный ноутбук с ИДЕ, сам отхожу в сторонку и прошу позвать меня когда будет готово.
В итоге многие городят какую-то дичь, которая в итоге не работает и валится с выходами за границу массива.
Тут можно сколько угодно рассуждать на тему стресса и "написания кода под прессингом", но если человек такое не может написать (даже без лимита времени) — он не программист и на вакансию программиста претендовать не может.
Пару раз приходилось "на безрыбье" брать людей, которые с этой задачей справлялись плохо — в итоге результаты работы были соответствующие.
Помню из своей первой конторы еще историю — после одного собеседования проводивший его вышел из коридора, начал биться головой об стену и приставать к проходившим по коридору и задавать им вопросы. Что характерно, на его вопросы даже наши 3д художники смогли ответить (ну они у нас там подкованные в ИТ были, для Maya всякие скрипты автоматизации писать умели, но все-таки не программисты). А (по его словам) люди, приходившие на позиции сеньора, с опытом и внушительным резюме, не могли. Но при этом не стеснялись просить ощутимых денег.
AlexTest
23.07.2019 02:57+1Я обычно даю задачку — обратить массив. Это простейший пример на понимание работы с циклами и индексами.
Ну а если он использует что-то типа array_reverse(), аналог которого есть в любом ЯПВУ, что вы тогда узнаете пропонимание работы с циклами и индексами
?Whuthering
23.07.2019 11:17Более того, если он не использует Array.reverse(), а сразу начнет изобретать велосипеды, то это уже минус для разработчика:)
JediPhilosopher
23.07.2019 12:10Если кандидат предложит библиотечный метод то это хорошо и повод немного поболтать на тему знания стандартной библиотеки. Но потом я все-таки прошу сделать это ручками.
deespater
23.07.2019 12:22Но потом я все-таки прошу сделать это ручками.
Зачем?Kobalt_x
23.07.2019 12:24чтобы понять что перед тобой разработчик и он понимает стоимость операций у этих библиотечных методов, а также в случае найма под особенный проект(где использовть стандартные библиотеки либо невозможно либо затруднительно) сможет реализовать это руками.
JediPhilosopher
23.07.2019 13:05Затем, что программирование это не только перекладывание из коллекции в коллекцию и вызов пары-тройки методов API. Иногда приходится своими руками что-то придумать. Ну вот пришел к вам набор данных, надо их отфильтровать, как-то упорядочить, преобразовать и только потом передать дальше.
Причем никогда заранее не знаешь, что и как потребуется обработать, иногда можно обойтись вызовом одной-двух библиотечных функций, иногда нет. Человек, который даже цикл написать не может, будет в таких моментах очень надолго зависать, тормозя всю работу.
При этом в рамках собеседований достаточно сложно родить какой-то содержательный пример "из жизни" — все они будут либо слишком большими (и тянут уже на тестовое задание, а не на задачку на собеседование, а такие задания — тоже источник постоянной боли и вайна на хабре), либо опять же очень синтетическими и упрощенными, и ничем не будут отличаться от таких абстрактных задачек. Поэтому в качестве эффективного фильтра приходится использовать такие вот простые упражнения.
JustDont
23.07.2019 13:16Можно предлагать не менее простую задачку, заведомо не решаемую одним вызовом API, это отсечёт большой пласт довольно пустых разговоров в духе «зачем я буду делать это руками». FizzBuzz был придуман именно таким, что вызовом API его не решить.
JediPhilosopher
23.07.2019 14:07Буду рад, если вы какую-нибудь такую задачку порекомендуете. Которая не настолько общеизвестная (как FizzBuzz), не требует написания больше 5-7 строчек кода и проверяет какие-нибудь базовые навыки программирования.
JustDont
23.07.2019 14:51Мы в своё время практиковали те самые скобочки, про которые тут речь уже в комментах шла. Простые скобочки (1 вид) — элементарнейшая задача, на которой можно посмотреть, как вообще человек пишет код. Много разных скобочек — для углубления в тему, со стеком поработать и т.п.
Но сейчас наверное и эта задача уже настолько же замылена, как и FizzBuzz.
deespater
23.07.2019 13:57При этом в рамках собеседований достаточно сложно родить какой-то содержательный пример «из жизни»
Поэтому лучше попросить кандидата написать абсолютно синтетический код, который никогда не понадобится?
Предлагали бы уже сортировку по заданным условиям делать, больше похоже на вменяемую задачу, чем «разверни массив с завязанными руками и без ноутбука».
И кстати, как бы вы ответили на встречный вопрос кандидата «зачем»?JediPhilosopher
23.07.2019 14:11Поэтому лучше попросить кандидата написать абсолютно синтетический код, который никогда не понадобится?
Любой код с собеседования скорее всего будет синтетическим и никогда в жизни не понадобится. Можно пытаться создать задачу исходя из своего релевантного опыта работы, но это как правило довольно нетривиально — суметь упаковать что-то несинтетическое в несколько строчек кода.
с завязанными руками и без ноутбука
Почему без ноутбука-то? Я как раз и пишу, что даю ноутбук с IDE и подготовленным проектом.
И кстати, как бы вы ответили на встречный вопрос кандидата «зачем»?
"Небольшая проверка на ваше умение писать простой код".
Повторюсь, я не проверяю знание алгоритмов, которые в реальности вряд ли пригодятся, я проверяю способность просто тупо написать три строчки работающего кода. Те, кто сами собеседования не проводят, обычно не представляют какое количество людей приходят на собеседования и не могут этого сделать.
deespater
23.07.2019 14:21но это как правило довольно нетривиально — суметь упаковать что-то несинтетическое в несколько строчек кода
Согласен. Но с моей точки зрения нужно объяснять ограничения: просьба развернуть массив не пользуясь библиотечной реализацией просто потому что интервьюер запретил, как раз и является очень синтетической задачей без предпосылок и искусственными ограничениями (читай с завязанными руками).
Небольшая проверка на ваше умение писать простой код
Так если вам писать простой код надо вы студента наймете? Вряд ли человек с опытом загорится желанием к вам идти чтобы писать простой код.
Да простой вопрос «а напишите map/reduce по таким-то условиям» уже на порядок лучше чем «разверните массив не пользуясь компилятором»
сами собеседования не проводят, обычно не представляют какое количество людей приходят на собеседования и не могут этого сделать.
Так может вам процессы пооптимизировать? Скрининг ввести, чтобы таких кандидатов отсеивать.
Опять же, я ничего против такого подхода не имею, просто для меняон выглядит иррациональным и слегка пассивно-снисходительным для кандидата.JediPhilosopher
23.07.2019 15:02А кто их отсеивать-то должен? По резюме? Так резюме обычно еще меньше о человеке говорят, чем умение решать задачки. По дополнительному собеседованию? Не у всех есть на это ресурсы, да и тут вон все воют когда вместо начальника отдела их начинают всякие хрюши мучать.
В общем нет тут правильного ответа, на любой вид собеседования найдутся те, кому он не понравится.
wataru
23.07.2019 15:35Я даю задачу, которою пришлось решать самому в нашем проекте. Вернее не решать, а перерешивать — там был написан вырвиглазный запутанный рекурсивный полный перебор, который можно было переписать на ДП, сократив в несколько раз, сильно ускорив и упростив при этом.
Пришлось ее немного упрастить, выкинув все некритичные детали, и абстрагировать от предметной области.
Мне конечно повезло, что я такую задачу нашел, но мне кажется что это не невозможно в любом довольно большом проекте. Не обязательно это должен быть какой-то умный алгоритм. В достаточно большом проекте будет хоть немного нетривиального кода, который как-то обрабатывает какие-то данные. Довольно часто из него можно сделать задачу на собеседование.
PsyHaSTe
25.07.2019 01:33+1Мне кажется такие задачи надо в сборник собирать. Чтобы хотя бы принципы как придумать похожую были видны.
AlexeySoshin
25.07.2019 18:31У нас был даже такой сборник. Помогает так же исключать ситуации, когда некоторые интервьюеры задают слишком простые или слишком сложные задачи. Полезная штука.
PsyHaSTe
25.07.2019 01:32Затем, что программирование это не только перекладывание из коллекции в коллекцию и вызов пары-тройки методов API.
Как правило, оно и есть.
Ну вот пришел к вам набор данных, надо их отфильтровать, как-то упорядочить, преобразовать и только потом передать дальше.
Ну вот эту задачу и задавайте. Хотя я бы её так и решал
xs.filter().group_by().map()....
От программиста следует ожидать самого простого способа решить задачу, а не вставлять палки в колеса "не используйте букву i в названии переменной цикла".
serge-phi
23.07.2019 14:12Потому что завтра может возникнуть задача, для которой нет библиотечного решения.
dominigato
23.07.2019 12:27Да уж, если ваш девопс начал изобретать методы сортировки, он явно делает что-то не то, время бить по рукам))
Но почему-то на интервью просят сделать именно неэффективную реализацию, которая никогда в жизни не может быть использована, которую нельзя делать потому что уже есть в библиотеке — то есть ровно наоборот того, что понадобится на рабочем месте.
Именно это почему то называется проверкой.
Xander_Vi
23.07.2019 11:47Обратить массив?
Не знаю, насколько сложно это реализовать в других языках, но в Python это не просто одна строчка — это буквально 6 символов (без учета названий переменных): reversed_list = input_list[::-1]
PsyHaSTe
25.07.2019 01:29+1Честно говоря, мне с трудом вериться, что такие существуют. Я постоянно вижу в интернетах мнение, что они есть, но вживую подобных коллег никогда не встречал. У меня в голове не укладывается, как это возможно. Я перестаю с человеком общаться, если он не хочет расти и не хочет понимать, почему индексирующий сервис должен быть идемпотентным, а тут про физзбазз страшные рассказы.
AlexeySoshin
25.07.2019 18:34Существуют :)
Даже тут полно товарищей "я уже знаю один язык, работу найду, больше и не нужно".
borv
22.07.2019 20:38+5Хмм… Я тоже завалил какую-то шнягу на трансформацию бинарного дерева в конторе "с совой". Потом еще какую-то другую шнягу на ограниченный поиск в другой такой же "перспективной компании".
Я думаю упражнения — это хорошо, но есть один нюанс. Проходить они должны в нормальных рабочих условиях, максимально приближенных к боевым. Как часто вы impromptu будете объяснять комнате полной инженеров как манипулировать двоичными деревьями? А кодить по тимвьюверу на чужой машине, параллельно объясняя ход своих мыслей? А как на счет оптимизации кода под конкретный GC без телеметрии? Может подъем кубов с масштабируемой трехзвенкой с нуля в проде за час? Вы правда именно так работаете? Если ответ — реально "да", то, простите, я ваш вертеп укурков не пойду работать ни за какие деньги. Если "нет" — тогда зачем весь этот цирк с конями? Что вы проверяете?
Куда более реалистично — поговорить про задачу у доски, придумать дизайн и уйти кодить, а через день принести код на ревью. Собственно у нас есть упражнение на дизайн (на доске, с группой из 4 человек) и задача часов на 4-6 которую надо сделать дома и прислать на ревью. Оба упражнения очень близки к тому, что реально делалось когда-то. Мне этот подход сразу показался адекватным, что существенно повлияло на мое решение работать с ними. После 2 лет в коллективе — не жалею ни разу. Контора (внезапно!) тоже оказалась очень адекватной, и по режиму работы, и по отношению к инженерам, и по компенсации.
В интервью очень многое — дань моде, к сожалению. Раньше было модно думать за пределами коробки, потому были круглые люки и автобусы набитые шариками. Сейчас модно хипстерство и коллаборешн, поэтому задачки и интерактив. Завтра будет найм только через нетворкинг и по количеству звезд на гитхабе. Если контора гоняется за трендами как ошпаренная, десять раз подумайте есть ли смысл там работать за +15К в год.
PsyHaSTe
25.07.2019 01:37Куда более реалистично — поговорить про задачу у доски, придумать дизайн и уйти кодить, а через день принести код на ревью. Собственно у нас есть упражнение на дизайн (на доске, с группой из 4 человек) и задача часов на 4-6 которую надо сделать дома и прислать на ревью. Оба упражнения очень близки к тому, что реально делалось когда-то. Мне этот подход сразу показался адекватным, что существенно повлияло на мое решение работать с ними. После 2 лет в коллективе — не жалею ни разу. Контора (внезапно!) тоже оказалась очень адекватной, и по режиму работы, и по отношению к инженерам, и по компенсации.
Подход хороший, но ИМХО предельное время на задачу — 1-2 часа, причем желательно и собеседующего, и собеседуемого, иначе это какая-то домашняя работа строгого учителя. "Разошлю сотне претендентов задачку, пусть помучаются". И потом 2 минуты на проверку каждой.
В конторах, где мне собеседование проходить понравилось оно было устроено в виде итеративного дизайна на бумажке вместе с местным архитектором. В стиле "как программисты хлеб пекли".
AlexeySoshin
25.07.2019 18:38Как software architect, именно так и стараюсь делать :)
Правда стараюсь не на бумажке, а на доске, но если кандидат очень хочет — можно и на бумажке, конечно.
botyaslonim
22.07.2019 20:54+1Меня (устраивался фронтэндом) тоже валили на бинарных деревьях. Причём, как мне показалось, собеседнику это было просто по приколу: он закончил МехМат МГУ и, видимо, любил эту древесину.
С тех пор прошло два года. Я устроился в другую компанию. Решил просто огромную гору задач, разработал кучу виджетов, отрефакторил тонны старого кода, вырастил джуна, написал много документации и так далее. С коллегами обсуждали: кажется, не два года прошло, а четыре, работы реально много. Моим поделками ежедневно пользуются миллионы людей, и вроде бы компанию устраивает качество работы.
А те ребята ещё спустя где-то полгода всё искали человека. И потом ещё через год искали.
ps. Думаю, более-менее разумным выходом были бы сертификации в авторитетных центрах. Что-то типа прошёл двухнедельные курсы, показал себя со всех сторон, порешал сложные задачи, получил лычку и право называться senior. Тогда и собеседующим было бы спокойнее. Смотрели бы на собесах soft skills и мотивацию кандидата, а не знание на память всех встроенных методов. Но до этого, очевидно, далеко.
musicriffstudio
22.07.2019 20:59-2Нытье какое-то.
Да, найм проводят плохо. Просто не умеют. Даже тут в каментах отметились подобные типы с безапелляционным мнением и чушью про стрингсплит.
Да, они сами не пройдут такое же точно интервью у такого же горе-программаста.
Нужно просто подготовиться к преодолению данной преграды и пройти квест. Даже если у спрашивальщика гораздо меньше опыта и он просто не понимает о чем ему говорят.
Выяснить заранее о процессе, пройти тесты пару раз, почитать какие вопросы задают и какой ответ у них в бумажке.
Это ж на один раз.
AlexeySoshin
25.07.2019 18:39И как успехи, где уже квест прошел? Google/Facebook/Netflix, Uber/Microsoft/Amazon хотя бы? :)
CrushBy
22.07.2019 20:59+11Когда я нанимал строителей на ремонт, то действовал по простому принципу: нужно брать тех, кто хуже всех «продает себя». Так как если они плохо продают, но до сих пор на рынке, то значит делают хорошо. А мошенники всегда просто отменно умеют ездить по ушам. К сожалению, с наймом тоже самое. Нету никакой гарантии, что люди, которые умеют хорошо проходить собеседования, также хорошо умеют работать.
Hydro
22.07.2019 23:28Как и люди, которые не умеют хорошо проходить собеседования.
Гарантии вообще, обычно, нет.CrushBy
23.07.2019 07:59Верно, гарантии нету. Но люди, которые понимают, что не умеют проходить собеседования, реже ходят на них, и стараются держаться за свое место. Но если такого человека не уволили, и он сам пришел на собеседование, то есть вероятность, что работник он хороший и его просто так недооценивают на текущем месте, что его уже достало.
VolCh
24.07.2019 12:17Или что-то другое достало. Или просто не видит дальнейшего роста. Ещё сркращения бывают.
VGoudkov
22.07.2019 21:01Мы вот тоже, после некоторого количества неудач, решили, что раз мы нанимаем программиста — он таки должен уметь программировать! И сделали класс с заготовками методов, заданиями в виде JavaDoc и тестами TestNG, которые проверяют результаты.Первый метод — реализовать тело FizzBuzz, далее задачки чуть хитрее (но все из практических ситуаций), в пределах стандартной библиотеки Java. Кандидату предоставляется ноутбук с IDEA, изображение дублируется на проектор в переговорке. Вопросы задавать можно, гуглить тоже. Обычно кандидаты справляются за 15-40 минут.
Интересен не столько достигнутый результат (все тесты зелёные), сколько способ решения задачи / кодирования. Если предложенный вариант решения мягко говоря странен — начинается дискуссия по возможным улучшениям и/или краевым случаям, что позволяет оценить опыт кандидата и количество косяков в production, которые от него можно ожидать.
Экономит просто ТОННЫ времени и нервных ресурсов на собеседованиях и неплохо отделяет тех, у кого код на кончиках пальцев, от заучивших ответы про устройство HashMap.AlexeySoshin
25.07.2019 18:41Это один из наиболее здравых подходов, кстати. Видел такое у OLX и Atlassian как минимум.
VolCh
26.07.2019 07:39+2Кстати, как-то было собеседование где предоставили ноутбук. С треском провалил прежде всего из-за ноутбука. Так состоялось моё первое личное знакомство с техникой и софтом Apple
moonster
22.07.2019 21:01Год уже как участвую в найме — провожу техническое интервью. Никакой теории не спрашиваю, сплошная практика.
За отпущенные 2 часа большинство не успевает.
Всего две задачи, можно использовать IDE.
Первая — разработать некий сервис + тесты, из сложностей — нужно уметь читать требованияна английском, иметь базовые навыки многопоточного программирования, уметь писать юнит-тесты. Разрешаю пользоваться документацией, даже гуглить при сильных затруднениях.
Вторая — до 20 строк забагованного кода, нужно почитать и найти косяки (уже без документации).
Обе задачи вполне себе боевые, первая имитирует процесс разработки, вторая — кодревью.
За год я смог одобрить 9 человек, прошло через меня несколько десятков.
А резюме почти у все были хорошие. Многообещающие.
Зато многие кандидаты говорят, что это был их лучший собес за все время. )))dominigato
22.07.2019 21:27+7Если бы это делалось дома, я бы еще согласился. Но пока человек сидит под стрессом интервью, это никак не «имитирует процесс разработки». У вас все разработчики пишут сервисы под вашим пристальным взглядом и на время?
Интервью может быть только тогда репрезентативным, когда максимально имитирует рабочие условия, тогда вы можете экстраполировать и предположить что человек так и будет работать.
Хотя даже и это не панацея — я как-то брал работника и было все хорошо первые полгода, а потом оказалось что он не понимает что такое работа вообще. То есть делать что нужно на работе и что от тебя требуют — это как-то странно, нужно же делать что тебе хочется и интересно. Даже если результатов нет, главное — процесс. Кстати, технически он был подкован на все 100.
Вот такие вещи нужно на интервью узнавать, а не сортировку пузырьком. Я пузырьком научу за 10 минут, а работать человека уже вряд ли кто-то научит.moonster
22.07.2019 23:30+1У вас все разработчики пишут сервисы под вашим пристальным взглядом и на время?
Таки да. Сами при планировании дают оценки, а потоминогдаукладываются в них. Непосредственно во время разработки наблюдения нет, зато потом перекрестное code review проходят вообще все, разработчики, лиды, архитектор. Причем люди уже поняли, что тащить сомнительное себе дороже, если нужна ранняя критика — сами придут к коллеге и попросят взглянуть.
А вообще есть только один способ узнать, может ли человек работать — это нанять его и поработать с ним вместе относительно длительное время.
Менеджмент к такому не готов, потому что на большом и сложном проекте человек за испытательный срок не выходит на полную мощность, а после — его уже просто так не уволить.
Так что приходится идти на компромиссы.dominigato
23.07.2019 00:36+1При чем тут сроки и code review, вы же не стоите за спиной разработчика или занимаетесь микроменеджментом? Или пристально смотрите на него в течении всего дня, угрожая уволить если он сделает ошибку? Именно это и происходит на интервью и именно об этом был вопрос.
Стрессовое программирование, наверное, тоже требуемый навык где-то, правда мне трудно представить где. Но явно не в большинстве мест.
Гораздо вернее дать человеку сделать задание в комфортной для него среде и его рабочей атмосфере, в которой он и будет скорее всего работать. А потом уже можно обсудить им сделанное и отсюда танцевать, например.moonster
23.07.2019 01:22Не стою, не занимаюсь микроменеджментом, не грожусь уволить (да и не могу).
Но вы немножко передергиваете. Интервью не предполагает увольнения или наказания за «плохой код».
Это встреча двух профессионалов, которые должны решить, хотят ли они работать друг с другом, причем собеседуемый заранее знает, что от него будет требоваться.dominigato
23.07.2019 02:55+1Ну, если человек не проходит интервью — он не работает в вашей компании, это почти все равно что уволить (просто еще до работы). И отказ в вакансии очень немногие воспринимают радостно.
Поэтому обычно кандидат все-таки в менее выигрышной позиции на интервью, вам то терять нечего.
AlexeySoshin
25.07.2019 18:44Так домашние задания тоже не хотят делать :)
dominigato
25.07.2019 19:28А вы хорошо попросите :)
Задания тоже разные бывают. Мне тут недавно дали одно, которое взяло бы примерно недели две фул-тайм. Я, конечно, рад узнать новое и потренироваться, но блин, надо же совесть иметь. Я не могу взять отпуск только чтобы ваше задание делать.
Я в другом месте дали примерно на неделю по вечерам, и технологий много и довольно бесполезное, то есть не оставляет впечатления что ты работаешь забесплатно на это компанию. Вполне нормально
А то есть любители раздавать свои баги и проблемы в продакшне в качестве «домашних заданий».AlexeySoshin
25.07.2019 22:50Бывают и такие случаи, хотя боюсь представить, что там на две недели могли прислать.
Сам даю обычно написать сервис на три endpoint'а буквально: create/get/getAll
Persistence — как бонус. Даже тесты бонусом.
И все равно многие отказываются писать :)
VolCh
26.07.2019 09:26Из заданий, которые делал в последние годы:
- написать интерпретатор простого языка. Решил использовать наконец-то полученные кучу лет назад по теории трансляторов, все эти парсеры, токенайзеры, токены, AST и т. д. Бонусом было компиляция скрипта в LLVM
- написать простой CRUD на голом PHP. Применил по полной SOLID, продублировав частично PSR интерфейсы, создал adhoc DataMapper ORM+identityMap+UnitOfWork c детектором изменений (Doctrine/Hibernate like в общем), DI-контейнер и т. п.
- написать программу выявления десинка частот часов двух нод на ассемблере с очень ограниченным набором команд. Говорили что использовали систему команд каких-то реальных процессоров, но по ощущениям даже если так, то сильно порезали
Во всех случаях главное, что побудило согласиться их делать: задачи интересные сами по себе или легко делаются интересными, если не решать их в лоб. Всем остальным с тестовыми вроде "на хорошо известном фреймворке сделать CRUD веб-сервис с паблишингом событий в рэббит, и консьюмер, которые их тупо выводит консоль, но устойчивый к повторной отправке" отвечал "могу устно рассказать техспециалисту (задания давали рекрутеры) как их буду делать". По статистике соглашались на это на проектах с европейскими заказчиками, американские, израильские, японские и российские — нет: или решение, или "нам не нужны люди, которые вместо решения задач буду рассказывать как они их будут решать" (почти дословная цитата).
siziyman
22.07.2019 21:45+6Ну «разработать сервис и покрыть тестами» не звучит, как задача, влезающая в час-полтора, да. Неудивительно, если честно.
moonster
22.07.2019 23:23К сожалению, не могу раскрывать детали тестового задания, чтобы убедить вас.
Никто не требует от кандидата слишком многого.
Речь не идет о коде качества, достойного production. Сервис, который нужно сделать, имеет одну зависимость (с единственным методом), и сам тоже имеет единственный публичный метод. Протестировать нужно ровно те кейсы, которые упомянуты в требованиях, их три. Это много?
moonster
22.07.2019 23:41А вы не могли бы привести пример задачи на час — полтора, с учетом того, что решать будет сеньор и можно пользоваться IDE и документацией?
siziyman
23.07.2019 00:02Я не считаю, что любая практическая задача на час-полтора позволит надёжно отличить даже хорошо знакомого со стеком толкового джуниора (в моей системе координат) с годом-полутора практического опыта от сеньора. Это как раз больше про теоретические беседы, понимание нюансов и технических, и командного взаимодействия.
Беседа по существующему коду даст больше, например — ввести в приблизительный контекст, показать код, попросить найти проблемные места — совсем необязательно ошибки per se, просто "это выстрелит нам в ногу при описанных условиях". Поговорить о командной работе, понять, комфортно ли вам с таким человеком взаимодействовать, достаточно ли вы схоже понимаете процессы разработки.
moonster
23.07.2019 01:05Я не знаю, какой у вас стек и ЯП, может, у вас реалии другие. Но в Java джун редко хорошо знает стандартную библиотеку. Он может хорошо зазубрить ответы на стандартные вопросы, но с практическим использованием у него туго, допускает много ошибок, опыта мало. Даже если такой человек умен и схватывает быстро, я не могу его порекомендовать к найму.
Если кандидат на практическом уровне знает Java и JDK, способен реализовать тестовую задачу с многопоточностью, способен понять, какие тесты нужны и написать их — сеньор почти наверняка.
Вот описанная вторая задача — она как раз по существующему коду, ее сеньор за 15 минут решает, если на четверку знаком с языком программирования и имеет
некоторый опыт поддержки реальных приложений.
Было за все время два интересных кандидата — правильно решили задачу на кодинг (с документацией и гуглом), но не смогли решить на ревью. Оказалось — сеньоры, но язвк недавно сменили. Умели тесты писать, принципы многопоточки понимали, но еще плохо знали JDK.
Таким образом, сочетание задач позволяет с приемлемой долей вероятности позволяет отличать новичков в Java, мидлов и джунов от сеньоров.
0xd34df00d
23.07.2019 02:53Написать парсер json или чего-то json-подобного.
Наваять обёртку вокруг mmap, которая прикидывается pod-типом.
Написать свой std::any. Или optional.
На проектирование, увы, придумать сложнее.
moonster
23.07.2019 03:54Полноценный парсер JSON — боюсь, слишком круто для полутора часов, если в языке нет какой-то специфической поддержки и нельзя использовать сторонние библиотеки. Ну разве что какое-то подмножество покрыть можно.
0xd34df00d
23.07.2019 03:59Прям совсем полноценный — да, сложновато, но вполне значимое подмножество сделать можно. Голыми руками тоже (по крайней мере, если знать про PEG и просто на коленке сваять свою реализацию).
Skerrigan
23.07.2019 08:16Не сам парсер, но «инструмент выборки/обработки», близкий к полному, писал сам в 2014-ом, когда еще не знал про JSONPath… ну чтобы «как в jQuery все было» (по селекторам).
Году в 2017 гугл в поисковой выдаче выдал JSONPath и… весь мой код спокойно был пересажен на опенсорсную библиотеку, без правок на моей стороне (по селекторам). Я доволен :)
PsyHaSTe
25.07.2019 01:43Слишком специфично. Я вот парсер-комбинаторы никогда не писал. Да, представляю, после того, как почитал книжку по ФП и там это был один из примеров монадической структуры данных, но — не писал. Написать в первый раз на собесе может и смог бы, не знаю. Но качество боюсь было бы не лучшее.
Если у вас работа основана на обработке данныхи у вас это альфа и омега — то конечно я вам тупо не подхожу, и задача хороша. Но как генерик-задача для сферического сениора в вакууме — не очень.
grinCo
23.07.2019 05:58Я понимаю когда Гугл, Фейсбук, Эппл, ну или стартап с хорошей зп и долей так делают. Но когда обычная средняя контора со средними задачами, репутацией и зарплатой выделывается — это за гранью.
Я на такое ходил только чтобы потренироваться.
PS. Не знаю, может вы работаете и в одной из перечислинных компаний, тогда ок. Но описание не подходит.moonster
23.07.2019 18:59Я провожу собеседования только на свой проект, считаю, сложность некоторых реальных задач проекта значительно превышает сложность задач на интервью.
Не Гугл, Фейсбук или Эппл.
А средняя зарплата — это какая, по вашему мнению?grinCo
23.07.2019 20:18Я даже не знаю в какой вы стране, какие технологии используете. Поэтому среднее сказать не могу. и
Ну и ясно, что сложность реальных задач выше, чем сложность задачи с двухчасового собеседования.moonster
24.07.2019 03:21РФ, СПб, никаких супертехнологий, сплошной опенсорс — spring, activiti, drools, mongodb, ну и по мелочи всякое.
grinCo
24.07.2019 10:57Для РФ я могу только ориентироваться на исследования в интернете и те предложения, которые я получал оттуда. Поэтому я не могу считаться авторитетом в этом вопросе. 150К выглядит медианой для среднего синьера в СПб.
Я из Беларуси и мне кажется эта цифра слишком заниженной.
Вообще, я говорил о том, что работник в основном оперирует двумя параметрами — ЗП и технологии. Если на проекте он отстает от трендов, то это должно компенсироваться деньгами. Если идет впереди трендов, то можно некоторое время работать с ЗП ниже рынка, чтобы потом свалить на ЗП в два раза выше там где нужны эти технологии. Ну еще если это Гугл или Яндекс, то можно поработать там на средней ЗП чтобы получить строчку в резюме и иногда хороший опыт.
dominigato
22.07.2019 21:18+6Собеседования это единственное что плохо делают в ИТ и причем делают это хуже и хуже. Все таки для этого нужны какие-то базовые знания не только в технологиях, а и в психологии. Пока программисты будут собеседовать, ничего улучшаться не будет.
Это какой-то идиотизм что для интервью нужно готовиться, выпускают специальные книжки, ожидается что люди будут читать эти книжки, проходить курсы, а потом интервьюеры будут задавать вопросы по этим книжкам, получать отверы по этим книжкам и все будут довольны. То, что человек готов к интервью мы выяснили, а готов ли он к работе — это не столь важно, да и времени на это уже нет.
Я постоянно хожу на интервью чтобы не потерять скилл и быть в курсе последних веяний, и сам интервьирую постоянно. Положение — ужас, хотя может и не ужас ужас ужас. (Я помню времена когда на интервью надо было толпой лего собирать.) Полно неадекватных интервьюеров, случайный людей которых вообще к интервью нельзя подпускать, идиотские вопрос не имеющие отношения к реальности и работе, но зато повторяющиеся от компании к компании, как будто они все ищут в гугле «что задать на интервью если я вообще не при делах» и все открывают один и тот же первый линк.
Большинство как понимаю просто тупо повторяет то, что спрашивали их самих и сам процесс интервью, что только закрепляет идиотские традиции. Есть большая часть доморощенных «психологов», которые считают себя пупом земли и что они «знают жизнь и людей», и это вообще какое-то жалкое зрелище.
Про ХР я даже не говорю, дай бог если одну-две нормальных видел. Эти вообще все невежды и профессионализмом там даже и не пахнет. Так как они знают что ведут себя по-любительски и ничего не понимают в своей области, они еще пытаются скрыть это и просто докапываются до кандидатов всякими недо-психологическими трюками, прочитанными вчера в брошюрке «стань ХР за 2 минуты».
Раздражает тенденция интервьюеров спрашивать на интервью то, что они сами только вчера узнали, или даже так и не узнали толком. Зачем делать интервью, которое ты бы сам не прошел позавчера? Понтов накидать?
Вообще положение аховое, думаю надо открыть контору которая будет профессионально отбирать людей для вакансии, а компании надо будет только ознакомительнор интервью сделать. Так как похоже почти никто на рынке не умеет отбирать людей — ни гугл, ни амазон, ни банки, ни стартапы. У всех свои дебильные заморочки как оно должно быть, но никакого понимания даже и близко нет. Думаю всем было бы удачнее просто кидать жребий и так был бы больший шанс нанять лучшего работника.
Наболело.JediPhilosopher
22.07.2019 22:45Пока программисты будут собеседовать, ничего улучшаться не будет.
Примерно половина вайна на хабре про собеседования — про случаи, когда собеседуют не программисты, а всякие хрюши и прочие психолухи. Гениев от ИТ оскорбляет, что какой-то плебс, не разбирающийся в их специальности, почему-то решает их судьбу.
siziyman
23.07.2019 00:05Это было бы прекрасно, если бы всем нужно было одно и то же от сотрудника (что технически, что с точки зрения работы в команде, что просто по человеческим качествам), но это, очевидно, совершенно не так, и потому будут 3-5 разных моделей собеседований, и, внезапно, они все имеют место быть. Это нормально и не плохо.
dominigato
23.07.2019 00:46+2Общих точек сопрокосновения между кандидатами и работодателями на порядки больше, чем кажется по рынку. Вакансии могли бы закрываться в разы быстрее чем сейчас и получать людей намного более подходящих чем сейчас. Просто идиотские процессы найма в компаниях как-раз мешают этим точкам сойтись, из-за полнейшего непрофессионализма в данной области. Любое дело надо уметь делать и надо учиться уметь его делать, но почему-то многим кажется что умение интервьировать и набирать людей у них с рождения.
Впрочем кандидаты тоже тут не отстают и стараются как можно лучше спрятать свои лучшие стороны, требуя чтобы интевьюеры их вытащили телепатией. Ведь это же так унизительно — «продавать себя», что я вещь какая-то. Пусть к мозгу подсоединяются и узнают какая я замечательная личность, ничего я им не скажу добровольно.DrPass
23.07.2019 00:53Впрочем кандидаты тоже тут не отстают и стараются как можно лучше спрятать свои лучшие стороны, требуя чтобы интевьюеры их вытащили телепатией.
Вообще, многим и прятать-то нечего :) Процент бестолковых людей, он ведь примерно одинаков, как среди эйчаров, так и среди программистов.
chilicoder
22.07.2019 23:41+3У вас есть выбор
1) Ходите на собесы в нормальные конторы, где люди ищут себе коллег и готовы общаться по вашему опыту и проектам
2) Если хотите конкретно в Google, Amazon, Facebook, Netflix и тд прекратите ныть и примите их правила игры.
DrPass
23.07.2019 00:06Я вот один из тех, кто задаёт задачки на интервью :) И я не тупой эйчар. Я сам программист, сам ненавидел решать задачки на интервью, хотя и решал. Знаете, почему я их даю? Это не идеальный, но достаточный фильтр. Который:
1. Может не пустить хорошего специалиста, который теряется, когда испытывает стресс на собеседовании
2. Может не пустить хорошего специалиста, который, блин, вот сегодня сам забыл, как инвертировать бинарное дерево, и придумать не успел.
3. Может отпугнуть хорошего специалиста, который считает, что ему негоже решать такие задачки и вообще это жуткий моветон, а такой работодатель — отстой.
Но
4. Люди, которых этот фильтр пропустил, не теряются в стрессовых ситуациях, они не из тех, кто не сложит себе цену, и, блин, они реально умеют программировать!
Так что я буду задавать задачки и дальше. Я переживу, если упущу какую-то звезду, есть и другие звёзды.dominigato
23.07.2019 00:51+6Люди, которых этот фильтр пропустит, это люди которые уже прочитали книжку «крекинг какое-то там интервью», откуда вы взяли свои задачки и бинарные деревья, нарешали кучу задачек на хакеранке, откуда вы взяли свои задачки и бинарные деревья, и тд. и т.п. Они натаскались и могут без проблем пройти ваше интервью и это все что вы проверили.
То что они умеют программировать — это уже как повезет, может да, может нет. Никто ведь так и не узнал.DrPass
23.07.2019 00:55это люди которые уже прочитали книжку «крекинг какое-то там интервью», откуда вы взяли свои задачки и бинарные деревья, нарешали кучу задачек на хакеранке,
Прекрасно. Это именно то, что надо, вообще-то это и называется «уметь программировать» :)dominigato
23.07.2019 01:05+3ОК, значит у нас разные понятие что такое «уметь программировать» :)
Мне только интересно — сколько тасков у вас в компании содержат задачи на хакеранке и сколько задач на бинарные деревье в спринт? Сколько раз в день надо писать фибоначчи? Просто любопытство :)DrPass
23.07.2019 01:11Немного. Но есть одно «но»: человек, который умеет решать подобные таски, решит и любые другие. А человек, который не умеет, стушуется на первой же задаче, где надо мозгами пошевелить, а не писать в стопицотпервый раз однотипный и совершенно линейный код по сохранению данных с формы в базу.
Source
23.07.2019 01:24Но есть одно «но»: человек, который умеет решать подобные таски, решит и любые другие.
Вы прикалываетесь? Все бы тогда джунами обошлись, если бы учебные задачки позволяли решать реальные.
DrPass
23.07.2019 01:36Не прикалываюсь. Умение соображать ведь не единственное требование к программисту, который метит в миддлы и сеньоры. Знание матчасти ведь никто не отменял :)
PashaNedved
23.07.2019 02:06Умение
соображатьпроходить собеседованияDrPass
23.07.2019 02:33Умение соображать проходить собеседования
Я не могу себе представить человека, который сможет сочинить нехитрый алгоритм на собеседовании, и не сможет сочинить его в другом случае. Зато легко представлю человека, который не сможет сочинить нехитрый алгоритм на собеседовании, и вообще нигде не сможет. Вторых и повидал предостаточно.dominigato
23.07.2019 02:45Алгоритмов очень ограниченное число, алгоритмов которые спрашивают на интервью — очень ограниченное число. Вы очень недооцениваете подготовку и натаскивание на интервью, принимая заученное за какое-то знание.
Вполне может быть это грамотный человек, который на основе своего опыта и знаний придумал решение вот сейчас — тогда вам повезло.
А вполне возможно это профессиональный проходчик интервью, и вам не повезло.
Речь о том, что с вашим подходом вы никак не отличите одного от другого.
Я уже не говорю о других качествах, которые нужны человеку на работе, как адекватность, инициатива, способность к учебе и т.д и т.п. Которые кстати, гораздо труднее даются, чем задачки на хакеранке, которым даже обезьяну можно научить.DrPass
23.07.2019 02:54Алгоритмов очень ограниченное число, алгоритмов которые спрашивают на интервью — очень ограниченное число.
Откуда тогда в природе берутся те ребята, которые тест FuzzBuzz на собеседованиях не проходят?dominigato
23.07.2019 03:04Во-первых, я думаю их количество слишком преувеличено. Во-вторых есть и клоуны, я же не говорю совсем не проверять.
За 15 минут обычных вопросов можно уже с уверенностью сказать владеет ли человек какой-то областью, или каким-то языком. Если да и он не клоун, то после этого можно дать ему нормальное задание, желательно на то, в чем он не очень силен — чтобы проверить скорость самообразования, пусть вернется с ним и тогда уже отталкиваясь от его кода и вашего ТЗ задавать вопросы, задачи и т.д.
PashaNedved
23.07.2019 02:49Я не могу себе представить человека, который сможет сочинить нехитрый алгоритм на собеседовании, и не сможет сочинить его в другом случае.
Он угадал, ему повезло.
Именно эту задачу он знает, как решить.
Уже задавали подобную задачу на предыдущем собеседовании. Подготовился к вашей задаче, интересовался у тех, кто проходил собес у вас.DrPass
23.07.2019 02:55+1Отлично, если он так прошел собеседование, а решать задачи не умеет, я возьму его своим секретарём, и он будет для меня покупать лотерейные билеты. Я с таким везучим чуваком разбогатею и без необходимости писать софт.
pprometey
24.07.2019 07:38Я бы на месте этого соискателя не стал бы устраиваться к чуваку, который собирается разбогатеть покупая лотерейные билеты)
Source
23.07.2019 12:04+1И как из этого следует "решит и любые другие"? Другие задачи на то и другие, что они принципиально отличаются.
dominigato
23.07.2019 02:40Но есть одно «но»: человек, который умеет решать подобные таски, решит и любые другие
Это очень наивно так думать, мягко говоря. Как и в любых делах, люди подгоняют результат под определенный KPI. Так и здесь — они умеют решать данную задачку на хакеранке, вряд ли они ее сами и решали вообще. Но смогут объяснить вам где-то подсмотренное решение как свое, не проблема.
Никакого отношения к любым другим таскам это не имеет и умения другие задачи решать это не означает.
Не знаю зачем писать «код по сохранению данных с формы в базу.» на интервью вообще, но если это и есть ваши 90% тасков, то зачем вы спрашиваете про бинарные деревья, бектрекинги и т.д.? На тот единственный таск в год, когда понадобится что-то нестандартное, он что-нибудь нагуглит уже.
Мне хотелось бы провести опрос среди интервьюеров, на соотношение работы которая включает навыки, о которых они спрашивают на интервью и работы, которая не включает. Прям конкретно по вопросам: сколько времени потрачено в спринтах на задачи с обходами деревьев, фибоначчи, рекурсией, переворачиванием бинарных деревьев и т.д.
А сколько на вычищение легаси, составление докерфайла, изучение очередного АПИ с реверс инжинирингом, влезание в недра какого-нибудь линукс модуля, составлением хмл рамочки и т.д.DrPass
23.07.2019 02:53Это очень наивно так думать, мягко говоря.
1. Нельзя наизусть выучить решение задачи, не поняв «фишку» их решения. Вернее, можно, но это сложно, долго и непродуктивно. Вероятность встретить подобного «шулера» ненулевая, но ей можно смело можно пренебречь.
2. Я с 2010 года собеседую людей, с тех пор как получил свою первую команду. Этот критерий меня ни разу не подводил. Последний довод для меня в сто раз убедительнее всех ваших рассуждений, так что уж не обессудьте, но вы ошибаетесь :)
но если это и есть ваши 90% тасков, то зачем вы спрашиваете про бинарные деревья
Затем, что как раз те оставшиеся 10% тасков, которые требуют включения мозгов, определяют, насколько софт работает эффективно и надежно. Это не один таск в год. Речь не о тому, что программисту там нужно будет перебалансировать B-дерево или что-то отсортировать вручную. Но, например, у него не будет готовой библиотечной функции для быстрого расчета прогноза по складским остаткам, ему нужно будет составить эту страшную штуку под названием «алгоритм», которая учитывает различные стадии выполнения заказов продажи и закупки с определённой вероятностью.dominigato
23.07.2019 03:14Ну я собеседую как и вы с 2010, только меньше на программистов, больше на другие специальности, которые однако тоже требуют навыки программирования.
И я не настолько идеален как вы, я обжигался пару раз, когда брал основываясь в основном на техническую подготовку кандидата. С которым потом не знал что делать, потому что уволить после испытательного срока уже нелегко, а добиться от него результата просто невозможно. Теперь у меня техническая сторона на втором, если не третьем месте вообще. Сейчас я смотрю больше на человека и его потенциал и историю.
И та одна задача в год когда у него не будет библиотеки он пойдет и найдет ее, затратив неделю, а не один день как другой. Ничего, зато все остальные 360 дней он будет работать на ура, в разы лучше чем любой профессиональный задачник. А с высоким скиллом самообразования и мотивацией он эти алгоритмы уже будет щелкать через месяц, это все мелочи если голова есть.DrunkBear
23.07.2019 12:04Может, это проблема в задачах на испытательный срок?
Везде, где устраивался, в задачах были прописаны:
1. Получить допуски и прочитать доки
2. Реализовать и зарелизить фичу №1 ( с использованием половины тех.стека)
3. Реализовать и зарелизить фичу №2 ( используя оставшуюся половину технологического стека)
Итого: к концу испытательного срока я уже знаю весь процесс выпуска в прод, прошёл пару раз кодревью, у меня развёрнут и настроен git/svn/jira, я показал свои навыки по всему стеку технологий, с которым дальше буду (или не буду) работать, пообщался с командой — и здесь уже легко понять, нужны ли мы с этой командой друг другу или пора расставаться.dominigato
23.07.2019 12:17К сожалению не везде это возможно, очень зависит от места и задач. На том месте была такая специфика, что человек начинал выдавать что-то осмысленное только где-то через месяцев 5-6 после начала работы. Когда испытательный срок уже давно позади. И пока он учится нормально — претензий к нему особо и нет.
DrunkBear
23.07.2019 13:12Вообще не было задач, даже маленьких или парного программирования, для оценки человека?
Можете подсказать контекст таких работ, любопытно стало?dominigato
23.07.2019 13:26Финтек, биржи, очень много спеков биржевых протоколов, специфики биржевых инструментов и торговли. Там наверное больше финансам учились чем чему-то еще.
Плюс много легаси, больше легаси где я где-либо видел.DrunkBear
23.07.2019 15:10IMHO, можно было дать пару протоколов и посмотреть на их реализацию, по ней уже решать, в идеале — смотреть, что получилось за неделю и добавлять по кусочкам специфику на следующую неделю — к концу испытательного срока будет или неплохой продукт с нужными фичами, или осознание, что человек не подходит.
senglory
23.07.2019 15:49Нельзя наизусть выучить решение задачи, не поняв «фишку» их решения. Вернее, можно, но это сложно, долго и непродуктивно. Вероятность встретить подобного «шулера» ненулевая, но ей можно смело можно пренебречь.
Осмелюсь спросить, вы с китайцами или индусами дело имели? Судя по такой оптимистичной оценки веротности — скорее, нет.DrPass
23.07.2019 16:34Осмелюсь спросить, вы с китайцами или индусами дело имели?
Эээ, а причем тут китайцы или индусы? Я не в гугле работаю.senglory
23.07.2019 21:29Потому что среди них овердофига персон, способных «наизусть выучить решение задачи, не поняв «фишку» их решения». Просто потому что их миллионы несметные.
0xd34df00d
23.07.2019 02:59-1Не, ну.
Я умею считать скобочки. И даже умею генерировать скобочки. И даже без дубликатов, если задуматься. И с радостью докажу вам формально, что алгоритм корректен и тотален, и случайно (или нет) уведу разговор в матлог и теорию типов.
Но если вы меня таки наймете, а там придется писать перекладывалку данных из формата в формат, я в лучшем случае стушуюсь, в худшем — напишу на идрисе, с формальными доказательствами корректности.
symbix
23.07.2019 01:15Это работает для миддлов, но совершенно не работает для senior-ов. Когда я там в последний раз инвертировал бинарное дерево вручную? Лет 20 назад? Не, ну соображу, конечно, если буду сидеть за ноутбуком и писать в IDE, но у доски с маркером — вот не знаю, может, и нет. И при этом то, что действительно требуется от senior-а, это не проверяет вообще.
Я на скайп-интервью прошу расшарить экран и, да, даю задачки, но простые (такие, которые любой нормальный программист уж точно решит в уме за 2-3 минуты и останется только код написать), разрешаю пользоваться привычной IDE, гуглить что угодно, кроме решения задачи, и смотрю на то, как человек работает в привычных ему условиях. Из того, как именно он работает в IDE, как мыслит, как пишет код, как называет переменные и функции, как по коду перемешается, если гуглит, то на английском ли, — сразу все ясно.
Ну и, конечно, это все не отменяет беседы, это такой относительно короткий этап. Самое интересное начинается потом, когда я даю очень примерную постановку задачи и прошу спроектировать.
GDXRepo
24.07.2019 01:11Удивили. Впервые за все прочитанные комменты увидел правильный подход к собеседованиям. Правильное собеседование — это дать практически полезную задачу (не алгоритмическую, а что-то из реальных вещей), запихнуть человека в привычную для него рабочую среду и посмотреть, как он ее сделает, со всеми сопутствующими телодвижениями. Это и даст мало-мальски полную картину отношения к работе. Приятно видеть, что есть люди, кто это понимает.
symbix
24.07.2019 20:24Не, ну алгоритмы у меня, строго говоря, есть, но что-то совсем базовое. Рекурсия какая-нибудь. Уровня школьных уроков или FizzBuzz-а. Это не то, на что я смотрю, просто если человек на таком откровенно тупит (чуточку потупить это ок), то как бы тоже все ясно.
PashaNedved
23.07.2019 01:18Всем привет! Я сеньор-погромист, за 10 лет хождения по собесам я так и не научился сортировке пузырьком.
agalakhov
23.07.2019 02:26+1Умение решать учебные задачи не означает умения решать реальные, но неумение решать учебные задачи настораживает. Как минимум оно означает, что человеку не приходилось никогда учить программировать других, да и самообразованием на досуге человек не особо-то занимается. Мы встречали "сеньоров", у которых "сеньор" означает выслугу лет, а не скиллы, вплоть до того, что единственное умение человека — это много лет копипастить со stackoverflow (не преувеличение) и выдавать чужую работу за свою.
Задачи на алгоритмы, кстати, в жизни встречаются чаще, чем принято думать. Их просто часто не замечают — из-за плохого знания алгоритмов же. Решают в лоб, каким-нибудь полным перебором, вообще не подозревая, что есть более простой способ. Такая вот разновидность эффекта Даннинга-Крюгера.
JustDont
23.07.2019 09:24Задачи на алгоритмы, кстати, в жизни встречаются чаще, чем принято думать. Их просто часто не замечают — из-за плохого знания алгоритмов же. Решают в лоб, каким-нибудь полным перебором, вообще не подозревая, что есть более простой способ. Такая вот разновидность эффекта Даннинга-Крюгера.
Есть еще такие штуки, как понятность кода и границы применимости. Если вам надо обработать 10 элементов в худшем случае, то от того, что кто-нибудь очень «глупый» сделает эту обработку в лоб простым и легко читаемым способом за О(N!) — ничего важного для кода не изменится. Зато потом другие люди на этом месте не будут спотыкаться об код.
Нет ничего более печального, чем видеть лес красно-чёрных деревьев, который «ускоряет» работу кода, вызываемого один раз с 0.01ms до 0.005ms.agalakhov
23.07.2019 11:17+2На этот случай есть готовые библиотеки реализаций алгоритмов. Вот так, чтобы под простую вещь не было приличной готовой реализации — это редкость. Обычно есть, но не находят, потому что не знают даже названий алгоритмов, а без названия фиг нагуглишь.
А еще часто бывает, что сам "алгоритм" — он в одну строчку и даже проще пишется, чем лобовое решение. Тут как раз показывали пример "найти недостающее число". Умный просто просуммирует числа и вычтет, а глупый начинает сортировать. Или, скажем, алгоритм суммирования Кэхэна, который экономит в первую очередь память по сравнению с алгоритмами, основанными на сортировке, а пишется тоже проще.
Самое печальное, что приходилось видеть — это когда говорили "ой, да у меня 10 элементов в худшем случае", а потом оказывалось, что 20 ("всего-то в два раза ошиблись"), а потом "ой-ой-ой, а что это оно зависло?" (ну правильно, 10! и 20! — как бы некоторая разница есть). А потом появляются посты про то, как плохо написан софт, что за время обновления винды можно было бы ее трижды с нуля переставить. Это ведь вот оно и есть.
Типичный пример выглядит так: вот надо человеку пробить строки по черному списку. Кто в курсе, тот понимает: "ага, тут подойдет Ахо-Корасик", расчехляет готовую библиотеку и решает задачу в две строки. Кто не в курсе, пишет for и получает там же 100 строк, да еще медленно работающих. Когда приходит жалоба ("тормозит"), начинает "оптимизировать" эти строки (ну профилировщик же на них указывает!) и "оптимизирует" до тех пор, пока не начнет глючить. В нашей практике был случай, подобный плохо написанный код год (!) пытались исправить, прежде чем согласились, что вывести и доказать алгоритм было бы быстрее (на митинге тогда говорили "да ну, мы сейчас за два дня пофиксим, а алгоритм две недели писать будем").
Решение не писать алгоритм должно происходить из знания алгоритмов. Алгоритм знаю, готовый поискал, подходящих не нашел, решил сделать субоптимально. Еще и с комментарием в коде: "Если вдруг начнет тормозить, то вот здесь переделай O(N!) на O(N), алгоритм называется так-то."
Fedorkov
23.07.2019 11:41Кто не в курсе, пишет for и получает там же 100 строк, да еще медленно работающих.
Кто не в курсе, гуглит %framework_name% multiple substring search.
michael_vostrikov
23.07.2019 21:42Типичный пример выглядит так: вот надо человеку пробить строки по черному списку
ага, тут подойдет Ахо-КорасикТипичное решение выглядит так:
Вариант 1
SELECT * from black_list WHERE value IN (...)
Вариант 2
$hashTable = array_combine($blackList, $blackList); $rowsFromBlackList = []; foreach ($rows as $row) { if (isset($hashTable[$row])) { $rowsFromBlackList[] = $row; } }
Работает не медленнее любой другой обработки данных, которая может встречаться в приложении.
DrunkBear
24.07.2019 09:36Первый вариант — типичное медленное решение при больших объемах таблицы и / или большом количестве строк для проверки в in ( а в случае с mssql + запросом размером больше 8 кб — не работающее).
Не проще ли создать временную таблицу с value_hash, заполнить её хэшами и сделать inner join по value_hash?
В самом ленивом случае — добавить триггер on after insert, который сам будет хэшировать value во временной таблице.
C индексом по value_hash этот вариант переживёт и 10, и 10! значений для проверки.
PS для варианта с небольшим черным списком, который не расширяется и не будет расширяться — подойдёт любое решение.
SELECT b.* from black_list b inner join value_hash_tmp t on b.value_hash=t.value_hashmichael_vostrikov
24.07.2019 11:40Можно, но только после практической оценки производительности, иначе будет усложнение, которое ничего не дает.
agalakhov
23.07.2019 11:23BTW, если каждый код, который вызывается один раз, ускорить с 0.01ms до 0.005ms, это даст двукратный рост производительности программы в целом. Для этого вовсе не надо переписывать сотни алгоритмов, так как алгоритмы обычно повторяются, и достаточно нескольких хорошо написанных дженериков. (И очень странно, если их приходится писать самому, обычно все уже написано до нас.)
JustDont
23.07.2019 13:24BTW, если каждый код, который вызывается один раз, ускорить с 0.01ms до 0.005ms, это даст двукратный рост производительности программы в целом.
Который может быть нафиг никому не нужен, потому что дальше вам результаты работы ваших 0.005ms надо переслать на другой конец мира с latency минимум в 500ms в идеальнейших условиях.
Сам по себе «рост производительности программы» не имеет значения. Да хоть тысячекратный. Зато очень даже имеют значение усилия, которыми это будет достигнуто: если вы ради этого написали так, что ваш код плохо понимают коллеги, резко упал bus factor, и надо нанять второго спеца вашего уровня только для того, чтоб проект не встал, если вы уйдете — это всё имеет выразимую стоимость в деньгах. Тысячекратное ускорение, если имеющейся скорости было достаточно — не даёт ничего.agalakhov
23.07.2019 18:35Дает упрощение архитектуры. Если удалось добиться тысячекратного ускорения, то решение можно не параллелить, кластер не нужен, многопоточность не нужна, никаких сетевых латентностей нет, так как система просто перестала быть распределенной. Можно сократить подразделение IT, можно выкинуть из кода все, что отвечало за параллельность и сократить программистов, которые эту параллельность поддерживали. Пара спецов, способных сделать 1000-кратное ускорение, точно окупится по сравнению со всем этим.
JustDont
23.07.2019 18:58+1Я повторю еще раз, сам по себе рост производительности не имеет значения. Вы напридумывали дополнительных вводных для того, чтоб придать этому смысл. Но этих вводных может и не быть.
PsyHaSTe
25.07.2019 02:01Оптимизация обычно выливается в усложнение, а не упрощение. Просто потому что по-определению программист изначально пишет максимально простым способом, который знает, и любое изменение ведет очевидно к усложнению.
VolCh
25.07.2019 06:26Очень разное понимание сложно или нет бывает с одной стороны, а, с другой, многие стараются писать универсально и/или обобщенно.
wataru
23.07.2019 12:46Соглашусь с ответом Вам выше: Часто наивный полный перебор длиннее и непонятнее умного алгоритма. Сам с таким кодом встречался. Рекурсивный перебор был 100 строк сильно запутанного кода, когда как весьма простое динамическое программирование было всего 20 строк, из которых 5 — комментарий, полностью описывающий все происходящее, что даже человек ни разу в жизни не видевший ДП, мог бы нагуглить и все понять.
JustDont
23.07.2019 13:28Часто наивный полный перебор длиннее и непонятнее умного алгоритма.
А часто — наоборот.
Выше «автор ответа мне» рассуждает про алгоритм Ахо-Корасика, который, например, если только не будет вызываться в одну строку из чужой либы, будет весьма так длиннее банального перебора через for.wataru
23.07.2019 15:15Ахо-корасика писать не надо — он уже 100500 раз написан в библиотеках. Но знать, что есть какой-то алгоритм поиска среди набора строк, который работает сильно быстрее чем цикл for — надо.
Я же говорил про динамическое программирование вместо полного перебора. Обычно это замена сложной рекурсивной функции двумя-тремя вложенными циклами с несколькими простыми арифметическими операциями внутри.
agalakhov
23.07.2019 18:44А если вдруг почему-то не написан, то стоит написать и опубликовать. Суммарные трудозатраты на один книжный алгоритм будут меньше, чем на все места, где его можно применить в проекте. В пределах одной предметной области задачи обычно довольно похожи, поэтому алгоритм можно применить, скорее всего, не раз и не два.
Особо гадкий случай — это когда делают "по-простому" через if-else, а потом годами растет простыня этих if-else, по одной веточке добавляют. Со всякими парсерами сложных конфигов или сетевых протоколов так бывает. Сразу бы написали на каком-нибудь LL — сэкономило бы буквально месяцы потом.
PsyHaSTe
25.07.2019 02:03Ахо-корасика писать не надо — он уже 100500 раз написан в библиотеках. Но знать, что есть какой-то алгоритм поиска среди набора строк, который работает сильно быстрее чем цикл for — надо.
Ну я вот не знал, я бы просто делал поиск в цикле по хэшсету. Работать за линию от входных данных вроде ок. Если бы вдруг этого не хватило, уверен в первой строчке гугла я бы нашел что мне нужно.
Когда я пилил бота для определения боянов в телеграм-канале до использования хэша цветового момента изображения я ведь как-то догадался, хотя до этого никогда с изображениями не работал. А вот на собесе бы не ответил.
AlexSky
23.07.2019 22:55+4О, да. Сколько я таких встречал. Приходит юноша бледный со взором горящим и начинает лепить самописные хеш-таблицы на десятиэлементный массив, втыкать likely в каждый if, одновременно накручивая по пять слоев абстракции "на будущее". А потом выясняется, что он захреначил древовидную шареную структуру без единого примитива синхронизации и на голубом глазу сообщает, что оно будет работать "само по себе". После объяснения, что не будет (началось с того, что полезли плавающие баги), втыкает биг факин лок на всю структуру, так как времени на нормальный редизайн уже нет.
У нас для этих товарищей уже даже название закрепилось — би-дровосеки (родоначальники запилили самописные би-деревья для какого-то коротенького списка).
Druu
24.07.2019 09:44Как минимум оно означает, что человеку не приходилось никогда учить программировать других, да и самообразованием на досуге человек не особо-то занимается.
Каким образом обучение программированию и самообразование связано с решением учебных задач?
Решают в лоб, каким-нибудь полным перебором, вообще не подозревая, что есть более простой способ.
Какой способ может быть проще, чем перебор в лоб?
Тут как раз показывали пример "найти недостающее число". Умный просто просуммирует числа и вычтет, а глупый начинает сортировать.
Задача программиста при написании кода состоит, в первую очередь, в том, чтобы объяснить другому программисту, что происходит в программе и зачем.
Так что вариант с сортировкой почти всегда более предпочтителен — сразу понятно что делается, в отличии от варианта с суммой, который понадобится откровенно декомпилировать, чтобы понять.
sergey-b
23.07.2019 03:07Я каждому кандидату, даже тем, кто мне не понравился, даю на дом решить одну задачу, трудоемкостью часа на 3, но без ограничения по времени.
Затем я полученное решение проверяю часа 4, выдаю кандидату список замечаний. Даже если задача сделана прям идеально (хотя такого не бывает), я чего-нибудь напишу по принципу "почему без шапки". Затем по телефону, или на 2-й встрече мы все эти замечания с ним вместе обсуждаем.
Хорошее предложение получает тот, кто в состоянии на профессиональном уровне обсудить свой собственный код, объяснить почему выбран тот или иной алгоритм, признать косяки, если такие нашлись, рассказать, как надо было сделать правильно.
Такой подход дает хорошие результаты, но чрезвычайно трудоемок.
dominigato
23.07.2019 03:16Затем я полученное решение проверяю часа 4
В смысле? Сидите с кандидатом и проверяете вместе? Почему 4 часа?sergey-b
23.07.2019 03:19Нет. Решение соискатель выкладывает из дома куда-нибудь на гитхаб. 4 часа требуется мне, чтобы все проверить и написать развернутые комментарии.
dominigato
23.07.2019 03:27Не легче давать комментарии и спрашивать вопросы по ходу проверки, когда вы с кандидатом? Ну, хотя бы после быстрого ознакомления до этого.
Писать 4 часа комментарии по-моему не очень продуктивно, если это задача на интервью с человеком, который может быть и не пройдет его.sergey-b
23.07.2019 03:444 часа это все вместе. В задаче есть простор для фантазии, поэтому мне некоторое время приходится потратить на настройку своего теста. Иногда, когда в программе есть race condition, я свой тест дорабатываю, чтобы наглядно продемонстрировать ошибку, а не метать бисер. Написание замечаний — это последний час, как правило.
Процесс, как я говорил, трудоемкий. Но я параллельно решаю задачу, чтобы, если человек стоящий, он захотел со мной работать. Чтобы он не только за деньги у меня работал, а за возможность узнать что-то новое и повышать свой профессиональный уровень.
sergey-b
23.07.2019 03:21Иногда быстрее проходит. Когда код заурядный, я беру список замечаний к самым косячным решениям и выкидываю оттуда лишнее.
xPomaHx
23.07.2019 07:22Это нереал бесит когда нет фидбэка сразу, представьте сколько человек проходит собесов и на каждом дают такие тест задания, например я спокойно прохожу 10 скайп бесед в неделю, и сразу говорю, что тестовое тока после общения с тех спецом, и что в нем есть смысл, обычно это понятно и так, потому что 10*4 это полная неделя рабочая у меня нет столько времени на это.
sergey-b
23.07.2019 07:56Да вы что. Обычно вообще никакого фидбека нет. Спасибо. Мы вам позвоним. Даже если возьмут на работу, фидбека, скорее всего не будет.
Skerrigan
23.07.2019 08:31Помнится был такой случай, что фидбек не получил на следующий день (как договаривались). И почему-то черт дернул «недовольство выразить в устной форме по телефону». Не удалось — когда подняли трубку, то дальше была реплика со смыслом «эм, а, это вы, мы про вас забыли… приходите на работу». Даже не знаю что сказать после этого.
vvbob
23.07.2019 09:32Увы, даже в приличных вроде-бы фирмах это сплошь и рядом. Просто после интервью молчание.
PsyHaSTe
25.07.2019 02:05+1Даже если задача сделана прям идеально (хотя такого не бывает), я чего-нибудь напишу по принципу "почему без шапки".
Пожалуй, к вам бы я не пошел.
sergey-b
25.07.2019 02:28Почему? Не воспринимаете критику?
PsyHaSTe
25.07.2019 02:32Только аргументированную. И когда "код написан идеально", а критика есть, значит это неаргументированная вкусовщина.
sergey-b
25.07.2019 02:50На мой взгляд, идеального кода не бывает. Но даже если кто-то думает, что он такой код написал, он должен уметь обосновать эту оценку и аргументированно отвергнуть придирки, а иначе от его перфекционизма будет мало толку.
PsyHaSTe
25.07.2019 03:05Между "задать вопросы по коду" и "докопаться до запятых, потому что в остальном с кодом все ок" есть некоторая разница.
sergey-b
25.07.2019 03:18-1Э-э-э. Вы не поняли фишку. Это психологический прием. Чувак написал идеальный код. Ждет заслуженную похвалу. А вместо этого бац: "Почему импорты со звездочками?" Его переполняют эмоции. Он вместо того, чтобы спокойно выбирать между похожими оферами, сидит и думает, как же это возможно. И тут ему предлагают все замечания конструктивно обсудить, обсуждают, у него появляется возможность проявить свои софт-скиллы, он побеждает в деловом споре, и позиция в нашей команде для него начинает ассоциироваться с победой.
PsyHaSTe
25.07.2019 03:52+1Я и говорю, дешевый психологический трюк, ориентированный непойми на кого.
Еще раз, вот допустим я вам скинул решение, если вы присылаете критику в стиле "а у вас тут запятые и пробелы неправильные" то мне не будет интересное предложение их конструктивно обсудить, потому что видно, что человек в неадеквате. И нет, я не буду мучиться бессоницей, чтобы понять, что не так у меня с запятыми. Слава богу, рынок достаточно велик, и вакансий на любой вкус хватает. А где не хватает, всегда можно по знакомым поспрашивать, где-то всегда вот уже вчера нужна голова для решения каких-то проблем.
Если у вас есть замечания к коду — отлично, обсудим. Докопаться до нормального кода чтобы развести человека на лишние разговоры — какие-то дешевые СЕОшные методики продвижения вакансий. Не знаю как остальные, а я и спамеров не люблю.
Druu
25.07.2019 05:46+1Вы сейчас целую историю рассказали, про то как и чего у потенциального кандидата в голове. Вот только к реальной голове реального кандидата она никакого отношения не имеет, беда-с.
Fedorkov
25.07.2019 08:19он побеждает в деловом споре, и позиция в нашей команде для него начинает ассоциироваться с победой.
Если человек действительно умнее вас, он сразу почувствует попытку манипулировать им, сделает фейспалм и уйдёт.
Heian
23.07.2019 07:31Почему Senior Developer'ы не могут устроиться на работу
Потому что они навесили на себя сеньерскую лычку и сеньерскую же зп после первого крупного проекта в качестве миддла, имея за плечами 1-2 года опыта и задрав нос? Пример из жизни, который, тем не менее, нашел себе работу
P.S. Статью не читалWhite_Scorpion
23.07.2019 15:19+1А если у меня опыта программирования с 2004 (это только профессиональный — без учёта институтских проектов), два раза минимум на меня навешивали "сениорскую" лычку, но я вот за 3 строчки сходу, как тут в комментах кто-то писал, не заинверсирую бинарное дерево — я от этого перестаю быть сениором?
С другой стороны, меня можете хоть джуниором звать — главное чтобы деньги хорошие платили.
P.S. Мож и заинверсирую — лень пробовать :).
OvkHabr
23.07.2019 07:40А я был поражен одним собеседованием в корпорации на «Аналитика с навыками разработчика».
Не проверяли вообще ничего. Всему верили на слово.
Примерно так:
— Вы говорите на китайском?
— Да. Поговорим по-китайски?
— Нет, зачем? (Ставит плюсик)
А ещё я заметил, что хорошо прохожу собеседования в мелкие конторы, где собеседует сам гендир/собственник. И проваливаю собеседования, где присутствует Hr, начальник отдела и пара ведущих специалистов.
FluktLight
23.07.2019 07:40Было у меня одно собеседование сначала предложили решить задачку про Волка, козу и капусту, когда я прервал того кто проводил собеседование, и закончил описание задачи вместо него мне предложили другую задачку на отмеривание времени с помощью неравномерно горящего фитиля…
По словам проводящего тест, это был тест на логическое мышление…
Хотя это и неудивительно, учитывая моих бывших одногруппников…
ohyou
23.07.2019 07:40В небольшие компании устроиться не проблема, обычно собеседования довольно техничные и часто просто обсуждается опыт и всякое такое.
Настоящие проблемы начинаются уже после выхода на новую работу. Когда с первого дня видишь, какие проблемы в менеджменте, как команда общается с тимлидом, как тимлид общается с «кем-то выше него», как поступают задачи, как сдаются задачи, и тд. В больишнстве случаев, за неделю можно примерно выявить, почему «ушел» прошлый сеньер.
Кстати очень помогает на собеседованиях совет, который вычитал на хабре когда еще был джуном: у техлида (или лица, который представляет «техлида» на собеседовании) спрашивать вопрос типа «как к вам поступают задачи, как вы их распределяете, и как вы их сдаете». Прошу заметить — спрашивать не у ПРа/ПМа, а именно у техлида. По ясности их ответа можно сразу очень неплохо прикинуть, как у них обстоят дела внутри.
В «хороших» компаниях (у которых всё нормально обстоит внутри) этот вопрос никогда не вызывает сложностей. И обычно техлид до мелочей может пересказать весь воркфлоу.
В «плохих» компаниях ответ выглядит как-то так: ну, у нас етсь ютрак, и в нем есть задачки, и разработчики их берут и решают.PsyHaSTe
25.07.2019 02:09Что если флоу правда состоит в том, что ПО создает задачки в ютреке, которые техлид потом декомпозирует?
ohyou
25.07.2019 11:32Тогда рано или поздно возникает подобная проблемная ситуация:
Появляются задачи рода «не думай, просто сделай, так надо», которые делаются через одно место т.к. нет понимания глобальной задачи, а потом еще рефакторятся несколько раз из-за отсутствия понимания вектора дополнительных требований по данной задаче. Плюс такие задачи очень неприятно делать, появляется отстраненность от процесса. Будто ты фрилансер и тебе закинули задачку, а не часть команды разработки.
Не спорю, что так построить работу невозможно, но меня бы такой воркфлоу очень сильно насторожил. Я бы спросил несколько деталей прежде чем делать вывод, но поворот в не ту сторону уже был бы сделан.PsyHaSTe
25.07.2019 15:48Появляются задачи рода «не думай, просто сделай, так надо»
Как это связано с задачами в ютреке?
Плюс такие задачи очень неприятно делать, появляется отстраненность от процесса. Будто ты фрилансер и тебе закинули задачку, а не часть команды разработки.
Посмотреть на эпик, поговорить с лидом, поговорить с ПО не поможет?
yuliaazak
23.07.2019 07:40Почему не оценивают по портфолио? Если кандидат может показать свои законченный проекты и объяснить логику (доказать, что это его/ее код), разве этого не будет исчерпывающие?
VIkrom
23.07.2019 08:19Проекты работодателей показывать нельзя, а своих может не быть.
dvmedvedev
23.07.2019 08:48Встречал компании, для которых отсутствие собственных завершенных проектов причина для отказа.
glestwid
23.07.2019 20:16+1Поделитесь, плиз, названиями этих понторезов.
PsyHaSTe
25.07.2019 02:10Смотря что такое завершенный проект. Если телеграм-бот который умеет по команде гифки в канал кидать то не такие уж это понты. За 5-10 лет работы наверное у любого разработчика появлялось желание и возможность реализовать хоть что-нибудь.
gohan
24.07.2019 00:22Проекты работодателей показывать нельзя
А мне пофиг, просто покажу проект со своего ноута, когда придётся собеседоваться. Передавать на сторону ни одного байта не придётся, текущий работодатель не пострадает.
Ещё могу показать полный лог своей работы за несколько лет в виде задач на каждый день и всяких пометок к ним. Там нет чувствительной информации. Правда, понадобится русскоязычный сотрудник в нанимающей фирме.vvbob
24.07.2019 00:36Сколько из того проекта именно вашего кода?
Вот я пришел на новую работу, запилил уже два-три модуля, они уже обросли кодом от коллег, я сам уже без гита не скажу где там мой код, а где не мой. В любом более-менее большом проекте так.
ИМХО гораздо адекватнее на собеседовании попросить претендента рассказать о задачах, которые он решал, пообщаться с ним. В сущности таким простым разговором можно получить довольно адекватное впечатление о человеке как о профессионале и как о человеке вообще. Насколько адекватен в общении, что знает, что умеет. Да и такое интервью обычно проходит с самым низким уровнем стресса.
vvbob
23.07.2019 09:31Ну я вот, к примеру, уже, страшно подумать, почти 20 лет программирую, вроде бы считаюсь вполне себе неплохим синьором (по крайней мере з/п соответствующую получаю), а никакого «портфолио» у меня нет. Весь написанный мной за последние лет десять является собственностью разных организаций и я не имею права выкладывать его в общественный доступ, а пилить что-то на стороне в качестве хобби у меня нет ни времени ни желания, предпочитаю хобби никак не связанное с программированием.
Как правило портфолио есть у фронтов, там сама суть кода в том что его не спрячешь или у вчерашних студентов — пока еще не работаешь где-то серьезно — есть время и желание пилить проекты по фану.
lanseg
23.07.2019 09:24Раз уж тема снова всплыла, то оставлю свою историю о собеседовании, которое неприятно поразило меня больше всего.
Задал мне собеседующий простую олимпиадную задачку и стал равнодушно пялиться в свой ноут. Я начинаю рассказывать, как и что я делаю, обосновывать своё решение, а собеседующий — ноль внимания. Когда я решил задачу, он мельником на неё взглянул и бросил "Квадрат, не пойдёт!", а ведь я объяснял, почему я делаю за квадрат и как потом буду улучшать.
Решил задачку за линейное время, показываю ему, а он — "Ладно. Так… у вас ошибка" и снова смотрит к себе. Оказалось, я пропустил проверку на граничные условия, но упомянул о ней вслух.
Кое-как завершил собеседование, но так и не понял, что это было — недавний олимпиадник? Педант, для которого неверными будут все решения, кроме оптимального? А если бы у меня так же спрашивали задачу "на сообразительность", я бы просто ушёл.
Из российских компаний самое адекватное собеседование было у Jetbrains, но я довольно халтурно подошёл к решению домашней задачки, потому что уже почти был готов оффер от гугла — возможно, та команда решила, что я ленивый раздолбай. Да и мог бы нормально слиться и не тратить зря их время — тогда было очень стыдно.vvbob
23.07.2019 09:38Из Джетбрейнс когда слал туда «резюму» даже не ответили ничего, тупо проигнорировали. Довольно неприятное отношение, почему-то мне не в лом написать ответ на приходящие письма от HR, даже когда вижу что они довольно типовые и человек не особо заморачивался написанием.
Kobalt_x
23.07.2019 10:31+1>Задал мне собеседующий простую олимпиадную задачку и стал равнодушно пялиться в свой ноут.
Не оправдываю собеседующего но могу объяснить почему так происходит.
Потому что внезапно во время собеседования ему ещё нужно вести полный протокол с таймстампами вида начал решать в 12:00 задал первый вопрос тогда-то, тогда-то вручил первое решение во столько-то. И да замечаю что обычные комментарии вслух мало кто слушает, вот задаете вопрос а какие ограничения, тогда говорят… обычно это бывает либо на phone-секциях или секциях с кодом на листке, когда код на доске там уже точно будут смотреть.
Почему они так делают тоже объяснить просто, потому что после собеседования лениво заполнять отчет выдумывая таймстампы и прочие вопросы из головы и тратить на это время, а хочется просто работать. поэтому сидят и заполняют прямо на месте.lanseg
23.07.2019 10:45+1В этом и проблема — как можно оценить качества кандидата, если не слушать его рассуждения? И это было на личном собеседовании, причём, было ещё четверо собеседующих и все они слушали пояснения, иногда задавали уместные каверзные вопросы.
Понять причины такого поведения можно, но вот считать его нормальным — точно нет.lanseg
23.07.2019 18:07Забыл уточнить, что было 4 собеседования, конкретно на этом собеседующий был один.
White_Scorpion
23.07.2019 10:26+1К тому же я слышал о собеседованиях, где кандидат вообще не умел программировать (не мог написать программу типа hello world)
Я Senior программист на C#.NET стеке и я… не напишу Hello World сходу.
Нет, если поставить задачу:
- Создать новый шаблон Console Application в Visual Studio 20XX
- Найти функцию Main вписать туда Console.WriteLine("Hello, World!"):
То с этим я вполне способен справиться.
Но если есть пустой файл документа (а некоторые умники вообще листок бумаги подсовывают), на котором надо написать всё без шаблона солюшена, автоподсказки и Intellisensa… то я скорее всего подвисну. Потому что точно помню, что класс program может быть без спецификатора доступа, а Main должна быть статичной… Но обязательно ли туда параметры вставлять или это опционально? Или какие там надо было namespace вписывать, чтобы всё заработало? System хватит или что-то ещё надо?
Я думаю — суть понятна.
Программисты уже давно переложили на IDE огромное количество рутины и теперь, когда подсовывают бумажку и предлагают напиши "Hello World!" от руки — это вводит в ступор. А они всё предлагают и предлагают бумажки.
P.S. Ну и я не отменяю иронии парадокса, что людей, которым на собеседовании подсовывают "напиши Hello World" — надо решать СОВСЕМ ДРУГИЕ задачи.
Как написание "Hello World!" коррелирует с задачей создания оптимальной архитектуры приложения или оптимизацией рабочих процессов — сие есть загадка неведома есьм.PsyHaSTe
25.07.2019 02:24Ну не знаю, имхо это базовые вещи. Напоминает статью про сениор сишарп разработчика, который не ответил зачем нужен кейворд virtual. Не, ну вопрос джунский, это очевидно, но люди почему-то забывают, что сениор по сути это надмножество джуна. Любую джуновую задачу сениор должен решать, причем сходу и максимально корректно. Да, он не должен этим заниматься, потому что во-первых недозагрузка интересными задачами сильно надоедает, а во-вторых потому что это тупо дорого. Но уметь он должен. Неужели от понимания как настроить шардирование и при каком виде нагрузки класс лучше спроектировать лок-фри или на простых локах человек может забыть то, что он ежедневно набирает?
Да, IDE помогает, но мозг она при этом не заменяет. Что мешает на бумажке написать:
svm { Console.WriteLine("Hello world!"); }
А интервьюверу объяснить, что это сатнадртный класс объявления входной точки в Visual studio? Раз вы эксперт в IDE то должны это знать. Если же человек не может хелло ворлд ни на бумажке, ни в IDE написать, то это достаточно грустно, пусть и не имеет прямого отношения к реальным задачам.
В какой момент времени стало модным невежество? "Я не знаю как работает гц, это пусть джуны учат". "Какие там модификаторы доступа? Я же сениор, мне это знать не обязательно". "Что такое SOLID? Спросите чего поновее".
Ну то есть вопросы тупые и очевидные, но они тупые потому что любой человек считающий себя разработчиком обязанть знать эти ответы. Это все равно что спросить физика-ядерщика что будет с шариком, который толкнули в невесомости, в отсутствие других сил. Он хоть и давно в школе учился, но законы Ньютона вполне себе помнит.
Теперь когда берем сениора и спрашиваем его что-то из основ он высокомерно изгибает бровь и говорит что это дело плебса знать такие нюансы.
White_Scorpion
25.07.2019 08:39svm
{
Console.WriteLine("Hello world!");
}
А интервьюверу объяснить, что это сатнадртный класс объявления входной точки в Visual studio?Что это за магия? Первый раз такое вижу. Гугл пишет, что это некая библиотека standard vector machine и Visual Studio требует устанавливать это отдельно посредством NuGet.
Вы уверены, в том что вы написали?Source
25.07.2019 11:39Это "static void Main" сокращенно, для тех, кто помнит что надо написать, но ему лень :-)
VolCh
26.07.2019 07:03любой человек считающий себя разработчиком обязанть знать эти ответы
С тех пор как я узнал про SOLID, я всё меньше знаю что это. У меня нет однозначного ответа что такое, например, SRP. Вот полноценный объект, в котором есть и данные, и методы их обрабатывающие, и изменяющие — у него две ответственности или одна? Это без учёта самих данных и методов. Вот создаём объект с публичным свойством, инициализируем его в конструкторе. Понятно, что одна — хранить это свойство. Или две уже — дать клиентам возможность его изменять? Создаём геттер — добавляем ли ответственности за доставку клиентам значения свойства? А за защиту этого свойства?
PashaNedved
26.07.2019 07:59Полное и исчерпывающее руководство по SRP
Принцип SRP можно применить только в том случае, когда:
объекту класса становится позволительно слишком много;
доменная логика концентрируется только в одном классе;
любое изменение логики поведения объекта приводит к изменениям в других местах приложения, где это не подразумевалось изначально;
приходится тестировать, исправлять ошибки, компилировать различные места приложения, даже если за их работоспособность отвечает третья сторона;
невозможно легко отделить и применить класс в другой сфере приложения, так как это потянет ненужные зависимости.
vvbob
26.07.2019 09:15ИМХО, я это так понимаю.
Нужно различать ответственность и действия. Когда описываем объект, в графе: «Объект отвечает за» — должно быть одно значение, а не перечисление. В графе: «Для обеспечения ответственности объект делает»: тут может быть сколько угодно пунктов, главное что-бы все эти действия были подчинены одной единственной ответственности.
Разумеется, тут как и в большинстве принципов все до предела формализовать не получится, любую ответственность при желании можно разбить на части, тут все отдается на откуп здравого смысла исполнителя, потому что доведением до абсурда любой толковой идеи, можно превратить код в нечитаемый лабиринт из паттернов, ломающийся от любого небольшого изменения.
PashaNedved
25.07.2019 11:14Но обязательно ли туда параметры вставлять или это опционально?
Математика 9 класс.
Я думаю — суть понятна.
Не совсем. Задача настолько сложная, что сеньору нужна IDE для решения этой задачи?
Это конечно сарказм, но с другой стороны интервьюеру стоит принять во внимание, что у сеньора возникают трудности в решении такой простой задачи. Это может быть как вопрос квалификации, так и вопрос психологии.
предлагают напиши «Hello World!» от руки — это вводит в ступор. А они всё предлагают и предлагают бумажки.
Одни раз за разом предлагают, а других каждый раз это вводит в ступор… Не пора бы привыкнуть? Или у вас есть решение, которое запретит предлагать hello world на бумажке?
P.S. Ну и я не отменяю иронии парадокса, что людей, которым на собеседовании подсовывают «напиши Hello World» — надо решать СОВСЕМ ДРУГИЕ задачи.
Как написание «Hello World!» коррелирует с задачей создания оптимальной архитектуры приложения или оптимизацией рабочих процессов — сие есть загадка неведома есьм.
Видишь суслика? Вот и я не вижу, а он есть!Druu
25.07.2019 11:33Задача настолько сложная, что сеньору нужна IDE для решения этой задачи?
А забить гвоздь — задача настолько сложная, что для этого нужен молоток?
PashaNedved
25.07.2019 11:39В кусок сливочного масла?
samhuawey
25.07.2019 13:15На одном собеседовании меня сначала спросили работал ли я с маком и какие дистрибутивы линукса знаю. После получения отрицательного ответа по поводу MacOS выдали мак и попросили установить в виртуалку c редким дистрибутивом линукса Jira и Confluence. Более менее справился, спросил почему именно так. Говорили, надо проверить как поведу себя under stress. Типа, кнопки давить все умеют, а решать неожиданно возникающие проблемы за ограниченное время — не все.
dominigato
25.07.2019 17:41Удивительно, меня как-то тоже попросили на интервью установить Jira. Правда на виртуалке с убунту на винде. В убунту были сломаны репозитории, так что пришлось чинить апт сначала, только потом устанавливать что-то. Самое интересное, что никто из интервьюеров даже не догадывался о проблемах с установленной криво убунтой и о сложностях, которые пришлось решать по ходу.
Тот случай когда интервьюеры ничего не понимают в твоей области, взяли «задачку из интернета» и не имеют никаких критериев оценки ее решения.
White_Scorpion
25.07.2019 13:52В кусок сливочного масла?
Нет, в графеновую пластинку не разрушив её, но чтобы держалось хорошо. На века.
PashaNedved
25.07.2019 14:05То есть, это сопоставимая по сложности задача с «hello world»?
Плотник 7 разряда сможет забить гвоздь без нейлера или без молотка?White_Scorpion
25.07.2019 14:57+1Да нет — это просто реакция на слишком "умного" индивидуума, который после озвучивания задачи меняет её условия на облегчённые — выставляя опрашиваемого в невыгодном свете. После чего продолжает считать себе ещё и слишком хитрым, но когда ему, в саркастической форме, указывают на некорректность постановки задачи — сливается в демагогию.
Druu
25.07.2019 14:03В кусок сливочного масла?
Зачем вы забиваете гвозди в сливочное масло?
PashaNedved
25.07.2019 14:10Я не забиваю.
Druu
26.07.2019 01:06Я не забиваю.
Тогда зачем предлагаете делать это соискателю?
PashaNedved
26.07.2019 01:39Давайте без метафор, а то один меня уже обвинил из-за банального недопонимания. Хотя я всего лишь имел ввиду то, что загнать гвоздь в мягкое масло, можно и без молотка, и это не должно вызывать существенных затруднений.
Вы имеете ввиду, зачем предлагать писать код на листочке, когда есть IDE?Druu
26.07.2019 05:07Хотя я всего лишь имел ввиду то, что загнать гвоздь в мягкое масло, можно и без молотка, и это не должно вызывать существенных затруднений.
Код можно еще писать не просто на листочке, но еще подпрыгивая, или ногами вместо рук, или вниз головой, или одновременно насвистывая заданную мелодию. Почему из всего многообразия цирковых номеров выбрано только "на листочке"? Я не уверен, что одно такое представление сможет развлечь публику само по себе. Может, еще предложить поперемножать в уме большие числа? Зрителям такое нравится.
Вы имеете ввиду, зачем предлагать писать код на листочке, когда есть IDE?
Ага. Зачем? На практике у программиста будет и ИДЕ и гугл и все остальное.
PashaNedved
26.07.2019 07:29-1Может, еще предложить поперемножать в уме большие числа?
Ну, математики это делают перед зрителем: умножают, делят, извлекают корни.
Ага. Зачем? На практике у программиста будет и ИДЕ и гугл и все остальное.
А еще вы будете работать на работе. Будут встречаться ТБ, дедлайны, сверхурочные, субординация и еще много очень страшных слов, не относящихся к непосредственному решению задач. Я понимаю, что все предпочитают наиболее благоприятные рабочие условия, но и работодателю хочется, чтобы вы писали код быстро и без багов.
Давайте будем обходиться без стресс тестов. На собеседовании вам преподносят рабочие условия так, как будто это фирма вашей мечты. Непосредственно, на работе вы осознаете, что попали в ад. Сразу уволиться вы не можете, придется терпеть и отработать какое-то время.
Тру стори, с другой позиции… Нанимается админ на ненормированный рабочий день, случается чп, требующее безотлагательного вмешательства, и админ начинает — не хочу, не буду, не обязан. Это нормально?vvbob
26.07.2019 09:19Тем не менее программисту (современному) никогда не придется кодить на листочке, да даже в «Блокноте» очень вряд-ли.
Тоже не понимаю этой страсти, сейчас такая проблема предоставить человеку на собеседование ноут с предустановленными несколькими популярными IDE?
Druu
26.07.2019 09:48Ну, математики это делают перед зрителем: умножают, делят, извлекают корни.
Ну так вам человек нужен для выступления перед зрителями?
А еще вы будете работать на работе. Будут встречаться ТБ, дедлайны, сверхурочные, субординация и еще много очень страшных слов, не относящихся к непосредственному решению задач. Я понимаю, что все предпочитают наиболее благоприятные рабочие условия, но и работодателю хочется, чтобы вы писали код быстро и без багов.
Не понял, к чему это все.
Еще раз — зачем соискателю задавать цирковые задачки, если он устраивается программистом к вам, а не циркачом? Он же не собирается у вас перед зрителями писать код во время езды на одноколесном велосипеде. Так зачем вы от него требуете этих непонятных скилов?
Ну да
Тру стори, с другой позиции… Нанимается админ на ненормированный рабочий день, случается чп, требующее безотлагательного вмешательства, и админ начинает — не хочу, не буду, не обязан. Это нормально?
Ну в договоре все это прописано? За переработки с двойным рейтом заплатят? Если да — не нормально. Если нет — нормально, конечно, т.к. в этом случае вам никто ничем не обязан.
PashaNedved
26.07.2019 11:06Ну в договоре все это прописано? За переработки с двойным рейтом заплатят?
Конечно прописано. Переработки компенсируются 3 днями оплачиваемого отпуска.
Не понял, к чему это все.
Еще раз — зачем соискателю задавать цирковые задачки, если он устраивается программистом к вам, а не циркачом? Он же не собирается у вас перед зрителями писать код во время езды на одноколесном велосипеде. Так зачем вы от него требуете этих непонятных скилов?
К тому, что для интервьюера — это не цирк, а стресс-тест, который поможет отсеять не подходящую кандидатуру.Druu
26.07.2019 11:51+1К тому, что для интервьюера — это не цирк, а стресс-тест, который поможет отсеять не подходящую кандидатуру.
Не подходящего в чем? Вы программиста ищите или работника мчс? Или, может быть, бойца спецназа? Почему тогда не проверяете навыки рукопашного боя и стрельбы? Не думали о том, чтобы забрасывать соискателя куда-нибудь в тайгу на недельку?
А то бумажка-то стресс не проверит никак, в чем стрессовость написания кода на бумажке?PashaNedved
26.07.2019 12:25Не подходящего в чем?
В деловых качествах.White_Scorpion
26.07.2019 13:22Какие именно "деловые качества" проверяются стрессом?
И самое главное — зачем вы человека планируете тестировать именно так? Вы думаете он стал сениором БЕЗ испытывания достаточного количества стресса? Без срывов дедлайнов, объяснений с манагерами и т.д.?PashaNedved
26.07.2019 14:04Вы думаете он стал сениором
Сеньором?
- Hello World без IDE написать не может
- Алгоритмов не знает
- Математики не знает
- Пет проектов — нет
- Вклада в opensource — нет
- Синтаксис языка знает плохо
- Кейворды не помнит
- ...
Зато хочет прийти на собеседование, поболтать за жили были и подписать оффер на работу с 300к. Чтобы потом на работе 1/4 времени проводить, играя в пинг понг и попивая смузи. Оставшееся время он будет зависать в гугле и на стековерфлоу.
А вы сеньору идиотские вопросы задаете…
Fedorkov
26.07.2019 13:45Я понимаю, что все предпочитают наиболее благоприятные рабочие условия, но и работодателю хочется, чтобы вы писали код быстро и без багов.
Работодателю выгоднее привлекать экспертов комфортными условиями труда, чем пытаться компенсировать внутренний бардак заоблачными зарплатами.
И мы вроде как обсуждаем именно программистов, а не админов.
Archie_RU
23.07.2019 10:39
Допустим мы получили 7 резюме.
Из них 5 — от Senior JavaScript developer с опытом менее 2 лет. На позицию Java architect.
Скажите, у вас течёт слюна на пол если вы сидите неподвижно более 3 секунд?
sergeymelnichuk
23.07.2019 10:47Если надо пройти собеседование — надо учиться проходить собеседования. Это отдельный скилл, который достаточно условно коррелирует с успехом на будущей работе. Это все знают, но не меняют подхода.
Но с другой стороны, Senior Developer который не может инвертировать бинарное дерево (рекурсивное решение занимает 3 строчки кода) или написать за час BFS по графу, должен провести очень серьёзную «инвентаризацию» своих скиллов и сделать выводы.
Andrey_Dolg
23.07.2019 11:04Я вот не знаю, что вы написали. Но вопрос не в дереве и графах а в том что ваш словарь(инвертировать, BFS) мне не знаком.=)
vvbob
23.07.2019 21:10Давно уже работаю синьором, с работой справляюсь, а обозначенное вами сходу не сделаю, без гугла. Прошло довольно много времени с момента когда я такие задачки решал, в повседневной деятельности эти навыки ни разу не пригодились и были благополучно забыты.
(Правда, у меня ни на одном собеседовании такого и не спрашивали, бывали вопросы вообще про деревья, что такое и зачем, но знание алгоритмов с ними связанных никто не требовал)sergeymelnichuk
23.07.2019 21:21Именно это я и хотел донести, что работать синьором не всегда поможет прохождению интервью, как ни парадоксально.
Но я остаюсь при своём мнении, не навязывая его: если простая алгоритмическая задача ставит в тупик, то титул синьора как бы обязывает поправить ситуацию, не обязательно в контексте подготовки к собеседованиям.vvbob
24.07.2019 08:57+2Но я остаюсь при своём мнении, не навязывая его: если простая алгоритмическая задача ставит в тупик, то титул синьора как бы обязывает поправить ситуацию, не обязательно в контексте подготовки к собеседованиям.
Думаю большинство разработчиков от мидла и выше она ставит в тупик не по причине того что они не могут этот алгоритм закодировать, а по причине того что сам алгоритм уже основательно забыт.
Человеческая память так устроена, что все неиспользуемое ежедневно уплывает далеко на периферию и вспомнить старые знания чем дальше тем сложнее. Видимо эволюция неспроста так распорядилась, ресурсы ограничены и лучше потратить их на что-то более актуальное.
Если на интервью так уж хочется проверить умение работы с деревьями — я думаю стоит просто дать человеку ноутбук с нормальным (и желательно привычным ему) IDE, описание задачи, включающее в себя описание алгоритма, и посмотреть на результат. Если человек не программист, то он и со всем этим ничего сделать не сумеет, и по результату будет хорошо видно какой уровень у разработчика.
Особенно если задачка не на три строки.
Оформление кода, декомпозиция задачи, использование (переиспользование) переменных, умение внятно объяснить примененные решения.
А тестировать память… это такое. Ну окажется что человек имеет феноменальную память и помнит алгоритм, который он 20 лет назад в ВУЗе учил, и что дальше то? Он только от этого становится полезным членом команды? Не думаю.
Beshere
23.07.2019 10:54Сам сейчас прохожу интервью. Опыт работы — 20 лет.
И вот что скажу — требования к скиллу стали очень серьезные, всем нужны сеньоры, чтобы все видел и все знал. Середнячков особо не нужно, новичков и даром не возьмут.
С одной стороны это хорошо — есть мотивация всем нам расти. С другой, вполсилы работать в нашей индустрии не получится, надо быть лучшим или идти бумажки перебирать или говорильню говорить.JustDont
23.07.2019 11:23И вот что скажу — требования к скиллу стали очень серьезные, всем нужны сеньоры, чтобы все видел и все знал. Середнячков особо не нужно, новичков и даром не возьмут.
Ничего подобного.
Впрочем, если вы смотрите вакансии на ваш опыт работы и на соответствующие деньги, то неудивительно, что там «требования к скиллу». Или вы думали, что джунам тоже будут по 100 с лишним тыщ платить просто потому, что это вайти?
Kyushu
23.07.2019 11:21Беседовал с парой человек из директоров компаний. Первый приглашал на работу без тестирования, второй говорил, что люди всегда нужны на позиции разработчиков, но на сайте таких объявлений нет. Часто нужны не «чистые» программисты, а специалисты, совмещающие программирование с определенной математикой или хорошими навыками коммуникациями. Не у всех хватает денег на классический набор распределения обязанностей.
savimar
23.07.2019 11:36Недавно собеседовалась в одну из компаний с задачками на 1 час. Не успела. Потом как-то там все-таки было техническое собеседование. От собеседующих завяли уши от их непрофессионализма
dominigato
23.07.2019 11:43+2Еще меня всегда удивляло когда спрашивали у опытных айтишников вещи, которые лучше всего знают студенты. Потому что только недавно сдавали экзамены и они еще не знают столько такого, что бы вытолкнуло знание бинарных деревьев на задворки памяти.
То есть если человек помнит все эти студенческие вопросы и пузырьки, то значит что он с тех пор особо то ничего и не выучил, иначе это бы было выдавлено новыми знаниями куда-то в очень долговременную память.agalakhov
23.07.2019 19:12Скорее это значит, что:
- человек так и не увидел, как связать эти знания с реальностью, и заклеймил их как "ненужые", возможно, работая много лет на однообразной рутине,
- человек никогда не работал со студентами и стажерами, не обучал их и не собеседовал, и вообще никогда никого не учил программировать. Т.е., по-видимому, к человеку не обращались младшие за помощью.
dominigato
23.07.2019 22:25+1Да, вы правы, лучше чем студенты на эти вопросы могут ответить их учителя. Они преподают это каждый семестр, конечно от зубов отлетает. Поэтому если это интервью на роль преподавателя, то все так.
Вот только учить кого-то программировать обычно не входит в обязанности девелоперов… для этого есть учителя, лекторы, и т.д. и т.п.gohan
24.07.2019 01:16+1Да, вы правы, лучше чем студенты на эти вопросы могут ответить их учителя. Они преподают это каждый семестр, конечно от зубов отлетает. Поэтому если это интервью на роль преподавателя, то все так.
Вот-вот. Меня в универе ещё бесил подход у некоторых заносчивых преподов (не все такими были, но немало). У них отношение такое, что типа «ну чего ты, дурак, этого не помнишь, я-то весь материал помню, всю теорию, вот какой я молодец!». Да, ты помнишь, вот только у тебя, дебила, ничего в жизни нет кроме своего предмета, который ты каждый день повторяешь по 100500 раз. А у нормального даже добросовестного студента без феноменальной памяти таких вот преподов и предметов с десяток одновременно, и попробуй-ка упомнить все формулы и доказательства. И какой-нибудь такой супер-препод гордый по теормеху скорее всего мог бы только лососнуть тунца, если я б ему задал вопрос по теорфизу, например.
Такая же фигня со всякими хитрыми алгоритмами и решениями задачек. Сейчас я нифига не вспомню их без гугла, а на момент окончания универа много такого знал и мог заодно решить всякие задачки по математике. И если бы сегодня собеседовали меня текущего и меня прошлого методом задачек без гуглежа, то моя прошлая версия прошла бы собес без проблем, вот только сходу хорошо работать эта версия не смогла бы по очевидным причинам и косяков была бы уйма при попытке делать реальные задачи.
dbelka
23.07.2019 11:55+1Многие считают, что сеньор должен решать простые задачи уж не медленнее джуна, а то и быстрее и легче, но в реальности всё как раз наоборот.
Сеньор отличается умением решать сложные задачи(а не строгать простые) и его мозг заточен под сложные задачи. Когда на собеседовании дают что-то элементарное, то у такого разработчика случается диссонанс в мозгу и перестроиться без дополнительной практики сложно.snuk182
23.07.2019 12:46Под демонстрацию как нельзя лучше подходит анекдот про решение инженером проблемы нахождения объема синего резинового мячика — тот просто достал с полки справочник и открыл его на странице с таблицей "Объемы синих резиновых мячиков".
sergeymelnichuk
23.07.2019 21:27Странная логика, получается чем опытнее инженер тем сложнее/медленнее он будет решать простые задачи? Мозг не может быть «заточен», мозг либо решает задачу либо нет.
Не могу представить себе инженера который быстро и легко решит, скажем, задачу распределённого консенсуса («изобретёт» PAXOS-like протокол, например), но который при этом не сможет инвертировать бинарное дерево :)
pprometey
23.07.2019 12:06Да, задачки, люки, деревья и прочий отстой который гуглиться за 10 секунд — это дерьмовая практика собеседования при приеме на работу программиста, которая не дает реального представления о хард и софт скиллах разработчика, особенно с большим опытом, такого как сеньора.
Больше пользы с того, когда разработчик расскажет о тех проектах которые делал, опыте, который извлек из этого, сложностях, с которыми столкнулся и то, как он их решил. Но это оценит только такой же коллега, как и он сам.
А эта вся чепуха с задачками, как мне кажется, идет из попыток автоматизировать и формализовать этот процесс, особенно когда подбором персонала занимаются люди других специальностей, либо бывшие программисты, уже давно забывшие что это такое на самом деле.
Еще хотел отметить такой психологический момент. В некоторых компаниях он применяется. Когда уже прошло собеседование, и произведена оценка кандидата, получено первоначальное одобрение… и перед разговором о конкретных условиях и заработной плате, компания может «накидывать»… т.е. спрашивать какие-нибудь особенно каверзные либо очень сложные вопросы, чтобы снизить уверенность кандидата в собственных силах и знаниях с целью «ослабить позиции» перед переговорами о оплате труда.JediPhilosopher
23.07.2019 12:37Есть нюансы.
Во-первых если речь идет о джунах — у них просто нет еще проектов о которых можно рассказывать. У миддлов часто тоже нет, или они не могут нормально рассказать — зачастую они сидят и пилят какую-то тривиальную функциональность.
Во-вторых человек может просто врать — да, так тоже бывает. Совсем уж наглую ложь конечно легко развалить парой вопросов, но бывают и подготовленные люди. Тут на хабре где-то даже статья была с примерами, как обманывают рекрутеров.
В-третьих человек мог формально участвовать в проекте (и он может о нем рассказать), но по сути программировать он все равно не умеет. В крупных конторах вполне можно попасть на теплое местечко, ничего не делать, общаться в курилке с коллегами, имитировать бурную деятельность, но не писать код (или писать очень-очень медленно). Внутренняя бюрократия всяких там ЕПАМов таким людям позволяет держаться годами, увольнять там не любят, а будут перекидывать из проекта в проект.
Так что какая-нибудь простая задачка на код — единственный на мой взгляд способ проверить, что человек умеет этот код писать. При этом я тоже считаю что всякие "напишите красно-черное дерево на бумажке" это ерунда и не нужно. Достаточно какого-нибудь простейшего FizzBuzz или аналога, ну и естественно на компьютере и с IDE.
pprometey
23.07.2019 13:11Я при приеме на работу практикую такой поток:
1. Созвониться, договориться о встрече. Этап — Телефонное интервью.
2. Встретиться с кандидатом, поговорить. Показать офис, условия труда. Этап — Предварительная оценка.
3. Тестовое задание. Из двух частей — опросник по навыкам (хард и софт скилы детально — 3-5 стр.), задание на разработку прототипа приложения (приход, расход товара, отчеты). Иногда можно дать дополнительное задание, специфичное для проекта (например на знание SQL, какой-либо библиотеки и т.д.). Предварительное время выполнения кандидат назначает сам. Этап — заключительная оценка.
4. Переговоры об условиях работы и оплаты труда. Этап — заключительное собеседование.
На мой взгляд это более-менее оптимизированный процесс приема не работу, не изматывающий марафон, но и не с кондачка.
pprometey
23.07.2019 13:20Насчет ньюансов — не обязательно иметь за плечами портфель проектов и о них рассказывать. В любом случае до собеседования была какая-то профессиональная деятельность либо попытки, даже первые шаги. Можно рассказать и о них, о проблемах и способах их решения в этом процессе.
agalakhov
23.07.2019 19:21Еще один нюанс. Если человек действительно сеньор с опытом, то он почти наверняка кого-то учил. Тогда он не может не знать учебные задачи. Очень слабо себе представляю ситуацию, как можно много лет работать и не столкнуться при этом с необходимостью объяснить кому-то устройство красно-черных деревьев. Ни разу никто не просил о помощи? Ни разу не курировал студентов? Ни разу не объяснял джуну, что внутри у std::map? За все эти годы?
senglory
23.07.2019 20:24как можно много лет работать и не столкнуться при этом с необходимостью объяснить кому-то устройство красно-черных деревьев
А нафига их знать, если в повседневной работе дело имеешь с Sharepoint, например? Или еще какой ERP системой?
dominigato
23.07.2019 23:36Почему это должен объяснять сеньор кому-то? Почему это не знает джун, который только что по этим красно-черным деревьям сдавал экзамен? И даже если нет — это его обязанность найти материал и выучить. Никогда не видел чтобы сеньоры сидели и учили другиих программированию, это совершенно неэффективная трата их времени, тут не школа, а бизнес вообще-то. Сеньор должен делать свою работу, за которую ему платят. Если он хочет учить — пусть идет на зарплату учителя и учит студентов там.
Хотя скорее тут джун может научить пузырькам сеньора, который это забыл уже)pprometey
24.07.2019 07:44Наставничество — неотъемлемый элемент в работе сеньора.
dominigato
24.07.2019 13:03+1Да, но это не наставничество, вы путаете его с учительством.
pprometey
24.07.2019 13:20Ну давайте тогда предметно. Что такое наставничество, что такое учительство. Какая между ними разница и где проходит грань перехода из одного в другое. А то так… Как то болтологично получается…
dominigato
24.07.2019 14:03Ну давайте предметно, расскажите что вы имеете в виду под наставничеством.
lotse8
23.07.2019 12:47Не от хорошей жизни эти тестовые задачки. Потому что многие называют себя программистами и сеньорами, но по факту уровень не всегда соответствует. Сходу не всегда поймешь за час собеседования. И еще одно: есть потенциал (человек знает очень много) и есть способность реализовать свой потенциал (сделать как надо и в срок), и не всегда из первого автоматически вытекает второе.
Идеальным вариантом для работодателя было бы организовать 10 рабочих мест и сразу взять 10 человек на испытательный срок, потом через неделю-две оставить одного-двух сеньоров, а остальных отправить искать работу дальше.
Но и с таким подходом тоже многие не согласятся и не захотят терять две недели своего времени. Так что же лучше для сеньора, потерять час на тестовом задании или две недели на испытательном сроке?Andrey_Dolg
23.07.2019 14:31Если человек с как вы сказали «потенциалом»(опыт) не сделал в срок, это в 90%(Имхо) случаях не верно поставленный срок.
vvbob
26.07.2019 09:23По-моему простая беседа с просьбой описать решаемые на предыдущей (текущей) работе задачами, проблемами и тем как они были решены, скажет о кандидате намного больше чем блестяще решенная задачка из учебника.
Самозванцу такую беседу не пройти наверняка, обман вскроется через мять минут общения.
MacIn
23.07.2019 13:12+1Это уже дай бог двадцатая статья на тему «на собеседованиях спрашивают задачки и вообще отвлеченное от будущих реальных задач».
И каждый раз как в первый раз — в комментариях страсти аж жуть, люди стоят на смерть. Не наскучило?
A114n
23.07.2019 13:25+1>Потребность в программистах велика как никогда
>не рассчитывайте, что годы опыта купят вам беззаботное трудоустройство
Самым замечательным здесь я считают то, что это написано не абы кем, а таки программистом.
Но по существу, конечно, ситуация ровно такая же, как с проблемой «нечего надеть» и «перевелись настоящие мужчины».
yuliaazak
23.07.2019 13:31Сейчас много людей учится программировать, но для решения задач прикладных, а не для красоты кода: надо построить базу данных для анализа или создать морду для сервиса- то есть это профессионалы из индустрии. Постепенно они повышают квалификацию и хотят перейти в разработку в смежную -такую же индустрию. Но они не пройдут через ассесмент программистов тк у них задачи и навыки другие.
Здесь может быть вопрос, что нужно компаниям (хардкодеры или междисциплинарнгсть) и что хотят люди (расширение своего профессионализма или глубокого кода ради кода/денег).
Если компаниям нужна monkeyjob- делай, что сказали, то у них есть бюджеты на то, чтобы ждать и искать лучшего по алгоритма наизусть, чтобы не лез в продукт. Если компания более подвижная, она возьмёт специалиста, кто сейчас метит в Джуны, и имеет большой опыт в индустрии.sergeymelnichuk
23.07.2019 21:38Программирование для не-прикладных задач — это академические исследования.
Всё остальное программирование — так или иначе предназначено для решения прикладных задач.
Построить базу данных — это очень узкая специфическая область. Правильно пользоваться базой данных — другая, но менее специфическая. Современный фронт-энд это вообще отдельная песня, с кучей нюансов.
Но во всех этих задачах применимы паттерны, лучшие практики, идиоматические подходы языка/платформы и т.д. Фундаментальные вещи не меняются уже десятки лет, и если человек из знает и умеет применять, велика вероятность что он сможет (условно) быстро и качественно осваивать новые технологии и производить качественные решения. Именно такую «базу», я считаю, есть смысл проверять на собеседованиях/ассесментах, я не специфические знания фреймворка/библиотеки.
> кто сейчас метит в Джуны, и имеет большой опыт в индустрии
это как вообще?
user_man
23.07.2019 13:45У гуглов реально вал заявок на «поиметь с них бабла». Ну и не удивительно — и 120к и 200к и больше можно зарабатывать. Плюс охват — по всему миру. Поэтому им нужен инструмент для фильтрации явных даунов. Вот они и выбрали простой вариант — задачки на алгоритмы. Не сразу, но постепенно набрали статистику, которая показывает — это работает. И всё. Более возражения не принимаются. Ибо с чего вдруг выкидывать работающий инструмент?
И да, гуглам нужны не сеньоры, а такие люди, которые будут выполнять требования тим-лидов. Не рассуждать о программах, а долго и продуктивно кодировать. То есть это конвейер, куда нужны конвейерные работяги. Так с чего вдруг у конвейерного работяги будут спрашивать про его мнение?
Ласково и осторожно общаются лишь с очень важными кандидатами. Сеньор — не важный кандидат. И при этом умение решать задачки хоть как-то позволяет отсортировать явных неумёх. Поэтому поступающую на вход очередь желающих чисто промышленными методами прогоняют через чисто промышленный фильтр, который, как и принято в промышленности, имеет погрешности, которые, в свою очередь, вполне устраивают хозяина конвейера. Поэтому плакать и возражать — неконструктивно. Хотите получать 200к? Тогда решайте задачки. Не хотите решать? Ну тогда не будет вам 200к. Всё просто. И желающих — вагон. Се ля ви.
И да, фильтр реально работает. А на погрешность при огромной очереди на вход — просто плевать. Это как с вопросом про кота — почему он лижет яйца? Потому что может. И всё. Возражения он не принимает. Ну а ваша яркая индивидуальность и великолепный опыт… Ну в общем на конвейере это не интересно.
ЗЫ. А для джунов всё ещё неприятнее, но они не плачут, а тихо зубрят и устраиваются в богатые конторы, что бы через несколько лет получать 200к. А те, кто плачут, идут работать дворниками. Опять се ля ви.
Хотите по другому? Меняйте мир. Не получается? Но почему вы в этом гуглов обвиняете? Это вы не смогли подстроить мир под себя, а не они. Они, как раз, смогли.JustDont
23.07.2019 13:52+2В случае с условными гуглами — дело в хайпе, а не в заплатах. В условных гуглах платят хорошо, но это далеко не топ-1 мира по зарплатам. Ключевое отличие — именно в хайпе, много кто хочет работать в условном гугле, а не в условной конторе по заготовке рогов и копыт, несмотря на то, что в этой конторе тоже 200к могут предлагать определенным спецам.
А уже из этого «много кто хочет» рождается и конвеерный подход — действительно, если в желающих недостатка нет, то можно их фильтровать как угодно.user_man
23.07.2019 14:00>> дело в хайпе
По мне так захайпованность — это признак неадекватности программиста. Он либо очень молод, либо не способен учиться. Как можно покупаться на виртуальную игрушку? Просто на абсолютно эфемерное ощущение величия (или чего они там от хайпа ощущают)? И при этом оставаться трезво мыслящим разработчиком. То есть трезвый подход не совместим с пьяным (одурманенным хайпом) состоянием.0xd34df00d
24.07.2019 14:59Это не совсем тот хайп, ИМХО.
Просто гугл — действительно неплохая строчка в резюме (ну или была неплохой какое-то время). А среднее время работы там, говорят, чуть больше года. Наверное, не зря.
samhuawey
23.07.2019 13:52+2Задачки помогут когда у специалиста 1-5 лет опыта. Если у него в резюме несколько компаний из программисткого Топа — какие вопросы, всё и так понятно. Останется спросить почему ушёл и поболтать на отвлечённые темы, а ещё лучше рассказать о предстоящей работе и спросить интересно или нет.
Это не работа выбирает сеньора (ну разве что после форс-мажора типа сворачивания бизнеса Sun в России), это сеньор выбирает работу, и после банального отсеяния на адекватность на уровне HR технические вопросы задавать бесмыссленно.
Когда я собеседовал на свою позицию, я проверял знание инструментов, а также банальную логику и стрессоустойчивость. Типа вот случилась на проде такая проблема, что будете делать. Тут уже не важны технические детали, всё равно для каждого продукта они свои, скорее важно общее понимание, и в том числе организационное, типа, сообщить СМСкой топ менеджеру — очень важный пункт.
spamas
23.07.2019 15:48-4Парадокс хабра: пишешь комент «дурацкий вопрос» к статье о том, как спросили в интервью в чем разница между коммит и пуш в гите, дык его минусуют активно. А тут комент «дурацкие вопросы в интервью бесполезны» просто ацки плюсуют.
Стадо.
rokuz
23.07.2019 16:03Для крупных корпораций этот подход хорош почти всем. Это превращает процесс найма в конвейер, это дает одну «линейку», который можно сравнивать разных разработчиков. «Линейка» позволяет унифицировано определять ЗП, в том числе продавливать разработчиков на меньшие деньги, так как олимпиадными задачами на работе мало кто занимается, а значит шанс того, что ты решишь все задачи без возможности придраться к чему-либо, совсем мал. Этим, кстати, активно пользуется небезызвестная российская корпорация.
Вот что такой подход нормально сделать не позволяет, так это нанять людей с узким профилем. Узких профилей бывает много, чтобы стать профессионалом в некоторых нужно потратить годы. Тот же Google прямо говорит, что такие люди в большинстве случаев им не нужны, им нужны универсалы, способные потенциально работать в любой части корпорации, которых можно перераспределить в случае закрытия проекта и любой другой смене направления деятельности. Так как такие корпорации имеют тенденцию скупать технологически сложные перспективные стартапы, то есть определенный риск того, что покрыть узкие профили в этих проектах с таким подходом к найму им будет не просто. Поэтому разработчики, которые попали в корпорацию вместе с проектом и получают там космические ЗП, а если покидают компанию, то проект оказывается на грани забвения. Это создает редкие случаи, когда корпорация отступает от правил, и собеседует людей в индивидуальном порядке, еще часто и по рекомендации. Все остальные, если действительно хотят в Google, и чувствуют, что там им будет комфортно, к сожалению, должны научиться проходить фильтр.
saterenko
23.07.2019 17:07Ну так нужны им вызубрившие спецификации с опытом решения олимпиадных задач… Из почти 20 лет опыта работы около 15-ти переходил по рекомендации… Иногда проходил собеседования just for fun, пролетел в Майкрософт, Блумберг, два раза в Яндекс… Подумываю закрыть профиль в линкедин, потому как всё одно и то же, ни кому не интересен мой опыт решения задач, всем нужны спецификации и олимпиадные задачи…
igor-sheludko
23.07.2019 17:31Задачи позволяют проверить насколько хорошо человек умеет мысли нестандартно. С набором опыта, специалист уже легко решает многие задачи, потому что имеет в голове подходящие шаблоны. Вероятно, это снижает частоту применения творческого подхода. Поэтому неудивительно, что опытные специалисты плохо проявляют себя в олимпиадных задачах.
Основной вопрос тут такой — будет ли искомый человек потом на работе часто решать нестандартные задачи? В большинстве случаев — скорее всего не будет. Лично я выступаю за проверку знаний с помощью быстрых тестов, на подобии тех, что проводят для определения уровня владения иностранными языками (50-100 вопросов за 30-60 минут).dbelka
23.07.2019 21:59+1Поэтому неудивительно, что опытные специалисты плохо проявляют себя в олимпиадных задачах.
Олимпиадные задачи это вообще отдельная тема, нужно специально тренироваться, чтобы был ощутимый результат.
Tantrido
24.07.2019 14:47В принципе мне подобные практические собеседования нравятся больше, чем те, что были раньше, когда компании нужен не программист решающий задачи, а ходячий справочник по технологии, например .Net. Но если в 16-м на работу взяли сеньором моментально и без проблем после решения тестовой задачи (на решение дали сутки) + резюме, github и LinkedIn, то сейчас даже решение 3-х задач на отлично на codility за 2.5 часа и успешно пройденное затем техническое интервью не гарантировало получение работы — бред.
Затем в другой очень известной фирме с высокими зп тоже напрягся и решил эти тестовые задания на codility. На решение дали уже меньше — 1.5 часа, что непонятно: спортсменов по программированию или рабов на галеры нанимают: даже тестовые задания нормально не успеваешь составить на проверку и производительность кода. Но потом этот бред продолжился: тестовые задания дали ещё и на последующем техническом интервью, только решить уже нужно было в присутствии интервьюера за 15-20 мин — решил за 21 мин — отказ. Что происходит?!
Уже нарешался этих задач на codility массу — аллергия на них уже, если б это ещё получение работы гарантировало. Они могут мои предыдущие тесты посмотреть?! ;)
iCoderXXI
24.07.2019 15:04А в чем проблема для крутого синьора потратить пару месяцев на кодварс и прокачать эти задачки?
dss_kalika
24.07.2019 15:19+1Потому что это не повышает его навыков программирования и ничего полезного как для специалиста не несёт.
iCoderXXI
24.07.2019 17:23-3Позвольте не согласиться с подобной позицией. Подобные задачки как раз таки демонстрируют навыки, в том числе как человек умеет в алгоритмы и структуры данных, т.к. большая часть задачек как раз вокруг этих вещей построено. Достаточно много разработчиков успешно минуют данную фазу, почём зря (имхо). Лично я своих учеников всех поголовно отправляю на кодварс качаться, потому что на таких задачках великолепно отрабатывается практика, которая и есть критерий истины.
Я вообще не понимаю, как человек мог стать синьором, и как он решает большие задачи и неможетхочет справиться с малыми.
Я в 2015 году радикально поменял стек, завалил десяток интервью, и чтобы приучить мозги думать на JS как раз таки пошел и тупо решал всё подряд на том же кодварс. Это очень интенсивный и эффективный метод.
Более того, в современных приложениях на React+Redux (мой основной стек в настоящее время), редьюсеры, селекторы и не только они, при чуть более сложном сторе требуют как раз таки ровно те самые навыки, которые и оттачиваются на подобных задачках. Поэтому я слабо представляю себе годного фронтенд-разработчика в наши дни, кто не умеет решать подобные задачи.
На самом деле в любом приложении, где нужно как-либо обрабатывать данные подобные задачи будут весьма полезны.
Поэтому повторюсь, позвольте не согласиться с Вашей позицией. Решать задачки нужно и весьма полезно, и зря синьоры от них носы воротят. Если они реально такие синьоры как о себе думают, то для них не будет проблемой пару месяцев побаловаться хоть на том же кодварс и проблема будет решена раз и на всегда. А если нет, то стоит задуматься…dss_kalika
24.07.2019 17:59+21. Если вы не пользуетесь чем то давно — то и задачки по этим вещам не решите, да и не очень они вам нужны, если вы ими не пользуетесь давно.
2. Есть технологии/задачи/области, для которых задачки такого рода не показывают ничего.
3. Это из разряда «каждый программист должен быть математиком и отучиться несколько курсов изучая интегральное/дискретное и прочие исчисления». Вроде бы и должен, но большая часть — никогда не столкнётся с необходимостью использовать эти знания и просто забудет их через 10 лет.
4. Забывают конкретику, а принципы остаются. Конкретную задачу можно не решить или решить неправильно, но думать при этом правильными категориями и исходя из правильных критериев делать прикидки и суждения. Потому что конкретика забывается, а привычки остаются.
ЗЫ:
Но, да — если в конкретной работе/области/технологии часто встречаются такого типа задачи и необходимы именно эти навыки, то такие задачи помогают оценить кандидата.
Только речь как раз о задачах, которые не встречаются в работе )iCoderXXI
24.07.2019 18:24-1Это всё лирика. :) Практика говорит за то, что коли сейчас повсеместно предлагают подобные задачки, то нужно просто потратить сколько-то времени да прорешать сотню-другую на досуге, и вопрос будет исчерпан. А то реально обидно маститому синьору срезаться на такой ерунде…
У меня в 11-12 годах отросла корона, а потом пришлось менять компанию, походил впервые за много лет по собесам, корону отшибло начисто, вместе с гордынюшкой. :)dss_kalika
24.07.2019 18:30+2Практика говорит, что если повсеместно предлагают подобные задачи — значит это распространённые и шаблонные задачи, из чего, чаще всего, следует что их просто откуда то взяли с остальным чеклистом для собеседования… что ну никак не говорит о том, насколько те, кто собеседуют могут адекватно понять из этого чеклиста какой специалист перед ними. (надеюсь, из этого путанного текста хоть что то понятно)
Люди частенько меняют работу или ходят на собеседования не думая заранее, что они будут это делать. (я, к примеру, просто ради мониторинга рынка хожу на собеседования и, конечно, получается что особо не готовлюсь к ним) И, как следствие, они готовы представить собеседователям свои навыки, свой опыт и что угодно, кроме того, что 10 лет уже как не используют и подзабыли… и скорее всего не используют и на этом месте работы. (чаще всего так и бывает)
Да и, некрасиво это — заставлять соискателей штудировать и тратить время на задачи, которые не используются в этом направлении и, особенно, в самой предстоящей работе просто ради… ради чего? )
Соответственно и реакция у соискателей на такие вещи не очень хорошая. =)iCoderXXI
24.07.2019 18:51Ну не. Эти аргументы похожи на что-то вроде английский знаю отлично, но слова забыл, т.к. давно не было практики, поэтому о себе рассказать не смогу, но английский знаю отлично, а практиковаться влом… :)
Из тех задачек что мне попадались на подобных интервью, никаких затруднений они у меня не вызывали, при том, что я ни разу не спортивный программер, просто стараюсь держать себя в мало-мальской форме. Да и в целом не знаю кому как, а мне интересно временами прорешать пару-тройку задачек, чисто по приколу. Плюс ученики постоянно подкидывают ту или иную задачку, а я, прежде чем им на пальцАх делать раскладки, разумеется сначала сам прорешиваю, иногда несколькими способами, смотрю другие решения… Короче это прикольно, имхо.
Я абсолютно убежден, что любой синьор, мидл, да даже джун за разумное время может порешать задачек и проблема будет исчерпана.
В 14-15 годах я осознал, что веб люто повзрослел, в него пришел энтерпрайз и все требования возросли на несколько порядков. И я, внезапно, превратился в седовласого, бородатого джуна. Я радикально поменял стек, смиренно штудировал доки, смотрел и слушал сотни часов обучающих материалов, покрывал белые пятна, прокачивал скиллы, выполнял десятки туториалов. Проваливал собес за собесом, получал фидбэки, работал над ошибками, пока, в некоторый момент, не начал получать офферы.
К слову сказать работу в этом же ключе я продолжаю и по сей день и не собираюсь успокаиваться на достигнутом. Сегодня каждый вынужден бежать что есть сил, только чтобы оставаться на том же самом месте…user_man
25.07.2019 12:25>> Я радикально поменял стек, смиренно штудировал доки, смотрел и слушал сотни часов обучающих материалов, покрывал белые пятна, прокачивал скиллы, выполнял десятки туториалов. Проваливал собес за собесом, получал фидбэки, работал над ошибками, пока, в некоторый момент, не начал получать офферы
И сколько времени всё это заняло?
Вообще, вы говорите о переходе на новые для вас технологии, а вам говорили про сеньора, который давно сидит на известных ему технологиях и именно по ним заработал своё сеньорство. Поэтому если в его работе встречались алгоритмические задачки, то он и их должен бы вместе со всем остальным хорошо представлять. Но бывает так, что алгоритмы в работе примитивные, и всё упирается именно в знание технологий. Это весьма распространённый вариант для бэка (ну пишет чел. OLTP 10 лет и ни про какие алгоритмы никогда не вспоминал). Хотя при этом работу с БД, целевой язык, библиотеки, инфраструктуру и много чего ещё он может знать очень хорошо (на много лучше джуна). И вот вы как поступите — откажете ему и возьмёте мало знающего джуна или? Хотя задачки сеньор может и решит, но медленно, медленнее джуна или ваших лимитов. А может даже чего-то не решит. Каков ваш выбор?iCoderXXI
25.07.2019 13:16Вот каждый о своём, ей Богу.
Любой спортсмен делает разминку регулярно. Любой музыкант постоянно фигачит гаммы и арпеджио. Певец распевается. Вот и задачки — такая же разминка для мозгов программиста. Не нужно из них делать проблему…
Кроме задачек грамотный эчйчар много моментов проверит. А вот когда маститый синьор не желает решить простенькую задачку, хотя по идее должен уметь щёлкать их как сэмки, то это звоночек…
Айти сфера развивается нереальными темпами, я в строю с 1995 года, и постоянно приходится держать руку на пульсе. Если человек 10 лет фигачил пусть даже какой-то очень забористый стек, и считает что он достиг пределов и развиваться ему нет нужды, ну что ж, как говорится желаем удачи…
Я вот постоянно помню, что горячие молодые разработчики, у которых ни ребенка, ни котёнка, которые готовы фигачить до потери пульса чуть ли не за еду, постоянно дышат в затылок и наступают на пятки. Писал выше и снова повторю, в наши времена нужно очень быстро бежать, чтобы только оставаться на том же самом месте…
Ах да, а еще Индия штампует десятки, если не сотни тысяч разработчиков каждый год. Прошу заметить, голодных и готовых почти на всё, разработчиков. И все они залетают на рынок. Наш российский айти сегмент спасает то, что эти друзья по русски ни бельмеса, а вот попробуйте на англоязычный рынок сунуться, ощутите во всей красе все прелести конкуренции с молодыми и голодными до всего, имеющими в распоряжении вагоны времени и энергии…
samhuawey
25.07.2019 13:18Очевидный выбор — взять сеньора, который поработал над очень разноплановыми продуктами. Если он смог быстро перестроиться, то и в новой компании проблем не будет. Если всю жизнь бронзовел на одной работе на одном проекте — ну не знаю.
> Я вот постоянно помню, что горячие молодые разработчики, у которых ни ребенка, ни котёнка, которые готовы фигачить до потери пульса чуть ли не за еду,
Не всё так просто. По моему опыту молодые быстро остывают и им становится всё равно. Именно тогда когда нужно тупо долбить и делать то, что написано в техзадании, покрывая тестами и обеспечивая выход продукта в назначенное время. Молодёжь это всегда риск.
michael_vostrikov
25.07.2019 17:49Эти аргументы похожи на что-то вроде английский знаю отлично, но слова забыл, т.к. давно не было практики
Нет, эти аргументы похожи на то, что китайский не знаю, т.к. давно не было практики, и он мне в работе не нужен. А на интервью его спрашивают по причине "Знание китайского покажет нам, как вы умеете по-английски говорить".
JustDont
25.07.2019 18:29Отличная аналогия. Причём ведь всерьез так и пишут (в том числе и тут в комментах): сеньёр? Ну значит, ваше отличное знание китайского покажет нам вашу любовь к языкам, которую мы ожидаем от всех наших сеньёров.
Fedorkov
24.07.2019 20:20По личному опыту, на практике важнее уметь вкурить в заумную научную статью с нюансами редкого алгоритма, чем выдать на-гора решение десятка олимпиадных задач. Хотя your mileage, как говориться, may vary.
Tantrido
24.07.2019 23:35Да, так и было, что сейчас творится — непонятно. Но думаю всё должно измениться к лучшему.
user_man
25.07.2019 14:05То есть в вашей практике сплошным косяком шли исключительно редкие алгоритмы из заумных статей? В какой области так работаете, не секрет?
Fedorkov
25.07.2019 22:25В том-то и дело, что ни у кого алгоритмы не идут косяком. Если вы раз в месяц по полдня мучаетесь над задачей типа тех, что на собеседованиях, вы потеряете 2% продуктивности по сравнению с олимпиадником. Но если вы совсем не можете хакнуть действительно сложную задачу, то весь проект может потерять в конкурентоспособности.
PsyHaSTe
25.07.2019 02:29Потому что зачем? У него и без того хватает предложений. Вторая причина — наличие тупых задачек говорит об интеллекте менеджмента, а второй золотое правило хорошего работника гласит "не работай с идиотами".
snuk182
Полтора года назад завалил подобное собеседование. Очень рад был недавно увидеть эту позицию незакрытой до сих пор. Мне даже неинтересны подробности — до сих пор ли они ищут кандидата, умеющего одновременно и олимпиадные задачки на скорость и способного взаимодействовать с ТЗ, либо набрали кого-то из антисанитарных стран до первого бетонного самолета.
LeshaVH
Большинство крупных компаний просто собирает базу данных)))
А вообще тому кто предлагает задачки сеньор или лид разработчикам с 15+ годами — надо просто пойти на хер)))
Ибо они не адекватны)))
snuk182
Ну почему же. Я уверен, менеджер искренне хочет найти здравомыслящего сотрудника, который способен реализовывать бизнес задачи соответственно заданиям, реагируя на обязательно возникающие изменения. Однако, автоматизация процесса рекрутинга, решение в пользу которой было принято даже не обязательно этим же менеджером, выдаст в итоге не вполне однозначные результаты. Это в случае компании, которая просто хочет "срезать углы" в процессе поиска специалиста. Есть же еще компании, где программист — заменяемый ресурс. С вытекающими следствиями как рекрутинга, так и отношения в процессе работы. По личному наблюдению — действительно ценных людей туда принимают в обход всего автоматизированно-бюрократического геморроя, чтобы, упаси боже, не спугнуть.
Ildar92
я знаю сеньора с 20+ годами опыта, но я бы так не сказал, если бы не знал этого факта. на кого-то между миддлом и сеньором потянул бы
depadep
Это верно, годы опыта сами по себе на хлеб не намажешь.
Но и другая проблема тоже есть — умение быстро решить олимпиадную задачку не гарантирует, что человек сможет работать программистом изо дня в день.
Годы опыта хотя бы дают такую надежду.
dim2r
В нейросетях подобная проблема есть — переобучение. Когда нейросеть запоминает как решать задачи на этапе обучения, но потом глючит на незнакомых реальных данных.
x67
Тут дело даже не в переобучениях, а в том, что умение решать олимпиадные задачки, хоть и коррелирует с навыками сеньора до какой-то степени, но по сути это две разные области. Можно взять тренированного 10классника, но сеньором от своего умения не станет. Хотя в него будут верить больше, чем в тех, кто эти задачи решать не умеет.
dim2r
Если они не использовали инверсию двоичных деревьев последние три года, то можно посылать нахеp.
Меня недавно спросили теорему Чёрча-Росса о ламбда исчислении. А оно мне надо?
sshikov
Ну, вообще такой вопрос кое-что говорит о спрашивающем. Вероятно, он не дурак (хотя можно попробовать уточнить, а то вдруг он списал этот вопрос в интернете). Если это правда, то надо ли вам работать с умными людьми? Ну уж во всяком случае ничего явно плохого в этом нет.
dim2r
можно быть очень умным, но использовать ум не по назначению
sshikov
Можно. Но и это вы частично сможете оценить, если вам зададут такой вопрос.
dim2r
Я сталкиваюсь с ситуацией, когда на интервью спрашивают умные вопросы и кажется, что проект будет очень умным. Но потом окунают в махровый легаси, бесконечную рутину и паранодальную систему защиты. Хочешь заниматься умными вещами — устравайся в НИИ, а не на кровавый энтерпрайз.
Nalivai
Это вы где в России видели НИИ с умными вещами?
dim2r
Я пару лет практиковался в новосибирском институте ядерной физики. Там есть очень интересные проекты, в том числе и сотрудничество с ЦЕРНом.
pprometey
Вот только оплата труда там не очень интересная.
dim2r
Там как повезет, скорее проблема с жильем. А зарплату можно приличную получать, если крутиться, ездить по командировкам, участвовать в конкурсах.
Mirn
т.е. мало заниматься или вообще не заниматься наукой?
тогда какой смысл?
qw1
depadep
Мне приходилось и задачки решать, и даже тесты на IQ проходить после 25 лет работы в IT.
Ощущение двоякое. С одной стороны чувствую, что решение задачи на скорость мало говорит о том, насколько я программист. Я даже в шахматы блиц не играю, хотя классику могу более-менее пристойно для любителя.
С другой проблема того, как понять кандидата за час действительно есть. Когда сам собеседую, предпочитаю дать несложную задачу на дизайн/рефакторинг без единственно правильного ответа — для того, чтобы понять как кандидат рассуждает и какие у него стиль кодирования.
dim2r
В некоторых конторах проводят интервью по душам. Вместо 300 вопросов по с++ просто в свободной форме расскажи о себе. Если кандидату дают кредит доверия, то он почему-то проявляет себя лучшим образом и готов вкладываться в развитие.
DrunkBear
Наиболее правильный, на мой взгляд, вариант: в процессе рассказа можно уточнять детали и уходить вглубь, спорить и предлагать конкретные минизадачи, которые имеют прямое отношение к работе.
Ну или услышать «диплом купил, сам ничего не писал, хочу хотя б 100 тыщ» и не тратить время.
Tantrido
Да, только почему-то на такие конторы попадаешь редко. Один раз просто написал в cover letter опыт 10+ лет в требуемой технологии — взяли сразу без интервью и собеседований — ВООБЩЕ НИЧЕГО!!! Справился, потом были очень довольны моей работой и оставили хорошие рекомендации.
Tantrido
В принципе мне подобные практические собеседования нравятся больше, чем те, что были раньше, когда компании нужен не программист решающий задачи, а ходячий справочник по технологии, например .Net. Но если в 16-м на работу взяли сеньором моментально и без проблем после решения тестовой задачи (на решение дали сутки) + резюме, github и LinkedIn, то сейчас даже решение 3-х задач на отлично на codility за 2.5 часа и успешно пройденное затем техническое интервью не гарантировало получение работы — бред.
Затем в другой очень известной фирме с высокими зп тоже напрягся и решил эти тестовые задания на codility. На решение дали уже меньше — 1.5 часа, что непонятно: спортсменов по программированию или рабов на галеры нанимают: даже тестовые задания нормально не успеваешь составить на проверку и производительность кода. Но потом этот бред продолжился: тестовые задания дали ещё и на последующем техническом интервью, только решить уже нужно было в присутствии интервьюера за 15-20 мин — решил за 21 мин — отказ. Что происходит?!
Уже нарешался этих задач на codility массу — аллергия на них уже, если б это ещё получение работы гарантировало. Они могут мои предыдущие тесты посмотреть?! ;)
Tantrido
Полностью с тобой согласен, у меня как раз 15+, но приходится смирять гордыню и самомнение и на общих основаниях со всеми проходит, хотя возможно что-то изменится. Возможно в себе нужно что-то менять.
Acuna
Простите, а можно пояснить для неопытных эту фразу?)
sovetnik
Не взлетит.
Acuna
Оу, ясно, спасибо, а кто в этой ситуации взлететь-то должен, стартап, или человек на должности?
dkasyan
ПО.
snuk182
СЕО моей первой компании рассказывал анекдот, чем отличаются программисты СНГ от программистов повосточней. Действие происходит задолго до моды на аджайл и прочие техники контроля проекта.
Приходит ТЗ двум командам, востоку и нашим — создать бетонный самолет.
Первые говорят — нефик делать, месяц работы. Заказчик приходит через месяц — стоит бетонный самолет. Красивый, большой, документированный.
Наши говорят — два месяца, приходите. Заказчик возвращается в назначенный срок. Стоит паровоз. Обычный паровоз, не бетонный, на колесах, на рельсах, пыхтит.
Acuna
О, во, благодарю, то, что я и хотел услышать! :)
Spaceoddity
Мне вот как-то ближе первый вариант. Нет в ТЗ — идите нахрен! А то понаплодят менеджеров, а задачи никто формулировать толком и не умеет. Постоянно приходится что-то доделывать, переделывать, на будущее потенциальное расширение проекта какой-то резерв оставлять (наверняка будут ещё то-то прикручивать — сделаю выход для него).
slonpts
Вообще это часть работы Senior Developer — рассказывать заказчику, что он может упускать из виду.
Потому что
а) заказчик может не быть специалистом во всем, что ему надо (например, некоторые заказчики могут просить сделать полностью одинаковый интерфейс для андроида и айфона)
б) некоторые противоречия становятся понятны только в процессе решения задачи
Если разработчик не пытается выяснить, что именно надо заказчику и объяснить ему последствия его решений, я бы не сказал, что это Senior.
Spaceoddity
Как-то вы странно обязанности распределяете… Как по мне, то этими делами должен заниматься менеджер или продюсер.
Но даже тут постоянно возникают заковыки — когда ты пытаешься менеджеру объяснить даже не какие-то технические аспекты, а просто логические — условное:
— так нельзя сделать, потому что если юзер введёт имя длиннее 15 символов, то…
— так сделайте поле в 25 символов!
— а если в имени будет 30 символов (Характерный момент — обычно технари при проектировании не сходят на конкретику, а закладывают все возможные варианты. Т.е. оперируют алгеброй, а не арифметикой. Гуманитариям же кажется что достаточно поднять лимит и проблема решена)
— сделайте поле в тысячу символов!
— тогда это поле не влезет ни в один интерфейс!
Zoolander
слава богу, что поля ввода на самом деле имеют внутренний скролл и в визуально узкое поле можно вводить хоть все сочинение Льва Толстого
snuk182
— Когда я копирую в поле логина содержимое третьего тома Войны и Мира, у меня зависает браузер! У вас баг на сайте!
Zoolander
пожалуйста, киньте скриншот с полным содержимым Войны и мира
вариант:
— укажит софт, который позволил вам выделить и скопировать третий том без зависания
PS: отмена!
обычный браузер позволяет легко выделять и копировать третий том
при попытке вставления в разные формы ввода в том же браузере было получено
— просто не реагирование формы вообще
— Некоторые при вставке из буфера — просто обрезали текст до минимальной величины
— зависания получено пока не было, но я не настоящий QA
dimm_ddr
И этот диалог про поле ввода великолепно объясняет почему формирование ТЗ — это общая работа. Что разработчик хочет от менеджера? Чтобы тот угадал нравящееся разработчику решение? У менеджера есть заказ от клиента в котором есть поле для ввода имени. Он это требование передал разработчику, дальше уже задача разработчика (тестировщика, аналитика, технаря с рандомной должностью созданной специально для таких вещей) определить возможные технические проблемы и пути их решения, описать эти пути с плюсами и минусами и заставить менеджера сделать выбор (либо заставить менеджера пнуть клиента чтобы выбрал он). Эту ситуацию невозможно решить только с одной стороны. Ну то есть возможно конечно, но именно из таких решений и появляются потом анекдоты про бесполезных менеджеров и бесполезных разработчиков.
RiseOfDeath
Вообще-то это задача аналитика переводить с клиентского на программистский.
depadep
Это если есть аналитик
Xandrmoro
Даже если его нет, то кто-то же этим занимается. Это задача аналитика как функции, а не как отдельного человека, и условный сеньор может эту функцию как исполнять, так и нет.
depadep
Верно.Часто это делегируют техлидам или тимлидам (если они программисты). В нашем случае подключают еще и архитекторов.
VolCh
Это если в процессе работы предусмотрена функция аналитика. Кто её исполняет отдельный вопрос, но её просто может не быть во флоу разработки.
Wesha
Уточняющие вопросы, говорите? Их есть у меня! Усаживайтесь поудобнее, мы здесь задержимся надолго.
slonpts
Конечно, надо подходить к вопросу разумно. Текст прекрасен как шутка, но если всерьез, то просто надо сразу спросить, почему нельзя использовать стандартную функцию.
А иногда заказчик сам не понимает, как ему надо. И тогда разумно предложить "сделаем пока так, а если что — переделаем". Как правило, останется как есть — т.е. заказчика все устраивает.
dim2r
Иногда можно не выяснять все до конца, а написать самодиагностирующуюся программу. Если все выяснять, то заказчик потеряет терпение.
RomanPyr
Это должен аналитик делать, а не разработчик. Даже старший.
VolCh
А вы знакомы с документами типа https://classinform.ru/profstandarty/06.035-razrabotchik-web-i-multimediinykh-prilozhenii.html. Раздел B части трудовые функции
RomanPyr
Если вы требуете точно ТЗ, то пишите сразу «без багов». Так не бывает? Вот и «точного ТЗ» не бывает.
scruff
А по-моему это отсыл к недавней катастрофе Б-777. Там вроде выяснили что ПО писалось
через одно местоиндусами за 2$/час.monah_tuk
737 MAX? (MAX имеет значение, т.к. 737 сам по себе уже достаточно старый самолётик)
scruff
economictimes.indiatimes.com/industry/transportation/airlines-/-aviation/boeings-737-max-software-outsourced-to-rs-620-an-hour-indian-engineers/articleshow/69999513.cms
khabib
При этом проблем с софтом как раз и не было. Все работало, в соответствии со спецификациями предоставленными, инженерами с зарплатой >200к в год
scruff
Как раз наоборот — в статье написали что QA делали индусы, нешарящие в авиации.
khabib
Как раз там написано:
В соответствии со спецификациями, MCAS работал правильно
scruff
Тем не менее «грамотно» оттестированный индусами и «работающий» MSAC привел к трагедии. А если бы большие дяди не экономили бы «на спичках» и заказали QA где-нибудь поближе чем Индия то всё обошлось бы.
khabib
Попытка переложить ответственность на субподрядчика, который выполнил проект в соответветствии со спецификациями заказчика?
Ошибка сделанная Боингом — системная/архитектурная, никакое стороннее тестирование MCAS как отдельного модуля на соответствие спецификации, не выявило бы проблему, что этот модуль полагается на данные только от одного датчика.
Это было решение индусов, не распространять информацию о появлении новой системы среди пилотов?
Это вина индусов, что пилоты оказались не готовы к «штатному» отказу «самовольная перекладка стабилизатора»?
Кроме того, презрительный комментарий по поводу 9$ в час — это 90к рублей в месяц. Какие там зарплаты сейчас у Сухого или Яковлева?
Carburn
9$ это цена, которую выставляет компания, а не конечная зарплата разработчика.
khabib
Компаний выставляла цену в 20-25 баксов в час и в изначалных статьях фигурировала эта цифра. Это уже позже, пересчитали предполагаемую цифру, которая доходила до разработчика (блумберг, кажется, был этим первым сайтом)
scruff
Вы внимательно читали мой комментарий? Я индусов винил? Нет. Они возможно сделали всё в рамках своих компетенций и тех «дырявых» спецификаций, что дал заказчик. Плюс еще дело в экономии в ИТ. Там где есть возможность сделать за 9уе вместо 20уе — всегда выберут 9уе (по крайней мере по такой цене продаются индийские гребцы исполнителем, по факту получающие может и меньше 1уе) — даже если на кону жизнь людей. Ведь всегда в случае всего можно спихнуть вину на технарей, не важно кто это будут — индусы, европейцы, китайцы, женщины; большие дяди как были на своих постах — так и остались. Что касаемо Сухого — я не знаю (и не обязан знать) что там у них с QA, но последний пожар на гражданском судне вряд ли заставит адекватного человека подумать, что «новый» Суперджет безопаснее 15-летнего Боинга\Эйрбаса\Эмбраера. Як? Гражданский? Вы серьезно? Кроме Як-40 за последние 10 лет из этого «бренда» я не видел ничего, да и то на задворках аэродрома с демонтированными движками.
khabib
Определенно, да. Иначе я не знаю, как можно было прочитать этот комментарий:
В итоге мы выяснили, что проблема не 9$ баксах в час, не в индусах и не в софте
scruff
Тогда в чем проблема по вашему? Продолжайте мысль…
pprometey
Рыба как обычно гниет с головы.
khabib
А это как разз не так и сложно:
— Топ менеджеры, которые доят бренд 737го слишком долго
— Маркетологи, которые продали MAX как «тот же NG, только новый и экономичный». Переход с NG на MAX это 1 день наземного тренинга.
— КБ и главный конструктор, который допустил что в самолете есть система без дублирования
— Авиаконтролирующие органы (как в Штатах так и международные), которые сертифицировали этот самолет
— Авиакомпании, которые заставляют пилотов летать только на автоматике, с минимум практики управления руками. (Сгоревший суперджет, это как раз туда же)
— Пилоты, которые молча хавают и соглашаются с этой политикой.
Но сми форсят факт «это просто индусы наговнокодили»
Kodiak
>… но последний пожар на гражданском судне вряд ли заставит адекватного человека подумать, что «новый» Суперджет безопаснее 15-летнего Боинга\Эйрбаса\Эмбраера.
Ну вотт новый Суперджет поимел проблемы при посадке с превышением посадочной массы после удара молнии — ~половина выжила.
«Штатная» работа одной систем Боинга — выживших немае.
Странная нонче адекватность у людей.
Wesha
Простите покорно, но "новый Суперджет поимел проблемы при посадке" всё же не "из-за превышения посадочной массы", а потому, что доходяга-пилот его об полосу бил-бил, и на третий раз таки разбил (смотрите сами). Как-то так.
Kodiak
Ну, тут пишут про перегрузки именно для посадки с превышением, а РТЭ мне, в отличие от РЛЭ (в котором отдельным пунктом посадка с превышением посадочной массы тоже есть), что-то нагуглить сходу не получилось.
Так что косяки пилотов косяками, но и помимо этого ИМХО были объективные факторы.
vladkorotnev
9 баксов в айти за бугром это очень мало для такого ответственного проекта. Я по молодости даже вмордпресс не допиливал на фрилансе меньше чем за 20. При отсутствии менеджмента и прочего бюрократического буллшита, с ним — нужно больше.
monah_tuk
Моя поправка была относительно модели самолёта, у вас — 777 указан.
deemytch
Поищите историю с Боингом, это недавнее. Они наняли индусов для своего ПО с ожидаемым анекдотическим результатом.
wataru
Там не проблема в ПО, а в менеджерах и вызванном этим плохом инженерном дизайне. Из-за маркетинговых требований пытались сделать новый самолет с точки зрения пилота точно такой же, как старый, только более эффективный. В итоге нагородили всяких костылей типа этого MCAS, который управлял самолетом игнорируя пилота и зависил от одного единственного дешевого датчика, который, сюрприз-сюрприз, иногда выходил из строя.
Если бы этой особенности уделили достаточно внимания при тренировке пилотов — трагедий можно было бы избежать, но для поддержания иллюзии "совсем как старый, только лучше" этого не делали.
Igor_O
Странно, что вас в принципе позвали на собеседование. В нескольких компаниях до сих пор висят открытые вакансии по моему профилю, на которые я многократно отправлял резюме. Даже ни одного просмотра резюме. Прошло пять лет уже. Вакансии — до сих пор открыты!
Почему? А госконтракты. По некоторым из них у исполнителя должно быть X специалистов по специальности Y. «Смотрите! У нас тут открыта вакансия по специальности Y и уже есть 100500 откликов на эту вакансию, мы уже завтра наймем человека!»
snuk182
Широко известная в узких кругах зарубежная финансовая контора. Там точно не госзаказ.
CrushBy
Проблема в том, что это все меняет мотивацию разработчиков. Нужно не учиться хорошо программировать, а учиться проходить собеседования. У меня есть знакомый, который начал прокачиваться именно в этом навыке, и потом менял работу каждые полгода, на каждом новом месте увеличивая себе зарплату на определенный процент исключительно за счет того, что мастерски проходил собеседования.
Lezenford
Вам это не напоминает грустную тенденцию в школьном образовании последних этак лет 15? Если что, я про ЕГЭ и ГИА, которые точно так же натаскивают на решение задач (тестов), а не на реальные знания)
Evgenym
Реальность диктует такие требования, поэтому людям приходится под них подстраиваться, чтобы
выжитьдостичь успеха в социуме. Мотивация проста: не сдашь ЕГЭ -> не поступишь -> не получишь диплом -> не устроишься на нормальную работу. Когда я заканчивал школу, цепочка была такая.CrushBy
Это в любой системе так, когда ставится KPI. И тогда все начинает сводится к достижению этого KPI любой ценой, даже с ущербом всех остальных показателей. Но проблема в том, что без KPI и оценок многие не могут. Возьмите, например, кол-во лайков и подписчиков в соцсетях. Для многих это превращается в смысл жизни.
Xander_Vi
К сожалению, вы правы, причем буквально. Недавно читал статью (сейчас не найду ссылку, к сожалению) о том, что в мире ежегодно несколько сотен людей совершают суицид потому, что их публикации в Инстаграм набирают слишком мало лайков (относительно того, сколько им хотелось бы) или потому, что их публикации набирают меньше лайков, чем публикации их друзей.
Nalivai
Это проблемы ментального здоровья уже, не будет лайков, будет что-то другое, не в них дело, в общем-то. Люди всегда мерялись письками, и всегда будут.
VlK
С другой стороны, как вы в большой организации будете проверять адекватность работы отделов? Нет KPI — нет оценки, и в этой ситуации часто разводится имитация бурной деятельности.
CrushBy
Да, так и есть. Без KPI тоже могут быть проблемы. Нужен какой-то баланс.
Gar02
Чтобы проверять адекватность работников с помощью KPI, эти KPI сами должны быть адекватными.
Вот был я в Тунисе. У чистильщика пляжа есть KPI: чистота пляжа. Этот чёрт чистит пляж на тракторе, а потом скидывает весь мусор в море. Зато KPI выполнен: пляж с утра идеально вычесан от мусора. Правда, море превратилось в дерьморе.
Русские туристы пару раз чуть не побили его, но что ему делать? «Умный» манагер не предусмотрел вывоз мусора. Куда его девать, если за его наличие на берегу тракториста штрафуют?
А вот найти адекватных составителей KPI — нереально. Эти люди должны знать всё об оцениваемом участке работ, а сегодня начальнички «не любят погружаться». Знакомая фразочка? То-то!
RedTalon
Любой адекватный критерий эффективности перестаёт быть таковым, когда становится известен оцениваемому.
Gar02
Такая ситуация — явный признак больших проблем в управлении. Там, где молятся на показатели, люди стремятся только к достижению показателей.
Тунисский пляж, короче говоря.
vvbob
Если человек точит гайки, и эффективность его работы оценивается качеством (размеры и форма в пределах допусков) и количеством выточенных гаек, то никаких проблем в том что он знает критерии нет. Скорее наоборот, лучше до него сразу же их доводить.
С разработкой так не работает по той причине что большую часть выполняемых работ невозможно исчерпывающе описать и задать адекватные критерии качества.
Разработчики ребята в основном неглупые и ленивые, и всякие KPI часто воспринимают как вызов, сам даже за собой замечаю. Вы мне KPI, а я вот найду способ нихрена не делать и иметь самый высокий из возможных KPI, не потому что так уж хочу ничего не делать, а просто из спортивного интереса :)
pprometey
Вот есть хорошая статья на Хабре по этому поводу (не в смысле челленджа, а в смысле объективной оценки работы разработчика)
Оцениваем разработчика на основе объективных данных
vvbob
Читал раньше, благодаря вам перечитал еще раз. Статья любопытная, но кмк, это немного более запутанная разновидность оценки качества работы по количеству строк кода, приведшая к знаменитому «индус-кодингу».
Единственный нормальный вариант, на мой взгляд — работа относительно небольшими командами, в таких командах все на виду и халявщики особо не побездельничают. Коллеги лучше видят кто чем занимается, кто пашет, а кто фаллосы пинает. Просто руководству надо больше внимания уделять коллективу, общаться и люди сами все расскажут как есть, без всех этих шаманских KPI.
pprometey
Короче первый принцип agile рулит — люди и их взаимодействия важнее процессов
VolCh
Перевести их на то, что лет 30 назад в Союзе называли "хозрасчёт".
altai2013
ЕГЭ — это экзамен, он не может ни на что натаскивать. Знания получают до экзамена, а не во время него. Если человек с «реальными знаниями» не может сдать тест, значит у него банально нет знаний. В тестах спрашивают ровно то, чему учили. Никто не просит в тесте по математике сплясать гопака. В этом и разница с собеседованием на работу, когда знания спрашивают в одной предметной области, а работать потом приходится в совершенно другой.
Lezenford
Сразу чувствуется, что вы закончили школу не меньше чем лет 13-15 назад и у вас еще нет детей старшего школьного возраста.
На самом деле сейчас выпускные классы сводятся именно к натаскиванию на решение определенного шаблона проверки знаний. Зачастую вам не пытаются составить всю структуру знаний, а дают именно подход для корректной сдачи экзамена. При этом в реальности человек может вообще не понимать, как эти знания применять. Точно как в примере с собеседованием — проходить умеют, а работать — нет.
ЗЫ это субъективный опыт, основанный на собственно сдаче (больше 10 лет назад) и на том, как учатся на текущий момент младшие братья\сестры жены, аккурат возраста сдачи ЕГЭ и ГИА…
dimm_ddr
rkuvaldin
А вы попробуйте сходить и сдать ЕГЭ. Чисто для себя, чтобы убедиться, что получить там сотню — плёвое дело
Его ведь может сдать любой человек :-)
Lezenford
Уверены что комментарий ко мне? Я то его уже сдавал и знаю, как к нему готовятся и что там спрашивают. Человек с улицы на 100 баллов ЕГЭ не сдаст) даже если у него за спиной красный диплом и отличные знания) У меня много примеров перед глазами было, кто готовился\учился в спец школах для одаренных и прочее, кто в итоге сдавал хуже тех, кто просто зубрили 2 года подряд и монотонно решали тесты)
Ametrin
За 10 лет форма заданий в ЕГЭ поменялась) да даже в те времена зубрежом можно было обеспечить себе не более 50-60 баллов
Lezenford
Т.е. я могу вас поздравить с 100 баллов который вы получили за экзамен в последние пару лет?) Тогда я за вас рад) Но вы скорее исключение, чем правило. 300 бальников даже на фоне страны не так много)
Ametrin
Эм, с чего Вы взяли, что у меня 100 баллов?) Как и у многих, у меня баллы посрезались на незазубриваемых задачах в основном (последние задачи С части, и сочинение по русскому подвалил).
За все предметы не скажу, но, объективно, ЕГЭ по информатике усложнился за 10 лет.
А еще я тоже сдавал ЕГЭ 10 лет назад)
Lezenford
Тогда вынужден признать, что фразу
>А вы попробуйте сходить и сдать ЕГЭ. Чисто для себя, чтобы убедиться, что получить там сотню — плёвое дело
Его ведь может сдать любой человек :-)
Я до конца не понимаю) И это либо сарказм либо это сильно выше моего понимания)
Ametrin
я воспринял ее как сарказм..)
siziyman
ЕГЭ и ГИА — прекрасная система. Идея и фундамент правильные. Проблемы бывают чисто прикладные (коррупция и низкая квалификация исполнительных органов на разных уровнях, неидеальный набор заданий), но идея однозначно лучше, чем то, что было до этого.
Кстати, то, что остатки хвалёной советской системы образования с трудом справляются с тем, чтобы подготовить среднего школьника к сдаче довольно простого (пока вы не целитесь в 80+, большинство экзаменов не очень сложные) экзамена без зубрёжки — это больше говорит об этой самой советской системе образования, чем о ЕГЭ и ГИА.
Lezenford
а я не говорю, что СИСТЕМА плохая. я говорю о том, что в реальности показатели подгоняются под эту систему проверки, а не на что то практически правильное.
Т.е. это косяк реализации, а не косяк самой абстрактной модели и ее целей\задач
Matisumi
До этого была гораздо более прозрачная система. Абы какие выпускные в школе (потому что ну реально, кому они вообще нужны?), а потом уже подросток сам решает что хочет делать — в армию, в ПТУ, или в институт. Если в институт — то в какой? И от этого уже зависит что он будет сдавать на вступительных и в каком объеме.
siziyman
Да и сейчас решает.И сейчас зависит, набор предметов и разница между профильной и общей математикой определяется именно тем, куда вы будете поступать.Универсальный стандарт, определяющий. что вузы набирают не «кого понравится», а людей, которые по некоторому универсальному показателю показали себя лучше остальных — однозначно вин, это не обсуждается даже.
Ctacfs
Егэ не решение проблемы коррупции на вступительных экзаменах, оно конечно решило эту проблему, но привнесло еще кучу новых в и без того полную проблем систему образования. Вузы теперь вынуждены снижать свою планку до уровня егэ, либо терять студентов. Выпускники спецшкол с углубленным изучением теряют преимущество.
Вуз должен набирать тех, кто понравится вузу, а не государственным экзаменаторам. Выпускной экзамен не должен заменять вступительный.
siziyman
Государственный вуз, работающий на мои (и, вероятно, ваши — вы же тоже в/из России, как я понимаю) налоги не имеет никакого права набирать «кого понравится», должны быть объективные критерии.
VolCh
Объективные критерии: результаты вступительных экзаменов. Пускай в той же форме, что ЕГЭ, но вот содержание каждый вуз точно должен иметь право выбирать сам.
dimm_ddr
Если содержание может быть любым, а не из заранее определенного списка, общего для всей страны, то мы вернемся к платным группам подготовки от института и фактическому ограничению в 1-2 возможных нормальных ВУЗа на выпускника. Потому что подготовится к большему количеству разных экзаменов (а они будут разными — нужно же стимулировать платить за подготовку) у абсолютного большинства выпускников не получится. То есть ровно та ситуация которая была до ЕГЭ. И это именно те причины по которым ЕГЭ вообще был создан — коррупционность зашкаливала просто. И я даже не говорю про взятки (которых тоже стало меньше с вводом ЕГЭ), речь о том что это достигалось совершенно легальными методами — специально подготовленными ВУЗом задачками которые практически нереально решить не узнав способ решения на платных курсах.
Ваш вариант работает только в случае если приемом занимаются кристально чистые люди на всех уровнях.
siziyman
Нет, не должен, потому что это замыкает проверку на сам вуз.
Государственный вуз, а мы говорим о них, это не частная организация. Это организация с как минимум частичным бюджетным финансированием, которое осуществляется в том числе из налогов. И такая организация не должна принимать решения по воле левой пятки учёного совета или отдельных людей в структуре вуза, потому что чем больше власти замыкается на этих людей, тем меньше вероятность того, что эти решения будут приниматься ангельски честно. Они уже так не принимаются, это я вам как недавний студент скажу — в вузах очень много внутреннего политиканства, стремления ухватить побольше денег из самых разных источников, и так далее.
Автономный внутренний экзамен — это очень хорошая мотивация делать курсы в ключе «готовься у нас или
умрине поступишь». Это, а также банальное количество таких разных экзаменов, лишает умных детей, которым не повезло родиться не там, готовиться к другому вузу, и т.д. поступить в хороший вуз, просто потому что учёному совету надо потешить ЧСВ.Matisumi
Можете обосновать необходимость выпускных экзаменов в школе?
siziyman
Нужен общий стандарт либо выпускных, либо вступительных экзаменов, чтобы несколько выровнять шансы людей на поступление в хороший вуз по признакам, отличным от социально-экономических в чистом виде (родился в правильном семье, живу в нужном городе, грубо говоря).
Ctacfs
Программа образования безусловно плохая, но как ее можно ругать за то, что она не соответствует экзамену, который ввели после нее? Егэ прекрасный пример реализации через задницу. Выпускной экзамен должен проверять качество образования, которое дала школа, сначала нужно было приводить в порядок образование.
VolCh
Система оценки знаний может и хорошаяя, но вот использование её в качестве основного критерия приёма в вузы — нет.
siziyman
Знания студентов должны быть единственным критерием приёма в вузы, помимо eligibility (вы закончили 11 классов школы, вы имеете право претендовать на бюджетное обучение, если мы говорим о бюджете, и т.д.). Соответственно покуда ЕГЭ — лучшая из существующих в России систем объективной и комплексной оценки знаний студентов, результаты ЕГЭ — лучший критерий для приёма в вузы, да, именно так.
VolCh
Это по вашему мнению это лучшая система оценки знаний.
Nalivai
Да ладно, я учился до ЕГЭ, и абсолютно та же ситуация была, разве что натаскивали не на ЕГЭ а на контрольные.
rkuvaldin
И вступительные.
Прямо в ВУЗах обычно были подготовительные курсы, которые натаскивали на вступительные конкретного ВУЗа, в которых было грубо говоря три нормальные задачи, и три — с «хитринкой», о которой рассказывали на подготовительных. И не учась там, вступительные экзамены было сдать довольно сложно.