Вопросы для собеседования бэкенд-разработчика

Т.е Джаву ниспослал господь, а люди могут только поменять ее на что-то или нет. Джава по умолчанию "по-старинке" а гринфилд проектов не бывает? Ее ж в свое время выбирал кто-то?

Излишняя демонизация goto и глобальных переменных говорит скорее об узости мышления таких демонизаторов.

Мне кажется, когда на вопрос "Почему goto зло" начинают отвечать, что "goto — не зло" это свидетельствует просто о нежелании понять вопрос. Человек вступает в режим конфронтации. Любая живая речь недостаточно формализована, чтобы иметь некотору свободу интерпретации. С моей точки зрения, наиболее адекватно воспринять вопрос "Почему [в каких-то случаях] goto — зло". И рассказать про идеи структурного программирования, отметив, что в каких-то случаях goto может быть полезным.

Интересно, что сейчас в оригинале перевода вопрос поставлен так:

Is goto evil? You may have heard of the famous paper "Go To Statement Considered Harmful" by Edsger Dijkstra, in which he criticized the use of the goto statement and advocated structured programming instead. The use of goto has always been controversial, so much that even Dijkstra's letter was criticized with articles such as "'GOTO Considered Harmful' Considered Harmful". What's your opinion on the use of goto?

В случае с конечным автоматом мне ближе подход, когда задача описывается в терминах конечного автомата и в языке достаточно средств, чтобы описать eDSL для удобной формулировки конечных автоматов. Хотя я признаю, что в случае низкоуровневого языка и сильных требований к быстродействию, когда-то допустим и goto.

Сейчас разработка ПО коллективный процесс, и, если человек не хочет услышать то, что ему пытаются сказать, а требует 100% точного формального вопроса, в моих глазах у него будет минус.

Тем, что deinit_some1 автоматически исполнится после deinit_some2, с одной стороны. А, с другой, deinit_some* можно исполнить с любого уровня, не дублируя код.

Потому что часто компоненты init_some2() и init_some1() взаимосвязаны.
Сравните код какого подхода чище:

void foo()
{
    Window *wnd = CreateWindow();
    if (!wnd) goto cleanup_wnd;

    Context *ctx = GetContext(wnd);
    if (!ctx) goto cleanup_ctx;

    Renderer *renderer = GetRenderer(ctx);
    if (!renderer) goto cleanup_renderer;

    renderer->drawline(0, 0, 100, 100);

cleanup_renderer:
    FreeRenderer(renderer);
cleanup_ctx:
    FreeContext(ctx);
cleanup_wnd:
    DestroyWindow(wnd);
}

Или:

void foo()
{
    bool wnd_failed = false;
    bool context_failed = false;
    bool renderer_failed = false;

    Window *wnd = CreateWindow();
    if (!wnd) 
        wnd_failed = true;

    Context *ctx = NULL;
    if (!wnd_failed) 
        ctx = GetContext(wnd);
    if (!ctx) 
        context_failed = true;

    Renderer *renderer = NULL;
    if (!context_failed) 
        GetRenderer(ctx);
    if (!renderer) 
        renderer_failed = true;

    if (!renderer_failed)
        renderer->drawline(0, 0, 100, 100);

if (renderer_failed)
    FreeRenderer(renderer);
if (context_failed)
    FreeContext(ctx);
if (wnd_failed)
    DestroyWindow(wnd);
}

foo(...)
{
    bool init1_success= !init_some1();
    // если init1_success == 0, init_some2() не будет выполнено
    bool init2_success = init1_success && !init_some2();
    // и так далее

    // деинициализируем в обратном порядке

    if (!init2_success) {
         deinit2();
    }
    if (!init1_success) {
         deinit3();
    }
    //
    // и так далее
}

Хорошие разрабы используют ОО языки для процедурного программирования.

Эту фразу стоит превратить в вопрос:

Расскажите почему хорошие программисты используют ОО языки для процедурного программирования?

и смело добавлять в статью, настолько она сильная.

Я не знаю как ещё это комментировать.

На самом деле в оригинале "What's the output of this Javascript function?", а в переводе это сейчас "результат выполнения" а не "что возвращает" :)

Я замечал такое только в российских компаниях. Иностранцы более прагматичны и рациональны.