Комментарии 220
Что касается обхода дерева, то совершать обход можно с разных сторон: слева или справа.
Здравия желаю, товарищ капитан!
1. Почему вы выбрали нашу компанию?А я отвечаю «это вы меня нашли». XD
Вы ранее привлекались за хранение данных в глобальных переменных?
Какой результат выполнения команды git push me and then just touch me till I can get my satisfaction, satisfaction?
Найдите точку G бинарным поиском
Назовите свою любимую позу для стендап митинга
Вы когда-нибудь делали .Net за деньги?
Вы способны довести девушку до оргазма языком программирования?
Сформулируйте зависимость времени исправления критического бага от seniority присутствующего менеджера
В своём резюме вы указали знание php. вам не стыдно?
Почему люк скайуокер круглый?
Какой из циклов быстрее, for, while или правило буравчика?
Обоснуйте полноту Javascript по Тьюрингу с позиций фрейдистской школы программирования
Перед вами кисть, холст и мольберт. напишите компилятор
Расскажите что-нибудь про Pascal
Расскажите о плюсах и минусах автокомплита в сексе
Как часто вы говорите своему коду «ну пожалуйста..»?
Перестаньте краснеть и хихикать! повторяем вопрос: «вы когда-нибудь ранее использовали LaTeX?»
У кого был самый длинный код в вашей прошлой команде?
Вы моете руки перед правкой кода на продакшне?
Что вызывает у вас бóльшую улыбку: «I have read and agree to the terms and conditions» или подпись под соглашением о неразглашении?
В резюме указано, что ваша последняя должность — delivery manager… вы пиццу что ли разносили?
Вас раньше обвиняли в попытках программирования?
Ну признайтесь уже — джаваскрипт алертами дебажили?
Можете ли вы провести аналогию между работой на пятилетнем проекте и проктологией?
Что, по-вашему мнению, более эффективно: скопипастить код из примеров или убедить заказчика, что ему не нужна эта фича?
push —force, checkout — а какие еще способы разрешения конфликтов вы знаете?
Если честно, то нас немного смущает тот факт, что вы искали работу программиста через биржу труда…
Согласны ли вы что каждый девелопер должен посадить зрение, построить велосипед и вырастить репозиторий?
В своем резюме вы указали, что хотели бы поработать на интересном проекте… вы этот проект с собой принесли?
Правда ли, что смесь php, css, js, html и sql в одном файле имеет слабительный эффект?
Согласны ли вы, что у админа должна быть борода, даже если админ — женщина?
Скажите, вы когда-нибудь симулировали ООП?
Умеете ли вы «договариваться» с QA накануне релиза?
Каким вы видите свой код через пять лет?
Раскройте геополитические предпосылки kernel panic с точки зрения теории струн.
Xbox, PlayStation или Terminal — какую консоль предпочитаете?
Вас когда-нибудь запирали в серверной? За что?
Какие приемущества force push перед стандартной работой с репозиторием? сколько времени данная методика экономит лично вам?
2048 или “Косынка” — в чём вы более успешны?
Скажите честно, вы врёте в LinkedIn?
По каким внешним признакам разработчика можно определить длину спринта?
Вы толерантны к копипастам?
«Семь раз update один раз commit» или «семь раз commit один раз revert» — какой методологии вы придерживаетесь?
Цикл, условие, переменная — а какие еще термины из С вы знаете, чтобы отказать парню?
Цой, Ленин, PHP — что между ними общего?
Как объяснить джуниору что пинговать сервера в его возрасте – это нормально?
Назовите самое экстремальное место в котором вы занимались багфиксингом
Напишите простейшую операционную систему. уложитесь в 140 символов
Как часто вы играете со шрифтами?
В резюме сказано, что вы проработали 10 лет в отделе тестирования майкрософт. мы проверили — такого отдела не существует!
Как вы относитесь к легализации курения мануалов?
Про недостатки я как то написал что люблю сладкое. Секретарша, принимавшая анкету очень возмущалась, говорила что это не недостаток. Хомячит сама наверное тортики по ночам :)))
Ну допустим, почему крышки из металла круглые — это как раз очевидно, а пластиковые стали делать круглыми, потому что уже были круглые металлические :)
Но это не связано с материалом.
А сейчас оказывается что пластиковым круглыми быть не обязательно. Как так? Пластик не позволяет квадратному люку проваливаться по диагонали?
Некоторые говорят, что крышки круглые, потому что колодцы круглые (можно сделать квадратные бОльшего размера, но это лишняя трата материала).
А колодцы круглые тоже для экономии (для того же сечения: меньше грунта вынимать, меньше материала для укрепления стенок).
Другие говорят, что бывают и квадратные колодцы и крышки (вероятно, на петлях, чтобы не поворачивались и не проваливались).
Яма круглая, но верхушка квадратная, потому что брёвна гнуть неудобно.
На самом деле мне кажется все гораздо проще: крыши круглые, потому что люки, которые они закрывают — круглые. А так, крышки люков ливневой канализации нередко квадратные, например.
Собеседование в фитнес:
1) Руководитель: Продай мне ручку
Соискатель: До свидания.
2) Руководитель: Вы нам подходите, мы вам перезвоним
Соискатель: А вы мне не подходите, до свидания.
3) Руководитель: нас можно найти по такому-то адресу. <Дальше начинает грузить какой-то херней>.
Соискатель: ой, извините, я передумала. До свидания.
Ну если какой-то примитив синхронизации просто не вспомнить в нужный момент (что он вообще существует), то и не придёт идея им воспользоваться.
Так а чем справочники от стековерфлоу отличаются? Не знаешь, что семафор вообще существует — не сможешь поискать по ключевому слову.
В справочниках, конечно, все примитивы синхронизации могут быть собраны в одной главе, рядом. Но это надо её прочитать, осознать, и опять же запомнить ключевые слова.
В общем, скажу по себе — иногда не хватает знания теории.
В конце-концов, есть и другие инженерные направления помимо софта. И там справочники очень даже в ходу.
Придумываешь инструмент, который мог бы помочь в конкретной ситуации и лезешь в гугл. В 99% случаев оказывается, что он уже существует. Мало кто из специалистов мыслит только в рамках своих непосредственных знаний.
Эдак можно и язык не знать и вообще программировать не уметь. Гугл же есть, туториалы зафигачил, стэковерфлоу почитал и вперёд — готовый миддл девелопер :)
Примитивы синхронизации, как и структуры данных это необходимая теория, их нужно знать хотя бы основные.
1) не работать бесплатно
2) не давать советы бесплатно
3) не работать вне рабочее время
Как только это начнешь выполнять, сразу становишься успешным IT специалистом
Нет, серьёзно, если мне интересно писать код — я не хочу руководить проектом.
Если я хочу руководить проектом — я устал от кода и иду руководить проектом.
И вообще, зачем мне подстёгивать карьеру, когда можно спокойно подстегнуть зарплату?
del
На западе в более или менее крупных конторах везде так, иначе бардак начинается. У нас имеются всякие DevOps Engineer IV и подобные.
Какой бардак, можно поподробнее?
Бардак в бухгалтерии, ведь столько денег тогда придется тратить на зарплатный фонд каждый месяц :)
В идеальном мире привязка зарплаты к должности и тесты для ее повышения не такая уж и плохая идея, так как тогда при улучшении знаний растет зарплата, вне зависимости от чьей-то предвзятости.
Но в реальном мире бизнес заинтересован в том, чтобы платить как можно меньше за работу. И если бизнес диктует свои правила по зарплате, то проигравшим всегда оказывается работник.
Уверен, что тесты для повышения квалификации будут:
1. Длиться несколько часов, чтобы отбить желание проходить такое снова
2. Содержать сложные задачки, которые не используются в реальной работе, чтобы убедить тебя в непрофессионализме
3. Повторно можно будет пройти тест только через несколько месяцев
Непрозрачная система компенсаций: HR и финансы обычно централизованы, сидят вообще в другом городе и не понимают как и что у вас в департаменте происходит — почему Васе столько-то, а Пете столько-то платится.
В советской действительности такая система действительно выглядит дико, так как оклад двух сотрудников со схожим функционалом может отличаться в худшем случае в разы. Тут же такого не бывает, оклады у всех более или менее ровные и отличаются максимум на десяток-другой процентов.
Поэтому в любых конторах с количеством сотрудников, которое измеряется тысячами, есть подобная система уровней. Она есть в Гугле и других конторах такого уровня.
При этом, у нас по крайней мере, у руководителя департамента есть бюджет из которого он может привлекать внешних сотрудников (аутсорсеров и прочих с галер) в помощь основному контингенту если это нужно.
Я не говорю что она офигительна, мне вот тоже не нравится что мой коллега со знанями и опытом в 50% от моих получает примерно столько же. Но если хочется зарабатывать и у тебя есть что комании предложить — способы для этого тоже есть (консалтинг, контракт и т.д.)
Значит вы с коллегой выполняете примерно одинаковую работу, раз вам платят примерно одинаково. Значит для этой работы нужно ровно половина от вашего опыта, соответственно это не он, а вы не на своем месте.
В конце концов, если вы считаете, что вам мало платят, идите к начальству или другую компанию и просите больше. Вот и всё. Если не дадут больше, то соббсно о чем речь? Вы стоите ровно столько, за сколько можете себя продать.
В том то и дело что делаем мы разное совсем, несмотря на то что должность и уровень одинаковые.
Задачи есть, а должность под них не предусмотрена, поэтому впихнули на ту какая была на те деньги которые я запросил. А внутри уже выяснилось что на тех же деньгах сидят менее квалифицированные персонажи :)
Вы не находите свои слова немного заносчивыми и завистливыми? Вы сами попросили некоторую сумму, вам ее дали, но вам обидно, что кому-то за "более простую" работу платят столько же? Я если честно не знаю исходя из каких критериев вы делаете выводы о меньшей опытности ваших коллег, но даже если предположить, что вы правы — все это не является проблемой для кого-то, кроме вас)
Вы не находите свои слова немного заносчивыми и завистливыми?Я констатирую проблемы данной системы оплаты труда. Когда я работал в РФ такой проблемы не было, несмотря на принятую у нас моду скрывать доходы, но шила то в мешке не утаишь. В итоге я договаривался о справедливом уровне пропорционально моему опыту\знаниям и, соответственно, полезности для компании.
Я если честно не знаю исходя из каких критериев вы делаете выводы о меньшей опытности ваших коллегЯ в этой лодке уже много лет и провел кучу собеседований. Так что определять уровень инженеров, а уж тем более тех с которыми работаю долгое время, немного научился.
все это не является проблемой для кого-то, кроме вас)Абсолютно согласен. Хотя для компании, в лице руководителя департамента, это тоже будет проблемой когда через некоторое я время заговорю о прибавке, а он ее, скорее всего, обеспечить не сможет т.к. политика партии такая. И будут мучительные поиски замены, передача дел и так далее.
В компаниях до 500 человек я просто приходил к гендиру\техдиру\дирдепу, обосновывал свою позицию и получал +ХХ процентов к окладу. В больших конторах это не работает. Это как управлять большой семьей и городом. Разные методы.
Понятное дело что бизнесу выгоднее платить меньше чем больше, но есть еще очень много других факторов. На ИТ рынке сейчас дефицит кадров и будет еще долго, так что компании готовы платить и много. Но если отдать бюджет на откуп сотням менеджеров — будет кумовство и бардак.
В смысле "может быть привязана"? Кем привязана? Это же просто решение людей сколько платить сотруднику. Тот кто принимает решение о найме может иметь не только лимиты, но и личные соображения сколько можно платить сотруднику. Но не существует никакого нормативного документа, ограничивающего ЗП.
В крупных корпорациях вполне себе существует сетка зарплат, за которую выходить ну совсем не разрешают. А про госкомпании вообще молчу.
Поэтому зп Васи и Пети за этот счёт ( а так же за хорошие отношения с начальством / бухгалтерией) может различаться в разы.
… только не твою карьеру
И кто бы могу подумать, мой первый работодатель ну что-то совсем не горел за меня так же сильно, как я горел за выполнение своей работы (т.е. за его проект).
Так что повторюсь еще раз: я бы себе сказал стараться поменьше.
Здравствуйте, у меня сегодня тяжёлый день — пособеседуйте себя сами пожалуйста, а я кофе пока попью. Позовите, как начнёте сам с собой зарплату обсуждать :))))
Собеседуешь человека в core команду разработки графдвижка в геймдеве, и попадаются люди которые искренне не понимают зачемзачем нужны игры :D
P.S. Я уловил ваш троллинг, но меня самого штырит от масштабов
Насколько быстр тот или иной алгоритм вполне понятно по общему представлению. А конкретно сложность сказать — это думать надо.
Ну и в целом пригодность алгоритмов по скорости оценивать не всегда(почти никогда) правильно.
Скажем приходит господин, видит задачу с большим количеством добавлений и удалений элементов. И заявляет, что массив тут никак не годится. Ведь реллокация же! И пишет на связных списках.
И даже вполне быстро. Только код получается хуже.
А ведь можно, например, использовать тот же массив, только запретить ему уменьшатся. Плюс сделать пропорциональное увеличение резерва. У нас тогда за десяток реаллоков массив занимает максимлаьно нужный ему объем и перестает вообще шевелится. А удобство использования остается.
Поэтому правильный ответ на вопрос: сколько времени занимает алгоритм — это «много» или «мало». Потому что детали помнить не нужно, а нужно помнить сложность в попугаях. Сложность всегда можно посчтитать точно уже в конкретной ситуации(ни разу в жизни не приходилось, хотя пару движков достаточно мощных с нуля написал).
Скажем приходит господин, видит задачу с большим количеством добавлений и удалений элементов. И заявляет, что массив тут никак не годится. Ведь реллокация же!
Ну, справедливости ради, массив с постоянной релокацией тут и правда не годится… Хотя это еще не повод связный список использовать.
Если человек не может посчитать сложность стандартных алгоритмов, то он вообще математику не знает — о чем с ним можно говорить? Хотя я конечно видел пару прогеров, которые не знают что такое логарифм и производная, но это были фронтенд, а не графические движки
Что-то я вас не понимаю. Какая разница сложность какого алгоритма считать?
Может вы хотели сказать «помнить сложность стандартных алгоритмов»?
Отдельный вопрос — можете привести пару примеров из движкописательства, где нужны логарифмы?
Движкописательство, это вообще на 99% реализация научных работ середины прошлого века. Если мы не говорим о топ 5 движков, то никаких изыскательных работ не проводится. Если же вы делаете движок не входящий в топ 5, а программист говорит что нужно разработать новый алгоритм — проверьте его квалификацию, похоже он изобретает велосипед.
Речь не о том, что всё уже написано.
Речь о том, что всё уже исследовано.
В топ 5 движков работают в частности и те, кто пишет научные работы.
Все остальные, даже делая уникальные решения лишь компонуют научные работы вот тех ребят из топ 5 и других ученых.
А уж реализовать алгоритм по пейперу много ума(научного) не надо.
Может вы хотели сказать «помнить сложность стандартных алгоритмов»?
Да нет вообще то. Как раз можно и не помнить сложность пузырьковой сортировки (нафиг она нужна), но вот если вы не знаете как ее вывести, то печально.
Отдельный вопрос — можете привести пару примеров из движкописательства, где нужны логарифмы?
Да что уж логарифмы сразу? Мне и квадратное уравнение решать давно не приходилось. Вы бы взяли на работу человека, которые квадратные уравнения не умеет решать? В графических и физических движках есть задачи где и диффуры решать надо.
Если же вы делаете движок не входящий в топ 5, а программист говорит что нужно разработать новый алгоритм — проверьте его квалификацию, похоже он изобретает велосипед.
вплоть до реализации софтверного рендера с поддержкой шейдеров
У вас тут никаких противоречий нет?
но вот если вы не знаете как ее вывести, то печально.
Все алгоритмы считаются одинаково и стандартны и не стандартные.
Вы бы взяли на работу человека, которые квадратные уравнения не умеет решать?
Не решал квадратные уравнения очень давно. Чтобы решить — придется серьезно напрягать память и возможно(о боже) даже лезть в учебник. О чем же это говорит?
У вас тут никаких противоречий нет?
Нет. Софтверный рендер я делал поприколу, в рамках челенджа на gamedev.ru. Посчитал что это будет неплохой проверкой теоретических знаний и в целом будет полезно. И да, я там не изобретал ничего нового с точки зрения науки. Только реализовывал в коде чужие научные работы.
Проводил собеседования про .net лет 10 назад. Тоже спрашивал про сборщик мусора и передачу по ссылке. 20% ответить не могли, в том числе те, кто претендовали на senior.
Вы считаете что senior вообще не должен понимать как работает сборщик мусора? Как тогда он будет проблемы с быстродействием и перерасходом памяти решать?
Я про такое и не спрашивал никогда. И если честно не понимаю о чем речь.
Вы же читали статью к которой пишете комментарии. В ней вопросы которые часто встречаются на собеседованиях и зачастую в них есть вполне практический смысл.
Конечно я не прав.
Видимо надо было нанимать философов, которые умеют рассуждать об ООП. Но мне нужны были люди, которые пишут код и понимают как этот код работает.
Вопросы про сборщик мусора был вообще первым в списке, потому что именно он показывает понимание человека что происходит "под капотом". И в ответ на этот вопрос многие могли "развернуться" очень сильно.
А вот холиваров в команде на тему "хорошо или плохо" я не допускал. Поэтому филосовствование мне было не нужно.
Потому что вы рядовой разработчик, а руководителю нужно чтобы работник в первую очередь умел делать. Если брать тех кто все время думает, то делать будет некому.
Насчет долгосрочной перспективы вопрос сложный. Долгосрочная перспектива это когда проект закроется и всех уволят. Поэтому нужны успехи в первую очередь в перспективе краткосрочной.
Поэтому нужны успехи в первую очередь в перспективе краткосрочной.
Простите за мои 5 копеек:
Когда гонятся в первую очередь за «ближними» (краткосрочными) целями, на выходе высокий шанс получить «макаронного монстра», которого потом поддерживать нет никакой возможности.
Моя позиция — в первую очередь задавать «долгосрочную перспективу». «Краткосрочная» должна подчиняться «долгосрочной». И иметь возможность эту самую «долгосрочную» корректировать.
Тогда мы имеем некий «план» и «решение в рамках этого плана». А не «шашки наголо и вперед на танки-окопы».
P.S. Я из Java мира и с .net дел не имел. Но у меня особо что-то думать на счет GC не то чтобы приходится.
Есть +- стандартные области видимости объектов. Есть их использование.
Если объект висит в памяти (используется) — GC его не трогает. Передаем по ссылке — объект продолжает использоваться и его GC не будет собирать. Если передали и клонировали, а не передали дальше, то оригинал более не используется и будет убран сборщиком. И с ходу в голове нет каких-то ситуаций, где было бы иначе (и возникали бы трудности).
Простите, какие-то общие слова, за которомы я не вижу конкретики.
Мой опыт говорит, что если все плохо в краткосрочной перспективе (нечего показывать на ближайшем демо), то и в долгосрочной будет все плохо, чего бы программисты не рассказывали.
А чтобы в краткосрочной было хорошо нужны люди которые умеют делать "сейчас", причем довольно толковые. Иначе, как вы сами говорите, получится "макаронный монстр".
У меня многократно такое получалось, когда было слишком много думателей в команде. Поэтому хороший специалист это не тот, кто можно пространно рассуждать об ООП, TDD, DDD, ADBC, EJB и АБВГД, а тот кто может взять и сделать то что будет работать.
PS. Ну вот у вас понимание как GC работает. И я был уверен что 100% программистов это расскажут, так как были не джуниоры. И очень удивился когда 20% не смогли.
нечего показывать на ближайшем демо
Эм… допускаю, что чего-то не догоняю, однако на моей практике это словосочетание могло обозначать ровно то, что собственно и написано.
Однако! Во временных единицах измерения тут, кхм, может быть что угодно: как «условный месяц», так и «через 15 минут созвон с заказчиком».
К чему это я — если счет идет на человеко-часы, то пахнет паленым и «дело труба». А если условный чекпоинт через ту же неделю, то ничего плохого не вижу в том, чтобы какое-то кол-во разработчиков вместо «написания кода на скорость в ИДЕ» взяли и минут 10 обсудили между собой, как:
«Будем прикручивать этот функционал… это будет отдельный модуль (с точки зрения проекта) или находиться внутри другого (уже существующего) модуля? Если отдельный модуль, то „как сервис“? Кто считает какое API необходимо этому модулю, может есть пожелания?»
Т.е. вот о чем я веду речь — о хорошей (в моем понимании) командной работе, когда коллеги по проекту хотя бы +- условно в курсе того, что делают остальные. Чтобы потом не было конфликтов «а я не знал, что Валера сделает это же самое, но во-о-о-н там».
UPD: И да, мой опыт говорит, что конструктивные быстрые переговоры вполне продуктивны, если при том же запуске проекта было капитальное обдумывание «общей схемы». Чтобы во время быстрых переговоров можно было опереться на «базовые договоренности в проекте».
Я уже давно работаю с фиксированными итерациями (аля скрам), поэтому краткосрочная перспектива это одна итерация (неделя-две). Среднесрочная — один релиз (месяц-два, изредка три), долгосрочная — полгода-год или более, обычно совпадает с длительностью проекта.
Людей всегда подбирал в первую очередь по умению укладываться в сроки итерации. Когда надо в рамках недельной итерации сделать 2-3 задачи, причем так, чтобы было что показать, то времени на работу "на долгосрочную перспективу" не остается.
Причем можно так фигачить с самого начала проекта. А потом просто рефакторить в случае чего. Но это уже вопрос кому как комфортнее. К вопросу найма не имеет отношения.
Человеку для решения задач необязательно понимать как под капотом устроена та или иная фича.
Я занимаюсь обработкой изображений. И могу сказать, что коллеги и падаваны, которые просто используют билиотечные функции без чёткого понимания, как алгоритмы устроены внутри, не способны ни провести оптимизацию параметров, ни ускорить алгоритм, ни реализовать что-то своё.
Если человек не имеет глубоких познаний в своей сфере, то senior-ом он ну никак быть не может.
через пару недель взяли в другую компанию. В первые дни сказали, что по проекту задач нет — но хотели бы, чтоб у всех был докер настроен для dev. За 2-3 дня — настроил, так_чтоб_работало — команде нормально. :)
т.е. цена вопроса 2-3 дня.
Я долго думал, кто потерял больше:
— я, который мог бы потратить 3 дня и изучить/сделать что_то
или
— компания, которая из-за узких вопросов отшивает кандидатов
пока ответ не нашел
А вы уверены, что отказ был именно из-за того, что вы докер никогда не настраивали? Просто выглядит такая причина очень странно.
Ну и, возможно, у той компании именно тогда была необходимость в хорошей экспертизе по докеру?
Очень может быть, что им нужен был именно докерист.
Про странность причин — это им решать.
А вообще, в институте нам все время твердили — важно не знать «методические данные или алгоритмы», важно знать что они есть и где их можно найти.
А вот такие вопросы из серии, что написано на 50й строке в таком-то файле такого то фреймворка задавать смысла ноль!
Вы утирируете. Здесь имелись в виду основные принципы работы, которые senior знать должен.
Да хрен с ним наизусть, люди даже базовые вещи не могли рассказать:
1) Как определяет что мусор, а что нет (в общих чертах)
2) Как убирается мусор (в общих чертах)
3) Зачем нужны поколения
Никогда не требовалось пересказывать CLR via C#, но довольно большой процент пересказывал, с пониманием дела.
Так можно о чем угодно сказать… Получается на собеседовании вообще ничего спрашивать не надо? Сразу тестовое задание давать?
В целом если кандидатов мало, то можно и так.
А тестовое действительно зачастую перекрывает то, что спрашивают на собесах.
Вопрос, на самом деле, животрепещущий, т.к. у нас еще нет лакмусовой бумажки для отделения хороших кодеров от плохих на собеседовании. Например, даже если человек тупит в ответе на вопрос про сборщик мусора, где гарантия, что его просто утром не стукнуло по башке и он грандиозно тупит? Опять же, с другой стороны, сборщик писался как раз для того, чтобы программист не вникал в тонкости работы этого сборщика. Что если тех самых бутылочных ситуаций не случится и человеку не пригодятся знания? Ну и наконец: как понять, что человек не сможет ими овладеть в приемлемый срок в случае их необходимости? Тот же GC штука не шибко сложная в своем принципе и почесать доку по фразе «c# app performance problem», наткнуться на предложение оптимизировать мусор во имя справедливости и почитать о том что такое этот сборщик можно минут за 20. Возникает вопрос: так ли существенны эти 20 минут, что вы заворачиваете из-за них кандидата?
Мы точно программистов нанимать хотим? Не философов? Зачем программисту навык аргументировать?
Или речь про вопросы в духе "сколько мячиков для гольфа влезает в автобус"?
У вопросов в духе "сколько-чего-куда" есть вполне определенный смысл — проверить умение давать численные оценки при очень малом наборе априорных знаний. Это очень полезны навык для программиста если что. Но не ключевой.
Даже у вопроса про гору фудзи есть смысл, хотя все ругают эти вопросы.
А вы какие вопросы имеете ввиду?
Практика давно показала что ответы на "вопросы без правильного ответа" не имеют отношения к навыку написания кода. Да и в целом "результат интервью не влияет на продуктивность сотрудника".
Поэтому все что вы можете проверить — минимально необходимый набор знаний и навыков.
Например, даже если человек тупит в ответе на вопрос про сборщик мусора, где гарантия, что его просто утром не стукнуло по башке и он грандиозно тупит?
Так он на любой вопрос будет тупить. В этом случае не надо тратить время ни соискателя, ни интервьюера.
Опять же, с другой стороны, сборщик писался как раз для того, чтобы программист не вникал в тонкости работы этого сборщика.
Вы путаете детали и принципы. Детали не спрашивал никогда, принципы нужно знать всем, кроме совсем джуниуров. Но джуниуров я не набирал никогда.
Ну и наконец: как понять, что человек не сможет ими овладеть в приемлемый срок в случае их необходимости?
Никак, мне нужны люди которые сразу будут разбираться что происходит под капотом.
Возникает вопрос: так ли существенны эти 20 минут, что вы заворачиваете из-за них кандидата?
Конечно, если кандидат предполчел не тратить свои 20 минут на то, чтобы подготовиться к собеседованию, то он не сильно нужен.
Мы точно программистов нанимать хотим? Не философов? Зачем программисту навык аргументировать?Придут так ваши сеньоры проект делать, да не смогут определиться со стеком технолоигий просто потому, что каждый гнет свою линию, а аргументировать почему вот именно их решение подойдет в данном конкретном случае не могут. И ответсвенному за проект тоже не понятно на основе чего принимать решение — собрались здоровые высокоуважаемые дяди и неаргументированными мнениями сыпят.
А вот джуну действительно навык аргументации не очень важен. Джун-же, считается что ничего не знает, поэтому часто получается что он работает с тем, что старшие товарищи сказали, и так, как они научили.
Конечно, если кандидат предполчел не тратить свои 20 минут на то, чтобы подготовиться к собеседованию, то он не сильно нужен.А вы вопросы на зачет заранее высылаете, или угадывать надо? Странно, из универа я вроде уже выпустился, а к зачетам и экзаменам все еще надо готовиться.
Вы путаете детали и принципы. Детали не спрашивал никогда, принципы нужно знать всем, кроме совсем джуниуров. Но джуниуров я не набирал никогда.Ок. Принцип работы GC — он чистит оперативу от мусора. Мусор это то, на что в программе не имеется ссылки. Остальное детали. Но вы ведь не такого ответа ожидаете.
Вообще у меня странное ощущение, что вы задаете сеньору те вопросы, которые следовало бы спрашивать у джуна.
Да и в целом «результат интервью не влияет на продуктивность сотрудника».Тогда возникает ровно один вопрос: зачем проводить интервью?
Или речь про вопросы в духе «сколько мячиков для гольфа влезает в автобус»?Это другая крайность одного идиотизма. Вот кабы программисту поставили задачу написания алгоритма расчета числа этих мячей, помещающихся в упрощенную модель автобуса (например, заместить автобус параллепипедом) и предложили накидать в общих чертах алгоритм, тогда это было бы как минимум познавательно в отношении кандидата.
Обратить внимание имеет смысл на следующие вещи:
- как кандидат начинает решать задачу, т.е. с чего он начинает проектирование
- какие инструменты (алгоритмы) кандидат решает использовать
- какие вещи вызывали у кандидата сомнение
Это позволит как минимум составить впечатление о его стиле работы, что важно если вы вписываете его в команду. Об остальном скажет послужной список в резюме.
Вообще странная ситуация. Когда был джуном, меня спрашивали о том, как бы я построил такую-то систему, как бы решал такую задачу. А когда стал наниматься на мида, пошли задачки из разряда «два стула; на какой сам сядешь, на какой код посадишь». Я как-то не так в хату зашел что ли?
Не понимаю зачем аргументировать. Если решение А лучше Б, то оно должно быть:
1) меньше
2) написано быстрее
3) содержать меньше ошибок
Это объективные параметры (и связанные на самом деле). А философские аргументы субъективны и по большому счету не нужны.
А вы вопросы на зачет заранее высылаете, или угадывать надо?
Если всем заранее высылать вопросы, то они быстро попадут в разряд зазубренных. Мы предполагали что человек пришедший на позицию Senior .NET developer (web, asp.net, sql server) достаточно хорошо знает .NET, чтобы поддержать разговор о GC, структурных и ссылочных типах, использовании dispose, а также имеет базовые хотя бы базовые представления об ASP.NET (тогда еще web forms), http протоколе и базах данных.
Для начала было 10 вопросов по этим темам и первый про GC. Это как скрининг, имеет ли смысл дальше с человеком разговаривать. Большинство вопросов были такие, что можно было рассказать и мало, и много. Где-то даже пофилосовствовать. При этом совершенно необязательно было отвечать на все 10 правильно, если хотя бы половину человек осиливал, что уже мог претендовать на Senior с соответствующей ЗП.
Странно, из универа я вроде уже выпустился, а к зачетам и экзаменам все еще надо готовиться.
Собеседование = продажа, готовиться надо. Откуда работодатель узнает что вы ценный сотрудник если не сможете доказать?
Ок. Принцип работы GC — он чистит оперативу от мусора. Мусор это то, на что в программе не имеется ссылки. Остальное детали. Но вы ведь не такого ответа ожидаете.
Дальше будет вопрос как GC определяет что такое мусор. Важно чтобы человек сказал о достижимости объектов в куче. Это дает понимание что время работы GC пропорционально количеству ЖИВЫХ объектов, а также о механизмах утечек памяти в .NET.
Потом будет вопрос о том как чистится память, важно чтобы человек понимал что программа останавливается в это время, также чтобы понимал, что куча "сжимается", чтобы обеспечечить работу выделения памяти путем приращения указателя.
Потом вопрос про поколениях, который проверят насколько человек понимает что в .NET память зачастую лучше освободить быстрее, чем держать дольше.
Вообще у меня странное ощущение, что вы задаете сеньору те вопросы, которые следовало бы спрашивать у джуна.
По вашему сеньор не должен знать то, что должен знать джун? Вы как себе это представляете? Программисты со временем тупеют?
Тогда возникает ровно один вопрос: зачем проводить интервью?
Очевидно чтобы проверить что человек может выполнять те обязанности, которые на него возложат.
Это объективные параметры (и связанные на самом деле). А философские аргументы субъективны и по большому счету не нужны.
Это правила для джунов и мидлов. Сеньоры и архитекторы должны думать на несколько шагов вперёд и не расставлять подпорки максимально быстрыми способами, а искать решения, чтобы эти подпорки не стали костылями.
Потом будет вопрос о том как чистится память, важно чтобы человек понимал что программа останавливается в это время
Вы всё ещё пишете под .NET 2.0? Сейчас сборка мусора стала намного сложнее.
По вашему сеньор не должен знать то, что должен знать джун? Вы как себе это представляете? Программисты со временем тупеют?
А вы что, помните все-все-все вещи, которые сдавали в университете на экзаменах?
Знание назубок академических вещей (определения, алгоритмы, методы, технологии) не равно умению применять их на практике.
Например, джун может сходу выдать определение виртуальной функции, может сходу ответить, чем класс отличается от структуры. Но понимания всего этого у него может и не быть. Например, для джуна нормально вызывать виртуальную функцию из конструктора, нормально для работы с изображениями использовать для пикселей ссылочный тип (и пофиг, что стало на порядок медленее и на порядок больше памяти уходит).
А вот спроси сеньора, который успешно справился с несколькими сложными проектами, что такое виртуальная функция — он задумается. Для него это все равно что попросить дать определния словам "рука" или "спать".
Вы считаете что сеньоры и архитекторы не должны знать того, что знают джуниоры? Как тогда код-ревью делать?
Если вы не читали тред, то повторю, что я задавал такие вопросы 10 лет назад. Если быть точным, то 11 лет назад — в 2008 году. И сборка мусора с тех пор не поменялась в общих чертах. А те детали, которые изменились никогда не спрашивал на собеседовании.
Все что сдавал на экзаменах конечно не помню, потому что очень мало применял из того что сдавал. Но когда писал на .NET понимание деталей работы GC пригождалось очень часто, и жизненный цикл ASP.NET веб-страниц нужен был постоянно, и а уж детали HTTP и T-SQL даже сегодня помню. Слишком часто использовал.
Причем у меня в команде были разработчики, которые могли и не зная всего этого писать, а мне приходилось постоянно исправлять за ними.
У меня есть стойкое убеждение, что справиться с перерасходом памяти и низким быстродействием из-за этого без понимания принципов работы GC будет крайне сложно. Проверить это умение в условиях собеседования почти нереально, но проверить необходимые знания вполне можно.
PS. В .net совершенно безопасно вызывать виртуальный метод из конструктора, особенно если вы понимаете что делаете.
Вы считаете что сеньоры и архитекторы не должны знать того, что знают джуниоры? Как тогда код-ревью делать?
Вещи, которые не используются, забываются. Да, сеньор не должен знать определение виртуальной функции, но должен глубоко понимать принципы работы со всеми нюансами. Код-ревью это не мешает.
Просто собеседование зачастую выглядит как экзамен: спрашиваются вещи, которые потом не будут использоваться.
PS. В .net совершенно безопасно вызывать виртуальный метод из конструктора, особенно если вы понимаете что делаете.
Да, вызвать можно, он даже правильно вызовется. Но вот незадача: конструкторы дочерних классов ещё не будут выполнены, из-за чего поля объекта будут частично неинициализированы.
Никогда не спрашивал на собеседованиях то что не будет использоваться. Всегда тупо времени жалко было на это. В том числе никогда не спрашивал про виртуальные методы, потому что в реальных проектах не доводилось создавать сложные иерархии классов.
Что касается вызова виртуальных методов из конструктора, то в .net поля класса инициализируются в начале конструктора, то есть на момент вызова метода дефолтный значения полей уже присвоены.
Так что если знаешь что происходит, то это безопасно.
Что касается вызова виртуальных методов из конструктора, то в .net поля класса инициализируются в начале конструктора, то есть на момент вызова метода дефолтный значения полей уже присвоены. Так что если знаешь что происходит, то это безопасно.
Вот именно что проинициализированы значениями по умолчанию (если нет in-place инициализаторов). Обращаться к ним безопасно, но вот значения по умолчанию — это не то, что хочется в них видеть.
Так делайте inplace, в чем проблема? Важно что есть детерминированное поведение в этом случае, поэтому зная детали (от знания которых некоторые хотят увернуться) можно без опасности вызывать виртуальные методы в конструкторе.
В отличие от C++, где вызов виртуального метода в конструкторе практически UB.
Собеседование = продажа, готовиться надо. Откуда работодатель узнает что вы ценный сотрудник если не сможете доказать?
Мы точно программистов нанимать хотим? Не философов? Зачем программисту навык аргументировать?Я ценный специалист, или философ? Зачем мне аргументироать свою ценность?
По вашему сеньор не должен знать то, что должен знать джун? Вы как себе это представляете? Программисты со временем тупеют?Нет, просто программисты перестают держать такое в голове. Зато в голове набирается куча абстрактных механизмов, помогающих решать реальные задачи. Это как со школой, например. Классе в пятом все знают доказательство теоремы пифагора потому что учить заставлют. А потом человек забывает его потому что само посебе оно не нужно, а место занимает.
Очевидно чтобы проверить что человек может выполнять те обязанности, которые на него возложат.Судя по набору ваших вопросов у вас для этого тестовое задания прекрано должно подойти. Предложите написать человеку «молотилку данных» и посмотрите как он с памятью работает без всяких магических определений. Потом задайте 1-2 вопроса по этому тестовому на интервью. Ну или не 1-2 если угодно.
Я ценный специалист, или философ? Зачем мне аргументироать свою ценность?
Как "покупатель" о вашей ценности узнает?
Нет, просто программисты перестают держать такое в голове. Зато в голове набирается куча абстрактных механизмов, помогающих решать реальные задачи.
Что за абстрактные механизмы и какие задачи они помогают решать?
Как проверить наличие этих абстрактных механизмов в голове на собеседовании?
Судя по набору ваших вопросов у вас для этого тестовое задания прекрано должно подойти.
Оно прекрасно и подходило. А вопросы в начале — скрининг, стоит ли вообще человеку давать задание, обладает ли он знаниями, чтобы решать те задачи, которые на него будут возлагаться.
Предложите написать человеку «молотилку данных» и посмотрите как он с памятью работает без всяких магических определений.
В этом и проблема. Дать достаточно большое тестовое задание нельзя, а в маленьком проверить навык решения проблем с расходом памяти нельзя. Поэтому проверяли знания.
Сейчас перешли на другой способ. Просто даем реальную задачу. Часов на 20. Человек делает — оплачиваем, делает лучше всех — берем на работу.
Но тогда отсев огромный. Из 10 довольно толковых специалистов только один нашел время сделать, и то он оказался не супер-работником.
1) Один проживаете?
2) Долго с девушкой?
3) Куда отдыхать поедите?
4) А Вам что больше нравится?
5) Сколько лет готовы проработать в нашей компании?
6) После тестового и двух собеседований нужно пройти психолога, это обязательно.
Сам недавно сталкивался с такими вопросами, впечатление от интервью осталось негативное.
Правильные ответы:
1) Не ваше дело.
2) Не ваше дело.
3) Не ваше дело.
4) Не ваше дело.
5) Если компания будет меня устраивать, а я компанию — много.
6) Не вопрос.
7) Можете не перезванивать.
У меня тоже однажды спросили про религию. Я не выдержал, и спросил, нахрена им это знать. В ответ они рассказали историю о том, как у них сотрудник буддист пришёл и потребовал отпуск, чтобы слетать куда-то там в Азию на свой буддистский ивент. Его не отпустили, после чего он плюнул и всё равно улетел. После этого они берут только христиан и атеистов. Буква Г — логика.
Хотя бы понятно, что «мозги промывать не собираются» и сам вопрос +- обоснован интересами организации (а не чтобы завалить под надуманным предлогом).
Не знаю, у меня в этот возник вопрос, а адекватны ли они там вообще. Уж не говоря о том, что это совершенно незаконно. Кстати, это была не обычная контора, а центр специальных разработок МО РФ.
совершенно незаконно
Эм, я конечно по профессии «педант», но в целом, в жизни… может быть конечно вы и правы, спорить не буду.
Однако, если провести параллель с реальным миром, скажем отношения между м/ж, лично я за то, чтобы «на берегу», заранее, все скользкие моменты обговорить, а не «связаться с кем-то, а потом страдать от проблем».
Серьезно, смотрите сами — если вас не стали как-либо обижать, унижать или еще делать какие-либо неприятные действия в ваш же адрес… а напротив, сразу объяснили, что было такое недоразумение и больше они со своей стороны с определенными лицами не имеют желания работать… вот разве нужно «назло» лезть в такое место, если оно вам не подходит?
По-моему все напротив, прекрасно, когда открыто и честно люди могут произвести взаимо-оценку.
Во-первых, я не буддист. Был бы я буддистом — у меня возник бы вопрос, какого меня обобщают с человеком, который поступил не очень адекватно по, в общем-то, совершенно не связанным с религией причинам.
Во-вторых, они это обобщили ещё и на остальные религии, кроме христианства. Тут вообще логика даже близко не просматривается.
В-третьих, они прямым текстом сказали, что дискриминируют людей по религиозному признаку. Казалось бы, в такой вещи должно быть как минимум стыдно признаться, но не им.
Как я и сказал, проблема не в том, что они лично меня чем-то задели. А в том, что они создали у меня ощущение неадекватных людей, с которыми дела лучше не иметь.
вот разве нужно «назло» лезть в такое место, если оно вам не подходит?
Ну, я и не стал лезть) Это было единственное собеседование, с которого я просто встал и ушёл.
По-моему все напротив, прекрасно, когда открыто и честно люди могут произвести взаимо-оценку.
Ну, всё же, есть критерии, по которым взаимооценку производить не принято, как то: раса, вероисповедание, пол. Или хотя бы молчать о том, что она производится.
Или хотя бы молчать о том, что она производится
Ряд представителей одного этноса открыто в свое время говорили мне, что «таким тут не место». Что же, как говорится, «если тебе тут не рады, то незачем оставаться» — я и мигрировал.
Я понимаю, что о чем-то на 2019-й не принято говорить. Однако, опять же лично мне, куда комфортней, когда все карты кладут на стол открыто, чем где-то и как-то «за глаза»/«за спиной». А могут и «козни» всячески твориться.
Так что, лучше так.
P.S. При прочих равных я, аналогичным образом, так же имею список критериев, которые с моей стороны в крайней степени не приветствуются. И если у каких-то людей они есть — предпочту ничего общего с ними не иметь. И да, ряд критериев опять же «порицаем».
Однако, если мне крайне неприятны какие-то критерии, то зачем мучать себя и «того, другого человека»? Лучше никому никаких проблем не создавать — сразу понять несовместимость и разойтись. Без оскорблений или других проблем.
В большинстве же компаний программисты общаются между собой, и если человек выглядит или ведёт себя не так как все — то ему и самому в такой компании будет тяжело работать, и остальным тоже с ним будет тяжело работать. При этом он, вполне возможно, отлично бы влился в другую команию, где, наоборот, человек с девушкой, детьми и кошкой выглядел бы чужим.
Речь про отсеивание людей, с которыми просто нельзя общаться, про отсеивание неадекватов. Никто не требует точного ответа на вопрос «что делаете в свободное время» или что-то там про девушку — кому это интересно-то? Задавая такие вопросы, смотрят на то, как человек в принципе реагирует на нестандартную ситуацию, на потенциально конфликтную.
Абсолютно согласен, странно что заминусовали. Общая адекватность, да и общие ценности с коллективом очень важны, даже важнее чем технические навыки. Толку то от навыков человека, если у него нет девушки, потому что он гамает или бухает все свободное время, например?
Видел я гиков, уехавших в психушку и угрожавших коллегам ножом и там по личной жизни все понятно.
Главное спрашивать корректно, а не это ментовское "с кем проживаете?" :)))
Знаю лично людей, которые живут одни и гамают по вечерам — у них с профессиональными навыками все в порядке.
Толку то от навыков человека, если у него нет девушки...
Вот вы сейчас прямо обесценили мою работу за последние 5 лет, надо рассказать начальству о том, что они заблуждаются, а то я собрался работу менять, а они уговаривают остаться)))
А потом выясняется, что там ни девушки, ни детей, ни кошки, ни друзей и «не зовите меня никуда»
А что если кандидат — гей-интроверт и любит собак? Он, получается, вам не подходит?
нужно много ментальных ресурсов и терпения потратить, чтобы выстроить процессы, начинаешь осознавать также и важность soft-skills и психологических качеств работника
Человек может быть очень компетентен в своей сфере, но чтобы эти компетенции разбудить, затрахаешься искать подход
второй случай. Выходит отдел тех поддержки на работу в понедельник. Ни один компьютер в отделе не включается. После вскрытия оказывается, что внутри каждого не хватает то проца, то памяти, то видео. Разборки. Оказалось один замкнутый сотрудник вышел на выходных поиграть, и решил собрать себе лучший комп, для чего разобрал все компы отдела. Собрать забыл. Все время пока техподдержка авралила, он сидел рядом слушал музыку.
Надо ли говорить что созданные проблемы в авральном режиме решали программеры, техники, в общем люди, чьи должностные обязанности только смежные с этими сотрудниками?
Это я к тому, что люди, минусующие за требование базовой социальности не догадываются насколько эта несоциальность может быть глубока. Они думают что в их личную жизнь собираются лезть, а по факту такой сотрудник портит эту личную жизнь всему отделу, переводя ее в непереходящий аврал
Это вы примеры не асоциальности привели, а раздолбайства.
Почти эталонные ответы для такой!
Рекрутер (технарь): «Вам знаком термин „длинный метод“? Что это такое?»
Я: «Да, знаком, этот метод не помещается на мой экран целиком, приходится прокручивать»
…
Р: «Наш метод близок к экстремальному программированию»
Я: «Это плохие новости, я не отношу себя к экстремистам»
Распрощались, конечно.
С другой стороны бывает обидно, когда после выполнения тестового задания тебе без объяснения причин дают отлуп. Но если задание непростое и интересное — то вообщем то и не так обидно.
Опыт работы от 50 лет.
Вы должны победить дракона.
Ненормированный рабочий день.
Наличие прав на управление вертолетом.
Умение программировать на всех возможных языках.
Знание языка суахили не ниже уровня upper intermediate.
Расширение клиентской базы на 100500 человек в день.
Знание основ термоядерного синтеза.
Опыт в организации концертов Бориса Моисеева в Дагестане.
Уверенное использование телекинеза в рамках компетенции.
Большая концентрация мидихлорианов в крови.
Наличие золотой или серебряной медали с одной из олимпийских игр.
Наличие собственной базы клиентов.
Наличие нобелевской премии по физике как плюс.
Мы предлагаем:
Стул, кипяток.
Комфортабельный офис в здании заброшенной психбольницы напротив кладбища.
Висит у меня резюме на одной площадке. Приходит в Вайбер сообщение:
Нужен на проект middle php-разработчик. Проект на Yii2. Вот тестовое задание. Сделаешь — напишешь.
Ни кто такие, ни что за проект, ни что предлагают… Никакой информации вообще.
Обычно, такие сообщения просто игнорирую. Собственно, так поступил и с этим.
Но вот дней через пять мне нечего было делать. И я полез посмотреть на это задание.
Задание оказалось достаточно простым. Я от нечего делать его написал. Ну и раз уже сделал, то почему бы не отправить.
Примерно через неделю перезванивает некий, назовём его Боба. С которым у нас состоялся примерно следующий диалог.
— Боба: Ты выполнял для нас тестовое задание. Готовы взять тебя на работу. Предлагаем fulltime удалённо, ЗП — 7000 грн. Приступить нужно вчера.
Стоит отметить что по ощущениям Боба звонил где-то из бункера, т.к. связь была отвратительной. И я решил что я просто не расслышал. И на самом деле прозвучала сумма 27000.
— Я: Вчера не получится. Я сейчас работаю. И даже если я соглашусь на ваше предложение, то мне понадобится некоторое время, чтобы завершить все дела на текущей работе.
— Боба: Нам требуется программист срочно. Но мы согласны на вариант, чтобы ты уделял нашему проекту несколько часов в день, пока полностью не перейдёшь к нам.
Потом поговорили немного о стеке, о проекте.., о прочих требованиях. К слову, требования были достаточно серьёзные.
— Я: Хорошо, я подумаю. Давайте подведём итоги. Вы предлагаете удалённую работу fulltime и ЗП 27000 грн в месяц. Верно?
— Боба: Нет, 7000, а не 27000.
— Я: Прошу прощения, мне послышалась сумма 27000. И вы серьёзно надеетесь найти middle-разработчика, обладающего всеми необходимыми навыками, на полный рабочий день 8 часов за 7000 в месяц?
— Боба: А че, нормальная ЗП. Только мы требуем fulltime, а не 8 часов.
— Я: А fulltime и полный рабочий день — это разные вещи?
— Боба: под fulltime мы подразумеваем именно fulltime. Ты должен быть в нашем распоряжении 24 часа в сутки.
После чего я сказал, что это называется рабство, а не fulltime и положил трубку.
— Что такое “SOLID”?Хах. Вопрос с которого я валю интервью.
— “Твердый”, реже — “сплошной”. Зависит от контекста, конечно.
Дуб, акация, клен, вишня
То самое место когда улыбка больше не сходит с лица.
Скажем так, достигнув некого определённого уровня, можно повыбирать из компаний, которые находятся ниже или на одном уровне с тобой. И разнообразные рычаги есть с обеих сторон, как и возможность, скажем, не пройти испытательный срок для компании тоже (а не только для сотрудника)
И повелел Господь: «собеседуйтесь и принимайте офферы»