опыт работы в не связанных областях в одном резюме

Напиши что у тебя 5 звезд на лоре, остальное не важно...

Эх. Так вот почему я так и не смог найти работу в ЫТ.

Ну у меня в резюме на разработчика указан опыт работы в университете 4 года не по специальности. И что такого? По крайней мере, видно, что после универа человек был занят, а не сидел на жопе, пока его не посетила идея «пойти в it».

Товарищи с хх.ру не пропускают мое резюме для публикации по этой причине.

А какие у них аргументы, ежели не секрет?

Резюме - это как-бы цепочка того, чем ты занимался по жизни, не понимаю, что такого страшного в том, что раньше ты занимался кардинально другими вещами.

а что такого? я так выкатился из айти на пару лет(паяльником махал) и вкатился обратно

Товарищи с хх.ру не пропускают мое резюме для публикации по этой причине

1.По какой «по этой»? 2.Зачем тебе резюме на ХХ? Просто посмотри какие вакансии есть в городе и лично свяжись.

а не сидел на жопе, пока его не посетила идея «пойти в it».

А если сидел, то что такого? Мало-ли кто где сидел... Я бы понял если работодатель просит уточнить, чем ты занимался, кроме последних лет, но ХХ-то какое нахрен дело? Совсем они берега попутали кмк.

Разработчиком врятли возьмут без опыта работы, а вот управленцем вполне, особенно если с людьми работал.

Петросян с женой разводится

У них аргументы, что они так хотят , правила у них такие видите ли. Под начинающего я не канаю, не понятно почему.

Страшного ничего, но нафига ит компании мои навыки по оценке стоимости строительства, если им нужеы люди с навыками в ит? Я бы ,нанимая кого то в стройку , весьма настороженно глядел бы на чувака или чувиху, которые строили только будку для собаки дома, а так вообше то работают нянечкой в лет саду

Попутали, но они владельцы сервиса, к сожалению

Что значит «резюме на вакансию ИТ»? Есть резюме - документ, где перечислены: образование, история трудоустройства, знания и умения. И есть сопроводительное письмо, под конкретную вакансию. Или я чего-то не понимаю?

А вот хз. На мой взгляд, если в резюме будет 15 лет стройки и параллельно последние 4 года нечто из ИТ, я бы такого перца не взял в ИТ:-(

Лучше, когда у человека эти навыки есть, чем когда их нет. Не забиваю голову ерундой.

Товарищей шли подальше.

Бред. Опыт работы он и есть опыт работы, не важно какой. Умение решать задачи и принимать ответственность очень важно. Если ты знаешь 283849 языков и сорцы ядра наизусть, но не можешь запланировать и вовремя решить задачу - ты никому не нужен.

Бред

Ну вот, а меня терзают смутные сомнения, как правильно сделать и есть ли вообще в данном случае это самое «правильно»

а вот управленцем вполне, особенно если с людьми работал.

вот уж увольте, управлять мне настообрыдло

нафига ит компании мои навыки по оценке стоимости строительства, если им нужеы люди с навыками в ит?

есть такое понятие - soft skills

где бы ты ни работал ты уже отличаешься от человека который идет в первый раз в первый класс, и это важное отличие

Ну а там уже по специфике работы можно релевантный опыт накопать - организация работ, ведение отчетности, договоренности с внешними заказчиками/поставщиками, мало ли что. В IT оно всё такое же.

Навыки управления при работе инженером все равно полезны. Если ты, например, можешь поставить себя на место того менеджера, с которым придется вместе ставить задачу, найти с ним общий язык и не скандалить по пустякам, как вчерашний школьник.

Управлять образованными людьми куда приятнее чем разнорабочими на стройке :) Но я вас услышал, не всем менеджмент по душе.

Да не. На том же hh есть секция «О себе», она как и предназначена для написания всякого бреда чтобы развлечь рекрутера и привлечь внимание. Я в рамках небольшой конторы занимаюсь подбором кадров в «ит-отдел» (формально отделов нет, по факту есть), и я бы оценил это как неплохую шутку и, наверняка скинул бы резюме главному инженеру, как минимум на поржать.

