Я не против fair play, но почему-то если ты честно скажешь работодателю, что намерен искать другую работу, то тебя либо начнут гнобить, либо сразу уволят (а ипотеку платить всё ещё нужно и семью кормить тоже). Не может тут быть fair play…
Это не предательство — это рынок. В законе прописано уведомить работодателя за 2-4 недели (в зависимости от страны). Если вы выполнили это, то всё честно. Конечно, если за 2 недели перед сдачей проекта ушли «в отпуск с последующим увольнением», то это некрасиво и так делать не нужно… А в остальных случаях — всё ОК…
Дело в том, что чаще всего фигачить алгоритмы не нужно. Для массивов есть Sort(). Для SQL есть ORDER BY. Умение избежать лишних циклов и выносить весь ненужный код за циклы — вот основа алгоритмов для программиста. Для SQL — умение читать планы запросов и знать как работают индексы. Пользуясь этими правилами можно избежать основных косяков, а дальше в дело вступает профайлер и в случае если код работает медленно — можно подумать как оптимизировать…
И кстати на западе Кобол до сих пор востребован (т.к. много успели написать на нём). Постоянно вижу 1-2 вакансии «Кобол для мейнфреймов», а специалисты по нему очень хорошо оплачиваемые именно потому что редкие, а новички туда идти не хотят…
Основы понимания сложности алгоритмов нужны, но они нужны уровня «лучше-хуже», «быстрее-медленнее», «можно-нельзя». Но никак не «линейная», «квадратическая», «логарифимическая» и т.д. Большим плюсом будет умение работать с профайлером, находить «горячие» функции и анализировать планы SQL запросов. К сожалению вопрос о сложности алгоритма при вставке в вектор в цикле не сможет помочь отличить хорошего кандидата от плохого…
О, обожаю эти вопросы про «какова сложность алгоритма»…
К реальной работе имеет отношение чуть больше чем никак. Т.е. кандидат должен знать что вариант А будет работать быстрее варианта Б (и желательно почему), но вот знать что тут именно «линейная» сложность, а не «квадратическая» ему знать совсем не обязательно. Дело в том, что в реальных проектах не пишут своих сортировок массивов, а используют готовые решения и библиотеки, а значит скорее всего они используют один из самых быстрых алгоритмов (если конечно у вас не специфические данные). А позвольте спросить зачем вы добавляете миллионы записей в вектор?! В реальной жизни такого не будет и если я увижу такой код, то я попытаюсь оптимизировать его ещё до прихода в этот цикл.
Из моего опыта могу сказать следующее:
1. Наличие проектов на GitHub — в б.СССР не сталкивался с работодателями, которым было это интересно (ну то есть наличие — это плюс, но отсутствие — это не минус). В западных странах «покажите примеры вашего кода» — это практически 2ой вопрос при найме, так что тут наличие GitHub-а — только плюс
2. Привязка к конкретному фреймворку — тут всё зависит от системы подбора кадров. Если резюме изучает технический специалист или если технология не очень популярная/не очень много кандидатов, то шансы попасть на интервью очень велики, но если кандидатов много, а резюме фильтруют HRы или даже автоматическая система по ключевым словам, то наличие данного пункта в резюме очень важно. (даже если будет в виде строчки: сейчас я изучаю Angular.JS)
3. Технические навыки важны, но ещё важнее умение продать себя и при этом не переусердствовать. Никто не ждёт от вас идеального краснорения, но если вы сможете создать комфортную для общения атмосферу и покажете, что с вами приятно работать, то этого будет достаточно для положительного ответа
4. В б.СССР рекомендации почти никто не спрашивает, но в западных компаниях это почти обязательно, так что лучше если они у вас будут (и будут либо на английском, либо переведены)
5. У «монстров с тысячей звёзд на гитхабе» чаще всего уже есть работа и они не собираются её менять и за ними идёт охота рекрутеров. Так что в конкуренции на вакансию с сайта они не участвуют. Если вы сомневаетесь в своих навыках, но вам очень нужна работа, то чуть снизьте цену (чуть ниже среднего по рынку по вашей квалификации), и тогда даже при наличии более сильного кандидата, но с гораздо большими требованиями, возьмут именно вас…
6. Зарплата не бывает большой, бывают компании которые не готовы её платить. В идеале нужно промониторить рынок, узнать зарплаты у коллег и знакомых и то, что предлагают компании, соотнести их навыки к вашими и на основании этого установить планку. Если у вас есть работа и вы просто ищите лучшие возможности, то просите почти по максимальной планке (т.к. компании часто дают хорошие зарплаты новым сотрудникам, но очень плохо повышают их тем, кто работает у них годами). Если же вам очень нужна работа, то просите среднюю по рынку или даже чуть ниже.
7. При отсутствии ответа хорошо позвонить и уточнить получили ли они ваше резюме. Это может быть хорошим толчком для них вытащить ваше резюме из стопки и рассмотреть его. Но не будьте слишком навязчивы…
8. Если бы на рынке были сотни свободных талантов, то вакансии закрывались бы очень быстро, но это не так. У талантов либо уже есть работа, либо она им не нужна. Т.е. из сотни кандидатов может найтись только 1-2 сильных, поэтому ваша задача попасть в их число.
9. Отказ не значит, что вы плохой программист. Это значит что либо компания нашла кандидата, который лучше по соотношению цена/качество (и не факт, что он талантливее вас, может просто просил меньше). Так что проанализируйте возможные причины отказа и подавайтесь в следющую компанию с учётом выводов, которые вы сделали. А иногда бывает, что компания не доросла ещё до кандидата (к примеру если на должность сеньёра спрашивают не про архитектуру, дизайн и проблемные ситуации, а просят написать сортировку методом пузырька на листе бумаги)
10. Отличное резюме — это то, в котором компания видит то, что им нужно. Из этого следует, что резюме должно подбиваться под требования компании, чтобы в нём было как можно больше совпадений с их ожиданиями. В идеале оно должно быть хорошо структурировано и не длинее 2х страниц.
11. Никогда не делайте массовую рассылку однотипных резюме. Всегда подбивайте их под требования компании и упоминайте её в резюме. Связи тоже очень важны, но лучше если это будет не толпа рекрутеров в LinkedIn, а разработчики с других контор.
Цифры не из статистики, а из собственного опыта и наблюдений за коллегами (4 компании, больше 10 проектов, 10 лет) — так что на абсолютную истину не претендую.
Про «виноваты менеджеры» — они виноваты не во всём. Есть 2 беды менеджемента — ошибки в планировании и жадность (вернее экономия на мелочах ведущая к потере чего то важного).
Недостатки планирования чаще всего выглядят в излишней самоуверенности менеджера (без понимания технических деталей) и желания выслужиться перед вышестоящим руководством. Отсюда появляется необходимость «стрессоустойчивых» сотрудников. Т.е. когда менеджер не советуясь с командой обещает руководству о сроках, а потом давит на свою команду чтобы это обещание сдержать. Если бы такой менеджер изначально пришёл к команде, попросил оценить задачу и обосновать оценку, добавил 20-30% времени на риски и потом уже подтвердил руководству сроки, то все были бы счастливы: руководство получило бы реальные сроки, которые не пришлось бы переносить, работники получили бы возможность работать без стресса, а менеджер — возможность показать с себя с лучшей стороны, т.к. все риски скорее всего не выстрелят и задачу закончат раньше.
Вторая проблема жадность. Пример из моего предыдущего опыта: в одной из команд менеджеры решили отказаться от тестировщиков и вместо них ввели тестирование разработчиками. На первый взгляд это сэкономило немало денег (можно показать красивые графики руководству и выслужиться), но в результате получилось что разработчики делают не свою работу (а значит делают её менее качественно), сроки релизов сильно просели из-за невозможности тестировать и разрабатывать одновременно, а стоимость тестирования возрасла т.к. его делают «дорогие» разработчики, а не «относительно дешёвые» тестировщики.
В работе разработчика — 60-70% — это умение читать, понимать чужой код и оптимизировать его (если это конечно не старт проекта с нуля). А из оставшихся 30% — половина — это умение чужой код переиспользовать и модифицировать. И только оставшиеся 15% — это те нестандартные задачи, где нужно много думать и делать что-то уникальное.
Про компетенцию в написании кода можно судить по тому, как кандидат предложит оптимизировать представленный фрагмент кода, а также при ответе на вопрос «как вы реализуете задачу» — конечно вы не увидите тут стандартов оформления или SOLID принципов (хотя и несоблюдение стандартов и нарушение SOLID может быть специально сделанными ошибками в показанном фрагменте и задача кандидата указать их).
Стрессоустойчивость — это хорошо, но когда это переходит в «создавать себе проблемы и потом героически их решать», то это признак плохого работодателя. Наличие стресса в работе сотрудников — это на 80% недостатки планирования или ресурсов (тут нужно менеджеров менять, а не искать стрессоустойчивых сотрудников).
Как разработчик, я согласен работать со стрессами в формате «давайте поднажмём чтобы выпустить релиз вовремя» или «у клента критическая ошибка — нужно срочно исправить», но если это «а напишите код на бумажке потому что я так хочу» или «что значит не сможете сделать за 3 дня! Я уже клиентам пообещал», то такой работы я не хочу… И да, за последние 8 лет я проработал в 3х солидных компаниях в разных частях мира и у меня были только стрессы первой категории (т.е. обычная рабочая рутина и авраалы, а не закидоны руководства и самодурство).
А не лучше ли потратить 30 минут тем, кто проводит техническое интервью и подобрать пару примеров кода, чтобы попросить кандидата рассказать что этот код делает, попросить найти ошибки и оптимизировать… Если ещё минут 15 потратить на вопросы вроде «нарисуйте блок-схему/алгоритм решения задачи» или «расскажите как бы вы решили эту задачу», то до испытательного срока дойдут как минимум неплохие программисты.
Нет, написать код для программиста не стресс, но для этого должны быть созданы условия: удобное рабочее место, компьютер с IDE настроенные под данного человека, доступ в Интернет для быстрого разрешения затыков. Написание на скорость кода «на салфетке» без подсветки синтаксиса, возможности скомпилировать и проверить как это работает — это стресс (к тому же это же часть интервью, а значит кандидат и так находится в состоянии стресса, так как хочет показать себя с лучшей стороны и получить эту работу)…
К примеру, я считаю себя неплохим разработчиком (10 лет опыта и участие в олимпиадах и хакатонах), но мне писать код на салфетке некомфортно и скорее всего написанное тупо не скомпилируется…
Нет, если в вашей компании до сих пор используют перфокарты, а потом стоят в очереди, чтобы скомпилировать и проверить, то написание кода на салфетке — хорошая идея… Если же вы современная компания, то не издевайтесь над людьми…
Мне кажется что это неправильно судить за покупку/сбыт/хранение таких устройств. Тут нет преступления. Вот за незаконное применение можно и осудить. Т.е. если ты продал/купил/хранишь GPS трекер или привязал его к своему коптеру/корове/авто, то тут всё нормально. А вот если ты использовал его для слежки за кем либо либо для сбора данных — тут уже преступление на лицо. К тому же список устройств устарел лет на 20.
Ну понятно, что в правилах этого нет — юристы же наверно составляли. От этого мошеничества меньше не становится… В моментальных лотереях, где ты должен стереть, к примеру, 3 поля из 9, после проигрыша ты мог стереть оставшиеся и посмотреть где была выигрышная комбинация. А в данном случае во-первых нет разницы куда кликнуть — всё равно покажется тот же результат, и к тому же в конце игры не показывается поле с выигрышной комбинацией (потому что его не существует).
Нагрузка на сервер копеечная… Сгенерировать картинки-то можно, но если передать все картинки на клиент, то клиент можно взломать, если передать заранее последовательность (как в статье), то от действий игрока ничего не зависит, а значит это мошенничество…
Можно было бы сделать эту лотерею честной.
На сервере генерируется поле (на клиент не передаётся, а передаётся только ID игры).
Далее юзер кликает на карточке и на сервер идут координаты ячейки — в ответ возвращается картинка для данной ячейки поля.
В случае проигрыша/выигрыша все карточки открываются, что демонстрирует наличие выигрышного варианта на поле.
Даёте пару примеров кода и просите рассказать что он делает, найти ошибки и рассказать как можно улучшить/оптимизировать… Эти 5-10 минут разговора отлично отсекают болтунов и в то же время не создают стресс для кандидата, как, например написание кода на салфетке/доске…
Ваше сообщение бы распечатать и под стекло на стол в HR отделы ИТ компаний (да и не только ИТ). Так и должно быть, когда спрашивают то, с чем реально работают, изучают предыдущий опыт и оценивают, насколько он будет полезен для компании…
Это много! Представьте что кандидат работает и хочет сменить работу (а у большинства хороших кандидатов именно так), он разослал резюме в 3-4 конторы и каждая из них проводит такие издевательские собеседования… 4*6 = 24 часа + подготовка, время на дорогу и т.д. получается что минимум 1 рабочая неделя уходит… (а ведь всё это происходит в рабочее время, а значит кандидат либо должен использовать отпуск, либо ещё как-то выкручиваться). Я уже писал выше, что если вы не можете понять за 2 часа подходит вам человек или нет, то значит вы не то спрашиваете или не на то смотрите… К тому же внимательное изучение резюме и профиля в LinkedIn поможет избежать ненужных вопросов, а разговор о предыдущих проектах покажет реальный опыт кандидата. Ещё одна важная вещь: спрашивайте то, что вы реально используете в своей работе. Если, к примеру, вы пишите API, то спрашивайте по API, а не про то как реализовать сортировку пузырьком в двухсвязанном списке…
А сколько интерьвю в результате проходит кандидат и сколько времени это занимает в новом процессе?
Если больше 1-2 интервью и 3 часов, то вы ничего не изменили в итоге… Если за 2 часа вы не можете понять подходит вам человек или нет, то вам нужно менять HR и тех, кто проводит техническое интервью. Как вариант вводить систему оценок с проходным баллом и возможностью интервьюверов давать дополнительные баллы за общее положительное или отрицательное впечатление, которое кандидат произвёл.
К реальной работе имеет отношение чуть больше чем никак. Т.е. кандидат должен знать что вариант А будет работать быстрее варианта Б (и желательно почему), но вот знать что тут именно «линейная» сложность, а не «квадратическая» ему знать совсем не обязательно. Дело в том, что в реальных проектах не пишут своих сортировок массивов, а используют готовые решения и библиотеки, а значит скорее всего они используют один из самых быстрых алгоритмов (если конечно у вас не специфические данные). А позвольте спросить зачем вы добавляете миллионы записей в вектор?! В реальной жизни такого не будет и если я увижу такой код, то я попытаюсь оптимизировать его ещё до прихода в этот цикл.
1. Наличие проектов на GitHub — в б.СССР не сталкивался с работодателями, которым было это интересно (ну то есть наличие — это плюс, но отсутствие — это не минус). В западных странах «покажите примеры вашего кода» — это практически 2ой вопрос при найме, так что тут наличие GitHub-а — только плюс
2. Привязка к конкретному фреймворку — тут всё зависит от системы подбора кадров. Если резюме изучает технический специалист или если технология не очень популярная/не очень много кандидатов, то шансы попасть на интервью очень велики, но если кандидатов много, а резюме фильтруют HRы или даже автоматическая система по ключевым словам, то наличие данного пункта в резюме очень важно. (даже если будет в виде строчки: сейчас я изучаю Angular.JS)
3. Технические навыки важны, но ещё важнее умение продать себя и при этом не переусердствовать. Никто не ждёт от вас идеального краснорения, но если вы сможете создать комфортную для общения атмосферу и покажете, что с вами приятно работать, то этого будет достаточно для положительного ответа
4. В б.СССР рекомендации почти никто не спрашивает, но в западных компаниях это почти обязательно, так что лучше если они у вас будут (и будут либо на английском, либо переведены)
5. У «монстров с тысячей звёзд на гитхабе» чаще всего уже есть работа и они не собираются её менять и за ними идёт охота рекрутеров. Так что в конкуренции на вакансию с сайта они не участвуют. Если вы сомневаетесь в своих навыках, но вам очень нужна работа, то чуть снизьте цену (чуть ниже среднего по рынку по вашей квалификации), и тогда даже при наличии более сильного кандидата, но с гораздо большими требованиями, возьмут именно вас…
6. Зарплата не бывает большой, бывают компании которые не готовы её платить. В идеале нужно промониторить рынок, узнать зарплаты у коллег и знакомых и то, что предлагают компании, соотнести их навыки к вашими и на основании этого установить планку. Если у вас есть работа и вы просто ищите лучшие возможности, то просите почти по максимальной планке (т.к. компании часто дают хорошие зарплаты новым сотрудникам, но очень плохо повышают их тем, кто работает у них годами). Если же вам очень нужна работа, то просите среднюю по рынку или даже чуть ниже.
7. При отсутствии ответа хорошо позвонить и уточнить получили ли они ваше резюме. Это может быть хорошим толчком для них вытащить ваше резюме из стопки и рассмотреть его. Но не будьте слишком навязчивы…
8. Если бы на рынке были сотни свободных талантов, то вакансии закрывались бы очень быстро, но это не так. У талантов либо уже есть работа, либо она им не нужна. Т.е. из сотни кандидатов может найтись только 1-2 сильных, поэтому ваша задача попасть в их число.
9. Отказ не значит, что вы плохой программист. Это значит что либо компания нашла кандидата, который лучше по соотношению цена/качество (и не факт, что он талантливее вас, может просто просил меньше). Так что проанализируйте возможные причины отказа и подавайтесь в следющую компанию с учётом выводов, которые вы сделали. А иногда бывает, что компания не доросла ещё до кандидата (к примеру если на должность сеньёра спрашивают не про архитектуру, дизайн и проблемные ситуации, а просят написать сортировку методом пузырька на листе бумаги)
10. Отличное резюме — это то, в котором компания видит то, что им нужно. Из этого следует, что резюме должно подбиваться под требования компании, чтобы в нём было как можно больше совпадений с их ожиданиями. В идеале оно должно быть хорошо структурировано и не длинее 2х страниц.
11. Никогда не делайте массовую рассылку однотипных резюме. Всегда подбивайте их под требования компании и упоминайте её в резюме. Связи тоже очень важны, но лучше если это будет не толпа рекрутеров в LinkedIn, а разработчики с других контор.
Про «виноваты менеджеры» — они виноваты не во всём. Есть 2 беды менеджемента — ошибки в планировании и жадность (вернее экономия на мелочах ведущая к потере чего то важного).
Недостатки планирования чаще всего выглядят в излишней самоуверенности менеджера (без понимания технических деталей) и желания выслужиться перед вышестоящим руководством. Отсюда появляется необходимость «стрессоустойчивых» сотрудников. Т.е. когда менеджер не советуясь с командой обещает руководству о сроках, а потом давит на свою команду чтобы это обещание сдержать. Если бы такой менеджер изначально пришёл к команде, попросил оценить задачу и обосновать оценку, добавил 20-30% времени на риски и потом уже подтвердил руководству сроки, то все были бы счастливы: руководство получило бы реальные сроки, которые не пришлось бы переносить, работники получили бы возможность работать без стресса, а менеджер — возможность показать с себя с лучшей стороны, т.к. все риски скорее всего не выстрелят и задачу закончат раньше.
Вторая проблема жадность. Пример из моего предыдущего опыта: в одной из команд менеджеры решили отказаться от тестировщиков и вместо них ввели тестирование разработчиками. На первый взгляд это сэкономило немало денег (можно показать красивые графики руководству и выслужиться), но в результате получилось что разработчики делают не свою работу (а значит делают её менее качественно), сроки релизов сильно просели из-за невозможности тестировать и разрабатывать одновременно, а стоимость тестирования возрасла т.к. его делают «дорогие» разработчики, а не «относительно дешёвые» тестировщики.
Про компетенцию в написании кода можно судить по тому, как кандидат предложит оптимизировать представленный фрагмент кода, а также при ответе на вопрос «как вы реализуете задачу» — конечно вы не увидите тут стандартов оформления или SOLID принципов (хотя и несоблюдение стандартов и нарушение SOLID может быть специально сделанными ошибками в показанном фрагменте и задача кандидата указать их).
Стрессоустойчивость — это хорошо, но когда это переходит в «создавать себе проблемы и потом героически их решать», то это признак плохого работодателя. Наличие стресса в работе сотрудников — это на 80% недостатки планирования или ресурсов (тут нужно менеджеров менять, а не искать стрессоустойчивых сотрудников).
Как разработчик, я согласен работать со стрессами в формате «давайте поднажмём чтобы выпустить релиз вовремя» или «у клента критическая ошибка — нужно срочно исправить», но если это «а напишите код на бумажке потому что я так хочу» или «что значит не сможете сделать за 3 дня! Я уже клиентам пообещал», то такой работы я не хочу… И да, за последние 8 лет я проработал в 3х солидных компаниях в разных частях мира и у меня были только стрессы первой категории (т.е. обычная рабочая рутина и авраалы, а не закидоны руководства и самодурство).
К примеру, я считаю себя неплохим разработчиком (10 лет опыта и участие в олимпиадах и хакатонах), но мне писать код на салфетке некомфортно и скорее всего написанное тупо не скомпилируется…
Нет, если в вашей компании до сих пор используют перфокарты, а потом стоят в очереди, чтобы скомпилировать и проверить, то написание кода на салфетке — хорошая идея… Если же вы современная компания, то не издевайтесь над людьми…
На сервере генерируется поле (на клиент не передаётся, а передаётся только ID игры).
Далее юзер кликает на карточке и на сервер идут координаты ячейки — в ответ возвращается картинка для данной ячейки поля.
В случае проигрыша/выигрыша все карточки открываются, что демонстрирует наличие выигрышного варианта на поле.
Если больше 1-2 интервью и 3 часов, то вы ничего не изменили в итоге… Если за 2 часа вы не можете понять подходит вам человек или нет, то вам нужно менять HR и тех, кто проводит техническое интервью. Как вариант вводить систему оценок с проходным баллом и возможностью интервьюверов давать дополнительные баллы за общее положительное или отрицательное впечатление, которое кандидат произвёл.