Речь идет не о том, чтобы рассказать свою историю. Речь идет о том, что видно из резюме. Когда ко мне попадает резюме - неважно, от HR, из сети или откуда еще - я всегда смотрю, что я могу понять из него о человеке (и конкретно смотрю именно на историю работ за последние лет 10). И, например, если я вижу как человек продвигается от Software Engineer к Senior Software Engineer, и дальше к тимлиду - у меня складывается определенный образ, я примерно понимаю, что это за человек. А непонятные перерывы в истории работ вызывают вопросы - а чем таким человек занимался эти два года, что он не хочет про это рассказывать?
И при этом просмотре я, конечно же, увижу если кандидат зачем-то указал курсы как опыт работы. И будет у меня всего три варианта объяснить это: или кандидат не понимает, чем отличается учеба от работы, или по невнимательности вписал куда не надо, или зачем-то хитрит. Все три варианта так себе. Пользы хето уж точно не принесет (да и хороший HR это увидит тоже, и, возможно, просто не пришлет мне это резюме).
С моей точки зрения, предлагаемый перевод искажает смысл, имеющийся в исходном тексте. Статья, о которой идет речь, обсуждает документацию именно что решений - то есть да, выбора, но выбора в широком смысле, не только компонентов и принципов, но и действий, стратегии, методологии и т.п. Слово "решение" прекрасно передает именно это значение; зачем его заменять - решительно непонятно. Ваш вариант создает впечатление, что речь идет о процессе в начале разработки проекта, когда делается выбор. В статье же говорится о более универсальном процессе, который - как это говорится в статье - может происходить на протяжении всей жизни проекта.
Позволю себе не согласиться с некоторыми советами.
Про "указывайте только релевантный опыт". Здесь есть важный нюанс - если это не приводит к перерывам в стаже. Если так получилось, что вы два года поработали маркетологом, лучше указать это, чем иметь на резюме непонятный перерыв в работе. Кроме того, что значит "нерелевантный"? Если вы, например, три года занимались развитием и построением своего бизнеса, то это вполне стоит указать, даже если бизнес напрямую не связан с позицией, на которую вы подаете. Самый главный принцип: резюме должно рассказать связную, понятную и привлекательную историю о вас.
Указывать курсы как опыт работы не стоит - это будет выглядеть как ненужная попытка схитрить, а это всегда создает негативное ощущение. Врать на резюме нельзя (но приукрашивать, конечно, можно :) )
Думаю, что задавать HR вопросы о технологиях и деплое не имеет особого смысла; они не тем занимаются, и квалифицированно не ответят. Спрашивать про это нужно у инженеров, у тех лида.
"Записывайте теоретические вопросы и гуглите. Примерно через пять собеседований уже будете знать основную теорию." -совет записывать вопросы и потом разбирать их - очень хороший. Только лучше "основную теорию" все же изучить до интервью, и более организованно :)
Сильные кандидаты могут просто-напросто не согласиться на испытательный срок. Onboarding , кстати, тоже да-а-алеко не бесплатный процесс. Так что лучше потратить немного больше времени и усилий на собеседовании.
По первому пункту, я ушел от абстрактных стори поинтов, и перешел на вульгарные, банальные человеко-дни (ну то есть сказал, что у нас поинт - это примерно то, что можно сделать за один день работы). Планировать оказалось намного проще - у нас спринты 2 недели, и мы установили примерную скорость в 8 поинтов за спринт (с учетом всяких митингов и прочего). Стало очень легко учитывать праздники, всякую дополнительную деятельность и т.п. Не то, чтобы "Ниуспе..." совсем исчезло, но ушло на уровень минимального шума.
Что касается срочных добавлений в спринт, если они совсем-совсем необходимы и их не дают положить в следующий спринт, я привлекаю к обсуждению Product Manager'а, и пусть он решает, что именно мы выкинем из спринта (поскольку добавлять без выкидывания чего-то другого я не позволяю никогда).
Для создания модели знания о нормальных формах не нужны. Для грамотного дизайна схемы базы данных необходимо понимание того, что такое нормализация, а также когда и почему от нее нужно отказаться.
Есть такой тезис: Сложность должна быть адекватна проекту. Причем адекватна с разных сторон и на разном уровне. Методика, пригодная для создания онлайн-магазина, не подойдет для, скажем, банковской системы - и наоборот. Это, как мне кажется, понимают (практически) все. Проблема в том, что каждый, кто хоть сколько-то проработал в индустрии, наверняка сталкивался с проектами, которые переросли свою исходную базу. Оно по-всякому бывает - неожиданный успех продукта, прототип, засунутый в рабочую систему, накопившийся техдолг - сценариев много, а результат один, весьма болезненный. И всякий, кто с таким сталкивался, хочет этого в дальнейшем избежать. А, поскольку не знают, где именно упадут, то соломку стелят повсюду.
Почему подозрительно? Тут как раз всё нормально: мы говорим HR, что, скажем, ищем на мид левел человека с опытом разработки 5-7 лет, и 2-3 года опыт на Питоне. Ну вот пусть они и проверяют резюме. И если они отсеют техлидов с опытом 20 лет или тех, у кого полтора месяца Питона, то это будет только хорошо.
Тут вот какое дело. Поиск и обучение нового кандидата обходятся очень недешево. Поэтому хочется, когда берешь человека на работу, быть уверенным (ну, насколько возможно) что он не уйдет через полгода. Отсюда и вопросы - почему человек хочет поменять работу? При этом "хочу больше денег" в принципе нормальный ответ, особенно если человек получает меньше средней рыночной ставки. "Закончился контракт", "Ищу карьерного роста", "Хочу новых технологий" - все это валидные причины, я понимаю, чего хочет кандидат и я могу оценить, смогу я это ему предложить или нет. А вот если я не получаю внятного ответа, то у меня появляются опасения, что человек проработает у меня неизвестно какое время, и по столь же неясной причине уйдет.
И с оверквалифицированностью та же история. Ну хорошо если я могу твердо обещать, что через месяц-два переведу человека на позицию, соответствующую его уровню. Но такое, если и случается, то крайне редко. А в ином случае человек уйдет, как только найдет что-то по своему уровню, и придется мне начинать поиск сначала.
Был такой старый анекдот про хозяина, у которого было два работника, Вася и Петя. Вот как-то Вася спрашивает у хозяина:
-- Хозяин, почему Петя получает в три раза больше, чем я? Мы пришли к вам в один день, одного возраста, почему такая разница?
-- Видишь ли... - говорит хозяин, - как тебе объяснить... О, видишь - воз мимо нас по улице едет? Узнай, что везут?
-- Момент, - говорит Вася, убегает, через минуту возвращается. - Пшеницу везут.
-- Интересно, - говорит хозяин, - а куда везут?
-- Ща... - говорит Вася, убегает, прибегает, запыхавшись. - На базар везут.
-- О, - говорит хозяин, - а зачем везут? Вася убегает, возвращается, еле дыша.
-- Продавать везут...
Тут в комнату входит Петя.
-- Хозяин, - говорит Петя, - тут мимо нас провезли пшеницу из Никольского на рынок продавать. Собирались торговать по пять за мешок, я предложил взять все оптом по три, они согласились, развернулись, сейчас у нас разгружаться будут.
-- Ну вот, - говорит хозяин Васе, - еще вопросы есть?
Исследователь из Беркли, ультра-либерального университета, просто не мог прийти к каким-либо другим результатам, кроме "богатые - плохие". Не уверен, что его работы заслуживают хоть какого-то доверия.
Про Европу не скажу; но в США - ну совсем не так. За все время, что я тут, никаких двойных/тройных оплат я в глаза не видел. Народ как правило сидит столько, сколько нужно, и это очень зависит от компании и индустрии. В некоторых принято пересиживать; например, когда я работал в инвестиционном банке, рабочий день начинался в 8:30 (и к этому времени половина народу уже давно была на месте), а в 6:30, когда я уходил, очень многие еще продолжали плотно сидеть. Авралы в компаниях, занимающихся разработкой игр - вообще притча во языцех. В других областях спокойнее, но если нужно - задерживаются или подсоединяются из дома и работают сколько надо.
Я в США живу и работаю больше 25 лет. И сам увольнял, и попадал под сокращения - всякое бывало. Так вот, бывало так, что сообщали очень заранее: типа, ты работаешь у нас последний месяц, извини (это в маленьких компаниях). Но в больших компаниях обычно так: или происходит общее собрание, на которое приглашают только уволенных (если большое сокращение идет), или просто увольняемого вызывает для разговора руководитель, а во время разговора, пока сообщают про увольнение, IT блокирует весь доступ. Потом уволенного сопровождают до рабочего места, чтбы он собрался, и провожают из здания.
Хорошее сопроводительное письмо может хорошо дополнить резюме, объяснить то, что из резюме может быть не сразу понятно, подчеркнуть неочевидные сильные стороны.
Я сейчас использую OneNote. Синхронизирую между PC, Маком и телефоном на Андроиде. И да, я понимаю, что сделав пару кувырков можно настроить синхронизацию Обсидиана на каждой платформе... Но хочется всё же, чтобы оно уже работало.
Речь идет не о том, чтобы рассказать свою историю. Речь идет о том, что видно из резюме. Когда ко мне попадает резюме - неважно, от HR, из сети или откуда еще - я всегда смотрю, что я могу понять из него о человеке (и конкретно смотрю именно на историю работ за последние лет 10). И, например, если я вижу как человек продвигается от Software Engineer к Senior Software Engineer, и дальше к тимлиду - у меня складывается определенный образ, я примерно понимаю, что это за человек. А непонятные перерывы в истории работ вызывают вопросы - а чем таким человек занимался эти два года, что он не хочет про это рассказывать?
И при этом просмотре я, конечно же, увижу если кандидат зачем-то указал курсы как опыт работы. И будет у меня всего три варианта объяснить это: или кандидат не понимает, чем отличается учеба от работы, или по невнимательности вписал куда не надо, или зачем-то хитрит. Все три варианта так себе. Пользы хето уж точно не принесет (да и хороший HR это увидит тоже, и, возможно, просто не пришлет мне это резюме).
Интересно бы узнать, как ситуация выглядела с точки зрения того самого тимлида...
С моей точки зрения, предлагаемый перевод искажает смысл, имеющийся в исходном тексте. Статья, о которой идет речь, обсуждает документацию именно что решений - то есть да, выбора, но выбора в широком смысле, не только компонентов и принципов, но и действий, стратегии, методологии и т.п. Слово "решение" прекрасно передает именно это значение; зачем его заменять - решительно непонятно. Ваш вариант создает впечатление, что речь идет о процессе в начале разработки проекта, когда делается выбор. В статье же говорится о более универсальном процессе, который - как это говорится в статье - может происходить на протяжении всей жизни проекта.
Позволю себе не согласиться с некоторыми советами.
Про "указывайте только релевантный опыт". Здесь есть важный нюанс - если это не приводит к перерывам в стаже. Если так получилось, что вы два года поработали маркетологом, лучше указать это, чем иметь на резюме непонятный перерыв в работе. Кроме того, что значит "нерелевантный"? Если вы, например, три года занимались развитием и построением своего бизнеса, то это вполне стоит указать, даже если бизнес напрямую не связан с позицией, на которую вы подаете. Самый главный принцип: резюме должно рассказать связную, понятную и привлекательную историю о вас.
Указывать курсы как опыт работы не стоит - это будет выглядеть как ненужная попытка схитрить, а это всегда создает негативное ощущение. Врать на резюме нельзя (но приукрашивать, конечно, можно :) )
Думаю, что задавать HR вопросы о технологиях и деплое не имеет особого смысла; они не тем занимаются, и квалифицированно не ответят. Спрашивать про это нужно у инженеров, у тех лида.
"Записывайте теоретические вопросы и гуглите. Примерно через пять собеседований уже будете знать основную теорию." -совет записывать вопросы и потом разбирать их - очень хороший. Только лучше "основную теорию" все же изучить до интервью, и более организованно :)
Сильные кандидаты могут просто-напросто не согласиться на испытательный срок. Onboarding , кстати, тоже да-а-алеко не бесплатный процесс. Так что лучше потратить немного больше времени и усилий на собеседовании.
По первому пункту, я ушел от абстрактных стори поинтов, и перешел на вульгарные, банальные человеко-дни (ну то есть сказал, что у нас поинт - это примерно то, что можно сделать за один день работы). Планировать оказалось намного проще - у нас спринты 2 недели, и мы установили примерную скорость в 8 поинтов за спринт (с учетом всяких митингов и прочего). Стало очень легко учитывать праздники, всякую дополнительную деятельность и т.п. Не то, чтобы "Ниуспе..." совсем исчезло, но ушло на уровень минимального шума.
Что касается срочных добавлений в спринт, если они совсем-совсем необходимы и их не дают положить в следующий спринт, я привлекаю к обсуждению Product Manager'а, и пусть он решает, что именно мы выкинем из спринта (поскольку добавлять без выкидывания чего-то другого я не позволяю никогда).
Для создания модели знания о нормальных формах не нужны. Для грамотного дизайна схемы базы данных необходимо понимание того, что такое нормализация, а также когда и почему от нее нужно отказаться.
Насколько я понимаю, это перевод вот этой статьи, да?
https://voussoir.net/writing/css_for_printing
Есть такой тезис: Сложность должна быть адекватна проекту. Причем адекватна с разных сторон и на разном уровне. Методика, пригодная для создания онлайн-магазина, не подойдет для, скажем, банковской системы - и наоборот. Это, как мне кажется, понимают (практически) все. Проблема в том, что каждый, кто хоть сколько-то проработал в индустрии, наверняка сталкивался с проектами, которые переросли свою исходную базу. Оно по-всякому бывает - неожиданный успех продукта, прототип, засунутый в рабочую систему, накопившийся техдолг - сценариев много, а результат один, весьма болезненный. И всякий, кто с таким сталкивался, хочет этого в дальнейшем избежать. А, поскольку не знают, где именно упадут, то соломку стелят повсюду.
Не очень понимаю, зачем этот текст? Те, кто поймут, о чем идет речь, и так знает этот жаргон. Остальным от написанного понятнее не станет.
Почему подозрительно? Тут как раз всё нормально: мы говорим HR, что, скажем, ищем на мид левел человека с опытом разработки 5-7 лет, и 2-3 года опыт на Питоне. Ну вот пусть они и проверяют резюме. И если они отсеют техлидов с опытом 20 лет или тех, у кого полтора месяца Питона, то это будет только хорошо.
Нужно, чтобы была возможность через полгода дать ему лучшие условия. В мелких стартапах такое возможно, в более крупных компаниях - ну очень сложно.
Тут вот какое дело. Поиск и обучение нового кандидата обходятся очень недешево. Поэтому хочется, когда берешь человека на работу, быть уверенным (ну, насколько возможно) что он не уйдет через полгода. Отсюда и вопросы - почему человек хочет поменять работу? При этом "хочу больше денег" в принципе нормальный ответ, особенно если человек получает меньше средней рыночной ставки. "Закончился контракт", "Ищу карьерного роста", "Хочу новых технологий" - все это валидные причины, я понимаю, чего хочет кандидат и я могу оценить, смогу я это ему предложить или нет. А вот если я не получаю внятного ответа, то у меня появляются опасения, что человек проработает у меня неизвестно какое время, и по столь же неясной причине уйдет.
И с оверквалифицированностью та же история. Ну хорошо если я могу твердо обещать, что через месяц-два переведу человека на позицию, соответствующую его уровню. Но такое, если и случается, то крайне редко. А в ином случае человек уйдет, как только найдет что-то по своему уровню, и придется мне начинать поиск сначала.
Эххх...
Был такой старый анекдот про хозяина, у которого было два работника, Вася и Петя. Вот как-то Вася спрашивает у хозяина:
-- Хозяин, почему Петя получает в три раза больше, чем я? Мы пришли к вам в один день, одного возраста, почему такая разница?
-- Видишь ли... - говорит хозяин, - как тебе объяснить... О, видишь - воз мимо нас по улице едет? Узнай, что везут?
-- Момент, - говорит Вася, убегает, через минуту возвращается. - Пшеницу везут.
-- Интересно, - говорит хозяин, - а куда везут?
-- Ща... - говорит Вася, убегает, прибегает, запыхавшись. - На базар везут.
-- О, - говорит хозяин, - а зачем везут? Вася убегает, возвращается, еле дыша.
-- Продавать везут...
Тут в комнату входит Петя.
-- Хозяин, - говорит Петя, - тут мимо нас провезли пшеницу из Никольского на рынок продавать. Собирались торговать по пять за мешок, я предложил взять все оптом по три, они согласились, развернулись, сейчас у нас разгружаться будут.
-- Ну вот, - говорит хозяин Васе, - еще вопросы есть?
Исследователь из Беркли, ультра-либерального университета, просто не мог прийти к каким-либо другим результатам, кроме "богатые - плохие". Не уверен, что его работы заслуживают хоть какого-то доверия.
Про Европу не скажу; но в США - ну совсем не так. За все время, что я тут, никаких двойных/тройных оплат я в глаза не видел. Народ как правило сидит столько, сколько нужно, и это очень зависит от компании и индустрии. В некоторых принято пересиживать; например, когда я работал в инвестиционном банке, рабочий день начинался в 8:30 (и к этому времени половина народу уже давно была на месте), а в 6:30, когда я уходил, очень многие еще продолжали плотно сидеть. Авралы в компаниях, занимающихся разработкой игр - вообще притча во языцех. В других областях спокойнее, но если нужно - задерживаются или подсоединяются из дома и работают сколько надо.
Я в США живу и работаю больше 25 лет. И сам увольнял, и попадал под сокращения - всякое бывало. Так вот, бывало так, что сообщали очень заранее: типа, ты работаешь у нас последний месяц, извини (это в маленьких компаниях). Но в больших компаниях обычно так: или происходит общее собрание, на которое приглашают только уволенных (если большое сокращение идет), или просто увольняемого вызывает для разговора руководитель, а во время разговора, пока сообщают про увольнение, IT блокирует весь доступ. Потом уволенного сопровождают до рабочего места, чтбы он собрался, и провожают из здания.
Хорошее сопроводительное письмо может хорошо дополнить резюме, объяснить то, что из резюме может быть не сразу понятно, подчеркнуть неочевидные сильные стороны.
Как писал в свое время Жванецкий, "Ты придумаешь, тебя же и заставят делать, тебя же и накажут за то, что плохо сделал".
Я сейчас использую OneNote. Синхронизирую между PC, Маком и телефоном на Андроиде. И да, я понимаю, что сделав пару кувырков можно настроить синхронизацию Обсидиана на каждой платформе... Но хочется всё же, чтобы оно уже работало.