Комментарии 56
А можно ссылку на оригинал, пожалуйста?
Дак, под статьей есть ссылка, если она оформлена как перевод. (Эта оформлена).
pmarchive.com/how_to_hire_the_best_people.html
pmarchive.com/how_to_hire_the_best_people.html
«Напористые люди не остаются подолгу там, где они не могут добиться успеха» как-то немного противоречиво звучит.
Ключевое слово — «подолгу». Если человек долго и добросовестно старается и не достигает результата, то в какой-то момент может накопиться достаточно оснований для понимания того, что причина неуспешности находится не в нем самом, а в тех условиях, в которых приходится работать.
Соответственно, напористость переключается с достижения результата на поиск новых возможностей. Мне в свое время понравилась метафора про то что не нужно упорно карабкаться по лестнице, которая приставлена не к той стене (точную цитату не помню, первоисточник тоже).
Соответственно, напористость переключается с достижения результата на поиск новых возможностей. Мне в свое время понравилась метафора про то что не нужно упорно карабкаться по лестнице, которая приставлена не к той стене (точную цитату не помню, первоисточник тоже).
После технического и общего опроса, на своих собеседованиях я задаю задачу, которая не имеет правильного ответа. Суть теста — замерить время за которое собеседник сдается. Практика показывает, что после 10 минут люди не сосредоточены на задаче: спрашивают подсказки, уточнения, сдаются, показывают частичные ответы. Но на 20 человек находится один, который решает ее до 50 минут! И тут 2 варианта: он упрям и хочет работу (берем!) или часто такие люди не знают чем массив от списка отличается :)
На мой взгляд, вполне разумный подход начать обсуждение проблемы как только осознал, что уперся в стену, а не тратить время впустую. Переводя на практическую сторону — я бы предпочел, чтобы разработчик подошел ко мне с проблемой через два дня исследования задачи, а не через две недели со сходным результатом.
Есть риск, что они будут спрашивать надо или не надо. А мне нужно, чтобы по каждой задаче было сделано максимальное исследования.
Я согласен, только у нас, по-видимому, оценка временного интервала разная. На мой взгляд, 50 минут на собеседовании на «нерешаемую» задачу — это нонсенс и потерянное время, как кандидата, так и собеседующего.
Большинство вкладываются в 15 минут. А на потенциального сотрудника я готов потратить и больше часа. Мне можно набирать только джуниоров, а среди них большинство стараются не подтянуть общий уровень знаний а научиться уверенно выглядеть на собеседованиях. Есть методы как с этим бороться, но мне по душе этот.
Этот метод по идее даст противоположные результаты.
Если человек в рамках собеседования 50 минут долбится в стену и при этом молчит как партизан, то на реальном проекте он будет терять дни/недели.
Далее, на мой взгляд ценнейшим навыком джуниора является умение задавать вопросы. Если, решая задачу на собеседовании, он долго буксует на месте, то правильным действием будет именно попросить подсказку/совет, а не как баран биться головой о стену.
Если человек в рамках собеседования 50 минут долбится в стену и при этом молчит как партизан, то на реальном проекте он будет терять дни/недели.
Далее, на мой взгляд ценнейшим навыком джуниора является умение задавать вопросы. Если, решая задачу на собеседовании, он долго буксует на месте, то правильным действием будет именно попросить подсказку/совет, а не как баран биться головой о стену.
Наверное, я не четко описал метод. Задача не просто очевидно-непробиваемая (найти в треугольника 4ту грань) — она сложная и долгая. На доказательство того что у нее нет ответа можно потратить часа. Сложность ее осознаешь по мере решения. После оценки сложности одни сдаются, а другие пытаются. И это характеристика человека. Остальные можно научить.
Очередная HR-статья про сферического коня в вакууме. И совсем ничего про найм сотрудников, когда в ряде ИТ-областей условия диктуются соискателями, а не работодателями. Из кого и как надо выбирать, когда из 5 подходящих кандидатов один отказывается от интерьвью, второй просто не приходит, двое до этого работали совсем в другой области, а последний просит зарплату в 3 раза выше средней по отрасли? Господа из HR, раскройте тему.
Простите, но появилось ощущение, что очередной HR вместо того чтобы поработать написал очередную статью ни о чём и ни для кого.
Часть про этичность — это вообще какой-то феерический бред.
Успокаивает одно — на практике оно, по большей части, так как и должно быть — HR тупо проверяет человека на общую адекватность и сравнивает по пунктам названия требований, данных ему свыше. Бывают, конечно, и профи — но они такое писать не будут точно.
Впрочем думать о себе как о великом психологе, наверное, дико приятно.
Часть про этичность — это вообще какой-то феерический бред.
Успокаивает одно — на практике оно, по большей части, так как и должно быть — HR тупо проверяет человека на общую адекватность и сравнивает по пунктам названия требований, данных ему свыше. Бывают, конечно, и профи — но они такое писать не будут точно.
Впрочем думать о себе как о великом психологе, наверное, дико приятно.
Касаемо «этичности» — если внимательно читать, видно, что автор имеет ввиду не всякие глупости, а честность и добросовестность.
Если внимательно читать, видно, что не видно ничего:
Банальность — если врет, он плохой. Спровоцируйте на вранье.
Как можно вообще обмануть в знаниях?
Скажет что знаком с некой незнакомой технологией? Ну любой же поймет, что далее вопросы последуют, ну только неадекват нагло будет врать.
Опять же — очень тонкая грань, может быть такую что технологию использовал, но своеобразно, на какие-то вопросы ответить не смог, это вранье?
Получается опять, проверка не на этичность, а на адекватность, впрочем как и почти все эти «советы» в статье.
Банальность — если врет, он плохой. Спровоцируйте на вранье.
Как можно вообще обмануть в знаниях?
Скажет что знаком с некой незнакомой технологией? Ну любой же поймет, что далее вопросы последуют, ну только неадекват нагло будет врать.
Опять же — очень тонкая грань, может быть такую что технологию использовал, но своеобразно, на какие-то вопросы ответить не смог, это вранье?
Получается опять, проверка не на этичность, а на адекватность, впрочем как и почти все эти «советы» в статье.
Начали за здравие, кончили за упокой
Про напористость и простые задачки — хорошо
Но как пошло про мелочи — трендец какой-то. У нормального спеца что, не может быть иногда депрессии? Азиаты и славяне нечасто улыбаются тоже, и что? И так далее.
Про напористость и простые задачки — хорошо
Но как пошло про мелочи — трендец какой-то. У нормального спеца что, не может быть иногда депрессии? Азиаты и славяне нечасто улыбаются тоже, и что? И так далее.
По-моему, ничего странного. Лучше отсеять кандидата, у которого сейчас временно настроение плохое, чем потом иметь дело с тем, кто постоянно депрессует. И так далее. HR — это не точная наука, тут приходится работать с вероятностями и с величинами меньше 100%.
Так это не кандидат сейчас депрессует — это про него кто-то сказал, что он депрессовал когда-то
Речь про то, что рекомендации с прошлых мест работы надо умножать на 10. «Иногда депрессовал» означает «довольно часто».
Ну да, а гадости с прошлых мест работы за глаза никто не говорит никогда
Вообще рекомендации имеет брать только внутри конторы, потому что потом жить вместе с обоими. Вне конторы у меня просили рекомендации в неакадемической среде ровно один раз. Ну и посоветовать тех, кто про тебя хорошее скажет — ничего не стоит. А если кто-то будет опрашивать без моего ведома людей, особенно с текущей работы — я ОЧЕНЬ сильно подумаю, работать ли мне там
Вообще рекомендации имеет брать только внутри конторы, потому что потом жить вместе с обоими. Вне конторы у меня просили рекомендации в неакадемической среде ровно один раз. Ну и посоветовать тех, кто про тебя хорошее скажет — ничего не стоит. А если кто-то будет опрашивать без моего ведома людей, особенно с текущей работы — я ОЧЕНЬ сильно подумаю, работать ли мне там
Удивительно, как много людей, приходящих на собеседование, не справляются с простыми тестами на те темы, которые описаны у них в резюме. Программистов можно тестировать на простых алгоритмах – связанные списки, бинарный поиск. Просто в псевдокоде – неважно, помнят ли они правильные вызовы Java-библиотек.
Какая ерунда. Проходил я однажды собеседование в компанию, где меня просили написать реализацию стека. В то время я только закончил универ и реального опыта у меня не было, зато как реализуется стэк на низком уровне я помнил и написал. И надо сказать меня приняли на работу. Однако увидел я их код и понял, что они спрашивают такую ерунду, не потому, что такие умные, а потому что не знают стандартные библиотеки, в данном случае std. И конечно же, каждый раз когда им нужен связный список, сортировка или просто прочитать файл они каждый раз пишут это заново. Надо ли говорить, что я предпочел уйти оттуда в первый же день.
Если у студента совсем нет опыта, ему конечно можно задавать такие странные вопросы, если больше спросить нечего. Но врядли в этом есть толк. А вот у человека с 5+ летним опытом, вся эта неиспользуемая на практике ерунда давно уже забыта напрочь. Ни одному опытному программисту в здравом уме не привдет в голову писать свои связные списки и сортировки. Для этого в любом языке есть стандартные библиотеки.
Нужно спрашивать человека по вещам более близким к тем задачам которые он будет решать придя на работу в вашу компанию, а не какую-то асбстрактную теоретическую хрень в вакууме, с которой он и за 10 лет практики в данной области не столкнется.
Ерунда. Очень часто бывает ситуация, когда стандартная структура — неоптимальная или просто нужно очень кастомное решение.
Я, например, неделю назад делал 4хсвязный интрузивный список внутри двумерного вектора. Сомневаюсь, что в STL'е такое есть :)
Еще если человек не может простейший список реализовать — 100% не знает скорость работы операций, продолбает итератор при удалении и т. д.
Я, например, неделю назад делал 4хсвязный интрузивный список внутри двумерного вектора. Сомневаюсь, что в STL'е такое есть :)
Еще если человек не может простейший список реализовать — 100% не знает скорость работы операций, продолбает итератор при удалении и т. д.
Очень частоВозможно, что конкретно в Вашем проекте, действительно часто. Но, готов побиться об заклад, в абсолютном большинстве среднестатистического ПО такие проблемы возникают чрезвычайно редко…
Ну я все равно не понимаю, как без знания, как устроены стандартные структуры данных, можно знать когда, скажем, использовать список, а когда вектор
Так я о том речь и веду — в большинстве случаев и знать этого не надо, т.к. «большинство случаев» — это структура из сотни-другой элементов, обращения к которой выполняются реже раза в секунду, в однопоточной среде. В таких условиях не имеет значение «как устроены стандартные структуры данных»… А если требуется работать с большими долгоживущими массивами, которые читаются/изменяются тысячи раз в секунду да еще и в конкурентной (многопоточной) среде, то тут, конечно, стоит поинтересоваться внутренней реализацией, и, возможно даже, реализовать свою.
НО! В разрезе темы статьи — лично я бы предпочел узнавать/разрабатывать низкоуровневые алгоритмы только когда текущая решаемая задача этого требует, а не просто теоретически знать (и помнить всю жизнь), чтобы на собеседовании блеснуть знаниями, которые пригодятся с вероятностью менее 1%…
НО! В разрезе темы статьи — лично я бы предпочел узнавать/разрабатывать низкоуровневые алгоритмы только когда текущая решаемая задача этого требует, а не просто теоретически знать (и помнить всю жизнь), чтобы на собеседовании блеснуть знаниями, которые пригодятся с вероятностью менее 1%…
Чем они отличаются знать это полезно и нужно и скорость выполнения операций в них. Этот вопрос был бы нормальный. Но знать досканально чтобы сходу написать реализацию, это совсем другое. Я вот например знаю чем отличаются hash-таблицы и btree и когда какое использовать, но написать на собеседовании реализацию я не смогу. Знаю что есть разные виды сортировок и они имеют разную скорость выполнения, на разных данных могут быть предпочтительны разные. Но кроме пузырьковой я тоже ни одну написать не смогу. А пузырьковую запомнил просто потому, что когда та на лабах я написал мной придуманную сортировку, а потом узнал, что это оказывается пузырьковая. Просто это самая тупая сортировка которая сразу в голову приходит.
Знаю чем отличаются например Adjacency List и Nested Sets и скорость выполнения операций в них, но на память реализовать Nested Sets не факт что смогу, хотя там ничего сложного нет. Просто зачем мне это в голове держать?
Знаю чем отличаются например Adjacency List и Nested Sets и скорость выполнения операций в них, но на память реализовать Nested Sets не факт что смогу, хотя там ничего сложного нет. Просто зачем мне это в голове держать?
Ну так а кто говорит, что нужно на собеседованиях заставлять кодить нетривиальные структуры данных вроде btree? Но понять знает ли кандидат общие принципы и отличия базовых структур необходимо — это же наша азбука.
Досконально никто и не просит. Я просто не очень понимаю, что можно не досконально знать в векторе и листе.
Реализовать удаление в бинарном дереве, понятно, никто просить не будет. Хотя про повороты, конечно, неплохо было бы хотя бы отдаленно слышать.
Реализовать удаление в бинарном дереве, понятно, никто просить не будет. Хотя про повороты, конечно, неплохо было бы хотя бы отдаленно слышать.
Я например не знаю как руль «подключен» к колесам автомобиля, но прекрасно справляюсь с ежедневными поездками на авто. А вот техник Вася должен это знать, там как ему там ковыряться. Это я к чему, к тому что большинству достаточно «черного ящика» (если руль покрутить влево, то машина поедет налево), и лишь в редких случаях нужно знать «внутренности».
Любой грамотный специалист в состоянии изобразить псевдокодом простейшую реализацию linked list или тот же bubble sort, для этого помнить ничего не надо. Разумеется, при этом скажет, какую стандартную бибилотеку он бы использовал в реальной жизни.
Вы, наверное, сами не проводили собеседования, и не представляете себе, какие кадры «с опытом от 10 лет» встречаются :)
Вы, наверное, сами не проводили собеседования, и не представляете себе, какие кадры «с опытом от 10 лет» встречаются :)
не представляете себе, какие кадры «с опытом от 10 лет» встречаютсяя, например, такой «кадр», и я не смогу написать пузырьковую сортировку даже на псевдокоде, т.к. не знаю принципа ее работы. И это несмотря на то, что лет 15 назад я точно знал как она работает. За «от 10 лет» практики на промышленных проектах (Один, например, из более сотни серверов, раскиданных по стране. Другой — обрабатывает более 1 млн. SOAP-запросов в сутки, имея при этом десятикратный запас производительности) мне ни разу не пригодилось знание низкоуровневой реализации списков и сортировок…
Возможно, Вы на собеседовании посчитаете мой опыт «неправильным», и ненужным, или подумаете что я про опыт лгу, раз не могу «изобразить» пузырьковую сортировку. Практически все мои коллеги (в т.ч. и бывшие) так не считают. Вопрос — кто прав, Вы с теоретическими вопросами или коллеги, знающие что я могу на практике?
Вы не обижайтесь, но без вашего реального кода перед глазами ничего нельзя сказать об эффективности, и в голову лезут мысли вроде того, что у вас там сотни серверов потому, что вы не умеете сортировку пузырьком сделать.
Конечно, возможно я ошибаюсь, и у вас там все хорошо с вашими проектами, но собеседование оно такое — скорее не возьмут хорошего, чем возьмут не хорошего, так что если пойдете на собеседовании, лучше википедию с пол-часа почитать, что бы не вызывать лишних подозрений.
P.S. Что касатеся миллиона запроса в сутки с 10 кратным запасом, то это примерно 100 запросов в секунду, что увы не является выдающимся показателем. Выдающийся показатель, это например 10 000 запросов в секунду.
Конечно, возможно я ошибаюсь, и у вас там все хорошо с вашими проектами, но собеседование оно такое — скорее не возьмут хорошего, чем возьмут не хорошего, так что если пойдете на собеседовании, лучше википедию с пол-часа почитать, что бы не вызывать лишних подозрений.
P.S. Что касатеся миллиона запроса в сутки с 10 кратным запасом, то это примерно 100 запросов в секунду, что увы не является выдающимся показателем. Выдающийся показатель, это например 10 000 запросов в секунду.
Выдающийся показатель, это например 10 000 запросов в секундуЗапрос запросу — рознь, так что не стоит вот так вот огульно под одну гребенку… К тому же это просто пример, в надежде донести мысль о том, что как я считаю, знание алгоритмов мало говорит о том, что представляет из себя разработчик. И даже наоборот, раз он так тщательно готовился к собеседованию и штудировал давно забытую теорию, то может с практикой у него туговато… Большинство студентов знает такие алгоритмы лучше, чем большинство синьоров и архитекторов, но говорит ли это о том, что студент лучше справится с реальным проектом?
Лично моя практика показывает, что студенты знают эти алгоритмы и структуры данных скорее поверхностно. При этом знакомые мне мощные архитекторы как раз таки в теме алгоритмов чаще как рыба в воде, так как под высокую нагрузку порой приходится реализовывать свои структуры данных ну или в любом случае понимать как работают готовые.
Похоже, что вы мыслите понятиями конкретно вашей специфики. Видимо, у вас т.н. high load проект(ы) в котором(ых) приходится работать с большим количеством данных, находящихся в ОЗУ. Да, для этого нужны вышеперечисленные знания, и поэтому ваши архитекторы в них «как рыба в воде». Но, во-первых, даже high load бывает разный, а во-вторых далеко не каждый второй проект в стране — это high load… Вам при собеседовании, видимо, надо спрашивать про алгоритмы, но мы же обсуждаем сферическое собеседование в вакууме, срез «в среднем по больнице», поэтому мне кажется, что ваши требования совсем не средние…
Собеседовния я проводил, но как раз исходил из соображений, что нужно на практике. Вероятность что придется на работе самому писать сортировку или свой linked list равна нулю, так зачем это спрашивать. Отлично, я узнаю, что человек умеет или не умеет на память воспроизвести linked list, и что дальше какой я должен вывод сделать — подходит ли человек для работы или нет? По вашему программисты делают только то чему их научили в универе? Научили писать связные списки, и вот они сидят и целыми днями на работе пишут эти самые связные спики. А если человек забыл за ненадобностью реализацию этого списка, потому что уже 10 лет пульзуется стандартной реализацией, то все этот человек не подходит. Это ведь пустяки, что он может выполнять всю работу требующуюся для данной позиции и выполнял аналогичную на двух прошлых местах работы.
Я вот не могу так сказать однозначно «спрашивайте на всех собеседования свзяные спики» или наоборот «никогда не спрашивайте связные списки». Все зависит от позиции, на которую претендует соискатель, т.е. от того что в реальности будет писать, если полчуит данную работу. Но в 99.99% случае вторая рекомендаци все же актуальнее, и более уместны вопросы по языку, фреймворку / ОС, и СУБД. Но тут тоже не надо лезть в дебри этих языков. Есть любители спрашивать вскую хитрую хрень, которая на практике никогда не встретится. Тут складывается ощущение, что они хотят повысить чувство собственной важности или сбить зарплату соискателю, но никак не, то что они хотят закрыть вакансию.
Все эти алгоритмы хрень, они быстро гугляться и быстро забываются. Вот я например год назад писал алгоритм Вisjoint Set Union, и он до сих пор работает в проекте. Ничем не сложнее какой-нибудь сортировки или очереднего дерева. И что думаете я вам на память его воспроизведу. Не воспроизведу. И я постоянно забываю как выполняется аггрегация в MySQL и MongoDB, потому что на практике это не те зепросы которые я пишу каждый день. На это документация и есть — открыл вспомнил, написал, забыл еще на год.
Как то было вообще смешно. Я собеседовался на вакансию на язык, на котором ранее программировал, но предыдущие 2 года программировал на другом языке. Конечно подзабыл малек… И меня спросили как понаследоваться от класса. И я не помнил… ) Значило ли это что я не могу программировать на данном языке. Очевидно нет, следующий год я на нем успешно программировал, правда в другой компании и нормальной зарплатой.
Я вот не могу так сказать однозначно «спрашивайте на всех собеседования свзяные спики» или наоборот «никогда не спрашивайте связные списки». Все зависит от позиции, на которую претендует соискатель, т.е. от того что в реальности будет писать, если полчуит данную работу. Но в 99.99% случае вторая рекомендаци все же актуальнее, и более уместны вопросы по языку, фреймворку / ОС, и СУБД. Но тут тоже не надо лезть в дебри этих языков. Есть любители спрашивать вскую хитрую хрень, которая на практике никогда не встретится. Тут складывается ощущение, что они хотят повысить чувство собственной важности или сбить зарплату соискателю, но никак не, то что они хотят закрыть вакансию.
Все эти алгоритмы хрень, они быстро гугляться и быстро забываются. Вот я например год назад писал алгоритм Вisjoint Set Union, и он до сих пор работает в проекте. Ничем не сложнее какой-нибудь сортировки или очереднего дерева. И что думаете я вам на память его воспроизведу. Не воспроизведу. И я постоянно забываю как выполняется аггрегация в MySQL и MongoDB, потому что на практике это не те зепросы которые я пишу каждый день. На это документация и есть — открыл вспомнил, написал, забыл еще на год.
Как то было вообще смешно. Я собеседовался на вакансию на язык, на котором ранее программировал, но предыдущие 2 года программировал на другом языке. Конечно подзабыл малек… И меня спросили как понаследоваться от класса. И я не помнил… ) Значило ли это что я не могу программировать на данном языке. Очевидно нет, следующий год я на нем успешно программировал, правда в другой компании и нормальной зарплатой.
Вместо того, чтобы помнить (помнить, действительно, совершенно необязательно), — можно просто сообразить.
В случае с linked list меня бы устроила банальная картинка с точечками и стрелочками и базовые рассуждения о сложностях операций.
В случае с сортировкой — любой алгоритм, который первый вспомнился или на ходу придумался.
В случае с linked list меня бы устроила банальная картинка с точечками и стрелочками и базовые рассуждения о сложностях операций.
В случае с сортировкой — любой алгоритм, который первый вспомнился или на ходу придумался.
Хочется пожелать автору почаще иметь в своей жизни дело с напористыми любознательными этичными неинтеллектуалами. Раз уж это его образ идеального сотрудника.
В целом статья оставила двоякое впечатление: с одной стороны автор относится к людям как к товару, с другой слабо ориентируется в реалиях отрасли. В итоге не совсем понятно почему я вообще это читаю.
В целом статья оставила двоякое впечатление: с одной стороны автор относится к людям как к товару, с другой слабо ориентируется в реалиях отрасли. В итоге не совсем понятно почему я вообще это читаю.
Исключительно гуманитарный подход. Выбрать несколько понравившихся черт, интуитивно оценить их, дать сортировку пузырька.
Насколько это убогий путь исследовал Daniel Kahneman например.
Тут есть два момента. Во-первых, личные качества могут сильно варьироваться в зависимости от обстановки. Например, напористость на собеседовании может полностью исчезнуть за рабочим местом. Корреляции никакой, никак не измеришь.
Во-вторых, оценка собеседующего — штука неточная. Зависит от личных предпочтений, настроения и вообще человек постоянно ошибается. Можно прошляпить хорошего сотрудника только из-за того, что пропустил обед и сидишь голодный и раздраженный.
Насколько это убогий путь исследовал Daniel Kahneman например.
Тут есть два момента. Во-первых, личные качества могут сильно варьироваться в зависимости от обстановки. Например, напористость на собеседовании может полностью исчезнуть за рабочим местом. Корреляции никакой, никак не измеришь.
Во-вторых, оценка собеседующего — штука неточная. Зависит от личных предпочтений, настроения и вообще человек постоянно ошибается. Можно прошляпить хорошего сотрудника только из-за того, что пропустил обед и сидишь голодный и раздраженный.
«Лучше работал с мужчинами, чем с женщинами» — сексист.
Вы говорите об этом так, как будто бы это что-то плохое. С женщинами не-технарями реально тяжело, особенно, если их больше двух. А если их большинство, то работа, местами, превращается в прогулку по минному полю.
Расскажу историю из жизни. Была одна западная компания, которая в российский офис (менеджеры, не ИТ) набирала людей по психологическим тестам. Брала самостоятельных, напористых, амбициозных. И таких — весь офис. В результате — полный паралич в работе из-за непрекращающейся грызни. Пауки в банке — все готовы идти по трупам.
Так что, психология, конечно, хорошо, но для работы в больших коллективах, куда нужны простые исполнители, лучше брать спокойных, безинициативных, способных к рутине. Пусть лиды сияют, а кодеры — кодят. Ну и когда берёшь такого кодера с крупной компании, надо понимать, что берёшь вышколенного исполнителя, с напрочь отбитой инициативой.
Так что, психология, конечно, хорошо, но для работы в больших коллективах, куда нужны простые исполнители, лучше брать спокойных, безинициативных, способных к рутине. Пусть лиды сияют, а кодеры — кодят. Ну и когда берёшь такого кодера с крупной компании, надо понимать, что берёшь вышколенного исполнителя, с напрочь отбитой инициативой.
Так там же есть пункт про этичность, что как бы должно компенсировать напористость.
Брала самостоятельных, напористых, амбициозных
лучше брать спокойных, безинициативных, способных к рутине
Хорошая команда должна состоять из людей различных психотипов/ролей. Есть исследования по этому поводу и тесты соответствующие. Так что неправы ни вы ни компания, т.к. в команде должны быть и те и другие типы людей, и еще несколько других…
Серия статей про стартапы. Это по определению небольшие коллективы энтузиастов.
(анекдот) Я спросил одного кадровика, почему все непременно требуют высшего образования. Он ответил: — Чтобы была гарантия, что человек в состоянии пяти лет заниматься неинтересной ему фигнёй.
ощущение, что ВСЕ :) статьи на тему — про найм сотрудников (как пройти собеседование, как проводить собеседования). Как-то однобоко, не находите?
Почаще бы статьи про то, как ориентироваться потенциальному сотруднику в потенциальном работодателе. Какие признаки выдадут того работодателя, который гладко стелет, да больно кколет.
Почаще бы статьи про то, как ориентироваться потенциальному сотруднику в потенциальном работодателе. Какие признаки выдадут того работодателя, который гладко стелет, да больно кколет.
Да уж. Найти хорошего сотрудника — пуд соли съесть =(
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как нанимать наилучших сотрудников