Комментарии 473
Той же оптимизацией расходов оправдывали рабство, детский труд и 12-часовой рабочий день. Буквально невозможно вести бизнес, если всё это отменить.
Так ведь бизнес для общества, а не общество для бизнеса. Я согласен с констатацией текущего (прискорбного, на мой взгляд) положения дел, но не понимаю, почему эта констатация является оправданием для самой себя.
О, вентиляция. Если бизнес так хорош в оптимизации расходов, почему он не вынуждает строителей и эксплуатантов офисных зданий делать хорошую вентиляцию? Особенно тот, что про ИТ, где основная статья расходов это ФОТ, и теоретическое 5%-ное понижение производительности означает примерно также же прямое увеличение расходов и сроков поставки? Или снова общество должно доказать, что оно тупо задыхается в этих условиях? Причём даже когда это общество таки идёт доказывать, бизнес делает очень грустные глаза и говорит «ничего невозможно сделать».
Примеры хорошие, но получается все равно «а у вас негров линчуют». Проблемы с вентиляцией и столами совершенно не отменяют проблем с опенспейсами, вопрос только в массовости (которую ещё посчитать нужно правильно, конечно).
Приходиться включать кондиционеры, чтобы за счет конвенции воздух хоть как-то двигался.
Но тут другая проблема, всегда есть люди, которым «дует».
И решения этой проблемы нет.
Больше всего меня убило, когда те же проблемы обнаружились у только что построенного офиса…
У меня была только одна мысль — все начальство сидело на нижних этажах, и к концу рабочего дня (обычного офиса) никто не проверял как и что на верхних…
Экономия не про «уменьшите мне номинал всех расходных операций», а про «сделайте так, чтобы в итоге денег на то же самое уходило меньше». Например, найм молодых специалистов на должности QA и саппорта со ставкой 10 тугриков в час может значительно избавить от рутины разработчиков со ставкой 15 тугриков в час, и последние смогут больше фич делать/багов чинить. В итоге мы:
1) получаем лояльный кадровый резерв внутри компании (понятно, лояльность зависит от кучи факторов, но на мой взгляд разработчик, вышедший из QA/саппорта, лучше, чем просто разработчик, потому что видел больше);
2) за менее «хитрую» работу платим меньше денег (да, я в курсе, что тестирование тестированию рознь);
3) получаем больше выхлопа от разработчиков без найма новых разработчиков.
В случае с вентиляцией такая же история: один раз тратятся деньги на пристойную систему вентиляции, потом эти же деньги плюс эксплуатационные расходы все равно размазываются в аренду, но на выходе мультипликатор к выхлопу вообще всех, работающих в этом здании (точнее, снятие штрафа за гнетущую атмосферу, который тоже множитель). То есть, чем более качественно работающего человека вы в это здание посадите, тем больше в абсолютном значении прибыль от вентиляции против ее отсутствия.
И вообще, от зарабатывания появляется больше денег, чем от их экономии, потому что сэкономить больше своих затрат очень сложно (математика запрещает), а получать больше прибыли — просто сложно.
Проблема в том, что людей, которые умеют это делать — меньшинство. До тех пор, пока бизнес не выделит «управление офисом» в отдельную сущность. Заработок которой зависит от производительности сотрудников — подвижек не будет. Ни по одной теме, что были уже озвучены.
Как только бизнес выделит "управление офисом" в отдельную сущность, то внезапно выяснится, что это чисто расходная статья бюджета, а раз так — то на ней всегда будут резать косты. Дальше пояснять? Хотя, конечно, есть шанс (мизерный), что что-то будет хорошо
Я сделал доклад про влияние углекислого газа на самочувствие с соответствующими замерами в офисных помещениях, и выступил в филиале, в котором работал. Следующим этапом должен был идти тот же доклад в основном офисе, но мне сказали что тема «скользкая» и давай на этом остановимся.
… через некоторое время ушел на удаленку, в той ситуации это был самое простое решение проблемы вентиляции )
Или снова общество должно доказать, что оно тупо задыхается в этих условиях?
Именно, а пока это общество, в массе своей — собрание терпил и лохов, не знающих даже где находится трудинспекция, прокуратура и здравнадзор, то только так к ним и будут относиться.
А даже если и вынуждает, на каждую хорошую вентиляцию найдётся девушка с малярным скотчем, которой дует.
Проблемы с вентиляцией и столами совершенно не отменяют проблем с опенспейсами
Не отменяют, но взаимосвязаны. При кабинетной системе обеспечить нормальную вентиляцию и дневное освещение сложнее, чем в опенспейсе :)
К сожалению, у меня опыт прямо противоположный — в опенспейсах всегда дышать можно (хотя каждый под себя, отегулировать температуру не может), а в кабинетной системе либо кто-то постоянно держит открытой форточку отчего половине сидящиих там сквозняк в спину наяривает, или наоборот всё задраено, как на подводной лодке и дышать совсем нельзя.
Ну и если стол в кабинете у окна — нормально с освещением, а те, что стоят у двери — без искуственного света работать невозможно.
Конечно, все эти кабинеты не в бизнесцентрах класса А были, может быть там и получше — но там я отдельные кабинеты только у начальников встречал.
Ну и если стол в кабинете у окна — нормально с освещением, а те, что стоят у двери — без искуственного света работать невозможно.
В опенспейсах чисто физически все столы у окна поставить не получится. Ну разве что это не переделанный под офис коридор. Там всегда будет исскуственное освещение для большинства. Кабинет при этом хотя бы в теории может быть достаточно маленьким.
В опенспейсе могут быть панорамные окна и тогда даже достаточно далеко от них светло. Иногда даже слишком светло.
Они точно так же могут быть и в кабинете, я в таком работал. Я не уверен что там были именно панорамные, я не силен в определениях окон, но окно во всю стену от пола до потолка там было. Кабинет был на 4-6 человек и света там было более чем достаточно.
p.s. Как часто в договорах на аренду офиса указывается воздухообмен?
PS
Не реклама сбербанка, давно там не работаю. Просто говорю, что некоторые работодатели легко на это идут
PPS
А опенспейсы все равно не для меня. Давно работаю из дома из своего кабинета(но тут такой же опенспейс, только с детьми)
Одно не отменяет другого. Разумеется в нормальных офисах должны быть такие столы. Знаю людей у которых проблемы со спиной если они долго сидят им без стоячих ( а точней меняющих высоту ) столов вообще никак.
За 12 лет работы мне ровно один раз попался офис с качественной вентиляцией. БЦ Технополис на Пулковском. Строили вроде финны (и вообще это финская сеть), что очень было заметно по дизайну. И вот они озаботились нормальным централизованным кондиционированием и вентиляцией. Причем не знаю, как оно было сделано, но летом было прохладно и при этом не дуло ниоткуда. Так что и войн между сотрудниками за пульт от кондиционера не было.
Все, больше нигде такого не было. Везде в лучшем случае кондиционеры как-то сами колхозят, а в худшем — и их нету (денех нет или на фасад ничего вешать нельзя). Действительно, никто не воспринимает это как проблему. И никакой договор вам тут не поможет — просто БЦ с нормальной вентиляцией очень мало, выбирать не из чего.
Ваша ошибка в том, что вы хотите оправдать бизнес, а это не требуется.
Если вы достаточно ценный сотрудник (или можете кооперироваться с коллегами), то получить себе вентиляцию не сложно (я попросил, нам за три месяца сделали на два кабинета).
Если недостаточно (и найти работу лучше вы не можете), тогда да, придётся без стола и вентиляции. Но и в этом случае оправдывать бизнес нет смысла. Их экономия виртуальна (на вашей производительности), никакого особого смысла нет для них, ни для общества в целом тут нет.
Почему весь хабр начинает сочится кислотой при упоминании слова «опенспейс»?
Потому что работали в опенспейсе, и есть понимание, что от «закрыться у себя в комнате на два часа после работы» даёт выхлопа в разЫ больше, чем четыре часа в опенспейсе, где все ходят, кто-то с кем-то разговаривает, непонятно, тебе ли машут рукой, неясно, какому Никите нужно обратить внимание на того парня за другим столом… или стоп, это был парень за соседним? А Вас когда-нибудь отвлекали запахи? Есть разные типы бутербродов, пицца, какая-то лапша, несколько видов кофе с какими-то непонятными… ароматизаторами? а ещё в опенспейсе этот кофе могут с очень колоритным звуком похлёбывать из кружки. Затем ставить эту кружку на чашку. И это не три-пять человек. Этих людей в среднем минимум три десятка. Плюс проблема с вентиляцией. P.S. Видел три опенспейса, ни в одном не было запрета пить кофе, и там же попутно есть
P.S. Видел три опенспейса, ни в одном не было запрета пить кофе, и там же попутно есть суп с бутербродом печеньки.
у нас такая дичь не принята....
То есть всё достаточно продумано и жить вполне можно. Но во первых они строили с нуля и потратили кучу денег. И не все фирмы на такое готовы пойти.
А во вторых лично мне всё равно комфортнее в кабинете в котором сидит только моя команда разработки и всё. Даже если этот кабинет сам по себе не настолько «продвинут».
Особенно когда начальники, в том числе большие, не видят в этом проблемы…
Но мне приятнее когда мой кофе стоит у компа. И если со мной в кабинете сидят люди, которых это не волнует, то я бы лучше делал так. В кабинете с моей командой я могу просто договориться о том могу я так делать или нет. В опенспейсе я это сделать уже пожалуй не могу.
Или вон у нас кто-то постоянно приносит в кабинет «вкусняшки» для всех. Иногда они пахнут. Иногда мы их едим прямо в кабинете. В опенспейсе такое не получится.
Поэтому можно наверное сказать что «культура кабинета» лично мне ближе чем «культура опенспейса». Намного ближе.
Я молчу про очень раскрученную сейчас тему «работы стоя».
Тут иногда срабатывает инстинкт «а вдруг все такое захотят». Типа почему Васе купили, а мне нет. Мне так, отказали в стойке для монитора за 50$. Купил сам и унёс домой, когда уволился. Ничего ужасного не случилось.
Ну, если общество докажет, что личные кабинеты — это этическая необходимость, я уверен, что бизнес со временем прогнется. Во всех отраслях.
Хотя бы тем, что эффективность работы растет. Ах, да, никто же это не считает и работодатель это считает само собой разумеещимся… А больничные из-за того, что все в опенспейсах друг друга заражают?
Сейчас же в любой отрасли кабинеты — либо дорогой бонус для начальства.
Вы смотрите в суть. Кабинет — становится привилегией. Чтобы начальство друг другу показывало свое значимость
Всё же данный факт не является аргументом в пользу того, что "оптимизация расходов в виде опенспейсов — зло"
Как мне кажется дело больше в культуре. Я работал в опенспейсе среднего размера, где было тише и комфортнее, чем в большом кабинете с меньшим числом людей на другом месте работы.
Потому что программирование — это в первую очередь концентрация на протяжении нескольких часов.
Хотя личные кабинеты, тоже не идеальное решение, сейчас разработка чаще всего ведется в команде и с командой надо общаться. Так что на мой взгляд идеальное помещение — это большой кабинет на команду, где у каждого есть стол с перегородкой, за которой можно спокойно сидеть погрузившись в свою задачу. И общее пространство в центре для внутрикомандных встреч.
Что касается затрат — зарплаты разработчиков настолько высокие, что на их фоне размещение по кабинетам или i9 процессоры — это пустяки.
зарплаты разработчиков настолько высокие, что на их фоне размещение по кабинетам
Ну, вообще говоря, офисы в башне «Федерация» как бы не дороже разработчиков в пересчете на квадратный метр обходятся.
У мистера Андерсона так вообще почти целый кабинет. А мне хотя бы стенки спереди и с боков уже были бы огромным благом. Неужели так дорого и настолько больше занимает места?
ну или хотя бы направление в ту сторону )
Это создали именно для того, чтобы повысить производительность труда, т.к. раньше до 60х годов были те самые опенспейсы — огромный ряд столов с людьми. Люди в таком мучались.
Кубиклы резко улучшили производительность, но были слишком дороги.
Там, где стоят 2 кубикла можно посадить в открытом пространстве 3-4 работника.
Дальше дорожки опенспейсов разошлись. Богатые корпорации делали опенспейсы с огромным пространством, чтобы люди могли чувствовать свободу. Там было много места на малое количество работников. Ну и бедные просто отказались от кубиклов, набивая людей как килек в банку.
Интровертам, которые работают головой сконцентрировавшись на задаче по нескольку часов, придумывая творческие или сложные решения почему-то мешает гул и шум и проходящие люди, действительно, что не так?
Мешают люди, которые к тебе обращаются по мелочам. Мешает даже сам факт, что люди могут к тебе обратиться по какому-то пустяку. Особенно, мешают вежливые приветливые люди, выполняющие функцию социальных клоунов, которые не могут пройти мимо тебя не спросив чего-нибудь из вежливости.
И работая в опенспейсах, меня больше беспокоит не столько то, что ты перед собой видишь, а то, что скрыто от твоего взора — то, что происходит у тебя за спиной. Я ненавижу рабочие места, где сзади тебя могут происходить какие-либо события. За моей спиной должна быть стена и ничего большее!
— о да! Поэтому меня напрягает есть на кухне в нашем офисе: раз 20 за обед надо с набитым ртом ответить «Спасибо!» на чьё-то «Приятного»
Так и хочется ответить этим очень вежливым людям: «Господа, позвольте мне уже отобедать!»
стульчики из икеии, на которых сидеть очень неудобно.
и для платящего за это — 4 человека на 100кв.м.
так себе офис мечты.
Кстати, я не люблю паласы, я бы даже его не заметил. Но вот этот вроде не плох.
Стул, на котором сидит чел слева — это стулья для конференций. У них есть особенность — возможность складываться один на другой и тем самым не занимать много места. Это, разумеется, накладывает некоторые ограничения на конструкцию стула и не может положительно сказаться на комфорте. Но, конкретно этот стул обладает строением ножек, за которые можно повесить небольшой столик с поворотом. Столик можно использовать для записи в тетради или для ноутбука с небольшой диагональю.
Столик можно использовать для записи в тетради или для ноутбука с небольшой диагональю.
Я понял, что я хочу такой поворотнйы столик для кресла IKEA
Низкий уровень серотонина, вот что не так.
Без понятия, почему этот коммент так заминусован. Я был приятно удивлен, в первый раз посетив свой текущий опенспейс — звукопоглощающие потолки + ковры обеспечивают очень тихую среду. Лично мне этого более чем достаточно (но да, это все равно не идеально, некоторым коллегам все равно нужны наушники).
Хотя вот лично мне было бы не очень комфортно, когда кто-то за соседним столом периодически крыл бы матом всю родословную какого-нибудь менеджера.
крыл бы матом всю родословную какого-нибудь менеджера.
К счастью, не могу представить на своей текущей работы такой неадекват (неконструктивную даже-не-критику в направлении конкретного человека)
Который любит очень громко, матом, выражать своё недоумение
Опенспейс — это не только "open", но и "space" — и места лично у меня чуть более, чем дофига. Люди могут собираться/кучковаться в произвольных местах, никому не мешая. (Даже не нужно далеко отходить, уже у соседней линии столов ничего особо не слышно). Обычно, если несколько человек из одной команды кучкуются для обсуждения, они только этим действием создают вокруг себя довольно таки большую "зону отчуждения".
К тому же, если кто-то таки мешает, можно пойти в специальные зоны, где обычно никаких громких переговоров нет.
Но когда все-таки происходит, заглушенная потребность выразить эмоции приносит чувство дискомфорта, что в свою очередь снижает работоспособность и выводит из потока.
Зато у нас высокий корпоративных дух, да!
На самом деле, я лично не знаю как это решать, но не придерживаюсь мнения что любое удивление нужно выражать матом.
Я лично работаю над матерым легаси, и те решения которые я иногда обнаруживаю в коде иногда ломают мозг. Посколько я единственный русскоговорящий сотрудник в команде, я стараюсь не выражаться вслух громко, и это часто действительно приносит дискомфорт.
Как вариант можно выматериться в подушку =)
Я займу нейтральную позицию, имхо «очень громко» и «молча пыхтеть» — это две крайности.
Разряжаться нужно! =)
В годы моего студенчества ходил по фидонету прикол что в японских офисах для разрядки устанавливают боксерские груши с фотографиями начальников.
Еще один прикол — про тумбочку на колесиках, ее пинаешь ногой, а она тебе голосом — «извините!».
Самое главное при работе в коллективе это не создавать конфликтов. Потому что конфликты трудно разруливать. Об этом мне поведал мой щёгун босс в первой моей компании.
Вот вы зачем их создаете, конфликты?
Я сижу в опенспейсе, который был сдан в эксплуатацию в феврале (это о новизне). В 3 метрах от двери… И каждый день через эту дверь проходят десятки людей. Каждый день я слышу десятки раз эти клац-клац-клац автоматического запирания. Раз за разом, каждый день. Это — ;"(;№)(;№;)
Так что не надо мне врать про "современные материалы" и "хитроумную конфигурацию" — уж на чём на чём, а на этом НИКТО из застройщиков НЕ запаривается. Опенспейс — это НИ В КОЕМ СЛУЧАЕ НЕ "реально удобная для работы среда".
Если вам удобно сидеть, когда регулярное клацанье отвлекает вас от работы — вам повезло. Мне — увы, но нет.
Каждый день я слышу десятки раз эти клац-клац-клац автоматического запиранияВидимо у вас ещё не пиликает при открытии)
Пиликает, но лишь в половине случаев: только если проходить в помещение, если выходить — обычный клац.
Отвечу тут же и DMGarikk — вентиляции слава богам не слышно.
уже в третьем опенспейсе сижу… где весь день в фоне постоянное у-у-у-у-у-у помню в одном было интеллектуальное управление зданием… там после 19.00 она отключалась… буквально оргазм можно было испытать от звенящей кристальной тишины которая буквально падала с потолка
При коллективах в 30-40+ человек без логических отделений на комнаты сложно добиться того, чтобы люди чувствовали себя одним коллективом. Я слышал объяснение что это связано с тем, что численность племени как раз была примерно в этих пределах. Чем больше людей в оупенспейсе — тем сложней возникновение дружеских/приятельских связей, которые для людей очень важны и сильно влияют на комфорт/удовольствие/общее впечатление от работы. Чем больше коллектив, тем больше средств и усилий придётся потратить на то, чтобы он был сплочён.
Я вообще за home office. И удобно, и реально можно сэкономить. А кабинеты да, остались. Это зависит от компании
И займитесь действительно конфигурацией опенспейса, а не «дизайнерскими» столами, с перегородками которые ничего не заслоняют и не глушат никак шум…
А иначе не удивляйтесь текучке кадров, сопровождая шум в списке причин «а вот в городе Н у нас в офисе еще шумнее!»…
Почему все так не любят опенспейсы?
чтобы не слышать разговоры пятидесяти людей вокруг или не сидеть в шумопоглощающих наушниках
Скажите, вот чисто из любопытства праздного, вы зачем спросили то, на что был дан предельно прямой ответ прямо в статье?..
На хабре нет 20 статей о плохой парковке почти в каждом бизнес центре. А о опенспейсе есть.
потому что в тех местах где работает большинство айтишников в РФ, ездить на машине, даже при наличии парковки — это боль и страдания
а вот опенспейс есть у всех, можно еще посетовать на воровство продуктов из холодильника
Парковка, в Москве, к примеру, вообще почти никому не нужна (доступность общественного транспорта и дороговизна). Нехватка кислорода вполне списывается на усталость, со столами — вообще очень узкоспециализированная проблема и прочее.
Есть большая разница между проблемой которая достаёт почти всех и теми, которые относятся скорее к разряду вкусовщины. =)
ЗЫ: более того, ситуацию усугубляет абсурдность данного фактора. Опенспейс преподносят как великое благо и пользу — это же обмен идеями! лёгкое общение! Но, по факту, он нужен руководству (экономия), а сотруднику даже мешает.
Никто, ни один комментатор не прочел мой вопрос как есть. Все увидели совершенно другой вопрос.Возможно, если все вас не поняли, то проблема не во всех, а в вопросе.
Я спросил почему из всех проблем работы в офисе — именно эта тема самая больная?Я вот в упор не вижу ничего похожего в изначальном комментарии.
Если вам интересна эта тема — могу рекомендовать начать ознакомление со статей Спольски («тест Спольски») и трудов ДеМарко
П.С. В бизнесе лучше увеличивать доходы, чем сокращать расходы. К сожалению, сокращать расходы проще, поэтому это первое что обычно делают. Увеличение эффективности команды в долгосрочной перспективе с большой долей вероятности даст бОльше прибыли, чем просто снижение расходов. Milfgard в своей книге хорошо описал случай, когда страх предпринимателя потратить чуть больше денег, чтобы получить больше прибыль, мешает быть эффективнее
Потому что работать в них в большинстве случаев неудобно. Проведено уже достаточно много исследований, показывающих что эффективность сотрудников в опенспесах падает существенно. Особенно в сферах умственного труда.
Это потому что сама идея «open space» была в том чтобы дать людям больше воздуха и пространства, а сейчас почему-то все пришло к идее впихнуть как можно больше людей на один квадратный метр.
Сегодня вы сидите в опенспейсе, завтра вы будете сидеть с коллегой за одним столом, а послезавтра делить с ним одно кресло.
Стоп, какое кресло, у нас же необходимая оптимизация расходов! Сидите на табуретке. Вот вам табуретка на двоих, как хотите, так и сидите.
И вообще, если вдуматься, два разработчика лишние. Уволим одного, а второму будем платить в два раза меньше. В качестве плюшки пообещаем опцион, обяжем подписать NDA, а в NDA засекретим даже название фирмы.
Необходимая оптимизация расходов же.
Ах да, корпоративный гимн надо не забыть. И штрафы для тех, кто путает слова.
P.S. [табличка "сарказм"]
Если бабла так мало, не хватает на нормальный офис — пусть работают по удаленке
Сколько мест с таким (или приближенным, желательно с указанием степени приближения) процессом собеседования Вы наблюдали лично? А сколько наблюдали мест, которые удовлетворяли хотя бы четырём из шести «хотелок»? Сколько из них были в РФ?
Я когда это всё людям в компаниях начинаю рассказывать, на меня смотрят как на идиота, и мне интересно понять, обоснован ли этот взгляд.
Значит, не сказки это, есть такие места, буду дальше искать.
Меня недавно спрашивали на собеседовании, что такое модель OSI, и настаивали, что это очень важное понятие, и как можно не знать (а я знал о ней в последний раз в институте, когда она в вопросах к зачёту была). При этом на тогдашней моей инфраструктуре за полчаса можно было сделать так, что в пакете с данными три раза встречается заголовок IP и по одному разу TCP и UDP. Но нет, уровни важнее.
Значит, не сказки это — есть такие места: буду дальше искать.даже если сказки — даже в них есть намек для добрых молодцев. Основная проблема — это наличие у соискателя «подушки», позволяющей не торопиться с выбором\решением.
П.С. Правда мой опыт тоже «территориально» относится к центральной Европе.
Это очень помогает, когда работаешь в команде.
Например у вас есть какой нибудь modbus, который вы считываете в сыром виде на 4ом уровне OSI. И есть приложение, которое парсит эту порнографию и инкапсулирует в 6ой уровень оси и отправляет по https у в виде запроса.
О, давайте побеседуем. Тот пример про три раза IP и TCP с UDP это «всего лишь» HTTP-трафик, завёрнутый в IPIP, завёрнутый в VXLAN и снятый, соответственно, с интерфейса гипервизора. При этом мне известно про существование scapy, где можно заворачивать вообще всё что угодно во всё что угодно пока пакет влезает в среду (на нём я начинал делать blackbox-проверку корректности настройки концов этих самых IPIP-туннелей, но вышло медленно и криво, поэтому переделал на табун фактических туннельных интерфейсов в ВМ).
То есть принципы разбиения на уровни и инкапсуляции я знаю, и также знаю, кто какой «конверт» заворачивает и разворачивает. Но я совершенно не помню, как называются эти семь уровней OSI и какие характеристики они в себе несут, и по своим ощущениям я ни разу от этого не пострадал, включая моменты отладки всего этого департамента мостов и тоннелей, в том числе при разговорах с сетевиками. Даже если это требуется, можно всё за две минуты посмотреть в той же Википедии и потом выкинуть из головы после окончания разговора до следующей проблемы. Зачем эти все мелкие детали прямо специально знать, если встречаешься с этим хорошо если раз в месяц?
На практике был случай, когда я говорю «Посмотри, с каким уровнем ОСИ работает та либа, что ты говорил», а мне в ответ «Что такое ОСИ?»
Сплоховал, вопрос-то я точно и не помню. Помню, что на ответ «это такая модель коммуникационных протоколов из семи уровней, нижний физический, верхний — приложений, больше про неё ничего не помню» получил огорчение столь поверхностным знанием.
На практике я сам недавно на вопрос собеседующего «скажи мне broadcast-адрес вот этой сети» несколько минут нёс такую ересь, что аж страшно потом стало. Но маски я считаю ещё реже, чем копаюсь в туннельном трафике.
Или еще вопрос от него же, «Минимальное кол-во интерфесов необходимое для маршрутизации трафика», я ответил один, на что получил корректировку совсем не связанную с вопросом «Не правильно, 2, какой смысл настраивать маршрутизацию на машине с одним интерфейсом».
А ты ему такой заворачиваешь — что там хитрая сетка с хитрой адресной политикой и несколько шлюзов, ЛОЛ. Или впны-шмепеены и вирт интерфейсы.
Забавно, что все большие финтех и продуктовые компании — это с 99% вероятностью оупенспейсы (в смысле — я видел 100%, но вдруг где-то иначе?).
К примеру, мне абсолютно не понятно, как при дефиците разработчиков, средненький стартап в Берлине устраивает 5 собеседований? В этом есть положительный момент, все это сильно увеличивает желание никуда не дергаться с текущей работы.
Если кандидат любит свою работу, а это видно по отношению к работе и кругозору, то это уже неплохой взгляд. А если не может сформулировать что именно делал на прошлом месте (ответ задачи в 50% случаев, какие — ну там ПМ ставил) или же блокчейн-бигдата-ai-микросервисы, то тут все ясно.
И к тому же, на вакансию может набежать десяткок людей с опытом «прошёл курсы Бигдатасатанист за 2 недели» и запросами от 250.
Он не верит во всякие переходы на .Net Core, разбиение монолита, микросервисный подход и высокие нагрузки.
Всегда в таких случаях вспоминаю свою работу, на которой использовался C# 2.0
Видимо у них тоже нашёлся 10-летний синьор, который не верит, не знаю. Но суть в том, что кодовая база от этого точно не выиграла. То, что даже в C# 4 автоматизируется одной строкой, там приходилось решать сотнями строк.
Остается надеяться, что только условные гуглы и будут писать на Хабре о 5-10 этапах найма с задачами о люках. Однако дождемся ли мы таких времен?
Чувствую что COVID сделает такие времена ощутимо ближе, судя по томатному пюре на биржах.
Потому что я вроде как бы тоже попадаю под описание «сениор с многолетним опытом работы (10+ лет), который успел поработать в нескольких конторах над несколькими проектами. За свою немаленькую карьеру такой разработчик, скорее всего видел и махровый легаси и смузи стартапы и кровавый энтерпрайз»
Но при этом как минимум в «переход на .NetCore», «разбиение монолита» и «гибкие методологии» я верю. И я вполне себе это видел «вживую» и вполне себе работающим. Не идеально работающим конечно, но вполне себе работающим.
И против «пятничных посиделок и тимбилдинга» я тоже ничего против не имею. Особенно если они включают в себя и семью и детей.
И точно так же я ничего не имею против сэндвичей, всяких «фруктово-овощных корзинок» и смузи в офисе. И если такое есть, то я с удовольствием этим пользуюсь.
То есть в статье на мой взгляд многое написано правильно и я готов под этим подписаться. А многое сильно субъективно и я с этим наоборот совсем не согласен.
На правах ИМХО — сейчас статью больше людей плюсануло, чем Ваш комментарий. Конечно, методологическая база моего сравнения не очень убедительна, но более точно сравнить все же можно будет если опишите свое видение в виде статьи и соберете свои плюсы. Однако текущий разрыв в оценках на целый порядок компенсирует несовершенство методологии.
Мысль была в том, что все вышеприведенное — это не решающий фактор. Хорошо, когда кола есть, но лично я ни разу не шел на работу из-за этого.
Более того, я сам не так давно занимался попытками разбиения монолита и переводом на Core, и это было примерно как проктологом работать. Просто сам факт перевода — это не плюс совсем. Вот если с нуля нормально писать, тогда да.
Тут скорее о том, что приходишь на собес, тебе "продают" позицию рассказами "сейчас у нас легаси, но мы всё обновим, на микросервисы разобъём, тестами покроем", принимаешь офер, но ничего особо не меняется. Или меняется, но так что лучше бы не менялось.
Тут скорее о том, что приходишь на собес, тебе «продают» позицию рассказами «сейчас у нас легаси, но мы всё обновим, на микросервисы разобъём, тестами покроем», принимаешь офер, но ничего особо не меняется. Или меняется, но так что лучше бы не менялось.
Если это те же люди что и написали всё существующее «легаси» — скорее всего, ничего хорошего по технической части ждать не стоит.
Как могут люди, не сумевшие качественно написать монолит, построить распределённую систему?
Но при этом как минимум в «переход на .NetCore», «разбиение монолита» и «гибкие методологии» я верю. И я вполне себе это видел «вживую» и вполне себе работающим. Не идеально работающим конечно, но вполне себе работающим.
Вы немного не так прочитали этот тезис в статье, на мой взгляд. Речь не о том, что так не бывает — конечно же бывает.
Речь о том, что когда мне говорят про это — я автоматически не верю, пока не доказано обратное. Потому что мой опыт мне подсказывает, что в подавляющем большинстве случаев (как минимум 9 из 10) за этим скрывается либо маркетинговый (в плане «продажи» компании кандидату) bullshit, либо же искреннее, но непрофессиональное желание так сделать — это когда, скажем, миграцию на более актуальные технологии действительно хотят сделать, но из-за неопытности не понимают ни масштаба затрат на миграцию, ни масштаба потерь при её отсутствии.
Зато когда мне кто-то рассказывает о том, как они в стартапческом запале налабали кучу кода, которая настолько плоха, что уже превратилась в легаси, а проект всё еще даже не вышел из стадии стартапа — этому я по умолчанию верю. Это как раз дело крайне нехитрое.
Но вы серьезно думаете, что разработчик с десятилетним стажем, работавший хотя бы по 1.5 года на каждом месте, успешно в течении десяти лет обманывал всех, что он не умеет писать код?Дело в том что это может быть разработчик с «десятилетним» стажем и интенсив курсами прохода технических собеседований. Предвидя возражения по повожу проверок «десятилетнего» опыта, могу возразить что практически у любого человека есть несколько знакомых со своими фирмами (даже ИП сойдёт), которые по просьбе, подтвердят что да, был такой, работал главным специалистом по бигдате и блокчейну, пять лет и т.п. и бумажку выдадут, если надо. С печатью.
Даже конторы есть специальные которые за деньги это вам сделают, не подкопаешься.
А если это так, почему вы уверены, что ну вот ваше техническое интервью его раскусит?Это не для того чтобы раскусить, а чтобы можно было проверить ширину знаний и увидев пробел, можно поковырять его, чтобы нащупать как глубока кроличья нора.
Как раз традиционное (сейчас) собеседование легче пройти после подобных интенсив курсов, книг, тренингов. Имея просто 10 лет опыта разработки, успешых проектов и реального вклада в бизнес, собеседование гугла, фб или амазона не пройдешь.
Это не для того чтобы раскусить, а чтобы можно было проверить ширину знаний и увидев пробел, можно поковырять его, чтобы нащупать как глубока кроличья нора.
Еще ни разу в жизни не видел, чтоб нащупывание «пробела в знаниях» на собеседованиях не было бы чем-то иным, кроме как попыткой самоутвердиться (или «продавить по зп», что тоже самое, только в финансовом разрезе) за счёт кандидата.
Пробелов у специалиста, копающего на безбрежном поле знаний (а разработчики именно такие) всегда можно найти бесконечно. Я бы даже сказал, что если вы в ходе часовой технической беседы не можете найти пробелов у собеседника — это скорее всего означает, что собеседник намного выше вас уровнем (не обязательно в программировании, вполне возможно, что он гораздо сильнее вас в прохождении собеседований).
Разговор за жизнь, это хорошо, но должна быть техническая состовляющая. Я например привожу кусок легаси кода где сделаны все возможные ошибки и прошу объяснить что сделано неправильно, почему и как поправить.
Никаких сортировок, круглых люков, тестовых заданий и т.п., но работает как магия. Через пять минут видно если человек имеет представление от том что он видит.
Если вы сами проводите интервью, то уверяю вас, вы должны были увидеть столько случаев попыток пролезть на позицию повыше, что трудно чему либо удивиться.
Попытки пролезть повыше нет смысла фильтровать через поиск «пробелов в знаниях», иначе вы наймете профессионального проходителя собеседований, и — ну, удачи с ним работать.
Я например привожу кусок легаси кода где сделаны все возможные ошибки и прошу объяснить что сделано неправильно, почему и как поправить.
Подход плох тем, что разговор об ошибках в коде не имеет смысла вне контекста остального кода, если только мы не про ошибки компилятора (а ошибки компилятора найдет и компилятор) или алгоритма (а ошибки алгоритма видны при знании алгоритма и не видны без оного, поэтому это то же самое, что и просить кандидата этот алгоритм написать). Итого вместо того, чтоб действительно проверять технические навыки кандидата, вы, как и обычно, проверяете принадлежность кандидата к «своим» — если у него общие представления о хорошести кода совпадут с вашими, то он ваш тест пройдет, а если нет — то нет.
var fs = new FileStream(@"d:\data\" + Request.QueryString["filename"]);Одна строчка, а разговора может минут на десять, чтобы ответить что? почему? как надо?
Подобного всего строк двадцать, но большиство распространнённых ошибок присутствует.
А вы мне рассказываете про ошибки компилятора и «итого вместо того, чтоб действительно проверять технические навыки кандидата, вы, как и обычно, проверяете принадлежность кандидата к «своим»».
Я написал что мы это использовали много раз и результат превосходит альтернативные методы по качеству и временным затратам. Как для нас, так и для собеседующихся.
Здесь два момента — отсутствие «using»
«Представьте себе, что вы компилятор» (с)
и directory traversal
А она тут есть. А что параметр filename называется — ну, «так исторически сложилось, публичный API не хотели трогать» (с). Ничего не мешает в нём передавать хвост с директориями.
Одна строчка, а хорошего общения тут примерно нисколько, ибо контекст у этой строчки отсутствует.
Вы конечно будете говорить я C# не знаю, я фронтендер, моё дело аттрибуты цвета выставлять. Ну вот и выставляйте.
Но вот ваш ответ, с другой стороны, очень хорошо иллюстрирует мой начальный тезис об необходимости самоутвердиться за счёт кого-то еще. Спасибо.
Но вот ваш ответ, с другой стороны, очень хорошо иллюстрирует мой начальный тезис об необходимости самоутвердиться за счёт кого-то еще.Наоборот, это ваш ответ подтверждает правильность методики интервьюирования.
Одна строчка кода выявила три проблемы. Одну общую и две технических.
1. Общая и наиболее важная — не зная C# и осозновая это, вы же незамедлительно бросаетесь судь о чём либо с высоты своего невежества. И после этого оправдываетесь отсутсвием знаний. Это характеризует вас как человека с «душком».
Нормальный человек хотя бы сначала спросил про что вообще речь идёт, вы же сразу начинаете поливать собеседника известной субстанцией.
2. directory traversal это базовая концепция и к C# не имеет отношения. Судя же по вашему ответу вы не имеете понятия что это вообще такое.
3. Поверх этого, вы начинаете рассуждать о проблеме с именованием параметра filename, т.е. вы серьёзно обсуждаете использование анти-паттерна «security through obscurity», что добавляет ещё один штришок к общей картине.
В целом я бы порекомендовал вашему работодателю отправить вас на курсы повышения квалификации. Хотя для джуна, это вполне простительно, не сразу Москва строилась.
То есть грубо говоря на мой взгляд как минимум у вас в голове какой-то контекст существует и вы оцениваете ситуацию исходя из него. Но с «кандидатом» этим контекстом вы при этом не поделились…
Потом, в моём комментарии я говорил о куске кода где-то в двадцать строк, этого достаточно для понятия контекста.
Ну и тем более если фронтенд девелопер, начинает трактовать два слова Request и QueryString как-либо кроме получения значения параметра из query string, это звоночек посильнее всех трёх вместе взятых. Говорит о том что он вообще не понимает что такое query string. Это уже клиника (для фронендера).
Если же он задаст вопрос
валидируется или авторизируется значения из Request.QueryStringто это как раз тот разговор который я ожидаю. Сразу понятно что человек мыслит в каком-то направлении и понимает процессы происходящие (или могущие происходить) на более низком уровне.
И вполне допускаю что мое мнение не правильное, за что заслуженно получил пару минусов в карму.
Я поделился опытом, который _может быть_ полезен начинающему интревьюеру, привел пример и в благодарность был облит помоями от человека который потом сам говорит — ну я же в этом ничего не понимаю, что вы от меня хотите.
И ваше «Подобного всего строк двадцать, но большиство распространнённых ошибок присутствует» лично я понял как наличие вот таких вот не связанных между собой строк кода, которые сами по себе должны содержать какие-то «распространённые ошибки».
П.С. Ну и у меня например первый вопрос который возник при взгляде на ваш код был а почему «d:\data\» не запихнуто в какую-то константу.
Я вообще не понял что это за строчка — видимо, что-то сишарп специфичное и мне нужны пояснения ))))
П.С. Ну и у меня например первый вопрос который возник при взгляде на ваш код был а почему «d:\data\» не запихнуто в какую-то константу.
+++
Ну и у меня например первый вопрос который возник при взгляде на ваш код был а почему «d:\data\» не запихнуто в какую-то константу.Опять же, хороший подовод поговорить. Если человек спросит про что-то подобное, это плюс. Если вместо константы предложит получать значение из конфигурационного файла, еще лучше.
На сколько я помню, FileStream есть и в node.js и в java, я думал
Только вот с «using» там вроде бы всё не так радужно.
Опять же, хороший подовод поговорить.
Но не «третий момент»? :)
Только вот с «using» там вроде бы всё не так радужно.В самом коде его нету, если кому-то хочется сказать что «Представьте себе, что вы компилятор» по поводу «using», то как бы ожидается что он хотя бы погуглил что это за зверь, ну и не использование «using» это вполне нормально и как раз повод для разговора.
Но не «третий момент»? :)Может и третий. Там было «если у него общие представления о хорошести кода совпадут с вашими» так что постеснялся по мелочам придираться.
А что это за вебсервер вообще? Как и где он используется? PeterPP явно считает, что его одна строчка кода «плохая», но конкретно в ней одной проблемы минимальны — плохое именование, да обращение к файловой системе где попало — заметим, что от одного только создания FileStream на чтение никому особо не поплохеет. А где режим, кстати? Или мне опять нужно поработать компилятором?
Anyway, автор строчки явно считает, что выход за пределы /data — это нехорошо. Но с чего он это решил? Из этой строчки кода оно вообще никак не следует. И даже из знания о том, что это вебсервер — тоже не следует. Я назову по крайней мере
И вот обсуждений уже вагон, а интересными они всё так же не становятся. Так, игра в «догадайся, что я имел в виду» с интервьюером.
Anyway, автор строчки явно считает, что выход за пределы /data — это нехорошо. Но с чего он это решил? Из этой строчки кода оно вообще никак не следует.
Ну, видимо, предполагается, что в filename придется ../../../something и приплыли
И вот обсуждений уже вагон, а интересными они всё так же не становятся. Так, игра в «догадайся, что я имел в виду» с интервьюером.
+1
Ну, видимо, предполагается, что в filename придется ../../../something и приплыли
Угу, это наиболее вероятное объяснение. Но мало ли, может там следующей строчкой проверяется fs.Name на «правильную» директорию. Или не проверяется, а просто с fs ничего интересного не происходит, и тогда вообще плевать, что что-то там куда-то вышло.
А еще бывают куда более интересные причины, когда это «норм»:
1) Заведомо уязвимый вебсервер. И не обязательно по банальным причинам типа «это внутренний проект, нам некогда было заморачиваться», иногда причины могут быть и интересными — например, ханипот.
2) Вебсервер не имеет файловых прав за пределами D:/data. И пусть хоть обвзламывают.
3) За пределами D:/data ничего нет и не будет. Банально, но работает :-)
4) D:/data — это симлинк на D:/
¯\_(ツ)_/¯
Наоборот, это ваш ответ подтверждает правильность методики интервьюирования.
Вот только мы не на интервью. Но даже это не мешает вам самоутверждаться, что очень характерно.
И что дважды характерно, это не мешает вам чувствовать себя обиженным, и реагировать через
начинаете поливать собеседника известной субстанцией
¯\_(ツ)_/¯
Я вообще считаю очень любопытным, когда человек одновременно крайне невежлив и обижается. Вот то самое passive aggressive как оно есть, прям хрестоматийно. Сначала послать лесом, а потом обидеться на импликацию и вернуться дополнительно подтверждать её справедливость.
Меж тем, всё, о чем я писал — это о том, что когда человек спорит со мной о том, что не всякие проверки на «пробелы в знаниях» это самоутверждение, а спустя пару постов высказывает «вы ничегошеньки не знаете, адьёс» — это, ну, настолько смешная иллюстрация моего тезиса, что на самом деле даже и не смешно.
На всякий случай, я тут сразу скажу как на самом деле надо правильно делать в таких случаях: отвечать «ошибка — вот в том-то и том-то». Это — правильный и вежливый вариант, пригодный для собеседования. Любые формы переходов на личности, в том числе и «ваши знания отстой, до свиданья» — не правильные, и на собеседовании применять их не стоит.
2. directory traversal это базовая концепция и к C# не имеет отношения. Судя по вашему ответу вы не имеете понятия что это вообще такое.
Извините великодушно, последний раз имел дело с потрохами вебсервера в 2008 году. Думал, с тех пор стало как-то поудобнее, чем проверять руками пути на выход из корня вебсервера, но видимо нет, по крайней мере в C#.
3. Поверх этого, вы начинаете рассуждать о проблеме с именованием параметра filename, т.е. вы серьёзно обсуждаете использование анти-паттерна «security through obscurity», что добавляет ещё один штришок к общей картине.
Если б вы не так сильно преследовали цель уязвить меня, и если у вас действительно есть нормальный опыт — я думаю, вы бы без труда припомнили бы свои варианты ситуации, когда плохо запроектированные и ужасно именованные публичные API живут годами, потому что менять их очень дорого.
Если у вас таких ситуаций не бывало — ну, отлично. Еще будут.
В целом я бы порекомендовал вашему работодателю отправить вас на курсы повышения квалификации.
В целом я бы рекомендовал вам не рекомендовать. У вас это получается довольно комично.
Извините великодушно, последний раз имел дело с потрохами вебсервера в 2008 году.Вы хоть погуглите для смеха что это такое, фронтенд девелопер должен относиться к безопасности своего приложения как к приоритету.
вы бы без труда припомнили бы свои варианты ситуации, когда плохо запроектированные и ужасно именованные публичные API живут годами, потому что менять их очень дорого.Опять же, вы не понимаете про что идёт разговор. Имя параметра filename это не проблема, проблема в том, что вы считаете что это является проблемой.
В чём заключается моё самоутверждение?
В том, что вы уже который по счету пост не можете съехать с ad hominem, хотя вроде б все тут взрослые люди.
Вы хоть погуглите для смеха что это такое
Я знаю, что это такое. Но чтоб начать соотносить это всё с вашей строчкой кода, мне потребовалось повспоминать обратно всё, что я знал про вебсерверы, но забыл за ненадобностью. Контекст нужный взять, другими словами. То, о чём я вам писал несколькими постами выше.
И, кстати, в вашей одной строчке никакой дыры безопасности нет. Она может появиться (или не появиться) только в последующих.
фронтенд девелопер должен относиться к безопасности своего приложения как к приоритету
У фронтенд-девелопера свои проблемы с безопасностью, мало относящиеся к файловым системам, но не менее критичные.
Опять же, вы не понимаете про что идёт разговор. Имя параметра filename это не проблема, проблема в том, что вы считаете что это является проблемой.
Имя параметра filename, если там может находиться не filename — это проблема. Более того, это одна из двух сложных проблем программирования. Если вы не считаете плохие имена проблемой — у вас проблема.
А смысл, если бекенду всё равно надо это всё валидировать?Я не писал что надо валидировать. Вы говорите что нету смысла фронтенд девелоперу знать потенциальные security vulnerabilities? т.е. работая с фронтендом и встретив ссылки типа /account/openfile?filename=../../mydata.txt он должен сказать, ну и ок, я же фронтенд, это не моё. Мне главное из джаваскритпа XSS не замутить.
К вашему серверу могут обращаться далеко не только из написанного фронтендером, э, фронтенда.Именно, это как раз показывает что человек понимает что вообще потенциально может происходить и получает плюсик при разговоре. Проблема с тем что если кто-то изучил основные вопросы для прохождения интервью, но не имеет реального знания в написаннии систем, хоть какого-то уровня важности, это всё вскрывается обсуждением реального, плохого кода.
Ну и теоретизирование в том что такой подход не работает, разбивается о нашу практику его использования (не претендую на истинную-истину).
Никто не жаловался, а что-то я не пойму в чём контекст, наоборот говорили что гораздо меньше стресса от чтения кода, чем от написания или алгоритмирования. К тому же спросить и прояснить непонятные детали, очень легко. Показывает общий уровень воспреимчивости к нечётким требованиям.
А зачем ему про них знать?Ну чтобы например поднять проблему.
Его фронтенд-действий для защиты от того, что актуально для бекенда, заведомо будет недостаточно.Ну например для того чтобы если мы отвалидировали всё правильно на фронтенде, то на сервере дублирующая валидация должна быть чистой. Если она сработала, то это red flag и кто-то нас пытается нагибать.
Вопрос лишь в том, насколько глубоко надо копать.Копать нужно до глубины использования технологий на проекте. Если глубже, то это начинаются красно-чёрные алгоритмы Нагла или треугольные люки в пределе к x.
Ну например для того чтобы если мы отвалидировали всё правильно на фронтенде, то на сервере дублирующая валидация должна быть чистой. Если она сработала, то это red flag и кто-то нас пытается нагибать.
насчет нагибать — это безосновательное утверждение от слова совсем. Может просто быть баг. Зато двойная валидация — это отличный способ удорожить разработку и удорожить поддержку
насчет нагибать — это безосновательное утверждение от слова совсем.Получается что баг нашли, польза на лицо.
Зато двойная валидация — это отличный способ удорожить разработку и удорожить поддержкуВо-первых в 90% случаев двойная валидация идёт бесплатно и автоматом. Во-вторых надо как-то пользователю показывать что, что-то не так как должно быть, если гонять данные на сервер и обратно для каждого валидирования, пользователи начнут кричать как-же web 2.0, хочу как у больших пацанов.
Получается что баг нашли, польза на лицо.
Так его бы и без валидация во фронтенде точно так же бы нашли.
Во-первых в 90% случаев двойная валидация идёт бесплатно и автоматом.
Это каким конкретно образом она вдруг так идёт? Мне аж интересно стало.
Во-вторых надо как-то пользователю показывать что, что-то не так как должно быть, если гонять данные на сервер и обратно для каждого валидирования, пользователи начнут кричать как-же web 2.0, хочу как у больших пацанов.
Ну на мой взгляд вот именно такие вещи достаточно валидировать только на сервере. Потому что случается очень редко и обычно подразумевает под собой либо наличие какого-то злого умысла со стороны посылающего реквест, либо действительно какой-то баг.
Так его бы и без валидация во фронтенде точно так же бы нашли.Как бы вы нашли, если у вас логи валидации были бы забиты валидными срабатываниями пользователей которые просто неправильные данные ввели. Как вы их отфильтруете.
Это каким конкретно образом она вдруг так идёт?
Очень просто идёт. Большинство валидаций, это что параметр необходим, что это число или дата или что максимальная длина не больше той что база принимает или что долен быть валидный емайл и т.п.
Для aps.mvc что-то типа
В .net forms это достигается тем что валидатор на форме автоматом делает это за вас.
Для валидаций в ангуляре, можно автоматически сгенирировать правила валидирования базируясь на определнии модели с сервера.
Валидация сервер сайд — это скорее всего проверка с точки зрения бизнес логики.
Как бы вы нашли, если у вас логи валидации были бы забиты валидными срабатываниями пользователей которые просто неправильные данные ввели. Как вы их отфильтруете.
Что значит «неправильные данные ввели» в контексте directory traversal? Ну то есть если формат строки неправильный, то это конечно во фронтенде отвалидировать можно. А если вам надо знать есть ли такой файл и есть ли у пользователя права на него, то как вы это собираетесь во фронтенде валидировать?
Очень просто идёт. Большинство валидаций, это что параметр необходим, что это число или дата или что максимальная длина не больше той что база принимает или что долен быть валидный емайл и т.п.
Ну во первых если у вас во фронтенде только такие валидации, то как они вам помогут против directory traversal? Во вторых даже такие валидации далеко не везде «идут бесплатно».
Вижу в куске достаточно проблем, начиная от хардкода и NRE и до утечек с юзингом, но что такое directory traversal?
Попытки пролезть повыше нет смысла фильтровать через поиск «пробелов в знаниях», иначе вы наймете профессионального проходителя собеседований, и — ну, удачи с ним работать.
Святая правда.
Но её не замечают, потому что — сюрприз, сюрприз! — большинство из тех, кто таки уже работает они И ЕСТЬ ПРОФЕССИОНАЛЬНЫЕ ПРОХОДИТЕЛИ СОБЕСЕДОВАНИЙ.
Любая социальная группа стремится к самовоспроизводству.
Некоторые полагают, что самовоспроизводство непрофессионалов вызовет удар Невидимой Руки Рыночка, который тут же порешает всех, кто не умеет по-настоящему работать.
Но на практике мы постоянно сталкиваемся с нерыночными ситуациями типа «хайпа», который позволяет создать стартап из трёх индусов и одного недоучившегося студента.
Поэтому никакой рыночек тут не поможет. Мы уже живём не просто в ситуации, когда одни профессиональные проходители собеседований нанимают других профессиональных проходителей собеседований. Так выглядел вчерашний день.
Сейчас уже обе стороны искренне считают, что:
1) То, что они делают перед трудоустройством — настоящее собеседование.
2) А то, что они делают после — настоящая работа.
По факту мы видим на этапе собеседований дебильные проверки на алгоритмы, а после собеседований — дебильный эджайл.
Следит ли за новыми технологиями? (у меня вот новый проект сразу на Blazor пилим)
Есть ли пет-проекты?
Какие еще языки пробовал?
Смотрит ли конференции/читает ли статьи?
В какую область хотел бы развиваться?
Примерно в эту степь. Естественно, самому надо быть тоже в курсе)
Есть ли пет-проекты?
Правильно понимаю, что возрастной джун в таком случае будет no go? У него ведь, скорее всего, не pet project, а семья и серьезные финансовые обязательства.
Те, кто приходят только за деньгами, не испытывая никаких эмоций к сабжу, даже если они по способностям тянут — сильно долго не задерживаются, как правило. Точно не на десятки лет.
IT уже не специальность для людей увлеченных, а ремесло. Ремеслом можно заниматься всю свою жизнь.
потому что тут хорошие деньги дают, а они мне нужны» — то это повод серьезно задуматься, нужен ли он вам
А что, ИТ — это корова священная, к которой надо какие-то нежные чувства иметь чтобы успешно работать и зарплату получать? От адвокатов почему-то не ожидается что они будут любить читать постановления пленума ВС, клиентов, закрытых по 228й или 105й, блаженно улыбаться, слушая оглашение приговора ил касатку писать особику.
А в IT это гораздо важнее по той причине, что стэк меняется на 100% за 5 лет. Если у человека нет любви к делу, то он не будет развиваться и он сам и компания застрянет глубоко в прошлом. По сути, любознательный джун вырастет до синьора достаточно быстро, а вот унылый мидл так и останется унылым мидлом.
А для учебников, кстати, нет типа errata?
Я Вас умолять, какие там errata для школьных учебников в РФ.
Ого.
У меня, как у ваннаби «возрастного джуна» сразу два вопроса
1) А что, много компаний нанимает человека с перспективой продержать его у себя десятки лет?
2) Много ли «десятков лет» работы остаётся у 40летнего, например?
Ну и традиционное — а вы, значит, работали бы, если бы вам не платили?
1) А что, много компаний нанимает человека с перспективой продержать его у себя десятки лет?
2) Много ли «десятков лет» работы остаётся у 40летнего, например?
1) Довольно много компаний желает нанять человека на достаточно длительный период. Не у всех по факту это получается, по очень многим причинам, но контор, нанимающих вас «от забора и как получится» — гораздо больше, чем контор, говорящих что-то в духе «нужен разработчик на проект, проект продлится максимум год».
2) Нет. И?
Ну и традиционное — а вы, значит, работали бы, если бы вам не платили?
Нет.
Этот вопрос мне подсказывает, что мой прошлый комментарий вы не очень сильно читали.
Детские сады, школы — когда подрастут :)
Отпуск по уходу за детьми не просто так дают, это действительно очень сложная вещь. Именно воспитание, а не «чем бы дитя не тешилось»
Было бы желание, а возможность найдется :) у нас в России практика с няньками не очень распространена, могут засмеять или дружить перестать. Кто-то просто боится, что нянька покалечит — мало кто хочет платить норм денег, а ведь при подходе найма няни, чтобы ходить ещё на работы, вы должны ей в прямом смысле платить зарплату. Люди не хотят столько денег тратить.
Опять же в России, ТК 256 (ироничный номер для сего ресурса) говорит, что отпуск даётся до достижения ребенком 3-х летнего возраста, и уволить не могут. Мне знакомые говорили, что есть особи, которые рожают с перерывом в 3 года, чтобы получать пособие и сидеть дома в декрете по 10 лет х) хотя не знаю, как это в реальности разруливается, может просто сплетни
Сам я ещё не в курсе, но знакомые говорят, что дети и их обучение — немалый такой пет-проект, весьма ресурсоёмкий и требовательный. Часто конфликтует с другими пет-проектами, особенно за время.
У меня трое детей, pet-проекты есть. Весьма тяжёлые, затратные по времени и абсолютно немонетизируемые. С другой стороны, из кучи моих близких знакомых программистов pet-проекты есть только у меня, а они специалисты высочайшего класса, работающие в компаниях от JB до Гугла.
Всё зависит от приоритетов, желаний, но никоим образом не является каким-то показателем профессионализма.
Ведущий разработчик, также известный как синьор
Я бы не торопился ставить ровно между «Ведущим» и «Сеньором», есть еще и «главный программист». Но у нас в России понятие «Сеньор» большинством вовсе неверно воспринимается, из за того что берем название зарубежное и натягиваем на наш трудовой кодекс, а чаще на собственное представление. Точнее благодаря тому что есть иное слово как «Сеньор» — дает повод придумывать свой стандарт. Для одних «Сеньор» это гуру и наставник человек понимающий внутренности любого API и организатор, а для других уровень зазубривания команд языка высокого уровня. И получается так что русский «Сеньор» равен зарубежному «Мидлу».
Да не, ничем тут РФ не выделяется. За бугром есть такие же самые сеньоры-помидоры.Ну это скорее условности, которые вносят путаницу.
И получается так что русский «Сеньор» равен зарубежному «Мидлу».
Я сказал, что мой товарищ говорит прямо противоположное. Там человек называется «Сеньор», но он примерно равен тому, что у нас называется «Миддл».
За 7 с чем то лет регулярных собеседований со стороны нанимателя родился следующий алгоритм:
Слушаем про опыт кандидата, например пару последних или самых интересных проектов, задаём вопросы пытаясь понять, что люди делали и в чем сложность и какова роль кандидата.
Гоняем кандидата по основам технологии (в нашем случае java) от простого к сложному, понимая глубину знаний.
Спрашиваем "А как бы ты сделал ..." — какое-нибудь решение из нашей практики.
Занимает обычно до 1.5 часа. Бывает, что с первых фраз видно хорошего человека, или наоборот, только к концу человек раскрывается.
Ведь в процессе рассказа как бы он сделал будет понятна и глубина знаний и опыт.
Наша специфика такова, что разработчикам необходимо писать много кода, в том числе и старшим. Для этого они должны хорошо ориентироваться в технологиях/фреймворках/библиотеках, которые мы используем.
Так вот, если сразу начинать с пункта 3, мы не сможем понять — человек сам может писать код, или он может только рассказывать "как космические корабли бороздят просторы Вселенной". К сожалению, второй вариант встречается довольно часто. Как вы понимаете, рассказать как устроен, например, FaceBook и разработать аналогичное решение — "две большие разницы" (С).
Таким образом получается, что до пункта 3 еще дойти надо. Если человек не знает, как в java коллекциями пользоваться — его мнение по архитектуре уже не такое ценное, просто потому, что понятно, что он руками вообще ничего не делал (потому как вопросы по технологии, мягко говоря, не сложные).
На вопрос зачем знать все это наизусть ответ был — не зная этого, вы не понимаете суть джавы. При этом сам спрашивающий сверял ответы с листочком.
Тут я просто сказал большое спасибо, встал и вышел.
Лично я вообще не вижу смысла спрашивать на собеседовании именно детали API.
Но вот например, чем Set отличается от List, вы наверняка бы ответили.
1. Человек решает задачу и мы обсуждаем это решение.
2. Человек сообщает, что быстро не может решить задачу, и мы принимаем решение на основе пунктов 1 и 2. То есть даже в такой ситуации сохраняется шанс не пропустить хорошего человека.
Рынок: запихивает соискателя кодить в опенспейс с колл-центром после многоступенчатого собеседования с гороскопами и неоплачиваемыми тестовыми заданиями длиной с неделю с эйчаром, техдиром, службой безопасности, секретарём гендира, рыбками секретаря гендира, самим гендиром.
если не научусь заново сортировку пузырьком на бумажке делать, то увы, до того самого адекватного менеджера, который сможет оценить мой опыт и уникальность я просто не доберусь — там Пелевенские «три кольца оцепления с пулемётами».
ну и опять же я зашёл на пару европейских компаний, то же Zalando, например — аналогично яндексу предлагает порешать задачки на время и возвращает результат без объяснения какие именно тесты сломались.
> не стал пробовать даже — понял, что не вывезу их задачки
Там не на все позиции сложные задачки, далеко не факт что вас будут спрашивать что-то про деревья, графы и сортировки — это вполне может быть что-то уровня «пробежаться по массиву и что-то просуммировать/разбить на группы», т.е. entry level алгоритмы, встречающиеся в повседневной работе.
Другое дело, что решить даже их за 10-20 минут у доски это очень стрессово и там можно забыть даже как цикл писать, несмотря на большой опыт, не говоря уже про какие-то нетривиальные моменты.
Это решается тренировкой, и если потратить месяц-другой на подготовку (порешать где-нибудь такие задачки типовые, в инете полно сайтов-подборок таких задач), то пройдёте даже самые сложные «секции». Если особо не готовиться и идти «на шару» (чисто скилл проверить), то конечно возможны лютые фейспалмы — и у меня были. Но так как интервью многоэтапное и с разными интервьюерами, то итоговая «взвешенная сумма» может всё равно оказаться в вашу пользу, даже если где-то в отдельных моментах вы затупите.
Как я понял, не обязательно решать всё идеально — достаточно быть лучше других кандидатов. А они тоже тупят адово, идеальных не бывает.
Деревья, хэши, листы. Все с++ структуры данных описал, да и сейчас описать могу, В принципе стандарт до 17ой версии я очень хорошо знаю.
Но вот когда дошло до реализации задачек, тут, если честно, все задачки были люто замудренные.
Такое ощущение, что им нужны олимпиадники-выпускники, которые в реальных проектах не работали, библиотек не знаю, ни буст, ни qt, ни stl, зато могут выдать реализацию алгоритма в пару секунд или сгенерировать грязную реализацию почти мгновенно.
Зачем тогда меня вообще спрашивали по STL, про шаблонную мета-магию в С++, и всем базовым стрктурам данных, если им нужны те, кто эти алгоритмы будет писать с нуля?
После теории через пару дней было практическое интервью. HR обещал мне, что они будут с интервалом в сутки или пару дней. Но ВНЕЗАПНО! в последний день, они решили провести три интерьвю подряд. А я дебил согласился.
— Первый интервьювер, опоздал на пол часа, был какой то сонный и словно на от-сь дал задание и отключился от микрофона: Найти все подстроки и во всех подстроках сделать реверс слов, и что-то еще надо было там сделать, что бы это было в минимум прогонов и сложность была не квадратичной. Без использования stl и библиотек. Т.е. чистый Си по факту. (я итерировал указателями, но пока пришел к решению, пока отладил указатели, ибо с сырыми указателями ногу прострелить, я напомню, труда не составляет, потерял много времени. Вообще то не все люди могут за 15 минут выдать решение реализации, надо подумать, обмозговать, прогнать идею в голове и только потом решать)
с stl и шаблонами, я бы это решил быстро, несколько строк. А без, мне нужно было подумать, в итоге когда ее закончил, мне сказали «для второго задания у нас уже времени не осталось.»
— Второй интерьвювер, так же подзадержался, был какой то уставший. Там была очень мутная-мутная задача, я в начале в условие часа пол вникал, к коду даже не притрагивал, и если честно, за год забыл условие. Я ее решил очень не оптимально и убил все время.
— Третий интервьювер. В начале мне сказали, что «она» опаздывает на час. А потом через пол часа мне позвонила девушка, по звукам было, словно она в метро и говорит такая «Извините, по результатам двум последним интервью, мы решили, что вы нам не подходите».
Ну и у меня сложилось впечатление, что им нужны дятлы, которые быстро штампуют код.
Так что впечатление после их — удручающие, тебя за говно держат, опаздывают и, я бы сказал, саботируют.
Зато, за счет этого ушел в гейм дев, освоил кучу технологий классных и по факту сам на себя работаю, а не сижу в душном офисе со смузи.
Это решается тренировкой, и если потратить месяц-другой на подготовку
Вот такие вот вещи у меня сразу отбивают все желание идти на собеседование
На самом деле это довольно интересно и развивает (в плане кругозора), открываются новые грани восприятия :) Не могу сказать что это действительно как-то помогает именно в рутинной повседневной работе (где куда важнее знать API чего-либо или как конфигурить что-то) — но мне кажется что такой опыт может зарешать в 1% случаев когда приходится таки сделать что-то нетривиальное.
Я вот никогда не задрачивал именно алгоритмы и теорию (Кнут et al.), но я постоянно в жизни делал или пытался делать какие-то собственные велосипеды (фреймворки, библиотеки, DSL, интерпретаторы, компиляторы), и думаю именно поэтому задачки Яндекса мне как-то не показались прямо сверхсложными и я без подготовки с большинством из них справился. Думаю, поэтому это работает и в обратную сторону — если целенаправленно «задрочить» алгоритмы, то потом легко будет решать нетривиальные задачи.
Дело в том что «трюки» и «подходы» встречающиеся в решениях таких «олимпиадных» задачек — они на самом деле довольно шаблонные, и поэтому прорешав какое-то их количество (+ изучив чужие оптимальные решения), мозг легко выделяет нужные абстракции и формирует в голове «библиотеку» из типовых подходов, на уровне спинномозговых рефлексов / интуиции.
Конечно, чтобы на это время тратить, нужно либо очень хотеть именно в большую компанию попасть (напр. что-то из FAANG), либо искренне интересоваться тем, как «под капотом» устроены всякие штуки встречающиеся в computer science...
При этом, чтобы просто иметь неплохую зарплату в IT, успешно при этом решая повседневные бизнес-задачи, это всё не нужно — есть полно компаний, где на интервью не будут мучить никакими задачками. Какой-нибудь неизвестный никому стартап, которому нужно нанять людей ещё «вчера» — часто просто не может себе позволить жесткий отбор кандидатов.
А почему в крупных компаниях отбор именно такой, про это уже много говорилось, но всё же, перечислю причины (как мне это видится):
Они могут себе это позволить — желающих слишком много, отбор можно (даже нужно) сделать максимально жестким.
У крупных компаний часто «всё свое», поэтому знания специфичных стеков и фреймворков «на входе» не особо важны, важнее некий raw base skill. Тут идея в том, что если человек разобрался в алгоритмах, то разберется и с любой другой фигней. А вот обратное не всегда верно, наверное.
Наблюдая вживую за процессом решения задачи, можно быстро прикинуть, знает ли человек базовые понятия и примитивы языка, как он в целом мыслит, знает ли на практике (а не в теории) элементарные вещи. А так же как он коммуницирует. Поэтому на интервью полезно «мыслить вслух» и не стесняться взаимодействовать с интервьюером.
Куда делись все эти оптимизаторы?
Подозреваю, что они просто занимаются не фронтендом, а какой-то внутренней инфраструктурой, и их работа незаметна (вероятно, как раз потому, что они делают её хорошо)...
Правда есть другая проблема — это никоим образом не помогает в реальной работе. За год с небольшим всего один раз потребовалось придумать и закодировать действительно сложный алгоритм. 90% времени просто читаешь/пишешь в БД и шину.
Алгоритм выдумывается минут за 10, даже если совсем забыл что там и как. Просто из общих соображений.
Человек хотящий 250к вроде как должен уметь писать код. Написать 5 строк кода это правда так сложно?
Замороченные задачки аля Яндекс может и не стоит прашивать. Но пузырек это обычная быстрая проверка что человек не врет и на самом деле умеет писать код.
П.С. То есть в нормальной фирме это пожалуй не проблема и там наверное можно написать любой. Но в нормальных фирмах обычно про такое и не спрашивают :)
Я бы тоже выгнал от греха подальше. Он похоже совсем код писать не умеет и врет много.
Хотя что такое дерево знать должны все. Все основные индексы в БД так работают. Без этого знания можно такого в базе наворотить… Тормозить на пустом месте будет. И что самое печальное это обнаружится в проде и есть шанс что малой кровью оно будет неисправимо.
А если я БД не использую, можно не знать про дерево?
А что касается проблем с производительностью — перед продом всегда должно быть нагрузочное тестирование и тестирование производительности. Если вы не можете отловить проблемы там, то кто же вам тогда доктор?
Примерно помнить общие правила работы с индексами? Это уровень человека за 250к по вашему? Это на мидла-то с трудом тянет на мой вкус.
Нагрузочное тестирование. Ну-ну. Максимум обстрелять инстанс можно. Что там с базой непонятно. И как она себя поведет на ×10 данных тоже непонятно. Только верить разработчику и ревьюеру и остается.
Что то там с базой непонятно. И как она себя поведет на ×10 данных тоже непонятно.
То есть планы выполнения запросов никто не проверяет и метрики с БД по запросам тоже не собираются?
БД точно так же обстреливается, хоть SQL запросами, хоть вызовами хранимых процедур/функций. Да, для этого надо понимать что конкретно у вас за сервис и как у вас вообще запросы формируются, потому что без этого только и остается, что верить разработчику, а это рано или поздно приведёт к ошибкам.
Сделали. Обстреляли. Все в разумных пределах. Потом добавили какой-то функционал. Выросла база в несколько раз. И все стало плохо. После исследований стало понятно что мина была заложена в самом начале. Но на том функционале и на том размере все работало. Переделывать много.
А человек всего-то не до конца понимает как индексы в базе работают.
Однако, лично мое имхо, если допустим с 50 миллионами записей проблем нет, то все ОК. На объемах больше в любом случае нужен DBD.
А DBD — отдельная специальность, база данных в разы сложнее, чем любой программист думает.
Люблю такое. Чуть в сторону и должен прийти специальный человек и сделать. Начиная от базы и заканчивая нечеткими тикетами. А что разработчик делает? Непонятно. Переводить четкие тикеты уже декомпозированные донельзя в код и обезьяна сможет. Зато понятно откуда берутся люди не могущие в простейшие алгоритмы.
Только вот в реальной жизни такое не работает. Делается нечто. Оно внезапно взлетает и вот тебе нагрузка и куча данных. И если сразу было плохо сделано все уходит на переделку. Это для бизнеса дорого. И поэтому требования к деревьям и вот этому всему.
Да куда уж мне. Пока работодатель не оплатит сертификацию человек ничего не умеет. Как оплатит сразу все умеет.
Нет бумажки — таблички не делаешь. Делаешь тикет на человека с бумажкой и ждешь. Запросы-то можно писать? Или тоже тикет этого человека делать? Базу можно одним запросом с небольшим рпс завалить при желании. А с jpa такие запросы вообще легко делать стало.
И зачем вообще все эти собеседования придумали?
Профильный диплом — джун.
Сертификация простенькая — мидл.
Много красивых бумажек — сеньер.
И все.
Только вот в реальной жизни такое не работает. Делается нечто. Оно внезапно взлетает и вот тебе нагрузка и куча данных. И если сразу было плохо сделано все уходит на переделку. Это для бизнеса дорого. И поэтому требования к деревьям и вот этому всему.
Я, с вашего позволения эту вашу линию аргументов разовью немного:
Делается нечто. Оно еще не взлетело, но мы конечно же верим, что да. Будущие падения нас пугают до дрожи в коленках. Денег на ДБД у нас нет. Поэтому давайте мы на нашу обычную посредственную зарплату нарисуем вагон требований, наймем кого-то, кто сумел пройти в наш неадекватный фильтр — или того, кто просто натренировался в них проходить, или настоящего разработчика с офигенским опытом по части баз и с самооценкой ниже плинтуса. Какова вероятность нанять второго? Да к черту вероятности, наняли и ладно.
А работает это всё потому, что множество «нечт» так никогда и не взлетают, и проверки боем никогда и не проходят. А в таких условиях неважно, что там понаворотили супермегаспецы по деревьям на зарплате чуть ниже рынка — всё равно это никто не проверит.
я было подумал что он вообще уже не работает в олимпиадную сторону, но вот рискнул на одной из конфренций поучаствовать в конкурсе от яндекс-авто и ухитрился третье место занять (а там в-основном молодёжь была), но там не было жёстких временных рамок — что-то около 4 часов получалось на решение.
но при этом, решение олимпиадных задачек никогда не было моим коньком, я даже на физтех-то чудом поступил, завалив экзамены в бауманке :) я всё больше по дизайну уникальных решений, по решению сложных интеграционных задач, по универсальным фреймворкам, вот это всё…
Сортировку пузырьком невозможно «разучиться». Это надо быть каким-то узкоспециализированным самоучкой с такими пробелами.
В условиях цейтнота и нервной обстановки — запросто можно не вспомнить сразу.
Давно когда то сдавал deep сертификацию (дайвинг). И инструктор не нашел ничего лучшего чем предложить поделить в столбик два пятизначных числа (тест на азотный наркоз на 40м).
Да я потом минут 5..7 уже на боте вспоминал детали как это делается. Общий принцип то понятен — позиционное десятичное исчисление. А детали… Ни разу со школы не делил на бумажке.
Вот Вы вот так прям сразу поделите 82734 на 36269 столбиком за 2 минуты? Элементарная же задача для школьника. Получилось сразу вспомнить технику деления/записи?
Сортировка пузырьком — общий принцип понятен, но если лет XX это не вспоминал, то на алгоритм уйдет > 2 минут. Потому что вот прямо сейчас (специально не заглядывая в..) у меня сортировка пузырьком только мысль/воспоминания "что то там всплывает и это неэффективный алгоритм".
вот как раз несколько минут уйдет на то, что бы вытащить эти совершенно ненужные для работы детали.
Если вспомнить описание алгоритма (проход по массиву с обменом до тех пор пока обмена не случится), то на примитивную реализацию на python или java или c++ как раз не более 2х минут и уйдет. Чет там писать то.
Специально ща отвлекся и набросал засекая время (intelleJ IDEA java было открыто)
Но это если вспомнить за эти 2 минуты еще и формулировку пузырька..
А кто требует написать пузырек, тем более за 2 минуты? Это же выдумка, правда?
Сарказм? Судя по тому, что я слышал, иногда и требуют. Да еще на "бумажке" без IDE. Уж не знаю, что этим пытаются проверить? Стрессссоустойчивость или возможность писать срипты взлома под авианалетом что ли..
Редко востребованный навык, что бы мазохистки прокачивать этот навык.
Хотя приходилось на сотовом python скрипт править в окне простого SSH клиента. Тонкое извращение. Мне не понравилось.
Я сейчас разрабатываю игры на движке Godot Engine. В самом движке почти все пишется на внутреннем gdscript (по сути это тот же питон, но в место сборщика мусора — подсчет ссылок, реализуемые внутреигровым компилятором).
Но я делаю игры кросплатформенные. На андройд и ios. Так вот. Игра при экспорте либо генерирует xcode проект, под ios, который я отдаю заказчику и тестируют, либо apk файл, если экспортирую под андройд.
Мне пришлось дописывать функционал в IAP под ios, на Objective-C, в виде отдельного модуля и компилировать библиотеку, а после линковать ее с xcode проектом.
Тоже самое делать на андройд.
А недавно я начал писать нативную, кросплатформенную либу на С++ для этого движка, что бы работать с GameSparksSDK.
И вот во всех случаях уменее писать грамотно в блокноте — очень полезно, ибо настраивать 2-3 среды на каждый модуль, который состоит максимум из 100 строк — такое себе удовольствие.
Да и еще godot и его нативные либы юзают Scons. А модуль под android оторваны от проекта и grandle файлы представляют из себя набор тегов, для генерации уже при экспорте, из за чего, в android studio этот модуль не загонишь, т.к. он не видит манифест файла, т.к. тот сгенерируется только после экспорта внутри самого APK
Эээ. VS Studio это IDE или не IDE. Код подсвечивать помогает… да. А сборка по кнопке и пр. — это опционально.
С++, например, все же в нем гораздо удобнее редактировать (а особенно автоформатирование нравится. Ускорят работу) чем блокноте/Far/nano.
Под IDE я все ж предполагаю не "IDE запускает сборку по кнопке". Для меня это опционально..
What is the difference between Visual Studio Code and Visual Studio IDE?
Visual Studio Code is a streamlined code editor with support for development operations like debugging, task running, and version control. It aims to provide just the tools a developer needs for a quick code-build-debug cycle and leaves more complex workflows to fuller featured IDEs, such as Visual Studio IDE
Ну с секундомером не стоят…
но по рассказу это выглядело так:
вот вам задачка. вот доска и маркер. задачка простейшая простейшая. решайте..
… пристально смотрят… человек пытается нервно вспомнить… что то сделать…
прошло 30 сек… 1 минута…
так. ну давайте следующую примитивную задачку если у вас не получается.
По крайней мере так выглядело со стороны соискателя.
Задачку точно не помню. то же что то примитивное типа пузырька.
Но у меня то же как то была ситуация. вот комп. вот IO тест (с интерфейсовм 90-х годов).
В IQ тесте какие то анаграммы (Интернета нет). Что такое анаграммы…
сидел тупил — пытался вспомнить/придумать что это слово означает "анаграммы..". послал всех и ушел.
прошел потом on-line IQ тест, разобравшись в принципах этих идиотских тестов и послал результат (ссылку на) с значением 142.
Идиотская вещь этот тест. На натаскивани на них.
Хорошо что и не попал в эту контору по распилу гос бабла. Прожила не долго
Уж не знаю, что этим пытаются проверить? Стрессссоустойчивость или возможность писать срипты взлома под авианалетом что ли..Может им это собеседование покоя не давало?
Будем называть операцией CAS (compare and swap) элементарную операцию сортировки пузырьком: два соседних элемента сравниваются, и, если первый элемент больше второго, элементы меняются местами.
Лемма: пусть дан массив элементов длины N, для которых задан полный порядок. Тогда для любого i такого, что 1 <= i < N, после i последовательных операций CAS на i первых парах соседних элементов наибольшего элемента массива нет среди первых i элементов.
Доказательство по индукции:
База: до CAS наибольший элемент либо является первым, либо не является. Если справедливо второе, то CAS оставит наибольший элемент на месте, иначе CAS поставит этот элемент на второе место. В любом случае первым этот элемент уже не будет.
Шаг индукции: пусть совершено k операций CAS. Тогда по предположению индукции наибольший элемент не может быть среди первых k элементов. Если наибольший элемент стоит на k + 1-том месте, то после CAS он будет на месте k + 2, в противном случае он не поменяет своего положения. В любом случае наибольший элемент уже не будет на k + 1 месте.
Используя эту лемму, можно, как совершенно справедливо заметил WASD1, показать, что каждая итерация алгоритма сортировки пузырьком добавляет как минимум один элемент в число отсортированных, а потому после (длина массива — 1) итераций массив гарантированно будет отсортирован.
Яндекс. Март 2017. Просили написать пузырек, я честно сказал, что не помню алгоритма ибо нафиг его и в реальности я лучше merge sort заиспользую.
если мой убитый кровавым тырпрайзом мозг не в состоянии решить простейшие задачки
Если мозг не способен решить даже простейшие задачки, я бы не ждал от такого мозга возможности решать сложные. Нет повода.
по итогам собеседования в яндекс мне вообще намекнули, что я и на джуна не тяну,
В яндексе в разных подразделениях довольно сильно разные способы собеседования, насколько я понял. В целом они совсем нетрудны технически, сколько трудны продолжительностью. Отсидеть три-четыре секции когда интервьюеры меняются, а ты один и тот же — непросто. Хотя и не запредельно сложно.
если не научусь заново сортировку пузырьком
Не понимаю. Вот честно не понимаю. Сортировка пузырьком — это три строчки на большинстве современных языков. Словесное описание не длиннее. Вы не в состоянии придумать за разумное время реализацию трёхстрочного алгоритма? Не выучить, зачем это учить — что за глупость? Написать реализацию по готовому алгоритму (если не помните про что там "пузырёк" можно ведь спросить — или это тоже за пределами компетенции человека с "10+ опыта жавы"? Вот, правда, в чём сложность? Я понимаю, что "пузырёк" — утрированый пример, но в реальности задачки ведь такого же уровня сложности. И, нет, это не про знание алгоритмов. Это про problem solving — или вы правда считаете, что это необязательное качество софтваре инженера и достаточно знать десяток ынтерпрайз базвордз? Ну, тогда это и правда уровень джуна — научить базвордам можно даже эйчара (шютка).
увы, до того самого адекватного менеджера, который сможет оценить мой опыт и уникальность
"специалист", которому нужно как-то специально учить способ реализации трёхстрочного алгоритма действительно "уникален".
Ну не мешок, обычная зп.
И да, не знал. Сами нашли, сами в скайп позвонили, всё норм было, а потом вот эти сессии с кодом на бумажке были неожиданны совсем.
Это их право спрашивать всякую муть, они просто лишают себя нормальных разработчиков. При том, что я знаю большинство алгоритмов, которые они спрашивают, почему я должен доказывать со своими 14 годами опыта, что я действительно умею обходить дерево не рекурсией?
У меня в резюме все написано. И там не ООО «Рога и Копыта», а вполне себе крупные и известные фирмы, и работал я там не по 3 месяца.
Проблема в том, что в ИТ много закомплексованных людей, которые используют собеседования так или иначе, как способ повышения ЧСВ:
1) Просто сказать чувакам, что они ничего не знают, показав свое превосходство
2) Показать этим же чувакам, насколько он крутой, чтобы им восхищались
3) Показать директору на примере чуваков, которые ничего не знают, насколько он ценный кадр и его надо держать
И еще куча кейсов.
Потому что если задача стоит найти нормальных людей, то эту задачу можно решать совсем иными способами.
А вот взять несколько айтишников и попросить их заняться собеседованием новых сотрудников это много где считается нормой.
Это их право спрашивать всякую муть, они просто лишают себя нормальных разработчиков
Ну да, также их право отсеивать тех, кто пришел на шару на собеседование. Также это и ваше право отказывать таким конторам по причине что вам не понравились технические вопросы на собеседовании. Это же обоюдно. И понятие «нормальный» так себе — вы себя оцениваете «нормальным», а компания — нет.
У меня в резюме все написано. И там не ООО «Рога и Копыта», а вполне себе крупные и известные фирмы, и работал я там не по 3 месяца.
Есть пример: в резюме написано работа с оборудованием Cisco в крупном операторе, на собеседовании спрашиваешь, как там настраивать, собеседуемый не знает, уточняешь, а что ты с Ciscoй делал, в ответ — фуры разгружал. И тоже ведь не придерешься)
И было ещё другое: люди как-будто примеривались, свой это человек или не свой. Можно ли на него вообще положиться, будет ли он работать или просто сидеть пинать, что он нового привнесёт, какие у него мотивации. Вот это, кмк, называется собеседованием сеньора.
А формальные задачи. Ну, вот завалил я одну задачу. Не самая сложная, но что-то стресс накатил, ноутбук не свой, время тикает, в голове непонятная для самого себя пустота. Я такой код и гораздо сложнее пишу тысячи строк на своих работах, но на время при собеседовании не смог. Ну бывает. Люди потратили кучу времени на предварительные ласки по скайпу, потом на очном, а в итоге — пшик и для меня, и для них. Зачем это, почему, насколько эффективно?..
Это по сути единственная цель, потому что я лично видел пару раз на своем веку, как адекватные в общении люди слетали с катушек через полгода.
Аналогичным образом ичары тоже не заметят подвохов в человеке, у которого всё норм. Ичары ведь не военно-врачебная комиссия для отбора космонавтов. Бывают случаи когда у человека просто что-то происходит в жизни — кризис какой-то жизненный или личностный — и он «слетает». Если всё было хорошо, а потоМ ХРЕНАКС то может быть лучше попытаться помочь?
Однако ичар на собеседовании может помочь сформировать ещё одно мнение со стороны, т.к. может заметить какие-то особенности поведения-реакций кандидата, которые пропустил интервьювер.
Как сеньор с 30+ годами опыта работы, соглашусь почти со всем в статье.
Но вы серьезно думаете, что разработчик с десятилетним стажем, работавший хотя бы по 1.5 года на каждом месте, успешно в течение десяти лет обманывал всех, что он не умеет писать код?Не обязательно обманывал. Мог заниматься какой-то ерундой все эти 10 лет. Если у кого-то опыт в 10 лет, это не значит, что у него высокий уровень. Может он достиг какого-то приемлемого для своей прошлой работы уровня, но это не значит, что этот уровень устроит мою команду. Причем крутость работодателя тоже ни о чем не говорит. Даже в хваленой корпорации добра таких личностей более чем хватает. И даже на уровнях выше сеньора я таких людей там видел.
Для чего нужны все эти алгоритмы обхода деревьев на собеседовании? Он что, каждый день будет писать эти деревья или алгоритмы сортировки в прод?Цель алгоритмического собеседования — вовсе не проверить, насколько вы хорошо знаете алгоритмы обхода деревьев. Алгоритм выступает лишь в роли контекста. Цель собеседования — получить представление об общем уровне вашей «соображалки», оценить коммуникативные навыки, стиль мышления, и заодно проверить навыки перевода идей из головы в код.
Но конечно сложно поспорить, что часто они действительно вырождаются в проверку, умеете ли вы писать обходы деревьев. Тут уж зависит все от собеседователя. Поэтому я понимаю общее недовольство алгоритмическими собеседованиями, но я в корне не согласен с критикой типа «я ж не буду писать сортировку каждый день, зачем вы меня ее спрашиваете». Я поддерживаю критику вроде «зачем вы меня заставляете решать задачки чтобы тупо посмотреть, решил я ее или нет, и докапываетесь до неважных деталей, вместо того, чтобы оценивать мои общие мыслительные способности в процессе собеседования».
Цель алгоритмического собеседования — вовсе не проверить, насколько вы хорошо знаете алгоритмы обхода деревьев. Алгоритм выступает лишь в роли контекста. Цель собеседования — получить представление об общем уровне вашей «соображалки», оценить коммуникативные навыки, стиль мышления, и заодно проверить навыки перевода идей из головы в код.
Как минимум такая проверка дает ложноотрицательные результаты. Ваша компания сознательно идет на этот шаг? У вас очередь из кандидатов?
У вас есть какие-то метрики, которые показывают, что собеседование с алгоритмами показывает уровень «соображалки» лучше, чем собеседования «за жизнь»? Я слышал, что опыт успешного прохождения таких собеседования набивается синтетически на сервисах типа leetcode
Да, лично я знаю и пузырек, и обход дерева. Но простите, сортирую я LINQ выражениями уже лет 10 и там совсем не пузырек. Так зачем мне показывать это знание? Что оно показывает?
Цель алгоритмического собеседования — вовсе не проверить, насколько вы хорошо знаете алгоритмы обхода деревьев. Алгоритм выступает лишь в роли контекста. Цель собеседования — получить представление об общем уровне вашей «соображалки», оценить коммуникативные навыки, стиль мышления, и заодно проверить навыки перевода идей из головы в код.Почему спрашивают алгоритмы, а на выходе ООП с таким кривущем дизайном, что глаза лопаются и служат детонатором для взрыва мозга.
Я не особо знаю алгоритмы, сходу я не скажу разницу между двумя произвольными алгоритмами сортировки, при этом я более-менее знаю как работают ассоциативные коллекции и какова цена определнных операций с ними.
Пару раз упарывался по производительности определенного куска кода и не более того, зато кривой и неповоротливый дизайн, который в свое время не переделали, а после обложили костылями куда серьезнее тормозит развитие продукта.
Если говорить о прикладном программировании, то в первую очередь это дизайн.
Конечно если нанимается человек на ИИ, распознавание и т.д. его обязательно надо спрашивать про алгоритмы, потому, что ему с ними работать.
Когда делаешь ремонт, строительной бригаде не задаешь логичекие задачки, а сморишь с чем работали, как и что делали, по какой технологии, какие решения вообще принимали в том или ином случае.
Почему у программистов то про люки спрашивают, то про забеги по джунглям, а потом садят писать вполне конкретный код.
Браво! Автору мое восхищение! Не в бровь, а в глаз. Особенно булшита — "духа" и "ценностей", все измеряется прибылью хозяина. )))
Это по сути единственная цель, потому что я лично видел пару раз на своем веку, как адекватные в общении люди слетали с катушек через полгода.
Я думаю, что стоит развить эту тему.
А на нём безраздельно царят работодатели, а не работники.
То есть многие тут в комментариях удивляются — «они что, в соискателях как в сору роются?». ДА Отличный пример привёл kolemik в этом комментарии.
Пора уже понять, в мире слишком много лишних людей, мифы о «дефиците айтишников» это только мифы, и именно поэтому любой набор персонала выглядит как набор в элитный отряд космонавтов. Да, вы должны быть именно тем человеком, ОДНИМ НА МИЛЛИОН, который после десяти лет работы ничего не забыл из студенческих времён, так что способен и все алгоритмы перечислить, и на доске/бумажке написать код, и одновременно решить задачку про круглые люки и попадание в миксер. Такого супермена, так и быть, возьмут на работу. А все остальные просто НЕ НУЖНЫ.
К сожалению, люди не хотят этого понимать, им застилает глаза дымовая завеса из громких криков «у нас дефицит в айти, дефицит». А приглядитесь — кто кричит-то? Кричат те, кому за тарелку супа не хотят блокчейн делать. Нет никакого дефицита на самом деле.
Там, где дефицит есть — там берут всех. Как я всегда говорю — там где нужен работник там нанимают работника, там где работник не нужен там проводят собеседования.
Тут набежали защитники идеи собеседований, мол, да это надо, да ведь обманут — ну это всё оправдания того же уровня, что и поиск принца до старости.
«Право, такое затруднение — выбор! Если бы еще один, два человека, а то четыре. Как хочешь, так и выбирай. Никанор Иванович недурен, хотя, конечно, худощав; Иван Кузьмич тоже недурен. Да если сказать правду, Иван Павлович тоже хоть и толст, а ведь очень видный мужчина. Прошу покорно, как тут быть? Балтазар Балтазарович опять мужчина с достоинствами. Уж как трудно решиться, так просто рассказать нельзя, как трудно! Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича, да взять сколько-нибудь развязности, какая у Балтазара Балтазарыча, да, пожалуй, прибавить к этому еще дородности Ивана Павловича — я бы тогда тотчас же решилась. А теперь поди подумай! просто голова даже стала болеть.» ©
Я вот и как работник (собеседующий) видел рынок и как соискатель… в каждой КАЖДОЙ конторе найти сеньора — это задача минимум на полгода и десятки-десятки собеседований
при этом найти мне работу — это неделя времени в течении которого я выбираю из работодателя из толстенной пачки предложений (я обычно выбираю быстро, потому что собеседование лично для меня огромный стресс)
и странно слышать что это работодатель великодушно соглашается меня взять на работу и роется среди стоящих за забором кучи людей… кому отдать ЗП из вилки которая зачастую больше ЗП среднестатистического директора какойнить захудалой ОООшки
в каждой КАЖДОЙ конторе найти сеньора — это задача минимум на полгода и десятки-десятки собеседований
Вы в 2008-2009 году в Нью Йорке собеседования видели? Так вот, там на сеньорскую вакансию претендовали десятки умеренно подходящих, штук 5 подходящих. Но вакансию закрывали за 2-3 дня, взяв единственного подходящего на 110%. Первичный отсев резюме — по списку из 2-3 десятков баззвордов. Нет одного баззворда — следующий. Версия Oracle 8? А у нас 9 — следующий. Версия Visual Studio 2005? А у нас 2008, следующий. Так что Вы просто не видели реальной жизни во всей красе.
При этом каждая вторая контора — тащит людей по h1b и если может то по L и явно не от хорошей жизни она это делает
А в Мск, человек дорастает до 250тыр… и всё давайдосвидания, уезжает за бугор… куда? а вот в этот ваш NY и уезжает… по этому почти во всех странах не из топ-списка нет сеньоров и вакансии висят не закрытыми годами
А сейчас любой студент с 2 годами опыта просит 200 и находятся видимо фирмы, что дают.
Прямо здесь вот на главной странице висит реклама с хаброкарьеры и в ней отлично видны зарплаты, постоянно вылезают цифры типа «от 65», «от 70».
Вы оба перегибаете.
Студент с 2мя годами опыта сейчас настреливает от 120 до 200 деревянных в зависимости от наглости
Если они там висят, это вовсе не значит, что кто-то за эти деньги идёт. Такие вакансии могут годами висеть, периодически пропадая и снова появляясь.
Есть огромное, невероятное, запредельное количество «донного народа» с низкой квалификацией и они тоже все хотят работу. Для многих таких и за 60к счастье куда-то пойти. Среди них могут быть довольно приемлемые/перспективные кандидаты с низкой самооценкой — не знающие себе цену. На «ловлю» таких «зелёных» и рассчитаны эти вакансии.
«От 65» это значит «мы в общем-то не против найти дурачка за 65» — но ведь это минимальная планка, а не то, сколько они реально готовы платить, столкнувшись с нехваткой квалифицированных кандидатов.
Там было много причин, начиная от индусского кода, заканчивая тем, что вместо полной переделки самолета, они пытались воткнуть в легаси шасси новый огромный движок, из-за чего развесовка и аэродинамика изменились и понадобился тот индусский код.
Сэкономили — получили.
У ВСМПО журналисты спрашивали: «Заказы Боинга упали, будет худо?»
Люди с ВСМПО отвечали, что да, Боинг упал, но Airbus увеличил заказы. Т.ч. примерно то же самое.
Какие-то управленцы накосячили — ну их выгнали. Вот когда таких не выгоняют, говоря что типа они незаменимые и всё такое, тогда да, начинается действительно упадок.
Про авиакомпании: да, коронавирус уменьшил пассажиропоток. При этом упала цена нефти -> затраты на топливо упали.
Стало много народу мереть — похоронщики больше денег получили.
Жизнь продолжается.
то есть денег в IT так много, что вместо десяти нормальных работников, умеющих не только массивы сортировать, но и в паттерны, и в нормальный читаемый код с тестами, можно нанять сотню условных индусов и методом мартышек они таки напишут любого Гамлета. А не напишут — ну что ж, наймём следующих.
плюс эти халявные деньги затягивают в индустрию всяких проходимцев, которые, первым же делом, занимают максимально далёкие от реальной работы места — тренинг-коучей, менеджеров по аджайлу, дизайнеров в пейнте, аналитиков в блокчейне и, конечно, специалистов по найму персонала.
надеюсь, что кризис всё же освежит нашу индустрию. мне вот не сложно потратить и день на собеседование, но я бы хотел его провести в беседе с непосредственным начальником и коллегами будущими, а не с бездушными тестами непонятно как относящимися к реальной работе. Да вы вспомните, когда крайний раз использовали массивы в реальном коде (а не в параметрических junit-тестах) иначе нежели Arrays.stream()?
надеюсь, что кризис всё же освежит нашу индустрию
Я бы побоялся надеяться на силу, которая не Вами запущена и не Вами управляется. Как раз в мутные времена проходимцы и приспособленцы будут выживать лучше, чем честные работники, не умеющие в построение «эффективных иерархических отношений». 30 лет назад предки тоже думали, что уйдет КПСС и заживем. Зажили…
уйдет КПССС поправками он вернётся.
Вот, кстати, здравствуйте, товарищ.
предки тоже думали, что уйдет КПСС и заживем. Зажили…
ну кстатати вполне себе зажили в бытовом плане то, люди не только на "Курорты Краснодарского края" ездили, а по всему миру… это смотря что вы оцениваете в этом вопросе
За последние пол года я прошел порядка 20+ собеседований чисто из интереса. И только 1 или от силы 2 были более менее адекватными. Всё остальное это: расскажите нам устройство ядерного блока и доказательство теоремы ферма, и тогда может быть мы дадим вам возможность исправлять баги в нашем накостыленном легаси коде, в котором даже и речи не идет о каком-либо SOLID. А ещё пожалуйста расскажите наизусть стишок из Рихтера
Людям в удовольствие издеваться и красть чужое время по причине полной безответственноти, им никто ничего не сделает если они украдут у вас 5 часов вашего времени
Прочитав данный материал, с ужасом делаю вывод что всё это строится осознанно. С целью выявления тех кто подойдёт на роль «половых тряпок» в устоявшемся коллективе.
Зеленый свет от такого сферического hr-менеджера кандидату, это маркер гопнику руководителю, что об кандидата можно вытирать ноги. Хотя сам hr этого может даже не осознавать.
А кто ещё может понравиться некомпетентному hr, кроме некомпетентного специалиста?
Жаль что такие вкусы на рынке труда доминируют. Стоит опасаться получать одобрение на найм от некомпетентных hr.
Более того, на одном онлайн митапе HR заявила, что входным фильтром может полужить хобби. Т.е. есть два примерно одинаковых кандидата (читай, нет кадровых проблем) и могут выбрать того, хобби которого лучше ложиться в корп. культуру.
Более того, на одном онлайн митапе HR заявила, что входным фильтром может полужить хобби. Т.е. есть два примерно одинаковых кандидата (читай, нет кадровых проблем) и могут выбрать того, хобби которого лучше ложиться в корп. культуру.
И по вашему это неправильно или странно? Для меня вполне себе логичный подход. Ну то есть на мой взгляд в такой ситуации было бы глупо брать того кандидата чьё хобби «хуже ложиться в корп. культуру».
В реальности его нет и подобные фильтры наглядно это показывают
Фильтры показывают что контора может работать не с полным комплектом кадров и перегрузкой сотрудников в поисках сеньора
сеньора нельзя заменить десятью миддлами, если вы об этом.
Если грубо, то допустим на рынке труда у нас 100 открытых вакансий и 50 кандидатов. И следовательно мы имеем нехватку кадров. При этом в какой-то отдельной фирме вполне себе может быть открыта одна вакансия и на неё могут претендовать несколько кандидатов.
Но вот что лично я наблюдаю на региональном рынке в сфере веб для опытного разработчика. Последних месяца три активно мониторю вакансии. Много рассылал откликов и ходил на собесы. Треть не смотрит отклик вовсе. Треть не отвечает вообще. В оставшийся трети либо реальному нужен мидл2/3, либо экономят по деньгам по уровню (<~100к на руки) либо разные мутные серые схемы. Возможно у вас другой опыт поисков?
Но если бы мы имели такую ситуацию, что в фирме Х был бы более строгий входной фильтр, чем в другие конторы. А в других конторах его бы небыло вовсе (если говорим про дефицит). Так?
Совсем не обязательно. Может быть дело просто в том что одни фирмы для кандидатов более привлекательны по каким-то причинам. А другие менее привлекательны или вообще не привлекательны.
Возможно у вас другой опыт поисков?
У меня однозначно другой опыт. Более того я бы даже вообще не сказал что последние лет десять я вообще занимался каким-то активным поиском. И работу я менял либо «по знакомству» когда меня к себе на фирму переманивали какие-то знакомые, либо через HR-агенства, которые сами выходили на меня. И мне минимум пару раз в месяц в том или ином виде приходят какие-то предложения по смене работы. И да, большинство из них не особо адекватны и меня вообще не интересуют. Но я бы сказал что минум раз в год приходит «вариант» над которым я уже и задумываюсь.
И я бы не сказал что я такой уж прямо суперценный и гениальный специалист.
И если послушать моих друзей, знакомых и коллег, то у них ситуация похожая. И я бы сказал в последние года 4-5 это всё ещё заметно обострилось.
Я бы сказал что я обычно менял работу примерно с 10-15% прибавкой. Но это сложно сказать так как всегда есть куча сопутствующих факторов, которые не особо хорошо «монетизируются». И например один раз я менял работу и при этом моя зарплата как таковая вообще не выросла.
Поэтому если зарплату повышают и всё остальное более-менее устраивает, то я тогда новой фирме вежливо отказываю. А если не повышают или проблема не в зарплате, то для меня это означает что тема закрыта и что я 100% ухожу.
Ну потому что лично мне кажется что если тебе повышают зарплату только если ты кладёшь на стол заявление об уходе, то ничего хорошего из этого всё равно не выйдет. Может я конечно и неправ, но мне так проще.
Треть не смотрит отклик вовсе. Треть не отвечает вообще.
Запросто могут занимться просто мониторингом рынка, сбором базы резюме.
Фильтры возникают не только при переизбытке кандидатов на одну вакансию, но и просто в процессе отбора на "соотвествие занимаемой должности".
Не всегда эти требования можно написать в вакансии по разным причинам, в том числе потому что их вообще сложно формализовать. Но если взять кандидата им не соотвествующего, то с большой вероятностью через относительно короткий срок ты откроешь эту вакансию снова.
В зависимости от таких требований "нехватка кадров" может превращаться в "нехватка кадров с развитыми и хард, и софт скилами" или "нехватка кадров, способных работать в аджайл/энтепрайз/бардак окружении".
… но многие, увидев прибавку 50% пойдут и блокчейн делать с бигдатой. У них ведь там семья и дети.
А не пойдут. Ровно по этой причине. Семья и дети учат тому, что «сейчас» — это важно, на наиболее важно это «завтра». Толку уходить на большую зарплату, которая в любой момент может рухнуть. Толку с добльшей зарплаты, если все добавочные доходы вынужден будешь «проесть» в очередной раз место подбирая. Да и частая смена работы в трудовой книжке — это негативный фактор. Выбирайте любую мотивацию: не уживается в коллективе, неверно оценивает возможности, некомпетентен. Стоит такого брать? Зачем компании сотрудник (за хорошие деньги — другое даже не обсуждается), который с большой долей вероятности сбежит яерез год-другой?
Ну и мой вечный вопрос. Как? Вот скажите мне, как можно стать глубоко владеющим вопросом специалистом, если раз в полтора-два года менять место работы? Войти в тему, разобраться, придумать лучшее решение, реализовать его, обкатать во всевозможных сценариях и замкнуть вечный круг разработки. Разве на это достаточно полутора-двух лет? Или во мне опять системщик embedder'щик играет и в прикладном ПО (фронтэнде/бакенде/подставь-нужное) все совсем иначе?
Тут, на мой взгляд, гораздо полезнее было бы просто пообщаться с кандидатом за жизнь, оценив степень его погружения в проблему.
Уволить сотрудника, если выяснится что он не такой уж и мастер кода как «поболтать» — довольно проблематично, поэтому, желательно, спросить ещё и какие то технические аспекты.
Очень часто люди пишут в резюме, что владют «N технологией» в совершестве, даже если только слышали про неё.
Был случай на интервью:
В резюме, CI/CD, devops, и проче и прочее.
Спрашиваю: — а как вы это реализовывали, какие трудности были?
— нууу, эээ, я не знаю, я кнопку нажимаю и оно все само собирается, магия!
Очень многие просто нагло врут.
— Спрашиваю, а вы знаете про "...."
— Эээ, нет…
— (начинаю обьяснять что это)
— А да, конечно!
— Ок, продолжайте!
— ээээ, нет, не знаю…
Пишут, синьйоры, 15 лет опыта, спрашиваю банальные вещи, (джуниор — мидл левела) — не знают…
Вопросы из разряда:
«чем left join отличается от inner join» и азы по языку программирования.
Мы так уже года полтора никого нанять не можем :(
Я не говорю что надо спрашивать какие-то алгоритмы, которые в большинстве случаев к работе никакого отношения не имеют, но базовые знания все же спрашивать нужно.
Пишут, синьйоры, 15 лет опыта, спрашиваю банальные вещи, (джуниор — мидл левела) — не знают…
забавно потом… устраиваешся на работу после такого собеседования, когда нос морщат 'оо, он не может объяснить банальные вещи'… в потом в их код смотришь (который интервьювер писал) и кровь из глаз течет и волосы шевелятся на *опе от ужаса…
Мы так уже года полтора никого нанять не можем :(
Так поди «Зарплата не выше рынка».
В ЖЖ было схожее обсуждение, столкнулись бизнесмены из регионов, жаловались на то, какие к ним приходят людишки — пьяницы, наркоманы, ворьё всякое, бомжи. Начали обсуждать, выяснилось, что к предлагающим зарплату выше 40к приходят почему-то нормальные люди, только таких бизнесменов раз-два и обчёлся, а остальные пытаются «среднюю» предлагать.
Мне кажется, просто очень мало в России хороших разрабов. Видимо уехали все кто — куда.
Да, забыл уточнить, я про Сидней, если что пишу
— почему? Нормальных разработчиков отпугивает нормальная зарплата? :)
Хотя вот наблюдаю последние месяцы вакансию senior front от одной беттинговой конторы. Объявили 300+, но никак не закроют. Может, замануха какая
А в бетинг многие знакомые как раз таки не пойдут, потому что это противоречит принципам. И я бы не пошел. Даже за 500.
Объявили 300+, но никак не закроют. Может, замануха какая
Или «нюансы» типа 50 фикс, а остальное — премия. Или необходимость начать через какое-то время приторговывать персональными данными клиентов, налить через себя и пр. Плюс реальный риск попасть в «маски шоу» под берцы космонавтов ЦСН.
Уволить сотрудника, если выяснится что он не такой уж и мастер кода как «поболтать»
С учетом того, что большинство ИТшников несколько, скажем так, слабоваты в области взаимодействия с людьми, не вижу никаких проблем выкинуть на мороз таких одним днем в 5 минут. Они не то что заяву в прокуратуру не напишут и не заэнфорсят ее движение, они даже не знают где такая находится. Да, еще и постесняются вообще на конфликт идти. Так что в большинстве случаев чуть больше нахрапа — и нежелательный элемент покидает офис под взором охранника. Если что — видел такое в Москве не один раз за период с 2002 по 2017 годы. Причем на мои слова про поход в трудинспекцию, прокуратуру, ФНС мямлили какую-то хрень про образ скандалиста, черные списки и пр.
Могут даже отказать за то что у вас чрезмерно широкий кругозор.
Помню себя джуном и мидлом — в булшит начинаешь вникать очень быстро.
Теперь я выбираю места по собеседованиям, если они отклоняются от описанного вами в сторону формализма и прогона по терминам — собеседование для меня заканчивается.
Полтора года назад перешёл в кабинетную контору из пост-заводского опенспейса, небо и земля. Но с нежностью вспоминаю кубики с самой первой работы (у них свои недостатки при неправильном размещении), полное ощущение своего пространства.
Мне крайне необходима возможность изоляции от лишних сенсорных стимулов, при этом сохранение рабочей атмосферы и периодического контакта с коллегами неформально.
По второй части: ИМХО — пусть собеседуют, как считают нужным (не претворяясь специально адекватными) — так легче понять, в каком-то приближении, насколько легко вам будет ужиться в данной компании.
Но не могу пройти мимо этой фразы:
Он хочет работать по согласованным требованиям. <...> А потому, что он понимает, что требования определяют архитектуру и сроки реализации, и смена их может привести к тому, что архитектуру нужно будет подпирать костылями, так как время на изменение никто не даст.
И вот тот самый управленец (правда из бывших разрабов), не понимаю откуда взять эти чертовые согласованные требования. Не встречал заказчиков, которые четко знают чего хотят. Им все покажи тут, покажи там, а вот тут не так, а вот там вообще вы нифига не поняли… переделывайте…
Я перестал верит в гениальных аналитиков и проджектов, которые способны четко просчитать требования и высчитать сроки. Не встречал их на своем пути, ни в своей компании, ни у конкурентов. А значит приходится с этим жить. А раз не будет согласованных требюований, то будет макет, полу-прототип, прототип, доделанный прототип, прототип читающий, прототип сохраняющий… И каждый раз есть риск выкинуть в корзину и начать сначала.
И времени на изменение архитектуры, переписывания с нуля и пр. я не дам. Это не нужно ни мне, ни заказчику — для меня это чистые убытки, для заказчика срыв госзадания.
Но что я могу дать?
Могу дать только возможность постоянного рефакторинга и изменения архитектуры. Каждый день/неделю/месяц… Но чтобы без остановок бизнеса!
А что это за архитектура такая — да. хрен знает. Решайте сами.
видел и махровый легаси и смузи стартапы и кровавый энтерпрайз
Конечно, гораздо приятнее это делать в компании, которая приносит пользу людям, но многие, увидев прибавку 50% пойдут и блокчейн делать с бигдатой.
Вот это было обидно. Что не так с блокчейном? Кроме того, вы же не думате, что это только крипта?
А ответ просто, можно срубить инвестиций и их освоить и побежать дальше с новой технологией, которая перевернет мир.
На моем веку я помню:
1) БигДата
2) Блокчейн
3) AI
Типа сам видел в Голландии стартап продажи билетов на блокчейне. Зачем?
значит поэтому блокчейн это зло везде?)
То, что вы увидели это неудачное применение, а не плохая технология. Это разные вещи.
Я не против, когда спрашивают алгоритмы и эффективность в НАСА, я против, когда это делает пиццерия.
Я возможно вас удивлю, но 99% кода — это бизнес таски вида запросить наличия товара у поставщиков — показать каталог — положить в корзину — провести чекаут — передать в доставку.
Ну так людей, которые умеют перекладывать джсон с места на место — миллионы. Логично отобрать из них самых смышленых. Алгоритмические задачки с этим неплохо справляются.
Так это Вы TCP/IP изобрели, а не OSI. Двух уровней не хватает, потому что они не нужны сейчас никому отдельно, и тогда были таким же аллюром придуманы из головы комитетчиками потому что модель получалась красивая. В итоге на вопрос про модель Вы не ответили всё равно.
Про сеточки вопрос был а-ля «скажите бродкаст адрес сети 192.168.2.44/21», и вот на нём я словил клина просто потому что ловить клины на собеседовании моя традиция и считаю в уме я плохо настолько, что у меня есть натуральная распечатанная таблица перевода часов в/из моего часового пояса, UTC и других интересных зон. Кстати, классовую адресацию отменили давно, и за пределами SOHO не все адреса сетей теперь бьются ровно по октетам.
Так как первые двое сеньоров это я, то повысим же градус накала: я ещё и не разработчик, а эксплуататор, и код пишу в крайнем случае, т.е. когда другого пути либо нет совсем, либо он ещё дороже. И люди, которые ко мне на работе приходят со своими проблемами, приходят не послушать про маски и OSI, а чтобы я им помог их проблемы решить. А иногда я к ним прихожу решать их проблему, о которой они ещё не знают, а мне уже заметно.
Короче, здравствуйте, я из эксплуатации и я решаю проблемы. Сеньорность измеряется не способностью к запоминанию (хотя это очень помогает), а способностью самостоятельно доставлять нужный результат. Не знаешь — узнай, не делал — сделай.
Сжатие статьи методом jpeg: "Эй, вы, из чебуречной! Не будьте м… нехорошими людьми!"
Ему не нужны бесплатные энергетические напитки и сэндвичи в офисе, так как он лучше поест дома вкусный и здоровый ужин, чем будет пичкать себя этой химией.оффтоп, конечно, но домашний вкусный и здоровый ужин — это тоже химия…
Давайте не будем толкать стереотипы телевизорных домохозяек?
Автору спасибо за статью! Будто я сама её написала — так близкО.
На предыдущее место работы меня пригласил мой будущий руководитель, пересеклись на каком-то межведомственном совещании, он же и проводил собеседование. Основной посыл его собеседования был — расскажи, не что умеешь, а что реально сделал, чем запомнился тот или иной проект, чего вышло в итоге. Короче, беседовали часа 2. Под конец за жизнь, за рыбалку/охоту. В итоге, он меня принял. Через пару месяцев, захожу к нему в кабинет, а он бумаги разбирает, и протягивает мне пачку бумаг, типа глянь. Я мельком глянул — резюме. Пачка приличная такая. Говорю, расширяемся? Он говорит, нет, это были претенденты на твою должность, но как-то не «зацепили» меня.
В последствии сам собеседовал на пару-тройку вакансий и попробовал такой стиль. Многих претендентов ставит в тупик такой подход, видимо, привылки по шаблону, «могу копать, могу не копать». Многие просто не могли связно рассказать, что конкретно сделали на прошлых местах работы, какие результаты.
И еще интересное жизненное наблюдение. Мой тесть, 69 лет, до сих пор работает на автопредприятии автоэлектриком. Ему главный инженер говорит, дед, ты сам можешь ничего не делать, просто приходи на работу, выходи в цех время от времени и смотри кто и как делает и подсказывай, выдавай идеи, учи. И говоря образно, я бы так же хотел закончить свою карьеру.
А в целом, с учетом жизненного опыта, полностью согласен с автором.
Но вы серьезно думаете, что разработчик с десятилетним стажем, работавший хотя бы по 1.5 года на каждом месте, успешно в течение десяти лет обманывал всех, что он не умеет писать код?
Часто люди все 10 лет опыта занимались перекладыванием кирпичиков со стек оверфлоу, не думая и не зная даже базы. От фразы 'Ну у меня как-то так всегда работало само, не запоминаю', когда спрашиваешь просто жизненный цикл контроллера, уже расшиб все лицо себе.
жизненный цикл контроллера
а расскажите, что вы имеете ввиду под этим термином? гугл выдаёт что-то неудобоваримое…
не запоминаю
Как бы это норма.
То, что вы не используете постоянно вы и не запоминаете.
Есть некоторые уникальные люди, которые всё запоминают. Но их мало.
Если необходимо в него вмешаться — то можно пролистать инфу и все вспомнить.
Если есть какая-то редкая проблема — то аналогично, пролистать инфу и вспомнить.
А если каждый день сталкиваться с проблемами в жизненном цикле — то тогда эта информация всегда будет в голове
В первом случае ты идешь в стаковерфлоу и начинаешь с нуля искать.
Врядли с нуля. Наверняка первой мыслью будет «должен же быть какой-то стандартный механизм».
А если проблема где-то глубоко во внутренностях, то нужны будут уже довольно глубокие знания механизмов которые врядли возможно постоянно держать в памяти и в результате все равно окажешься на стаковерфлоу с нулевым понятием где и что пошло не так
Или человек является фанатом какой-то одной технологии или библиотеки, применяет ее к месту или нет и «решает» с ее помощью все задачи. А как работать без библиотеки не знает.
Я считаю, что надо еще давать человеку небольшое тестовое, которое решается за пару часов. Это показывает не только качество кода, но и как человек сможет решить простую задачу, какими средствами. Часто встречаются кандидаты, которые под видом pet-projects выдают форки чужих репозиторий или проекты фирмы, к которым имели доступ, но где собственно их кода нет.
Т.е. это повод людей пихать как скот — а чего — пускай вообще на головах друг у друга сидят, не? А хотя не прокатит — есть же наверняка какие-то санпины по этому поводу. Кстати, меряли CO2 в опенспейсе к концу дня — уровень зашкаливающий. А ты думаешь — почему это эффективность работы после обеда падает
И да, это магическим образом искореняет вражду тех, кому душно и кому дует: кому душно — нижний ряд и окно приоткрыть, кому дует — в верхний ряд, тёплый воздух поднимается вверх.
Т.е. это повод людей пихать как скот — а чего — пускай вообще на головах друг у друга сидят, не?
Не вижу расхождения с тем, что в головах у большинства владельцев заводов, газет и пароходов. Хотя и искренне против такого расклада.
Годная, неимоверно годная статья.
Теперь замечание:
В процессе разговора необходимо честно рассказать реальное положение дел в компании, кто ставит задачи, есть ли стандарты разработки, CI/CD и прочее.
Это они не могут, честно рассказать. Что они, дураки что ли?
Чувак в статье подается на «Сеньорскую позицию», но при этом говорит глупости вроде «не верю в перевод проекта на .net core, потому что до меня все плохо сделали» и «я хочу, чтобы у меня были четкие требования и куча времени на выпиливание идеального кода» и «хочу, чтобы в организации были налажены все процессы, а я только понятные задачи делал». И при этом всем, он хочет большую ЗП и получить офер просто «пообщавшись за жизнь». Серьезно? Это никакой не уровень сеньора, это уровень мидла в лучшем случае. Помимо того, что таких желающих сидеть на работе ровно на попе и не напрягаться за хорошую ЗП вагон, он еще и в случае чего внештатного первый же сольется, кинув команду. Сеньор — это как раз человек, который не боится вызовов, пусть то будут алгоритмы на собеседованиях или непонятные требования, отсутствие процессов и жесткие дедлайны. Когда человек на сеньорской позиции пытается это все свалить на кого-то другого или на исторические причины, вместо того, чтобы решать эти проблемы и продавливать у менеджмента нужные решения как например переезд на тот же .net core, то человек явно не на своей позиции находится.
В том же ФБ во многих командах нет четких процессов, а в гугле постоянно меняются требования и закрываются проекты. Так устроено прибыльное айти в современном мире.
Я всю жизнь работал в компаниях, где было достаточно «поговорить по душам» для офера, и сейчас понимаю, насколько я из-за этого отстаю от крутых спецов. Поэтому прилагаю много усилий, чтобы это поменять.
оу, ниче я коммент накатал, никогда такого не было, видимо статья меня задела :)
На всякий случай – это только мое мнение на данный момент моей жизни, и я не говорю, что оно единственное верное.
Я понимаю людей, кто хочет просто хорошую работу с нормальной зп и вменяемого работодателя. Но не понимаю, когда люди с таким подходом хотят «крутой хайлод проект» и ЗП как в ФААНге.
Это никакой не уровень сеньора, это уровень мидла в лучшем случае.
не вижу логики.
он еще и в случае чего внештатного первый же сольется, кинув команду.
Вывод тоже откуда-то с потолка.
отсутствие процессов и жесткие дедлайны
только это совершенно не означает, что необходимо положить свою жизнь на борьбу с ветряными мельницами
Я понимаю людей, кто хочет просто хорошую работу с нормальной зп и вменяемого работодателя. Но не понимаю, когда люди с таким подходом хотят «крутой хайлод проект» и ЗП как в ФААНге.
+1 наверное, хотеть не вредно )
Не спрашивайте того, чего у вас на проекте не применяется!
Если у вас не используются сложные алгоритмы сортировки и т.д, смысл их спрашивать? Не, я конечно выучу их перед собеседованием, но без практики, через неделю уже всё забуду.
В первую очередь, вам должно быть комфортно работать в команде с этим человеком, крутой спец которые не может общаться с людьми и работать в команде стоит 0
Может кому-то приятно общаться с людьми, которые в сортировках разбираются. Вопрос тогда не на технические знания по сути, а на культурный кругозор или типа того )
Ну может кому-то приятно работать в обществе девушек модельной внешности :) Вопрос готов ли за это платить наш клиент)
Ваш — не знаю, но наш (на прошлом проекте) был готов платить за командные (нетехнические) интервью, основной целью которых было не допустить в команду людей, с которыми будет неприятно работать большинству команды.
Ну это огромная редкость, так как такая система просто малоэффективна… Собеседование (командное) идёт 1-2 часа… Узнать за это время человека, как он себя будет вести в той или иной ситуации… невозможно, тем более что модель поведения на собеседование и в реалях проекта может существенно отличаться.
Но, то что вы развели клиента на подобную хрень конечно здорово )
Предлагаю ещё проводить командное собеседование в баре или в сауне :)
Узнать за это время человека, как он себя будет вести в той или иной ситуации… невозможно
Имхо, лучше так чем никак
Но, то что вы развели клиента на подобную хрень конечно здорово )
Я стараюсь не работать в местах, где заказчики разрабатываемого софта — это клиенты, а не коллеги.
Ну назвать их можно как угодно :) "Дорогие и любимые клиенты ", "братья", "товарищи", "уважаемые коллеги" и т.д)
Суть от этого не поменяется, заказчик тот кто платит вам зарплату ) Всё становится проще, если свести всё к экономике и экономическим взаимпотношениям )
Имхо лучше никак, чем так )
Во всяком случае не будем просто так сжигать деньги клиента )
А то получается как в анекдоте :
Приходит министр сельского хозяйства к М. С. Горбачеву.
- Михаил Сергеевич, беда, в стране куры дохнут.
- Ничего страшного, нарисуйте перед каждой курицей желтый круг.
Пожал плечами министр, ушел. Через две недели приходит: - Михаил Сергеевич, все равно дохнут.
- Впишите в желтый круг зеленый квадрат.
Пожал плечами, ушел. Приходит через неделю: - Михаил Сергеевич, дохнут ведь, совсем мало осталось.
- Впишите в зеленый квадрат красный треугольник Проходит месяц,
встречает Горбачев Министра и воспрашает, а чтож вы не заходите не
рассказываете как там куры? - Да понимаете Михаил Сергеевич, сдохли все.
- Ах как жаль, у меня еще так много идей!
Зарплату мне платит работодатель, а ему платят его (наши) клиенты. Я предпочитаю работать в компаниях, где клиенты — конечные пользователи продукта, имеющие весьма опосредованное отношение к тому что и как мы разрабатываем для них, а не там, где клиент работодателя одновременно и заказчик разработки и разрабатываем мы то, что он скажет и, зачастую, так как он скажет.
Работодатель это всего лишь прокладка между исполнителем и клиентом. Он вам зарплату не платит.За все что вы делаете всегда платит клиент. Что значит "конечные пользователи имеют весьма опосредованное отношение к тому что и как вы разрабатываете "?
Заказчик вам платит за то чтобы вы разрабатывали штуку которую он потом не использует ?
Заказчик вам платит за то чтобы вы разрабатывали штуку которую он потом не использует ?
бывает и такое, к сожалению. А с проектами-долгостроями бывает так, что они не вводятся в строй никогда на 100%, а когда вроде бы уже пора — так уже новый проект начался по внедрению чего-то еще....
Обычно не прокладка, особенно в случае продуктовой разработки. Работодатель вкладывает свои деньги в продукт, в том числе в зарплату разработчиков, и пытается потом компенсировать эти траты, желательно с прибылью, за счёт клиентов.
Клиенты платят нам за использование штуки, которую мы сделали. Вы вот пользуетесь Хабром, но не указываете им как его делать? Голосуете своим присутствием и активностью за те или иные фичи. Примерно так и у нас, только голосуют деньгами.
Узнать за это время человека, как он себя будет вести в той или иной ситуации… невозможно, тем более что модель поведения на собеседование и в реалях проекта может существенно отличаться.
Это означает "Никогда ни для кого узнать невозможно?" или "Невозможно узнать со 100% уверенностью для всех?".
Я думаю есть такие кандидаты которых можно достоверно оценить и отсеять.
Например, если он на собеседовании воняет или все время ведет себя неконструктивно.
Собеседование здорового человека