NMNH

Фриланс для меня всегда был местом, где я искал (и находил) проекты, чтобы попрактиковаться. Начинал я с самого простого, научился печатать вслепую - занимался транскрибацией аудио в текст, потом начал изучать фотошоп и брался за проекты, связанные с обработкой фото. Когда изучал php тоже брал проекты, которые мне уже было под силу выполнить, чем больше знаний, тем сложнее проекты. Сначала это были всяческие настройки форм обратной связи, устранение мелких багов и т.п. Потом сложнее и сложнее, например, разработка сайтов, CRM систем и т.п. То же самое с фронтендом и со всеми остальными технологиями, которые я изучал. Соответственно чем больше опыта, тем выше цены.
А заказчики есть совершенно разные - тем, кому нужно качество, будут выбирать по портфолио и более опытных специалистов. А те, кому нужно быстро и дешево обычно понимают, что будут работать с новичками.

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

MongoDB

Выбросте эту мысль из головы. Возьмите PostgreSQL или на худой конец MySQL. Монгу можно как дополнительный инструмент но ни в коем случае не как основной. Это резко сужает возможности разработчика и для большинства задач увеличивает сложность.

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

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

Была у меня задача где монга с шардингом подошла идеально - сбор и архивирование логов действий пользователей. Были десятки миллионов действий в день. Тут понадобилась и гибкая структура и легкий шардинг на запись. Шардили коллекции по дате записи. TTL не использовали.

Высокопроизводительные распределенные интернет-приложения. Конкретные примеры: amazon.com, netflix.com, ebay.com. NoSQL движение возникло как ответ на проблемы масштабируемости. Реляционные базы ориентируются на требования ACID и как следствие имеют проблемы с горизонтальным масштабированием. Для таких баз необходимо реализовывать шардинг на уровне приложения. Но тогда будет необходимо отказаться от ACID, объединения таблиц и контроля целостности. В таком случае реляционная база теряет все козыри перед NoSQL. Но оставляет на плечах разработчика заботу о шардинге.

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

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

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

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

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

ИМХО
1) Обо мне – не стал бы писать, кому какая разница какой я коммуникабельный, проактивный и эмпатичный человек. Лучше привести примеры работы с ссылками на сайты и с подробно расписанными кейсами. Не просто простыня из рендеров страниц, а подробное описание: Цель, задачи, трудности, как решил, какой стек, результаты работы. Условно, можешь это писать на каком-нибудь medium и просто подтягивай на страницу портфолио. (Medium.com явно будет индексироваться лучше, чем твой сайт)
Еще прикрепи свой github и активно веди его, отмечай какие-то свои находки, веди проекты, разрабатывай инструменты для сообщества и так далее.
Да, контакты тоже нужно не забыть прикрепить.
2) Всё, что не стесняешься приложить (телеграм, почта, социальные сети) [почтовый адрес не надо]
3) Ты конечно можешь сделать "просто и понятно как у эпл", но зачем. Сделай как тебе нравится и как тебе хочется, ведь к тебе придут люди предложить работу и лучше пусть их зацепит то, что нравится тебе, тогда ты будешь кайфовать от работы.

PHP - по количеству заказов явный лидер, я работаю на нем (в основном на framework yii2)
Python - меньше заказов, но и конкуренция меньше, более интересные, но и сложные проекты, чем на php. На php горы однотипного барахла, где работа больше на усидчивость, чем на подумать.
Node.js - не юзаю, и знаю краями, поэтому воздержусь от комментариев