Русский
Русский
English
Статистика
Реклама

Middle

А ты точно senior? или ожидания продуктовых компаний

07.01.2021 14:19:53 | Автор: admin

Привет, я тех/тим лид в одной из продуктовых web компаний - систематически занимаюсь собеседованиями. Для меня главная проблема понять кто перед тобой senior, или не особо. А если еще и нужно согласовать мнение со вторым интервьюером...

В общем если вы занимаетесь WEB разработкой хотите понять свой уровень, или стоите на страже компании и не до конца понимаете как понять уровень кандидата добро пожаловать под кат.

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

Для себя я выделил два основных направления - аутсорс и продуктовые компании.
Для аутсорс важнее широкий спектр технологий с которыми сталкивался кандидат.
В продуктовой будет важнее глубокое понимание технологий и принципы написания поддерживаемого кода.

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

Итак первое знакомство с кандидатом - резюме

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

На что обращаю внимание:
Как долго работает в одной компании, есть ли рост/смена позиций за время работы.

На чем акцент: технологии или подходы, задачи которые решал или технологии которыми пользовался.

Красным флагом могут быть:
частая смена проектов
большие количество проектов с CMS
пустое перечисление ключевых слов от CSS до IDE.

Если будет интересно к теме хорошего оформления резюме как-нибудь вернемся.

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

И пока не забыл, обязательно подпишитесь на мой канал в телеграмм чтобы не пропустить новые публикации, так-же буду там делится короткими размышлениями по темам разработки, отписаться если что всегда успеешь :)

Итак наш герой дня, таблица навыков для web разработчика, учтите что таблица указывает на средний/верхний порог уровня, для нижнего можно на усмотрение убрать по пункту из тем:

Под таблицей есть спойлер с картинкой если на вашем экране таблица поползла)

Junior

Middle

Senior

Архитектура приложений

Есть базовое понимание принципов ООП

Слышал про SOLID

Может придерживаться соглашений проекта и прослеживать аналогии

Знает пару паттернов

Хорошо понимает SOLID

Слышал про GRASP

Знает про модульную архитектуру

Знает какие есть паттерны, понимает когда нужно применять

Знает основные подходы к проектированию приложения(CQRS,ES,Modular,SOA)

Хорошо понимает как предупредить каскадные изменения

Может рассуждать про метрики качества кода

Знает паттерны вне GOF

Код

Знает базовые конструкции языка

С помощью гугла может решить основные задачи

Знает основные возможности языка, ряд популярных дополнений/библиотек

Может решить сложные задачи и направить Junior разработчика

Может грамотно построить структуру проекта

Код понятен легко читаем без лишнего усложнения

Структуры данных/алгоритмы

Знает какие есть структуры данных

Может подобрать подходящую для простых случаев

Может написать простой алгоритм, посчитать его сложность

Хорошо понимает структуры данных, в каком случае какую выбрать

Может выбирать, создавать сложные алгоритмы

При выборе алгоритма и структуры данных размышляет про эффективность выбора в разрезе RAM/CPU

Реляционные базы данных

Может строить простые запросы(выборки, простые джоины)

Понимает что такое индексы

Может построить отношения между таблицами

Может строить сложные запросы(сложные джоины, подзапросы, агрегации)

Понимает как построить оптимальные индексы

Может профилировать запросы, знает explain

Может спроектировать простую структуру базы данных

Понимает как работать с большими таблицами

Знает про репликацию

Может построить сложную структуру базы данных(шардинг, денормализация)

Знает ограничения и возможности популярных баз данных

Понимает ограничения CAP, PACELC

Безопасность

Слышал основные уязвимости

Знает основные OWASP уязвимости и как их предотвращать

Знает ряд техник для мониторинга, предотвращения уязвимостей.

Понимает как действовать при атаке

Тестирование

Есть базовое понимание для чего и как писать юнит тесты

Понимает различия между разными видами тестов

Может эффективно их писать

Понимает как избегать хрупких тестов

Знает разные подходы к написанию тестов(TLD, TDD)

Может рассуждать о пирамиде тестирования

Знает что дает и как создать нагрузочное тестирование

Как плюс знает AB тестирования

API

Знает базовые методы HTTP

Слышал про RPC,REST

Хорошо понимает принципы проектирования API

Знает какие есть варианты авторизаций

Знает основные подходы стандартизации/версионирования API

Может выбрать тип авторизации для проекта

Очереди/ Шина сообщений

Понимает зачем они и как работать на уровне интерфейса языка/библиотек

Понимает разницу между очередью и шинной данных

Знает основные проблемы воркеров и как из предотвращать (утечки памяти, перезапуск, мониторинг)

Знает основные решения по настройке, мониторингу очередей

Может выбрать подходящий брокер

Спроектировать подход к обработке данных (очередь, пайплайн, асинхронный ответ)

Многопоточность/ Асинхронность
Если поддерживает язык

Владеет на уровне интерфейса языка

Знает как работать с многопоточностью
(блокировки, синхронизация)

Знает как работать с асинхронностью

Понимает что такое итоговая согласованность

Когда и как лучше распараллелить процесс

Кеширование

Может работать на уровне интерфейса языка/библиотеки

Догадывается когда использовать

Знает как организовать кеш, какие бывают проблемы

Хорошо знаком с проблемами нагруженного кеша(прогрев, волна запросов, конкурентный доступ)

Инфраструктура/Сети

Знание базовых команд операционной системы

Знает какие этапы проходит запрос перед тем как попасть в приложение

Знаком с одним из средств виртуализации

Понимает какие вещи и как нужно настроить для продакшн среды

Понимает виртуализацию и контейнеризацию

Знает базовые сетевые протоколы TCP, UDP, HTTP, HTTPS

Понимает как устроена сеть DNS, NAT, OSPF, BGP, RIP

Знает как балансировать нагрузку(включая необходимость попадания данных на тот-же сервер)

