Saboteur

Говорят C# уже можно в Линукс, а раз хотите изучить, можете рискнуть.
А так - вопрос что за GUI.
Какая-нить утилита с простыми окнами, так можно и на js вебморду к ней сделать будет кроссплатформенно, а бэкенд уже на чем хотите с вариантом переписать его потом на другом языке.

P.S. Только не электрон.

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

При внезапном прохождении интервью, совершенно нормально сказать, чот вы можете приступить к работе не ранее чем через 2-3 недели, чтобы оформить уход с прошлой работы.

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

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

2. Окей, а если не на собеседовании вам поставят задачу - вы разберетесь или будете волноваться что наизусть не знаете?

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

Никак.
Данные могут храниться в виде разных переменных, и вычисляться перед выводом.
Данные могут храниться в относительных координатах и уточняться перед выводом.
Данные могут храниться в более детальном виде (float), и при выводе округляться.

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

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

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

> Я могу себе представить требования к backend, потому что backend сложнее.
Нет

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

> Там разного рода масштабирования, linux и sql.
Во фронте много js, json, xml, CS, много зрелых технологий на изучение которых требуется много времении сил, много новых технологий.

> А вот требования к frontend разработчику высокого уровня мне представить сложно. Тут один достаточно простой (по сравнению) ЯП, приходящие модные технологии вроде babel, webpack и TypeScript, которые еще сильнее упрощают работу и какой-нибудь фреймворк.
А как же webassembly, html5, RMTP, и другое медиа? Флэш сейчас уступил место JS и HTML5, но это только расширяет возможности использования.

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

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

> В целом, если его очень хорошо протестировать, то разработчик уверен на 99.9%, что все работает на всех браузерах и на всех утройствах. Здесь не может быть ситуации, когда пришло слишком много пользователей или память на сервере закончилась.
Ну как это не может? Вы знаете все устройства, где запустится ваше вебприложение? А если на смарттв? А если на нонейм планшете? А если это голосовой чат в веб-приложении на 50 человек?

> Тут нет мониторинг систем.
Зато есть понимание метрик, их сбора, и отправки на бэкенд или куда-то еще?

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

Приложить усилия. Нельзя выучить английский, просто заплатив куда-то денег.
Поэтому выделять нужно не просот 1.5к в месяца, а много времени и УСИЛИЙ, которые реально тратятся на изучение, а не просто полистать учебник полтора часа, не вникая в смысл.

Советую воспользоваться поиском и найти уже готовые ответы вроде
* онлайн-ресурсов (lingualeo и др игровые варианты для регулярных занятий).
* Посещение курсов (любых, где есть преподаватель и общение)
* Регулярный просмотр видео на английском

Опять же, если у вас сейчас уровень elementary, то 6 месяцев может оказаться недостаточно, если вы не живете в стране с носителями.

1.5 месяца очень мало.

Видимо вы принялись за питон, вообще не имея представления о том, как в принципе работает интернет и сайты.
Почитайте немного про HTML/HTTP/базовое понимание о сетях, что такое web API.

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

Знание чисто языка программирования - ничто без понимания, как работает система.

Нет такого успешного опыта.

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

Поэтому в случае чего - просто поднимаете приложение в том же датацентре, где сейчас мастер.

А вы уверены, что проблема именно в CPU, а не в скорости считывания файла с диска?
Особенно учитывая, что файлов очень много?

GPU достаточно специфичная вещь, смысл ее применять для подобной операции не слишком виден.

А как вы себе представляете сканировать "неизвестные ранее различные баги" в различном ПО?
Такого не существует, поэтому и не нашли.

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

Так можно писать сканер известных уязвимостей к различным ресурсам.

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

Но все сводится к тому, что конкретные дыры вы должны заранее знать.