То и значит, делаешь акценты.

Пишешь резюме на разраба, указываешь ссылку на гитхаб, пишешь резюме на дизайнера прикладываешь сайтик с портфолио, устраиваешься условным «журналистом», прикладываешь ссылку на какой-нибудь бложек там или стейки, пишешь в «О себе» что-то по теме. А на хантере сразу видно сколько лет опыта у кандидата в конкретной сфере, если резюме профильное.

Рекрутеру, который ищет разраба, как-то насрать сколько там лет чувак работал на стройке, это не релевантно. Оно особо не помешает, но и не поможет.

Когда в резюме эти 15 лет работы подробно расписаны, то это действительно отпугивает, резюме всё же айтишным должно быть, но понять чем ты раньше занимался для кого-то может не лишним оказаться.

есть ли вообще это самое «правильно»

Нет, рекрутеры — люди, у каждого свой подход.

Вот ищешь ты инженера, в объявлении вполне чёткие формулировки. А тебе приходит резюме в котором простыня про менеджмент написана, озаглавленное «Руководитель-проектов». Руководитель справедливо будет отправлен руководить где-то ещё, ибо чувак очевидно левый, а отклик сделан на удачу не глядя, зачем вообще тратить на него время?

А тебе приходит резюме в котором простыня про менеджмент написана, озаглавленное «Руководитель-проектов».

Печальный случай, но к моим словам это никакого отношения не имеет.

Да, простыню про менеджмент писать не надо, «hard skills» забывать не надо, и название надо писать правильно и писать резюме и сопроводительное письмо надо под вакансию, а не абы как.

Тем не менее управление - это важный навык, который не надо прятать и из которого надо извлекать пользу. Когда я ищу инженера - мне надо понимать будет ли это тупо исполнитель простых команд: запусти сервис, настрой бекап, выполни апгрейд и «а у этого я бекап не настроил потому что мне не дали такой команды»...

Или он будет приходить ко мне со словами «нам нужно провести апгрейд всех систем до конца года, думаю что нужно спланировать это следующим образом: главную БД оставим на после сдачи финансовой отчетности, первыми отработаем такие-то и такие-то сервера. Я договорился с командой X, что у них на это время не запланировано релизов поэтому у нас будет достаточно времени...»

Или он будет приходить ко мне со словами «нам нужно провести апгрейд всех систем до конца года, думаю что нужно спланировать это следующим образом: главную БД оставим на после сдачи финансовой отчетности, первыми отработаем такие-то и такие-то сервера. Я договорился с командой X, что у них на это время не запланировано релизов поэтому у нас будет достаточно времени...»

На самом деле это «Или он будет делать за меня мою работу» //фикс

Извини, не удержался

Ну а там уже по специфике работы можно релевантный опыт накопать - организация работ, ведение отчетности, договоренности с внешними заказчиками/поставщиками, мало ли что. В IT оно всё такое же.

Если бы мне надо было в управление ИТ проектами, я бы так и писал и вопрос о предыдущем опыте не возник бы.

В этом случае возможно мой опыт руководства маленьким коллективом, опыт коммуникаций и кроссфункционального взаимодействия был бы даже где-то в тему, а знания всего понемногу о разработке, тестировании и внедрении софта вполне могли бы мне помочь на новом месте.

Каждый инженер уровня выше Junior в какой-то мере управляет своим «проектом». Разного масштаба, разного уровня формализации, с разными способами отчетности... Возможность самостоятельной высокоуровневой деятельности - это банально определяющий признак не-джуниора.

Это часть работы инженера. И не микроменеджер за тебя будет её делать.

у нас был инженер, у которого первая должность в трудовой книжке была «тракторист». ну, родился человек в колхозе. другой работы там особо и нет. так что я думаю, опыт прошлых работ не слишком влияет. главное, чтобы опыт в области, на которую претендуешь, был приемлемым для работодателя.