Хорошо понимает принципы работы CDN и как решать базовые проблемы

Знает ограничения текущей платформы, как их обойти

Метрики/логи

Знает зачем логи, как их писать

Знает варианты сбора логов

Понимает зачем проекту мониторинг, как им пользоваться

Может выбрать необходимые метрики

Знаком с рядом вариантов сбора метрик/логов

Способен настроить алертинг, сбор необходимых метрик

Желательно знакомство с TSDB

CVS/ Релиз процесс

Понимает зачем нужна CVS

Может выполнять базовые операции CVS

Может рассказать как сделать простой релиз через CVS и SSH руками

Хорошо знает команды CVS

Знает пару фреймворков построения процесса

Знает как работает CI

Может построить CI процесс, знает какие для этого есть инструменты

Хорошо знает подходы к ветвлению, может выбрать подходящий

PNG

С радостью выслушаю ваши замечания и мысли по этому поводу в комментариях, или реакцией в телеграмм

Подробнее..

От студента до учителя как разобраться в веб-разработке, если это не твой профиль

21.04.2021 20:21:36 | Автор: admin

Хоть кому-то и может показаться, что веб-разработчик это суровый технарь (айтишник же!), вход в эту профессию не сложнее, чем вPython. В неё часто переходят бывшие педагоги, юристы, бухгалтеры и другие гуманитарии. О том, с чего начать обучение, какие ошибки допускают новички, как освоиться в профессии и стоит ли самостоятельно учиться, рассказывает преподаватель веб-разработки в GeekBrains Алексей Кадочников.

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

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

Никогда не откладывайте обучение на завтра: заведите будильник, например, на восемь вечера. Большинство людей к этому времени успевают освободиться от работы, попасть домой и даже поужинать. Зазвенит садитесь и занимайтесь до девяти-десяти. И так каждый день. Пропустили? Добавьте пропущенный час к занятию завтра.

Конечно же, 8 вечера это не панацея. Главное оптимизировать график, чтобы эффективно совмещать обучение и работу. Когда я переучивался на разработчика (об этом расскажу дальше), ставил будильник на шесть утра, занимался, завтракал и ехал на работу.

Кто переучивается на разработчика

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

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

Мне самому пришлось сменить специальность. Восемь лет назад, когда я окончил университет, оказалось, что на рынке по специальности Вычислительные машины, комплексы, системы и сети всего 8 вакансий. Для четырех из них мне не хватало опыта, а по ещё четырём мне не перезвонили. В результате устроился инженером на завод и через несколько месяцев работы понял, что это не то, чему я хочу посвятить жизнь. Тогда яс нуляпрошелкурсы веб-разработкии нашёл работу по их окончанию. СейчасяFront-end developerвMail.ru GroupипреподаювGeekBrains.

Еще один пример мой студент Павел Литвин. Он не доучился в ВУЗе на безопасника, работал менеджером по продажам, потом в SEO, в конце концов выучился фронтенд-разработке и стал зарабатывать в4 раза больше, чем до курсов.И таких историй множество.

Представление о профессии у новичков зачастую далеко от реальности. Некоторым всё ещё кажется, что программист это тот, кто сидит дома, ничего не делает и много зарабатывает. Когда сталкиваюсь с таким у студентов, приходится объяснять, чем именно нужно будет заниматься, сколько времени учиться и как потом предстоит работать.

Чтобы понять, подойдет ли тебе специальность, надо просто попробовать. В онлайн-школах, где учат разработке, есть бесплатныеинтенсивына несколько часов. За это время студентам предлагается сделать небольшой проект: так можно понять, подходит ли им эта сфера. Если вы попробовали пару таких интенсивов и ничего не получается или не нравится процесс, возможно, это не ваше призвание и стоит продолжить поиски. Профессия веб-разработчика подходит многим, но это не универсальный рецепт. Наверняка вы найдете для себя что-то другое.

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

Самостоятельное обучение

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

В момент, когда я пошёл на курсы, мой знакомый решил учиться самостоятельно три года что-то читал, смотрел в интернете. В итоге за это время он вышел на зарплату в 50 000 рублей. Пойди он на курсы, достиг бы этого результата уже через полгода-год. Думая, что экономит, он потерял деньги.

Еще одна частая проблема самостоятельногообучения веб-разработке с нуляосвоение устаревших технологий. Мне приходилось переучивать студентов, выучивших неактуальную информацию. Есть вещи, которые уже не применяются, оптимизировались и их нужно удалить из памяти или перенастроить. Например, раньше в верстке для перемещения элемента использовалась командаfloat left, но это довольно громоздкое и сложное решение. Затем вместо него начали использоватьdisplay: flex. Теперь и этот метод успел устареть и теперь актуаленdisplay: grid. Внешний вид от всех этих способов будет одинаковым, но последнее решение изящнее и быстрее в реализации.

Наверное, самое большое заблуждение при самостоятельном освоении профессии отсутствие представления о том, как технологии связаны друг с другом и могут работать в связке. Без учебной программы все знания получаются хаотичными. Также велика вероятность, что после самообучения у вас не будет портфолио (на курсах оно будет) и четкого понимания путей развития в профессии (чтобы его выработать, нужно общаться с теми, кто в этом разбирается).

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

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

Чтобы сохранить мотивацию, когда я делаю что-то новое, использую такой приём: записываю видео, в котором озвучиваю цели и мотивы текущих задач. Если через условные три месяца наступает момент, когда опускаются руки, просматриваю его. Если идея с видео вам не нравится, попробуйте написать вдохновляющее письмо.

Высшее образование и курсы

Я устраивался на работу много раз, переезжал между городами и даже странами СНГ. За всё время про диплом о высшем образовании у меня спросили всего дважды. Поэтому я бы не сказал, что это дает какое-то преимущество перед другими соискателями. На собеседованиях проверяют технические знания. Если их нет, никакой диплом не спасет.

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

