Комментарии 461
Тема про БАЗУ вытекает из того, что 90% интервьюеров - лентяи. К собесу надо готовиться с обеих сторон. В резюме надо вчитываться и корректировать свой пул вопросов под конкретного человека, продумывать тактику разговора. Но зачем, если можно подрочить в сотый раз устройство хэшмапы и шлифануть литкодингом. Говорю это как интервьюер, если что (надеюсь, что не лентяй).
А в чем собственно проблема вопросов по базе? Если человек действительно эксперт то легко ответит на них за 5 минут и дальше можно перейти к чему то более интересному, а вкатыши в айти которые знают только то с чем работали и нафиг не нужны. Понятно что как контр аргумент можно сказать что это ж можно зазубрить и пройти фильтр. Ну в целом можно но практика показывает что люди ленивы и таких зубрил по пальцам пересчитать можно к тому же если человек способен зазубрить то и в работе у него все будет хорошо.
А в чем собственно проблема вопросов по базе?
Проблема в том, что у лентяев ничего, кроме этих платиновых вопросов, в запасе нет.
Если человек действительно эксперт то легко ответит на них за 5 минут и дальше можно перейти к чему то более интересному
К тому, в чем разница между ArrayList и LinkedList? Или чем в спринге синглтон от прототайпа отличается? Было б смешно, если б не было так грустно. Я специально хожу по собесам как кандидат с целью найти интересные вопросы и темы для моих собственных собесов. Вдохновиться, так сказать. Так вот за последние полгода улов нулевой. Мне просто досадно, что я трачу по полтора часа на очередное обсуждение "Top 50 Java questions you should know"
Мне просто досадно, что я трачу по полтора часа на очередное обсуждение "Top 50 Java questions you should know"
Потенциальные работадатели, наверное, тоже переживают, что в очередной раз потратили полтора часа на чтобы подсказать интересные вопросы кандидату, который не собирался у них работать. Баланс ))
Все зависит от того зачем эти вопросы задаются, если человек не знает чем отличается связный список от массива это уже звоночек. Вы пойдете к врачу который не знает "базу" и умеет лечить только то что лечил на прошлом месте? Я думаю что нет, почему тогда в мире ИТ это норма?
если человек не знает чем отличается связный список от массива это уже звоночек
Для препода с универа может и звоночек, а для меня нет. Я считаю, что можно писать ПО и без этого. А звоночек для меня, это, например, когда сеньор-помидор декларирует знания трех фремворков и двух баз данных, а потом не может объяснить, чем эти продукты друг от друга отличаются, что для каких случаев лучше подходит, и за счет чего одно работает быстрее другого.
Вы пойдете к врачу который не знает "базу" и умеет лечить только то что лечил на прошлом месте?
Ок, берем врача ЛОРа педиатора. Лечит детям уши. Лечит хорошо. И тут мы ему вопрос по анатомии малого таза, а потом пусть все ферменты поджелудочной железы перечислит, а потом пусть вспомнит названия всех слоев мозга на латыни.
Меня смущает, когда такие вопросы начинают задавать миддлу на разгребание легаси, в котором сложившуюся архитектуру уже дёшево не поменять.
Особенно когда бенчмарки фреймворков и БД меняются от версии к версии.
ЛОР должен знать группы крови и как минимум должен смочь прочитать результаты анализа крови даже если не гематолог. Если вилку из глаза в живот то это не доктор.
Когда Вы идёте к ЛОРу за лечением проблем, которые лечит ЛОР, то Вы будете гораздо более счастливы, если он эксперт конкретно в своей области, который не тратит своё время на знания, которые для конкретно его работы помогают мало. Нужен специалист широкого профиля — идите к терапевту, он вероятно отправит к нужному доктору, но не всегда. И уж вряд ли вылечит что-то сложнее ОРЗ.
База необходима даже ЛОРу. Допустим он видит запредельное количество лейкоцитов в анализе крови. Он не спец по раку, но может послать человека к другому специалисту. Это как в программировании. Фронтэндщик может проигнорировать неправильный ответ от сервера, типа моё дело маленькое, не работает да и хрен с ним. А может подойти к бекендщику и грамотно рассказать о проблеме. Вся команда только выиграет от этого.
ИМХО, количество лейкоцитов в крови обычно терапевт смотрит. И только если видит, что надо к ЛОРу, то отправляет к ЛОРу.
Я, к сожалению, часто хожу по врачам. И пришел к выводу, что к любому врачу лучше идти с анализами. Да, они не всегда нужны, да не всегда их просят. Но я много раз нарывался на то, что даже ЛОР просит анализы. Более того, у меня несколько друзей врачи-стоматологи и все они умееют читать базовые анализы, кардиограмы и ти д. - курс базовой медицины преподают всем. Да, они не скажут по анализам что с вами не так, что за болезнь (это, к сожалению, даже специалисты не всегда скажут), но увидеть аномалию и отправить к врачу смогут.
Во-первых, никто не идет к лору чтобы тот посмотрел анализ крови, во-вторых, лор может это знать, но поскольку нормальные люди пойдут к нему не с анализом крови(возможно в каких-то конкретных случаях это играет роль, но в большинстве своем нет), а со своими проблемами касающихся лора, то он может знать как читать анализ крови, даже анализ кала и мочи может разобрать, но будь я лором, я бы точно был недоволен, если бы ко мне ходили чтобы я анализ мочи и кала разобрал, у меня задачи другие, это не моя ответственность и обязанность, так что даже если в твоем примере фронтэнд не пойдет рассказывать о проблеме, никто не имеет права его винить, это косяк бекэнда и тут роль человеческое отношение играет, не более
Врач любого профиля должен выловить любую экстренную патологию и оказать помощь, либо вызвать бригаду. По плановым патологиям та же история. Я могу не знать деталей диагностики сложной неврологии, но распознать гиперкинез и направить к неврологу должен.
Короче, врач по чужой области должен сработать как корректный маршрутизатор. В идеале - связать в цепочку со своей патологией, если применимо.
ЛОР должен знать группы крови и как минимум должен смочь прочитать результаты анализа крови даже если не гематолог. Если вилку из глаза в живот то это не доктор.
Группы крови может знать любой школьник. В базе их 4*2. А на самом деле их там сотни.
Что же касается "прочитать результаты анализа крови", то по анализу крови ЛОР никак не распознает что у пациента, например, подозрение на рак. Ибо изучал другие направления. И запредельное количество лейкоцитов может быть не только рак, а например простуда, воспаление, беременность, инфекция...
И вообще для рака может быть характерно не запредельное количество, а наличие слишком молодых лейкоцитов, которые по формуле далеко не каждый врач может нормально распознать.
Ну ок, то есть ЛОР по вашему у умирающего должен вылечить ухо и послать домой.
Я к тому что нормальный программист, даже не разбираясь в технологии используемой в соседнем отделе, может бегло просмотреть код и указать на очевидные ошибки. Чем принесёт пользу общему делу. А миддл клепающий формочки придёт в 9 уйдёт в 5 и ничего его не волнует.
Ну ок, то есть ЛОР по вашему у умирающего должен вылечить ухо и послать домой.
Если к нему пришли с больным ухом, то он должен лечить больное ухо. Вопрос скорее в том почему терапевт направил человека в таком состоянии только к ЛОРу.
Я к тому что нормальный программист, даже не разбираясь в технологии используемой в соседнем отделе, может бегло просмотреть код и указать на очевидные ошибки.
Если у человека грубо десятисантиметровые лимфоузлы, то ЛОР на это тоже сможет указать.
А миддл клепающий формочки придёт в 9 уйдёт в 5 и ничего его не волнует.
Нормальный программист тоже может придти в 9 и уйти в 5. Или там решить что дела другого отдела его не касаются.
а зачем нормальный программист должен лезть в чужую работу и почему он не может прийти в 9 и уйти в 5?
Если речь не идёт о госконторе то коммерческая фирма зарабатывает деньги. Если из-за косяка сервер упадёт или клиент разорвёт контракт фирма закроется и программисту придётся искать работу. И наоборот, если его наблюдательность или сознательность улучшит работу сервиса ему будут благодарны, фирма улучшит материальное положение и возможно выпишут бонус.
Знакомому в похожем случае оплатили поездку в США, он был доволен.
Так а зачем ему задерживаться? Пусть его наблюдательность и сознательность поможет ему сделать сервер перезапускаемым и готовым к нагрузкам, чтобы спокойно работать с 9 до 5 и ему, и всем остальным.
Коммерческая фирма так же будет довольна.
Программист не обязан брать ответственность за выполнение бизнес-целей и не обязан заниматься риск-менеджментом. Если фирма закроется - туда ей и дорога. А программист всегда нацдет новую работу поскольку - востребован.
Если речь не идёт о госконторе то коммерческая фирма зарабатывает деньги.
А сотрудник зарабатывает деньги выполняя свои должностные обязанности в рабочее время. Доход сотрудника в подавляющем большинстве случаев не привязан к доходу фирмы, а устанавливается рынком труда
Если из-за косяка сервер упадёт или клиент разорвёт контракт фирма закроется и программисту придётся искать работу
Тут вопросы к рабочим процессам: если сотрудник может сломать так, чтобы прод упал и понёс серьёзные убытки не подняв тревогу, то фирма когда-нибудь точно закроется )
ему будут благодарны, фирма улучшит материальное положение и возможно выпишут бонус.
Возможно. А может и не будут. Может просто по плечу похлопают и "спасибо" скажут. Где какие-нибудь гарантии?
то, что кого то где то как то отблагодарили - это повод работать в режиме 24/7/365 ? чем принципиально в этом отношение программист должен отличаться от строителя, водителя, дворника, сантехника? что за непонятные попытки доказать элитарность и незаменимость какой то конкретной профессии?
myvar=${#myvar} && myvar=${myvar,,}Я вот интуитивно подозреваю, что вы не очень разбираетесь в шелле. Подскажите очевидную ошибку в этом коде без гугления?
Вы же считаете себя нормальным программистом?
Это базис. Должен делать любой врач. Как минимум направлять на пересдачу анализа и к онкогематологу, если там НЁХ с анализами.
Ходил я к одному такому ЛОРу горло лечить, месяц потратил, потом поменял врача и за один прием выяснилось что это был рефлюкс. Вот что значит база.
Доктор вполне мог иметь аналогичный случай месяцем ранее. И у вас он просто увидел знакомый паттерн. Вы не можете 100% знать, что тут некая "база", а не обычный рабочий опыт.
Точно так же разраб может решить проблему перфоманса БД не потому, что он собаку съел на реляционной алгебре и внутреннем устройстве СУБД, а просто потому, что разбирал похожий кейс на прошлом месте.
Вот на этом предположении и держится вся ваша аргументация, это не врач профессионал потому что в институте хорошо учился и знает как одно от другого отличить, а просто это ему так повезло и он по приколу в прошлом месяце половину пациентов к гастроэнтерологу отправлял а потом статистику смотрел кого вылечили, а кого нет. Конечно в медицине все так и работает.
Моя аргументация держится на факте, что в дрочильных вопросах о "базе" я сам весьма плох. А в прикладной работе весьма хорош. Я экстраполирую этот факт на других людей и считаю, что дрочильные вопросы сами по себе, а способность думать и решать задачи сама по себе. И именно на этой способности я фокусируюсь во время интервью.
Скажите, вам правда кажется сложным вопрос про AL vs LL? Вопрос без подводных камней, мне действительно любопытно
Позвольте дополнить ваш тезис, коллега, подсократив множество не попадающих в вашу экстраполяцию вариантов: не могу припомнить специалиста по дорочильным вопросам, который хорошо решал бы прикладные задачи. Более того, я совершенно точно не встречал ни одного дрочилу, который решал бы такие задачи однозначно лучше или хотя бы сопоставимо относительно прикладных специалистов.
Если сэкстраполировать данный тезис консолидированно с вашим, то, боюсь, у нас вовсе не останется иного варианта, кроме как сделать статистически обоснованный вывод о том, что степень задрачивания базой В БОЛЬШИНСТВЕ СВОЕМ обратно пропорциональна прикладной полезности специалиста.
Который в общем то можно вывести аналитически, а не статистически: направление умственного ресурса на прикладные задачи освобождает эти ресурсы с поддержки "базы", ненужной для решения этих задач, и чем больше ресурсов будет выделено, тем лучше будут решаться эти задачи и, следовательно, тем меньше будет владение базой (по крайней мере, оперативное). И наоборот.
А уже отсюда, позвольте в силу профдеформации позанудствовать, можно сделать уже следующий вывод: наблюдаемый систематический рост такого подхода в найме свидетельствует как о наблюдаемой общей деградации ИТ-индустрии, как минимум, в стране, так и о неизбежном ускорении этой деградации в ближайшем будущем. Причина такого вывода очевидна: поскольку результат такого подхода в виде перебоев в разработке не приводит к его смене, значит топменеджмент такой подход и, следовательно, перебои, устраивает. Причем систематически, массово. А причиной этого, в свою очередь, может являться только одно: падает востребованность продукта индустрии в экономике. Высокие темы держатся на инерции но привод уже отключился. Далее инерция приведет к переизбытку предложения и случится кризис, если ситуация в идустрии не изменится.
Моя личная гипотеза причин подобного в том, что индустрия начала поедать сама себя, продукт начал создаваться ради продукта, цели начали выдумываться за неимением объективно стоящих, и под этим самокопирующемся шлаком хоронятся немногочисленные (на общем фоне) действительно востребованные решения. Так что, коллега, опасаюсь что эпоха когда программисты будут как бухгалтеры в начале 2000-х, уже не за горами.
Была как-то статья на хабре про специалиста которого попросили решить проблему с нагрузкой сервера. Посмотрел - там и докеры, и кластеры баз данных, и заббиксы, всё в точном соответствии с современными вакансиями. И сам сервис который тупо отдавал условно говоря решение квадратного уравнения.
Спец поднял другой сервер с крошечным скриптом на питоне и рестартом в случае чего, установил на распберри пи и уменьшил расходы фирмы на 500 баксов в месяц.
Наверное потому что базу знал.
Так наверное или нет?
Очень круто, что он подобрал такое решение, но ваш вывод про базу из этого не следует.
Тот специалист может:
- знать базу
- не знать базу
- знать базу но что-то другое помогло ему прийти к этому решению...
- не знать базу, пожалеть что именно ее нехватает, поучить и сделать как сделал.
- много других вариантов...
Кроме этого специалиста никто не скажет, как на самом деле было, помогло ли ему знание базы, было ли у него оно...
Но вы берете и подгоняете вывод под желаемое - это вам знание базы помогло?
Апелляция к личному опыту это не научный метод. У меня, например, другой опыт : люди которые уделяют внимание БАЗЕ (пытаются досконально разобраться как оно работает, в каких случаях что лучше применить и тд.) и в работе показывают лучше результаты. Можно ли именно мой опыт экстраполировать на других людей? Возможно, у техлида из статьи такой же опыт.
Рефлюкс почти у каждого второго. Раздражение горла от рефлюкса — настолько типичный случай, что уже нельзя ссылаться на узкую специализацию. То есть, возникают серьезные вопросы к компетентности.
А когда вы приходите к инфекционисту с ангиной, а он находит болезнь Грейвса только по дрожащим рукам, встречающуюся так редко.... База нужна всем, вопрос только в том, на каком уровне она нужна.
Базедова-Грейвса ни с чем не перепутать обычно) Глаза навыкате, блестят. Пациент часто моргает и выглядит как крысобелка под амфетамином. Это как раз любой врач должен определять.
Сейчас я это понимаю... А в то время меня останавливал каждый сотрудник ППС, т.к. мои глаза ему казались весьма странными. За несколько месяцев до инфекциониста, я посетил окулиста, т.к. сильно болели глаза. Она нашел аллергический конъюнктивит, быстренько его вылечил, а вот глядя на мои глаза к эндокринологу меня не отправил. И в момент посещения окулиста глаза выглядели не лучше, чем в период лечения у инфекциониста, Грейвс был лет 5 наверное как минимум, до начала лечения. Так что да, там может быть и все очевидно, но без знания базы и очевидные вещи не замечаются.
выглядит как крысобелка под амфетамином. Это как раз любой врач должен определять.
Крысобелку не всякий охотовед распознает — а Вы о врачах...
То есть для вас не звоночек что человек не знает структур данных, может выбрать кривую и просадить производительность на ровном месте буквально на порядки? Хотя может конечно у меня уже деформация от плюсов и перформанса, но для меня если человек не понимает структур данных в своём языке это неплохой такой звонок. А всякие новый фреймворки выучить это как раз уже не так страшно если будет нужно.
То есть для вас не звоночек что человек не знает структур данных
Не знать структуры данных, конечно, плохо. Но дело в том, что я не считаю, что отличные ответы по структурам на собесе эквиваленты хорошему их знанию на практике. На моей памяти самые четкие ответы на "как устроена хэшмапа" давали джуны - они же со спокойной душой засаживали в код алгоритмы O(n*n). Сеньор или мидл, наоборот, могут продолбаться на этом вопросе, но код их будет лучше.
Согласен что знать != применять, но не знать это уже скорее == не уметь применять. Но в общем то еще конечно зависит от области, для меня странно если плюсовик не знает как стэк, куча (которые не структуры данных, а память, хотя оно так называется потому что стэк организован как... стэк) работают, как кэши процессора работают и т.д. Хотя я то же самое спрашивал у знакомого пхпшника и он ничего не смог сказать (а я бы ничего не смог сказать про всякие вэб протоколы). В целом в плюсах люди могут сказать на собесах эти вещи (а потом себе ноги отстрелить какими-нибудь более изощренными штуками).
как устроена хэшмапа
Есть некоторая разница между:
- Могу сам написать хешмапу за 20 минут с тестами. Засекайте
- Понимаю как работает. Могу нарисовать, показать, рассказать.
- Я тут плыву, если честно, но знаю когда стоит применять, а когда не стоит.
- Ну это… не знаю что это. Я код из стековерфлоу обычно копирую.
Если человек не отличает связный список от массива, то это 4-й пункт. За таким нужен тщательный присмотр и менторинг.
У меня был персонаж с другим вариантом. Смотрю, там где можно по смыслу использовать мапу он использует массив. Спрашиваю про мапу, чтоб натолкнуть на мысль ее использования - рассказывает все, но он не понимает то, что рассказывает - зазубрено, определение не сопоставляется с реальностью. Попытался на пальцах вместе разобраться - ноль, т.к. практически вся база знаний, мышление так построены. Распрощались, хотя навязали как мидла.
К сожалению, подобное, когда знания не соотносятся с реальностью, а воспринимаются как что-то абстрактное довольно распространенное явление не только в программировании, а в любой сфере. Более того, неадекватное восприятие реальности было обозначено, как одна из трех наиболее значимых проблем современного человечества. Ну, и как тут жить прикажите?! Остановите Землю, я сойду ! :)
О, я такое встречала точь-в-точь на тему изучения английского языка. Пока училась в университете, местным студентам по условиям стипендии, помогала разговориться. Так как у них массовая проблема была - они сдают тесты на отлично, грамматика от зубов отлетает, даже сложная, словарный запас до небес, но говорить не могут.
Один даже пришёл и показал мне две общие тетради, исписанные в каждой клеточке фразами на английском, вопросы, утверждения, на разные темы, и он всё это зазубрил, и даже научился применять (что уже ого-го себе, он очень-очень постарался научиться говорить). Но при этом общаться на живом языке - нет.
Условно говоря, я спрашиваю его, есть ли у него кот дома - да. А какой? Он рассказывает про (например) кота, какого он размера, веса и цвета, и даже что он любит. И, если я задаю какие-то квадратно-гнездовые вопросы, он на них легко отвечает, почти без задержки. И тут я спрашиваю, а есть ли у кота (условное) белое пятнышко на хвосте? И всё, завис человек. При этом он грамматику вопроса знает отдельно, слова все ему знакомы. Но нестандартный вопрос вгоняет его в панику.
А я как бы даже не экзамен, я здесь просто поболтать, но любая беседа, выходящая за рамки учебника, просто не клеится. Потому что у многих не было вообще понимания языка как речи.
Это исключительно проблема преподавателя и методики. У меня есть с чем сравнивать. В школе за ошибку в грамматике ставили два и у нас никто не говорил. А вот как-то попался американский учебник для мигрантов и я в рамках эксперимента взял группу пенсионеров поднатаскать в английском с нуля. Учебник очень простой. Картинка, как произнести слово и диалог. Никакой грамматики, исключительно разговорная практика. И бабушки заговорили спустя пару месяцев. Да, зачастую с ошибками, но вполне уверенно.
Это работает для маленькой группы, как только вам нужно быстро проверить знания миллиона-другого человек, на сцену выходят стандартизированные тесты. Это же были вчерашние дети после школьного курса английского.
К тому же есть такая штука как языковой барьер, у них отдельная паника случалась, оттого, что они увидели настоящего живого иностранца. Это как раз с каждым человеком может случиться при самой лучшей методике, если, конечно, не выписывать настоящих иностранцев в качестве учителей (но это не всем по карману, вот в нашем универе как раз нас и выписали за кормёжку и обучение)
Суть всего спора в том, что существуют полностью осознанные знания, которые вытекают из понимания базы, то есть фундамента на чём всё строится и тупо функциональных зазубренных знаниях без самого понимания основ.
Вот взять кубик Рубика, можно пойти в утуб и быстренько посмотреть самый быстрый алгоритм сборки, а потом на глазах у знакомых его быстренько собирать, можно ещё всяким трюкам научится спидкуберским, тогда вообще огонь будет смотреться.
Только вот бездумно зазубрить рабочий алгоритм, это вообще не тоже самое, что самостоятельно крутя вертя кубик, найти те закономерности и те особенности которые помогут тебе добиваться какого-то результата где сам алгоритм уже вывели математики.
Мы все точно так же в школе зазубривали метод деления в столбик, не задаваясь вопросом, а почему этот метод возможен и на каких закономерностях он основан и как кто-то пришёл к этому методу, мы просто зазубрили функциональную часть, где этот метод даёт нам нужный ответ, попробовали его пару раз, проверили что он рабочий и всё, наша цель же была в том, чтобы верно решать примеры, чтобы нас похвалили и поставили 5.
С рубиком и столбиком оно работает одинаково, зазубренный рабочий метод это способности обезьянки, которая научилась повторять что-то, что вывел более осознанный субъект, который задавался куда более фундаментальными вопросами, как чёрт возьми оно устроено по своей сути, а не то, как получить нужный мне результат, чтобы козырять этим перед остальными.
Для каких-то прорывных вещей требуется знание базы, а просто ехать можно и на функциональных знаниях не понимая что лежит в их основе и как оно было выведено.
В идеале конечно лучше чтобы все в команде понимали всё с фундамента, но это вовсе не обязательно, нужно какое-то лишь достаточное количество ключевых людей, которые будут видеть архитектуру с нуля и проверять её, направляя людей.
Например автомобиль, как концепция состоит из разных функциональных элементов, где база, колёса, двигатель, объединяются в единое целое и только в таком виде, оно выполняет свой функционал, невозможно убрать что-то, оно сразу перестанет выполнять свои функции.
Так вот, чел который тут всех отбраковывает, требует полной универсальности, где каждый член был бы полностью автономен и в одно жало мог бы написать всю задачу с нуля. Но это не обязательно, нужно чтобы костяк спецов, понимал и следил за развитием инфраструктуры, а спецы без понимания базы не увели бы проект куда-то не туда, не понимая основных принципов.
Где в компании есть нехватка рабочих мощностей, что сказывается на конечном продукте, так как появляется перегрузка команды, недовольство командой, недовольство руководством и кадровой политикой.
Где требуется урезать требования к базе, но выставить жесткое разграничение для людей которые эту базу не знают, где они будут лишь как подмога, но не будут участвовать в проектировании фундаментальных структур, а будут лишь выполнять задания сверху.
что можно писать ПО и без этого
Это вообще как? Что это за ПО такое, что можно все массивы на связные списки поменять и всем плевать?! Я бы к вам не пошёл. Пишите такое ПО сами. И пользуйтесь тоже им сами.
24 плюса. Хабр, что с тобой? Я понимаю, если бы человек написал что ему человек со знанием эхо-корасиков не нужен. Но блин не отличать связный список от массива… Причём в Java… Что дальше? Кандидат путается в 3-х IF-ах? Ок, берём. Будем давать задачи с 2 IF-ами.
Во-первых, вы еще пойдите найдите кейс, где в современном джава-приложении ArrayList и LinkedList ведут себя драматически по-разному. Типовая обработка коллекций вся давно на функторах - а они разницу не видят. Сценарий, где мы зачем-то берем энный элемент списка и получаем ту самую разницу O(1) vs O(n) - это экзотика, которая встречается скорее на литкоде, а не на практике.
Во-вторых, если человек путается в этих нюансах, то это решается ровно 1 замечанием на код ревью.
В-третьих, LinkedList в джаве - предмет шуток даже для его автора. Why so serious?
Что-то не выходит драмы.
то это решается ровно 1 замечанием на код ревью.
Не решается. Если человек не знает этого, то он не знает почти ничего. Его придётся учить почти с нуля.
где мы зачем-то берем энный элемент списка
Т.е. вы используете массивы, но адрессная арифтметика вас не интересует. Какие-нибудь матрицы смежности это видимо high end технологии. Понял. А ну да. Графы это наверное уже литкод. К реальному коду отношения не имеет. В реальном коде мы ведь за пределы итераторов никогда не вылезаем. Понял, понял.
Что-то не выходит драмы
И правда. В вашей вселенной не выходит. Главное от неё держаться подальше.
Графы это наверное уже литкод. К реальному коду отношения не имеет. В реальном коде мы ведь за пределы итераторов никогда не вылезаем. Понял, понял.
Реальный код у каждого свой. Если вам какой-то аспект важнее других - я не против, если вы вокруг этого свое интервью будете строить. Просто смиритесь, что у каждого своя ситуация и далеко не каждому нужен выдроченный курс CS.
Главное от неё держаться подальше
Я рад, что искусство диагноза по аватарке все еще живо.
выдроченный курс CS… связный список
Ох. И это Java, которую всегда ставили в пример. А я думал у нас всё плохо.
В джаве в 99.(9)% случаев используют ArrayList. И вообще есть бест практис работать с листами как с интерфейсом List. А обрабатываются они через стримы (т.е. функторами). Обращаться к элементу по индексу - это реально редкость в энетрпрайзе. LinkedList лично я за 8 лет практики использовал только на литкоде, т.к. этот класс также реализует интерфейсы Queue и Stack.
Реальной проблемы в выборе реализации просто не стоИт. Поэтому вообще ноль проблем, если человек не знает разницу или подзабыл. На самом деле джуны+ и далее знают все прекрасно.
В чем именно ваша проблема? Почему вы продолжаете хамить даже не разобравшись в ситуации?
Да разобрался я вашей ситуации. Знаю я и про итераторы, и про кровавый ынтерпрайз. Грустно мне. За державу нашу отрасль обидно. Докатились, так сказать, до ручки.
Queue и Stack
Не-не. Никаких очередей и стеков. Долой литкодщину. Слишком сложно. Спринт горит!
P.S. я там выше скриншот добавил. У нас вроде тоже ынтерпрайз. И тоже итераторы.
В джаве в 99.(9)% случаев используют ArrayList.
Не сказал бы. У нас около 20% LinkedList, и есть даже над ним обвертки, для большей эффективности. Все зависит от задач.
Обращаться к элементу по индексу - это реально редкость в энетрпрайзе.
Скорее говнокод, даже не знаю где может понадобится. Или же в моей практике просто не встречалось.. Как у вас с LinkedList.
вообще ноль проблем, если человек не знает разницу
Если он работает у нас, то проблема. Если у Вас, то проблем нет, так как вы не используете.. В целом, если вернуться по стеку к статье, то скорее когда на собеседовании задают вопрос по LinkedList, то наверное используют и наверное им важно..
не придраться, но спросить:
20% случаев использования LinkedList(-) вместо Arr на Java(-). Мне хм... не то, чтобы сложно поверить - но кажется ваш случай действительно довольно специфичен.
Из всех вариантов когда List лучше Arr - у вас остался только случай специфической нагрузки (много удалений \ вставок) на достаточно длинные коллекции.
(real-time мимо из-за Java, lock-free мимо из-за List).
Судя по вашему скрину, у вас а) фронтенд б) что-то связанное с графикой
тут, пожалуй, индексы могут пригодится. но область уж очень узкая.
Открыл наш backend:
- 955 results in 293 files
- 3916 results in 654
Полистал. Часть, конечно, что-то левое. Но более чем достаточно кода где прямое обращение к элементу массива по индексу. Как и вызовов всяких splice, findIndex, slice.
Backend самый обыкновенный (ну кроме того что это high-load). Посмотрел по смыслу — всякие сопоставления коллекций, их merge-инг, валидация, группировка и т.д… Ну т.е. довольно рутиные операции. Не какие-нибудь графические вектора.
Покажите пожалуйста пару мест - очень интересно где вы обращаетесь по индексу.
Простите, но влезу в разговор ссылкой на код хромиума. Куча обращений по индексам. Где-то 80% найденного там — это действительно тупо итерация по контейнеру, объявления массивов и прочие комментарии: не считается, да. В оставшихся там есть обращения к подряд идущим элементам. Еще где-то индекс является ключем в колекции — это именно обращение по индексу, которое нетривиально заменить на что-то еще.
Выше кратко привёл вид задач. Включил поиск по проекту:
- Самый частый кейс это какая-нибудь реализация навигации стрелками с клавиатуры по списку.
- Какой-то кейс где у нас есть несколько уровней тарифных планов, которые поддерживают разный набор фич. И у них есть иерархия. Задача — выбрать ближайший в пределах иерархии план, содержащий нужную фичу, чтобы попросить юзера купить этот план.
- Какой-то мудрёный код в иерархическом контроле где всякие каталоги, подкаталоги. Я вижу там вообще полно индексов. Но это надо вникать в каждый конкретный метод.
- Merge-инг разнородных коллекций во что-то новое.
- Много кода со всяким парсингом строк. Тоже индекс на индексе.
- Ооочень много кода, где массивы используются в роли хеш-мап, но с числовыми ключами (которые и есть индексы в коллекции). Формально можно заменить на хешмапы с сохранением порядка и со случайной генерацией ID, но на кой чёрт? :)
- Куча какого-то кода с поиском. В том числе иерархическим.
Ну и прочие примеры. Там 513 кейсов даже по такой регулярке: \[(idx|index).
ArrayList это ресайзабл массив, а LinkedList связный список? К примеру в плюсах будет чаще перформанс хит не из-за алгоритмической сложности, а из-за того, что связные списки раскиданы по памяти и очень плохо ложатся на процессорный кэш и просадка из-за того, что "ой, а след элемент у нас не в кэше, пойдем за ним долго и упорно в след левелы, а если не повезет в оперативу". В жаве не так (мммм всё на хипе и в массиве все равно будут указатели на куда попало? но с примитивными типами должно работать все равно)?
мммм всё на хипе и в массиве все равно будут указатели на куда попало
Не, ну там же не полный хаос царит. Всё равно будут большие цельные блоки памяти в пределах которых всё работает быстро.
Ну утрированно. Понятно про система скорее всего вам пытаться будет целыми блоками давать и поближе, плюс процессор скорее всего умеет, скажем так, держать у себя в кэше данные с разных мест в памяти и может этого хватит (может в эмедед мире не так) и так далее, то есть на практике ну не так все плохо будет скорее всего, но в перформанс критичных приложениях лучше так не рисковать. Ну либо разворачивать свой лист на своей преаллоцированной арене, которая будет гарантированно одним большим постоянным блоком.
Ну в целом я согласен с коллегой что огромный пласт ПО можно писать без этого) Печалит в этой истории то что людям не только совершенно не любопытна теория по своей профессии, но они ещё и кичатся этим, поднимают на флаг. "Нам он и на* не нужон, хашмап ваш"(с)
Вот тут чуть мимо. Человек сложно устроен. Я однажды мучился с почками, ходил по врачам, пока однажды уролог не сказал: "Да у вас просто мышцы спины в гипертонусе" и отправил к совершенно другому специалисту
Смею заметить, что пример с врачом по моему мнению в корне некорректен: люди намного хуже стандартизованы в деталях функционирования конкретного организма нежели 90 процентов программных продуктов. А еще код можно читать, совсем как текст, а вот состояние человеческого организма прочитать, увы, не выйдет, его можно только оценить по огромному комплексу сложных, непостоянных и индивидуальных метрик. Если выкинуть совсем энциклопедические случаи - даже терапевту, чтобы лечить хорошо, действительно нужен кругозор и база. Чтобы написать рабочий, просто рабочий код требуется, ИМХО, на порядок меньший кругозор и пресловутая «база».
Возможно я Вас удивлю, но врачи тоже гуглят. А мировая практика показала, что даже очень опытные врачи сталкиваясь с редкими заболеваниями не могут их распознать.
Во первых гуглить тоже надо уметь, человек без нормальной базы на гугление потратит в 5 раз больше времени и не факт что вообще поймет что он там нагуглил.
И потом может тогда врачам тоже не стоит 5 лет учиться, пусть идут на трёхмесячные курсы от гикбрейнс и вперёд, все равно 90% больных у ЛОРа болеют вирусными заболеваниями которые сами пройдут за неделю, а остальные можно и нагуглить
может тогда врачам тоже не стоит 5 лет учиться, пусть идут на трёхмесячные курсы от гикбрейнс и вперёд, все равно 90% больных у ЛОРа болеют вирусными заболеваниями которые сами пройдут за неделю, а остальные можно и нагуглить
Тссс, не подсказывайте министру здравоохранения идеи оптимизации расходов на медицину для быдл электоральных масс
Недавно был эксперимент кто лучше и точнее диагностирует заболевания. Взяли врачей с минимальным опытом после обучения и опытных врачей с огромным стажем и узкой специализацией. Опытные врачи великолепно ставили диагнозы по своей специализации и проигрывали выпусникам в диагностике болезней не своей специализации. Выпускники неплохо диагностировали болезни по большинству специализаций и лучше по своей но гораздо хуже опытных врачей по их специализациям. То есть нужно брать только выпусников или людей с широкой специализацией.
А еще лучше опытных но не растерявших полученные в учебе знания.
FAANG в общем то так и делает, вот тебе секция алгоритмов и секция дизайна распределенных систем, пройдешь значит будут с тобой говорить, нет так нет. Но на хабре от этого у многих хорошенько так пригорает, как же так, мы же в вузе не учились зато прекрасно json'ы перекладываем, значит это не мы плохие, а интервью неправильные.
литкод-макака
Ироничненько (с)
Но, в общем и целом, согласен. Про другие фаанги ничего не скажу, но в Гугле народ слишком дофига занимается перформанс ревью друг друга и прочей хернёй. Алгоритмы, про которые они спрашивают на входе, 95% там в работе никакие не юзают.
видишь выходца из FAANG — считай абсолютно бесполезная в реальной разработке литкод-макака.
Опишите, пожалуйста (или ссылку на ваш старый коммент дайте, если уже писали), в чем конкретно они бесполезные в разработке?
Как говорится критикуя предлагай. Пока что никто толком не описал как правильно проводить интервью, однако жалоб вагон, обижают бедных сеньоров вопросами про хеш таблицы, ужас ужас.
видишь выходца из FAANG
Работаю с выходцами из FAANG. Отличные спецы знающие своё дело. Имеющие превосходное представление о реальной разработке, причём часто с позиции business-а. Прекрасно понимают где и когда можно скосить углы, где будут perf-bottleneck-и, где можно писать код ногами, и куда подстелить соломку. Хорошо понимают роль логирования, умеют в продвинутый troubleshoot-инг и debug-инг. И обладают высокой инициативой. Хорошо доносят своё мнение. Умеют идти на компромисы. Обладают глубокими познаниями в используемых инструментах. Без проблем пишут свои решения, библиотеки. Прекрасно разбираются в чужом коде.
Вообще грех жаловаться. Что это вам за выходцы из FAANG-а попадались, что в разработку не умеют?
ИЧСХ далеко не все из них умеют в "литкод-макакинг".
видишь выходца из FAANG - считай абсолютно бесполезная в реальной разработке литкод-макака.
А вы много таких выходцев реально встречали/работали? Литкод в ФААНГЕ это может 10%-15% от всей серии интервью на позиции выше джунов, остальное как у всех - тех, опыт работы и всё вот это вот. Или у вас все операционные системы, иде и т.д. пишут исключительно литкод макаки и просто рэндомно выходят продукты которыми буквально пользуются миллионы/миллиарды?
Я думаю что нет, почему тогда в мире ИТ это норма?
Потому что мир ИТ совсем не похож на мир физиологии человека.
"База" анатомии довольно статична и не расширяется так, как "база" ИТ. Анатомию без специализаций выучить можно, а объять также сферу ИТ невозможно. Во фронте каждые 10 лет прикладные фреймворки меняются — вы представляете себе врача, у которого инструментарий каждые 10 лет абсолютно не похож на предыдущий?
Проблема то эта лежит вобщем-то в финансовой плоскости. Поддерживать эту разрастающуюся "базу", большая часть которой малоиспользуема, требует много затрат времени => такой специалист очень дорогой в обучении => очень дорогой в дальнейшей работе (ведь стоимость обучения перекладывается на работу). А бизнес почему-то не хочет платить за эти затраты. Бизнесу идеально как раз нанимать ровно "умеет лечить только то что лечил на прошлом месте" если области совпадают.
База ИТ ровно так же статична как и база анатомии, просто многие в этом посте не понимают что такое база в принципе и думают что это названия классов и методов в фреймворках которые они использует. Так вот нет, фреймворки это не база и никогда ею не были. Продублирую свой ответ из соседнего треда:
https://habr.com/en/articles/758838/comments/#comment_25932550
Вы пойдёте к такому врачу, так же как и я, и уже много-много раз ходили. Вы же каждого врача не интервьюируете?
Когда вы последний раз использовали связный список?
По крайней мере в гугле их используют постоянно. Писать их, конечно, с нуля почти не пишут, за очень редкими исключением, но на интервью иногда спрашивают, чтобы убедится, что кандидат таки поймет, когда использовать std::vector, когда std::list. Можно было бы просто спрашивать о свойствах списков, но все равно же надо выдавить из кандидата 5-10 строк осмысленного кода, почему бы не спросить что-то со списком написать?
Блин, разница между хорошим специалистом и плохим в том, что и тот и тот могут забыть\не знать каких то вещей, но первый может довольно быстро разобраться в вопросе. Я вот за годы своей карьеры позабывал кучу хитрых алгоритмов, которые хорошо знал лет 10 назад, сейчас спросите - не отвечу. Но со шпаргалкой разберусь и вспомню. Однако такой кейс на собеседовании красный флаг для большинства интервьюверов.
Какие такие хитрые алгоритмы спрашивают на интервью? Ни разу такого не видел. Обычно спрашивают про отличия в стандартных структурах данных по асимптоматике да и все, или вас по красно-черным деревьям гоняют?
Даже задачки с литкода обычно везде дают уровня easy, максимум medium, что бы их решить обычно ничего сложнее хеш таблицы и слияния двух массивов знать не требуется.
Всякое бывает. Коллегу одна немецкая контора попросила задачку на поиск оптимального пути в графе решить. Я хоть и решил таких штук 50 наверное сейчас вот так вот сходу и не решу. Всё выветрилось. Но там, справедливости ради, в самой вакансии было указано, что алгоритмы играют ключевую роль в позиции.
Я специально хожу по собесам как кандидат с целью найти интересные вопросы и темы для моих собственных собесов.
Т.е. лень самому придумать вопосы и темы, но не лень время тратить на пустые собеседования? Может это и есть ответ про других: им тоже лень думать и подстраиваться под каждого кандидата.
Т.е. лень самому придумать вопосы и темы
С потолка взяли? Невозможно придумать из головы все возможные интересные вопросы. В другой конторе могли иметь уникальный кейс, который потом превратился в вопрос для собеса. На это и расчет.
Цель: адекватно оценить и нанять кандидата на соответствующую роль, а не поупражняться в изяществе вопросов. Достаточно, "просто", подходить к каждому кандидату индивидуально. Перефразируйте вопросы, вплетите вопрос к другой контекст, чтоб он вытекал из задачи и не был академическим, чтоб выбить кандидата из привычной среды экзамена и не дать соотнести вопрос с ранее услышаной формулировкой и т.д. Да, проводить собеседование тоже искусство. Нужно тренироваться, учиться, овладевать психологическими практиками и иметь широкий кругозор.
Тут все зависит от того, как эти вопросы задавать и оценивать. Если все это в стиле квиза с попыткой подловить на незнании деталей - то это ад, конечно, с другой же стороны можно эти вопросы задавать просто с целью посмотреть на то, как человек будет отвечать. Если человек может четко и грамотно сформулировать, что он знает, и очертить круг того, что "вот это уже забыл", то и понятно сразу будет, что по факту он в вопросе разбирается.
По сути, это все просто такие универсальные темы для разговора.
Ну вот, например, после вопроса про устройство hashmap можно спросить - а можно ли в качестве ключа исользовать null? А что будет при постоянных коллизиях?
Проблема что это не всегда что-то из разряда фундаментального. Для той же системы .Net вы влет может огрести от разной реализации в mono и clr.
Для c++ реализация хэша в контейнерах может меняться от версии компилятора.
И т.д.
Для c++ реализация хэша в контейнерах может меняться от версии компилятора.
И в команде никто этого не знает и не знает где бывают эти проблемы в их проекте?
Ну имхо что такое хэшэйблы (всякие unordered_) и по какому принципу оно работает это как раз фундаментальное и это по хорошему надо знать, а как оно уже конкретно реализованно это детали. Хотя С++ страдает от того что все знают 5% языка и у всех эти 5% свои с небольшими пересечениями, а спрашивать "а зачем нужен виртуальный деструктор, а можно ли выбрасывать исключения в деструкторе" и так далее как-то не серьезно (да и отвечать на это тоже задалбливает)
Проблема вопросов по базе в том, что они могут не иметь отношения к реальным юз кейсам.
Не так давно собеседовался в компанию как Unreal Engine плюсовик. Обсуждали ромбовидное наследование что это, как правильно наследоваться и что будет в разных вариантах наследования. Всё что я мог сказать: "Да, я конечно читал про проблемы ромбовидного наследования. Лет 10 назад. Потому что на практике мы его нигде и никогда не используем из-за того что это проблемная штука, которой нужно избегать."
И вот получается - это база. И это база, которую я не знаю(вернее не помню, но это одно и тоже). Давайте меня браковать за это?
проблемы ромбовидного наследования
И это база, которую я не знаю(вернее не помню, но это одно и тоже).
Да, бросьте, в чём состоит проблема ромбовидного наследования нет проблем вывести через пол-минуты размышлений.
Вот вспомнить наизусть что означают какие буквы в SOLID и иногда даже CAP - это без освежения данных сложнее. Впрочем, на собеседованиях одно и то же спрашивают, после первого собеса в серии, это будет отлетать от зубов.
Для энтерпрайзных разрабов обычно нет проблем рассказать про солид во всех его проявлениях, связать di c юнит тестами, и c них перескочить на bdd с примерами из реальной жизни, рассказать про легаси, в котором пришлось это все править и проч. Рассказать про проблемы, которые приходилось решать, поиски боттлнеков и гейзенбагов. А вот вопросы по "БАЗЕ" - ну блин... Бывают такие дебильные. Но правда бывают и хорошие и можно глубоко по ним докопаться. Как повезет с интервьюером. Судя по статье везет не всем.
Да я не про рассказать. Я про буквы. Из этих букв я, обычно, только первую помню потому что она первая и L потому что она Бабра Лискофф :).
Рассказать потом не проблема, проблема вспомнить что какая буква означает.
И это база, которую я не знаю(вернее не помню, но это одно и тоже)
"Не дожидаясь отказа, свою кандидатуру я снимаю сам." (c) некто по фамилии Эйнштейн
если человек способен зазубрить то и в работе у него все будет хорошо
Как раз практика показывает, что если человек способен зазубрить, то он способен зазубрить и больше ничего. Обычно тупой зубрежкой как раз компенсируют неспособность самостоятельно решать задачи.
Не везде и не всегда. Есть правила наработанные практикой которая отличается от теории. Потому что последняя не учитывает пограничные случаи. Та же сортировка. Один алгоритм работает быстрее в случае почти отсортированных данных, другой незаменим если мало памяти и тд и тп. Новичок может не знать какие именно данные поступают из очереди и тогда ему проще заучить то что говорят более опытные коллеги.
Опять таки вопрос времени. Книжка Кнута размером в три тома замечательная и после неё ты точно будешь разбираться в теории и сможешь ответить на любой вопрос. Но есть ли у тебя время на Кнута? И сотни других книжек.
Я думаю что в чём-то конкретном программист должен разбираться досконально. В остальном можно зазубрить. Например, если он фронтендщик, ему не надо разбираться в node.js, достаточно запомнить пару команд как быстро поднять сервер локально, дальше пусть devops парится.
Не путайте "уметь пользоваться на уровне пользователя" и зубрежку. По факту, как в школе, выучить, значит и понять, нужно только "таблицу умножения". Остальное нужно уметь выводить путем логических размышлерий. А зубрежка, даже, так и называется, что отскакиевает от зубов минуя мозг и этап размышления.
Проблема базы в том, что база - это бесконечные знания. Базой можно назвать все, от простых функций до того, как работает компилятор и как работает GC под капотом. В общих чертах понимать, конечно, надо, но точно знать последовательности и точные названия каждого уровня языка и каждого этапа выполнения - просто нереально. Плюс к этому, знания чисто энциклопедические, в реальной жизни почти не используются. Поэтому забываются, а вспомнить все перед собеседованием - просто невозможно.
Я знаю базу языка Delphi, ты знаешь базу языка java, а собеседование на разработчика python. Если я буду тебя спрашивать свою базу ты на нее сможешь ответить?
Для начала стоит определиться что такое "база". В моем понимании это те вещи которые проходят на курсе CS в вузах. Туда входят структуры данных, алгоритмы, реляционные базы, распределенные системы. Что касается языков то некоторые компании вообще не проверяют знание конкретных языков и платформ, ну например тот же яндекс. Во вторых каждый язык использует какую то парадигму программирования(процедурная/функциональная/ооп и т д), возможно есть какие то нюансы в реализации но суть обычно одна и та же везде, вот эту базу и можно спрашивать.
А в чем собственно проблема вопросов по базе?
Как минимум проблема в том, что если я начну спрашивать свою "базу" у человека, который меня интевьюирует, он посыпется на первых же вопросах, потому что в отличии от него, я к собесу готовился) В итоге мы друг другу докажем, что оба идиоты. Ну и смысл?
вкатыши в айти которые знают только то с чем работали и нафиг не нужны
Я в айти уже считай 10 лет. И, удивительным образом, я знаю только то, с чем работал :) А то, с чем не работал - не знаю. Да и не стремлюсь особо. Знать всё невозможно и не нужно.
IMHO, основная проблема вопросов по базе, что многие путают низкоуровневые нюансы и базу.
Вместо того, чтобы задать общий вопрос по архитектуре на понимание принципов, задают по деталям реализации конкретной фичи в конкретном фреймворке/библиотеке.
Мало кто пытается на интервью выяснить что человек знает, чаще стараются что не знает.
Я провел сотни интервью, у меня треть интервью идет по разным вопросам касательно технологий указанных в резюме. Даже если я не знаком с какими-то технологиями, я могу позадавать общие вопросы, выяснить насколько глубоко человек их копал. Да и для себя полезное узнать.
а что за пренебрежение к тем кто хочет "вкатиться в IT" ? может если бы в нашей стране норм ЗП получали не только нефтяники и ITшники то может быть и вкатышей не было бы ?
А то странно ругать людей в стране скатывающейся в "темные века технологий" что кто то хочет вкаиться в IT
Или вы предлагает людям работать за 15 000 в пятерочке или медсестрой которая вам же будет вводить лекарства и желательно чтобы она была не уставшая чтобы не перепутать лекарство и раствор хлорида натрия
А как же тогда повыделываться знанием алгоритмов?
Мне кажется пара реальных сценариев из жизни может быть гораздо интереснее литкодинга. Начать например так - ты знаешь что такое рекурсия. Окей, а вот допустим у тебя есть рекурсивный алгоритм, но внезапно вылетает stackoverflow - а что это? А почему это - и как ты решишь эту проблему.? Оо, развернешь в стек или очередь, здорово. А слышал про хвостовую рекурсию? А в C# она есть? А где есть? Ооо, а ты использовал F# для реальных задач в проектах? Расскажи. А что ты еще знаешь про приемы функционального программирования, если мы пишем на C#? А что такое Result<T> и где он используется?
Вот я считаю что такая беседа была бы очень крута и сразу бы выявила сильного разработчика. В принципе клубок в любую сторону можно разматывать, и по многопоточности, и по вебу итд. По беседе вообще обычно сразу становится понятно.
Не могу не поддержать такой подход. Самый лучшие мои собесы были именно такого рода. Они же оставляли после себя самые приятные впечатления, независимо от успешности самого собеседования.
Это и собеседованием сложно назвать. Скорее обмен мнениями, диалог специалистов или что-то похожее.
Вооот. Вы рассказываете про индивидуальный грамотный подход человека, которому нужно найти кандидата в свой проект. Но, к сожалению, довольно часто применяется подход, когда собеседуют на абстрактную должность в абстрактный проект. И тут уже остается на совести интервьювера как относиться к собеседнику.
но внезапно вылетает stackoverflow - а что это?
Это сайт, с ответами на все вопросы)
Знание стандартного алгоритма освобождает от необходимости его применения в коде. Ну потому что потому что уже написано написано до нас, библиотека, модуль, пакет.
Нестандартный, специфический алгоритм придумать самому - это не нужно. Тимлиду не нужны какие-то изобретатели. Ему нужны 1) рабы. Разрабы. 2) Зерги, что тоже самое. Чтоб работали, делали, что скажут, а не изобретали. Тимлид (отечественный, с другими дела не имел) должен быть посредственностью, работающей на результат, на синицу здесь и сейчас, чтоб успеть к сроку. Для зерграша ему нужно много еще более дешевых юнитов, посредственных посредственностей, но, однако по-своему мотивированных.
Суперюнита или нескольких можно прикупить одного на полставки или там сдельно - под конкретную задачу. Это хорошо и правильно. Так можно закончить проект успешно и получить денег на новый. И остаться тимлидом.
Общался в среде литераторов - они конкурсы проводили, на которые писатели подавали свои рассказы. Повыделывался знанием сортировок.
Причем все по классике. Обсуждение пришло к тому, что не понятно как бить участников на группы в случае, если работ будет много (вернее можно бить так - но такая проблема, сяк - другая проблема). Было предложено решение бить на группы в зависимости от размера текста (критерий: дать членам жюри читать одинаковый размер чистого текста при разном количестве рассказов). Идея была одобрена. А потом все вспомнили, что тут в среде людей искусства есть еще и скромно молчащие айтишники...
Мораль - повыделываться алгоритмами можно вообще в отдельной от айти среде. И даже нужно. Но спрашивать алгоритмы, чтобы узнать про алгоритмы такое себе конечно.
В резюме надо вчитываться и корректировать свой пул вопросов под конкретного человека, продумывать тактику разговора.
Чаще всего в резюме написано что "работал работу", ещё может быть стек указан, но сразу на весь срок в компании на протяжении 5+ лет.
Во что тут вчитываться и что корректировать?
Резюме со ссылкой на Github я ещё не встречал.
Правда встречал со ссылкой на Stackoverflow, только там реальная активность была 5+ лет назад, а потом всё - ни вопросов ни ответов - что мне дал это профиль? В чём смысл оставления этой ссылки в резюме?
Чаще всего в резюме написано что "работал работу"
Ну если кандидат про все Х лет своего опыта поднатужился и выдавил только "работал работу", то не зовите такого кандидата, не вчитывайтесь и не корректируйте. И в целом я не согласен с "чаще всего". У нас сейчас на HR доске где-то 15 кандидатов висит. Почти в каждом резюме глаз за что-то цепляется.
И в целом я не согласен с "чаще всего".
У нас сейчас на HR доске где-то 15 кандидатов висит.
Почти в каждом резюме глаз за что-то цепляется.
Более 20-ти собесов с июня - подробности по проектам были хорошо если у 4-5 человек
Ссылок на GitHub ноль и, как я уже говорил, одна на заброшенный Stackoverflow.
Да, у некоторых есть за что зацепиться, но это именно исключение из правил.
У меня вот такая статистика.
Как-то странно. Если человек 15 лет отработал в ИТ, но давно забил на личные проекты, а в свободное время выращивает помидорки - он уже не кандидат?
ага. А если он работает по 8 часов в день с двумя выходными в неделю - видимо с ним уже вообще не о чем разговаривать :-)
Вы же даже не поняли о чем речь. Какие личные проекты вообще? Речь про людей, которые пишут что-то типа "работал в ООО Рога и Копыта с 2012 по 2019, правил баги, делал фичи" - и все, другой информации нет. На чем писал, чего достиг, какие проблемы порешал?
То есть кандидату лень нормально составить резюме, но я почему-то все равно должен его пригласить и потратить время на лишние распросы?
ну, иногда может быть такое, что кроме "правил баги, делал фичи" и написать то нечего. ну вот какая нибудь большая контора, огромный проект, всякая мелочь идёт непрерывным потоком, человек пашет не поднимая головы, задачи выполняет. А вспомнить и описать толком нечего
Да можно, стоит тлько поднапрячься. Наверняка среди багов были и супер важные, про которые и стоит расписать их важность и столько денег терялось пока я героически не починил. И не супер важные но интересные и редкие, про которые тоже есть что сказать.
Ну а про фичи и тем более - всегда можно найти и важную и уникальную.
p.s. попросите ЧатГПТ помочь, ставлю десятку он придумает что написать
можно. Если поднапрячься и выдать красивую картинку для удовлетворения чувства прекрасного интервьютера. Но реальная картина зачастую именно - быстро и качественно делал непрерывный поток разной мелочёвки. ну вот было у человека за несколько лет в этом потоке что то интересное. и потратил он на это неделю-две-три-месяц. Или даже не месяц - или даже потратил он час и выдал гениальное решение, от которого у всей конторы наступило щастье. А потом ещё несколько лет сидел в потоке разного. Что его больше характеризует - единичное озарение или способность устойчиво выдавать приемлемый результат?
Если поднапрячься и выдать красивую картинку для удовлетворения чувства прекрасного интервьютера
В общем лайфхак от капитана Очевидность: резюме как раз для того и пишут, чтобы сообщить о себе нанимающей стороне, показать себя в лучшем свете и пробить приглашение на собес. Это буквально единственное назначение данного документа. Если резюме такую функцию не выполняет, то зачем оно вообще?
Ого, я думала, что ссылка на GitHub должна быть в каждом резюме, если конечно у человека есть там что-нибудь за относительно недавнее время...
Моя личная статистика бытия собеседующим тимлидом говорит, что у человека 25+, имеющего несколько лет опыта работы и метящего в мидла или выше, вероятность встретить пет-проекты стремится к нулю.
Люди проводят время с семьей или с самим собой, крутят гайки в машине, путешествуют, катаются на лыжах, ходят в походы, танцуют, и свободное время используют для социализации. А если что и будет - в 99% это что-то, решившее проблему конкретного человека, и который сделал это для себя, возможно совершенно неоптимально, не покрыв тестами и т.д. Так сказать, as is.
К тому же, за крайне редким исключением, у всех компаний код под NDA, и как следствие - 8+ лет опыта у меня есть, гитхаб тоже, а показать есть говнокод 10-летней давности)
Ну зачем в каждом - у людей есть жизнь вне работы, а нормальный отдых залог хорошей работы. Кому-то стыдно выкладывать свой код в паблик и люди пишут пет проекты в приватных репах. У кого-то корпоративные политики запрещают выкладывать любой код в опенсорс так как считается что конфликт интересов (можно согласовать свой личный проект у юристов фирмы, пройти еще этапы согласований и вообще заморочится, проще уж ну его) и т.д. и т.п.
Подскажите мне, я вот почти 10 лет уже являюсь ETL-разработчиком (Oracle BI + Oracle Data Integrator). Я вот смотрю на свои огромные схемы ETL-процессов и не понимаю каким образом я это должен выложить на github? А еще у меня куча разработанных дашбордов в BI, скриншоты может мне выложить на github? или я просто не разработчик? Так пишите как будто сами вот только-только вкатились в айти
Я стараюсь везде давать ссылки на GitHub, StackOverflow, не только в резюме. Смысл этого в том, что я того же жду и от других. Категорически императив что ли.
Если готовиться нужно с обеих сторон то выходит такая ситуация что на собес приходят люди играть роли, роли тех кем на самом деле в "миру" не являются. Корчим из себя не пойми что в итоги и нанимаем не пойми что.
И теперь, 25 лет спустя, я узнаю что это оказывается была "база" и без неё ты никто и звать тебя никак...
Представляете какого людям, вроде меня, у которых вообще формального образования в CS нет. Все мои познания в "базе" - это обрывочная информация, которая поступала в мозг путём чтения случайных и не очень книг.
При этом это совершенно не мешает мне работать) Просто когда что-то нужно, я трачу день на то, чтобы разобраться) Понимаю, что в мире стартапов и вообще везде, где баги нужно фиксить мгновенно, мне делать нечего, но не одними стартапами едины. Есть и болотца попроще.
Сейчас вообще есть ChatGPT, который мне и подводные камни подскажет в случае чего, и примеры напишет и вообще распрашивай не хочу) Я согласен с тем, что в целом понимать архитектуру ЭВМ и "архитектуру" алгоритмов и структур данных бывает полезно, но только на уровне "могу порассуждать". Знания уровня даже Leet Code medium обычно не нужны никому.
как часто в работе над реальным проектом вам нужны знания тонкостей реализации коллекций? Насколько велика вероятность, что какой нибудь супер пупер сеньёр не менявший работу последние N лет и за это время поднявший какую нибудь большую систему сходу вспомнит эти тонкости?
Из десятков собеседований у меня было только одно, где проверяли не мою память, а мой навык рассуждать и уметь находить решения. Хотя, перед этим ознакомились с пет-проектами.
Интервьюер не заваливал вопросами, не пытался давить. Он просто рассказал про команду, задачи и описал общий процесс работы. После чего мы ненавязчиво перешли к собеседованию в стиле - а давай представим, что нам с тобой нужно реализовать приложение для учета горюче-смазочнвх материалов на АЗС (далее шло условное ТЗ) и мы начали думать (вдвоем!!!). Накидали диаграмму условной бизнес-логики, потом плавно перешли к реализации некоторых задач. Это было самое длинное, но самое шикарное интервью. Интервьюеру не были интересны мои академические знания или то, как я вызубрил мифическую базу. Он не пожалел времени, чтобы выяснить мой скилл поиска решений и информации. И, кстати, было видно, что ему и самому интересен такой процесс прощупывания соискателя. В итоге, я с околонулевыми знаниями зашел в команду и проработал там пару лет. Команда тоже оказалась офигенной, продуктивной и в какой-то мере фанатичной и тоже многие вошли так же, как и я - с околонулевыми знаниями и росли как спецы уже на проекте. Побольше бы таких вникающих и проницательных специалистов на собесах и тогда жить стало бы проще. Действительно тупые соискатели отсеивались бы автоматически, а люди с перспективами в недалеком будущем, но околонулевыми знаниями сейчас - спокойно заходили бы на позиции.
Вот и получается, что собеседования в России - чистой воды рандом
Согласен полностью! Хожу по собесам и первый вопрос: 'Что у вас с английским?'. Резюме моë состоит из 10 строк, а в 3й строке написано, что преподавал английский в университете 10 лет)) Сидишь и просто не знаешь, что ответить))
Может поделитесь опытом проведения интервью. О чем стоит спрашивать кандидатов? К примеру, я обычно спрашиваю о старом опыте, проектах, как устроено и почему. Бывает даю задачку на подумать, как человек реализовал ту или иную фичу, как декомпозировал фичу, какие компоненты бы реализовал.
Про то, что проходить собеседования - это отдельный скилл, отличный от решения реальных задач на работе, и его надо "качать", написано много. Теперь, вот так сюрприз, оказывается, что проводить собеседования - это тоже отдельный скилл, и его тоже надо "качать". Только вот у проходящих собеседование есть хорошая такая мотивация (кушац-то хочется) и скилл качать, и над обратной связью порефлексировать, а у проводящих эта мотивация не очень хорошая (особенно если на собес дёрнули погрязшего в срочно-важных тасках обычного разраба) и цикл обратной связи подлиннее (1-3 мес нанять, 1-3 мес понять что "тянет"/"не тянет"). Вот и имеем что имеем. Как только тимлиду/руководителю разработки припечёт - наймут первого подходящего.
Мне видимо дико везло - я всегда попадал на такие собеседования, где у нанимателей (Сбер, Точка, Альфа-Банк) каждый раз получалось меня искренне заинтересовать работой и стеком технологий. Большую часть времени они давали мне самому рассказать о своём опыте и уточняли некоторые моменты. При этом это было сделано максимально дружелюбно и не было ощущения, что пытаются на чём-то подловить.
Потом они рассказывали о том, чем надо будет заниматься и их интересовали мои знания этих продуктов или схожих. Из того что я не знаю RabbitMQ не делалось трагедии, они просто интересовались на каком уровне я вообще знаю работу брокеров, например. Но это были в основном люди 30-35+, уверенные в себе, которым ничего не надо себе доказывать и которым был нужен специалист.
Мне кажется интервью с кандидатом должно быть основано таким образом, чтобы понять что человек ЗНАЕТ. А не то, чего он НЕ ЗНАЕТ. Понять, насколько он мотивирован что-то узнать и выучить. Мотивирует ли его работа с новым стеком, или он хотел бы заниматься точно тем же, чем занимался раньше? Горят ли у него вообще глаза? Какие у него софт-скиллы - насколько он коммуникабелен, не стесняется ли спрашивать других людей для экономии своего времени. Можно спросить про подход к обучению новому стеку (как он это делает), это тоже о многом говорит.
Вопросы, на которых кандидат посыпался или долго думает можно отложить и вернуться к ним в конце интервью, чтобы кандидат не "закрылся". Я видел, как люди сильно "подтупливают" на каких-то вопросах в начале собеседования, но при повторном вопросе в конце собеса отвечают очень точно и чётко. Хорошее собеседование это когда был интересный для обоих сторон диалог и когда ты понял свои "слабые" места, но это у тебя не вызывает фрустрации и чувства никчёмности если тебя не приняли, а вызывает желание учиться.
а у вас были кандидаты, которых ваш сеньор с ролью техлида одобрил? может сперва с ним обсудить подход к отбору?
Да, были, но их уровень знаний и опыта был выше, чем финансовая часть, которую мы могли предложить, по этой причине были отказы уже со стороны кандидатов.
А ларчик просто открывался :) То есть кадры есть, просто нет на них денег. Тогда может с техлидом обсудить, что на "сеньоров" как он их видит, нет денег, есть на мидлов? Чтоб требования тоже были пониже.
Вот и ответ на все вопросы. Бизнесу не нужна звезда. Ему нужен человек работу работать за имеющийся бюджет.
А техлид хочет работать с крутыми специалистами.
Вывод: человек просто не на своем месте, так как не понимает потребности бизнеса. Все же техлид это не только про хард скилы.
Вот до этого комментария не хотел писать, что техлид дурак, но теперь напишу )
У вас одна проблема в команде
Может просто техлида поменять и дело пойдёт быстрее?
Хотя бы просто попробовать не пускать на собесы.
Как бы раньше тимлида не поменяли за то что тот не может "организовать работу" с командой. Походу там тупо личный конфликт между тех и тмлидом
ну тут вопрос, кого поменять проще. У меня знакомая hr в одной компании как то 10 месяцев не могла закрыть позицию. то одно техлиду не нравилось, то другое.. при этом сроки горели, баги лезли косяками, техлид героически превозмогал и показывал свою незаменимость работая до 10 вечера и по выходным. А кандидаты все какие то не такие были - ну вот никак не могли ответить на простейшие вопросы и показать знания элементарных алгоритмов. А потом техлида ушли. И позицию закрыли за неделю - просто взяли одного из ранее отвергнутых кандидатов. И работать он стал более менее по 8 часов. и со сроками и качеством стало получше.. только говорят периодически матерился на код ушедшего техлида..
Я не утверждаю, что тут та же ситуация, но почему то из опыта - когда сильно докапываются по формальным параметрам - обычно на проекте творится всякое.
А бывают случаи, когда разработчики не матерятся на код своих предшественников?
Дзэн левел называется, когда понимаешь что то что ты видишь такое себе, но ты не застал всей эволюции и не понимаешь почему оно стало тем, чем стало, что ну возьмешь и перепишешь даже, то может и получишь +- то же самое когда соберешь все грабли, может получится лучше, но все равно через годы ты, и те кто пришли после, будут смотреть на твой код и материться. Так что зачем тратить время и нервы на маты, просто пожимаешь плечами и пытаешься сделать то, что сейчас в твоих силах чтоб стало хоть немного лучше
Дзен левел это когда ты постиг "работает не трожь, а если трожь, то напиши сначала юнит тесты с полным покрытием".
Так что зачем тратить время и нервы на маты, просто пожимаешь плечами и пытаешься сделать то, что сейчас в твоих силах чтоб стало хоть немного лучше
А потом такой фидбек от хрюшки на интервью " у него нет интереса к продукту, глаза не горят"...
В принципе, у меня было даже наоборот однажды. Я пришёл в проект на чистом Си и такой: "вау, как всё круто и удобно сделано, буду делать теперь также" :) Я даже немножечко разлюбил С++, настолько был код хорош, прост, понятен и расширяем. Но там и сам проект - это была относительно небольшая библиотека, которая писалась без спешки и делала хорошо поддающийся декомпозиции функционал, который был отлично документирован.
Иногда чудеса случаются)
Ну, честно говоря, техлид, который заваливает кандидатов вопросами по "Базе" и тимлид, который в кризисной ситуации вместо того, чтобы обсудить проблему с техлидом и начальством побежал по собеседованиям в другие компании и винит теперь "Потерянную культуру рекрутинга" достойны друг друга, сладкая парочка.
Увы, вот такое как в статье поведение демонстрируют многие начинающие тимлиды, вчерашние разработчики - в проблемной ситуации делать то, что умеешь лучше всего - ходить по собеседованиям.
А вам не кажется что вполне логично походить по собесам в другие компании чтобы понять как можно улучшить собственный процесс найма в компании?
А разве в статье сказано, что проблема не обсуждалась с руководством? При этом как раз сказано, что пошел по собесам из любопытства как нынче проходит отбор в других компаниях
К сожалению, подобные обсуждения на практике редко приносят пользу, даже если состоятся.
Кроме того, автор нигде не упоминает, были ли "разборы полетов" с техлидом или начальством. Так что походы на собеседования хотя бы в ознакомительных целях (посмотреть как работают в других компаниях и узнать сколько сейчас стоишь на рынке) не считаю чем-то неверным. Скорее, даже наоборот.
Эта проблема уже обсуждается и уже не в первый раз. Если бы я был плохим тимлидом, то конфликт с техлидом был бы уже в рутинных задачах. Возможно открою секрет, но одним из важных факторов утвердить должность специалиста является авторитет самого специалиста в его области работы. Так же и здесь. Техлид является авторитетом для начальства как "технический гуру", по этой причине равный мне голос при выборе кандидата.
Я не начинающий тимлид и скажу, что один из основных навыков - это умение работать с разношерстными людьми и получать явный результат. Создать конфликт и бежать к начальству со словами "Меня обидел техлид, он не хочет дружить с теми, с кем хочу я", вот это поведение начинающего тимлида.
А на счёт решения, универсального нет, как в технических, так и в управленческих задачах. Нужно всегда учитывать много факторов, которые затрудняют решение, а в каждой команде в разных компаниях они разные. Да и статья не голден хаммер по решению вопроса найма разработчиков, а по большей части описание личного опыта и приход к проблемам, которые присуще найму айтишников в целом.
А у вас техлид не устал ли случайно до той степени, что у него сил нет на принятие решений, и он "нет" говорит просто потому что так легче? Может, ему в отпуск?
Эта проблема уже обсуждается и уже не в первый раз.
Супер. Первая часть алгоритма решения проблемы выполнена - поговорили . Хотелось бы перейти ко второй части - договориться о решении . Потом, понятно, претворить это решение в жизнь, ну и про четвертую часть, уверен вы тоже знаете.
>> Создать конфликт и бежать к начальству со словами "Меня обидел техлид, он не хочет дружить с теми, с кем хочу я", вот это поведение начинающего тимлида.
Именно. Последнее, что вам нужно - это создавать конфликт и жаловаться. Не надо так делать.
Судя по тому, что формат собеседования и критерии оценки со стороны техлида для вас раз за разом оказывались сюрпризом - вы с ним по делу не говорили, а между тем, вопрос "А почему он себя так ведет" у вас сейчас один из основных.
Вы уцепились за самый простой ответ "Он упырь и упрямый долбоящер, который понятия не имеет как проводить собеседования", а между тем все может быть совсем не так.
Может быть, у него годовая премия зависит от того, насколько теоретически подкованными будут нанятые кандидаты. Может быть его к вам приставили именно потому, что у начальства есть подозрения, что без няньки вы наймете слабых людей. Может быть, в целом у начальства есть сомнения в, так сказать, engineering excellence в организации и оно решает проблему таким способом - попросив техлида "Пожощще там спрашивать на собесах". Может быть, что-то похожее думает сам техлид. Можно сколько угодно гадать, но пока вы с ним продуктивно не поговорите, можно будет долго изучать "культуру рекрутинга" в других компаниях, пока у себя найм стоит.
Здесь мы, понятно, исходим из того, что техлид и сам хочет нанять лучших из возможных кандидатов в том смысле, в котором он это понимает. Если он саботажник, то дело другое, но это, конечно, маловероятно.
По переговорам с начальством у вас в статье упоминается, что на вас давят через техлида ( WAT?! ) и что задаются вопросы о медленно достигаемых результатов. А вы-то какие запросы к ним адресуете? Чего от них хотите, что предлагаете?
P.S. Нанять человека без обсуждения с техлидом, типа протащить, когда он будет в отпуске - это бомба замедленного действия, собственноручно подложенная под проект.
Просто тимлидировать и рекрутировать это две разные компетенции, не всегда сосуществующие в одном человеке. Поэтому что для компании важнее, той компетенции она и должна (в идеале) отдавать предпочтение. И не спрашивать по другой как по само собой разумеющейся.
Нет противника страшнее, чем союзник-идиот
На самом деле и сами специалисты, в том числе, перенапрягаясь чтобы их взяли в такие компании создают эту проблему.
Понятно, что сейчас, на самом деле, реальная проблема в рухнувшем объёме рынка, но то что устроиться не реально это следствие именно "тупости" самих разработчиков. Под "тупостью" я понимаю общий интеллект, т.е. и софт-скиллы, потому что умения написать гениальный алгоритм недостаточно чтобы быть в общем адекватным человеком.
Проблема так же и в том, что собесы эти сами айтишники эти и проводят, многие из которых вообще слабо одупляют даже в собственной профессии в общем, зато наизусть заучили ту самую базу.
Интересно как собесы будут через пять лет выглядеть.
Одна контора вывешивала одну и ту же вакансию техлида трижды за год. Либо брали неподходящих на два-три месяца, либо не могут позволить себе подходящих. Но если вакансия не закрывается так долго, нужна ли она на самом деле...
Да, тут бесспорно. Хорошие места долго пустыми не будут, как и хорошие специалисты без работы. Но к сожалению, как мне кажется, не всегда хорошему специалисту такое место быстро находится, приходится перебрать и большое количество мусора, чтоб найти бриллиант.
Будут. Наблюдаю тут за одной компанией. Там сменился начальник и понеслось... Условно написано: кандидат должен знать такую-то базовую вещь и три надстройки над ней. На опыте моём я ни разу не видел человека, который знает все три. Максимум две. Штуки крайне специфичные. Вакансии год! Начальник рубит всех, потому что не знают люди все три. Хотя доучить человека дело полутора месяцев(я понимаю, о чем речь, так как стек мой, я тем же самым занимаюсь). И таких вакансий у них уже штуки 4.
Снова отказ от техлида по причине отсутствия пет-проектов и невозможности оценить практическую часть.
А можно было не отказывать, а сказать: "мы подумаем", а на следующий день попросить рекрутёра пригласить кандидата на второе интервью с лайв-кодингом (предупредив о нём).
Судя по всему, в конторе просто не нужен особо человек. Был бы нужен - студента бы наняли бы и научили бы. Тем более на микросервисы, когда зона твоей ответственности ограничивается контрактом, а задача разжёвана аналитиком и декомпозирована лидом.
Забава в том, что текущий техлид, это вчерашний сеньор, которому предложили место техлида в новом проекте за выслугу лет и опыт разработчика. Да и я лично не имел честь с ним работать до этого момента и только сейчас мы пересеклись как два специалиста на одном проекте. Благо начальство не глупое и видят проблему найма. К чему оно придёт, к сожалению, сказать не могу, но варианты решения уже предоставил.
Такие как этот техлид это психически больные люди.
...
Видать из конторы все бегут от этого шизика, вот людей и не хватает.
Встречал таких. Выглядит всё оч нелепо. Самое грустное, что заранее таких на чистую воду сложно вывести. А то и вовсе появляются на проекте по чьей-то воле.
У меня на одном собеседовании спросили, какой ассемблерный код сгенерирует компилятор Go для инкремента
Скажу так, я бы с удовольствием покинул IT, но слишком уже много времени и сил вложил в развитие себя в этой области (ещё со старших классов школы). И ничего другого я делать не умею
Ну, думаю, не стоит из-за одного собеседования с немного неадекватным интервьюером вешать нос) Я помню случаи когда и меня спрашивали, как будет выглядеть конечный автомат в async-await механизме в предкомпилированном коде c#. Но мне больше жалко людей, которые задают такие вопросы, так как все их знания и мир, как мне кажется, сконцентрированы на подобных вещах.
А по поводу того, чем бы заняться вместо it думаю любой выгоревший специалист думал. Даже я в какой-то момент подумывал просто скопить начальный капитал и заняться своим делом, достаточно банальным и без особых сложностей в процессах, но приносящих денег на уровне работы it-специалистом.
Да и не стоит думать, что другого не умеете) Я всегда был уверен, что большинство it-спецов умные ребята вне зависимости от сферы, но, к сожалению, не уверены в себе)
Ну, я бы предположил, что любой вменяемый компилятор для инкремента сгенерирует конструкцию на безе инструкции "inc", хотя... смотря для какой архитектуры - я только на x86, да Z-80 в ассемблер смотрел...
ничего другого я делать не умею
Газобетон класть всё умеют. Хрен ли там уметь? Верёвочку натянул, да клади :)
Ну не скажите. Видел я дома из газобетона с сантиметровыми швами которые сводят все преимущества материала в ноль. В идеале его вообще кладут на пену, но для этого нужен хороший завод с правильными допусками. Если человек не знает базу (теплопроводность газобетона) он положит как кирпич и будет глубоко не прав.
Видел я дома из газобетона с сантиметровыми швами которые сводят все преимущества материала в ноль
Ну, не то чтобы в ноль, свойства материала никуда не денутся, но режим подпортит, да.
В идеале его вообще кладут на пену
На сей счёт полного согласия среди специалистов пока что нет. Внутри помещений - да, никуда оно не денется, а лишнюю сырость разводить ни к чему. Дом строить на пене... я бы не стал.
Ну не скажите.... Если человек не знает базу...
Уточню. Любой ойтишнег (который ещё не достиг ожирения) может домики строить или там атамабили починять. Он же как привык: берём туториал и делаем по нему. А потом полирнём теорией. Ну или наоборот. А туториалов по стройке, причём очень хороших, в сети - завались! Поэтому да, любой освоит, было бы желание :)
Уже давно полное согласие специалистов в том, что класть удобнее на тонкий слой клей-раствора по горизонтали, и три-четыре полоски клей-пены по вертикали, дешевле просто на клей-раствор, и качественнее и надежней на клей-пену (при нормальных допусках геометрии блока). И да, строитель который боится клей-пены это человек, который не разобрался в вопросе и не хочет этого делать, что по сути профнепригодность и причина с таким не работать.
Не все хорошие техлиды - хорошие интервьюверы.
Все истории выглядят так, что техлид отбросил кандидатов по неадекватным причинам.
Я и сам таким был. Помню как гневался что приходится работать с людьми, которые не понимают почему float width = 1 / screenWidthPixelsCount; дает ноль.
Я бы таких на работу не взял!!!
Хорошо что я лидил, а не брал на работу. Потому что люди приходили, спрашивали почему не работает, получали ответ, исправляли и дальше просто делали свою работу.
А вы не имеете влияние на техлида? Если вы понимаете что техлид неправ, можно поговорить или попытаться отстранить его от собесов.
Потому что нужен Raft и Leader Election, а у вас консенсуса нет.
И в топку вашу базу, если вы не делаете HFT, embedded, web3, cryptography и паблик либы.
оффтоп, но расскажите, пожалуйста, как у вас получается "техлид нового проекта с опытом уровня senior"
Следующий уровень за senior у вас не lead, причём не technical lead?
Похоже что уровень lead над senior встречаю в вакансиях всего как несколько лет. Раньше это однозначно была роль. А уровней квалификации три.
И например teamleadом вполне мог быть middle+
По большей части имел в виду, что текущий техлид это бывший сеньор с большим опытом, получивший авторитет в глазах начальства. А оно, в свою очередь, предложило ему место техлида нового проекта. А тимлидом может стать любой разработчик, начиная с мидла, имеющий неплохие софт скилы и скилы менеджмента. Но, естественно, если есть необходимость в новом тимлиде.
"Крупные it-игроки ушли, с ними ушли стандарты, топовые специалисты и рабочие места. " - в первых же строках статьи автор дает ответ на все вопросы... И боюсь, что это только начало конца - госкомпаниям нет смысла переманивать разработчиков друг у друга бОльшими ЗП, а наоборот - проще сделать ЗП примерно одинаковыми, чтобы не переходили туда-сюда, да и прибыль от госконтракта не зависит от качества продукта (все равно купят), и, соответственно - от уровня разработчиков...
Тут двоякий момент. Если смотреть на уровень зп, то за 22-23 год темпов роста относительно одной и той же позиции почти нет. До этого год за годом зарплаты росли как на дрожжах, да и достаточно было пройти несколько собеседований чтоб получить оффер с +30% зп от текущего места. Сейчас таких чудес нет. А на счёт госпроектов сложно сказать однозначно. В основном реализация госзаказа прилетает частной конторе под пристальным взором или управлением свыше. Но it-шники тоже не дураки и работать за прайс ниже того, к чему они привыкли не всегда хотят. Из-за этого постоянно будет появляться конкуренция продуктов в тех или иных бизнес-доменах. Хотя есть один продукт-монополист в своей сфере в странах снг, 1с, но это частный случай.
распространенное заблуждение. Куча "новосозданных аккредитованных IT организаций", выделенных из штата, стали пилить свои продукты для широкого рынка, а не только для внутреннего заказчика. Соответственно и появляется конкуренция. Одних только альтернатив зуму и скайпу я уже десяток могу насчитать.
Либо проблема в техлиде либо автор чего-то не договаривает. Не хватает точки зрения второй стороны.
Прохождение интервью тренирует лишь скилл прохождения интервью. А по делу, обратный лайвкодинг не пробовали? Например, берём типовой алгоритм, делаем переменные неочевидными и под руководством кандидата рефакторим его на предмет нахождения имени алгоритма. Тут тебе и навыки чистого кода, и работа в паре, и реверс (программист он в первую очередь хороший читатель). Попутно про всякие биг-О можно поговорить и степень глубины знаний выяснить. Не стрессово, на полчаса времени, приближено к ежедневной рутине.
Это если рутина - копаться в легаси в попытке понять что там диды напридумывали внукам на головную боль.
Легаси это активы компании в которые вложены финансы, иногда очень серьёзные. Переписывать всё с нуля в угоду программистов это так себе вариант, особенно если бизнес привык считать деньги.
На почасовке без разницы сколько проектов поддерживать, на каком они стеке и насколько модны. Хехе, наверное я стар, если вижу в лигаси историю успеха компании. "Возвращаю тех.долги, дорого."
Кстати, мое самое лучшее собеседование примерно так и выглядело) Прошла его на ура и досрочно, получила оффер)
Хмм, интересно, не пробовал, стоит поразмыслить на счёт этого, спасибо)
Не за что. Собеседования кандидата сократились до двух звонков общей длительностью в полтора часа - 30 минут знакомство, 30 кодинг, 30 поведенческое финальное. Вы все равно не узнаете как сотрудничество пойдет через 3-6 месяцев. Кандидаты тоже занятые люди, и скажут спасибо за гуманное отношение. ФААНГ может позволить себе разбрасываться талантами, то набирая, то увольняя, а у маленьких лояльность это критический актив.
У меня было два лучших собеседования за последние 3 года (на самом деле значимых всего 4 за >20 лет, но пара из них не считается).
Исходно:
0) Удалёнка, Россия.
00) После пробивки HR (BTW, резюме читали, это уже плюс, но идиотские вопросы "почему ушёл" - сразу в минус, как и "почему к нам")
1) Тимлид: не будем тянуть кота за, вот два тестовых задания.
За второе даже не брался, после первого сразу оффер.
Расстались, увы.
2) Совсем недавно.
После первого созвона: "OK, дай мне минут 40"
???
"Посмотрел твой гитхаб, мне спрашивать нечего, давай начнём" (первый! за столько лет! не трахал мозги мусорными вопросами про коллективные ценности, и олимпиадными подколами, а посмотрел в реальный код)
Работаем :-)
А можно посмотреть твой гитхаб?
Да ничего интересного там нет. Так, какие-то ошмётки чего-то личного, да и то нерегулярно. Тут, скорее, сработало попадание в предметную область, конкретно вот эта мелочёвка - как затравка для более предметного разговора, безо всяких вступлений.
На этом моменте я усомнился в адекватности техлида.
то есть раньше таких сомнений не возникло ? 8-0
Можете написать, что у вас там была за задачка с литкода?
Я думаю правы оба, и техлид, и тимлид.
Без базы я бы не стал брать даже толкового программиста. Просто потому что есть риск в определённый момент нарваться на труднообнаруживаемые баги, которые принесут много неприятных часов в продакшине.
Расскажу пример. У нас закончился очередной проект и освободилось время. Мне дали задание поискать потенциальные проблемы в многопоточном C# коде проекта соседнего отдела. Код вполне рабочий, продажи идут. Через пару дней число заведённых мною багов перевалило за сотню и мне сказали "горшочек не вари". В основном потенциальные race conditions и незащищённые переменные которые могли изменяться одновременно несколькими потоками. С одной стороны пока не падало, с другой упадёт мало не покажется.
Но и вредничать особо тоже не стоит. Если в конторе культура кода и техлид покажет как и что делать - проблем не будет даже у тех кто плавает в базе. На то и техлид чтобы делиться знаниями и делать мир лучше. Если он социопат - пусть пишет КБ и делает код ревью.
Я вот как раз с последним случаем столкнулся - техлид не собеседует кандидатов. В итоге интервью проводили ребята из соседнего отдела и человек тупо не понял куда он попал, в итоге мучается, хотя мог бы выбрать другую компанию (было два оффера).
Совсем недавно было забавно, техинтервьювер думал подловить на вопросе чем отличается tas от ttas в спинлоке, а я совсем недавно эту тему копал немножко ну и выложил ему теорию и пять или шесть реализаций того и другого, еще и графиков нарисовал. Были круглые глаза и они с лидом полезли смотреть в гугль чем они реально отличаются, потом вопрос "А зачем тебе это?". Тут уже я сослался на митинг и ушел с созвона
Да, было то же самое на вступительном экзамене в ВУЗ когда я умудрился за день до этого прочитать книжку про гравитацию и получил билет по теории тяготения. Спустя полчаса оба экзаменатора просили меня остановиться.
Та же фигня :) В школе, выпускной экзамен по химии, мне досталась тема по полупроводникам (или конкретно про кремний, не помню). Экзамен устный, с подготовкой на доске. Я что-то быстро подготовился и, пока коллега отвечал, я начирикал на доске картинки из книжки Степаненко (учебник по микроэлектронике для ВУЗов), который как раз в то время листал, и заодно рассказал физику, как там орбитали устроены и как примеси влияют на тип проводимости.
Педагоги были слегка в ахере, но в целом довольны :)
Вот в этом и есть лоттерейность собеседований. База безгранична, всю не объять и не выучить, кандидат повторяет то, что считает нужным, а интервьюер базу по-другому определяет. Если совпадет, то хорошо, бинго) И неплохо бы, чтобы компании, раз уж из собеседования экзамен устраивают, выкладывали бы список вопросов, как в вузе за семестр. И пусть кандидат тянет билет, чтобы у него был шанс вытянуть единственно выученный счастливый билет))
В точку, как раз один из моих пунктов об этом) Если пазл представления о базе интервьюера сходится с базой кандидата, то происходит коннект)
А это кстати классная идея. Опубликуйте условных 100 вопросов (ну если так уж и хочется проверить "базу"), и если кандидат не подготовился по ним, то это уже говорит и про кандидата тоже. А с другой стороны, кандидат по "вменяемости" вопросов получит представление о интервьюерах.
Хожу на тех. собесы чтоб держать себя в тонусе и подтягивать скиллы.
Я тебе Google что ли, я забыл это уже давно. Отстань, у меня интеграция нереализованная.
Удручает ситуация, когда компании среднего уровня берут задачи для собеседования от Google и хотят чтоб кандидат решил их за ограниченно отведённое время (весь тех собес ~1ч 30м).
Что самое забавное, в этих компаниях работники занимаются перекладыванием json между микросервисами. И никаких тебе низкоуровневых, требующих реального знания алгоритмов, задач.
У Google и Яндекса такие собеседования из-за того что они ВСЁ реализуют сами. Остальные 95% пользуются готовыми решениями, и как правило лучшими, чем если бы вы написали их сами.
Но теперь очень мало компаний, умеющих расположить к себе. Очень мало компаний, которые сразу тебе скажут, на что ты подписываешься. Очень мало адекватных собеседующих и правильной культуры проведения собеседований.
У меня сложилось мнение, что таких компаний больше среди тех, у кого есть требование работы в офисе.
Как выглядят собеседования сейчас