У хх есть подсчет сколько у тебя лет опыта, тебе нужно чтобы эта чиселка была поближе к релевантному опыту.

Печальный случай, но к моим словам это никакого отношения не имеет

Я просто описал типичный случай «руководителя».

Когда я ищу инженера - мне надо понимать будет ли это тупо исполнитель простых команд

Вряд ли пару слов про опыт управления тебе что-то действительно даст. Во-первых, руководители случаются и на пустом месте, нередко бывают и кончеными дятлами, во-вторых, он наверняка не из хороших, если пошел на понижение.

Иногда такое может говорить о тех или иных качествах характера / умениях, в любом случае я подобное рассматриваю как плюс.

Вряд ли пару слов про опыт управления тебе что-то действительно даст

Ну так, собеседование чтением резюме только начинается.

он наверняка не из хороших, если пошел на понижение

Из руководителя в инженеры - это не понижение, а переключение. Зарплата при этом может и повыситься, а дело может быть даже просто в личном интересе. Управлять другими надоедает, хочется поделать что-то своими руками.

В хороших местах у инженеров есть свой карьерный рост, у менеджеров свой, и ты можешь выбрать по какому идти.

Каждый инженер уровня выше Junior в какой-то мере управляет своим «проектом»

Зависит от уровня конторы. Где-то и целиком под ответственность джуна могут что-то не очень нужное отдать, а где-то и над сеньёрами стоит лид, за которым последнее слово. Где-то организационные вопросы, как и положено, решаются менеджментом, а где-то разработчики ведут переговоры с клиентами / партнёрами.

а где-то и над сеньёрами стоит лид, за которым последнее слово

А над лидом стоит его лид, за которым распоследнее слово, а над тем лидом.. Да, так это всё и работает.

Управление - это не «делай что хочешь», это договаривайся, планируй, обосновывай. На уровне тим лида, на уровне клиента, на уровне коллеги-стажера, с которым ты вместе пилишь одну фичу..

Где-то организационные вопросы, как и положено, решаются менеджментом

Задача менеджера проектов брать на себя управление твоими действиями, а расчищать те завалы, которые ты расчистить не потянешь при всем желании. Это дополнительная деятельность, а не замещающая управление в твоей работе.

это договаривайся, планируй, обосновывай

Это делается на всевозможных совещаниях по планированию и «оперативках». Разраб должен иметь чёткое тз и делать своё дело, заниматься вопросами разработки, а не организацией чего бы то ни было. Иначе эффективный разраб превращается в осьминога, который занимается чем попало вместо написания кода.

Задача менеджера проектов

Решать организационные вопросы он должен, иначе на кой чёрт вообще нужен руководитель? Разрабы в твоей схеме и сами неплохо самоорганизуются, напридумают проектов, найдут клиентов / пользователей, закажут рекламу, организуют IPO, постоят себе новый офигенный офис с видеоиграми и шлюхами.

Считается, что нерелевантный опыт в резюме указывать не нужно. Но если там есть чем похвастаться, то можно указать, схлопнув его в одну позицию (если там было несколько мест/должностей), наверное.

У них аргументы, что они так хотят

Да посылай ты их лесом. Нахрен они тебе сдались-то? Как будто рекрутеры только этот ХаХа и мониторят...

По-моему ты споришь не со мной, а с каким-то воображаемым врагом на воображаемую тему.

Я говорю об управлении проектам в широком смысле. Разбить твоё ТЗ на таски, сгруппировать их по порядку выполнения и скоординироваться с коллегой кто из вас что делает - это уже управление, и это одновременно «вопросы разработки».

И я тебе там выше даже пример привела. Задача: «обновить вот эту часть инфры до новой версии» - это твоё ТЗ. Разбить его на куски и спланировать обновление так чтобы минимизировать downtime - это твоё управление этим проектом. И это твоя инженерная работа.

