Как собрать портфолио для back-end разработчика?

Question

[Vania Kovmir]

Как собрать портфолио (или то, чем можно аргументировать свою кандидатуру) для back-end разработчика?

Comments

[Сергей Горностаев]

Делаешь работы, добавляешь их в портфолио. Что тут может быть непонятного?

[Андрей Шишкин]

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

Answer 1

[Роман Булгаков]

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

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

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

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

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

Comments

[Андрей Титов]

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

[Роман Булгаков]

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

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

Если же у вас прямо стояла цель сделать систему способной обеспечивать какую то обработку (обязательно описать какую) и добиться при этом хорошей производительности - то я бы предпочел увидеть не график в вакууме а описание:

мол стояла задача сделать/улучшить такой то сервис выполняющий такую то функцию и вот в прототипе в лоб у меня было 10 RPS макс а я добился 10-100-1000 кратного роста RPS за счет оптимизации/рефакторинга/скалирования или чего еще - и вот у меня теперь система умеет 10000RPS"

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

Нагрузочное тестирование и понятие того за счет чего выигрыш - это объемная тема.
То есть графики как бы вам использовать никто не запрещает - но что бы отразить главный показатель (утрированно) - 2 числа до и после - в этом нет большого смысла. Гораздо важнее понимание специфики (вами) какой то конкретной проблемы которую вы решили за счет чего повысилась производительность (и повысилась ли она вообще?) и донесения факта того что вы смогли понять/улучшить/переделать в вашем портфолио.

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

И совсем другое дело - если скажем я заявлю что:

вот был сервис, который предположим кропает картинки и _при тех же костах за хостинг_ я добился увеличения производительности в 3-5-10 раз за счет того что допустим переписал/оптимизировал/заменил библиотеку которая собственно занималась кропом.

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

[Роман Булгаков]

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

например есть пакет uvloop для Python - они переписали eventloop под asyncio на libuv - и получили 2х кратный прирост производительности в задачах связанных с I/O. и вот они на целую статью накатали объяснений - вот мы используем это и вот такие задачи у нас выполняются быстрее вот в таких то условиях.
- и там есть графики сравнения - под каждый тип задач.

Т.е. как я и говорю - там объяснена природа проблемы, что сделано для оптимизации и в каких условиях это работает и как тестировалось. - там графики являются наглядными.
Вот та статья - https://magic.io/blog/uvloop-blazing-fast-python-n...