Чтобы учиться на курсах эффективно, нужно смотреть вебинары, выполнять практические задания и (как минимум) читать первыессылкив Google или Яндекс по теме урока: это помогает немного расширить понимание пройденного.

Читать учебники перед началом обучения не стоит: они очень быстро устаревают. С момента написания книги до её попадания на полки проходит не один месяц. Её нужно отредактировать, сверстать, напечатать, выпустить на рынок. Лучше перед учебой (или одновременно с ней) читать официальную документацию выбранного языка или технологии. Например, вотсайт, на котором собран максимум информации для старта в JavaScript.

У нас на курсах есть задания для командной работы с несколькими разработчиками. Мы стараемся сделать программу максимально адаптивной. Каждый, кто прошел курс, может написать о нём и своём преподавателеотзыв. То, что присылают выпускники, не модерируется и всегда рассматривается отделом качества. Если его специалисты видят проблемы по какому-то предмету, они отправляют заявку, чтобы курс обновили.

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

  • Junior-frontendдолжензнатьhtml + css + js + react.

  • Junior-fullstack: html + css + js + php +базыданных.

  • Middle frontendразработчик: html + css + js + react + vue + node.js +команднаяразработка.

  • Middle-fullstack: html + css + js + react + php + laravel +базыданных+команднаяразработка.

Обучение веб-разработкена наших курсах длится от 5 месяцев. За это время можно получить базу junior-фронтенда. Чтобы изучить технологии, нужные для миддл-фронтенда, понадобится год. Освоение навыков миддла и для фронтенда, и для бэкенда требует 1,5 года. А дальше нужно идти в бой и набираться опыта, чтобы подтвердить этот статус в реальной работе.

Я преподаю фронтенд-разработку. Особенность курса в постоянной демонстрации практической составляющей, в каждом уроке показываю, как применять изученное. Мы даём прикладные знания, а все домашние задания связаны друг с другом. С 1 по 8 урок студенты постепенно разрабатывают готовый проект, и в итоге они успевают сделать пятистраничный проект интернет-магазина. Например, вот такого:

Как устроиться на работу и что от нее ожидать

Для работы необходимы общие знания по веб-разработке. Даже если вы учились фронтенду, на собеседовании придётся показать, что владеешь и бекендом. Например, спрашивают про PHP, а если ты его не знаешь, уточняют, готов ли подучить.

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

Джуну на первой работе можно рассчитывать на 4060 тысяч, миддл зарабатывает от 100150 тысяч. По сути, зарплата может быть и 200250 тысяч, но чтобы знаний хватило на зарплату миддла, нужно прилежно учиться не меньше полугода-года.

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

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

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

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

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

Подробнее..

Как джуниор Python-разработчику стать мидлом за год

23.12.2020 12:19:27 | Автор: admin
Привет! Я Рома, менеджер продукта в Яндекс.Практикуме, где развиваю курс Мидл Python-разработчик. Мы делаем из начинающих разработчиков крепких мидлов с инженерным мышлением. Сегодня хочу поделиться небольшими заметками о том, над чем стоит работать, если вы джуниор, который хочет стать мидлом.

Я не разработчик, поэтому эта статья во многом отражает взгляд со стороны. Ответить на вопрос Как джуниор Python-разработчику стать мидлом за год? не такая простая задача, как может показаться на первый взгляд. Здесь спряталось сразу несколько челленджей:

  1. Ответить на вопрос, кто такой джуниор: определить отправную точку, базу навыков, с которой мы будем рассматривать рост.
  2. Ответить на вопрос, кто такой мидл финальная точка нашего путешествия. Конечно же, во всех компаниях мидлы разные, а нам нужно какое-то взвешенное среднее, не оторванное от реальности.
  3. Ответить на вопрос, почему рассматриваем рост именно за год. Не ради красивой круглой цифры же, верно?

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

Почему в индустрии у всех разные взгляды на рост разработчика:

  1. Понимание грейдов джуниор-мидл-сениор и требования к кандидатам разнятся от компании к компании, а некоторые вообще говорят, что так разработчиков делить нельзя.
  2. Разные системы роста джуниор-разработчиков в разных компаниях (тут влияют не только требования по хардовым навыкам, но и корпкультура).
  3. Каждый мидл или сениор рассуждает на эту тему через призму своего опыта и своего пути роста.

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

И хотя статья больше про бэкенд-разработку на Python, я сделал упор на общеприкладных скиллах, а не на умениях работать с конкретными технологиями. Реальные требования к кандидатам в плане инструментов разработки сильно различаются в зависимости от компании и задач. Поговорим про фундаментальные навыки, которые актуальны для роста в других направлениях бэкенд-разработки и разработки в целом. Так что если вы не питонист не уходите, прочитайте до конца.

Какой ты джун


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

Юнлинг


Первый этап развития начинающего разработчика стажёр. Это ещё не полноценный джун скорее его MVP. На этом уровне человек знает основы языка, но практики программирования у него нет. Его не нужно учить синтаксису его нужно учить пользоваться языком, применять его в решении реальных задач. Чтобы дать стажёру задачу, нужно детально её расписать: сделай A, B и С, возьми такую технологию и используй вот этот приём.

Стажёры обычно не занимаются задачами, которые важны для проекта. Их бросают, например, на техдолг. Если накосячат, компания не потеряет деньги. Зато если исправят мелочи, на которые не хватает времени у более старших разработчиков, то принесут проекту много пользы. Попутно набравшись опыта.

Падаван


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

Давайте посмотрим на развитие этой стадии чуть подробнее.

Новичок


