Здравствуйте, Кодт, Вы писали:
E>>Мне просто интересно, ответ "Нужно глянуть в справочнике" когда-нибудь в природе встречался? E>>И если бы встретился, то к какой категории он был бы отнесен?
К>Бора с борометром уже упоминали, а этот ответ — тоже классика, кажется, Эдисон интервьюировал Эйнштейна.
Ну так как бы интересно: интервьюер, возомнивший себя Эдисоном, есть, а попадались ли ему кандидаты, мнящие себя Эйнштенами?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Lloyd, Вы писали:
L>Во-вторых, в подавляющем большинстве приложений необходимости в разработке архитектуры как таковой нет, достаточно знать существующие гайдлайны от зубров — микрософта, сана,... и придерживаться их.
Ну это очень вряд ли. С остальным согласен.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
L> Ага. Самого раз отсеяли — незнал зачем крышки круглые (кто знает тот знает) . Ощущения — боль ... обида. Злость в первую очередь на себя. Щас зп больше чем там предлагали в 2 раза. Контора больше. Много бонусов. Интересная работа. Переспективы роста. L> Спустя время даже благодарен что невзяли.
Вряд ли не взяли из-за этого. Я тоже люблю задавать подобные вопросы. Но в целом они мало влияют на оценку кандидата, и если влияют, то в положительную сторону. Т. е. я легко возьму того, кто демонстрирует умение программировать, но затрудняется с подобными задачками, но не наоборот. А если еще и с задачками легко расправляется -- это повод набросить уровень :-).
)
M>Собеседования. Найм программистов. M>(сильно не ругайте А ругайте несильно )
Сильно ругать не буду =)
Читать весь тред времени особо нет, но хочется прокомментировать, если повторюсь не обессудьте.
Начали вы очень здорово. Впечатлило. Потому что, стремление работадателя взять человека получше — действительно часто выражается в "найти поумнее, поспособнее и т.д.". Но я совершенно согласен, что человек который может следовать указаниям руководителя, проявляя __РАЗУМНУЮ ИНИЦИАТИВУ__ и то по большей части в research нежели development, который не гиперамбициозен, и нормально переносит рутину — принесет много больше конечной пользы, нежели философ-мегамозг. Обычно необходимый уровень хорошего исполнителя много ниже — запрашиваемого на собеседовании.
Но мой коментарий нацелен на указание следующих моментов:
1. "Мегамозг — это энтузиаст, который возьмет все и перепишет с использованием новейших технологий". Этот тезис вы использовали многократно. Но согласитесь — вы здесь пали жертвой шаблона. Это не мегамозг — это фанатик. Мегамозг — это человек, понимающий последствия всех принимаемых решений, и адекватно оценивающий требования заказчика. Это человек который способен обобщать и тем самым минимизировать работу. Человек накопивший достаточно опыта для того чтобы не наступать на известные "грабли". В общем, определение "мегамозга" — в вашей статье — очень слабое место. Потому что вы хотели разрушить одно заблуждение оперируя другим.
(Но нельзя не ответить, что люди строящие проектные команды иногда сами не достаточно профессиональны)
2. Over-qualification. Это то, что многие наниматели не берут в расчет. И это как раз та причина, которая толкает заскучавшего человека разнообразить свой рабочий день, переписывая "велосипед" на новый лад.
Имея опыт работы в нескольких конторах над разными проектами на разных должностях могу сказать вот что:
1) 80% тасков "новонанятым" программерам — support или bug fix старого (!!!) кода, реализованного с использованием старых технологий. Чаще всего код писался теми, кто уже уволился (или перешел на другой проект) + код этот довольно посредственного качества, хотя бывают исплючения.
2) В 95% случаях никаких мега-математических способностпей, знаний алгоритмов соритровок и умения рещать задачи о Фудзяме ВООБЩЕ не требуется для выполнения этих тасков. А требуется вот что: разбираться в технологии, которая использовалась для реализации фичи (например ASP.Net 3.5, WinForms или PHP и т.д.и т.п.) и разбираться в ТЗ и бизнес-логике приложения. Для этого не нужен мегамозг. Нужен адекватный человек, который способен за конечное время разобраться в чужом коде, что-то дописать, что-то поправить и в итоге пофиксить ошибку, не сделав при этом новых багов.
3) "Обычный" программер, получив таск начнет его выполнять, особо не задумываясь ни над чем. Мегамоск же придумает массу "оптимизаций" кода, процесса разработки, предложит сделать полный рефакторинг, переписать код с использованием 145 паттернов, разбить архитектуру на 25 уровней и т.п. Мегамосгу скучно просто фиксить баг. Он выше этого. Если ему вовремя не дать по рукам, а позволить сделать хотя бы 10% от того, что он предложит, проект может уже и не выплыть.
Вернемся к собеседованиям. Почему-то самые адекватные люди оказывались в тех контрорах, где собеседования были без "домашних заданий", без написаний на бумажке алгоритма сортировки массива, без тестов на время и без прочей ерунды. И наоборот — самая ужасная контора была та, где с порога тебя садят за 2 сложных теста (C# и OOP), потом требуют быстро решить 2 математических залачки — написать на бумажке код программы, решающей их, а потом идет своеобразный "допрос с пристрастием"... Да, они найдут себе мегамозгов таким макаром, отпугнут "средних" программеров. Вопрос — стоит ли оно того? Я, кстати, прошел все тесты, но выбрал другую контору тогда — очень рад этому сейчас.
Как и msk78, могу привести ряд реальных примеров из жизни, подтверждающих данные факты.
Здравствуйте, Lloyd, Вы писали:
L>Имхо, человек может забыть площадь круга только в том случае, если в свое время она была банально заучена, без попытки понять, откуда она берется.
я число Pi с кандычка то не выведу , не то что площадь круга. Нуууу может пользуясь приближениями , апроксимировать круг треугольниками ..
Здравствуйте, Davader, Вы писали:
D>Полностью согласен! Добавлю свой коментарий.
А я совершенно не согласен.
Пара примеров из моей практики:
— Было некоторое приложение, которое мы саппортили. Периодически в нем повреждались данные, причем эту ошибку никто не мог стабильно воспроизвести. На этот баг было потрачено разными людьми в разное время довольно много времени.
Попалась эта проблема на глаза хорошему разработчику. За один день был составлен 2х страничный документ, описывающий логику обращения к этим данным. При составления этого документа было найдено 6 потенциальных проблем в коде (я имею ввиду реальные потенциальные баги, а не ошибки уровня несогласованного coding style), при обсуждении — еще 3. В тот же день код удалось отрефакторить, сократив количество потоков, которое обращалось к этим данным, с 5ти до 2х. На следующий день код прошел код ревью, тестирование и был проинтегирован в текущую версию. Результат — данные больше не повреждаются, функциональность работает.
— То же самое приложение, баг в логике в одной из фич. Опять же, удалось переписать всю фукциональность за один день. Код в итоге стал поддерживаемым, баг исчез. Дельта кода — 1200 строк кода удалено, 300 добавлено.
Посмотрел бы я, как "обычный" программер справился бы с такими задачами.
Мне некоторые руководители возражают, что решать быстро и качественно сложные задачи в разработке ПО не надо, что проект выплывет и так. Не знаю, не видел я проектов, в которых без таких девелоперов можно обойтись. Зато видел много проектов, похороненных из-за недостаточной квалификации девелоперов. Код разрастается так, что его невозможно понять, становится сложно что-нибудь изменить, не побоясь сломать половину функциональности. Темп разработки новых фич и фикса багов уменьшается, так как девелоперам нужно разбираться в плохом коде и ставить на него заплатки.
D> Мегамоск же придумает массу "оптимизаций" кода, процесса разработки, предложит сделать полный рефакторинг, переписать код с использованием 145 паттернов, разбить архитектуру на 25 уровней и т.п.
Если команда считает, что скорость разработки от этого увеличится — почему нет?
D> Мегамосгу скучно просто фиксить баг. Он выше этого. Если ему вовремя не дать по рукам, а позволить сделать хотя бы 10% от того, что он предложит, проект может уже и не выплыть.
Ээээ... это где вы таких находили?
D> Как и msk78, могу привести ряд реальных примеров из жизни, подтверждающих данные факты.
На самом деле хочется услышать примеры. Может, где-то есть другие проекты, в которых мозгам делать действительно нечего?
Здравствуйте, Dirichlet, Вы писали:
D>Попалась эта проблема на глаза хорошему разработчику. За один день был составлен 2х страничный документ, описывающий логику обращения к этим данным. При составления этого документа было найдено 6 потенциальных проблем в коде (я имею ввиду реальные потенциальные баги, а не ошибки уровня несогласованного coding style), при обсуждении — еще 3
Скажите, пожалуйста, а какие именно знания помогли хорошему разработчику решить эту проблему? Знания алгоритмов сортировки или умение решать задачу о Фудзияме?
D>Зато видел много проектов, похороненных из-за недостаточной квалификации девелоперов. Код разрастается так, что его невозможно понять, становится сложно что-нибудь изменить, не побоясь сломать половину функциональности. Темп разработки новых фич и фикса багов уменьшается, так как девелоперам нужно разбираться в плохом коде и ставить на него заплатки.
Знакомо. Данный сценарий говорит не о недостаточной квалификации разработчиков, а о недостаточной квалификации тимлидов и менеджеров, которые неправильно оценили сложность проекта и квалификацию разработчиков
Здравствуйте, MescalitoPeyot, Вы писали:
MP>Здравствуйте, Dirichlet, Вы писали:
D>>Попалась эта проблема на глаза хорошему разработчику. За один день был составлен 2х страничный документ, описывающий логику обращения к этим данным. При составления этого документа было найдено 6 потенциальных проблем в коде (я имею ввиду реальные потенциальные баги, а не ошибки уровня несогласованного coding style), при обсуждении — еще 3
MP>Скажите, пожалуйста, а какие именно знания помогли хорошему разработчику решить эту проблему? Знания алгоритмов сортировки или умение решать задачу о Фудзияме?
Предположу, что хорошие знания языка программирования и способов синхронизации потоков + умение понимать чужой код и писать свой + представление о теории графов и алгоритме топологической сортировки.
D>>>Попалась эта проблема на глаза хорошему разработчику. За один день был составлен 2х страничный документ, описывающий логику обращения к этим данным. При составления этого документа было найдено 6 потенциальных проблем в коде (я имею ввиду реальные потенциальные баги, а не ошибки уровня несогласованного coding style), при обсуждении — еще 3
D>Предположу, что хорошие знания языка программирования и способов синхронизации потоков + умение понимать чужой код и писать свой + представление о теории графов и алгоритме топологической сортировки.
философию ещё забыл. без знания основного вопроса филосфии вообще труба
Здравствуйте, BulatZiganshin, Вы писали:
D>>Предположу, что хорошие знания языка программирования и способов синхронизации потоков + умение понимать чужой код и писать свой + представление о теории графов и алгоритме топологической сортировки.
BZ>философию ещё забыл. без знания основного вопроса филосфии вообще труба
И где я не прав? Без чего-то из того что я перечислил можно нормально фиксить баги в чужом многопоточном коде?
я тоже репу чешу, зачем для синхронизации потоков нужно знать сортировку и теорию графов? логичнее предположить, что для этого нужно знать, какие объекты синхронизации используются, чем они отличаются и как их использовать.
Здравствуйте, игппук, Вы писали:
И>я тоже репу чешу, зачем для синхронизации потоков нужно знать сортировку и теорию графов? логичнее предположить, что для этого нужно знать, какие объекты синхронизации используются, чем они отличаются и как их использовать.
Чтобы отловить deadlock, например, на 4х потоках и 4х ресурсах.
Здравствуйте, MescalitoPeyot, Вы писали:
MP>Скажите, пожалуйста, а какие именно знания помогли хорошему разработчику решить эту проблему?
Подозреваю что опыт
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
E>Ну так как бы интересно: интервьюер, возомнивший себя Эдисоном, есть, а попадались ли ему кандидаты, мнящие себя Эйнштенами?
Имеется пример из жизни:
Интервью на должность NET разработчика. Работодатель дает задачку
Ванна заполняется водой из крана за 5 минут, а опорожняется через слив — за 3 минуты.
За сколько опорожнится ванна, если открыть слив и включить кран?
И вот тут надо очень вниметельно смотреть на работодателя и угадывать, что у него было по физике в школе. Если на морде написано, что не больше тройки, то вычитаем из одной дроби другую — и тест пройден.
Однако, если работодатель похож на физтеховца, то говорим о зависимости скорости опорожнения от уровня воды, рисуем ванную, делаем допущения о размерах, набрасываем дифур, говорим что "решать впадулу" — и получаем все шансы занять вакансию
-----
Любимая фраза физика-теоретика: "Вот видите, мы ошиблись всего лишь на порядок".
уже упоминали, а этот ответ — тоже классика, кажется, Эдисон интервьюировал Эйнштейна.
