Чтобы провести собеседование с разработчиком, не надо его заваливать тонкостями и головоломками. Достаточно с ним поговорить на профессиональные темы минуть пять. Когда сам озадачен актуальными вопросами, коллега с большой вероятностью либо сам с ними уже когда-либо сталкивался, либо может прямо в беседе проконсультировать.
Плюс, командная работа — это всегда совместимость между людьми. Если человек вам неприятен, с большой вероятностью это скажется и в работе отрицательно. Поэтому важно выбирать тех, с кем придется работать ежедневно. То что он знает в совершенстве какие-то темные стороны языка программирования — это дело совсем даже не десятого порядка важности.
Пробелы в каких-то знаниях — не недостаток. Мы сейчас живем в условиях, когда то, что было еще полгода назад, — уже мало актуально. Для веба это особенно актуально — тут все меняется так серьезно, что все приходится изучать с нуля. И на готовых проектах. Ни разу в моем опыте не было такого, чтобы лично я что-то специально заучивал наизусть и требовал или ожидал заучивания от других. Абсолютно всегда приходилось быстро вникать в то, что видишь впервые в жизни. И нет времени на тонкости. Понимание тонкостей приходит с опытом. И чем больше кругозор и опыт разработчика, тем с большей правдой он, даже не зная новую для себя вещь, сможет быстро догадаться о потенциальных проблемах. Потому что все компьютерные технологие построены на примерно одинаковых вещах, где есть типовые недостатки и подводные камни.
И такой подход я получил от своих преподавателей еще советской школы. Специалист — это не тот кто все знает, а кто знает где найти справочник или того, у кого можно проконсультироваться. И эти мои преподаватели делали прорывы в технологиях и науке.
А то что я вижу сейчас в собеседованиях — это стыд и позор. Набирают, такое ощущение, — лишь кодировщиков, кто бы очень быстро кодировал все, что им прикажут сверху. Раньше такая профессия была — Оператор ЭВМ. Очень похоже.
Если вы новичок в программировании, вам все-равно эти типовые головоломки ничего не дадут, хоть выучи наизусть, хоть месяцами сиди в интернете и штудируй курсы. А уж попытки вызубрить наизусть какие-нибудь популярные темы типа шаблонов проектирования или все классы стандартной библиотеки и вовсе тщетны. Через неделю все выветрится из головы.
Реальное обучение проходит напрямую в живом проекте, когда то что тебе нужо, находишь и применяешь. В этом деле через месяц уже станешь разбираться лучше абсолютного большинства тех, кто обучает на курсах. А если это станет твоей специализацией, так все тонкости раздобудешь и будешь в этих вопросах разбираться лучше чем большинство других программистов. Просто потому, что это тебе нужно и это твоя работа.
Если же ты уже опытный программист, все эти вопросы на собеседованиях раздражают. Если ваш собеседует живой человек, а не программа по отсеву программистов (бывает такая жесть — когда присылают ссылку на веб вопросник), он сразу оценивает тебя и переходит к твоему реальному уровню очень быстро. По крайней мере, у меня всегда было так. И меня брали с существенными пробелами в знаниях, потому что собеседующие были адекватными. Им нужен был не заучка и энциклопедист, а инженер.
Еще бывает такая вещь, как синдром вахтера. Когда HR работник лучше самого работодателя знает, кого надо нанять: высчитывает его психологическую карту, чуть ли не как на ТАРО строит твой почти гороскоп, загружая свою голову барахлом из псевдо-научных психологических верований. И занимается он такой фигней, искренне веря, что тем самым делает благое дело, не понимая, что его задача — поиск и первичный отсев тех, кто точно не подойдет. Не больше. Нормально собеседовать человека сможет прямой руководитель.
В-общем, фигня все эти задачки и попытки рыться в пробелах кандидатах. Прочитал я эти вопросы. В моем опыте абсолютное большинство указанных вопросов — то с чем программист скорей всего не столкнется. А если он чего-то подзабыл или не знает, ничего страшного — ему платят за то, чтобы он умел находить решения.
Лично мне коллеги-заучки не нужны.
Как быть, если вы заметили неадекватных собеседующих? Либо прямо про это им говорите либо молча уходите. Себе дороже терпеть этот бардак. Вам же с ними потом вместе работать. Но вы должны быть уверены в своих словах. Это не волшебная мантра, — вы должны готовы отстоять свои слова. Иначе не беритесь с кем-то спорить. Нет ничего смешнее человека, кто строит из себя крутого мачо, но на деле у него пшик. И не беритесь брать ответственность в тех вещах, где у вас немнного не хватает квалификации. Это ваша работа — уметь в условиях неизвестности решать трудные технические задачи. Мне такая тактика в свои годы позволила из только что окончившего ВУЗ птенца сразу перейти в разряд ключевых работников организации.
PS. Я профессиональный разработчик. Еще вживую видел перфокарты. Собеседовал несколько раз и сам принимал участие в собеседованиях. К сожалению, смотря на все это вокруг, становится очень грустно. Не потому что я что-то не знаю из того где лично меня «валили», а потому, что многие собеседующие и собеседуемые ничего не понимают в разработке — а на основе своих странных знаний о программировании принимают неверные решения.
Не писал никогда на хабр, но последние перлы на хабре касаемо собеседований не оставили меня в стороне.
Плюс, командная работа — это всегда совместимость между людьми. Если человек вам неприятен, с большой вероятностью это скажется и в работе отрицательно. Поэтому важно выбирать тех, с кем придется работать ежедневно. То что он знает в совершенстве какие-то темные стороны языка программирования — это дело совсем даже не десятого порядка важности.
Пробелы в каких-то знаниях — не недостаток. Мы сейчас живем в условиях, когда то, что было еще полгода назад, — уже мало актуально. Для веба это особенно актуально — тут все меняется так серьезно, что все приходится изучать с нуля. И на готовых проектах. Ни разу в моем опыте не было такого, чтобы лично я что-то специально заучивал наизусть и требовал или ожидал заучивания от других. Абсолютно всегда приходилось быстро вникать в то, что видишь впервые в жизни. И нет времени на тонкости. Понимание тонкостей приходит с опытом. И чем больше кругозор и опыт разработчика, тем с большей правдой он, даже не зная новую для себя вещь, сможет быстро догадаться о потенциальных проблемах. Потому что все компьютерные технологие построены на примерно одинаковых вещах, где есть типовые недостатки и подводные камни.
И такой подход я получил от своих преподавателей еще советской школы. Специалист — это не тот кто все знает, а кто знает где найти справочник или того, у кого можно проконсультироваться. И эти мои преподаватели делали прорывы в технологиях и науке.
А то что я вижу сейчас в собеседованиях — это стыд и позор. Набирают, такое ощущение, — лишь кодировщиков, кто бы очень быстро кодировал все, что им прикажут сверху. Раньше такая профессия была — Оператор ЭВМ. Очень похоже.
Если вы новичок в программировании, вам все-равно эти типовые головоломки ничего не дадут, хоть выучи наизусть, хоть месяцами сиди в интернете и штудируй курсы. А уж попытки вызубрить наизусть какие-нибудь популярные темы типа шаблонов проектирования или все классы стандартной библиотеки и вовсе тщетны. Через неделю все выветрится из головы.
Реальное обучение проходит напрямую в живом проекте, когда то что тебе нужо, находишь и применяешь. В этом деле через месяц уже станешь разбираться лучше абсолютного большинства тех, кто обучает на курсах. А если это станет твоей специализацией, так все тонкости раздобудешь и будешь в этих вопросах разбираться лучше чем большинство других программистов. Просто потому, что это тебе нужно и это твоя работа.
Если же ты уже опытный программист, все эти вопросы на собеседованиях раздражают. Если ваш собеседует живой человек, а не программа по отсеву программистов (бывает такая жесть — когда присылают ссылку на веб вопросник), он сразу оценивает тебя и переходит к твоему реальному уровню очень быстро. По крайней мере, у меня всегда было так. И меня брали с существенными пробелами в знаниях, потому что собеседующие были адекватными. Им нужен был не заучка и энциклопедист, а инженер.
Еще бывает такая вещь, как синдром вахтера. Когда HR работник лучше самого работодателя знает, кого надо нанять: высчитывает его психологическую карту, чуть ли не как на ТАРО строит твой почти гороскоп, загружая свою голову барахлом из псевдо-научных психологических верований. И занимается он такой фигней, искренне веря, что тем самым делает благое дело, не понимая, что его задача — поиск и первичный отсев тех, кто точно не подойдет. Не больше. Нормально собеседовать человека сможет прямой руководитель.
В-общем, фигня все эти задачки и попытки рыться в пробелах кандидатах. Прочитал я эти вопросы. В моем опыте абсолютное большинство указанных вопросов — то с чем программист скорей всего не столкнется. А если он чего-то подзабыл или не знает, ничего страшного — ему платят за то, чтобы он умел находить решения.
Лично мне коллеги-заучки не нужны.
Как быть, если вы заметили неадекватных собеседующих? Либо прямо про это им говорите либо молча уходите. Себе дороже терпеть этот бардак. Вам же с ними потом вместе работать. Но вы должны быть уверены в своих словах. Это не волшебная мантра, — вы должны готовы отстоять свои слова. Иначе не беритесь с кем-то спорить. Нет ничего смешнее человека, кто строит из себя крутого мачо, но на деле у него пшик. И не беритесь брать ответственность в тех вещах, где у вас немнного не хватает квалификации. Это ваша работа — уметь в условиях неизвестности решать трудные технические задачи. Мне такая тактика в свои годы позволила из только что окончившего ВУЗ птенца сразу перейти в разряд ключевых работников организации.
PS. Я профессиональный разработчик. Еще вживую видел перфокарты. Собеседовал несколько раз и сам принимал участие в собеседованиях. К сожалению, смотря на все это вокруг, становится очень грустно. Не потому что я что-то не знаю из того где лично меня «валили», а потому, что многие собеседующие и собеседуемые ничего не понимают в разработке — а на основе своих странных знаний о программировании принимают неверные решения.
Не писал никогда на хабр, но последние перлы на хабре касаемо собеседований не оставили меня в стороне.