Разработчик, который буквально вчера принял своей первый оффер и уже жаждет влиться в команду и закрывать таски. Джун-новичок обладает достаточным набором академических знаний, чтобы выполнять простые задачи. Он умеет работать с документацией и может вытащить оттуда что-то полезное. Но знания процессов разработки больше теоретические, что приводит к ошибкам на разных стадиях написания кода. На этом этапе развития человек всё ещё учится тому, как применять язык для решения коммерческих и прикладных задач. Нормально, что он приходит к старшим коллегам и говорит: У меня что-то ломается. Не могу это сделать. Помоги! Ведь лучше задать вопрос, чем уйти в себя, не показать никакого результата и подвести команду.

Обыкновенный


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

Но как только готов план, вы можете жить в нём как минимум в рамках одного рабочего дня с вами не нужно заниматься микроменеджментом. Вы начинаете понимать, какие проблемы сможете затащить своими силами. Всегда стараетесь достигнуть результата самостоятельно, изучая документацию, и идёте к тимлиду уже с более глубокими вопросами, чем просто: Не работает не знаю, что делать. Здесь должно появиться: Я попробовал то и вот это, но не получилось. Нужна помощь, чтобы понять, почему так происходит и где ещё поискать решение.

Крепкий


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

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

Рыцарь-джедай


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

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

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

Резюме роста




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

Представьте, что вы попали в исследовательский центр Британской Секретной службы в качестве инженера. Вашей команде нужно разработать машину для одного известного любителя коктейлей. Грейды инженеров в британской разведке такие же, как у нас в разработке: джуниор, мидл, сениор, тимлид, CTO.



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

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

Мидл не будет продумывать архитектурные проблемы как его система катапультирования будет связана с другими системами машины или какие технологии и материалы ему использовать. Проработку этой части возьмёт на себя сениор.

Тимлид возьмёт на себя ответственность за развитие какого-то значимого направления разработки машины. Система катапультирования является одной из боевых функций машины. Но ещё есть ракеты, автоматы в фарах или даже боевые лазеры. Нужно продумать, как все системы будут взаимодействовать между собой. Задать правильные вопросы команде и поделиться своим опытом и знаниями, чтобы она пришла к хорошему архитектурному решению. А ещё на реализацию всего этого безумства нужно найти людей, организовать их работу и выдержать поставленные сроки.

И вот мы добрались до вершины CTO или, на местный лад, Q. Он определит общие технические требования к машине, включая специфические. Он тесно общается с заказчиками руководством Ми-6 и самим Бондом. Поэтому знает, что спорткар должен уметь превращаться в подводную лодку, чтобы миссия прошла успешно.

Мой выбор


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

Харды


Подобрались к самому интересному. Как и обещал, будет про технологии, но без конкретных названий.

Итак, на что стоит делать упор в своём развитии? Вот шесть главных аспектов.

  1. Прокачивайте понимание, как работают технологии, которые вы используете
    Мидлу должны быть понятны те инструменты, которые он ежедневно использует. Джуниор-разработчику простительно просто писать код, который решает задачу, и не задумываться, как работают те или иные конструкции языка. Но если ты мидл, разработка не может быть для тебя магией.
    Важно задаваться вопросом, как работает код, который ты пишешь. Хорошо, если вы умеете объяснить принцип работы технологии или написанной программы другому человеку простыми словами.

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

    Скорее всего, даже три из пяти почему заставят вас достаточно глубоко покопаться в теме и дадут хорошее понимание исследуемого инструмента.
  2. Учитесь декомпозировать задачи
    Когда начинающий разработчик получает задачу, у него есть соблазн сразу начать писать код. Из-за этого структура его решения выстраивается хаотически. Учитесь сначала продумывать ход решения в голове, строить архитектуру, а только потом кодить. Стройте связи: Я буду решать задачу вот таким образом, потому что <причина 1>, <причина 2>. А вот здесь у меня такое техническое требование, поэтому я буду использовать <приём 1>, <приём 2>.

    Как улучшать навык
    • Учитесь выделять в задаче самое главное. Не гонитесь за идеальным решением сразу вначале просто сделайте рабочее решение. Когда оно будет готово, ненадолго остановитесь, вы молодец. Самое время подумать, как можно улучшить это решение сделать его более грамотным и оптимальным. Важно: что такое рабочее и грамотное решение, важно определять в самом начале, на этапе проработки задачи.
    • Выстраивайте для себя граф будущего решения с обоснованиями своих решений в ключевых точках. Это не только повышает качество вашего кода, но помогает защищать свой код и идеи перед коллегами.

  3. Проходите и проводите code-review
    Первый этап научиться правильно проходить код-ревью. Это софтовый навык: нужно уметь слушать обратную связь, не принимать критику кода как личную обиду и доставать из ревью полезные для себя вещи.

    А вот проводить ревью это уже следующий уровень, который должен освоить мидл. Когда к вам попадает код другого человека, в первую очередь вы должны понять структуру программы на верхнем уровне. Отталкиваясь от этого, вы сможете подсказать человеку, что нужно исправить и улучшить.

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

    Как улучшать навык
    • Если у вас на работе нет культуры код-ревью, найдите человека уровнем выше, чем вы. Попросите его давать обратную связь по тому, что вы пишете. Иначе вы не поймёте, хорошо ли то, что вы сейчас делаете.
    • Проводите селф-ревью. Возвращайтесь к своему коду, думайте, какие есть ещё решения у задачи. Как выбрать между несколькими возможными вариантами решения. Нашли решение лучше перепишите, проверьте свои догадки. Бывает полезно проводить селф-ревью в интерфейсе git уже после того, как вы оформили изменения в merge request. Смена обстановки поможет взглянуть на проделанную работу по-новому.
  4. Подучите алгоритмы
    Да, я уже чувствую ваш скепсис. Ещё бы человек из Яндекса не посоветовал учить алгоритмы.

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

    Как улучшать навык
    • Самый простой путь просто решать задачи на алгоритмы. Их много, например, на Leetcode. Если алгоритмы вам нужны в первую очередь для прохождения собеседований, это верный путь достичь своей цели. Если для общего развития, то не забывайте про связь с практикой. Просто нарешать 100 задач будет не так полезно, как глубоко обдумать практическое применение 510 из них.
    • Посмотрите курс Максима Бабенко Алгоритмы и структуры данных поиска. Это правда стоит того: многие идут в ШАД именно ради курса Максима по алгоритмам.
    • Почувствуйте, что решать алгоритмические задачи может быть интересно и несложно. Вот наш разбор задачи по алгоритмам в помощь вашей мотивации.
  5. Развивайте насмотренность
    Чтобы быть классным разработчиком, нужно знать, что сейчас происходит в индустрии. Чтобы принимать правильные решения в своих задачах, нужно увидеть как можно больше хороших решений других разработчиков. Хотя не только хороших решений ошибок тоже

    Знаете, почему сениор может сразу написать классное решение? Потому что он за свою карьеру совершил много ошибок. Много-много раз сделал что-то неправильно и теперь знает сотню способов, как делать не надо. Начинающий разработчик, наоборот, знает только несколько способов сделать так, чтобы работало.

    Как улучшать навык
    • Не бояться совершать ошибки. Насмотренность приходит с опытом, её можно приобрести только практикой. Делайте ошибки и изучайте опыт своих коллег.
    • Пилите собственные проекты с технологиями, с которыми бы никогда не столкнулись на основной работе. Новый язык, база данных, фреймворк всё это расширяет ваш кругозор и пополняет багаж знаний.
    • Изучайте публичные кейсы компаний, где они рассказывают о своих ошибках или, наоборот, о достижениях в решении сложных задач.
  6. Учитесь писать скучный код
    Когда пишете код, думайте, насколько он будет понятен человеку, который в первый раз его увидит. Хотите внедрить нетривиальное и нестандартное решение трижды подумайте. Я один раз услышал очень хорошую фразу, которая показывает всю ценность этого навыка. Делюсь ей с вами: Чем скучнее и понятнее ваш код, тем меньше вероятность, что вас поднимут в час ночи и заставят его чинить.


