Lo-fi

Web перспективнее для фриланса. Да и вообще.

Оборонка, микроконтроллеры, хех =))
Что насчет темной стороны силы? Писать руткиты и бомбить в 0day-дырки может быть насколько опасно, настолько и увлекательно. Главное сильно не перестараться обчитавшись журналом ][akep или что там сейчас в тренде/школе.
Студент же, из-за наличия относительно большого кол-ва свободного времени, может с легкостью удариться и во что-то далекое от мейнстрима, вроде VxWorks или QNX. Вот прям сходу конечно денег не приносит, но при должном уровне стараний кто знает...
Ну а более приземленные варианты – найти что-то по душе в мире open-source и развиваться в направлении вакансий вроде этого:
www.softeq.by/career/vacancies/firmware-developer
www.softeq.by/career/vacancies/VHDL/Verilog-Specialist
www.softeq.by/career/vacancies/embedded-system-sof...

Не вижу проблем с хранением всего в JSON-файле с кодированием бинарных данных в Base64 (так изображения хранить проще простого; про формулы в конце). JSON парсить в php (да и вообще) – проще некуда. Сохранение в JSON-файл из *.doc/docx можно реализовать макросом-скриптом на Visual Basic за половину рабочего дня.
Если не планируется какое либо распространение этого софта и заранее известно окружение (например система тестирования в университете с определенной версией MS Office =) ), то можно использовать автоматизацию приложений MS Office. Насколько помню, на том же Delphi довольно просто прикручивался кастомный GUI к документу MS Office при наличии хоть какого опыта работы с технологией COM. В таком случае достаточно будет лишь правильно разметить документ. С веб-версией, в случае ее необходимости, придется обращаться к .NET-платформе (хотя наверняка в MSDN уже есть мануал с сорцами на эту тему).
И стоит напомнить: *.docx – это не более чем переименованный *.zip с файлами в xml-формате. Не знаю как там хранятся изображения, но парсить распакованную структуру не должно составить большого труда средствами любого языка программирования.
Что является формулами я не смог понять из вопроса. Если объекты *math* или как там в MS Office они зовуться, то тут нужно искать решение. Например отрендерить предварительно =)). Вроде когда из .docx импортировали в *.doc для Office 2003 так и было.

Для тех, кто умеет читать код https://github.com/google/gumbo-parser

computers.tutsplus.com/tutorials/how-to-launch-any...

"Scala для нетерпеливых" годится как entry-level manual, книгу Одерски прочитать в любом случае придется. ИМХО Одерски как первая книга скучна и не очень, но вот со средних размеров багажом читается просто отлично. Багаж можно наполнить чтением сорцов самой скалы, на уровне посмотреть как работают базовые классы и коллекции (когда учил ставил эксперименты вроде "а как бы я это реализовал сам с теми знаниями что у меня есть сейчас", лез читать код и просветлялся). Если что-то читается тяжело, то лучше это пропустить – не вся библиотека блещет красивыми и логичными решениями, некоторые решения просто удивляли (описываю 2.10).
Может это сугубо персонально, но код на скале читается просто очень легко, если автор преследовал такую цель (имею ввиду стандартную библиотеку).
Про spray не скажу, но у проекта typesafe вроде как очень хорошая документация с туториалами.
Из книг можн пробежаться по Functional Programming Patterns in Scala and Clojure, если маловат опыт в функциональном программировании и планируется активное использование этой парадигмы.

На ответ тянет deadbyelpy
Добавить можно про определенную категорию языков, работу на которых найти тяжело, но изучить тем не менее стоит. Например, Erlang, OCaml, F# и другие функциональные языки очень сильно развивают мышление в терминах проблемы, а не языка программирования (то, что у МакКоннелла "Программируйте с использованием языка, а не на языке"). Clojure, как пример очень старой основы для языка, но с неимоверно крутыми идеями для современного мира, вроде STM да и в целом моделью параллелизма (отдельно стоит упомянуть ClojureScript и FRP).

Изучение одного языка сегодня не имеет смысла

– тяжело не согласиться, т.к. сегодня программист просто вынужден знать несколько языков (думаю 2-3 на уровне библиотек и фреймоворков, 5 на уровне стандартной библиотеки, и с десяток на уровне чтения кода). Провериться можно тут.

