Василий Банников

Нужен ли на установленный .net на платформе где будет запускаться такое .net приложение?

Когда ты публикуешь приложение для Linux - оно будет с расширением исполняемого файла от линукса.
А именно - ни с каким.
Если будешь публиковать платформонезависимое приложение, то тогда будет .dll и в любом случае понадобится установленный рантайм.

Нужен ли на установленный .net на платформе где будет запускаться такое .net приложение?

Если публиковал с флагом --self-contained или --self-contained true, то не нужен.
Если публиковал без флага --self-contained или с флагом --self-contained false, то нужен.

Это всё ты мог проверить самостоятельно, просто скомпилировав хеллоу ворлд.

PS: вот что конкретно выдаётся в результате:

C:/workspace
❯ dotnet new console -o DemoLinuxPublish
Шаблон "Консольное приложение" успешно создан.

Идет обработка действий после создания...
Выполнение "dotnet restore" для C:\workspace\DemoLinuxPublish\DemoLinuxPublish.csproj...
  Определение проектов для восстановления...
  Восстановлен C:\workspace\DemoLinuxPublish\DemoLinuxPublish.csproj (за 113 ms).
Восстановление выполнено.


C:/workspace took 2s
❯ cd .\DemoLinuxPublish\

C:/workspace/DemoLinuxPublish via .NET v6.0.100  net6.0 took 12s
❯ dotnet publish -c Release -r linux-x64 --self-contained -v q --nologo -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true -p:DebugType=None -p:DebugSymbols=false -p:PublishReadyToRun=true -p:PublishTrimmed=true

C:/workspace/DemoLinuxPublish via .NET v6.0.100  net6.0 took 2s
❯ ls .\bin\Release\net6.0\linux-x64\publish\

    Directory: C:\workspace\DemoLinuxPublish\bin\Release\net6.0\linux-x64\publish

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---          21.03.2022     3:25       15866695 DemoLinuxPublish

PPS: я немного упоролся с дополнительными параметрами сборки

https://dotnet.microsoft.com/en-us/apps/aspnet

Мне кажется или в 1 случае это весьма самоуверенно - позволять джуну бэкэндеру проектировать бд

А вы спросите что конкретно они понимают под проектированием.
Скорее всего, на проекте уже есть какая-то бд и архитектура, так что от тебя будет требоваться максимум - спроектировать новую таблицу, или несколько + связи между ними.
+ Знать про разные НФ и уметь нормализовать данные до 3НФ

Это вполне обычная работа бэкендера.

Когда возникла нужда во фронтенде, тогда и изучать.
Например если ты не понимаешь причины претензий фронтендеров к твоему апи, или вдруг понадобилось самому по-быстрому запилить фронт.

Я так понимаю в компании я этим заниматься точно не буду? Кто этим занимается? Продакт-менеджер?

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

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

Зависит от компании. Обычно есть какой-то roadmap, в котором описано, к какому сроку надо выпустить фичи, и бэклог, в котором фичи разбиты на отдельные истории, а истории на задачи.
Если будешь работать в команде, а не в соло, то бэклог будешь составлять с командой.

4. Тесты кто-то будет за меня писать или это всё ещё моя ответственность? Если в компании есть тестовики.

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

5. Нужно работать в jira? Никогда не использовал навороченные таск-трекеры, только канбан. Для чего это вообще нужно? В чем отличия от Issues и PR на гитхаб?

Зависит от компании. Даже в крупных компаниях вполне используют канбан (его кстати готовить очень сложно, на самом деле. Скорее всего, вы использовали просто доски)
JIRA по сути - это навороченные Issues, на которые можно навертеть сложный процесс с кучей людей и дополнительных полей.
Лично я жиру не люблю, и предпочитаю youtrack

6. Когда делал заказы "под ключ", часто деплоить тоже приходилось самому (хвала AWS!). В компании деплоем занимается кто-то другой или разрабы сами деплоят?

Везде по разному.

7. Много ли компаний с жесткими ограничениями по используемому софту? Типа все должны использовать VS, GitKraken, и тп.

Хз. За всё время самое жёсткое ограничение, какое я видел - "используй вот эту IDE, тк мы активно практикуем парное программирование, и хотелось бы, чтобы у всех была +/- похожая среда".
А так в основном - если твой любимый набор инструментов позволяет тебе эффективно работать, то используй его.

8. Будет куча разных митинтов в течение дня? Всякие стендапы и тп. Или это миф?

Везде по разному.
Обычно из митингов - это 10 минут Daily и ещё пара каких-нибудь крупных встреч типа Sprint Planning / Sprint Retro каждые две недели.
Иногда даже меньше - встречал случаи, когда аналог дейли проводили раз в два дня.
Много звонков и встреч - это про менеджеров, тк это их работа.

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

Если фронт трогать можно, то есть разные варианты:
https://habr.com/ru/company/yandex/blog/442762/

Всё будет нормально, просто надо будет их разнести на два разных порта.