Софты


Фуух, с хардовой частью разобрались. А что там про софты? Что это за зверь и зачем он нужен разработчику?

Ловите ответы. Софты это все навыки, которые вам нужны в работе, не связанные напрямую с написанием кода. Недобор по софтам может нивелировать всю вашу гениальность в разработке.
Мягкие навыки важны, потому сейчас настали времена командной, а не одиночной разработки. Чтобы выводить на рынок хорошие технические решения и делать это в требуемые сроки, сил одного человека уже недостаточно. Команда разработчиков на длинной дистанции всегда обгонит гения-одиночку.

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

Про умение коммуницировать, наверное, и так все наслышаны. А что ещё из мягких навыков может понадобиться в разработке?

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

    Мидл может взять таск, где есть несколько активностей, разложить их в план и приступить к работе. Над ним нужен контроль только из серии Как у тебя дела? Что ты делаешь сейчас?
  2. Научитесь видеть проблему бизнеса в технической задаче
    Помните, что на самом деле ваша задача не просто написать код. Код всего лишь инструмент. Вы как разработчик должны делать техническое решение для задачи бизнеса. Учитывайте это, когда продумываете своё решение и оцениваете его оптимальность.

    Иногда важно аргументировать, почему не нужно делать задачу, которую вам поставили, а не бросаться писать код. Например, если вы видите, что на реализацию текущих требований команда потратит очень много ресурсов и есть более простое и дешёвое решение. Учитесь получать информацию по задаче от нетехнических коллег и объяснять им технические ограничения.
  3. Показывайте увлечённость разработкой
    Никому в команде не нужен человек, который не мотивирован делать то, чем он сейчас занимается. Учитесь рассказывать интересные истории о своей работе и достигнутых результатах. Говорите о том, почему вам интересно было заниматься тем или иным проектом.
    Грустно, когда на собеседовании задаёшь вопрос: Расскажите, чем вы занимались на прошлой работе?, а кандидат отвечает: Ну я решал задачки, писал код. Был Джанго, писали на нём небольшой сервис. Часто делал простые задачки с данными. Рассказывайте про свой опыт через призму того, почему у вас была мотивация его получить, и какие выводы вы для себя сделали.

    Если про работу сложно рассказать что-то интересное, используйте собственные проекты. На работе решал стандартные задачи на Django, а вот в собственном проекте недавно попробовал FastAPI. Классный опыт, потому что <причина 1>, <причина 2>. По-новому взглянул на <приём в разработке 1> и <приём в разработке 2>. Вот это уже хочется обсудить с человеком.


Саммари


  1. Чётких грейдов разработчиков в индустрии нет, и это нормально: разные команды выдвигают разные требования в зависимости от своих задач.
  2. Тем не менее можно выделить критерий вашего роста как разработчика ответственность и сложность задач, которые вы можете решить самостоятельно.
  3. Мидл должен быть самостоятельным разработчиком и решать большинство падающих на него задач без помощи старших разработчиков.
  4. Опыт работы с конкретными технологиями часто не так ценен, как фундаментальные навыки. Если вы глубоко разбираетесь в технологиях, с которыми уже работали, и показываете способность и желание быстро изучать новые этого часто достаточно, чтобы попасть в компанию, где ваш опыт не покрывает весь стек технологий.
  5. Изучайте чужой код, пробуйте новые технологии, не бойтесь совершать ошибки. Это поможет вам развить насмотренность и профессиональный кругозор.
  6. Сейчас век командной разработки, поэтому софты не менее важны, чем харды. Компании дешевле подтянуть нового сотрудника по техническим навыкам, чем вписывать в команду некомандного человека.
  7. Подходите к своему развитию осознанно. Выбирайте место работы, отталкиваясь от людей, с которыми вы хотите работать, и задач, которые вас драйвят. Стройте процесс учёбы и получения новых знаний так, чтобы он приносил удовольствие. Например, мы с командой обожаем кино, поэтому построили курс вокруг разработки онлайн-кинотеатра, аналога Netflix (да, отсылки к фильмам в этой статье не случайность). Подумайте, что может дать вдохновение вам?