После определенного уровня профессионализма программист сам способен выбирать на чем писать, и наличие в его арсенале нескольких языков и платформ является несомненным плюсом.
А вообще, уже давно прошло то время, когда ты либо программируешь на Fortran/Basic/C, либо голодный и без денег. Изучение даже очень редкого языка окупается, т.к. это повышает уровень абстракции на котором мыслит программист. Корреляция этого уровня и зарплатных ожиданий пусть и сложна, но определенно существует.

Бывалые же советуют всегда держать под рукой интерпретируемый язык программирования, вроде Python или Ruby с REPL, для работ вроде "забрать кучу файлов по адресам из текстового файла". Ну и какой нибудь компилируемый тоже пригодится. Вне зависимости от стека и основного языка на проекте эти два друга будут выручать в любых ситуациях.
Python/PHP/Ruby для веба являются взаимозаменяемыми (при наличии нормальной архитектуры у приложения). Связка C/Go/Python/JS выглядит мощной и очень достаточной на много лет вперед.

А то, что все зовут стеками, для других является всего лишь набором старых парадигм, паттернов и практик, кочующих от одного языка к другому, но суть от этого не меняется (тут ООП и MVC передают приветы Smalltalk'у, а бородатый Лисп недоумевает, т.к. все эти DSL и приемы метапрограммирования давно живут своей жизнью и забыли истоки).

www.codemonkey.co.il
www.codeavengers.com
www.jsdares.com
betathegame.com

Забавные головоломки для новичков www.pythonchallenge.com
MUD inspired www.lisperati.com

Хотя это все для очень начинающих.
Еще есть сайт с отличной графикой и пазлами для среднего уровня на Python, но почему то упорно отказывается гуглиться. Если вспомню – дам знать.

Половина ответа в вопросе, но дьявол в мелочах.
Действительно, для относительно продуктивной backend-разработки практически на любом языке программирования необходимо знать несколько базовых фреймворков и тулов, которые решают большинство задач. Это скелет ~90% приложений сложнее hello world. Хотя и этот скелет меняется и развивается, пусть и не так быстро как хотелось бы, как разнообразные отростки (не консервативность, но более долгий жизненный цикл). Суммарный вес технологий и инструментов не меньше, и уж точно не менее динамично изменяющийся, чем у frontend-разработчиков.
Далее личный опыт на примере Java.
Лет 7-8 тому достаточно было знать Spring, Struts, Hibernate да Apache Commons в довесок для разработки большинства решений. Ну и J2EE-стек для задач Enterprise-уровня.
В году 2014 Spring, Hibernate все также в арсенале программиста, но появилась куча абсолютно новых вещей вроде AMPQ, Hadoop, Netty, Scala с функциональной парадигмой, мультиязычные окружения с Clojure/Groovy/JRuby; стали чаще встречаться альтернативные реализации популярных библиотек (например Guice / Guava); старые технологии вроде J2EE стали использоваться несколько реже. А одних только Key-Value хранилищ, кэшей и прочих NoSQL как грязи. Изменился даже сам подход к построению приложений – мало кто в 2005 слышал про asynchronous event-driven модели и отталкивался при проектировании от REST-стиля (собственно, там и корни frontend-девелопера как отдельной специализации). Про эволюцию систем сборок, VCS, бенчмарков и прочих "микро"-элементов можно расписывать не одну простыню.
И да простят меня frontend-товарищи за, возможно, чванливый тон, но раскурить тонкости работы async IO в зависимости от ОС-специфики вроде epoll/kqueue или учитывать CAP-теорему при построении middleware-кэша это уровнем сложности повыше, чем новый CSS-препроцессор и CoffeeScript c очередным MVC / MVVM-фреймворком. Некоторые задачи, вроде синхронизации потоков, так и вообще лежат большей частью в области математики.
Уверен, что и в frontend-разработке существуют задачи сложнее и интереснее поехавшей на пиксель верстки и обновления полей после парсинга JSON, но ИМХО backend-разработка ближе к системному программированию старой школы, в то время как frontend суть прикладное программирование с примесями дизайна.
Frontend-инструментов больше, backend-инструменты сложнее.