Если честно, подобные статьи публикуются на многих сайтах уже не первый год. Сайты и авторы обычно разные, а вот содержание наоборот почти одно и то же.
Что делать фулстек-разработчикам? Готовить три резюме:
как фулстек, чтобы показать, что вы универсал;
сеньор фронтенд-разработчика;
сеньор бекенд-разработчика.
В каждом резюме указывается свой ключевой стек.
Очень странное представление о full stack.
Если перед Вами Full stack разработчик, к сожалению, это не означает, что он сеньор. Он может быть, так же как и все остальные, и джуном и мидлом и т.д. Плюс степень владения технологиями back и front у одного и того же специалиста может различаться. Да и не факт, что full stack разработчику будет интересна работа в более узкой специализации.
Задача рекрутера — быстрее закрыть вакансию. Он/она не будет вчитываться в резюме, а отбирает только тех специалистов, что проходят по формальным признакам. Поэтому рекрутер смотрит резюме примерно минуту (или меньше) «по диагонали» — по ключевым словам и фразам.
А, потом максимум через 2-3 месяца вакансию снова откроют? Но, за то честно высказано отношение и к соискателю, и, самое главное к компании, на которую такой рекрутёр работает.
Реклама всевозможные курсов и пр.говорит только о наличии спроса на соответствующие услуги. Не более.
Войти легко только туда, где порог вхождения низкий. В том же тестировании можно заниматься рпростыми ручным тестами (таких тестировщиков всегда было полно), а можно делать очень серьёзные вещи, к которым без подготовки даже не подойти. Это если в двух словах.
Насчёт задачи про ДНК не уверен, но остальные вопросы обычно задают для быстрого отсева «случайных» кандидатов, которым по факту до сеньора ещё расти и расти не один год.
Если же всё техническое интервью состоит из вопросов примерно такого плана, то это конечно повод задуматься.
Возможно я ошибаюсь, но обычно причиной овертаймов бывает одно из двух.
Это либо форс-мажор (но, такое происходит согласитесь не каждый день), либо недостаточно квалифицированный менеджмент, который не смог должным образом выстроить процессы (это самая распространённая причина).
ребята, я тут методичку прочитала на 16 страниц, сертификат получила, сейчас я буду вам рассказывать, как нужно выстраивать скрам/канбан процесс". Реально?? Можно было просто сказать "вы тупые, работали столько лет неправильно, а я умная, сейчас вас научу". Я была бы послана обратно со скоростью пули.
Как гласит пословица: "Хочешь помочь мастеру - отойди и не мешай!". Особенно если все знания и опыт сводятся к "методичке на 16 страниц".
Тем более, даже в PMBOK написано, что SCRUM/Kanban и т.д. не должны быть самоцелью.
XP оставалась популярной не благодаря задержке выхода новой версии винды, как пишет автор статьи, а потому что последняя даже после релиза очень сильно уступала XP в плане качества. Господство XP стало сходить на нет только после выхода 7. Аналогично 7 смогла понастоящему вытеснить только 10.
До сих пор помню как после покупки свежего ПК или ноутбука с Vista или 8 люди сразу ставили вместо родной ОС XP или 7.
если преподаватель в Бауманке знает только эту версию Spice
ИМХО именно это, а не возраст является ключевыми словами.
Чтобы подготовить курс по той или иной технологии для начала нужно самому её изучить. Потом разработать разработать программу курса, потом материал по теории и практике и т.д… Короче нужно приложить определённые усилия. Про выход новых версий я уж умолчу. Гораздо проще 1 раз написать лекции и практический материал и потом N лет по ним учить.
Многие даже молодые преподаватели, к сожалению, идут именно по второму пути. Некоторые так и вовсе не заморачиваются и берут за основу чужие лекции в открытом доступе и даже видеоуроки.
А, потом выпускник приходит устраиваться в компанию и ему вежливо (или не очень объясняют), что он «отстал от жизни» на 15-20 лет.
Документация для разработчика — здесь имела ввиду бизнес-описание фичей (что это? зачем? как оно должно работать? какой результат юзер должен получить).
Обычно всё это описывается в требованиях и это вотчина аналитиков. Пока аналитики не напишут в ТЗ или тот же Confluence требования для новой фичи или доработки старой, задача в разработку идти не должна. И техпис, хотя бы, до завершения описания требований, по хорошему не должен её касаться. Просто у вас в компании видимо по «доброй» традиции решили сэкономить на аналитиках и отдать их работу техписам со всеми вытекающими.
Говорю не в упрёк. На самом деле в очень многих компаниях подобная печаль.
пользователь-начинашка, который ищет кнопку “Сделать хорошо” в интерфейсе, или разработчик, которого подключают на новый проект, – документация должна помочь такому пользователю или разработчику.
Выскажу точку зрения с позиции разработчика.
Документация для пользователя в целом полезна, как общее описание системы. Она, при грамотном использовании, сокращает время ознакомления с проектом. Но, специальная документация для разработки в большинстве случаев уже давно ушла в прошлое (по большей части).
Если в проекте код написан соответствующим образом, то разобраться в его работе можно и без документации. Плюс во многих компаниях те же API и прочий функционал, а также требования ко всему этому документируются по мере развития системы аналитиками и самими разработчиками в Confluence (или аналогичных продуктах) самостоятельно.
Поэтому писать development guide целесообразно только когда проект в той или иной степени предназначен для использования при разработке другого ПО (библиотеки, информационные системы с API для интеграции со сторонними системами и т.п.).
Другое дело, когда в коде может разобраться в лучшем случае только его автор, нет базы знаний, требования не оформлялись должным образом и т.д. Но, в таких случаях даже от документации толку мало потому, что проблема не в ней или её отсутствии, а в самой постановке рабочего процесса и «культуре производства».
P.S.
налаживайте процесс вычитки документации у себя в команде.
Всё хорошо, когда бывает кстати и меру.
Во многих проектах (если брать серьёзные проекты) объём документации (различные руководства, спецификации) измеряется десятками, а часто и сотнями страниц для каждого тома. Как Вы думаете, сколько нужно времени хотя бы на то, чтобы всё это вычитать? Не говоря уже о том, что бы прочитанный материал был понят и усвоен…
Быстрый горизонтальный рост компетенций
Минимальные начальные требования для кандидатов
Это называется «эффект низкой базы».
Первое время, пока знаний толком нет и всё новое вы развиваетесь, но потом вы очень быстро упрётесь в потолок. Такова специфика техподдержки как таковой (особенно если вас поставят на 1ю линию).
Если «познаний в схемотехнике не так много» и у нет цели их углубить, то ИМХО проще купить готовый KVM переключатель. Тем более сейчас они продаются во многих магазинах и стоят сравнительно недорого.
Возможно вы будете очень удивлены. Только на отсутствие обратной связи опытные люди давно не обращают внимания.
Если человек нужен, компания очень редко когда затягивает процесс дольше чем на несколько дней. Если молчат дольше, можно о них забыть. Если конечно у вас нет цели работать именно в этой компании.
Как по мне в статье описано одно из типичных заблуждений начинающих специалистов, которые склонны видеть только техническую часть проекта. Это с одной стороны.
С другой стороны карго-культ (или, как говорил в свое время Архипенков, «методологическое безумие») некоторых представителей менеджмента. Где всевозможные стратегии, презентации и т.п. наше всё.
Только по мере профессионального роста начинаешь понимать, что на одном программировании далеко не уедешь, а приёмы менеджмента без реального результата тоже никому не нужны.
Сам факт тестового задания можно использовать, как лакмусовую бумажку. За долгие годы не встретил ни одной действительно хорошей вакансии, где предлагали тестовое. Либо это предложения начального уровня (студенты, выпускники и т.д.), либо это предложения, мягко скажем, вызывающие много вопросов.
В большинстве адекватных компаний как-то без этого обходятся. Там по hard skills всё решает техническое собеседование, испытательный срок и портфолио (при наличии).
Всё вышесказанное суть личное субъективное мнение на основе личного жизненного опыта. Не более.
Теряется быстрота реакций, возможность маневра, широта эксперимента, а главное – совершенно нет возможности взять трубку и наорать на бекэндчиков, ибо бэкенд в данном случае – на стороне клиента.
Если проблема в том, что бэки плохо справляются с работой, то нанимайте толковых бэков и не вешайте по 100500 проектов, на одного-двух сотрудников.
Если же бэк на стороне заказчика, учитесь сотрудничать и как-то договариваться. В конце-концов вы оказываете заказчику услуги, а он платит вам деньги, а не наоборот.
Но давайте запомним – хороший программист не может стоить дешево. Поэтому если вам предлагают что-то критично ниже рынка – скорее всего, те мандарины с гнильцой.
К сожалению, топовый ценник вовсе не всегда означает топовые доходы конечных исполнителей (тех же программистов). А, топовый доход специалиста также не всегда соответствует его квалификации.
Подрядчик может попросить большую кучу денег из которых все сливки снимут до того, как они дойдут до команды разработки. Разработчики с заоблачными зарплатными ожиданиями, но которых просто опасно подпускать к любому проекту, к сожалению тоже встречаются.
Конечно, рассчитывать на то, что по цене сборной модели из картона вам сделают настоящий авиалайнер, по меньшей мере наивно. Но, и делать выводы опираясь в первую очередь на ценовой фактор, тоже не совсем разумно.
Статья по сути просто набор устаревших стереотипов. Очень позабавило относительно фрилансеров и продуктовых компаний.
Первых часто с удовольствием берут в «проектные» компании, т.к. у таких кандидатов уже есть опыт заказной разработки. А, люди, пришедшие с «продукта» как раз наоборот нередко с трудом адаптируются к её специфике. Да и опыт на «продукте», при всём уважении, не всегда можно получить хороший. Многое зависит от конкретной компании и её " продукта ".
Очень странное представление о full stack.
Если перед Вами Full stack разработчик, к сожалению, это не означает, что он сеньор. Он может быть, так же как и все остальные, и джуном и мидлом и т.д. Плюс степень владения технологиями back и front у одного и того же специалиста может различаться. Да и не факт, что full stack разработчику будет интересна работа в более узкой специализации.
А, потом максимум через 2-3 месяца вакансию снова откроют? Но, за то честно высказано отношение и к соискателю, и, самое главное к компании, на которую такой рекрутёр работает.
Войти легко только туда, где порог вхождения низкий. В том же тестировании можно заниматься рпростыми ручным тестами (таких тестировщиков всегда было полно), а можно делать очень серьёзные вещи, к которым без подготовки даже не подойти. Это если в двух словах.
Так что всё на самом деле не так однозначно.
Если же всё техническое интервью состоит из вопросов примерно такого плана, то это конечно повод задуматься.
Возможно я ошибаюсь, но обычно причиной овертаймов бывает одно из двух.
Это либо форс-мажор (но, такое происходит согласитесь не каждый день), либо недостаточно квалифицированный менеджмент, который не смог должным образом выстроить процессы (это самая распространённая причина).
Как гласит пословица: "Хочешь помочь мастеру - отойди и не мешай!". Особенно если все знания и опыт сводятся к "методичке на 16 страниц".
Тем более, даже в PMBOK написано, что SCRUM/Kanban и т.д. не должны быть самоцелью.
До сих пор помню как после покупки свежего ПК или ноутбука с Vista или 8 люди сразу ставили вместо родной ОС XP или 7.
ИМХО именно это, а не возраст является ключевыми словами.
Чтобы подготовить курс по той или иной технологии для начала нужно самому её изучить. Потом разработать разработать программу курса, потом материал по теории и практике и т.д… Короче нужно приложить определённые усилия. Про выход новых версий я уж умолчу. Гораздо проще 1 раз написать лекции и практический материал и потом N лет по ним учить.
Многие даже молодые преподаватели, к сожалению, идут именно по второму пути. Некоторые так и вовсе не заморачиваются и берут за основу чужие лекции в открытом доступе и даже видеоуроки.
А, потом выпускник приходит устраиваться в компанию и ему вежливо (или не очень объясняют), что он «отстал от жизни» на 15-20 лет.
Обычно всё это описывается в требованиях и это вотчина аналитиков. Пока аналитики не напишут в ТЗ или тот же Confluence требования для новой фичи или доработки старой, задача в разработку идти не должна. И техпис, хотя бы, до завершения описания требований, по хорошему не должен её касаться. Просто у вас в компании видимо по «доброй» традиции решили сэкономить на аналитиках и отдать их работу техписам со всеми вытекающими.
Говорю не в упрёк. На самом деле в очень многих компаниях подобная печаль.
Выскажу точку зрения с позиции разработчика.
Документация для пользователя в целом полезна, как общее описание системы. Она, при грамотном использовании, сокращает время ознакомления с проектом. Но, специальная документация для разработки в большинстве случаев уже давно ушла в прошлое (по большей части).
Если в проекте код написан соответствующим образом, то разобраться в его работе можно и без документации. Плюс во многих компаниях те же API и прочий функционал, а также требования ко всему этому документируются по мере развития системы аналитиками и самими разработчиками в Confluence (или аналогичных продуктах) самостоятельно.
Поэтому писать development guide целесообразно только когда проект в той или иной степени предназначен для использования при разработке другого ПО (библиотеки, информационные системы с API для интеграции со сторонними системами и т.п.).
Другое дело, когда в коде может разобраться в лучшем случае только его автор, нет базы знаний, требования не оформлялись должным образом и т.д. Но, в таких случаях даже от документации толку мало потому, что проблема не в ней или её отсутствии, а в самой постановке рабочего процесса и «культуре производства».
P.S.
Всё хорошо, когда бывает кстати и меру.
Во многих проектах (если брать серьёзные проекты) объём документации (различные руководства, спецификации) измеряется десятками, а часто и сотнями страниц для каждого тома. Как Вы думаете, сколько нужно времени хотя бы на то, чтобы всё это вычитать? Не говоря уже о том, что бы прочитанный материал был понят и усвоен…
Это называется «эффект низкой базы».
Первое время, пока знаний толком нет и всё новое вы развиваетесь, но потом вы очень быстро упрётесь в потолок. Такова специфика техподдержки как таковой (особенно если вас поставят на 1ю линию).
«Самозванцы» здесь ни при чём. Почитайте пожалуйста об эффекте Даннинга-Крюгера применительно к квалифицированным специалистам…
Если человек нужен, компания очень редко когда затягивает процесс дольше чем на несколько дней. Если молчат дольше, можно о них забыть. Если конечно у вас нет цели работать именно в этой компании.
С другой стороны карго-культ (или, как говорил в свое время Архипенков, «методологическое безумие») некоторых представителей менеджмента. Где всевозможные стратегии, презентации и т.п. наше всё.
Только по мере профессионального роста начинаешь понимать, что на одном программировании далеко не уедешь, а приёмы менеджмента без реального результата тоже никому не нужны.
В большинстве адекватных компаний как-то без этого обходятся. Там по hard skills всё решает техническое собеседование, испытательный срок и портфолио (при наличии).
Всё вышесказанное суть личное субъективное мнение на основе личного жизненного опыта. Не более.
Я в курсе, что не вы их нанимаете. Только вопрос совсем не в том, кто их нанимает.
Если у вас есть свой сектор бэк разработки постройте правильно подбор людей и работу с ними. Тогда вам не придётся на них кричать.
Если же бэк на стороне клиента, то по этому поводу я уже написал выше. Только переговоры, мудрость и сдержанность.
Если проблема в том, что бэки плохо справляются с работой, то нанимайте толковых бэков и не вешайте по 100500 проектов, на одного-двух сотрудников.
Если же бэк на стороне заказчика, учитесь сотрудничать и как-то договариваться. В конце-концов вы оказываете заказчику услуги, а он платит вам деньги, а не наоборот.
К сожалению, топовый ценник вовсе не всегда означает топовые доходы конечных исполнителей (тех же программистов). А, топовый доход специалиста также не всегда соответствует его квалификации.
Подрядчик может попросить большую кучу денег из которых все сливки снимут до того, как они дойдут до команды разработки. Разработчики с заоблачными зарплатными ожиданиями, но которых просто опасно подпускать к любому проекту, к сожалению тоже встречаются.
Конечно, рассчитывать на то, что по цене сборной модели из картона вам сделают настоящий авиалайнер, по меньшей мере наивно. Но, и делать выводы опираясь в первую очередь на ценовой фактор, тоже не совсем разумно.
Первых часто с удовольствием берут в «проектные» компании, т.к. у таких кандидатов уже есть опыт заказной разработки. А, люди, пришедшие с «продукта» как раз наоборот нередко с трудом адаптируются к её специфике. Да и опыт на «продукте», при всём уважении, не всегда можно получить хороший. Многое зависит от конкретной компании и её " продукта ".