Подробнее..

Как вырастить веб-разработчика от стажера до архитектора. Матрица компетенций

03.09.2020 12:19:11 | Автор: admin
Вместо эпиграфа
Когда в 2004 году я окончил университет, в нашем городе почти не было команд разработчиков.
Где работать, у кого набираться практического опыта?
Выбор был прост: админом или в Москву. Или уйти из профессии.
Сейчас я преподаю веб-разработку в местных ВУЗах, руковожу большим коллективом и мне важно, чтобы в моем городе хотели жить толковые молодые ребята, чтобы наш город не считался тухлым местом.

Суть статьи коротко


Мы с коллегами умеем растить веб-программистов с почти нуля до уровня уверенного профессионала (Senior / Архитектор).
Хотим рассказать как все работает и поделиться с сообществом материалами и методикой.

Статья написана для студентов, начинающих и растущих веб-разработчиков.

Далее описан трек развития веб-разработчика, уровни компетенций Стажер, Junior, Middle, Senior и Architect, как я их вижу и даны примеры аттестационных заданий.

Пирамида способностей программиста или что качать на старте


Как стать хорошим веб-программистом? Нужно ли заканчивать информатику в хорошем ВУЗе? Или хватит месячных курсов? Или с книжкой и мышкой все можно изучить?

Три кита, на которых стоит профессия любого разработчика на любом стеке технологий, это алгоритмизация, базы данных и собственно программирование (язык + ООП + паттерны).
image

Что такое алгоритмизация?


Близкий житейский аналог технического навыка алгоритмизации ремонт вентилятора. Что делать, если не крутится? Проверить/сменить розетку, потом рукой крутануть лопасти, потом прозвонить провод.

Логика очевидна: разделил на части и проверил каждую. Удивительно, но многие люди не умеют так мыслить. У настоящего программиста это в крови.

Базы данных


Курс БД один из основных, как физика для инженера. Плохо что часто преподают их одинаково плохо: сводят к пересказыванию параграфов.

В БД важны и теория, и практика. Программист должен уметь и писать запросы, и разбираться в логике ORM, и проектировать структуру.

Какие технологии нужно знать программисту?


Из чего вообще состоит профессионализм разработчика?
Указано примерное время освоения при классическом пути развития (начиная с ВУЗа).

Пирамида.png

По уму алгоритмизации учат в школе/ВУЗе. Тратится на это 1-2 года, и этот период определяет высоту будущего профессионального взлета. Если вы не освоите алгоритмизацию, то никогда не вырастете.

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

Фреймворки часто включают сотни модулей/классов/расширений и постоянно развиваются. Освоение фреймворка займет у вас несколько месяцев как минимум.

Многие самоучки идут по легкому, но неверному пути: вместо алгоритмизации начинают учить фреймворк. И уже через пару месяцев практики заявляют что умеют программировать. Серьезные собеседования они проваливают уже через 10 минут после начала.

Конкретные технологии (например AJAX, серверный рендеринг JS, push&pull, распределение нагрузки по гео-кластеру, профилировка долгих запросов в xhprof, очереди сообщений, NoSQL базы данных) бесконечно разнообразны. Учить их можно вечно.

Эту пирамиду нужно проходить снизу вверх. Если вы начнете с фреймворка и напишете красивое резюме, но не будете знать как работает голый JS или чем get-запрос отличается от post профи вам не быть.

Какие задачи нужно решать?


Первый этап старт. Сначала нужен навык уверенного и правильного решения относительно простых задач. Чаще всего это игровые, математические или логические задачи.

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



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

Такой метод обучения у медиков называется методом свинцовой ж*пы. Простите за грубость, но из народного творчества слов не выкинешь.

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

Это очень сложный переход. Многие программисты не делают его никогда: они становятся разработчиками одной программы или всегда пишут проекты не более чем в 200 строк. Это не уровень профи.

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


Большие задачи реальные сервисы, которыми пользуются люди, где команда состоит минимум из 2 человек, и состоящие из тысяч строк кода. Такие проекты формируют уверенного специалиста.

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

Более сложная и более полезная книга Шаблоны корпоративных приложений Мартина Фаулера. Ее тоже нужно прочитать, примерно через год-полтора работы в профессии.

А зачем? Можно просто закончить 3-месячные курсы веб-разработчика?

Удивительно часто на собеседование приходят как бы программисты. У них за плечами курсы, несколько мест работы, портфолио с красивыми сайтами (странная манера, как будто мы ищем веб-дизайнера).

При этом на простейший вопрос типа что такое cookies или как работает подгрузка сообщений в ленте ВКонтакте люди часто не знают ответа, у них даже версий толком нет.

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

Как получить эту базу? Где правильно учиться? Есть два пути.
Первый 4-5 лет в хорошем ВУЗе.
Второй несколько лет упорного самообучения и практики. Можно стать сильным программистом без профильного образования, если у вас светлая голова, открытое сердце, а вы сами готовы много работать.

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

Матрица компетенций. Стажер Junior Middle Senior Architect


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

По ссылке доступна полная матрица с примерными вопросами по аттестации.

Это таблица, разделенная на грейды (стажер, junior, middle, senior). Каждый грейд содержит набор уникальных компетенций. Вопросы сгруппированы по областям знаний (PHP, SQL, Frontend, веб-технологии в целом и управление серверным хозяйством)

Стажер

На старте стажер должен быть способен:
  • уверенно отличать куки от сессий;
  • понимать на сервере или в браузере происходит конкретная операция;
  • написать на PHP без серверных фреймворков несложную задачу управления данными. Например ведение БД групп и студентов с редактированием, удалением, созданием и выводом;
  • прилично оформить результат своей работы.

