Станислав Макаров

Всегда и везде UTF-8

Полно заказов для Windows Desktop, это основной язык.

C# - язык использующийся в крупных компаниях, активно использующих инфраструктуру MS. Это практически противоположное фрилансу понятие. Выбрав C#, вы сами по сути вышли из сферы 99% фриланс-проектов, но это не значит что вам нужно учить пхп, C# отличный язык. Ищите нормальную работу или стажировку на нем.

Мобильная разработка под Win Phone, теряет всякий смысл, так как MS не удалось занять сколько нибудь ощутимую нишу на мобильном рынке. Судя по последним новостям, MS вообще будет сворачивать это направление, и думать над чем-то еще.

Из коробки нет. Берите ItemsControl и вперед.

Начав использовать типы в TypeScript, с нормальным автодополнением в IDE, тяжело возвращаться обратно - это мой опыт.

Там в колбэке функции есть аргумент отвечающий за описание ошибок. Воспользуйтесь им что бы понять в чем причина.

Так же убедитесь что сервер поднят на том порту и на том хосте что нужно. Ну и что он поднят. Проще всего через netcat.

Потому что аксессоры в JS предназначены для того, чтобы задать какую-то логику на геттер или сеттер. Таким образом можно, например, реализовать счетчик того, сколько раз какое-то свойство было изменено и т.п.
Да и с помощью них можно реализовать такую штуку как:

var Test;
(function() {
  var super_priv = 1;
  Test = class {
    get priv() {
      return super_priv;
    }
    set priv(val) {
      super_priv = val;
      return priv;
    }
  };
})();

Возможности PHP очень ограничены
Можно пример? ПХП гавнище редкостное, но возможности в вебе у него ни разу не ограничены.

Как бы вы не старались, люди найдут как обойти. Принесут свой portable плеер или браузер с установлеными плагинами: сам так делал, ничего проще чем обмануть админов ;-) Можно пустить интернет только через прокси-сервер, и на стороне прокси делать такие ограничения. Ну файлы больше 20мб нельзя скачивать или там еще что-нибудь придумать. Но это борьба с ветром. И с людьми которые не хотят работать.

Джун джуну рознь. Чем больше знаний - тем лучше.
Троелсен и правда очень медленно и педантично повествует. Он удобен как настольная книга джуниора, как справочник - по конкретным задачам копать. Но, ИМХО, Шилдт будет приятнее.

Основные контейнеры - преимущества и недостатки. Сложность алгоритмов поиска и вставки, сортировки. Хэш-таблицы, хэш-код объектов, equality и как это все устроено. Неплохо бы знать про многопоточность и примитивы синхронизации (в общих чертах).
Хорошо бы знать кое-что про платформу .NET - типы-значения и ссылочные типы (про стек и кучу), про GC с поколениями, SOH/LOH, как можно устроить утечку памяти -> IDisposable.
Уметь делать запросы к базе через голый ADO.NET.
По базам данных: владеть основными запросами SQL, писать и вызывать хранимые процедуры. Знать что такое и зачем нужны индексы, нормализация, View, где смотреть query execution plan.
Суметь рассказать о том, что такое MVC, ориентироваться в основных паттернах.

Если курс на веб, то понимать работу HTTP, REST, знать основы фронта (приоритет селекторов в CSS, "всплывающие" объявления переменных в javascript, разницу "==" и "===", чем отличается асинхронность от параллельности и чем это грозит).

Вызовет уважение в глазах интервьюера: понимать и применять IoC/DI, уметь писать тесты, работать с ORM (EntityFramework допустим), async/await и SynchronizationContext.

В идеале второй вариант, если это возможно.

Скажем я на своих проектах пытаюсь делать так насколько это возможно. Перед началом разработки какой-то фичи разработчики просто договариваются между собой как будет организовано взаимодействие с сервером (по сути пишется описание API на каком api blueprint, сейчас будем переходить на raml).

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

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

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