frontender

Посмотрите здесь. Там, правда, предлагают писать на ROR, но всё перечисленное в статье можно писать на чём угодно. В том числе и на node.js

Есть прикольное задание, которое нашел как-то на просторах интернета:

Управление виртуальным центром запуска ракет.
Есть несколько баз (при запуске сервера они "создаются" заново).
Нажимаешь кнопку, выбираешь цель и ракета летит, транслируя свои координаты на клиент (+ оставшееся время).
В момент полета может произойти авария и ракета не долетит, надо чтобы это выводилось пользователю в браузер.
Когда ракета долетает, то базе наносится урон (вычисляется случайно). Когда у базы жизней < 0 игра считается завершенной и пользователю об этом показывается сообщение при загрузке страницы.
Все это на сервере работает через JSON, а на клиенте через react/angular/custom и обновляется в реалтайме через long-polling или websocket.

интерфейс - просто выпадающий список, а после нажатия на кнопку один див с координатами, второй с оставшимся временем.

Для того чтобы повысить свой уровень, нужно найти свои недостатки.
Из-за этого я составил карту развития веб-разработчика https://github.com/zualex/devmap

Как мне кажется путь повышения своего уровня индивидуален. Опишу как было у меня

1) Работал в веб-студии, клепал сайты один за одним, стало очень скучно, возомнил себя крутым и решил пойти на повышение, после первого собеседования понял что я никто)
Level up - осознания того что ты не крут

2) Стал изучать и самое главное применять новые для меня технологии: git, laravel, gulp и т.д. Изучал постепенно, не набрасывался на всё сразу, что-то отпадало, что-то становилось бесценным инструментом.
Level up - осознание что нужно постоянно развиваться

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

4) Спустя время понял, что достиг потолка, начал ходить на собеседования, выявлялись разного рода недостатки.
Level up - ходить на собеседования

5) Новая работа, где устроенно все по другому (в хорошем смысле), новая команда, новые испытания
Level up - выход из зоны комфорта

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

TL;DR: Читайте книжки, делайте дела, читайте чужой код.

Что можно начать делать прямо сейчас, чтобы стать программистом лучше?

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

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

3. Написание кода - не самая большая часть работы сеньор-девелоперов, я бы сказал. Но когда речь заходит о самом коде, нужно понимать что ты пишешь и зачем. Есть классические книжки, которые можно найти, например, в матрице компетентности программиста, есть современные, но полезные типа The Art of Readable Code, которую я очень рекомендую. Нужно читать книжки. На собеседовании я всегда спрашиваю какие книжки читал или читает соискатель и если ответ отрицательный, то это большой минус.

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

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

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

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

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

В вакансии у нас указана реальная вилка ЗП и от того сколько человек получал на предыдущем месте ни эта вилка, ни условия не изменятся. Девушка однажды пришла на собеседование так же на 25-30, сказала на предыдущем месте работы 200 получала, на джипе приехала ))

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

Лично у меня код вида

setupList();
showListProgress(true);
getTaskList();

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

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

Здравствуйте!

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

Сам задавался таким вопросом и посоветовали "Выразительный JavaScript", автор - Марейн Хавербек, можно на торрентах найти PDF.
Ну и learn.javascript.ru

«JavaScript. Шаблоны» С. Стефанов