Сообщение Re: Своя IT-фирма: о найме разработчиков и по мотивам недавн от 23.11.2015 12:07
Изменено 23.11.2015 12:17 ELazin
S> — те, кто против выполнения каких-либо тестовых заданий вообще;
S> — те, кто против выполнения ТЗ на дому (а на собеседовании — ок).
Против первого и второго.
ТЗ на дому обычно у всех объемное, мне в одной конторе однажды заявили что, цитирую "задание совсем небольшое, примерно на 6-8 часов, можно один выходной выделить и все сделать". После этого товарищи незамедлительно пошли лесом. Работодателю следует задаться вопросом — срхена ли кто-то в здравом уме и памяти должен тратить 8 часов своего личного времени на тз в компанию, в которую еще могут и не взять, и за которые не заплатят ни копейки. Если это не убеждает, возможно убедит следующее — самый обычный программист в поисках работы обычно находится в процессе общения с множеством компаний одновременно, чаще всего при этом он продолжает работать на текущем месте работы. Если одна из этих компаний пошлет его делать объемное ТЗ, очень вероятно, что выбор будет сделать в пользу тех кто не пошлет. В общем, ТЗ это чаще всего непрофессионализм работодателя. Я один раз делал ТЗ, в поиск яндекса. Но там ТЗ во первых — достаточно интересное (нужно было написать свой поиск и добиться определенной релевантности), во вторых, его можно было сделать довольно быстро, по крайней мере если ты знаком с основами IR.
S>Нет, друзья, нихрена код не показывает. Код позволяет увидеть стиль программирования, но не личные качества. Я много раз встречал примеры аккуратно, хорошо оформленного кода, который работал неправильно. Причины могли быть разные: либо ошибка на системном уровне, либо более мелкие ошибки из-за невнимательности (а это важно!). Вникать же в представленный код настолько глубоко, чтобы находить подобные ошибки — у меня просто банально нет на это времени. Как вы думаете, если на объявление на каком-нибудь hh.ru приходит более 100 откликов за неделю, реально ли подробно и детально изучить код каждого из них? Неважно, кому это делать: мне, или тимлиду — времени уйдет очень много, и реальная работа на это время встанет. И еще раз хочу напомнить: красиво оформленный код нередко работает плохо!
Можно почитать код и понять, хороший это код или нет. Не обязательно читать код полностью для этого, просто взять и поревьюить его 30-40 минут. Часто достаточно 5-10 минут для того, чтобы сформулировать какие-нибудь претензии/вопросы по коду, по которым уже можно будет дальше разговаривать и обсуждать. Все любят потрепаться, мало кто может взять и сделать, так ты тут писал? Вот это как раз тот случай — нужно взять и вникнуть. Не получится добиться результата не вникая. Даже если все сделают вам ТЗ, толку от этого не будет, если вы будете изучать ТЗ поверхностно.
S>У тестового задания есть очень хороший плюс. Это задание, выданное разным кандидатам, позволяет _сравнить_ их между собой. Для начала можно даже несильно вникать в код. Достаточно просто прогнать различные тестовые ситуации.
Это заблуждение. Сравнивая код разных кандидатов в итоге выберешь того, кто пишет наиболее понятным/близким для тебя способом. Ревью более объективный процесс, так как в ходе ревью ты должен найти не то что тебе нравится или не нравится, а объективные проблемы.
S>Кстати, еще ремарка. У успешных и известных компаний подход аналогичен. Скажем, тестовые задания на дом есть у яндекса, есть у студии Лебедева. И нельзя сказать, что они очень маленькие (хотя зависит от должности). Можно возразить, что я — не студия Лебедева, но значит ли это, что нельзя брать пример с лучших компаний? А может быть они не просто так стали лучшими?
Не знаю как у Лебедева, но у Яндекса ТЗ — это просто способ отсеять совсем уж дебилов. У них очень большой поток кандидатов. ТЗ очень простое (можно на сайте у них посмотреть), ТЗ посложнее у них есть не во всех командах (насколько я знаю). Основное у них — собеседование в офисе.
S>Так вот, там нужно было взять несколько человек непрограммистской направленности, а именно: руководителя IT-службы, руководителя отдела обучения, менеджера сопровождения. Руководитель IT должен сформировать свой отдел, т.е. набрать сисадминов, и обеспечивать нормальное функционирование инфраструктуры у наших клиентов (клиник). Отдел обучения должен обучать юзеров нашей программе. Менеджер сопровождения — ну что-то типа личного менеджера у каждого клиента, хорошо знает нашу программу, помогает им в сложных вопросах, передает нам их хотелки.
S>Еще, что меня поразило — это крайне низкий уровень технических знаний у IT-директоров. Почти никто не знал отличия BIOS от UEFI, никто не знал что такое GPT-диск, на вопрос "чем fat32 отличается от ntfs" наиболее распространенный ответ — "у ntfs размер раздела может быть больше", как реально работает маска подсети почти никто не знает, ну а wildcard-маска — это вопрос-fatality
Зачем это все знать управленцу? Я вот, например, не знаю без гугла чем BIOS отличается от UEFI и что такое GPT. 10 лет в индустрии коту под хвост, видимо.
В общем, не стоит забывать о том что тут обе стороны выбирают. Рынок труда не трещит от толковых программистов, скорее наоборот — он трещит от бестолковых работодателей, так что делаем выводы.
S> — те, кто против выполнения ТЗ на дому (а на собеседовании — ок).
Против первого и второго.
ТЗ на дому обычно у всех объемное, мне в одной конторе однажды заявили что, цитирую "задание совсем небольшое, примерно на 6-8 часов, можно один выходной выделить и все сделать". После этого товарищи незамедлительно пошли лесом. Работодателю следует задаться вопросом — срхена ли кто-то в здравом уме и памяти должен тратить 8 часов своего личного времени на тз в компанию, в которую еще могут и не взять, и за которые не заплатят ни копейки. Если это не убеждает, возможно убедит следующее — самый обычный программист в поисках работы обычно находится в процессе общения с множеством компаний одновременно, чаще всего при этом он продолжает работать на текущем месте работы. Если одна из этих компаний пошлет его делать объемное ТЗ, очень вероятно, что выбор будет сделать в пользу тех кто не пошлет. В общем, ТЗ это чаще всего непрофессионализм работодателя. Я один раз делал ТЗ, в поиск яндекса. Но там ТЗ во первых — достаточно интересное (нужно было написать свой поиск и добиться определенной релевантности), во вторых, его можно было сделать довольно быстро, по крайней мере если ты знаком с основами IR.
S>Нет, друзья, нихрена код не показывает. Код позволяет увидеть стиль программирования, но не личные качества. Я много раз встречал примеры аккуратно, хорошо оформленного кода, который работал неправильно. Причины могли быть разные: либо ошибка на системном уровне, либо более мелкие ошибки из-за невнимательности (а это важно!). Вникать же в представленный код настолько глубоко, чтобы находить подобные ошибки — у меня просто банально нет на это времени. Как вы думаете, если на объявление на каком-нибудь hh.ru приходит более 100 откликов за неделю, реально ли подробно и детально изучить код каждого из них? Неважно, кому это делать: мне, или тимлиду — времени уйдет очень много, и реальная работа на это время встанет. И еще раз хочу напомнить: красиво оформленный код нередко работает плохо!
Можно почитать код и понять, хороший это код или нет. Не обязательно читать код полностью для этого, просто взять и поревьюить его 30-40 минут. Часто достаточно 5-10 минут для того, чтобы сформулировать какие-нибудь претензии/вопросы по коду, по которым уже можно будет дальше разговаривать и обсуждать. Все любят потрепаться, мало кто может взять и сделать, так ты тут писал? Вот это как раз тот случай — нужно взять и вникнуть. Не получится добиться результата не вникая. Даже если все сделают вам ТЗ, толку от этого не будет, если вы будете изучать ТЗ поверхностно.
S>У тестового задания есть очень хороший плюс. Это задание, выданное разным кандидатам, позволяет _сравнить_ их между собой. Для начала можно даже несильно вникать в код. Достаточно просто прогнать различные тестовые ситуации.
Это заблуждение. Сравнивая код разных кандидатов в итоге выберешь того, кто пишет наиболее понятным/близким для тебя способом. Ревью более объективный процесс, так как в ходе ревью ты должен найти не то что тебе нравится или не нравится, а объективные проблемы.
S>Кстати, еще ремарка. У успешных и известных компаний подход аналогичен. Скажем, тестовые задания на дом есть у яндекса, есть у студии Лебедева. И нельзя сказать, что они очень маленькие (хотя зависит от должности). Можно возразить, что я — не студия Лебедева, но значит ли это, что нельзя брать пример с лучших компаний? А может быть они не просто так стали лучшими?
Не знаю как у Лебедева, но у Яндекса ТЗ — это просто способ отсеять совсем уж дебилов. У них очень большой поток кандидатов. ТЗ очень простое (можно на сайте у них посмотреть), ТЗ посложнее у них есть не во всех командах (насколько я знаю). Основное у них — собеседование в офисе.
S>Так вот, там нужно было взять несколько человек непрограммистской направленности, а именно: руководителя IT-службы, руководителя отдела обучения, менеджера сопровождения. Руководитель IT должен сформировать свой отдел, т.е. набрать сисадминов, и обеспечивать нормальное функционирование инфраструктуры у наших клиентов (клиник). Отдел обучения должен обучать юзеров нашей программе. Менеджер сопровождения — ну что-то типа личного менеджера у каждого клиента, хорошо знает нашу программу, помогает им в сложных вопросах, передает нам их хотелки.
S>Еще, что меня поразило — это крайне низкий уровень технических знаний у IT-директоров. Почти никто не знал отличия BIOS от UEFI, никто не знал что такое GPT-диск, на вопрос "чем fat32 отличается от ntfs" наиболее распространенный ответ — "у ntfs размер раздела может быть больше", как реально работает маска подсети почти никто не знает, ну а wildcard-маска — это вопрос-fatality
Зачем это все знать управленцу? Я вот, например, не знаю без гугла чем BIOS отличается от UEFI и что такое GPT. 10 лет в индустрии коту под хвост, видимо.
В общем, не стоит забывать о том что тут обе стороны выбирают. Рынок труда не трещит от толковых программистов, скорее наоборот — он трещит от бестолковых работодателей, так что делаем выводы.
Re: Своя IT-фирма: о найме разработчиков и по мотивам недавн
S> — те, кто против выполнения каких-либо тестовых заданий вообще;
S> — те, кто против выполнения ТЗ на дому (а на собеседовании — ок).
Против первого и второго.
ТЗ на дому обычно у всех объемное, мне в одной конторе однажды заявили что, цитирую "задание совсем небольшое, примерно на 6-8 часов, можно один выходной выделить и все сделать". После этого товарищи незамедлительно пошли лесом. Работодателю следует задаться вопросом — срхена ли кто-то в здравом уме и памяти должен тратить 8 часов своего личного времени на тз в компанию, в которую еще могут и не взять, и за которые не заплатят ни копейки. Если это не убеждает, возможно убедит следующее — самый обычный программист в поисках работы обычно находится в процессе общения с множеством компаний одновременно, чаще всего при этом он продолжает работать на текущем месте работы. Если одна из этих компаний пошлет его делать объемное ТЗ, очень вероятно, что выбор будет сделать в пользу тех кто не пошлет. В общем, ТЗ это чаще всего непрофессионализм работодателя. Я один раз делал ТЗ, в поиск яндекса. Но там ТЗ во первых — достаточно интересное (нужно было написать свой поиск и добиться определенной релевантности), во вторых, его можно было сделать довольно быстро, по крайней мере если ты знаком с основами IR.
S>Нет, друзья, нихрена код не показывает. Код позволяет увидеть стиль программирования, но не личные качества. Я много раз встречал примеры аккуратно, хорошо оформленного кода, который работал неправильно. Причины могли быть разные: либо ошибка на системном уровне, либо более мелкие ошибки из-за невнимательности (а это важно!). Вникать же в представленный код настолько глубоко, чтобы находить подобные ошибки — у меня просто банально нет на это времени. Как вы думаете, если на объявление на каком-нибудь hh.ru приходит более 100 откликов за неделю, реально ли подробно и детально изучить код каждого из них? Неважно, кому это делать: мне, или тимлиду — времени уйдет очень много, и реальная работа на это время встанет. И еще раз хочу напомнить: красиво оформленный код нередко работает плохо!
Можно почитать код и понять, хороший это код или нет. Не обязательно читать код полностью для этого, просто взять и поревьюить его 30-40 минут. Часто достаточно 5-10 минут для того, чтобы сформулировать какие-нибудь претензии/вопросы по коду, по которым уже можно будет дальше разговаривать и обсуждать. Все любят потрепаться, мало кто может взять и сделать, так ты тут писал? Вот это как раз тот случай — нужно взять и вникнуть. Не получится добиться результата не вникая. Даже если все сделают ТЗ, толку от этого не будет, если ты будешь изучать ТЗ поверхностно.
S>У тестового задания есть очень хороший плюс. Это задание, выданное разным кандидатам, позволяет _сравнить_ их между собой. Для начала можно даже несильно вникать в код. Достаточно просто прогнать различные тестовые ситуации.
Это заблуждение. Сравнивая код разных кандидатов в итоге выберешь того, кто пишет наиболее понятным/близким для тебя способом. Ревью более объективный процесс, так как в ходе ревью ты должен найти не то что тебе нравится или не нравится, а объективные проблемы.
S>Кстати, еще ремарка. У успешных и известных компаний подход аналогичен. Скажем, тестовые задания на дом есть у яндекса, есть у студии Лебедева. И нельзя сказать, что они очень маленькие (хотя зависит от должности). Можно возразить, что я — не студия Лебедева, но значит ли это, что нельзя брать пример с лучших компаний? А может быть они не просто так стали лучшими?
Не знаю как у Лебедева, но у Яндекса ТЗ — это просто способ отсеять совсем уж дебилов. У них очень большой поток кандидатов. ТЗ очень простое (можно на сайте у них посмотреть), ТЗ посложнее у них есть не во всех командах (насколько я знаю). Основное у них — собеседование в офисе.
S>Так вот, там нужно было взять несколько человек непрограммистской направленности, а именно: руководителя IT-службы, руководителя отдела обучения, менеджера сопровождения. Руководитель IT должен сформировать свой отдел, т.е. набрать сисадминов, и обеспечивать нормальное функционирование инфраструктуры у наших клиентов (клиник). Отдел обучения должен обучать юзеров нашей программе. Менеджер сопровождения — ну что-то типа личного менеджера у каждого клиента, хорошо знает нашу программу, помогает им в сложных вопросах, передает нам их хотелки.
S>Еще, что меня поразило — это крайне низкий уровень технических знаний у IT-директоров. Почти никто не знал отличия BIOS от UEFI, никто не знал что такое GPT-диск, на вопрос "чем fat32 отличается от ntfs" наиболее распространенный ответ — "у ntfs размер раздела может быть больше", как реально работает маска подсети почти никто не знает, ну а wildcard-маска — это вопрос-fatality
Зачем это все знать управленцу? Я вот, например, не знаю без гугла чем BIOS отличается от UEFI и что такое GPT. 10 лет в индустрии коту под хвост, видимо.
В общем, не стоит забывать о том что тут обе стороны выбирают. Рынок труда не трещит от толковых программистов, скорее наоборот — он трещит от бестолковых работодателей, так что делаем выводы.
S> — те, кто против выполнения ТЗ на дому (а на собеседовании — ок).
Против первого и второго.
ТЗ на дому обычно у всех объемное, мне в одной конторе однажды заявили что, цитирую "задание совсем небольшое, примерно на 6-8 часов, можно один выходной выделить и все сделать". После этого товарищи незамедлительно пошли лесом. Работодателю следует задаться вопросом — срхена ли кто-то в здравом уме и памяти должен тратить 8 часов своего личного времени на тз в компанию, в которую еще могут и не взять, и за которые не заплатят ни копейки. Если это не убеждает, возможно убедит следующее — самый обычный программист в поисках работы обычно находится в процессе общения с множеством компаний одновременно, чаще всего при этом он продолжает работать на текущем месте работы. Если одна из этих компаний пошлет его делать объемное ТЗ, очень вероятно, что выбор будет сделать в пользу тех кто не пошлет. В общем, ТЗ это чаще всего непрофессионализм работодателя. Я один раз делал ТЗ, в поиск яндекса. Но там ТЗ во первых — достаточно интересное (нужно было написать свой поиск и добиться определенной релевантности), во вторых, его можно было сделать довольно быстро, по крайней мере если ты знаком с основами IR.
S>Нет, друзья, нихрена код не показывает. Код позволяет увидеть стиль программирования, но не личные качества. Я много раз встречал примеры аккуратно, хорошо оформленного кода, который работал неправильно. Причины могли быть разные: либо ошибка на системном уровне, либо более мелкие ошибки из-за невнимательности (а это важно!). Вникать же в представленный код настолько глубоко, чтобы находить подобные ошибки — у меня просто банально нет на это времени. Как вы думаете, если на объявление на каком-нибудь hh.ru приходит более 100 откликов за неделю, реально ли подробно и детально изучить код каждого из них? Неважно, кому это делать: мне, или тимлиду — времени уйдет очень много, и реальная работа на это время встанет. И еще раз хочу напомнить: красиво оформленный код нередко работает плохо!
Можно почитать код и понять, хороший это код или нет. Не обязательно читать код полностью для этого, просто взять и поревьюить его 30-40 минут. Часто достаточно 5-10 минут для того, чтобы сформулировать какие-нибудь претензии/вопросы по коду, по которым уже можно будет дальше разговаривать и обсуждать. Все любят потрепаться, мало кто может взять и сделать, так ты тут писал? Вот это как раз тот случай — нужно взять и вникнуть. Не получится добиться результата не вникая. Даже если все сделают ТЗ, толку от этого не будет, если ты будешь изучать ТЗ поверхностно.
S>У тестового задания есть очень хороший плюс. Это задание, выданное разным кандидатам, позволяет _сравнить_ их между собой. Для начала можно даже несильно вникать в код. Достаточно просто прогнать различные тестовые ситуации.
Это заблуждение. Сравнивая код разных кандидатов в итоге выберешь того, кто пишет наиболее понятным/близким для тебя способом. Ревью более объективный процесс, так как в ходе ревью ты должен найти не то что тебе нравится или не нравится, а объективные проблемы.
S>Кстати, еще ремарка. У успешных и известных компаний подход аналогичен. Скажем, тестовые задания на дом есть у яндекса, есть у студии Лебедева. И нельзя сказать, что они очень маленькие (хотя зависит от должности). Можно возразить, что я — не студия Лебедева, но значит ли это, что нельзя брать пример с лучших компаний? А может быть они не просто так стали лучшими?
Не знаю как у Лебедева, но у Яндекса ТЗ — это просто способ отсеять совсем уж дебилов. У них очень большой поток кандидатов. ТЗ очень простое (можно на сайте у них посмотреть), ТЗ посложнее у них есть не во всех командах (насколько я знаю). Основное у них — собеседование в офисе.
S>Так вот, там нужно было взять несколько человек непрограммистской направленности, а именно: руководителя IT-службы, руководителя отдела обучения, менеджера сопровождения. Руководитель IT должен сформировать свой отдел, т.е. набрать сисадминов, и обеспечивать нормальное функционирование инфраструктуры у наших клиентов (клиник). Отдел обучения должен обучать юзеров нашей программе. Менеджер сопровождения — ну что-то типа личного менеджера у каждого клиента, хорошо знает нашу программу, помогает им в сложных вопросах, передает нам их хотелки.
S>Еще, что меня поразило — это крайне низкий уровень технических знаний у IT-директоров. Почти никто не знал отличия BIOS от UEFI, никто не знал что такое GPT-диск, на вопрос "чем fat32 отличается от ntfs" наиболее распространенный ответ — "у ntfs размер раздела может быть больше", как реально работает маска подсети почти никто не знает, ну а wildcard-маска — это вопрос-fatality
Зачем это все знать управленцу? Я вот, например, не знаю без гугла чем BIOS отличается от UEFI и что такое GPT. 10 лет в индустрии коту под хвост, видимо.
В общем, не стоит забывать о том что тут обе стороны выбирают. Рынок труда не трещит от толковых программистов, скорее наоборот — он трещит от бестолковых работодателей, так что делаем выводы.