Стажер учится. Его главная задача набираться знаний, решать задачи под присмотром, и набивать шишки.
Почти каждый стажер удаляет базу, промахивается окном или решает заново давно закрытую задачу. Разумеется, 6ез вреда для боевых проектов.
Ошибки нормальная часть обучения.

Junior

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

Что практически должен уметь Junior на старте:

  • переписать (а значить досконально понимать) авторизацию на сайте;
  • уверенно править настройками и кодом фреймворка работу каталогов, ленты новостей, формы;
  • собирать простые интерфейсы управления данными и целые сайты на фреймворке;
  • писать простую интеграцию с внешним API.

Middle

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

Что практически должен уметь Middle на старте:

  • работать с внешней авторизацией (войти через внешний провайдер или сделать свой код провайдером авторизации);
  • уверенно программировать интерфейсы публичных интернет-магазинов, маркетплейсов или интранет-порталов (в зависимости от специфики);
  • собирать сложные интерфейсы управления данными и разделы на фреймворке;
  • писать сложные интеграции с внешним API, реализовывать веб-сервисы.


Senior

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

Вот например, что сам Senior должен знать и уметь по блоку Работа с серверами и Linux.

  • Сборка нетиповой системы выкатки изменений
  • Работа с микросервисами.
  • Организация нагрузочного тестирования
  • Настройка continuous integration
  • Синхронизация файлов и репликация данных
  • Сборка отказоустойчивого и высоконагруженного кластера на Bitrix Framework и без него.
  • ELK / другие системы логирования и аналитики
  • Серверы очередей Gearman / RabbitMQ и построение распределенных систем

Как правило, Senior играет роль технического лидера группы разработчиков.

Architect

Архитектор следующий уровень развития специалиста, когда он продумывает архитектуры крупных проектов и руководит их реализацией. Он не только технический, но и проектный руководитель.

Такие специалисты играют ключевую роль в технически и организационно сложных проектах.

Качество архитектора определяет способность проекта выполняться в срок и развиваться много лет подряд.

Управление развитием программиста

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

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

Как устроена проверка уровня (аттестация)?

Что такое аттестация?
Это процедура подтверждения квалификации программиста. Ее проходят все программисты.
Аттестация включает лабораторные работы и устные экзамены.

В результате аттестации в матрице компетенций появляются Да напротив подтвержденных компетенций. От этого увеличивается грейд, например, Стажер-54% Junior-27%.

Как проходит аттестация?

Аттестация включает теорию (устный экзамен) и практику (лабораторные работы). Цель закрыть несколько компетенций в матрице, подтвердить уровень, получить новые задачи и повысить зарплату.

Практические задания можно сделать правильно только если изучить и понять теорию. Списывать и хитрить не принято, и наставник не пропустит халтуру.

Многие блоки матрицы компетенций закрываются практикой и теоретических вопросов по ним нет.

Теория. Устный экзамен

Компетенции, не покрытые лабораторными работами нужно подтвердить на устном экзамене.

По каждой компетенции мы задаем около 5 вопросов. По-хорошему ответить надо на все или почти все. Длительность устного экзамена зависит от уровня, обычно это 1-2 ч.

Практика. Лабораторные работы

Лабораторная работа покрывает сразу несколько компетенций. После выполнения лабораторной работу эти компетенции засчитываются как подтвержденные и не попадают в устный экзамен.

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

Примерные формулировки заданий

Мы разработали около 20 заданий (называем их привычно для студентов лабораторные работы). Несколько опубликуем.

Вот примеры простых заданий.

Задание 2а. Базовый web. Реализуем CRUD на чистом PHP.

Компетенции:
  • PHP: Аутентификация и авторизация на сайте
  • PHP: Обработка форма обратной связи с сохранением данных и валидацией
  • Фронт: Создание форм на html
  • Фронт: Синтаксис и селекторы CSS, общее представление о весах селекторов
  • SQL: Основы Mysql
  • SQL: Типы данных
  • PHP: Синтаксис языка PHP

Суть:
  • завести репозиторий на bitbucket и выполнять в нем;
  • сразу сделать ветку и pull request;
  • в PhpStorm установить плагин Statistic, максимальное кол-во строк на весь проект 1500:
  • через PhpStorm создать необходимые таблицы и заполнить их данными;
  • сделать страницу аутентификации;
  • сделать страницу с формой обратной связи, на которой есть: текстовое поле, многострочное текстовое поле, радиокнопки, флажки, выпадающий список, кнопка сброса формы, кнопка отправки формы;
  • форма обратной связи доступна только авторизованным пользователям, критерий допуска вход в систему выполнен;
  • все красиво сверстать, показать пример использования основных типов селекторов: id, class, attribute, pseudo-class, pseudo-element;
  • обе формы должны обрабатываться без JS;
  • проверить через PhpStorm, что данные добавляются в таблицу.


Проверка:

  • проверяется качество декомпозиции php, js, css;
  • умение выделить ответственность и установить правильные зависимости между компонентами MVC/ECB;
  • безопасность (доступ);
  • безопасность (XSS, SQL injection);
  • корректность редиректов;
  • единство стиля оформления кода.


Развитие задания

Задание 2б. Развитие CRUD-интерфейса на PHP.

Компетенции:
  • 3 способа подключения скрипта
  • Создание форм на html
  • Синтаксис и селекторы CSS, общее представление о весах селекторов
  • JS: операторы, функции
  • Отладка JS с помощью консоли браузера
  • Основы Mysql
  • Типы данных


