• Собеседование в Яндекс: театр абсурда :/
    0
    Не, у меня было так же, вежливо уточнил у HRа не возникло ли тут какой ошибки. Нет, так и задумано.
  • Собеседование в Яндекс: театр абсурда :/
    +1
    Проходил через эту историю, как раз как питонист, и могу сказать что им таки нужно не лучшее решение, а именно эталонное.
    Задача — почитать количество единиц в битовом представлении числа. Ну, какбы, пишу я, bin и count. Никакой стандартной библиотеки, никаких импортов, в питоне это считай О(1). Но интервьвера это понятное дело не устроило. Я уточнил, что я конечно могу написать обычный вариант с битовым смещением, но он будет заведомо хуже ибо будет линейным, интервьювер сказал — пишите, именно он мне и нужен. Написал.
    На других задачах я так не блистал, потому на тимлида меня не взяли. Но сказали готовы рассмтореть на сеньора. Я ради интереса согласился, и что вы думаете? Снова пачка таких же задач. Не взяли. Предложили мидла или другую команду. Что было бы дальше я проверять, конечно, не стал :)
  • Как мы сделали движок и игру на нем за полтора года
    +28
    Текст явно писал не разраб, а маркетолог. Потому что читая эти строки, я как человек работавший в геймдеве как разраб, вижу человека который работает в отрасли максимум несколько месяцев.
    Человек, который написал аж несколько игровых проектов, да еще и директор, в жизни не скажет «двигать отрасль вперед». Потому что геймдев, это наверное, самая высоконкурентная сфера в ИТ. У нее нет «переда», у нее только «зад» есть. Потому что весь геймдев это огромный конкурс о том, кто лучше доит своих клиентов.
    Вся эта амбициозность про напиливание своих движков живет только до первого прибытия результатов аналитики.
    Я помню этот день как вчера. За спиной был с год проекта, выход в прибыль, команда человек в 10-15. Мы сделали новый релиз который готовили пару месяцев, выправили кучу багов, сделали кучу офигенных оптимизаций, зарефачились вволю, и и запилили несколько классных, реально новых механик, которых нет у конкурентов. Мы были довольны собой.
    И тут издатель такой, ребята, вы реально классные, но вам надо поработать над конверсией. И в знак нашего доверия, вот вам доступ к аналитике конверсий других наших игр.
    И ты начинаешь смотреть. Вот наша игра, мультиплеер, 3D, графон, хитрые механики, сеть, кроссплатформенность, и т.д. И, условно, миллион баксов в месяц. И рядом другая игра. Обезьянки лопают шарики. Все. просто обезьянки лопают шарики. Для детей. Такую фигню на вскидку пилят два человека плюс дизайнер. Втроем за пол года можно не напрягаясь запилить. И там, условно, десять миллионов за тот же месяц.
    После этого ты нервно закуриваешь, и уходишь в закат думать о смысле бытия, тщетности всего сущего и вот этом всем. И вот таких постов уже никогда не пишешь.
  • Хороший код до Google не доведет
    +1
    там уйма противоречивых требований которые очень не любят складываться.
    К примеру — выпадает человек на бенч, подбираешь ему хороший проект, а он не стартует. Заказчик маринует месяц, потом второй, третий…
    Новички(кто только пришел в компанию) очень не любят сидеть на бенче. Поскольку ежели я вам так нужен, что вы меня наняли, как так что для меня проекта нет? А именно их сложнее всего пристроить.
    И да, на бенче чаще всего сидят миддлы и джуны, но именно им бенч меньше всего интересен и нужен — на бенч лучше всего сажать старших, что бы хоть передохнули между проектами, но их оттуда оттаскивают в первую очередь.
    Это только в общих чертах. При этом бенч довольно важная штука в профилактике выгорания, росте и развитии компании, и качество управления им имеет очень большое значение для компании. Но управлять им — реальный ад. Почти всегда выбираешь наименее отвратительное решение, удачные и верные ходы — большая редкость.
  • Хороший код до Google не доведет
    0
    простите, а зачем? Очевидно в вашу компетенцию это не входит (раз в нее не входит проверка соответствия статуса таски реальному положению дел) и реальной информацией вы тоже не обладаете. Зачем говорить что над задачей плотно работают, если вы об этом реально не знаете и отношения особо не имеете?
  • Хороший код до Google не доведет
    0
    Да, но давайте все таки вернемся к кейсу «мы плотно работаем» в том конкретном случае, когда на самом деле нет. Вы же не скажете «багофикс в QA, тестеры над ним активно работают» опираясь чисто на статус в багтрекере. Только в том случае если есть реальная информация, что они действительно над ним работают.
    Опираясь на статус багов отчитываются только те, у кого есть менеджерские обязанности(бывает и разработчики). Остальные отчитываются в основном только за себя (где обладают полной информацией), либо если обладают реальной информацией о других, в которой они точно уверены, например видели своими глазами.
  • Хороший код до Google не доведет
    0
    Люди, в чью компетенцию не входит проверять чужую работу и не отвечают о состоянии работ по задачам опираясь на статус тикета в багтрекере. Они и без багтрекера прекрасно знают работают они над задачей или нет.
  • Хороший код до Google не доведет
    0
    отличаю, а вы? Таки между заблуждением и распространением заблуждений есть весьма заметная разница.
    И сказать то он может все что угодно, но за слова отвечать потом придется самостоятельно. В частности если вдруг язык повернулся отчитался что «плотно работаем» глядя чисто на статус тикета, неплохо бы пойти потом и проверить, что работа реально происходит.
  • Хороший код до Google не доведет
    0
    Ну мы так даже конкретный проект обычно не предлагаем. Они у нас идут паровозами, и отправляются достаточно рандомно, так что на момент собеседования вообще сложно что-то сказать. Пока идет собеседование и найм, некоторые проекты можно и сделать успеть, даже такое бывает. Особенно если кандидат просит 1.5 месяца на переход.
    А вот с выбором проекта это да, боль. Обычно куда поставят — туда поедешь, без вариантов. Это практически везде. Мы стараемся наверное больше остальных упарыватся подбирать проекты под людей, но сколько усилий не трать — гарантии получить проект не выходит. Но управление бенчом это тема для отдельного разговора.
  • Хороший код до Google не доведет
    0
    Видимо они до вас просто не добрались ) Обычно выметают с рынка все что есть что бы посадить на реальные проекты, спрос большой (у нас к примеру открыты вакансии в нескольких городах, мы как раз такая компания). Собственно частенько в компаниях существует перманентный дефицит который закрывают субподрядчиками.
    Компании без бенча — не уверен что их можно называть аутсорс компаниями. Вполне себе тянет просто на посредника или биржу труда.
  • Хороший код до Google не доведет
    0
    удивительно что такой простой факт — производится работа или нет у вас вызывает сложности.
    Производство работы это процесс. Состояние бага в багрекере это не процесс. Либо кто-то работает над задачей, либо нет. Вы сами сказали — статус выставили, и «когда-нибудь до него у кого-нибудь дойдут руки». Это совсем не тоже самое что «задумался о чем-то или пописать отошел».
    Либо работа реально реально производится, либо нет. Работа это любая деятельность направленная на решение проблемы, будь то написание кода, либо просто размышление над задачей или общение с закачиком, это не важно. Если работа не производится, а разработчик говорит, что «мы плотно работаем», то это ложь. Независимо от того какие там статусы в багтрекере. Перевод статусов в багтрекере не способствует решению задачи.
    Либо работа реально производится и кто-то над ней работает и тогда все ок.
    Если вы не понимаете таких довольно простых вещей, не вижу большого смысла с вами обсуждать более сложные аспекты коммуникации
  • Хороший код до Google не доведет
    0
    Софистикой не страдайте. Когда к вам начальник придет и спросит что было сделано за неделю такой «усилинной работы» вы о чем отчитаетесь? «Мы баг в прогресс перевели»?
  • Хороший код до Google не доведет
    0
    В таком аутсорсе — это в каком? По сути аутсорс один, а это просто разные формы контрактов. Как правило аутсорсинговые компании не ограничивают себя какой-то конкретной формой сотрудничества и всегда готовы идти на встречу заказчикам. По факту это означает что у одной аутсорсинговой компании в работе как правило находятся контракты всех видов, и чем крупнее — тем большее разнообразие можно встретить.
  • Хороший код до Google не доведет
    0
    Потому что если человек говорит «мы усиленно работаем», а на деле не делается ровным счетом ничего — это ложь как ни заморачивайся с интерпретациями. Все эти «ну он же в багтрекере есть» это пустые отмазки, а не интерпретации.
  • Хороший код до Google не доведет
    0
    Сейчас наверное все аутсорсеры так работают. В продуктовых компаниях еще можно как-то от клиента изолироваться, а вот в аутсорсе не выйдет. Особенно в проектах с совмещенными командами или под прямым управлением заказчика.
  • Выводим лгуна на чистую воду: собеседование – это не трудовые отношения. Естественно
    +1
    Таки нет, устные договоренности тоже считаются. На этот случай даже предусмотрен механизм «уклонение от заключения трудового договора».
  • Хороший код до Google не доведет
    0
    Как я уже написал выше, совсем не обязательно подразумевает. Это также может подразумевать «фиг знает что с ним делать, займусь пока чем то поважнее, может потом в голову чего придет».
    Это вообще все что угодно может подразумевать. Сама фраза, как я уже сказал, не несет ровным счетом никакой полезной информации. Все остальное — домыслы, попытки опереться и угадать исходя из дополнительного контекста, что же разработчик имел ввиду.
  • Хороший код до Google не доведет
    0
    В том числе. Там вообще большой список причин. Нынче разработчики это не только инженеры. Это еще и лицо компании, при том с разных сторон. И перед клиентом, и, например, перед рынком труда. По этому компании вкладываются в проведение мероприятий, отправляют своих инженеров спикерами. Ну и в командную игру нужно уметь. А так сложилось что это все довольно связанные вещи, и набор навыков для всего этого нужен плюс минус один и тот же.
  • Хороший код до Google не доведет
    0
    а вы думаете откуда этот раздел про soft skills вырос. Лет десять назад такие вещи никого не волновали.
    У нас кстати говоря разработчики работают с заказчиком напрямую. И в нескольких конторах до того, где я работал это происходило в той или иной степени.
    Образ разработчика как нелюдимого тролля, говорящего не непонятном языке уходит в прошлое.
  • Хороший код до Google не доведет
    0
    ну если разработчики напрямую врут, то тут есть проблемы посерьезнее некорректных формулировок.
  • Хороший код до Google не доведет
    +1
    Ну сейчас довольно можно вести прямой контакт между разработчиком и клиентом, сильно снижает уровень бюрократии и ускоряет коммуникацию.
    Ну и «такой ситуации не должно возникнуть» так себе логика. По ней и багов то быть не должно. Пони, радуга, рок-н-ролл.
  • Хороший код до Google не доведет
    0
    заявить «у меня все работает» и «уточнять условия вопроизведения», «отреджектить тикет» это таки две большие разницы. Это может происходить одновременно, а может и не происходить. Тикет может висеть открытым годами, и по нему не будет ничего не происходить, потому что «у меня не воспроизводится», где подразумевается «фиг знает что с ним делать». Весьма распространенная ситуация. Видел такое в разных компаниях, в том числе крупных и известных.
  • Хороший код до Google не доведет
    0
    Это значит что над ней по крайней мере работают. «у меня все работает» вообще ничего не значит.
  • Хороший код до Google не доведет
    0
    Может. А может означать что ткнул пару раз, решил что муть какая-то и решил просто ничего не делать. А может там вся команда бьется над решением с привлечением смежных департаментов. Собственно это и значит что он не сообщает нужной вопрошающему информации. Вообще никакой кроме того, что судя по всему, что-то идет не так.
    «О Великий Думатель, я хочу услышать ответ четкий и ясный, дай нам ответ на главный вопрос» (с)
  • Хороший код до Google не доведет
    0
    Ну в примере очевидно вариант ответа клиенту. По этому ощущение шизофрении при ответе начальнику нормально.
    Для ответа начальнику очевидно достаточно «сейчас работаю над этим». В случае критичности проблемы можно сказать «отложил остальные задачи, сейчас работаю только над этим».
    Ну и нужно понимать это это воображаемый пример который просто иллюстрирует как может звучать ответ, который отражает информацию по важным аспектам. Естественно его нужно допилить по месту.
  • Хороший код до Google не доведет
    +1
    Как я уже сказал, нет никакого «нет» на пересечение зон ответственности. Его и быть не должно. И да, человек должен лезть повсюду. Если человек видит проблему, знает как и хочет ее исправить, ничего не должно ему мешать. Наоборот — все должны ему помогать. Это не так часто происходит как хотелось бы, что бы еще какие-то ограничения вводить.
  • Хороший код до Google не доведет
    0
    У нас некоторые проекты ведут мидлы, т.е. они выступают в роли девлида. Но обычно, конечно, это небольшие проекты, простые, с совсем маленькой командой, или даже скорее вовсе без нее. Человек-проект.
    Но и требования к мидлам (да и вообще ко всем разработчикам) достаточно серьезные.
  • Хороший код до Google не доведет
    0
    Ну те доступы которые не выданы, ты вполне можешь запросить и получить. У нас нет вообще очень мало такого, что «тебе знать не положено». Любой человек может заниматься любыми вопросами. Это просто реальный пример по приведенному вами случаю, который приводился в пример, что «так не работает». Работает. И еще как. Не совсем так как приведено у вас конечно, но работает. Владелец выдает полномочия, когда ты сильно выходишь за рамки ответственности, и попадаешь на его «поле». Но если речь идет о бюджете департамента, то тоже будет происходить с руковдителем департамента.
    Но границ нет. Есть зоны ответственности, но они никак не ограничивают в деятельности. Да, конечно, твои действия должны быть согласованы с тем, в чьих зонах ответственности ты действуешь, но это не граница, там нет запрета на пересечение.
  • Хороший код до Google не доведет
    0
    Ну собственно речь о том, что «у меня работает» не может быть ответом. Может быть дополнительной информацией, пояснением к ответу, но самим ответом должно быть что-то другое. А иногда приходится сталкиваться с тем, что разработчик считает, что это может сойти именно за ответ.
  • Хороший код до Google не доведет
    0
    Вы удивитесь, но у нас в компании у сотрудников таки есть доступы к бюджетом. И любой разработчик может прийти (в том числе и к владельцу), и выдвинуть свои предложения о том, как этим бюджетам следует распорядится.
    И вполне возможна ситуация, что владелец скажет — окей, займись этим, т.е. выдаст ему все полномочия для проведения этих изменений. Для этого есть специальный механизм, и касается это даже джунов.
    Так что вы несколько ошиблись в том, кто плавает в теме.
  • Хороший код до Google не доведет
    0
    Ну на самом деле чем выше должность, чем больше тебе платят именно за знания, а не за деятельность. По сути по мере роста компании в сторону бирюзы (тут вроде оказалось достаточно много народу способных поддержать беседу в этом ключе), руководитель превращается из исполнителя в советника. И то чем он по сути занимается — это шарит знания, а не производит какую-то реальную работу. Они имеют гораздо большую ценность. Тимлид в таких структурах это самая верхняя из должностей кто реально еще может что-то делать руками, но должен уже стремится к тому, что бы перейти на следующую ступеньку, где ему этого не светит.

    Ну а монструозные списки требований как правило вылезают из размазанных зон ответственности. По факту обычно не известно точно, что нужно. Есть некоторая дыра которую надо закрыть, и тут уж кого найдут — тем и закроют. Т.е. список требований — это список пожеланий и не нужно к нему подходить как то, что нужно реально все это знать. Как правило ожидают до 75% покрытия.
    Ну, и опять же, планка критериев поиска всегда должна быть выше ожидаемого результата. Вы удивитесь по насколько безумным требованиям иногда удается находить реальных кандидатов, которые им удовлетворяют. А если не завышать ожидания, таких не найдешь.
  • Хороший код до Google не доведет
    +2
    Даже для играющего тренера, ожидать знания всех формул на зубок странно. И чем больше вы ожидаете от него как от тренера, тем меньше очевидно следует ожидать технических знаний.
    Например если это тимлид плюс, который может уже не только тимлидить, а подхватывать и более высокоуровневые вопросы, то такой человек очевидно гораздо более ценен практически для любой компании. Таким подходом такие люди автоматом отсеиваются. А должно быть наоборот.
  • Хороший код до Google не доведет
    +1
    Ограничение областей власти нынче не в моде )
  • Хороший код до Google не доведет
    0
    Там дело не только в высокой ответственности и количестве софт скилов, там вообще огромный спектр требований. Нужно до идеала надраить все предыдущие уровни — и иерархическое управление, и роль индивидуума, и культурный слой, шаринг знаний, список длинный. Но сейчас речь не об этом.
    В бирюзовых организациях любой сотрудник имеет возможность проводить изменения любого уровня. По сути, даже джун, может проводить изменения на уровне компании, то что в классической схеме управления часто может сделать только владелец компании. Это таки очень сильно увеличивает степень ответственности на всех уровнях, особенно на низких (на высоких она наоборот снижается, происходит выравнивание).
  • Хороший код до Google не доведет
    +1
    Определенно больше понравиться, хоть он и по прежнему плох. Из ответа «не могу воспроизвести» следует, что он пытался воспроизвести и у него не получилось. Из ответа «у меня все работает» вообще ничего не следует.
    Хороший ответ должен давать информацию по следующим аспектам:
    1. Насколько плотно работают над проблемой?
    2. Когда она будет решена?
    3. Требуется ли что-то, для того что бы задача была решена или решена быстрее?
    По сути это единственное что волнует клиента, и как следствие, должно волновать разработчика. Ответ «у меня все работает» не отвечает ни на один из аспектов, более того, создает впечатление негативных ответов. Похоже, над проблемой сейчас не производится никаких работ, и не похоже что кто-то что-то делал. Вариант «не могу воспроизвести», означает что по крайней мере кто-то что-то попытался сделать, но ситуация по прежнему не улучшается.
    Идеальный ответ звучит так:
    «Наши лучшие специалисты в настоящий момент плотно работают над этим, ожидаем решения в течении часа. Ребятам здорово поможет, если вы дополнительно предоставите следующую информацию:
    1.…
    2. ....»
  • Хороший код до Google не доведет
    +1
    Так и какое клиенту дело, что на машине разработчика работало/работает? Ему это чем поможет? Оно не работает у него, и только это его заботит.Единственное к чему она имеет отношение — к выяснению технических деталей инцидента. Но люди, которым этот ответ обычно дают, к такому выяснению обычно сами не причастны.
    И да, «попробуйте еще раз через 5 минут» это допустимый ответ. «Выясняем, сообщу вам через час», тоже допустимо. А вот «у меня работает» это классический ответ по которому можно понять что работаешь с недостаточно квалифицированным человеком.
  • Хороший код до Google не доведет
    0
    Проблема в том, что это никому не нужная информация не имеющая реального отношения к делу.
  • Хороший код до Google не доведет
    0
    Не могу сказать что такая мысль меня не посетила в тот момент. Там было несколько других аспектов, которые наводили на мысль, что с собеседованием вообще что-то пошло не так. Так что я пообщался с HRом на тему не забыли ли они чего. Но вроде как нет, это «особенность политики найма». Бодаться с политиками найма крупных компаний при входе я нашел и неуместными и бесперспективными. Ну и честно говоря не уверен что хотел бы работать с командой, которую отбирали подобным образом.
    К тому же по слухам зарплаты там были не особо высокие, да и в итоге на собеседования по сумме ушло больше 8 часов(только к ним), продолжать не похоже что имело смысл.
  • Хороший код до Google не доведет
    +1
    потому что это совершенно не важно что и как работает у программиста. Работать должно у клиента.
  • Хороший код до Google не доведет
    0
    тут дело не столько в мультиклассовости, а в том что тимлид решает вопросы на другом уровне. Он оперирует архитектурой, и крупными блоками, не закапываясь в мелкие детали. Делает он это по прежнему руками (к примеру архитектор обычно уже нет). Тем не менее в детали обычно закапываются другие, за исключением случаев требующих особой квалификации или знаний. Это просто более высокий уровень абстракции, а не другой класс работы.
    Хотя конечно, от компании зависит. Бывает по всякому.