Есть набор компаний, у которых входной порог на собес — решение алгозадач, далее идет дизайн секция, на которой за 3часа делают фейцбух, ютуп и прочие известные сервисы, которые писали тыщи людей и сами же эти сервисы претерпевали несколько стадий эволюций.
Предисловие:
К собесу надо готовиться. Для чего? Почему? чтобы что? Если человек может подготовиться к собесу, то его практические навыки нафиг не нужны на этой работе и можно нанимать в принципе любого, кто прослушал курс Х или же сам его изучил.
Алгозадачи.
Алгозадачи демонстрируют лишь умение решать эти самые задачи, т.е. даже хардовая задача на литкоде, пусть занимает день, это не равно тому, что делает человек на проекте хотя бы пол года, это совсем разные измерения. Алгозадача какой-то миг, решение проблем на проекте это краткосрок или долгосрок в зависимости от ситуации.
Нормально, если дают алго-задачи, тогда, когда этого требует предметная область: базы данных, движки поисковых систем, хитрая маршрутизация и т.д. когда в принципе неважно знание фреймворков и технологий, достаточно знания языка, исполняемой среды и стандартной библиотеки.
Дизайн интервью
Этот кейс более приближен к реальности, но когда дают запроектировать фейсбук или ютуб за 3 часа, то какой смысл давать такое, если человек не будет писать этот фейсбук, а даже если и будет, то будет писать 3-4 сервиса.
Реальность
Я не совсем понимаю что компании проверяют, более того в инете куча всяких каналов по разбору задач, по разбору сисдиз интервью. Т.е. человек, который банально поднатаскался с не очень релевантным опытом может вполне пройти собес.
И вот тут у меня закрадывается сомнение: сложность разработки по сути миф, достаточно взять любого человека, который может просто писать код. У больших IT компаний денег столько, что можно нанимать в принципе кого угодно кто проходит стартовый фильтр. Получается так, что ФААНГ действуют как картель, компанию с сильными спецами и готовым хорошим решением дешевле купить, чем писать такое у себя с нуля.
Мои собесы
За всю жизнь было собесов штук 20 наверное, года 1,5 назад собесился в амазон и завалил первую или вторую задачу литкода, до этого литкод не решал вообще никогда, хотя при этом писал фрейморки, продукты, плюс минус разбираюсь в инфраструктуре как в виндовой, так и в линуксовой, немного сетей и т.д. Наводил порядок в нескольких проектах(успещная борьба с лютым легаси и тех долгом + кривыми процессами), что менеджмент просто забывал о том, что такой проект есть.
Видимой такой опыт сейчас в принципе не интересен.
Потом я кстати начал решать литкод, в этом есть некоторый плюс и фокус с ООП языков (преимущественно на которых писал я) смещается в сторону алгосов в них абстракции несколько иные, но никуда не деваются, но в работе мне это точно не помогает.
Разве что может базу или распределенный кэш какой свой написать, но опять там уже все придумано до нас, только прочитать, переварить да применить.
По другую сторону баррикад
Сейчас сам являюсь интервьювером по этим же самым алгозадачам, и вот если человек готовился и решал — то он их возможно решит, при этом бывают норм кандидаты(15 лет опыта во всяких ынтерпрайзах), где основная сложность не в алгоритме, а в понимании того, как весь этот зоопарк работает, то его даже не рассматривают. При этом позиция писать плюс минус такой же ыинтерпрайз с перекладыванием жсонов, в базенках там поковыряться, с людьми пообщаться. На возражения, что задачи не нужны, руководство упорствует.
да еще при помощи литкода неплохо учить язык, недавно чет на Си проперло, вот для этого литкод вполне себе хорош.
Идеальный собес
Вообще идеальный собес это когда готовятся 2 стороны, я в принципе всегда и пытаюсь так сделать.
1) Понять сильные и слабые стороны кандидата, как технические, так и психологические
2) Определить как и что из этого можно использовать у себя на проектах
3) Понять подходит ли компания человеку, его ожиданиям, целям в развитии и т.д.
Сформировать область пересечения интересов.
Эпилог
И вот еще мысль была, почему-то все хотят стандартизировать процесс найма, но при этом не видел, чтобы выстраивали культуру найма. Условно вот чел, который умеет отбирать людей и после него %% людей которые работают эффективно в компании выше, чем у всех остальных, так давайте поучимся у него. Вместо этого собес формализуют в этапах, чтобы чуть ли не обезьяна могла прособесить по методичке, но раз можно прособесить по методичке, то опять таки нанимаем по шаблону и что-то может в шаблон и не пролезет
On Jul 16, 2024, 10:46 AM, diez_p <81585@users.rsdn.org> wrote:
DP>И вот когда дают такое на собесе и ожидают, что?
Задачи — это всего лишь следствие конкуренции на рынке труда. Не ищите здесь никакой рациональной подоплеки. И тем более, недоумевать по поводу того, что на работе "формошлеперство", а на собеседование тебя тягают от дизайна архитектуры до задач и обратно. Когда инженеров разработки была нехватка, то готовы были брать любого с улицы без собесов, который прочитает "We are hiring" в ASCII на рекламном щите или знает ответ на "как сдвинуть гору Фудзи". Сейчас конвеер. Тебя выжимают 2-4 года, затем твое место занимает такой же клон тебя 2-4 года давности. Клон с такими же ожиданиями и иллюзиями. И все по кругу.
DP>А если человек заучил и повторил решение, то какую проблему он сможет решить?
Аналогичную проблему. Конечно, в том числе и по этой причине тесты IQ и убрали как инструмент измерения уровня интеллекта. Потому что обнаружили, что результат у человека который проходил логическую часть тестов резко выше при повторном прохождении этих тестов. Человеческий мозг легко делает аналогические конструкты, гораздо хуже ему синтезировать новые.
DP>В последнее время стал больше интересоваться в том числе историей математики, чтобы понять ход мыслей тех, кто решал какие-то проблемы впервые. На текущий момент найти готовое решение в принципе не составляет труда, важно уметь синтезировать оптимальное решение при текущих обстоятельствах.
Имхо, самая важная черта инженеров разработки найти оптимальное решение в состоянии стресса. Поэтому на собесе главное отсеять явный неликвид (типа алкаши или нарков) и нанять того, кто похож на человека находящего оптимальное решение в состоянии стресса.
⸻ ❧
“Small is not just a stepping-stone. Small is a great destination itself.” ― Jason Fried
Re[3]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, r0nd, Вы писали:
R>Задачи — это всего лишь следствие конкуренции на рынке труда.
100% согласен.
R>Имхо, самая важная черта инженеров разработки найти оптимальное решение в состоянии стресса. Поэтому на собесе главное отсеять явный неликвид (типа алкаши или нарков) и нанять того, кто похож на человека находящего оптимальное решение в состоянии стресса.
А с какого хрена "инженеры разработки" должны находиться в стрессе? Надеюсь, что зарплата стоит того, ибо стресс — прямая дорога к проблемам со здоровьем и ранней смерти.
Re[4]: Еще раз о собеседованиях разработчика, не понимаю
On Jul 17, 2024, 12:51 AM, Ip Man <133900@users.rsdn.org> wrote:
IM>А с какого хрена "инженеры разработки" должны находиться в стрессе? Надеюсь, что зарплата стоит того, ибо стресс — прямая дорога к проблемам со здоровьем и ранней смерти.
Нет, я не имел ввиду, что кто-то должен. Никто никому ничего не должен, и здоровье инженера на первом месте. Но работа разработчика предполагает рутину и решение проблем на постоянной основе, а не периодами, и все умные после университетов, но жизнь она другая — и сложности и кризисы не должны пугать разработчика, а только подстегивать, умение думать в критически сложных ситуациях — по моему мнению самый важный навык, который может быть. Особенно он ценится в дни больших релизов.
А что касается собеседования, то стрессовая ситуация там для любого честного соискателя вакансии по общему конкурсе, и если это помнить, то можно собеседование ускорить и упростить, если обращать на то что важно и не задавать то, что не важно.
⸻ ❧
“The only one who can tell you “you can’t win” is you and you don’t have to listen.” — Jessica Ennis
Re: Еще раз о собеседованиях разработчика, не понимаю
По фаанг могу ошибаться, но у меня сложилось такое впечатление, что там всё настолько отличается от остальных компаний, что опыт очень часто иррелевантен. Ну есть у тебя опыт работы с git, а в гугле там своя VCS. Есть у тебя опыт работы со спрингом, а в гугле ты его использовать не будешь, ты будешь первые полгода изучать их внутренние библиотеки.
Поэтому они в первую очередь смотрят на "живость ума", а не на то, какие ты проекты поднимал. Вероятно решение задач литкода и эти дизайн-интервью коррелируют со скоростью обучения. Тут надо понимать, что у них статистика огромная и если они что-то делают, есть вероятность, что это действительно работает.
Обычным компаниям это всё не нужно. Ну к ним и потока такого нет, как в фаанг. Я как-то интервьюировал несколько десятков ребят — какой там литкод, простейшие задачи половина решить не могут, в двух циклах блуждают.
Re: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
_>Я не совсем понимаю что компании проверяют, более того в инете куча всяких каналов по разбору задач, по разбору сисдиз интервью. Т.е. человек, который банально поднатаскался с не очень релевантным опытом может вполне пройти собес.
Могу дать несколько объяснений:
— сбить зарплатные ожидания
— выбор послушных. Тех, кто готов выполнять указания независимо от того, насколько они нелепы.
— в качестве приятного бонуса, дает организаторам мероприятия чувство собственной важности и крутизны.
Ад пуст, все бесы здесь.
Re[3]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, Michael7, Вы писали:
P>>Если требуется взять на работу три человека, а желающих выстроилось аж три тысячи, то как поступить работодателю? M>Нанять первых же трёх, которые подойдут по требованиям.
Если слишком быстро будешь нанимать, то тебя уволят, посчитают, что ты нихера не делаешь.
Нанимать кого-то нужно ровно столько времени, чтобы начальник был уверен, что ты весь в мыле и тебе в помощь нужно нанять помощника.
Re: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
И есть еще один тонкий момент, даже психологическая ловушка.
Мне всегда было интересно, как работает мозг всяких коши, дирихле, риманов и лебегов, ну или перельмана.
Т.е. эти крайне сообразительные граждане решали какую-то задачу, которая не была решена, сидели думали, тратили время и по итогу получали какое-то решение, которое остается потом в книжках на века. Позже большинство только пытается понять и применить их решение. И вот в этот момент появляется психологическая ловушка, что если я знаю интегрирование дифференцирование и прочее, то я хоть как-то становлюсь ближе к этим гражданам, но нет. Чтобы встать с ними на одну ступень, надо решить какую-то похожую проблему.
так же и с алгозадачами, например поиск подстроки палиндрома в строке и оптимальный алгоритм был предложен Гленном Манакером в 1975 году, уже тогда готовились к собесам
И вот когда дают такое на собесе и ожидают, что?
Если человек придумает такое решение, то наверное он гений или точно не ординарный человек и ему наверное можно давать какие-то другие сложные задачи, а не перекладывать жсоны в рест пользуясь ассойиативными контейнерами. А если человек заучил и повторил решение, то какую проблему он сможет решить?
В последнее время стал больше интересоваться в том числе историей математики, чтобы понять ход мыслей тех, кто решал какие-то проблемы впервые. На текущий момент найти готовое решение в принципе не составляет труда, важно уметь синтезировать оптимальное решение при текущих обстоятельствах.
Re[2]: Еще раз о собеседованиях разработчика, не понимаю
_>>Есть набор компаний, у которых входной порог на собес — решение алгозадач, далее идет дизайн секция, на которой за 3часа делают фейцбух, ютуп итп
IM>Я уже как-то писал здесь об этом. Нужно балансировать текущую работу с подготовкой к собеседованиям всё время, а не за месяц до.
по моему ощущению — не соглашусь
пока работаешь — работа есть и так, зачем тратить силы на деятельность связанную с поиском работы
изъятые силы могут привести к выгоранию на текущем месте
а когда встанет вопрос с поиском следующей работы, то можно выделить месяц-два на подготовку
у меня собесов было в жизни штук 150, и могу уверенно сказать, что поветрия, принятые при найме меняются
и ты их можешь ощутить только в текущее полугодие — через 2 года локальные правила будут уже другие
и я никогда не понимал и не практиковал поиск с одной работы сразу следующей — а жить-то когда?
уволься, поживи хотя бы полгода, потом и ищи следующую работу
если это необходимость, то зачем ставить себя в такие рамки, чтобы жить было некогда — одной зарплаты последние лет 10 должно хватать на долго
Re[5]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, r0nd, Вы писали:
R>Нет, я не имел ввиду, что кто-то должен. Никто никому ничего не должен, и здоровье инженера на первом месте. Но работа разработчика предполагает рутину и решение проблем на постоянной основе, а не периодами, и все умные после университетов, но жизнь она другая — и сложности и кризисы не должны пугать разработчика, а только подстегивать, умение думать в критически сложных ситуациях — по моему мнению самый важный навык, который может быть. Особенно он ценится в дни больших релизов.
Выпуск релиза должен быть рядовым событием, на котором не требуется чего-то особенного от людей.
Как ТО на машине. Периодически надо делать, придётся потратить время и может быть деньги, но никак не катастрофа и место для подвига, а просто рядовая процедура.
Если же релиз это подвиг, то что-то не так. И в состоянии нехватки времени пишут так себе код. Тесты, естественно, в этот момент никто не добавляет. Хорошо, если потом это всё разгребут.
Re[3]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
_>Тут вопрос в другом, почему первый это не сделал? я не думаю, что батчинг это прям таки неочевидное решение, т.е. в этом слуае скорее забил, нежели, чем не знал, потому как проблема то действительно была. Хотя поднатаскавшись на задачи, скорее всего и первый разраб их будет решать вполне себе.
Потому, что требованиям удовлетворяло? Удовлетворяло! Code review проходило? Проходило! Тесты прошли? Тоже прошли!
К тому же, всех и всегда учат, что premature optimization — корень всего злого, приписывая эту фразу то Кнуту, то Пайку (оба открещиваются). А про своевременную пессимизацию ничего плохого не говорят.
Тогда зачем тратить еще несколько дней на батчинг, добавляя себе минусов в карму? Тикет закрыл — из сердца вон!
Re: Еще раз о собеседованиях разработчика, не понимаю
_> Т.е. человек, который банально поднатаскался с не очень релевантным опытом может вполне пройти собес.
Верно. Проверяется не набор знаний, а то, может ли человек что-то изучить (подготовиться). Потому что 99% времени его работы в конторе будет как раз изучение каких-то существующих легаси систем. Где-то допилить, где-то переделать, где-то скопировать.
Почему так? Да потому, что если человек смог по-быстрому научиться, — это ценный кадр.
_> до этого литкод не решал вообще никогда, хотя при этом писал фрейморки, продукты, плюс минус разбираюсь в инфраструктуре как в виндовой, так и в линуксовой, немного сетей и т.д. Наводил порядок в нескольких проектах
В том-то и дело что таких специалистов пруд пруди. Можно взять любого — и он выполнит эту работу. Но, скорее всего, медленнее, чем тот, кто умеет быстро в чем-то разобраться.
_>1) Понять сильные и слабые стороны кандидата, как технические, так и психологические _>2) Определить как и что из этого можно использовать у себя на проектах _>3) Понять подходит ли компания человеку, его ожиданиям, целям в развитии и т.д.
Проблема (1) в том, что формат собеседования редко когда помогает выявить эти самые сильные и слабые стороны. Человек, как правило, вообще не раскрывается в первые недели, а то и месяцы, работы с ним.
_>И вот еще мысль была, почему-то все хотят стандартизировать процесс найма, но при этом не видел, чтобы выстраивали культуру найма.
Потому что конвейерный найм проще и в целом дешевле. Культуру найма могут позволить только совсем небольшие, я б сказал, элитные, команды.
Re: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали: _>И вот еще мысль была, почему-то все хотят стандартизировать процесс найма, но при этом не видел, чтобы выстраивали культуру найма.
Если требуется взять на работу три человека, а желающих выстроилось аж три тысячи, то как поступить работодателю? На мой взгляд, все эти многоразовые собеседования и предложения решать заумные задачи служат лишь одной цели — вежливо отказать большинству желающих трудоустроиться.
Re[4]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, diez_p, Вы писали:
_>>Тут вопрос в другом, почему первый это не сделал? я не думаю, что батчинг это прям таки неочевидное решение, т.е. в этом слуае скорее забил, нежели, чем не знал, потому как проблема то действительно была. Хотя поднатаскавшись на задачи, скорее всего и первый разраб их будет решать вполне себе.
Pzz>Потому, что требованиям удовлетворяло? Удовлетворяло! Code review проходило? Проходило! Тесты прошли? Тоже прошли!
Pzz>К тому же, всех и всегда учат, что premature optimization — корень всего злого, приписывая эту фразу то Кнуту, то Пайку (оба открещиваются). А про своевременную пессимизацию ничего плохого не говорят.
Pzz>Тогда зачем тратить еще несколько дней на батчинг, добавляя себе минусов в карму? Тикет закрыл — из сердца вон!
Да, пока объемы данных были маленькие было неочевидно — юзеры видят в интерфейсе что работа идёт, прогрессбар двигается, есть несколько минут выпить кофейку, жалоб нет. Проходит почти год с начала использования, входных данных вкидывают больше в тысячу раз чем было, уже не "кофейку выпить" а "запустить и проверить завтра", и начинают жаловаться что что-то оно долго.
Больше половины проблемы была даже не в батчинге а в десериализаторе, чтобы потом прочесть 3 значения из многокилобайтного объекта. Там разработчик и не подозревал насколько медленную операцию применил: десериализатор из стандартной библиотеки, так что поискав примеры в интернете любой подумает "все так делают".
Re[3]: Еще раз о собеседованиях разработчика, не понимаю
Почти всегда временнОй аспект для бизнеса важнее всех остальных. Разумеется, есть области, где на первый план выходят другие качества, но их, увы, слишком мало, чтобы быть заметными на фоне.
Re[2]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, Pitirimov, Вы писали:
P>Если требуется взять на работу три человека, а желающих выстроилось аж три тысячи, то как поступить работодателю?
Нанять первых же трёх, которые подойдут по требованиям. Есть конечно соблазн выбрать самых-самых, но по-моему, если кандидатов слишком много, то не факт, что долгие и изнурительные тестирования дадут лучший результат.
P> На мой взгляд, все эти многоразовые собеседования и предложения решать заумные задачи служат лишь одной цели — вежливо отказать большинству желающих трудоустроиться.
Еще появляется риск, что профессиональные навыки и умения проходить собеседования — это разные вещи.
Re[2]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, Qulac, Вы писали:
Q>Вроде глупо конечно, а как отбирать если много желающих?
Прособеседовать первых 3-7 и нанять того, кто тебе понравился больше.
Все остальные — неудачники же.
Re: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
_>По другую сторону баррикад _>Сейчас сам являюсь интервьювером по этим же самым алгозадачам, и вот если человек готовился и решал — то он их возможно решит, при этом бывают норм кандидаты(15 лет опыта во всяких ынтерпрайзах), где основная сложность не в алгоритме, а в понимании того, как весь этот зоопарк работает, то его даже не рассматривают. При этом позиция писать плюс минус такой же ыинтерпрайз с перекладыванием жсонов, в базенках там поковыряться, с людьми пообщаться. На возражения, что задачи не нужны, руководство упорствует.
Задачи не нужны, но показывают что человек по крайней мере что-то о них слышал, и имеет хоть какое представление об алгоритмической сложности, параллельной обработке и прочем.
По опыту даже при перекладывании жсонов в ентерпрайзе можно сделать одно и то же с разницей в производительности в десятки или сотни раз.
Живой пример из недавнего — есть ынтерпрайз система, один процесс постепенно обрабатывает записи в базе и обновляет их статус, второй ловит события обновлений в базе и обновляет общую статистику успешных/провальных/в процессе чтобы показать в интерфейсе.
Логически это всё вполне правильно, но поскольку первый процесс распараллелен он делает работу относительно быстро. А вот второй был написан так что он принимал сообщения по одному, конвертировал жсон из формата события, читал идентификатор записи и какой статус сменился на какой, потом делал +1 и -1 к нужным полям в таблице статистики. Обработка очереди всех обновлений статуса занимала на многие часы дольше чем собственно полезная работа, а юзеры видели интерфейс и думали что работа ещё идёт.
Теперь второй принимает сразу по тысяче сообшений, не тратит время на конвертирование а читает нужные данные прямо так, подсчитывает сколько статусов перешло в какие в этой тысяче и потом делает одно обновление сводной статистики, это ускорило его примерно в 400 раз.
Re: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
Pzz>>Тогда зачем тратить еще несколько дней на батчинг, добавляя себе минусов в карму? Тикет закрыл — из сердца вон!
_>я про другое говорил, что первый знал, что проблема есть, т.е. юзеры уже страдают, почему бы не переделать на нормальную реализацию?
Потому, что никто не поставил перед ним эту задачу. А самому себе ставить — можно и обжечься.
Re: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
_>Есть набор компаний, у которых входной порог на собес — решение алгозадач, далее идет дизайн секция, на которой за 3часа делают фейцбух, ютуп итп
Я уже как-то писал здесь об этом. Нужно балансировать текущую работу с подготовкой к собеседованиям всё время, а не за месяц до.
Вопрос "почему так" — скорее философский. Потому что компании рулят рынком, особенно в последнюю пару лет, когда произошло много сокращений, а миллион индийских выпускников всё так же появляется на рынке каждый год.
Re: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
_>Дизайн интервью _>Этот кейс более приближен к реальности, но когда дают запроектировать фейсбук или ютуб за 3 часа, то какой смысл давать такое, если человек не будет писать этот фейсбук, а даже если и будет, то будет писать 3-4 сервиса.
Банально чтобы проверить, что человек в теме как работают современные большие системы, т.е. есть какое-то общее
понимание. Кажется, что актуально для биг-техов и всяких банков. Почему нет? Опять же, можно проверять навыки
декомпозиции проблемы, работа с требованиями, архитектурные требования и компромиссы и т.п. вещи.
Кодом людям нужно помогать!
Re[5]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, r0nd, Вы писали:
R>сложности и кризисы не должны пугать разработчика, а только подстегивать, умение думать в критически сложных ситуациях — по моему мнению самый важный навык, который может быть. Особенно он ценится в дни больших релизов.
Я работал и в компаниях где что ни релиз то аврал, так и в компаниях, где никаких стрессов не было. В первых — это всегда была полная некомпетентность руководства и/или программистов.
Ад пуст, все бесы здесь.
Re[3]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, Pyromancer, Вы писали:
P>Живой пример из недавнего — есть ынтерпрайз система, один процесс постепенно обрабатывает записи в базе и обновляет их статус, второй ловит события обновлений в базе и обновляет общую статистику успешных/провальных/в процессе чтобы показать в интерфейсе. P>Логически это всё вполне правильно, но поскольку первый процесс распараллелен он делает работу относительно быстро. А вот второй был написан так что он принимал сообщения по одному, конвертировал жсон из формата события, читал идентификатор записи и какой статус сменился на какой, потом делал +1 и -1 к нужным полям в таблице статистики. Обработка очереди всех обновлений статуса занимала на многие часы дольше чем собственно полезная работа, а юзеры видели интерфейс и думали что работа ещё идёт. P>Теперь второй принимает сразу по тысяче сообшений, не тратит время на конвертирование а читает нужные данные прямо так, подсчитывает сколько статусов перешло в какие в этой тысяче и потом делает одно обновление сводной статистики, это ускорило его примерно в 400 раз
Скорее всего второй процесс много раз дописывали. Может требования менялись, может первый поддерживающий программист не понял задачу, следующий тоже не стал разбираться, а просто добавил свою часть. И получилось то, что получилось. И все эти люди прошли фильтр олимпиадных задачек на входе, а также в ходе собеседования их спрашивали про проектирование всяких сложных систем. А не то, что обновление статистики.
И как теперь это исправить? Наверное надо взять ещё одного человека, который знает что-то про сложность задач и слышал, что алгоритм с квадратичной сложностью работает медленнее, чем с линейной. Что-то мне кажется не поможет. Надо взять человека, который будет упорно разбираться что происходит и попутно пытаясь хоть как-то ускорить программу. Причём почти наверняка вариант написать заново не подходит, т.к. часть багов стало фичами и много программ от них зависят. Естественно это всё незадокументированно. А люди, которые это писали, либо уволились, либо у них амнезия и ничего полезного рассказать не могут.
Re[2]: Еще раз о собеседованиях разработчика, не понимаю
E>Зачем мы сдаём/сдавали экзамен по математике для поступления в ВУЗ, чтобы учиться на программиста? Фактически это были годы подготовки, чтобы в решающий момент не завалиться на всяких задачах по тригонометрии и стереометрии. Я думаю, что с собеседованиями произошло нечто похожее. При должной массовости запускается механизм коллективного бессознательного, который порождает... вот это вот всё.
Математика стала чем-то вроде секты. Функционеры её проникли на руководящие посты в образовании, перегородили все проходы, и пропускают только своих, хорошо натасканных на знание сектантских церемоний, а не тех кто имеет способности к законам природы и к технике.
что в итоге? Во главе крупной лаборатории, занимающейся ядерной физикой встал математик! Не тот, кто понимает, что происходит с атомами и электронами, а математик! И это не в одной лаборатории произошло и не один раз. А везде и по всему миру и постоянно. И этот математик, не только не смог ничего создать в своей лаборатории что-либо, но он ещё и объявил дураком того, кто на его месте мог бы что-то сделать, и выпихнул того учёного из науки на рынок.
И даже более, этот математик, выпинул его из науки не тогда, когда они оба закончили университет. А ещё на вступительных экзаменах, на самом раннем этапе. Заняв бюджетное место того, кто мог бы продвинуть ядерную физику. Ещё в школе, выиграв престижную олимпиаду по математике. Не дав выиграть тому, кто бы мог что-то сделать.
Нужна ли высшая математика такой сложности как сейчас в науке? Вопрос риторический. Можно ли высшую математику рассматривать как основной фильтр при поступлении в университет? Кстати высшую математику везде на технических специальностях сдают вообще всегда.
Re: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
_>Я не совсем понимаю что компании проверяют,
Часть интервью — это получение знаний друг о друге. Но всё в мире относительно, и кандидаты на собеседовании не исключение. Интервьюер всегда их сравнивает с другими — даже если проводит собеседование впервые, он сравнивает с собой и другими людьми, которых видел/общался. Так что многое на интервью ради сравнения, а не ради выяснения чего-то. Интервьюер задает какие-то задачи/вопросы на размышление, смотрит, как кандидат решает, как размышляет, сравнивает с другими — делает выводы о его относительном уровне.
Бывает даже не важно, решает кандидат задачу или нет — задача вообще может не иметь решения или иметь множество разных решений — акцент именно на том, как именно человек размышляет в сравнении с другими кандидатами.
То же по психологии и поведению.
Так же и в обратную сторону — кандидат сравнивает компании с другими — с теми, где еще собеседовался, где работал, а новичок так вообще с некими воображаемыми компаниями, про которые где-то что-то слышал.
_>Идеальный собес _>1) Понять сильные и слабые стороны кандидата, как технические, так и психологические _>2) Определить как и что из этого можно использовать у себя на проектах _>3) Понять подходит ли компания человеку, его ожиданиям, целям в развитии и т.д.
Это не идеальное собеседование, а задачи собеседования.
_>И вот еще мысль была, почему-то все хотят стандартизировать процесс найма
...так давайте поучимся у него.
Хороший интервьюер — это такая же смесь личных качеств, таланта и опыта, как и хороший разработчик. Не всем дано и далеко не все научатся.
Стандартизация же — это и есть обобщение хорошего опыта. Точно так же стандартизируют, к примеру, управление бизнесом/предприятием — см. МБА. Да обучение любой работе — это обучение стандартным подходам. А дальше уже основная масса будет работать по ним, и из этой части кто-то будет выделяться и расти.
_>Вместо этого собес формализуют в этапах, чтобы чуть ли не обезьяна могла прособесить по методичке, но раз можно прособесить по методичке, то опять таки нанимаем по шаблону и что-то может в шаблон и не пролезет
Это нужно по причинам:
1. Когда человек только начинает собеседовать — ему нужна база, с чего начать. Дальше получит опыт и сам выработает свой подход.
2. Ресурсы "хороших интервьюеров" ограничены, так что да — нужны и те, кто по методичке — т.к. решить задачу хоть как-то лучше, чем не решить никак.
Здравствуйте, Pyromancer, Вы писали:
P>Здравствуйте, diez_p, Вы писали:
_>>По другую сторону баррикад P>Теперь второй принимает сразу по тысяче сообшений, не тратит время на конвертирование а читает нужные данные прямо так, подсчитывает сколько статусов перешло в какие в этой тысяче и потом делает одно обновление сводной статистики, это ускорило его примерно в 400 раз.
Тут вопрос в другом, почему первый это не сделал? я не думаю, что батчинг это прям таки неочевидное решение, т.е. в этом слуае скорее забил, нежели, чем не знал, потому как проблема то действительно была. Хотя поднатаскавшись на задачи, скорее всего и первый разраб их будет решать вполне себе.
Re[5]: Еще раз о собеседованиях разработчика, не понимаю
P>Больше половины проблемы была даже не в батчинге а в десериализаторе, чтобы потом прочесть 3 значения из многокилобайтного объекта. Там разработчик и не подозревал насколько медленную операцию применил: десериализатор из стандартной библиотеки, так что поискав примеры в интернете любой подумает "все так делают".
У нас такого было вагон и маленькая тележка, а почему бы нам тут не залепить? залепили, потом начинает тормозить, начинаешь решать вопрос, где-то батчинг, где-то какие-то кастомные аллокаторы, где-то еще какие-то варианты решений ищешь. Т.е. ключевое тут умение иденитфицировать и решать проблемы.
являются ли умение "не умею решать алго задачи" достаточным условием того, чтобы не брать человека на работу — для меня непонятно.
Re[4]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
_>Здравствуйте, diez_p, Вы писали: _>И есть еще один тонкий момент, даже психологическая ловушка. _>Мне всегда было интересно, как работает мозг всяких коши, дирихле, риманов и лебегов, ну или перельмана. _>Т.е. эти крайне сообразительные граждане решали какую-то задачу, которая не была решена, сидели думали, тратили время и по итогу получали какое-то решение, которое остается потом в книжках на века. Позже большинство только пытается понять и применить их решение. И вот в этот момент появляется психологическая ловушка, что если я знаю интегрирование дифференцирование и прочее, то я хоть как-то становлюсь ближе к этим гражданам, но нет. Чтобы встать с ними на одну ступень, надо решить какую-то похожую проблему.
Кажется, это не совсем корректное представление. Все эти люди умны, но они прежде всего умеют концентрироваться
в долгую над решением соотв. задачи, а не между тасками переключаться. Короче, они просто дольше всех думали над решением
той или иной задачи. Вовсе не факт, что это были гении или крайне сообразительные люди. Кажется, что тут чуть ли не характер
или воля решают больше.
_>так же и с алгозадачами, например поиск подстроки палиндрома в строке и оптимальный алгоритм был предложен Гленном Манакером в 1975 году, уже тогда готовились к собесам _>И вот когда дают такое на собесе и ожидают, что? _>Если человек придумает такое решение, то наверное он гений или точно не ординарный человек и ему наверное можно давать какие-то другие сложные задачи, а не перекладывать жсоны в рест пользуясь ассойиативными контейнерами. А если человек заучил и повторил решение, то какую проблему он сможет решить?
Если придумает, то да. Но скорее всего такое спрашивают, если придется заниматься чем-то релевантным, т.е. закрыть какую-то
конкретную позицию. Если заучил и повторил решение, то как минимум человек мотивированный.
Кодом людям нужно помогать!
Re[5]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
Pzz>>Тогда зачем тратить еще несколько дней на батчинг, добавляя себе минусов в карму? Тикет закрыл — из сердца вон! _>я про другое говорил, что первый знал, что проблема есть, т.е. юзеры уже страдают, почему бы не переделать на нормальную реализацию?
Выше написали, что не знал. Планировалось гонять задачу на небольших наборах данных, а оно эвоно как.
Банально нормально не протестировали или не предусмотрели такой вариант использования.
Кодом людям нужно помогать!
Re[2]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, vsb, Вы писали:
vsb>По фаанг могу ошибаться, но у меня сложилось такое впечатление, что там всё настолько отличается от остальных компаний, что опыт очень часто иррелевантен. Ну есть у тебя опыт работы с git, а в гугле там своя VCS. Есть у тебя опыт работы со спрингом, а в гугле ты его использовать не будешь, ты будешь первые полгода изучать их внутренние библиотеки.
Или например, писал программист на питоне, а им понадобился программист на C++. Ничего страшного — этого переучим!
vsb>Поэтому они в первую очередь смотрят на "живость ума", а не на то, какие ты проекты поднимал.
К этим собеседованиям готовятся, потому что иначе хрен пройдешь. И эта подготовка работает. Все готовятся, без исключений. Если говорят, что не готовятся — пи*дят. (Кстати, к вопросу о живости ума, ты сообщение ТСа вообще прочитал?)
Более того, даже многие хрюши говорят что надо готовиться, и это уже совсем за гранью бреда.
Хотя на самом деле, корреляция действительно есть. Но не с живостью ума, а с готовностью выполнять любые указания, независимо от того, насколько они нелепы. Именно это они и тестируют.
Здравствуйте, reversecode, Вы писали:
R>если бы разработчика можно было так же легко уволить/разойтись R>как и нанят R>то все эти собесы уменьшились бы на 95%
В некоторой степени да. Но что мешает нанять кандидата как контрактора, например? Отработал к примеру три месяца, получил за них оплату, а далее — уже по обоюдному решению сторон. Программисту (толковому) такой вариант тоже лучше, потому что если руководство — идиоты, то лучше свалить как можно раньше.
Ад пуст, все бесы здесь.
Re[2]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, Pyromancer, Вы писали:
P>Живой пример из недавнего
А вот тебе другой живой пример. Собеседование в компании — круче нас только горы. Что не помешало прошедшему его программисту сделать квадратичную сложность в совершенно тривиальной задаче, так что выполнение батча с самого начала занимало часы, а потом данных стало немного больше — и оно стало занимать уже дни.
P>Обработка очереди всех обновлений статуса занимала на многие часы дольше чем собственно полезная работа
Интеграционных тестов не было? Тестеров не было?
Ад пуст, все бесы здесь.
Re[4]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
_>К собесу надо готовиться. Для чего? Почему? чтобы что? Если человек может подготовиться к собесу, то его практические навыки нафиг не нужны на этой работе и можно нанимать в принципе любого, кто прослушал курс Х или же сам его изучил. _>Вообще идеальный собес это когда готовятся 2 стороны, я в принципе всегда и пытаюсь так сделать.
Человек общается сам с собой и процессе общения меняет точку зрения. Шизофрения это всегда нескучно
Re[3]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, r0nd, Вы писали:
R>Сейчас конвеер. Тебя выжимают 2-4 года, затем твое место занимает такой же клон тебя 2-4 года давности. Клон с такими же ожиданиями и иллюзиями. И все по кругу.
Видимо мне надо куда-то двигаться в более инженерную или научную сферу. Либо действительно дефицита в IT кадрах нет в принципе и сито в виде алгозадач вполне себе устраивает и работает.
R>Аналогичную проблему. Конечно, в том числе и по этой причине тесты IQ и убрали как инструмент измерения уровня интеллекта. Потому что обнаружили, что результат у человека который проходил логическую часть тестов резко выше при повторном прохождении этих тестов. Человеческий мозг легко делает аналогические конструкты, гораздо хуже ему синтезировать новые.
Так это равносильно тому, что а давайте я загуглю, но какова вероятность, что надо будет скать например палиндром в подстроке?
R>Имхо, самая важная черта инженеров разработки найти оптимальное решение в состоянии стресса. Поэтому на собесе главное отсеять явный неликвид (типа алкаши или нарков) и нанять того, кто похож на человека находящего оптимальное решение в состоянии стресса.
Это точно не про меня, я люблю решать задачи без стрессов, планово иногда с большей работоспособностью иногда с меньшей.
Re[2]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, cppguard, Вы писали:
C>Здравствуйте, diez_p, Вы писали:
_>>К собесу надо готовиться. Для чего? Почему? чтобы что? Если человек может подготовиться к собесу, то его практические навыки нафиг не нужны на этой работе и можно нанимать в принципе любого, кто прослушал курс Х или же сам его изучил. _>>Вообще идеальный собес это когда готовятся 2 стороны, я в принципе всегда и пытаюсь так сделать.
C>
C>Человек общается сам с собой и процессе общения меняет точку зрения. Шизофрения это всегда нескучно
Возможно я некорректно выразился, когда я проводил в целом собесы я всегда готовился к кандидату, сейчас приходится проводить и собес по алгозадачам и рассуждаю об опыте с с каждой стороны
Re: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, Pyromancer, Вы писали:
P>разработчик и не подозревал насколько медленную операцию применил: десериализатор из стандартной библиотеки, так что поискав примеры в интернете любой подумает "все так делают".
С++ ?
Какая хреновая стандартная библиотека.
Re[4]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
R>>Имхо, самая важная черта инженеров разработки найти оптимальное решение в состоянии стресса. Поэтому на собесе главное отсеять явный неликвид (типа алкаши или нарков) и нанять того, кто похож на человека находящего оптимальное решение в состоянии стресса. _>Это точно не про меня, я люблю решать задачи без стрессов, планово иногда с большей работоспособностью иногда с меньшей.
В состоянии стресса любят решать проблемы только адреналиновые наркоманы.
У обычных разработчиков падает как производительность, так и качество. Не знаю людей, которые что-то делают так себе. Но если находятся в стрессе, то выдают шедевры.
Re: Еще раз о собеседованиях разработчика, не понимаю
Если чел не может решить лёгкую алгозадачу, то он идёт лесом. Его опыт ныряния в говно может прлизрастать из того, что он это гоано и породил и привнесёт пахучую субстанцию в команду. Оно надо?
Re: Еще раз о собеседованиях разработчика, не понимаю
Зачем мы сдаём/сдавали экзамен по математике для поступления в ВУЗ, чтобы учиться на программиста? Фактически это были годы подготовки, чтобы в решающий момент не завалиться на всяких задачах по тригонометрии и стереометрии. Я думаю, что с собеседованиями произошло нечто похожее. При должной массовости запускается механизм коллективного бессознательного, который порождает... вот это вот всё.
Re: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
_>Есть набор компаний, у которых входной порог на собес — решение алгозадач, далее идет дизайн секция, на которой за 3часа делают фейцбух, ютуп и прочие известные сервисы, которые писали тыщи людей и сами же эти сервисы претерпевали несколько стадий эволюций.
Всё определяется исключительно целью собеседования. А целей практически столько же, сколько собеседующих да еще и в разное время разные цели у них.
А вообще современный подход к подбору программистов на работы практически добил софто- и хардварестроение.
Re[4]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
_>Видимо мне надо куда-то двигаться в более инженерную или научную сферу. Либо действительно дефицита в IT кадрах нет в принципе и сито в виде алгозадач вполне себе устраивает и работает.
Дефицита в IT кадрах уже очень давно нет. В инженерной и научной сферах все то же.
Дефицит есть там, где руками или ногами работают.
_>Это точно не про меня, я люблю решать задачи без стрессов, планово иногда с большей работоспособностью иногда с меньшей.
Это твои личные проблемы.
Re: Еще раз о собеседованиях разработчика, не понимаю
мне всегда нравились задачки на интервью, никогда к ним не готовился.
и никогда дизайн систем — там вскусовщины много.
задача штука объективная. бывало мне говорят, неправильно, баги — я спорю, мы проверяем — убеждаемся что багов нет.
с дизайном систем все не так жестко, упрется интервьюер рогом и всё — можно просто игнорить аргументы
Re: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
_>Алгозадачи. _>Алгозадачи демонстрируют лишь умение решать эти самые задачи
Не только умение,но и время потраченное на все это дело — т.е. это говорит нам о том, что кандидат учится.
Если задачу сводить не к решению, а к обсуждению, то вы получите ответ на то, как кандидат думает, как понимает вычислительную сложность, итд.
Скажем, люди которые не умеют решать такие задачи, как правило пишут лютую дичь — "у меня всё работает !!!!1111кукуку".
_>Дизайн интервью _>Этот кейс более приближен к реальности, но когда дают запроектировать фейсбук или ютуб за 3 часа, то какой смысл давать такое, если человек не будет писать этот фейсбук, а даже если и будет, то будет писать 3-4 сервиса.
Чаще всего просят чаты, боты, покупки, итд, из того, что реально успеть за час.
Здесь вы снова наблюдаете, как человек реагирует на ваши вводные, следовательно — как он думает, учится ли он или просто штампует рецепты.
_>Реальность _>Я не совсем понимаю что компании проверяют, более того в инете куча всяких каналов по разбору задач, по разбору сисдиз интервью. Т.е. человек, который банально поднатаскался с не очень релевантным опытом может вполне пройти собес.
Есть такая вещь — нужно давать задачи уникальные, и уметь копаться в опыте кандидата.
_>И вот тут у меня закрадывается сомнение: сложность разработки по сути миф, достаточно взять любого человека, который может просто писать код.
Сначала должны быть внятные мысли про то, как этот код должен выглядеть, как должен работать итд. А уже потом идет написание.
Слишком много задач только выглядят простыми для написания.
А кроме написания кода, нужно еще и уметь тестировать, уметь писать тесты. А для этого вам нужно более менее внятное представление о дизайне.
_>Видимой такой опыт сейчас в принципе не интересен.
Интересен, только выявить его на собеседованиее можно нетехническими методами, типа поведенческое интервью итд, которыми 90 интеврьюеров не владеет.
Типа "рассказать можно что угодно дадим лучше задачку на алгоритмы"
_>По другую сторону баррикад _>Сейчас сам являюсь интервьювером по этим же самым алгозадачам, и вот если человек готовился и решал — то он их возможно решит, при этом бывают норм кандидаты(15 лет опыта во всяких ынтерпрайзах), где основная сложность не в алгоритме, а в понимании того, как весь этот зоопарк работает, то его даже не рассматривают. При этом позиция писать плюс минус такой же ыинтерпрайз с перекладыванием жсонов, в базенках там поковыряться, с людьми пообщаться. На возражения, что задачи не нужны, руководство упорствует.
Задачи нужны, только сводить к ним 100% времени собеседования смысла нет.
Я думаю, вам нужно как то внятно сформулировать свой подход и продемонстрировать его на практике.
Только вы замахиваетесь на изменение процесса найма, а это изменение крайне небыстрое — месяцы и годы минимум.
И вам стоит начать с ответа на вопрос, где же вы будете брать нужных интервьюеров.
Скажем, те интервьюеры, что любят задачки, ничего кроме этого не умеют. Их нужно или убрать, или переучить. А они еще и сопротивляться будут, рассказывать что все ваши методы это херня т.к. взяты из книжек по психологии.
_>Идеальный собес _>Вообще идеальный собес это когда готовятся 2 стороны, я в принципе всегда и пытаюсь так сделать. _>1) Понять сильные и слабые стороны кандидата, как технические, так и психологические _>2) Определить как и что из этого можно использовать у себя на проектах _>3) Понять подходит ли компания человеку, его ожиданиям, целям в развитии и т.д.
п1 2 и 3 большинству технических интервьюеров недоступны, к сожалению. Вот и штампуют собесы по задачкам.
п2 и 3 — на это у интервьюера просто нет сведений
п3 — не совсем ясно, зачем выворачивать "подходит ли компания человеку" Проще заходить с "подходит ли кандидат"
_>Эпилог _>И вот еще мысль была, почему-то все хотят стандартизировать процесс найма, но при этом не видел, чтобы выстраивали культуру найма. Условно вот чел, который умеет отбирать людей и после него %% людей которые работают эффективно в компании выше, чем у всех остальных, так давайте поучимся у него. Вместо этого собес формализуют в этапах, чтобы чуть ли не обезьяна могла прособесить по методичке, но раз можно прособесить по методичке, то опять таки нанимаем по шаблону и что-то может в шаблон и не пролезет
Это потому, что технические специалисты в среднем выбирают решения, где больше контроля, т.к. такой скилл как доверие к чужому решению отсутствует. Это можно понаблюдать, как разработчики в первый же день рвутся всё переписать.
Когда такой товарищ становится нанимающим менеджером, он точно так же выбирает решение где у него максимум власти и контроля.
Re[3]: Еще раз о собеседованиях разработчика, не понимаю
C>Хотя на самом деле, корреляция действительно есть. Но не с живостью ума, а с готовностью выполнять любые указания, независимо от того, насколько они нелепы. Именно это они и тестируют.
Т.е. в принципе там могут и ламбаду + стриптиз с дрочкой на камеру с таким же успехом потребовать. Выполняет — годен, в залупу полез — следующий.
Re[2]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, SkyDance, Вы писали:
_>> Т.е. человек, который банально поднатаскался с не очень релевантным опытом может вполне пройти собес. SD>Верно. Проверяется не набор знаний, а то, может ли человек что-то изучить (подготовиться). Потому что 99% времени его работы в конторе будет как раз изучение каких-то существующих легаси систем. Где-то допилить, где-то переделать, где-то скопировать. SD>Почему так? Да потому, что если человек смог по-быстрому научиться, — это ценный кадр.
А куда все так спешат? Ну может он медленнее, но более вдумчив, т.е. меньше проблем с его решениями будет. Нет, я конечно понимаю, что при прочих равных, если все будет сделано одинаково, то тот кто сделал быстрее более ценен. Но это не всегда так.
Кодом людям нужно помогать!
Re[2]: Еще раз о собеседованиях разработчика, не понимаю
_>И есть еще один тонкий момент, даже психологическая ловушка. _>Мне всегда было интересно, как работает мозг всяких коши, дирихле, риманов и лебегов, ну или перельмана. _>Т.е. эти крайне сообразительные граждане решали какую-то задачу, которая не была решена, сидели думали, тратили время и по итогу получали какое-то решение, которое остается потом в книжках на века. Позже большинство только пытается понять и применить их решение. И вот в этот момент появляется психологическая ловушка, что если я знаю интегрирование дифференцирование и прочее, то я хоть как-то становлюсь ближе к этим гражданам, но нет. Чтобы встать с ними на одну ступень, надо решить какую-то похожую проблему.
Ответ крайне прост.
С детства повседневная жизнь должна быть менее интересна, чем решение таких задач.
С детства — мозги развиваются в детстве.
И потом во взрослой жизни повседневная жизнь должна быть менее интересна, чем решение вот таких вот задач.
Перельман жил очень скромно (сейчас не знаю где и как). Отказался от миллиона. Отказался быть академиком.
Жены нет. Детей нет.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, senglory, Вы писали:
S>Т.е. в принципе там могут и ламбаду + стриптиз с дрочкой на камеру с таким же успехом потребовать. Выполняет — годен, в залупу полез — следующий.
Я уже практически ничему не удивлюсь.
Ад пуст, все бесы здесь.
Re[4]: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, SkyDance, Вы писали:
S>>А куда все так спешат?
SD>Почти всегда временнОй аспект для бизнеса важнее всех остальных.
Есть такое. При этом не "почти", а именно всегда, погоня исключительно за "временнЫм аспектом" приводит к ситуации класса "приехали". Вопрос лишь в том, как быстро.
L>Есть такое. При этом не "почти", а именно всегда, погоня исключительно за "временнЫм аспектом" приводит к ситуации класса "приехали". Вопрос лишь в том, как быстро.
К тому времени уже или ишак, или падишах придут к горе.
Re: Еще раз о собеседованиях разработчика, не понимаю
Здравствуйте, diez_p, Вы писали:
_>И вот тут у меня закрадывается сомнение: сложность разработки по сути миф, достаточно взять любого человека, который может просто писать код.
А ты вообще представляешь, какой код пишут те, кто может только писать код? Типа осилил курсы месячные и все. А также ладно код — сколько нужно некоторым товарищам объяснять что нужно сделать, там затраты на объяснение некоторых задач временные будут больше, чем написать самому. Количество багов какое будет, какой код будет в поддержке и все такое, сможет ли человек написать нетривиальный код к определенному сроку и все такое. Как минимум требуется чтобы у человека были мозги, он быстро схватывал что нужно сделать и быстро обучался. Это абсолютно необходимый навык, и к сожалению по этому критерию большинство не в состоянии работать. Если этого нет, то сложные задачи не поручить, можно поручать только типовые, а типовые нужно блин автоматизировать чтоб на типовое время не тратить. А простые задачи — будешь дольше объяснять что нужно сделать, чем сделать самому. И человек сделает — но настолько медленно, что просто капец. И супернекачественно с кучей багов еще, абсолютно не поддерживаемо и все такое. Пока станет писать нормально — пройдет несколько лет, и то если по рукам бить. Большинство не бьет и они варятся в собственном соку.