Ты можешь попытаться быть «чистым разработчиком» и ждать пока кто-то (бизнес-аналитик, архитектор, тим лид, менеджер, «постановщик задач»..) разжует всё до мелких тасков вида «реализовать функцию такую-то получающую такие-то данные на вход и выдающую такой-то результат».

Но только это уже будет не разработка. Это работа секретаря-машиниста с расширенной клавиатурой.

И правильно делают. Опыт должен быть ревелантен работе.

Зачем мне при поиске программиста/админа читать про стройку?

это уже управление, и это одновременно «вопросы разработки»

Именно по этой причине это следует обсудить на совещании, а решения должен принять не абстрактный менеджер в вакууме, а вполне конкретный тимлид. Разработчики не должны ничего бить на таски и распределять, лишь высказать мнение, которое лид учтёт.

Но только это уже будет не разработка

Разработка — это архитектура, реализация, документация, профилирование, тестирование и так далее, мб даже деплой, а работа по «тз» «сделай ЗБС вон тем чувакам, вот их имейл» — уже не разработка.

И ты говоришь не «об управлении проектам в широком смысле», а о типичном колхозном, назовём его, «managementless» подходе, когда менеджер либо не компетентен, либо ленив.

Разработчики не должны ничего бить на таски и распределять, лишь высказать мнение, которое лид учтёт.

Чтобы высказать мнение надо его иметь. Чтобы иметь мнение надо понимать что ты делаешь. Это и называется навыки управления, которые являются плюсом при работе разработчиком или инженером.

Разработка — это архитектура, реализация, документация, профилирование, тестирование и так далее, мб даже деплой, а работа по «тз» «сделай ЗБС вон тем чувакам, вот их имейл» — уже не разработка.

Что не противоречит ни одному из моих постов.

Попробуй вчитаться что ли.

И правильно делают. Опыт должен быть ревелантен работе.

Зачем мне при поиске программиста/админа читать про стройку?

у них претензия не к тому, что я пишу стройку в ИТ резюме под ИТ вакансию, а в том, что якобы я не могу быть начинающим, поскольку мне уже лет много и опыт есть в том же ИТ (какой есть, не суть), и при этом опыта почему-то должно быть от 5-7 лет УЖЕ. Когда я их спрашиваю, а если нет опыта 5 лет, а есть 4, чем это плохо-то, то в ответ слышу идиотскую отсылку к их правилам. Логика там не ночевала и конечно их техподдержка даже не хочет вдумываться в мой вопрос.

Что не противоречит ни одному из моих постов

Задача менеджера проектов не (? пропущено) брать на себя управление твоими действиями, а расчищать те завалы, которые ты расчистить не потянешь при всем желании
Разбить твоё ТЗ на таски, сгруппировать их по порядку выполнения и скоординироваться с коллегой кто из вас что делает - это уже управление, и это одновременно «вопросы разработки»

Твой общий посыл, если я его правильно понимаю, в том, что разработчик — самостоятельная единица, которая должна самоорганизовываться. Чем в твоей парадигме должен заниматься менеджер, я так и не понял.

В моей парадигме разраб выполняет тз и не занимается организационными вопросами ни в каком виде, в рамках его деятельности ему и так достаточно где пораскинуть мозгами. Организационные вопросы решает менеджер, на уровне непосредственной разработки это лид, на уровне продукта уже некто выше и так далее. Принятие решений одним человеком всегда эффективней чем самотёк среди кучки программистов, которые не знают в точности что им делать.

Тут хх не правы.

Но и если опыта мало, иди сразу на галеры в обучение и дальше по кривой дорожке. Либо через друзей. Хх не даст выхлопа.

Попробуй вчитаться что ли.

У тебя специфика деятельности. Не думаю, что ее будут понимать люди из дева особенно низовых должностей.

Это у нас абстрактная задача - организовать пайплайн или архитектуру деплоя, или организацию взаимодействия сервиса с внешним миром.

Там суровый дев: кнопка синего цвета в 2 пикселях от кнопки красного цвета :) как только вырастет хотя бы до сеньора - до него дойдет :)