Ставлю плюс. Чувствую, что придется писать еще одну статью — про сетевую жизнь на Западе, много недопонимания. Когда я только приехал в Канаду, я был поражен что чуть ли у каждого фонарного столба есть фейсбук и твиттер. Вполне обычное явление — увидить какого-нибудь бомжа с ноутом, сидящим в фейсбуке около старбакса с бесплатным вайфаем (правда это относится больше к Канаде, потому что сильная социалка, когда можно бомжевать чисто из принципа). Я уже не говорю о некоторых сайтах для поиска работы, в анкете которых обязательная ссылка на Linked In профиль.
Надо учитывать реалии запада (поэтому я и сделал уточнение, что для России ситуация может быть другая). Linked In — это практически уже стандарт де-факто. Свой проект, даже минимальный, на github-e еще заставляют делать в университете или колледже (не во всех конечно, но со специализацией в IT). Засветиться на stackoverflow — это дело чести, народ специально пишет максимально осмысленные комментарии, что иметь высокую «карму». Все это — часть рекламирования себя, и человек с минимальным сетевым присутствием воспринимается именно так, как я описал. Это другая культура, и таких параноиков как RMS, абсолютное меньшинство, люди не пытаются скрыться всеми способами.
Это система не была придумана мною, я предпочитаю другого рода тестирования, однако предполагаю следующие причины:
— подготовка к техническому интервью. Даже если кандидат все скопирует с Интернета, у него будет время разобраться с решениями и подтянуть недостающие знания.
— оценка честности кандидата. Если кандидат гуглил, но потом не может объяснить как это работает, и не признается в гуглении, это практически сразу крест на нем. Должен признать, что 80% признается, оставшиеся 20% конечно же отбрасываются.
— часть вопросов кандидаты стараются все-таки решить сами, и можно сразу видеть квалификацию еще до интервью. Например, в одном из заданий дается возможность использовать любую библиотеку JS, либо не использовать вообще никаких библиотек. Сделанный выбор позволяет составить какое-то мнение о соответствующих навыках.
Я не знаю деталей парсера, но по результатам парсинга (БД хранит оригинальный файл резюме для сравнения) сделал следующие выводы: текстовые форматы парсятся наилучшим образом (что очевидно), вордовские доки не особо, особенно со всякими шаблонами и навороченной графикой. Мне кажется что используется какой-то виртуальный принтер в текст, потому что HTML парсится не намного лучше какого-нибудь PDF. Так что (мое личное мнение, как я уже сказал, я не знаю деталей) только позиция и формат текста важны. Некоторые сайты типа того же monster.com или linkedin (возможно dice.com), у которых есть парсеры резюме, обычно дают грамотные рекомендации и примеры, как лучше оформлять резюме.
Вообще, по многим пунктам я с вами совершенно согласен. И вообще пост был сделан именно с целью, как все происходит в реальном мире, а не в вакууме в сферическими конями. Однако хочу уточнить пункты.
1. Нужны именно С+Python+Web. Это специфика разработки под встраиваемые системы. Хотя мы и пытаемся все делать на питоне, но с некоторым API (мониторинг, диагностика, специфическое конфигурирования, включая системные запросы к драйверам) приходится взаимодействовать напрямую в Си. Немного помогает Cython, но все равно нужно знать Си.
2. Системы управления проектами — это хорошо и замечательно. Но когда вам звонят из офиса Майкрософт, и говорят, чтобы починили «прям счас», у многих возникает паника, и все идет мимо кассы. Я совершенно не согласен с такой позицией (прогибаться под Майкрософт, госструктуры и т.п.), но в компании именно такая политика. Хотя думаю, это оправдано с позиции бизнеса — «клиент всегда прав».
3. Вообще-то мне ваше удивление немного непонятно. Неужели вы думаете, что в компаниях, которые у всех на слуху, текут молочные реки и все кружат хороводы в дружном единении? Везде есть свои «племянники», «друзья», ленивые работники и некомпетентные менеджеры. Поэтому сейчас и популярна культура стартапов, потому что позволяет этого избежать. Но великая тройка (Google, Apple, MS) скупает эти стартапы с бешеной силой, и формирует огромные патентные пакеты, давящие другие стартапы, и если честно, я немного опасаюсь, чем это все закончится.
Ну если вы по памяти сможете написать селектор типа p:nth-last-of-type(2n+1) и назвать это азами, то я вас поздравляю. Не все люди гении и с феноменальной памятью. Тоже самое касается и «домашнего» задания — иногда полтора часа маловато, особенно если затрагиваются много несвязных областей. Я весьма уверен, что есть не так много разработчиков, которым приходится одновременно работать C + Python + HTML/JS/CSS (особенно Си).
P.S. Лично я тоже считаю, что никакого стресса возникать не должно, и все должны знать что у malloc-а двойное поведение в зависимости от размера выделяемого объекта. Однако я не навязываю свою точку зрения.
В больших компаниях другие масштабы. Например, у нас был человек, который полгода делал один проект без единого коммита, все локально, просто показывал демо. К слову сказать, код у него был достаточно хорошим, он специалист своего дела. Но потом ему пришлось уволиться по семейным обстоятельствам (переезд в другую страну). Начальство почесало голову, и решило просто забить на этот проект. Я не говорю, что это хорошо, это просто реалии больших компаний (вспомним гугл и сколько проектов они начинали и убивали).
Хм, наверное мне стоило уточнить. Мой отдел — это всего-лишь маленькая команда разработчиков одной части функционала. У нас очень много команд — software development (и моя команда — лишь одна из многих), hardware development, QA, marketing/sales и и т.п. У нас есть сотрудники, которым и по 70 (!) лет (пенсии всегда мало, даже канадской). Присылают резюме люди разного возраста, и под 60. Думаю, самый высокий процент разработчиков старше 50 в отделе разработки железа, там никакие новые технологии не нужны, сиди себе и делай распайки и сборки на базе готовых схем от ARM, Intel и т.п. Навскидку наверное процентов 20. В отделе тестирования процент намного выше, как бы даже не половина всех тестеров старше 50. Но я не могу сказать точно, хорошая экология и здоровый образ жизни приводят к тому, что на глаз оценить возраст достаточно проблематично, многие и в 60 выглядят на 35-40.
Не все отделы имеют жесткий ценз на коммиты. Иногда просто ставится задача, и коммиты когда будут, тогда и будут. Лично я требую частые коммиты, но не все менеджеры разделяют это мнение. Особенно когда им приходится сталкиваться с разработчиками «старой закалки», которые не хотят коммитить код пока его не отшлифуют. А учитывая разницу в возрасте, когда разработчик старше своего менеджера на 20 лет, то менеджер просто опасается пойти наперекор. Но это уже социальный фактор.
Вообще на западе совершенно другое отношение к возрасту (потому что сама индустрия постарше). В моем отделе есть 2 человека 40+ (47 и 43), оба просто разработчики, не архитекторы или менеджеры, и эта ситуация вполне нормальная. Разговоры про пенсию и социальные гарантии не относятся к чему-то мифическому, а вполне адекватные. Так что никаких ограничений нет. И это не только в нашей компании, а в абсолютном большинстве, включая стартапы.
Да я и не спорю, и ни в коем случае не ставил целью что-то рекламировать или советовать. Я просто описал то, что есть. Но должен отметить, что такого рода проблемы есть у многих крупных компаний, особенно с ярко выраженным воплощением закона Паркинсона, когда разработчики становятся менеджерами, не особо понимая как это делать и пуская дела на самотек.
Ха, ничего подобного. Это стереотип, который я бы не хотел видеть у кандидатов (но конечно вижу очень часто). Любой начальник любит, когда под него прогибаются, однако надо знать рамки. На западе интервью — это больше торг, чем экзамен. У кандидата есть товар — его навыки и знания, у интервьюверов есть потребность в покупке этого «товара» (не было бы потребности, они бы и не искали). Никто на реальном рынке не согласится продать товар за бесценок, при этом кланяясь в ноги (кроме отчаянных ситуаций). Конечно, последнее слово всегда за покупателем, но это не значит, что надо соглашаться на все. В интернете очень много статей на тему, как правильно продать себя, как правильно проходить интервью, и одно из первых правил — это установка личного контакта, включая и постановку вопросов. Просто надо понимать, что для интервьювера (как в принципе, и для экзаменатора) интервью — это очень скучный процесс, и они всегда рады сделать его менее скучным. Такой же трюк можно использовать и на экзаменах — я помню, когда я получил 5, не ответив и на половину вопросов, но при этом я установил контакт с экзаменатором, и мы вместе пришли к решению вопросов, которые я не осилил.
Да, я понимаю, что это немного дико для программистов, которые считаются несколько замкнутыми в себе людьми, но это очень неплохо работает, и такие навыки сильно увеличивают шансы на успехи в жизни :)
P.S. В России ситуация все-таки с этим похуже, потому что открытость считается чем-то плохим и подозрительным, но с адекватными людьми тоже работает.
«ситуация собеседования уточняющие вопросы задавать не позволяет, чтобы не выглядеть идиотом» — это одна из ошибок, зачастую совершаемая кандидатами. На интервью анализируются не только технические, но и социальные навыки. Можно быть хорошим программистом, но если на все ответы думать по полчаса ища подвох, не смотреть в глаза и держаться скованно, то есть большой шанс получить отказ, потому что менеджеры решат, что такой человек не сможет работать в команде.
Я понимаю, что есть исключения, но мой опыт показывает, что индивидуалисты склонны решать проблемы только своей головой, не консультируясь ни с менеджерами, ни с коллегами. Зачастую это приводит к тому, что их решение хоть и brilliant, но по сути своей ошибочно, потому что они не учли каких-то факторов или требований, которые не были озвучены в спецификации или багрепорте. Когда им указывают на ошибку, они начинают старую песню про то, что «этого не было в спецификации, так что это ваши проблемы». К сожалению, мир не идеален, и особенно в условиях жесткой конкуренции необходимо учитывать, что всего не учтешь. Естественно, есть инструменты, чтобы минимизировать риски — тот же процесс codereview, однако и он зачастую заканчивается перепалками и обвинениями в некомпентности, только уже в онлайне.
Хорошо, напишу статью чуть попозжу. Вообще, работа с большой транснациональной компании открыла глаза, как все может быть запущено — и со стороны кандидатов, и со стороны интервьюверов.
Насчет int-а. Ваш ответ весьма замечателен, многие даже не задумываются про нюансы. Но в целом, я имел в виду баг на переполнение, которые некоторые «специалисты» делают, т.к. не особо осведомлены про разрядность. Например, у них все работает на x86-64 платформе, а потом оказывается, что ARM-платформа «почему-то» не работает (и конечно же виноваты разработчики процессора, слишком много там багов, вон даже Торвальдс ругается).
Как человеку по той стороны баррикады (тому, кто проводит много интервью), позвольте мне побыть адвокатом дьявола и объяснить некоторые нюансы. Сразу скажу, что по-русски я технические термины уже не употребляю достаточно давно, так что буду писать кое-где по английски, чтобы не делать коверканных переводов. Ответ достаточно большой, возможно кто-то захочет увидеть полноценную статью, дайте знать. Также надо отметить, что интервью junior-ов и senior-ов разные, далее я имею в виду именно последнее (автор явно не junior).
Сначала в поддержку автора. Многие интервьюеверы ленивы и недалеки. Не в последнюю очередь это из-за того, что они бывшие программисты, которых подняли до менеджера, но при этом они не имеют никаких социальных навыков для этого. Для них интервью — это просто трата времени, поэтому они быстро гуглят одни и те же вопросы, и повысив свое ЧСВ за счет унижения кандидата, они довольные собой, дают отказ. Причем отказ этот зачастую имеет эмоциональную природу («он — тупой, не знает алгоритма вычисления пи, а я такой умный и все знаю», либо «он — слишком умный и подсидит меня на моем теплом местечке»). Но не все такие.
Про резюме. Я никогда не доверяю резюме. Большой опыт ни о чем не говорит — это может быть большой опыт написания миллиона строк там, где использование библиотек или даже хорошего знания инструментария позволило бы сократить этот код до нескольких сотен строк. Или например, «LLVM contributor», что в реальности может быть — «LLVM вываливался на мой говнокод, пришлось связываться с разработчиками, и через месяц я еле как разобрался с gdb и смог-таки найти ошибочную строку. Потом еще целый месяц делал патч, т.к. не знаю основ (D)VCS.»
Далее, элементарные вопросы, на которые отвечают «дайте мне гугл, я найду за минуту». Иногда некоторые базовые вещи надо просто знать. Например, иметь хотя бы представление о типах данных и их размерностях. «Я тут умножаю миллион на миллион и сохраняю в int, что может пойти не так?» Для некоторых отраслей элементарные вопросы могут быть достаточно сложными, но обязательными для работы. Например, если идет речь о разработке сетевых приложений, надо обязательно знать sniffer-ы и OSI.
Далее, термины. Многие упускают такой момент, что в команде желательно говорить на одном языке. Опять-таки это можно нагуглить, но по своему опыту я знаю, что зачастую гугл не особо помогает. Например, один из моих тестеров даже после гугления термина CSRF и долгого муторного объяснения от меня, так и не понял, как сама атака работает. Такая же ситуация повторилась и с некоторыми нашими разработчиками. Зачастую программисты не могут понять позицию пользователя (или хакера, как в моем случае), потому что они не имеют достаточной гибкости мышления («не хочу я думать как хакер, я тут вызвал escape(), все должно теперь работать путем»).
Небольшое отступление. Иногда можно не знать сам термин, но использовать его на практике. Например, программист знает, что надо скрывать внутреннее состояние объекта от внешнего мира, и всегда делает это правильно, но не знает что это называется инкапсуляция. Хорошие интервьюверы обычно это выясняют. Особенно это важно в многонациональных компаниях, когда языковой барьер не позволяет кандидату сказать как термин называет по-английски.
И последнее. Многие жалуются что на интервью их спрашивают слишком сложные вопросы, ответы на которые знают только единицы. Обычно мы это делаем специально, чтобы выяснить пределы знаний и навыков кандидата. Никто не ожидает, что вы ответите на эти вопросы, но если ответите, то это будет большой плюс. Так что не надо воспринимать это как издевательство — это стандартная практика, как минимум, на западе.
Если судить по интервью, которые я провожу у студентов, обучающихся в Ванкувере, самое лучшее IT-образование дает BCIT. Студенты из UBC в основном показывают достаточно средние результаты, SFU еще хуже. Однако, конечно, все зависит от людей — многие и без университетов становятся блестящими специалистами. Если я еще буду в Ванкувере через несколько лет, можете обратиться ко мне, если будете искать работу. Ну или просто пишите, если нужна какая помощь в Ванкувере :)
Growl не поддерживает HTML, и причем весь передаваемый текст (как минимум через growlnotify) эскейпит. Заниматься обратным преобразованием, валидировать полученный HTML (который наверняка бы начал ломать всплываемое сообщение) и т.п. мне было не охота — проще сделать поддержку BBCode.
Я считаю что для изучения языка (а не просто выражений) надо выводить немного больше информации, чем просто строчку «оригинал — перевод», например, добавлять контекст. Мне понравился список идиом на сайте Native English, сейчас связался с владельцами сайта на тему условий использования их материала.
Как только получу разрешение и экспортирую данные, выложу отдельную статью. Пример, как это будет работать (придется использовать собственный стиль для Growl):
— подготовка к техническому интервью. Даже если кандидат все скопирует с Интернета, у него будет время разобраться с решениями и подтянуть недостающие знания.
— оценка честности кандидата. Если кандидат гуглил, но потом не может объяснить как это работает, и не признается в гуглении, это практически сразу крест на нем. Должен признать, что 80% признается, оставшиеся 20% конечно же отбрасываются.
— часть вопросов кандидаты стараются все-таки решить сами, и можно сразу видеть квалификацию еще до интервью. Например, в одном из заданий дается возможность использовать любую библиотеку JS, либо не использовать вообще никаких библиотек. Сделанный выбор позволяет составить какое-то мнение о соответствующих навыках.
1. Нужны именно С+Python+Web. Это специфика разработки под встраиваемые системы. Хотя мы и пытаемся все делать на питоне, но с некоторым API (мониторинг, диагностика, специфическое конфигурирования, включая системные запросы к драйверам) приходится взаимодействовать напрямую в Си. Немного помогает Cython, но все равно нужно знать Си.
2. Системы управления проектами — это хорошо и замечательно. Но когда вам звонят из офиса Майкрософт, и говорят, чтобы починили «прям счас», у многих возникает паника, и все идет мимо кассы. Я совершенно не согласен с такой позицией (прогибаться под Майкрософт, госструктуры и т.п.), но в компании именно такая политика. Хотя думаю, это оправдано с позиции бизнеса — «клиент всегда прав».
3. Вообще-то мне ваше удивление немного непонятно. Неужели вы думаете, что в компаниях, которые у всех на слуху, текут молочные реки и все кружат хороводы в дружном единении? Везде есть свои «племянники», «друзья», ленивые работники и некомпетентные менеджеры. Поэтому сейчас и популярна культура стартапов, потому что позволяет этого избежать. Но великая тройка (Google, Apple, MS) скупает эти стартапы с бешеной силой, и формирует огромные патентные пакеты, давящие другие стартапы, и если честно, я немного опасаюсь, чем это все закончится.
P.S. Лично я тоже считаю, что никакого стресса возникать не должно, и все должны знать что у malloc-а двойное поведение в зависимости от размера выделяемого объекта. Однако я не навязываю свою точку зрения.
Да, я понимаю, что это немного дико для программистов, которые считаются несколько замкнутыми в себе людьми, но это очень неплохо работает, и такие навыки сильно увеличивают шансы на успехи в жизни :)
P.S. В России ситуация все-таки с этим похуже, потому что открытость считается чем-то плохим и подозрительным, но с адекватными людьми тоже работает.
Я понимаю, что есть исключения, но мой опыт показывает, что индивидуалисты склонны решать проблемы только своей головой, не консультируясь ни с менеджерами, ни с коллегами. Зачастую это приводит к тому, что их решение хоть и brilliant, но по сути своей ошибочно, потому что они не учли каких-то факторов или требований, которые не были озвучены в спецификации или багрепорте. Когда им указывают на ошибку, они начинают старую песню про то, что «этого не было в спецификации, так что это ваши проблемы». К сожалению, мир не идеален, и особенно в условиях жесткой конкуренции необходимо учитывать, что всего не учтешь. Естественно, есть инструменты, чтобы минимизировать риски — тот же процесс codereview, однако и он зачастую заканчивается перепалками и обвинениями в некомпентности, только уже в онлайне.
Насчет int-а. Ваш ответ весьма замечателен, многие даже не задумываются про нюансы. Но в целом, я имел в виду баг на переполнение, которые некоторые «специалисты» делают, т.к. не особо осведомлены про разрядность. Например, у них все работает на x86-64 платформе, а потом оказывается, что ARM-платформа «почему-то» не работает (и конечно же виноваты разработчики процессора, слишком много там багов, вон даже Торвальдс ругается).
Сначала в поддержку автора. Многие интервьюеверы ленивы и недалеки. Не в последнюю очередь это из-за того, что они бывшие программисты, которых подняли до менеджера, но при этом они не имеют никаких социальных навыков для этого. Для них интервью — это просто трата времени, поэтому они быстро гуглят одни и те же вопросы, и повысив свое ЧСВ за счет унижения кандидата, они довольные собой, дают отказ. Причем отказ этот зачастую имеет эмоциональную природу («он — тупой, не знает алгоритма вычисления пи, а я такой умный и все знаю», либо «он — слишком умный и подсидит меня на моем теплом местечке»). Но не все такие.
Про резюме. Я никогда не доверяю резюме. Большой опыт ни о чем не говорит — это может быть большой опыт написания миллиона строк там, где использование библиотек или даже хорошего знания инструментария позволило бы сократить этот код до нескольких сотен строк. Или например, «LLVM contributor», что в реальности может быть — «LLVM вываливался на мой говнокод, пришлось связываться с разработчиками, и через месяц я еле как разобрался с gdb и смог-таки найти ошибочную строку. Потом еще целый месяц делал патч, т.к. не знаю основ (D)VCS.»
Далее, элементарные вопросы, на которые отвечают «дайте мне гугл, я найду за минуту». Иногда некоторые базовые вещи надо просто знать. Например, иметь хотя бы представление о типах данных и их размерностях. «Я тут умножаю миллион на миллион и сохраняю в int, что может пойти не так?» Для некоторых отраслей элементарные вопросы могут быть достаточно сложными, но обязательными для работы. Например, если идет речь о разработке сетевых приложений, надо обязательно знать sniffer-ы и OSI.
Далее, термины. Многие упускают такой момент, что в команде желательно говорить на одном языке. Опять-таки это можно нагуглить, но по своему опыту я знаю, что зачастую гугл не особо помогает. Например, один из моих тестеров даже после гугления термина CSRF и долгого муторного объяснения от меня, так и не понял, как сама атака работает. Такая же ситуация повторилась и с некоторыми нашими разработчиками. Зачастую программисты не могут понять позицию пользователя (или хакера, как в моем случае), потому что они не имеют достаточной гибкости мышления («не хочу я думать как хакер, я тут вызвал escape(), все должно теперь работать путем»).
Небольшое отступление. Иногда можно не знать сам термин, но использовать его на практике. Например, программист знает, что надо скрывать внутреннее состояние объекта от внешнего мира, и всегда делает это правильно, но не знает что это называется инкапсуляция. Хорошие интервьюверы обычно это выясняют. Особенно это важно в многонациональных компаниях, когда языковой барьер не позволяет кандидату сказать как термин называет по-английски.
И последнее. Многие жалуются что на интервью их спрашивают слишком сложные вопросы, ответы на которые знают только единицы. Обычно мы это делаем специально, чтобы выяснить пределы знаний и навыков кандидата. Никто не ожидает, что вы ответите на эти вопросы, но если ответите, то это будет большой плюс. Так что не надо воспринимать это как издевательство — это стандартная практика, как минимум, на западе.
Как только получу разрешение и экспортирую данные, выложу отдельную статью. Пример, как это будет работать (придется использовать собственный стиль для Growl):