Александр Дорофеев

Да, это нормально. У вашего приложения есть api в состав которого входят сущности, с которыми вы работаете и которые вы возвращаете клиенту (причем внутреннее представление и внешняя модель могут отличаться).

Чтобы избавиться от бойлерплейта с геттерами, сеттерами и прочим, используйте lombok

/**
 * аннотация @Data добавит в байткод методы 
 * getString, setString, 
 * getAnotherString, setAnotherString, 
 * equals, hashcode, toString
 */
@Data
public class App {
    private String string;
    private String anotherString;
}

В этой библиотеке очень много удобных аннотаций. Для поддержки в среде idea можно установить lombok plugin

Впринципе задумка верная, можно сделать немного красивее

//..
if (!(o instanceof A) {
    return false;
}
if (!(o instanceof B)) {
    return this.equals(o);
}
//..

Нету правильного способа ибо вы всегда будете нарушать что то(транзитивность в данном случае).
Из Effective Java 2nd edition item8:

There is no way to extend an instantiable class and add a value component while preserving the equals contract

Часто можно просто пересмотреть подход и использовать композицию вместо наследования.

Спорный вопрос, но Josh Bloch с вами согласен.
С другой стороны нарушен принцип симметричности equals.
В любом случае, серебрянной пули не существует, а отдельные решения отлично подходят в каждом конкретном случае.

Эмулятор

А что за приложения-то там разрабатывают?
Какие технологии: Xamarin, Unity, ...? Да и суть их какая?
ИМХО, при собеседовании важнее не знания как таковые, а соответствие стандартам данной фирмы, кто лучше соответствует, того и возьмут скорее.

C++ (NDK) - для компонентов, которым нужна производительность и не нужно взаимодействие с элементами из SDK ( кнопочки, доступ к железу). Конечно, его можно сделать через JNI (а там все равно Java) но это гемор еще тот

Java (SDK) - для всего остального.

Code -> Reformat Code
или
CTRL+ALT+L

Что в моем случае можете посоветовать?

retrofit + dagger

Помимо использования устаревших org.apache.http.* для запросов, не вижу лично проблем.

Берете то, что вам интересно и делаете. Если ничего не интересно - делаете, что попроще.
Делать то, что интересно не вам, а другим - бред и вообще провал полный.
Удачи с диссертацией.

Тоже читал эту новость. Интересно, кому там котлин проигрывает, если иногда он даже быстрее джавы(оптимальнее), как минимум не медленнее, потому что компилится в джавовый байт-код, а свифта под андроид нет. И во что они планируют компилить свифт, если не в тот же байт-код? В нативные сошники? А как взаимодействовать с обычными либами? Через нативный интерфейс?
Короче мутная перспектива, больше вопросов, чем ответов, я б не стал(и не планирую пока) рваться в свифт.
Насчёт сложности перехода - всё очень индивидуально. Я смогу за пару недель перейти, чтобы писать нормальный код, имхо. Вам виднее, сколько времени вы на это затратите.

В IntelliJ IDEA курсор на интересующий класс/метод и Ctrl+B == все что нужно для глубокого понимания внутренней структуры.

Почему нельзя? Можно! Но только не всегда :)
АсинкТаски - для коротких асинхронный операций. Типичный пример - обращение к БД. Ни в коем случае не использовать для работы с сетью.
Почему:
1) АсинкТаски не привязаны к жизненному циклу активити. При пересоздании активити onPostExecute() выполнится, но активити будет не та (и она может утечь, что совсем не круто).
2) Следствие 1 - довольно хорошо заморочиться надо, чтобы написать правильный код с АсинкТасками. Такой код становится негибким и неудобным.
3) Без дополнительный усилий (executeOnExecutor) асинктаски ставятся в очередь и выполняются в отдельном потоке, но последовательно. Как следствие - тормоза UI там, где они используются правильно (например AsyncTaskLoader).