Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 100
Просто и понятно. Мне понравилась Ваша статья. Согласен с Вами, что собеседование действительно должно быть ограниченно по времени. И причем не стоит это ограничение делать, скажем, в 3 часа, ну разве что кандидат действительно стоит этого времени.
>> «вы запустили программу с хипом в 2 гигабайта и она работает медленно, что будете делать?»
Классный вопрос, с подвохом. Вы сразу направляете кандидата по пути работы с памятью в целом и GC в частности. А правильным ответом, на мой взгляд, будет: «Запущу профайлер».
Классный вопрос, с подвохом. Вы сразу направляете кандидата по пути работы с памятью в целом и GC в частности. А правильным ответом, на мой взгляд, будет: «Запущу профайлер».
Бывают советы полезные, бывают откровенно вредные, а бывают никакие. В топике иллюстрируется неумение спрашивающего задавать вопросы. Как мне кажется, нормальный кандидат почти на любой вопрос из приведённых примеров будет задавать уточняющий вопрос:
(замечу, что лично я бы на собеседовании спрашивал о семантике, так что оба приведённых ответа меня бы одинаково не устроили)
И общее резюме. Если ваш сотрудник HR задаёт на собеседовании вопросы, не понимая их бессмысленность (то есть не понимая, что хороший кандидат обязан потребовать уточнений), то
— Что такое Object.hashCode()?
— Вас интересует текущая реализация, или семантика функции?
(замечу, что лично я бы на собеседовании спрашивал о семантике, так что оба приведённых ответа меня бы одинаково не устроили)
— вы запустили программу с хипом в 2 гигабайта и она работает медленно, что будете делать?
— а что за программа? какие инструменты есть в моём распряжении? почему вы считаете важным размер кучи?Почему вы привычное русское слово «куча» заменили странным заимствованием?
— предположим в этом коде нам надо перед «Some processing» отсортировать список в алфавитном порядке. Что будете делать?
— А можно ли менять входные данные, или лучше потратить время на их копирование?
И общее резюме. Если ваш сотрудник HR задаёт на собеседовании вопросы, не понимая их бессмысленность (то есть не понимая, что хороший кандидат обязан потребовать уточнений), то
вам еще рано искать технических специалистов. Для начала вам надо найти нового HR.
Эмм, разумеется это то же хорошие ответы.
Какая формулировка в статье заставила вас подумать, что я считаю единственно допустимым течением беседы то, которое я привожу как пример?
Тут скорее идея была в том, что одного ответа на вопрос мало — ответ (или вопрос) кандидата порождает ответную реакцию от вас и так далее.
— вы запустили программу с хипом в 2 гигабайта и она работает медленно, что будете делать?
— а что за программа? какие инструменты есть в моём распряжении? почему вы считаете важным размер кучи?
— Ну интуитивно мне кажется что реализация упирается в память(скажем, я вижу что ответы идут с характерными паузами). Хотя может и нет. На самом деле я даже не уверен что она работает «медленно» — может быстрее эта задача в принципе не решается. Но все же, хочется ускорить. Так как вы начнете выяснять в чем проблема? (инструменты — любые)
Какая формулировка в статье заставила вас подумать, что я считаю единственно допустимым течением беседы то, которое я привожу как пример?
Тут скорее идея была в том, что одного ответа на вопрос мало — ответ (или вопрос) кандидата порождает ответную реакцию от вас и так далее.
— вы запустили программу с хипом в 2 гигабайта и она работает медленно, что будете делать?
— а что за программа? какие инструменты есть в моём распряжении? почему вы считаете важным размер кучи?
— Ну интуитивно мне кажется что реализация упирается в память(скажем, я вижу что ответы идут с характерными паузами). Хотя может и нет. На самом деле я даже не уверен что она работает «медленно» — может быстрее эта задача в принципе не решается. Но все же, хочется ускорить. Так как вы начнете выяснять в чем проблема? (инструменты — любые)
Хотя может и нет. На самом деле я даже не уверен что она работает «медленно» — может быстрее эта задача в принципе не решается. Но все же, хочется ускорить.
— Те у Вас даже требований по необходимой производительности/отзывчивости системы нет? (возможный вариант продолжения разговора).
На мой взгляд, единственно верный вариант продолжения разговора в случае вопроса о медленности — это узнать критерий этой самой медленности и условия измерения. И только после этого можно приступать к анализу ибо велик риск варианта, что не устраивает latency, а до сервиса ~13000км по кратчайшему пути в трехмерном пространстве, что даже еще не изобретенная нейтринная связь не поможет получать результат быстрее чем за 44мс :)
— Те у Вас даже требований по необходимой производительности/отзывчивости системы нет? (возможный вариант продолжения разговора).
— Да, именно так. У меня есть java-программа, я хочу понять, можно ли ускорить ее работу потратив скажем 2 часа рабочего времени? А что такого… Поскольку время ограничено, а программа довольно большая, я даже не предлагаю вам разбираться что она делает. Тем не менее, я полагаю что можно предпринять набор тривиальных и быстрых мероприятий, что бы устранить наиболее вероятные проблемы. Под «ускорить» я понимаю сократить итоговое время работы(предположим моя программа запускается, делает свое дело и выдает результат)
— Да, именно так. У меня есть java-программа, я хочу понять, можно ли ускорить ее работу потратив скажем 2 часа рабочего времени? А что такого… Поскольку время ограничено, а программа довольно большая, я даже не предлагаю вам разбираться что она делает. Тем не менее, я полагаю что можно предпринять набор тривиальных и быстрых мероприятий, что бы устранить наиболее вероятные проблемы. Под «ускорить» я понимаю сократить итоговое время работы(предположим моя программа запускается, делает свое дело и выдает результат)
Я думаю, что поставленная Вами задача будет в большей степени неразрешима, а в худшем случае вредна, так как оптимизация большой программы без анализа того, что она делает приведет либо к появлению трудночитаемых костылей из-за микрооптимизаций, либо к тому, что программа будет сломана.
Ответ конечно получился не для собеседования :), но в жизни скорее это будет так. Что-бы проводить оптимизации нужно понимать, что делает программа, так как без этого не понятно куда прикладывать профайлер, непонятно, нужен ли он вообще (может быть сервер перегружен на все 146% или приложение активно читает/пишет на диск, а диски не справляются или проблема в сети по которой приложение получает какие-то данные или ...), а может быть в программе сортируются гигабайты пузырьковой сортировкой и нужные оптимизации на самом деле алгоритмические, которые без анализа алгоритма не сделать.
Ответ конечно получился не для собеседования :), но в жизни скорее это будет так. Что-бы проводить оптимизации нужно понимать, что делает программа, так как без этого не понятно куда прикладывать профайлер, непонятно, нужен ли он вообще (может быть сервер перегружен на все 146% или приложение активно читает/пишет на диск, а диски не справляются или проблема в сети по которой приложение получает какие-то данные или ...), а может быть в программе сортируются гигабайты пузырьковой сортировкой и нужные оптимизации на самом деле алгоритмические, которые без анализа алгоритма не сделать.
Ответ конечно получился не для собеседования :), но в жизни скорее это будет так.
Я не согласен с тем что вы ставите разницу между понятиями «для собеседования» и «для жизни».
Собеседование — не викторина. Завтра, если вы мне понравитесь, вы придете на работу, и если я что-то неправильно понял о вас на собеседовании, то либо мне придется доучивать вас, вместо того что бы писать любимый код, либо идти на крайне неприятные разговоры с HR.
Поэтому подразумевается, что задачки на собеседовании — не «брейнфитнес», а эмуляция реальных событий и рассмотрение вашей реакции.
>Что-бы проводить оптимизации нужно понимать, что делает программа, так как без этого не понятно куда прикладывать профайлер, непонятно, нужен ли он вообще (может быть сервер перегружен на все 146% или приложение активно читает/пишет на диск, а диски не справляются или проблема в сети по которой приложение получает какие-то данные или ...), а может быть в программе сортируются гигабайты пузырьковой сортировкой и нужные оптимизации на самом деле алгоритмические, которые без анализа алгоритма не сделать.
Ну вообще iostat+gclog — и вы за минуту узнаете — есть ли overcommit по диску, есть ли излишняя нагрузка на gc, есть ли излишняя нагрузка на проц, не уходит ли ваша программа в своп. Кроме того, я вам уже подсказал, что у меня есть серьезные подозрения что проблема именно в gc — т.к. характерные паузы в работе приложении говорят именно об этом.
Если вам повезло, и gclog показал проблемы с gc, то вы уже можете что-то улучшить. Да, конечно, возможно ваша программа криво написана и клепает короткоживущие объекты. Но если ситуацию можно временно улучшить потратив 10 минут на игру с параметрами gc, почему бы это не сделать?
Я не согласен с тем что вы ставите разницу между понятиями «для собеседования» и «для жизни».
Ее ставлю не я. Она есть априори и задача интервьюера эту разницу минимизировать. А суть этой разницы в том, что любое интервью или в широком смысле оценка чьих то знаний — это всегда стресс, который в обычной работе отсутствует полностью (могут быть в работе конечно и другие стрессы, но речь не об этом).
Ну вообще iostat+gclog — и вы за минуту узнаете — есть ли overcommit по диску, есть ли излишняя нагрузка на gc, есть ли излишняя нагрузка на проц, не уходит ли ваша программа в своп.
Видите сколько инструментов и направлений анализа вылезло из простой на первый взгляд задачи? А все из-за того, что нет требований к тому, что нужно получить и нет никакой информации о среде запуска и т.д. Все, что необходимо даже для начала решения необходимо выспрашивать отдельно, а это с моей точки зрения большой минус…
Кроме того, я вам уже подсказал, что у меня есть серьезные подозрения что проблема именно в gc — т.к. характерные паузы в работе приложении говорят именно об этом.
Диск и сеть могут давать точно такие-же паузы, так что тут не все так очевидно. Опять-же вместо того, чтобы просто потыкать профайлером приходится еще анализировать окружение, алгоритмы работы приложения и многое другое. Не слишком ли размыта задача и критерий признания ее решенной?
Но если ситуацию можно временно улучшить потратив 10 минут на игру с параметрами gc, почему бы это не сделать?
Это порочная практика, так как она не решает проблемы, а лишь маскирует ее и по закону Мерфи проблема выстрелит в полный рост тогда, когда ее будут ждать меньше всего.
P.S. Возможно, конечно, что задача кажется мне столь неопределенной из-за того, что я программист не на Java, а на С++ и всего-лишь не знаю Java-инструментов…
Видите сколько инструментов и направлений анализа вылезло из простой на первый взгляд задачи? А все из-за того, что нет требований к тому, что нужно получить и нет никакой информации о среде запуска и т.д. Все, что необходимо даже для начала решения необходимо выспрашивать отдельно, а это с моей точки зрения большой минус…
Цель всего топика была показать, как из простого вопроса вытекает множество других вопросов, и что в итоге все это помогает познакомится с кандидатом, причем помогает сделать это лучше, чем простые вопросы с единственным правильным ответом. То есть да, я вижу, сколько инструментов вылезло, и собственно видел это когда давал задачу. Да и задача оптимизации уж явно не является «простой» даже на первый взгляд.
Диск и сеть могут давать точно такие-же паузы, так что тут не все так очевидноКстати именно поэтому мы запускали iostat.
Это порочная практика, так как она не решает проблемы, а лишь маскирует ее и по закону Мерфи проблема выстрелит в полный рост тогда, когда ее будут ждать меньше всегоЧто именно «это» является порочной практикой? Минимизация усилий?
Кстати именно поэтому мы запускали iostat.
Прошу прощения, просмотрел в Вашем сообщении iostat.
Что именно «это» является порочной практикой? Минимизация усилий?
Вот это:
Да, конечно, возможно ваша программа криво написана и клепает короткоживущие объекты. Но если ситуацию можно временно улучшить потратив 10 минут на игру с параметрами gc, почему бы это не сделать?
Если есть косяк в программе, то его и нужно исправлять, а не прикручивать подпорки в виде параметров gc, так как в следующий раз подпорки могут не помочь, а времени на реакцию может и не остаться.
Ну смотрите, вы говорите — «не надо делать временные заплатки, проблемы надо решать в корне».
А теперь представьте что я владелец бизнеса.
Я теряю сколько долларов каждый час из-за того, что я теряю клиентов, из-за того что программа тормозит.
Я могу дать пару часов разработчикам на создание заплатки, или поручить админам купить компьютер помощнее, в надежде что это поможет, но вот чего я не могу, так это ждать пока вы там проводите исследования.
Значит ли это что после того как вы сделаете заплатку я на эту проблему забью и поручу вам клепать новую форму? Нет, почему же, наоборот. Как только вы сделаете эту заплатку я начну экономить по н доларов в час, и с радостью отдам некоторую их часть на более продуманный фикс — я ведь не идиот и не хочу наткнуться на эту же проблему еще раз когда мой сервис еще подрастет.
Но если текущую проблему я смог решить только силам администраторов, которые купят новый компьютер, в то время как разработчики спасовали, то я это запомню. И буду ценить своих администраторов сильнее, чем разработчиков.
А теперь представьте что я владелец бизнеса.
Я теряю сколько долларов каждый час из-за того, что я теряю клиентов, из-за того что программа тормозит.
Я могу дать пару часов разработчикам на создание заплатки, или поручить админам купить компьютер помощнее, в надежде что это поможет, но вот чего я не могу, так это ждать пока вы там проводите исследования.
Значит ли это что после того как вы сделаете заплатку я на эту проблему забью и поручу вам клепать новую форму? Нет, почему же, наоборот. Как только вы сделаете эту заплатку я начну экономить по н доларов в час, и с радостью отдам некоторую их часть на более продуманный фикс — я ведь не идиот и не хочу наткнуться на эту же проблему еще раз когда мой сервис еще подрастет.
Но если текущую проблему я смог решить только силам администраторов, которые купят новый компьютер, в то время как разработчики спасовали, то я это запомню. И буду ценить своих администраторов сильнее, чем разработчиков.
Видение подходов напрямую является следствием задач (резервов объективно может не быть), а новые ряды стоек с оборудованием могут обойтись существенно дороже пути, который начнется с анализа проблемы.
Вы сами себе противоречите. Если Вы знаете, что «теряете», то вы знаете каких показателей Вам нужно добиться(а вначале вы сказали, что показателей нет) и исходя из оценки недополученной прибыли(потерь у Вас нет, есть только сумма, которую Вы могли бы дополнительно получить работая сервис быстрее) можете оценивать сколько вы можете дать времени программистам на анализ и исправление конкретной проблемы. И это будет обоснованная цифра, а не абстрактные пара часов.
Я теряю сколько долларов каждый час из-за того, что я теряю клиентов, из-за того что программа тормозит.
Я могу дать пару часов разработчикам на создание заплатки, или поручить админам купить компьютер помощнее, в надежде что это поможет, но вот чего я не могу, так это ждать пока вы там проводите исследования.
Вы сами себе противоречите. Если Вы знаете, что «теряете», то вы знаете каких показателей Вам нужно добиться(а вначале вы сказали, что показателей нет) и исходя из оценки недополученной прибыли(потерь у Вас нет, есть только сумма, которую Вы могли бы дополнительно получить работая сервис быстрее) можете оценивать сколько вы можете дать времени программистам на анализ и исправление конкретной проблемы. И это будет обоснованная цифра, а не абстрактные пара часов.
Но если ситуацию можно временно улучшить потратив 10 минут на игру с параметрами gc, почему бы это не сделать
Далеко не факт что улучшить. Для примера возьмите знакомый вам код, который хорошо так по gc бьет и поиграйтесь с параметрами. Если у вас за плечами нет хорошего опыта по оптимизации всего этого, то думаю вы и через час и через два будете методично возвращаться туда, оттуда начинали оптимизацию*. А уж на собеседовании заниматься такими вещами. Думаю что тогда следующие вопросы будут в духе: укажите в данном коде ребра happens-before
* если конечно проблема не решиться уж совсем тривиальными способами, к примеру переходу к CMS + ParNew и/или увеличению yg.
Далеко не факт что улучшить. Для примера возьмите знакомый вам код, который хорошо так по gc бьет и поиграйтесь с параметрами. Если у вас за плечами нет хорошего опыта по оптимизации всего этого, то думаю вы и через час и через два будете методично возвращаться туда, оттуда начинали оптимизацию*. А уж на собеседовании заниматься такими вещами. Думаю что тогда следующие вопросы будут в духе: укажите в данном коде ребра happens-before
* если конечно проблема не решиться уж совсем тривиальными способами, к примеру переходу к CMS + ParNew и/или увеличению yg.
Кроме ограничения по времени, с которым все более-менее согласны, статья очень спорная.
В данном случае, ИМХО:
1. Описание собеседования бессистемно — у собеседования должна быть определенная структура, и она очень важна, с временными рамками на каждый этап (если-уж мы время ограничиваем).
2. «не нужно спрашивать, кем человек был» — очень зря, при рассмотрении прошлых работ или проектов как раз очень много можно о человеке узнать — был-ли он вовлечен/заинтересован, интересовался-ли он проектом в целом и бизнес-целями организации, или тупо кодил свой модуль, умеет-ли он вообще внятно объяснить архитектуру и детали реализации того, чем занимался — а это все ключевые факторы успешного сотрудника.
3. под конец такое ощущение, что статья скомкана — писать надоело :-)
В данном случае, ИМХО:
1. Описание собеседования бессистемно — у собеседования должна быть определенная структура, и она очень важна, с временными рамками на каждый этап (если-уж мы время ограничиваем).
2. «не нужно спрашивать, кем человек был» — очень зря, при рассмотрении прошлых работ или проектов как раз очень много можно о человеке узнать — был-ли он вовлечен/заинтересован, интересовался-ли он проектом в целом и бизнес-целями организации, или тупо кодил свой модуль, умеет-ли он вообще внятно объяснить архитектуру и детали реализации того, чем занимался — а это все ключевые факторы успешного сотрудника.
3. под конец такое ощущение, что статья скомкана — писать надоело :-)
Всё отлично, но:
Собеседование, очевидно, должно подстраиваться под уровень кандидата.
Если senior начал писать код, не спросив «зачем?» — то это плохой знак. А для мидла/джуна — вполне нормальный подход.
Самое главное — не существует «правильных» ответов (А этим грешат многие интервьюеры — ждут определённого ответа, все остальные заносят в неправильные). Важно понять, почему человек назвал такой ответ. «Почему вы использовали ....» — «Потому что это первое что пришло мне в голову, а я не хотел тратить Ваше и моё время на поиск другого решения.» — шикарнейший ответ, я думаю. Если, конечно же, представленое решение выполняет предьявленные изначально требования.
P.S. Заметил, что на собеседованиях гоняют по быстродействию/оптимальному использованию памяти. На практике — в 99% случаев никто об этом не думает. Так в чём же дело?
Собеседование, очевидно, должно подстраиваться под уровень кандидата.
Если senior начал писать код, не спросив «зачем?» — то это плохой знак. А для мидла/джуна — вполне нормальный подход.
Самое главное — не существует «правильных» ответов (А этим грешат многие интервьюеры — ждут определённого ответа, все остальные заносят в неправильные). Важно понять, почему человек назвал такой ответ. «Почему вы использовали ....» — «Потому что это первое что пришло мне в голову, а я не хотел тратить Ваше и моё время на поиск другого решения.» — шикарнейший ответ, я думаю. Если, конечно же, представленое решение выполняет предьявленные изначально требования.
P.S. Заметил, что на собеседованиях гоняют по быстродействию/оптимальному использованию памяти. На практике — в 99% случаев никто об этом не думает. Так в чём же дело?
не существует «правильных» ответов
Да, но именно это я и имел ввиду когда говорил, что цель таких простых вопросов — понять образ мыслей кандидата.
Заметил, что на собеседованиях гоняют по быстродействию/оптимальному использованию памяти. На практике — в 99% случаев никто об этом не думает.
Это как раз плохие вопросы. Я думаю если по работе вы ни разу не «утыкались» в gc то и спрашивать об этом кандидата нет смысла. Наверняка в вашей работе есть и другие нюансы — о них и надо спрашивать.\
Про то что для определенного уровня нормально писать не задумываясь — с этим не согласен.
>>Про то что для определенного уровня нормально писать не задумываясь — с этим не согласен.
Приходится смириться с тем — что у людей разный уровень и разный потенциал. И что, к сожалению, набить команду сениорами часто просто не получится, да и не нужно.
По сути мидл — это не уровень, а должность кандидата. Которая связана с некими обязанностями. Если в эти обязанности проработка архитектуры не входит — то делать без вопросов — не плохой вариант.
А вот последствия ситуации, когда человека с уровнем подходящем для мидла, и которого брали как мидла, ставят выполнять задачи сениора — могут быть весьма плачевны
Приходится смириться с тем — что у людей разный уровень и разный потенциал. И что, к сожалению, набить команду сениорами часто просто не получится, да и не нужно.
По сути мидл — это не уровень, а должность кандидата. Которая связана с некими обязанностями. Если в эти обязанности проработка архитектуры не входит — то делать без вопросов — не плохой вариант.
А вот последствия ситуации, когда человека с уровнем подходящем для мидла, и которого брали как мидла, ставят выполнять задачи сениора — могут быть весьма плачевны
Извините, что вмешаюсь…
«А вот последствия ситуации, когда человека с уровнем подходящем для мидла, и которого брали как мидла, ставят выполнять задачи сениора — могут быть весьма плачевны»
Собственно, ниже я и писал, что если взять «думающего мидла», то он быстро наберет уровень и будет предлагать свежим взглядом интересные архитектурные решения.
А если взять «кодера, накопипастившего N-тысяч строк кода из гугла», то ситуация может стать плачевной, даже если его и не пускать к архитектуре.
Насчет «у всех разный уровень и потенциал» — полностью соглашусь.
А насчет «набить команду сеньорами» — я вас скажу, это категорически противопоказано. Всегда должен быть баланс. Должны быть люди разного уровня в проекте, но это тема для отдельного разговора.
«А вот последствия ситуации, когда человека с уровнем подходящем для мидла, и которого брали как мидла, ставят выполнять задачи сениора — могут быть весьма плачевны»
Собственно, ниже я и писал, что если взять «думающего мидла», то он быстро наберет уровень и будет предлагать свежим взглядом интересные архитектурные решения.
А если взять «кодера, накопипастившего N-тысяч строк кода из гугла», то ситуация может стать плачевной, даже если его и не пускать к архитектуре.
Насчет «у всех разный уровень и потенциал» — полностью соглашусь.
А насчет «набить команду сеньорами» — я вас скажу, это категорически противопоказано. Всегда должен быть баланс. Должны быть люди разного уровня в проекте, но это тема для отдельного разговора.
>>Собственно, ниже я и писал, что если взять «думающего мидла», то он быстро наберет уровень и будет предлагать свежим взглядом интересные архитектурные решения.
И зачем Вы взяли мидла, если Вам нужен был сениор? Потому что он денег просил меньше? Вам не кажется, что это несколько неправильно, давать ему играться с реальным проектом, пока он набирается опыта?
>>Всегда должен быть баланс.
Полностью согласен. Нет, сениоры великолепно делают работу мидлов. Но не долго. Потому что увольняются (нафиг эту рутину!).
И зачем Вы взяли мидла, если Вам нужен был сениор? Потому что он денег просил меньше? Вам не кажется, что это несколько неправильно, давать ему играться с реальным проектом, пока он набирается опыта?
>>Всегда должен быть баланс.
Полностью согласен. Нет, сениоры великолепно делают работу мидлов. Но не долго. Потому что увольняются (нафиг эту рутину!).
«И зачем Вы взяли мидла, если Вам нужен был сениор? „
С чего вы решили, что был нужен сеньор? Уже был сеньор. Усиливали середину. Всегда стараюсь поддерживать баланс, чтобы было середины больше. Но есть и сеньоры, есть и джуниоры.
С чего вы решили, что был нужен сеньор? Уже был сеньор. Усиливали середину. Всегда стараюсь поддерживать баланс, чтобы было середины больше. Но есть и сеньоры, есть и джуниоры.
Подождите, так основная идея формирования команды — это поддержка балланса? Вы, простите, коллекционированием занимаетесь?
Смотрите — моя идея, это команда, которая ориентированна на решение задач. Нам нужно работать с друпалом? — ок, лучше взять человека который уже умеет это делать. Да, можно взять человека уровнем повыше, он разберётся. Но во-первых, Вы теряете неделю-две рабочего времени, а во-вторых — человеку просто не интересно будет клепать однообразные странички.
тут как с обычными хостингами — чтоб Выдержать нагрузку, которая бывает раз в год — Вы платите за мощный сервер всё время.
Смотрите — моя идея, это команда, которая ориентированна на решение задач. Нам нужно работать с друпалом? — ок, лучше взять человека который уже умеет это делать. Да, можно взять человека уровнем повыше, он разберётся. Но во-первых, Вы теряете неделю-две рабочего времени, а во-вторых — человеку просто не интересно будет клепать однообразные странички.
тут как с обычными хостингами — чтоб Выдержать нагрузку, которая бывает раз в год — Вы платите за мощный сервер всё время.
«Подождите, так основная идея формирования команды — это поддержка балланса? Вы, простите, коллекционированием занимаетесь?»
Я про проекты, где в команде (проекта) — читать, как над одним проектом работают вместе — работают несколько программистов, причем все разного уровня. И среди их уровня я стараюсь соблюдать баланс, чтобы были и люди, которые могли задать тон проекту, и научить, и те, кто набивал руку на более рутинных задачах и учился.
Может быть это все потому, что мой опыт — это не клепание сайтов визиток на друпале на потоке. Тогда извините, я не правильно воспринял многие ваши утверждение. Но только в моем понимании тогда это имеет очень мало общего с программированием. Я бы это назвал термином «сайтостроение». Там работают другие законы, этому рынку нужны другие люди и тд…
«тут как с обычными хостингами — чтоб Выдержать нагрузку, которая бывает раз в год — Вы платите за мощный сервер всё время.»
Я предпочту облако.
Я про проекты, где в команде (проекта) — читать, как над одним проектом работают вместе — работают несколько программистов, причем все разного уровня. И среди их уровня я стараюсь соблюдать баланс, чтобы были и люди, которые могли задать тон проекту, и научить, и те, кто набивал руку на более рутинных задачах и учился.
Может быть это все потому, что мой опыт — это не клепание сайтов визиток на друпале на потоке. Тогда извините, я не правильно воспринял многие ваши утверждение. Но только в моем понимании тогда это имеет очень мало общего с программированием. Я бы это назвал термином «сайтостроение». Там работают другие законы, этому рынку нужны другие люди и тд…
«тут как с обычными хостингами — чтоб Выдержать нагрузку, которая бывает раз в год — Вы платите за мощный сервер всё время.»
Я предпочту облако.
>>Я предпочту облако.
Точно! :) А облако — это как раз привлекать специалистов по мере их надобности. А не ради баланса. Я рад что Вы меня поняли.
>>Может быть это все потому, что мой опыт — это не клепание сайтов визиток на друпале на потоке. Тогда извините, я не правильно воспринял многие ваши утверждение
Пытаетесь меня задеть? :) Не получится, я тоже не визитки клепаю. Вот только дела это не меняет. Вот одна неделя из моей работы на хайлоаде — 1 задача по оптимизации быстродействия (часть кода ускорена в 12 раз) — 4 часа. Остальное время — рутинный рефакторинг. РУТИНА. Нет интересных задач, скука и тоска. Поэтому я оттуда и ушёл. Хотя сам проект был интересный. Проблема в том, что для программиста — практически везде тоже самое.
Точно! :) А облако — это как раз привлекать специалистов по мере их надобности. А не ради баланса. Я рад что Вы меня поняли.
>>Может быть это все потому, что мой опыт — это не клепание сайтов визиток на друпале на потоке. Тогда извините, я не правильно воспринял многие ваши утверждение
Пытаетесь меня задеть? :) Не получится, я тоже не визитки клепаю. Вот только дела это не меняет. Вот одна неделя из моей работы на хайлоаде — 1 задача по оптимизации быстродействия (часть кода ускорена в 12 раз) — 4 часа. Остальное время — рутинный рефакторинг. РУТИНА. Нет интересных задач, скука и тоска. Поэтому я оттуда и ушёл. Хотя сам проект был интересный. Проблема в том, что для программиста — практически везде тоже самое.
«Точно! :) А облако — это как раз привлекать специалистов по мере их надобности. А не ради баланса. Я рад что Вы меня поняли.»
Специалист — это не баланс и не ради баланса.
«Пытаетесь меня задеть? :) „
Ни в коем разе. Прошу простить, если был так понят. Просто действительно у разных людей есть разный опыт. И он очень сильно откладывает отпечаток. Я раньше не подразумевал даже, какой.
“Проблема в том, что для программиста — практически везде тоже самое.»
Ну спорный вопрос :)
Как говорится, либо прет, либо не прет. (не в плане «везет», а в качестве «в кайф делать»)
В целом я со многими вещами из статьи согласен (но не со всеми). В частности, готов «люто плюсовать» за ограничение времени собеседования. Иной раз, придешь сам на собеседование. И начинают рассказы / расспросы. После 2-3-его часа хочется прервать увлеченного собеседника и сказать «я завтра зайду… А лучше вы это… на почту напишите, если вопросы остались какие».
Специалист — это не баланс и не ради баланса.
«Пытаетесь меня задеть? :) „
Ни в коем разе. Прошу простить, если был так понят. Просто действительно у разных людей есть разный опыт. И он очень сильно откладывает отпечаток. Я раньше не подразумевал даже, какой.
“Проблема в том, что для программиста — практически везде тоже самое.»
Ну спорный вопрос :)
Как говорится, либо прет, либо не прет. (не в плане «везет», а в качестве «в кайф делать»)
В целом я со многими вещами из статьи согласен (но не со всеми). В частности, готов «люто плюсовать» за ограничение времени собеседования. Иной раз, придешь сам на собеседование. И начинают рассказы / расспросы. После 2-3-его часа хочется прервать увлеченного собеседника и сказать «я завтра зайду… А лучше вы это… на почту напишите, если вопросы остались какие».
PS к слову о рутине — попробуйте посмотреть новые технологии. Ими пестрит хабр. Можно открывать ооочень много нового чуть ли не каждый день.
Но мы ведь говорим о рутине в работе, а не в жизни, правда? А в рабочем проекте, который УЖЕ приносит деньги — как в военной технике — лучше годами проверенное старое, чем не пойми как работающее новое.
Открывать что-то новое — да, применять это в работе — не всегда. ТО есть в работе вполне может быть «все тоже самое»
На собеседованиях, часто вобще гоняют по той теме, которая интересна интервьюверу и в большинстве случаев никак вообще не связана с тем, чем придется заниматься.
Я обратил внимание на ответы «абстрактных» кандидатов:
«Ну», «Эмм», «Да там» говорят о сложностях при выражении своих мыслей, и, как следствие, неуверенности.
Возможно, интервьюверы не согласятся со мной (у меня нет этого опыта — мне сложно судить), но грамотно поставленная уверенная речь (без слов-паразитов и мычания) и прямая осанка добавляют поинтов к общему баллу оценки кандидата. На конференциях или на совещаниях человек, четко и грамотно выражающий свою мысль, привлечет больше внимания и симпатий, чем тот, кто запинается и «ну»-кает. Все мы знаем, что лучшими становятся не те, кто умнее всех. Я считаю, что на техническом собеседовании этот фактор тоже имеет немаловажное значение.
— Ну там была сложная система моделирующая систему городских коммуникаций с поиском оптимальных маршрутов и (…)
— Эмм, да, и что-то такое я слышал.
— Ну это адрес объекта
— Да там генератор случайный чисел, вот он и возвращает.
«Ну», «Эмм», «Да там» говорят о сложностях при выражении своих мыслей, и, как следствие, неуверенности.
Возможно, интервьюверы не согласятся со мной (у меня нет этого опыта — мне сложно судить), но грамотно поставленная уверенная речь (без слов-паразитов и мычания) и прямая осанка добавляют поинтов к общему баллу оценки кандидата. На конференциях или на совещаниях человек, четко и грамотно выражающий свою мысль, привлечет больше внимания и симпатий, чем тот, кто запинается и «ну»-кает. Все мы знаем, что лучшими становятся не те, кто умнее всех. Я считаю, что на техническом собеседовании этот фактор тоже имеет немаловажное значение.
О, это зависит от должности кандидата.
Если вы нанимаете технического директора или человека которого будете водить к партнерам, то вероятно это действительно очень важно.
Если же вы нанимаете программиста… Понимаете, программисты пишут код. Хорошие пишут код, плохие пишут код, и гениальные тоже пишут код. Именно код выражает результат труда программиста. Код это то, что запускается на компьютере когда вы ставите свою программу. Именно баги в коде буду донимать ваших пользователей. Именно продуманность кода даст вам конкурентное преимущество, когда вы перейдете на новую платформу и выпустите новую версию за неделю, в то время как ваши конкуренты второй месяц пытаются понять что там теперь падает.
Не так страшно, если программист плохо выражает свои мысли в словах. Страшно, если он плохо выражает их в коде.
Если вы нанимаете технического директора или человека которого будете водить к партнерам, то вероятно это действительно очень важно.
Если же вы нанимаете программиста… Понимаете, программисты пишут код. Хорошие пишут код, плохие пишут код, и гениальные тоже пишут код. Именно код выражает результат труда программиста. Код это то, что запускается на компьютере когда вы ставите свою программу. Именно баги в коде буду донимать ваших пользователей. Именно продуманность кода даст вам конкурентное преимущество, когда вы перейдете на новую платформу и выпустите новую версию за неделю, в то время как ваши конкуренты второй месяц пытаются понять что там теперь падает.
Не так страшно, если программист плохо выражает свои мысли в словах. Страшно, если он плохо выражает их в коде.
Программисты не только пишут код. Они общаются с другими программистами. Они — часть команды. И если с человеком трудно общаться — то пусть его код будет трижды гениален — я этого никогда не узнаю, потому что не возьму его на работу.
Вы черезчур категоричны. Есть люди, которые очень зависимы от окружения. От того, как Вы посмотрите на них на собеседовании, зависит — будут ли они молчать, или изливать Вам свою душу. Особенно это касается замкнутых людей, из которых получаются весьма неплохие программисты и сотрудники.
По сути дела, Вы должны понимать, что Вы платите за всё. За умение общаться и держать себя на встрече. За умение продать себя. За умение действительно программировать, в конце концов. Так что — Вам решать, за что же Вы всё таки будете платить зарплату человеку.
По сути дела, Вы должны понимать, что Вы платите за всё. За умение общаться и держать себя на встрече. За умение продать себя. За умение действительно программировать, в конце концов. Так что — Вам решать, за что же Вы всё таки будете платить зарплату человеку.
Ну немного категоричности не помешает, для придания живости обсуждению (см. комментарий ниже ) :)
На собеседовании мы сидим в нашем опенспейсе, все сотрудники видят кандидата и могут составть о нем представление. Если с технической точки зрения он нам подходит — второй вопрос — он сможет стать частью команды?
На моей памяти никто не спрашивал «зачем нам это?», все как-то сами понимали. И чьи-то кандидатуры мы после коллективного обсуждения отклонили, что поделать. Ну не хотят люди работать с этим человеком, зачем их заставлять, будем искать дальше. Плюс не факт, что самим кандидатам было бы у нас комфортно, так что эта палка о двух концах.
На собеседовании мы сидим в нашем опенспейсе, все сотрудники видят кандидата и могут составть о нем представление. Если с технической точки зрения он нам подходит — второй вопрос — он сможет стать частью команды?
На моей памяти никто не спрашивал «зачем нам это?», все как-то сами понимали. И чьи-то кандидатуры мы после коллективного обсуждения отклонили, что поделать. Ну не хотят люди работать с этим человеком, зачем их заставлять, будем искать дальше. Плюс не факт, что самим кандидатам было бы у нас комфортно, так что эта палка о двух концах.
Сам Ваш комментарий не предполагал такого развития событий. Ведь судя из него — Вы сначала бы решили, насколько хороший человек оратор — и лишь затем уже рассматривали бы его тех. возможности.
>>На собеседовании мы сидим в нашем опенспейсе, все сотрудники видят кандидата и могут составть о нем представление. Если с технической точки зрения он нам подходит — второй вопрос — он сможет стать частью команды?
Во время, когда нам нужны были программисты, мне приходилось участвовать в 2-3х собеседованиях в день. Вы считаете такая трата времени ВСЕМИ участниками группы — оправдана?
Я не помню случая, чтобы люди отказывались работать с кандидатом, если тот «некрасиво» выражал свою мысль или был через чур застенчивым. Обычно наоборот — отсеивают заносчивых и самоуверенных. А ещё — тех кто представляет опасность в плане конкуренции или не поддерживает веру в священную корову команды — например, самописный фреймворк, ненужность тестов, какието паттерны. Так что — не всегда следует тупо верить тому, что говорит команда, особенно когда от её имени говорит кто-то один.
>>На собеседовании мы сидим в нашем опенспейсе, все сотрудники видят кандидата и могут составть о нем представление. Если с технической точки зрения он нам подходит — второй вопрос — он сможет стать частью команды?
Во время, когда нам нужны были программисты, мне приходилось участвовать в 2-3х собеседованиях в день. Вы считаете такая трата времени ВСЕМИ участниками группы — оправдана?
Я не помню случая, чтобы люди отказывались работать с кандидатом, если тот «некрасиво» выражал свою мысль или был через чур застенчивым. Обычно наоборот — отсеивают заносчивых и самоуверенных. А ещё — тех кто представляет опасность в плане конкуренции или не поддерживает веру в священную корову команды — например, самописный фреймворк, ненужность тестов, какието паттерны. Так что — не всегда следует тупо верить тому, что говорит команда, особенно когда от её имени говорит кто-то один.
я лишь сказал, что «не кодом единым»… а мне уже приписали бог знает что: растрату времени команды, сначала оратор, затем программист, опасность в плане конкуренции и прочая и прочая :)
гениальный код — не самоцель. он не должен обязательно быть гениальным, он должен быть «достаточно хорош»
и «умение играть в команде» не менее важно
вот и все, что я хотел сказать
гениальный код — не самоцель. он не должен обязательно быть гениальным, он должен быть «достаточно хорош»
и «умение играть в команде» не менее важно
вот и все, что я хотел сказать
Ну и будете работать с жизнерадостными и разговорчивыми лентяями и безграмотными специалистами.
Извините, но это бред. Вы ищете пиарщика, что ли?, который речи будет толкать перед публикой? Или грамотного технчиеского специалиста? И уж так сплеча рубить при одном лишь употреблении слов-паразитов — это явно перебор. И, конечно же, человек при собеседовании совсем не волнуется и все его проблемы речи исключительно от неуверенности, да.
1. «Неуверенность» — это вообще ниочём. Масса программистов слегка социопаты, это в ваших там всяких холиварных интернетах смелые, а в автобусе нахамили — и ой. Я говорю не о том, что это хорошо/плохо, я говорю, что это так.
2. Я знал одного программера, он скорее говорил вот этими «гм», «ну» и «типа». А как программер — замечательный, великолепный, сейчас где-то на Силиконщине.
>>На конференциях или на совещаниях человек, четко и грамотно выражающий свою мысль, привлечет больше внимания и симпатий
Неумение сформулировать требования — это бич HR-ов. Ну казалось бы, так и пишите: «для выступлениях на конференциях требуется человек с хорошей дикцией, опыт активного исспользования риторики и софистики не менее 5 лет»… Нет, всякие «C++ boost» зачем-то лепят…
2. Я знал одного программера, он скорее говорил вот этими «гм», «ну» и «типа». А как программер — замечательный, великолепный, сейчас где-то на Силиконщине.
>>На конференциях или на совещаниях человек, четко и грамотно выражающий свою мысль, привлечет больше внимания и симпатий
Неумение сформулировать требования — это бич HR-ов. Ну казалось бы, так и пишите: «для выступлениях на конференциях требуется человек с хорошей дикцией, опыт активного исспользования риторики и софистики не менее 5 лет»… Нет, всякие «C++ boost» зачем-то лепят…
А при чём здесь вообще неуверенность?
Что бы грамотно ответить на технический вопрос по заранее неизвестной области нужно какое-то время на формулирование этого ответа. Обычно несколько секунд. И если эти несколько секунд молчать, то оппонент решит, что его вообще не услышали.
Что бы грамотно ответить на технический вопрос по заранее неизвестной области нужно какое-то время на формулирование этого ответа. Обычно несколько секунд. И если эти несколько секунд молчать, то оппонент решит, что его вообще не услышали.
Тут такое дело… иногда кандидаты приходят во-первых после основной работы, а во-вторых они иногда и волнуются (таких очень много), поэтому на всякие «ну», «эмм», «да там» и прочие сложности выражения мыслей можно не брать в расчет, если их количество укладываются в какие-то нормы, которые, конечно же определяете вы сами.
А я на собеседованиях предлагал алгоритмы порешать. Можно даже на абстрактном языке.
Многие говорят заученные фразы из википедии о том, что такое синглтон, а когда либо даешь человеку минут 5 написать на бумажке, либо по скайпу в расшаренном документе написать, то сразу видишь и ход его мыслей, и понимает ли, он как работает.
Как показала практика, знание ньюансов различных инструментов, безусловно, важны. Но умение думать — гораздо важнее. Освоить можно любой инструмент. А решать задачи нестандартные дано не каждому.
Многие говорят заученные фразы из википедии о том, что такое синглтон, а когда либо даешь человеку минут 5 написать на бумажке, либо по скайпу в расшаренном документе написать, то сразу видишь и ход его мыслей, и понимает ли, он как работает.
Как показала практика, знание ньюансов различных инструментов, безусловно, важны. Но умение думать — гораздо важнее. Освоить можно любой инструмент. А решать задачи нестандартные дано не каждому.
Скажите, а вашим программистам действительно приходится большую часть времени заниматся изобретением велосипедов и нестандартными задачами?
Я разве сказал, что программист должен уметь изобретать велосипеды?
А насчет решений нестандартных задач. Знаете, бывает. Не часто, но когда встала задача то сеньоры, которые «не практиковали и не любили задачи, но были с большим опытом» сели на этой задачи, а вот мидлы, у которых не было опыта с хайлоадами, у которых не было богатого опыта, но которые в свободное время разбирали алгоритмы, а за обедом — загадки на логику разбирали, весьма быстро решили эту задачу.
Это не замена опыту и другому техническому багажу, я это не пытаюсь сказать. Это лишь означает, что человек будет сразу думать о том, как эту задачу можно решить оптимальнее, и рост у него будет значительно быстрее и качественнее.
Ну и пользы такой человек может принести гораздо больше.
А насчет решений нестандартных задач. Знаете, бывает. Не часто, но когда встала задача то сеньоры, которые «не практиковали и не любили задачи, но были с большим опытом» сели на этой задачи, а вот мидлы, у которых не было опыта с хайлоадами, у которых не было богатого опыта, но которые в свободное время разбирали алгоритмы, а за обедом — загадки на логику разбирали, весьма быстро решили эту задачу.
Это не замена опыту и другому техническому багажу, я это не пытаюсь сказать. Это лишь означает, что человек будет сразу думать о том, как эту задачу можно решить оптимальнее, и рост у него будет значительно быстрее и качественнее.
Ну и пользы такой человек может принести гораздо больше.
>>Я разве сказал, что программист должен уметь изобретать велосипеды?
>>Многие говорят заученные фразы из википедии о том, что такое синглтон, а когда либо даешь человеку минут 5 написать на бумажке, либо по скайпу в расшаренном документе написать, то сразу видишь и ход его мыслей, и понимает ли, он как работает.
Я понял это как то, что Вы своим кандидатам даёте написать реализацию синглтона.
Смотрите — Вы сами говорите, что нестандартное мышление и так далее — нужно не часто. Практика подсказывает, что большинство задач, с тем же хайлоадом решается гуглением, и применением стандартных инструментов. А теперь вопрос — зачем же Вы на собеседовании спрашиваете человека о том, что ему прийдётся делать довольно редко? Не лучше ли спросить то, что ему придётся делать постоянно?
Впрочем, что это я — и сам подобным грешил. И знаю ответ, почему так — потому что это интересно. Смотреть как человек делает страничку на друпале, или перелицовывает стандартный элемент — скука. А тут — есть где пообсуждать, поспорить, получить удовольствие от беседы (особенно если кандидат действительно толковый). Вот только с выбором идеального кандидата это не имеет ничего общего.
>>Многие говорят заученные фразы из википедии о том, что такое синглтон, а когда либо даешь человеку минут 5 написать на бумажке, либо по скайпу в расшаренном документе написать, то сразу видишь и ход его мыслей, и понимает ли, он как работает.
Я понял это как то, что Вы своим кандидатам даёте написать реализацию синглтона.
Смотрите — Вы сами говорите, что нестандартное мышление и так далее — нужно не часто. Практика подсказывает, что большинство задач, с тем же хайлоадом решается гуглением, и применением стандартных инструментов. А теперь вопрос — зачем же Вы на собеседовании спрашиваете человека о том, что ему прийдётся делать довольно редко? Не лучше ли спросить то, что ему придётся делать постоянно?
Впрочем, что это я — и сам подобным грешил. И знаю ответ, почему так — потому что это интересно. Смотреть как человек делает страничку на друпале, или перелицовывает стандартный элемент — скука. А тут — есть где пообсуждать, поспорить, получить удовольствие от беседы (особенно если кандидат действительно толковый). Вот только с выбором идеального кандидата это не имеет ничего общего.
«5 написать на бумажке, либо по скайпу в расшаренном документе написать, то сразу видишь и ход его мыслей, и понимает ли, он как работает.
Я понял это как то, что Вы своим кандидатам даёте написать реализацию синглтона.»
Синглтон я привел для примера. Как правило, каждый раз я даю индивидуально задачу. Опять таки, смотрю на должность, на навыки и опыт человека, и пытаюсь приценится «как он может быть полезен мне и компании».
А дальше лишь проверяю, насколько он действительно компетентен. Иногда хватает вопроса и про реализацию множественного наследования в php.
— Его нет
— А если будет нужно, как будете делать
— Никак, это невозможно
— А знаком термин traits
— Да, слышал, в новой версии появилось.
И я понимаю, что даже гугл не поможет человеку. А я ожидал услышать хотя бы вопрос «А какую задачу то решаем?»
«Смотрите — Вы сами говорите, что нестандартное мышление и так далее — нужно не часто.»
Нестандартное решение — может быть, а умение думать нужно всегда. ИМХО.
«Практика подсказывает, что большинство задач, с тем же хайлоадом решается гуглением, и применением стандартных инструментов. А теперь вопрос — зачем же Вы на собеседовании спрашиваете человека о том, что ему прийдётся делать довольно редко? Не лучше ли спросить то, что ему придётся делать постоянно?»
Мы сейчас говорим о собеседовании на роль джуниора-тайпера, или мидл-сеньора, который еще и умеет задачи решать? Знаете, обезьянку даже можно научить делать однотипные задачи. Или вам нужно убедиться в том, что человек за месяц научится писать красивые джоины? Или Регулярку для проверки валидности email? Только я сомневаюсь, что такой человек будет часто выходить из «зоны комфорта» и экспериментировать, а следовательно, я бы не стал ждать от него, что он будет осмысленно понимать, когда нужно регулярку вставить, а когда достаточно стандартные фильтры php поставить, когда нужно сделать ненормализованную структуру БД. Вы уверены, что вы в гугле сможете найти ответы на все свои вопросы?
Да, не спорю, человек сможет найти и регулярку. Да, вы можете сказать зачем ему уметь писать, если в нете их дофига. А вы пустите этого человека к архитектуре проекта? Я нет. Тогда еще раз задам вопрос — мы про какую позицию говорим — джуниора-тайпера или все же посильнее?
Я понял это как то, что Вы своим кандидатам даёте написать реализацию синглтона.»
Синглтон я привел для примера. Как правило, каждый раз я даю индивидуально задачу. Опять таки, смотрю на должность, на навыки и опыт человека, и пытаюсь приценится «как он может быть полезен мне и компании».
А дальше лишь проверяю, насколько он действительно компетентен. Иногда хватает вопроса и про реализацию множественного наследования в php.
— Его нет
— А если будет нужно, как будете делать
— Никак, это невозможно
— А знаком термин traits
— Да, слышал, в новой версии появилось.
И я понимаю, что даже гугл не поможет человеку. А я ожидал услышать хотя бы вопрос «А какую задачу то решаем?»
«Смотрите — Вы сами говорите, что нестандартное мышление и так далее — нужно не часто.»
Нестандартное решение — может быть, а умение думать нужно всегда. ИМХО.
«Практика подсказывает, что большинство задач, с тем же хайлоадом решается гуглением, и применением стандартных инструментов. А теперь вопрос — зачем же Вы на собеседовании спрашиваете человека о том, что ему прийдётся делать довольно редко? Не лучше ли спросить то, что ему придётся делать постоянно?»
Мы сейчас говорим о собеседовании на роль джуниора-тайпера, или мидл-сеньора, который еще и умеет задачи решать? Знаете, обезьянку даже можно научить делать однотипные задачи. Или вам нужно убедиться в том, что человек за месяц научится писать красивые джоины? Или Регулярку для проверки валидности email? Только я сомневаюсь, что такой человек будет часто выходить из «зоны комфорта» и экспериментировать, а следовательно, я бы не стал ждать от него, что он будет осмысленно понимать, когда нужно регулярку вставить, а когда достаточно стандартные фильтры php поставить, когда нужно сделать ненормализованную структуру БД. Вы уверены, что вы в гугле сможете найти ответы на все свои вопросы?
Да, не спорю, человек сможет найти и регулярку. Да, вы можете сказать зачем ему уметь писать, если в нете их дофига. А вы пустите этого человека к архитектуре проекта? Я нет. Тогда еще раз задам вопрос — мы про какую позицию говорим — джуниора-тайпера или все же посильнее?
>>Тогда еще раз задам вопрос — мы про какую позицию говорим — джуниора-тайпера или все же посильнее?
Этот вопрос стоило задать и ответить перед тем как писать первый комментарий. А я впрочем, уже писал, что то, что простительно для джуниора — не простительно для сениора.
>>Только я сомневаюсь, что такой человек будет часто выходить из «зоны комфорта» и экспериментировать
На продакшене не нужны эксперементы, если Вы только не гугл или фейсбук. Если Вы делаете технически не выдающийся проект (99% случаев) то все проблемы уже решены до Вас. И как раз человек, который вместо настройки сфинкса начнёт «эксперементировать» со своей тулзой — представляет опасность для проекта.
Я мог бы разобрать и этот комментарий, и ответить на каждую строчку — но ответы есть в других моих комментариях.
Поэтому я лишь назову свою позицию:
Если Вы нанимаете человека на работу, значит у вас есть конкретная проблема, которую этот человек будет решать.Если Вы нанимаете человека, чтобы он решал некую конкретную проблему — так проверте насколько он подходит для решения этой конкретной проблемы.
Этот вопрос стоило задать и ответить перед тем как писать первый комментарий. А я впрочем, уже писал, что то, что простительно для джуниора — не простительно для сениора.
>>Только я сомневаюсь, что такой человек будет часто выходить из «зоны комфорта» и экспериментировать
На продакшене не нужны эксперементы, если Вы только не гугл или фейсбук. Если Вы делаете технически не выдающийся проект (99% случаев) то все проблемы уже решены до Вас. И как раз человек, который вместо настройки сфинкса начнёт «эксперементировать» со своей тулзой — представляет опасность для проекта.
Я мог бы разобрать и этот комментарий, и ответить на каждую строчку — но ответы есть в других моих комментариях.
Поэтому я лишь назову свою позицию:
Если Вы нанимаете человека на работу, значит у вас есть конкретная проблема, которую этот человек будет решать.Если Вы нанимаете человека, чтобы он решал некую конкретную проблему — так проверте насколько он подходит для решения этой конкретной проблемы.
уфф… Уже достаточно написал. Повторяться не буду.
Лишь один вопрос задам.
«Если Вы нанимаете человека на работу, значит у вас есть конкретная проблема, которую этот человек будет решать.Если Вы нанимаете человека, чтобы он решал некую конкретную проблему — так проверте насколько он подходит для решения этой конкретной проблемы.»
А что вы будете делать с человеком, когда эту проблему решите? А если поймете, что под другие задачи он не подходит? Увольнять? А как команде работать в условиях текучки кадров? Сильно не экспериментировал, но по моим субъективным ощущениям, производительность ВСЕЙ команды очень значительно упадет.
Лишь один вопрос задам.
«Если Вы нанимаете человека на работу, значит у вас есть конкретная проблема, которую этот человек будет решать.Если Вы нанимаете человека, чтобы он решал некую конкретную проблему — так проверте насколько он подходит для решения этой конкретной проблемы.»
А что вы будете делать с человеком, когда эту проблему решите? А если поймете, что под другие задачи он не подходит? Увольнять? А как команде работать в условиях текучки кадров? Сильно не экспериментировал, но по моим субъективным ощущениям, производительность ВСЕЙ команды очень значительно упадет.
>> А что вы будете делать с человеком, когда эту проблему решите? А если поймете, что под другие задачи он не подходит? Увольнять?
Да. А команда как работала без него — так и продолжит. Я надеюсь Вы понимаете, что проблема не ставится как «нам нужен человек чтоб настроить XXX — давайте его наймём, он два дня проработает и уволим». Некоторые задачи действительно проще отдать на оутсорс, чем решать внутри команды.
По сути, описанный Вами сценарий работает, если только мы меняем поле деятельности. Скажем у нас была разработка на джумле, по каким-то причинам перешли на друпал. 7 человек справилось, один не тянет. Ну и что с ним прикажете делать?
Ещё раз, мы не пиво пить собираемся. Мы работу делаем.
Да. А команда как работала без него — так и продолжит. Я надеюсь Вы понимаете, что проблема не ставится как «нам нужен человек чтоб настроить XXX — давайте его наймём, он два дня проработает и уволим». Некоторые задачи действительно проще отдать на оутсорс, чем решать внутри команды.
По сути, описанный Вами сценарий работает, если только мы меняем поле деятельности. Скажем у нас была разработка на джумле, по каким-то причинам перешли на друпал. 7 человек справилось, один не тянет. Ну и что с ним прикажете делать?
Ещё раз, мы не пиво пить собираемся. Мы работу делаем.
А к слову о велосипедах… Поиск N-го числа Фибаначи и оценка сложности алгоритма, которым решена задача вместе с ответом на следующий вопрос «а можно лучше? И, если да, то почему вы предложили именно такое решение?» в моем понимании никогда не было изобретением велосипедов.
В моем понимании, есть такое качество у людей, как общая техническая грамотность.
В одном замечательном военном вузе у меня был преподаватель. Полковник далекого запаса. Войну еще прошел. Преподавал секретную дисциплину, но мы сами были ИТ-ишниками по сути.
Когда на экзамене / зачете кто-то не мог ответить на его вопрос по предмету, всякое бывает, он пытался вытянуть. И то, как он это делал, мне запомнилось на всю жизнь. Он переходил на вопросы по специальности, со словами «Ну я понимаю, что предмет у меня своеобразный. Но тогда давайте поговорим о вашей специальности, ведь я понимаю, что для вас это важнее». Если снова не помогало, он говорил, «Хм… Тогда вы наверно интересуетесь современными технологиями». И если получал утвердительный ответ, но просил рассказать, что последнего узнал человек. Либо задавал вопросы, например «Вот на прошлой неделе, я читал, NVidia выпустила новую видеокарту. Расскажите, что они там придумали интересного. Ведь архитектура реализации доступа к памяти там — по сути революционная. Я когда прочитал это, даже был потрясен».
На такие вопросы еще реже находился ответ. Тогда он переходил к городам. Спрашивал из какого города. И задавал вопрос об истории города, и надо заметить, что тут он тоже валил очень многих.
Он учил нас изобретать велосипеды? Нет, он учил грамотно подходить к решению задач, быть технически грамотными и подготовленными, постоянно развиваться и расти.
PS извините за много букв.
В моем понимании, есть такое качество у людей, как общая техническая грамотность.
В одном замечательном военном вузе у меня был преподаватель. Полковник далекого запаса. Войну еще прошел. Преподавал секретную дисциплину, но мы сами были ИТ-ишниками по сути.
Когда на экзамене / зачете кто-то не мог ответить на его вопрос по предмету, всякое бывает, он пытался вытянуть. И то, как он это делал, мне запомнилось на всю жизнь. Он переходил на вопросы по специальности, со словами «Ну я понимаю, что предмет у меня своеобразный. Но тогда давайте поговорим о вашей специальности, ведь я понимаю, что для вас это важнее». Если снова не помогало, он говорил, «Хм… Тогда вы наверно интересуетесь современными технологиями». И если получал утвердительный ответ, но просил рассказать, что последнего узнал человек. Либо задавал вопросы, например «Вот на прошлой неделе, я читал, NVidia выпустила новую видеокарту. Расскажите, что они там придумали интересного. Ведь архитектура реализации доступа к памяти там — по сути революционная. Я когда прочитал это, даже был потрясен».
На такие вопросы еще реже находился ответ. Тогда он переходил к городам. Спрашивал из какого города. И задавал вопрос об истории города, и надо заметить, что тут он тоже валил очень многих.
Он учил нас изобретать велосипеды? Нет, он учил грамотно подходить к решению задач, быть технически грамотными и подготовленными, постоянно развиваться и расти.
PS извините за много букв.
>>Поиск N-го числа Фибаначи и оценка сложности алгоритма, которым решена задача вместе с ответом на следующий вопрос «а можно лучше? И, если да, то почему вы предложили именно такое решение?»
И как часто Вам это надо на практике?
>>В моем понимании, есть такое качество у людей, как общая техническая грамотность.
Опять таки, насколько это Вам важно на практике?
И вообще, Вы понимаете разницу между преподавателем и работодателем?
Не нужно мешать свои интересы, хобби и работу. То что Вы болеете за один футбольный клуб, или оба вчера парились с установкой последнего обновления андроида — ещё не значит что кандидат сможет справляться со своими обязанностями.
И как часто Вам это надо на практике?
>>В моем понимании, есть такое качество у людей, как общая техническая грамотность.
Опять таки, насколько это Вам важно на практике?
И вообще, Вы понимаете разницу между преподавателем и работодателем?
Не нужно мешать свои интересы, хобби и работу. То что Вы болеете за один футбольный клуб, или оба вчера парились с установкой последнего обновления андроида — ещё не значит что кандидат сможет справляться со своими обязанностями.
Сейчас даже «тайперы», или как их еще любят называть, «кодеры» весьма не дешевые, поэтому я предпочитаю переплатить и взять думающего программиста.
А дальше лишь грамотное управление этими людьми, подкидывание им пищи и возможность развиваться и расти.
Поэтому мне это нужно на практике и достаточно часто. Я сам стараюсь развиваться и использовать более оптимальные алгоритмы и решения.
У меня есть замечательные друзья, которых я считаю высококлассными профи. У них выбор технологий, на которых будет реализован тот или иной продукт основывается не на «мы это умеем», а на основе «так будет лучше потому что ....» Они владеют различным стеком, от php до различных ява, питонов, скала, грейлс.
А насчет преподавателем и работодателем… Наверно у нас с вами был разный опыт, поэтому нам не понять друг друга. Когда ты понимаешь, что стандартное решение на php встроенными средствами, использует не самый оптимальный алгоритм. Для решения задачи достаточно порядка 20-30 строк кода на си, а ускорение производительности порядка 8 раз. Как вы считаете, это чисто академические знания, или они нужны на практике?
Думаю, что вопрос лучше оставить риторическим. Скажу лишь, что мне они нужны и я их стараюсь применять.
А дальше лишь грамотное управление этими людьми, подкидывание им пищи и возможность развиваться и расти.
Поэтому мне это нужно на практике и достаточно часто. Я сам стараюсь развиваться и использовать более оптимальные алгоритмы и решения.
У меня есть замечательные друзья, которых я считаю высококлассными профи. У них выбор технологий, на которых будет реализован тот или иной продукт основывается не на «мы это умеем», а на основе «так будет лучше потому что ....» Они владеют различным стеком, от php до различных ява, питонов, скала, грейлс.
А насчет преподавателем и работодателем… Наверно у нас с вами был разный опыт, поэтому нам не понять друг друга. Когда ты понимаешь, что стандартное решение на php встроенными средствами, использует не самый оптимальный алгоритм. Для решения задачи достаточно порядка 20-30 строк кода на си, а ускорение производительности порядка 8 раз. Как вы считаете, это чисто академические знания, или они нужны на практике?
Думаю, что вопрос лучше оставить риторическим. Скажу лишь, что мне они нужны и я их стараюсь применять.
>>Для решения задачи достаточно порядка 20-30 строк кода на си, а ускорение производительности порядка 8 раз.
Ооо, обожаю С. За возможность в 20 строках прострелить себе ногу. Нет правда, это заставляет думать головой. А вот насколько нужен этот прирост производительности в отдельно взятой функции?.. Не гоняетесь ли Вы за призраком?
В вашем комментарии нет ни строчки о том, как «думающий» человек будет лучше справлятся со своими повседневными обязанностями. Расти, развиваться, придумывать сложные решения — всё супер. А работать кто будет?
Ооо, обожаю С. За возможность в 20 строках прострелить себе ногу. Нет правда, это заставляет думать головой. А вот насколько нужен этот прирост производительности в отдельно взятой функции?.. Не гоняетесь ли Вы за призраком?
В вашем комментарии нет ни строчки о том, как «думающий» человек будет лучше справлятся со своими повседневными обязанностями. Расти, развиваться, придумывать сложные решения — всё супер. А работать кто будет?
Есть люди, которым говорят «Вот тебе интерфейс, напиши по нему такой то метод / класс и тд, который делает вот то то и так то. Вот тебе диаграмма классов». Он сидит и тайпит.
Есть вариант похуже. Ему просто говорят «напиши, нам горит». Он не выдумывает свои велосипеды, ибо сам руками ничего без гугла написать не может — ищет первое попавшееся более менее подходящее решение и начинает его «подхачивать» под свою задачу. Тратит времени на реализацию — ну достаточно минимум. Но в памяти мало чего отложит у себя. (Если я вас верно понял, то это идеальный кандидат в вашем понимании. Он минимально отвлекается и минимально думает «дабы не навредить»).
Теперь масштабируем случай. Задача чуть чуть не стандартная. Решения вроде бы и рядом, писать самому лень, хочется найти готовое решение. И он тратит много времени на то, чтобы найти, нежели взять и сделать самому.
А теперь по другому — спустя месяц ему надо будет сделать такую же задачу на другом проекте. Его решение — снова гугл? ок.
Теперь рассмотрим последний случай — человек, которые задается вопросом, «что», «для чего» и «почему именно так» делаем. Такие люди кстати, достаточное количество раз экономили кучу времени при хреновых PM ах на проекте.
«Ооо, обожаю С. За возможность в 20 строках прострелить себе ногу. Нет правда, это заставляет думать головой. А вот насколько нужен этот прирост производительности в отдельно взятой функции?.. Не гоняетесь ли Вы за призраком?»
Вообще не понял, что вы хотели этим сказать.
Есть вариант похуже. Ему просто говорят «напиши, нам горит». Он не выдумывает свои велосипеды, ибо сам руками ничего без гугла написать не может — ищет первое попавшееся более менее подходящее решение и начинает его «подхачивать» под свою задачу. Тратит времени на реализацию — ну достаточно минимум. Но в памяти мало чего отложит у себя. (Если я вас верно понял, то это идеальный кандидат в вашем понимании. Он минимально отвлекается и минимально думает «дабы не навредить»).
Теперь масштабируем случай. Задача чуть чуть не стандартная. Решения вроде бы и рядом, писать самому лень, хочется найти готовое решение. И он тратит много времени на то, чтобы найти, нежели взять и сделать самому.
А теперь по другому — спустя месяц ему надо будет сделать такую же задачу на другом проекте. Его решение — снова гугл? ок.
Теперь рассмотрим последний случай — человек, которые задается вопросом, «что», «для чего» и «почему именно так» делаем. Такие люди кстати, достаточное количество раз экономили кучу времени при хреновых PM ах на проекте.
«Ооо, обожаю С. За возможность в 20 строках прострелить себе ногу. Нет правда, это заставляет думать головой. А вот насколько нужен этот прирост производительности в отдельно взятой функции?.. Не гоняетесь ли Вы за призраком?»
Вообще не понял, что вы хотели этим сказать.
>>Такие люди кстати, достаточное количество раз экономили кучу времени при хреновых PM ах на проекте.
А ПМ-ы то почему у вас паршивые? :). Знаете, каждый должен выполнять свою задачу. Да, в условиях, когда никто не знает куда бежать — универсальные бойцы лучше. Они хоть смогут свою работу спланировать, выбить требования, и как то двигать проект дальше. Но и стоят они значительно дороже.
Мне не понятна Ваша логика. Вы говорите что взяли человека который не преспособлен для решения нестандартных задач, а потом подсовываете ему нестандартную задачу. И дескать — он её не решит, или решит плохо. Но извините, это Ваша вина, как руководителя.
Как правило не более 1-2% всех задач — действительно интересны. Тоесть один «гениальный» человек на 10 обычных — вполне достаточно, чтобы решать все «нестандартные» задачи. И стоить это будет намного дешевле 10 гениев (тот самый баланс). да и 10 гениев просто передерутся, чьё решение лучше.
А ПМ-ы то почему у вас паршивые? :). Знаете, каждый должен выполнять свою задачу. Да, в условиях, когда никто не знает куда бежать — универсальные бойцы лучше. Они хоть смогут свою работу спланировать, выбить требования, и как то двигать проект дальше. Но и стоят они значительно дороже.
Мне не понятна Ваша логика. Вы говорите что взяли человека который не преспособлен для решения нестандартных задач, а потом подсовываете ему нестандартную задачу. И дескать — он её не решит, или решит плохо. Но извините, это Ваша вина, как руководителя.
Как правило не более 1-2% всех задач — действительно интересны. Тоесть один «гениальный» человек на 10 обычных — вполне достаточно, чтобы решать все «нестандартные» задачи. И стоить это будет намного дешевле 10 гениев (тот самый баланс). да и 10 гениев просто передерутся, чьё решение лучше.
1) Не всегда PM в рамках нашей компании.
2) Я не всегда отвечаю за PM, PO и другой менеджерский состав.
«Мне не понятна Ваша логика. Вы говорите что взяли человека который не преспособлен для решения нестандартных задач, а потом подсовываете ему нестандартную задачу. И дескать — он её не решит, или решит плохо. Но извините, это Ваша вина, как руководителя.»
ГДЕ Я ЭТО СКАЗАЛ? o_O?
Я сказал ровно следующее — в компании на проекте был сеньор, который был классным спецом, но не любил думать, придумывать решения, задумываться над производительностью и тд. Он заложил хорошую архитектуру, которую уже неоднократно использовал в других проектах, Но когда встала задача, которая потребовала нестандартного решения, которое не гуглится просто так, он оказался бессилен, так как думать не любил. не то, чтобы он отказался решать эту задачу. Нет, речь о другом. Речь о том, что люди, которых также взяли на проект, и они хорошо относились к таким задачкам, гораздо лучше проявили себя. И круг задач, на которых «они проявляли себя значительно лучше», а также их рост был значительно лучше.
Просьба не перевирать мои слова. Это не красиво.
" Но и стоят они значительно дороже." Хм… не знаю. Но последних людей, которых мы взяли на позицию мидлов, они значительно дешевле сеньоров.
«Как правило не более 1-2% всех задач — действительно интересны. Тоесть один «гениальный» человек на 10 обычных — вполне достаточно, чтобы решать все «нестандартные» задачи. И стоить это будет намного дешевле 10 гениев (тот самый баланс). да и 10 гениев просто передерутся, чьё решение лучше.»
1) Насчет 1-2 процентов задач. Не знаю как у вы, но я с конвейре по разработке сайтов визиток на потоке давно ушел.
2) Насчет гениев и тд — я выше писал возражение вам, что в команде не должны быть все сеньоры. Речь в том числе и об этом.
2) Я не всегда отвечаю за PM, PO и другой менеджерский состав.
«Мне не понятна Ваша логика. Вы говорите что взяли человека который не преспособлен для решения нестандартных задач, а потом подсовываете ему нестандартную задачу. И дескать — он её не решит, или решит плохо. Но извините, это Ваша вина, как руководителя.»
ГДЕ Я ЭТО СКАЗАЛ? o_O?
Я сказал ровно следующее — в компании на проекте был сеньор, который был классным спецом, но не любил думать, придумывать решения, задумываться над производительностью и тд. Он заложил хорошую архитектуру, которую уже неоднократно использовал в других проектах, Но когда встала задача, которая потребовала нестандартного решения, которое не гуглится просто так, он оказался бессилен, так как думать не любил. не то, чтобы он отказался решать эту задачу. Нет, речь о другом. Речь о том, что люди, которых также взяли на проект, и они хорошо относились к таким задачкам, гораздо лучше проявили себя. И круг задач, на которых «они проявляли себя значительно лучше», а также их рост был значительно лучше.
Просьба не перевирать мои слова. Это не красиво.
" Но и стоят они значительно дороже." Хм… не знаю. Но последних людей, которых мы взяли на позицию мидлов, они значительно дешевле сеньоров.
«Как правило не более 1-2% всех задач — действительно интересны. Тоесть один «гениальный» человек на 10 обычных — вполне достаточно, чтобы решать все «нестандартные» задачи. И стоить это будет намного дешевле 10 гениев (тот самый баланс). да и 10 гениев просто передерутся, чьё решение лучше.»
1) Насчет 1-2 процентов задач. Не знаю как у вы, но я с конвейре по разработке сайтов визиток на потоке давно ушел.
2) Насчет гениев и тд — я выше писал возражение вам, что в команде не должны быть все сеньоры. Речь в том числе и об этом.
А насчет последнего — считаю, что нужно поддерживать дружеские взаимоотношение и теплую атмосферу в коллективе. В проекте самое главное — это люди.
Это не означает, что надо делиться чем то личным, или залезать человеку в душу. А вот насчет обсуждений последних обновлений, футбольных клубов и тд — мне кажется, мы о разном говорим. Я же не требую правильного ответа. Но если человек сразу говорит, что я не знаю даже что это такое, так что я сдаюсь. Я ему подсказываю алгоритм образования ряда. Если мыслей вслух не начинает возникать, но я не стану надеяться на то, что человек испугался, а вот «дай ему гугл, так сразу произойдет чудо».
Это не означает, что надо делиться чем то личным, или залезать человеку в душу. А вот насчет обсуждений последних обновлений, футбольных клубов и тд — мне кажется, мы о разном говорим. Я же не требую правильного ответа. Но если человек сразу говорит, что я не знаю даже что это такое, так что я сдаюсь. Я ему подсказываю алгоритм образования ряда. Если мыслей вслух не начинает возникать, но я не стану надеяться на то, что человек испугался, а вот «дай ему гугл, так сразу произойдет чудо».
нестандартными
А что в вашем понимании — стандартные задачи
А что в вашем понимании — стандартные задачи
Ну я понял по комментариям, что разработка на конвейере на паблик CMS а ля джумла / друпал.
Поправьте меня, если я понял не верно.
Поправьте меня, если я понял не верно.
Тут просто дело в том, что иногда «стандартные» задачи бывают относительно сложны и интересны.
Согласен. Практически любую задачу можно решить по разному.
Иногда это «затайпить», а иногда еще и подумать почему так делали раньше, и почему сейчас нужно именно так. Это не занимает много времени и с лихвой окупает себя в конечном счете.
Я только прошу не вгонять в крайности на тему «я не грудь стану, но не дам джуниор пхпшнику экспериментировать с настройкой продакшн сервера, даже если ему очень хочется».
«Внимательный читатель поймет о чем идет речь» (с)
Иногда это «затайпить», а иногда еще и подумать почему так делали раньше, и почему сейчас нужно именно так. Это не занимает много времени и с лихвой окупает себя в конечном счете.
Я только прошу не вгонять в крайности на тему «я не грудь стану, но не дам джуниор пхпшнику экспериментировать с настройкой продакшн сервера, даже если ему очень хочется».
«Внимательный читатель поймет о чем идет речь» (с)
Оглянитесь на неделю своего рабочего времени и скажите — сколько времени Вы занимаетесь реально интересными задачами, а сколько — рутиной.
Хотя безусловно, интересы у каждого свои. Кому то действительно нравится заниматся подгонкой верстки/функционала под нужды заказчиков. Кому то действительно нравится кодить одну и туже по сути вещь каждый день.
Хотя безусловно, интересы у каждого свои. Кому то действительно нравится заниматся подгонкой верстки/функционала под нужды заказчиков. Кому то действительно нравится кодить одну и туже по сути вещь каждый день.
Оглянулся, за последнюю неделю-две одна рутина — багофиксы и прочие «ах, вот еще забыли про ...». Релиз же скоро. До этого я уже и не помню когда мой день не начинался с мысли «И так, как бы зафигачить…
И кстати, мир вебом не ограничивается.
И кстати, мир вебом не ограничивается.
Даже рутина — это повод задуматься «а какого инструмента мне здесь не хватает, чтобы уменьшить время и усилия на эту часть работы». Плюс накапливающийся опыт, который потом можно использовать для создания этого инструмента.
За неделю — 8 часов рутина, 8 часов интересные задачи. Остальное — медитация на тему «с какой стороны к этим и остальным интересным задачам лучше подступиться». Анализ, поиск эвристик и контрпримеров к ним, эксперименты (которые тоже могут выглядеть, как рутина)…
За неделю — 8 часов рутина, 8 часов интересные задачи. Остальное — медитация на тему «с какой стороны к этим и остальным интересным задачам лучше подступиться». Анализ, поиск эвристик и контрпримеров к ним, эксперименты (которые тоже могут выглядеть, как рутина)…
скрытая реклама braingames.ru
вы запустили программу с хипом в 2 гигабайта и она работает медленно, что будете делать?уменьшу хип.
Ответ не чуть не хуже, чем
увеличу хип
И вообще, доказать, что задача решена неправильно порой сложнее, чем доказать, что она решена правильно.
И потому все задачи на собеседованиях абсолютно бесполезны. Общая эрудиция и наличие самоиронии решают.
Статья очень спорная в некоторых моментах. Но со многим соглашусь. Правда, мне приходилось «собеседовать» админов, а не программера. Но не думаю, что разница велика. Потратив несколько часов на составление теста я сэкономил очень много времени на интервью. Я отсеивал более 50% кандидатов именно на тестах. Слишком большой поток «на удачу» шел, а времени на отбор, как обычно, мало. И если человек не мог ответить в тесте на БАЗОВЫЕ вопросы профессии (например, не мог написать маску для сети /26 или что-нить подобное), то, увы, такой админ был не нужен, о чем ему и сообщалось очень быстро. Хотя бы по тому, что времени на обучение АЗАМ не было, надо было сразу работать. Кстати, часть кандидатов получив анкету-тест уходили сами, сказав что «не тянут».
А еще у меня есть «бзик». Все хотелось посмотреть, могут ли кандидаты думать. Давал любимую простенькую задачу в 4 простых действия (ну там, плюс, минус, умножить, разделить), бумажку, ручку и полчаса времени (задача решается в уме за 2 минуты). И ни один не решил. Хотя, трое теперь работают и оказались хорошими спецами (два админа и спец по ERP).
А еще у меня есть «бзик». Все хотелось посмотреть, могут ли кандидаты думать. Давал любимую простенькую задачу в 4 простых действия (ну там, плюс, минус, умножить, разделить), бумажку, ручку и полчаса времени (задача решается в уме за 2 минуты). И ни один не решил. Хотя, трое теперь работают и оказались хорошими спецами (два админа и спец по ERP).
Легко.
Жили-были три мужика по фамилиям Тройкин, Пятеркин и Бестопливный. Собрались они как-то готовить ужин. Затопили печь. Тройкин принес три полена, Пятеркин — пять, Бестопливный — ничего. Сготовили ужин, огнем пользовались поровну. И вот Бестопливный говорит: «Мужики. Как-то нехорошо получилось, я-то дров не принес. Но вот в качестве компенсации вам восемь рублей». Вопрос: как должны быть разделены деньги между Тройкиным и Пятеркиным?
Жили-были три мужика по фамилиям Тройкин, Пятеркин и Бестопливный. Собрались они как-то готовить ужин. Затопили печь. Тройкин принес три полена, Пятеркин — пять, Бестопливный — ничего. Сготовили ужин, огнем пользовались поровну. И вот Бестопливный говорит: «Мужики. Как-то нехорошо получилось, я-то дров не принес. Но вот в качестве компенсации вам восемь рублей». Вопрос: как должны быть разделены деньги между Тройкиным и Пятеркиным?
1 рубль Тройкину, 7 — пятеркину. Верно? :)
Да, так. Старая задача… вероятно, из Перельмана.
Сказка №35 «Решение мудреца» (продолжается на следующей странице).
Возможно, она старше Перельмана :)
Возможно, она старше Перельмана :)
Ответ верный. Не поверите, ведь это, по сути, бухгалтерская задача, и целая бухгалтерия не могла решить — искали ответ в гугле.
А еще люблю спрашивать у программистов и бухгалтеров (и те, и те должны дать сразу правильный ответ, но зачастую не могут: «Ване дали три яблока и два забрали. Сколько яблок у Вани?» Причем ответ, который дает моя пятилетняя дочь, я не принимаю от своего 11 летнего балбеса :-)
Я проводил довольно много собеседований на вакансию программиста в нашем небольшом городе. Не могу судить о крупных городах, но проблема провинциального хедхантеринга, по моему опыту заключается в том, что шанс найти специалиста подходящего вам априори крайне, крайне мал.
Адекватные опытные спецы давно свалили в мск/спб или работают удаленно, их рейты скорее всего выросли настолько, что уже стали больше рейтов вашей компании.
Неадекватные опытные спецы, гики и прочие, за счет своей врожденной социопатии и неумения общаться с людьми вполне могут застрять навечно в провинции. Они даже могут прийти на собеседование, но в коллективе, к сожалению, такие люди приживаются плохо, их кругозор зациклен только на технической части и не обращает внимания на другие бизнес требования, заставить что-либо их делать против их мировоззрения сложно, а если за ними пристально не следить, то вместо простого решения, вы получите космический корабль, на неизвестных технологиях. Это супер круто с технической части, но как вам с этим жить дальше?
Третий вид кандидатов — это «вчерашние» студенты. Собеседовать их — одно удовольствие. Т.е. это как анекдот, мы даже иногда зовем их на собеседование в пятницу вечером, чтоб расслабить коллектив чуточкой фана, что конечно, довольно цинично. Провинциальные вузы не учат ничему, только завышают ЧСВ — студент прослушал лекцию дотнета и считает, что он отлично знает, к примеру, сиш. Так и говорит: «Я считаю, я хорошо знаю c#». На деле же, почти никто не смог назвать ни одного паттерна.
Что такое синглтон? — мммм, не сталкивался.
Ладно, ок, Вы использовали интерфейсы? — что простите?
Интерфейсы… — ммм,
Ну, вы знаете, что такое интерфейс в c# — мммм, не сталкивался.
Даже не пытайтесь спрашивать, что либо сложное. Хотя, если только по вечерам пятницы. Надо следующих просить попкорн захватить.
Так вот, суть в сухом остатке в том, что в провинции ваше собеседование направлено не на поиск специалиста, а на поиск не совсем испорченного вчерашнего студента, которого хардкорными, унизительными вопросами приводишь к тому, что он осознает свой уровень, и если повезет, через несколько месяцев активного вправления мозга, он начинает что-то собой представлять. А еще через пару месяцев он успешно проходит собеседование в мск/спб и валит туда. Утрирую конечно, но схема очень жизненна.
Если говорить о собеседовании, то оно меняет свой формат, на технические вопросы адекватного ответа не получить, приходится придумывать, «разбалтывать» человека, что б понять его суть, что он делал, какие планы на жизнь, чем увлекается. Можно спросить про математику, но тут все настолько уныло, что даже не смешно. Такие вопросы сразу выявят сбившего с пути молодого гика, готового к перевоспитанию, а если вас угораздило делать ИТ бизнес в провинции — это без сомнений ваш вариант
Адекватные опытные спецы давно свалили в мск/спб или работают удаленно, их рейты скорее всего выросли настолько, что уже стали больше рейтов вашей компании.
Неадекватные опытные спецы, гики и прочие, за счет своей врожденной социопатии и неумения общаться с людьми вполне могут застрять навечно в провинции. Они даже могут прийти на собеседование, но в коллективе, к сожалению, такие люди приживаются плохо, их кругозор зациклен только на технической части и не обращает внимания на другие бизнес требования, заставить что-либо их делать против их мировоззрения сложно, а если за ними пристально не следить, то вместо простого решения, вы получите космический корабль, на неизвестных технологиях. Это супер круто с технической части, но как вам с этим жить дальше?
Третий вид кандидатов — это «вчерашние» студенты. Собеседовать их — одно удовольствие. Т.е. это как анекдот, мы даже иногда зовем их на собеседование в пятницу вечером, чтоб расслабить коллектив чуточкой фана, что конечно, довольно цинично. Провинциальные вузы не учат ничему, только завышают ЧСВ — студент прослушал лекцию дотнета и считает, что он отлично знает, к примеру, сиш. Так и говорит: «Я считаю, я хорошо знаю c#». На деле же, почти никто не смог назвать ни одного паттерна.
Что такое синглтон? — мммм, не сталкивался.
Ладно, ок, Вы использовали интерфейсы? — что простите?
Интерфейсы… — ммм,
Ну, вы знаете, что такое интерфейс в c# — мммм, не сталкивался.
Даже не пытайтесь спрашивать, что либо сложное. Хотя, если только по вечерам пятницы. Надо следующих просить попкорн захватить.
Так вот, суть в сухом остатке в том, что в провинции ваше собеседование направлено не на поиск специалиста, а на поиск не совсем испорченного вчерашнего студента, которого хардкорными, унизительными вопросами приводишь к тому, что он осознает свой уровень, и если повезет, через несколько месяцев активного вправления мозга, он начинает что-то собой представлять. А еще через пару месяцев он успешно проходит собеседование в мск/спб и валит туда. Утрирую конечно, но схема очень жизненна.
Если говорить о собеседовании, то оно меняет свой формат, на технические вопросы адекватного ответа не получить, приходится придумывать, «разбалтывать» человека, что б понять его суть, что он делал, какие планы на жизнь, чем увлекается. Можно спросить про математику, но тут все настолько уныло, что даже не смешно. Такие вопросы сразу выявят сбившего с пути молодого гика, готового к перевоспитанию, а если вас угораздило делать ИТ бизнес в провинции — это без сомнений ваш вариант
шанс найти специалиста подходящего вам априори крайне, крайне мал
В Москве такая же проблема, если вам нужен специалист, со знанием, хоть каким-нибудь, concurrency например (я сейчас про java). EE-шников — до жопы, но, увы, у них строение мозга такое, что они привыкли брать три-четыре-магические-буквы технологию\фреймворк и использовать его, а не думать своей головой.
Да и любят они, знаете ли, взять таску и обсасывать ее неделю, думая как же ее лучше сделать, как покрасивше прикрутить — в их мире, где им по каждому требованию выдают нужное количество серверов, где все проблемы с бд решаются — а почему не Оракл, да и две недели в месяц можно сидеть в потолок плевать — это норма.
В Москве такая же проблема, если вам нужен специалист, со знанием, хоть каким-нибудь, concurrency например (я сейчас про java). EE-шников — до жопы, но, увы, у них строение мозга такое, что они привыкли брать три-четыре-магические-буквы технологию\фреймворк и использовать его, а не думать своей головой.
Да и любят они, знаете ли, взять таску и обсасывать ее неделю, думая как же ее лучше сделать, как покрасивше прикрутить — в их мире, где им по каждому требованию выдают нужное количество серверов, где все проблемы с бд решаются — а почему не Оракл, да и две недели в месяц можно сидеть в потолок плевать — это норма.
считает, что он отлично знает, к примеру, сиш. Так и говорит: «Я считаю, я хорошо знаю c#». На деле же, почти никто не смог назвать ни одного паттерна.
Противоречие-то в чём?
«Иванов считает, что он отлично знает, к примеру, английский. Так и говорит: „Я считаю, я хорошо знаю английский“. На деле же, не смог назвать ни одного тропа.»
Сообразительность — да.
Алгоритмика — это знания различным известных алгоритмов, плюс сообразительность, там где эти знания кончаются.
Мне кажется алгоритмика, в отличие от сообразительности, штука прокачиваемая: чем больше знаешь классических алгоритмов, связанных с ними структур данных, тем проще решить те или иные алгоритмические задачи. Это как слух развивать.
А вот сообразительность, она, как мне кажется, либо есть, либо увы нет.
С опытом проведения собеседований пришла гипотеза о том, что умный, талантливый человек — талантлив во многих областях. Поэтому чтобы определить врожденные умственные навыки можно попробовать поговорить с человеком на абсолютно разные темы, никак не связанные с ИТ или конкретной вакансией. Например, спросить что кандидат думает о текущем положении в стране, или как накормить голодающие населения Африки — рвите шаблоны, программист это не робот для кодирования, это человек, с ним можно и нужно общаться на разные темы :)
Алгоритмика — это знания различным известных алгоритмов, плюс сообразительность, там где эти знания кончаются.
Мне кажется алгоритмика, в отличие от сообразительности, штука прокачиваемая: чем больше знаешь классических алгоритмов, связанных с ними структур данных, тем проще решить те или иные алгоритмические задачи. Это как слух развивать.
А вот сообразительность, она, как мне кажется, либо есть, либо увы нет.
С опытом проведения собеседований пришла гипотеза о том, что умный, талантливый человек — талантлив во многих областях. Поэтому чтобы определить врожденные умственные навыки можно попробовать поговорить с человеком на абсолютно разные темы, никак не связанные с ИТ или конкретной вакансией. Например, спросить что кандидат думает о текущем положении в стране, или как накормить голодающие населения Африки — рвите шаблоны, программист это не робот для кодирования, это человек, с ним можно и нужно общаться на разные темы :)
Есть такая игра, пишем на стикере например животное, приклеиваем оппоненту на лоб, а он вам свой. Цель — отгадать что на вашем стикере. Главный козырь тут в том чтобы спросить такой вопрос, ответ на который давал бы вам сразу несколько других ответов.
Не обязательно спрашивать человека знает ли он что такое thread, проще сразу спросить, чем мютекс отличается от семафора или как решить проблему с dead lock.
Не обязательно спрашивать человека знает ли он что такое thread, проще сразу спросить, чем мютекс отличается от семафора или как решить проблему с dead lock.
чем мютекс отличается от семафора или как решить проблему с dead lock
Я когда собирал команду, мне нужны были люди с глубоким знанием Qt и SQL. Оказалось что это во-первых крайне редкое сочетание, а во вторых — SQL это та технология, которую совсем не сложно изучить в процессе работы. Я не говорю про банальные SELECT'ы, речь про гораздо более сложные запросы, и серверную логику. В итоге требование по SQL убрали и не пожалели.
Так и многопоточность — да, важный и ответственный стек технологий, но все ли в команде должны его знать на зубок? Достаточно одного эксперта, который сделает эту работу или научит остальных.
Знать многопоточность на зубок, это означает знать хотя бы несколько паттернов многопоточного программирования, знать что такое барьеры памяти, к чему может привести переупорядочивание инструкций на уровне процессора, как организовать read-write очереди и еще многое другое. А знать чем мютекс отличается от семафора и что такое дедлок это начальное понимание многопточного программирования :) Возможно это специфика работы на С++, и для написание мобильных приложений оно и не нужно. Я это так сказать просто яркий пример привел :)
А знать чем мютекс отличается от семафора и что такое дедлок это начальное понимание многопточного программирования :) Возможно это специфика работы на С++, и для написание мобильных приложений оно и не нужноВы сильно удивитесь, но на Qt мы делаем тяжелые бизнес-приложения для десктопов. Факт в том, что задачки по многопоточности возникают не чаще 2-3 в год на всю команду. Да иметь представление полезно, но если человек преимущественно занимается например GUI или БД в проекте — нафиг оно ему надо? :)
Так и многопоточность — да, важный и ответственный стек технологий, но все ли в команде должны его знать на зубок? Достаточно одного эксперта, который сделает эту работу или научит остальных.
Научить мыслить в рамках многопоточности — достаточно сложно, это долгий процесс, который длится месяцами, если хорошо прикладывать к этому усилия, либо годами, если воспринимать это «раз надо, то надо».
С одним экспертом схема прогорит, если у вас изначально софт многопоточный. Допустим пишете вы игровой сервер, хорошо, если у вас все запросы от пользователя изолированы — много дров не наломаете (хотя конечно можно и постоянно дедлоки ловить), а если начинается взаимодействие между пользователями… то без понимания как должно происходить это взаимодействие мы получим ну просто замечательную картину, когда ничего не работает и никто не знает ничего.
Научить мыслить в рамках многопоточности — достаточно сложно, это долгий процесс, который длится месяцами, если хорошо прикладывать к этому усилия, либо годами, если воспринимать это «раз надо, то надо».
С одним экспертом схема прогорит, если у вас изначально софт многопоточный. Допустим пишете вы игровой сервер, хорошо, если у вас все запросы от пользователя изолированы — много дров не наломаете (хотя конечно можно и постоянно дедлоки ловить), а если начинается взаимодействие между пользователями… то без понимания как должно происходить это взаимодействие мы получим ну просто замечательную картину, когда ничего не работает и никто не знает ничего.
Но не стоит слишком зацикливаться на личных качествах
Зацикливаться конечно не стоит, но есть такие особенности людей, которые будут мешать работе, пусть даже они семи пядей во лбу. Я бы выделил следующие:
— Катастрофическая непунктуальность (опоздал на собеседование на час, не предупредив, не отвечает на почту или звонки)
— Неспособность признавать свои ошибки или признаваться в незнании чего-то
— Жизненная позиция «Есть только два варианта: мой и неправильный»
— Нацеленность исключительно на деньги: вы часто будете слышать от этого человека фразу «За те деньги что мне платят я не собираюсь ...»
Цель технического собеседования — определить, способен ли человек делать то, что от него требуется, или будет на работе только время тратить.
Цель личного собеседования — определить, собирается ли человек делать то, что от него требуется, или будет на работе только время тратить.
В принципе, возможны все четыре комбинации вариантов; но технический специалист, проводящий техническое собеседование, вряд ли обладает достаточными способностями к психологии, чтобы получить заключение и по второму вопросу. Поэтому второй вопрос поручают выяснять эйчару.
Но дело в том, что технический специалист вряд ли обладает достаточными способностями к психологии, чтобы определить, обладает ли ими эйчар, проводящий личное собеседование — или сам этот эйчар на работе только время тратит.
Вот отсюда, по-моему, и недоверие :-)
Цель личного собеседования — определить, собирается ли человек делать то, что от него требуется, или будет на работе только время тратить.
В принципе, возможны все четыре комбинации вариантов; но технический специалист, проводящий техническое собеседование, вряд ли обладает достаточными способностями к психологии, чтобы получить заключение и по второму вопросу. Поэтому второй вопрос поручают выяснять эйчару.
Но дело в том, что технический специалист вряд ли обладает достаточными способностями к психологии, чтобы определить, обладает ли ими эйчар, проводящий личное собеседование — или сам этот эйчар на работе только время тратит.
Вот отсюда, по-моему, и недоверие :-)
Поэтому второй вопрос поручают выяснять эйчаруКаким бы HR распрекрасным не был, работать с этим соискателем вам а не эйчару, поэтому работу надо проверять. Это не значит прямо в лоб трещать «за жизнь» сначала. Нет. Все эти вопросы можно раскрыть в ходе технического собеседования. Впрочем немного «за жизнь» поболтать тоже полезно. Во первых в большей степени соискатель выбирает вас а не вы его (если вы не Google), надо дать понять что вы прежде всего люди а не роботы. А во вторых неожиданно ввернутый в серьезный технический диалог «прикол из жизни» прямо таки расслабляет соискателя, пробивает его защиту, и он может рассказать много интересного. Как в плюс так и в минус себе конечно. Да, тех. руководитель все равно прежде всего с людьми работает, и должен понимать психологию интуитивно.
Мы говорим о разных людях.
Есть руководитель, который работает с людьми и понимает психологию, но кодил последний раз N-надцать лет назад, и то на Коболе. Кроме того, нет у него времени на такую чепуху, как собеседование двадцати кандидатов.
В абсолютном большинстве случаев, техническое собеседование он не проводит сам, а поручает технически компетентному специалисту. Либо они проводят собеседование вдвоём, но тогда и психологическое давление на кандидата удвоенное. А если они ещё и примутся перемежать технические вопросы с личными, так это вообще взрыв мозга, потому что сосредоточиться не позволяет ни на одном, ни на другом.
PS: с одним таким руководителем мы на моём собеседовании обсуждали BBS-ки и Бейсик с номерами строк — потому что это именно то, что запало ему в душу до перехода в менеджмент :-)
Есть руководитель, который работает с людьми и понимает психологию, но кодил последний раз N-надцать лет назад, и то на Коболе. Кроме того, нет у него времени на такую чепуху, как собеседование двадцати кандидатов.
В абсолютном большинстве случаев, техническое собеседование он не проводит сам, а поручает технически компетентному специалисту. Либо они проводят собеседование вдвоём, но тогда и психологическое давление на кандидата удвоенное. А если они ещё и примутся перемежать технические вопросы с личными, так это вообще взрыв мозга, потому что сосредоточиться не позволяет ни на одном, ни на другом.
PS: с одним таким руководителем мы на моём собеседовании обсуждали BBS-ки и Бейсик с номерами строк — потому что это именно то, что запало ему в душу до перехода в менеджмент :-)
Кроме того, нет у него времени на такую чепуху, как собеседование двадцати кандидатовНичего себе чепуха. Команда это самая важная часть проекта.
Совершенно верно, но по «начальным условиям» команда уже есть.
Пополнение существующей, сработавшейся, эффективной команды — задача явно не первоприоритетная для проекта.
У Вас есть продукт, устоявшаяся команда и финансирование. Вы (команда) хорошо работали, и руководство готово заплатить еще денег чтобы нанять человека, чтобы, соответственно, ускорить разработку, повысить качество и иметь возможность тратить ресурсы на технологическое развитие продукта. <...> Исключения составляют компании которым «человек нужен вчера» <...>
Пополнение существующей, сработавшейся, эффективной команды — задача явно не первоприоритетная для проекта.
Ещё расскажу историю по поводу "Катастрофическая непунктуальность (опоздал на собеседование на час, не предупредив"
Как-то я искал работу через фирму-посредника, которая рассылала моё резюме и назначала собеседования.
На очередное собеседование я пришёл на час раньше назначенного времени: просто в это время я проходил мимо офиса той фирмы, весь час был у меня свободен, и я решил, «дай заскочу, в худшем случае просижу час у них в прихожей».
Меня приняли крайне раздражённо, выдали мне письменный тест, я его заполнил и сдал, и больше от той фирмы ничего не слышал. А сотрудница фирмы-посредника меня отчитывала: «Как же так можно! Можно придти ну самое большее на 15 минут раньше срока, но чтобы на час! Это ж просто наглость!»
Как-то я искал работу через фирму-посредника, которая рассылала моё резюме и назначала собеседования.
На очередное собеседование я пришёл на час раньше назначенного времени: просто в это время я проходил мимо офиса той фирмы, весь час был у меня свободен, и я решил, «дай заскочу, в худшем случае просижу час у них в прихожей».
Меня приняли крайне раздражённо, выдали мне письменный тест, я его заполнил и сдал, и больше от той фирмы ничего не слышал. А сотрудница фирмы-посредника меня отчитывала: «Как же так можно! Можно придти ну самое большее на 15 минут раньше срока, но чтобы на час! Это ж просто наглость!»
Эх! А я только заметил… Вы пишите, что "sort все равно копирует перед сортировкой данные в массив, а потом возвращает обратно". Действительно, документация Java именно об этом и говорит. Но зачем, зачем копировать в массив список, чтобы применить сортировку слиянием(!)? Ведь именно этот тип сортировки был разработан для структур данных, имеющих именно последовательный доступ.
То ли я очень устал после рабочего дня, однако javadoc гласит: «This avoids the n*n log(n) performance that would result from attempting to sort a linked list in place.»
Всегда думал, что сложность сортировки слиянием на месте(in place) n log(n), при этом затраты на дополнительную память (если использовать стек) всего лишь log(n), что меньше, замечу, чем АЖ n (при копировании целого списка в массив).
Откуда же они взяли квадратично-логарифмическую сложность? Исходники не проверял, но в документации так и написано, начиная с версии 1.4.2 и вплоть до 1.7.
То ли я очень устал после рабочего дня, однако javadoc гласит: «This avoids the n*n log(n) performance that would result from attempting to sort a linked list in place.»
Всегда думал, что сложность сортировки слиянием на месте(in place) n log(n), при этом затраты на дополнительную память (если использовать стек) всего лишь log(n), что меньше, замечу, чем АЖ n (при копировании целого списка в массив).
Откуда же они взяли квадратично-логарифмическую сложность? Исходники не проверял, но в документации так и написано, начиная с версии 1.4.2 и вплоть до 1.7.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О техническом собеседовании