Суть продолжаем работу над сайтом из задания 2а:
  1. сделать мини-админку:
  2. список отправленных форм обратной связи;
  3. список должен быть отсортирован по дате отправки, новые сначала;
  4. список можно обновить, это делается с помощью AJAX;
  5. совет: для интерактивного тестирования запросов к БД используйте консоль БД в PhpStorm;
  6. отправленную форму можно удалить из админки, все на AJAX;
  7. таким образом продемонстрировать все способы подключения JS;
  8. отправленные данные можно отредактировать (использовать уже разработанную форму, без AJAX);
  9. можно использовать jQuery.
  10. открыть инструменты разработчика (желательно Firefox):
  11. найти источник запроса из лога запросов;
  12. установить точку останова, спровоцировать выполнение кода, изучить пошаговое выполнение кода;
  13. во время пошагового выполнения просмотреть значения переменных через соответствующий инспектор;
  14. добавить watch;
  15. воспользоваться консолью для доступа к переменным в текущей области видимости.
Проверка:
  1. проверяется качество декомпозиции php, js, css;
  2. умение выделить и установить правильные зависимости между компонентами MVC/ECB;
  3. безопасность (доступ);
  4. безопасность (XSS, SQL injection);
  5. единство стиля оформления кода;
  6. все пункты по использованию инструментов разработчика продемонстрировать.


Вот пример средней сложности

Задание 10. Парсинг сайтов

Компетенции:

  • Регулярные выражения
  • HTTP-запросы с сервера, cURL
  • TODO: написание консольных утилит (и одноразовых скриптов) на кодовой базе Bitrix Framework
  • TODO: добавить CRON


Суть:

  • Проанализировать сайт, продумать структуры данных, пригодные для автоматизированной обработки
  • Распарсить сайт в эти структуры
  • Оформить в виде CLI-скрипта
  • Настройками реализовать возможность парсить не все подряд, а только то, что нужно пользователю


Проверка:

  • корректность CLI-окружения
  • декомпозиция регулярных выражений
  • экономичность по запросам
  • обработка ошибок
  • возможность параллельного парсинга нескольких объектов сразу
  • Работа в консольном и интерактивном режиме
  • *работа в режиме внешнего сервиса, доступного по HTTP, с поддержкой очередей



Посмотреть и скачать матрицу компетенций 2020

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

Бинарная оценка профессиональных навыков

01.04.2021 14:11:52 | Автор: admin

Совсем недавно я начал задумываться: А как понять, что твой уровень знаний достойный?. И здесь закономерно приходит в голову мысль, что для оценки нужны какие-то критерии, но давайте не будем углубляться в подробности, а сразу перейдем к стандартным градациям: Junior, Middle, Senior. Похожие используются в размерной сетке одежды, они достаточно просты и понятны. Может поэтому мы их так любим? Но на практике, оценка градации может быть очень сильно искажена оценщиком. Ведь за каждым лейблом находится большое количество метрик, которое для нас любезно рассчитывает производитель одежды и маркирует. Но стоит отметить, что не всегда все проходит гладко. Что уж говорить об оценке профессиональных навыков...

Давайте пойдем дальше и упростим нашу оценку. В итоге мы получим бинарную оценку: Подходит/Не подходит, она максимально проста и существенно снижает вероятность ошибки.

Об одной из таких оценок, на реальном примере, я бы и хотел вам сегодня рассказать.

В 2002-2006 годах я активно играл в Counter-Strike 1.6 (CS). На тот момент я был одним из лучших игроков в Сибирском регионе. И так случилось, что в колледже, где я учился, решили провести чемпионат по CS. О турнире я узнал случайно и конечно же захотел принять участие в нём. Как оказалось, этот турнир был не первый, а ранее уже организовывался, но я об этом не знал.

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

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

Кроме подключения манипуляторов, я также принес с собой 3,5 дюймовую дискету, на которой был файл конфига (осуществляет биндинг клавиш). Моя конфигурация была не типичная и отличалась от стандартной. Использование конфига позволяло мне экономить время на настройку и уделить больше внимания разминке.

Я скопировал конфиг в папку с игрой и загрузил. Привел в порядок настройки операционной системы (чувствительность мыши, настройки видеокарты) и вот я был готов. Началась игра. Формат игры был 3х3, поэтому мы без особого труда вели в счете с нулевым результатом для соперника. У меня даже не было смертей, а количество фрагов сильно переваливало за десяток. Мне казалось, что всё идет отлично, но были и те, кто думал по-другому

И вот в один момент заходит преподаватель, который привез команду противника, они были из области. Он стал говорить, указывая на меня пальцем: Он принес дискету, на ней читы, я видел как он их скачивал!. Я пытался возразить, протягивал ему дискету, чтобы он мог проверить, что на ней только конфиг и больше ничего нет, но он был непреклонен. Организатор турнира, выхватил дискету из рук, смял и выбросил её в мусорное ведро, а меня отстранили от участия.

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

С тех пор я научился устанавливать управление достаточно быстро, без использования конфига. Я начал использовать консоль для биндинга клавиш и любое управление я мог настроить себе просто, вводя команды в консоль. А с какого-то момента мне и вовсе показалось использовать интерфейс неудобно, а конфиг я начал воспринимать как рудимент. Так я перестал пользоваться интерфейсом для выставления управления, но ручной биндинг тоже давал свои сбои в игре. Например, в самый неподходящий момент можно было обнаружить, что бинд на разминирование бомбы (один из ключевых элементов в CS) мог отсутствовать. Здесь главное, чтобы времени было достаточно для того, чтобы открыть консоль и написать bind t +use и все было в порядке, но это совсем другая история.

Подводя итоги, очевидно, что оценка профессиональных навыков даже в бинарном формате может быть неверной. Наверняка моя ситуация не является уникальной. Я не берусь судить о мотивах такой оценки или пытаться найти какие-то критерии. Убежден, они будут очень сильно зависеть от личности человека, который ее осуществляет. Мне интересно узнать как вы поступаете в ситуациях, когда получаете очевидно ошибочную оценку. Идёте до конца или же уходите в сторону?

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru