Website development
Programming
Server optimization
Database Administration
IT career
Comments 274
+40
Почему многие разработчики не любят Java?
Что делает хороший код хорошим?
Что вы узнали за последнюю неделю?
Объясните Юникод или транзакции в СУБД пятилетнему ребёнку.
Ваше последнее достижение, которым вы гордитесь?
...<много подобного в статье>...
Боже, нет, такие вопросы я бы меньше всего хотел слышать на техническом собеседовании.

Хотя… для нетрезвых конкурсов на корпоративе они вполне сгодятся.
+51
Поздно. Тысячи HR уже скопипастили себе статью в файлик «Вопросы на собеседование компьютерщика.doc».
+16

Вероятно автор спутал тех.собеседование и приём у психолога


Хотите обсудить эту тему?
+1

Я на большинство вопросов «хотите обсудить эту тему» ответил «нет»:) Видимо, меня не возьмут.

+4
Это вопросы не на умение программировать, а на знание модных баззвордов. Не дай бог заиметь начальника, который оценивает тебя по подобному списку.
+1
В корне с вами не соглашусь. Про баззворды там вопросов раз, два, и обчелся.
Большинство вопросов как раз-таки на понимание архитектуры программных продуктов и хорошие практики разработки.
+3
Знание названий паттернов — это не понимание архитектуры. Точнее понимание архитектуры совсем не подразумевает знания всех этих идиотских словечек, которыми пестрит вопросник. Про явно подразумеваемое соответствие «бэкенд = java» вообще промолчу.
0
Говоря про паттерны и прочие «идиотские словечки», обычно ожидают и оценивают не знание названий, а понимание их смысла и назначения.
И решительно не ясно, почему все так взъелись на «Java», по-моему вполне очевидно, что при собеседовании разработчика с другим стеком вместо Java в вопросах будет %your_language_name% и %your_platform_name%, благо большинство из вопросов с некоторыми адаптациями применимы и для других языков и технологий.
+1

Думаю, тут еще в коvментах происходит тестирование на то, наколько человек хочет понять что сказал собеседник и поискать там рациональное зерно или насколько хочет доказать что собеседник неправ :)

+1
Говоря про паттерны и прочие «идиотские словечки», обычно ожидают и оценивают не знание названий, а понимание их смысла и назначения.

Если вопрос содержит название очередного «active-record», то подразумевается, что я должен знать что это такое. А я, как оказалось, уже лет 15 пользуюсь этим паттерном чуть не каждый день, но данное идиотское словосочетание вижу в первый раз.

Для каждого из миллиона способов сохранить данные в программе тоже отдельное название придумали? Заняться совсем нечем?

И решительно не ясно, почему все так взъелись на «Java», по-моему вполне очевидно, что при собеседовании разработчика с другим стеком вместо Java в вопросах будет %your_language_name%

А кодсниппеты с характерными «болячками» %your_language_name% тоже будут другими? Что-то сомневаюсь.
+1
Понимание смысла и назначения паттерна это одно, но не факт, что человек может знать его название. Успешно применяет и понимает, сам до этого дошёл, а названия не знает, такое вполне возможно. Тут уже зависит от упоротости проводящего собеседование, если ему важно знание терминологии и он не хочет задавать наводящие вопросы — скорее всего он поставит мысленный минус кандидату, хотя фактически, это скорее минус именно ему.
+1
уже зависит от упоротости проводящего собеседование

Что не зависит от упоротости проводящего собеседование?

+2
Еще одного вопроса нет, который мне несколько раз задавали — «нравится ли вам java?»

Для мне это что-то типа «нравится ли уборщице швабра?» или «нравится ли кузнецу молот?». Мне на самом деле мне нравится решать задачи, а каким образом, — это уже второй вопрос. Обычно приходится решать теми инструментами, которые заказчик предпочитает. Если он захочет забивать гвозди мороженной колбасой, — забью без проблем. :) Эстетов будет воротить, но гвоздь будет забит.
+2
Если он захочет забивать гвозди мороженной колбасой, — забью без проблем.

А не бывает ли таких ситуаций когда есть возможность выбрать инструмент или поговорить с заказчиком и убедить использовать другой?


Во-вторых, вопрос может быть не для того, чтобы дать вам выбирать а просто выяснить ваш кругозор — насколько вы знаете возможности Джавы и насколько вы будете готовы, когда следующая версия принесет новые возможности из других языков

+1
А не бывает ли таких ситуаций когда есть возможность выбрать инструмент или поговорить с заказчиком и убедить использовать другой?


А это вообще тонкий вопрос. Тут как повезёт. Некоторые загипнотизированы фразами «новые технологии», «новые возможности». А некоторые думают «а где мы найдем специалистов на этот зоопарк, давайте по-старинке работать?»
0

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

0
> Почему многие разработчики не любят Java?
вот тоже интересно.
я, например, немного недолюбливаю(недолюбливал?) за отсутствие некоторых очевидных вещей типа лямбд и val, которые теперь есть.
ну и нелюблю саму jvm по причине отсутствия unsigned типов и ряда других нюансов.
UFO landed and left these words here
0
это уже скорее не к языку относится а к нездоровым технологиям применения
0
А мне кажется, что не любят за многословность и остутствие геттеров и сеттеров (вернее за необходимость их генерировать)
-1
Геттеры и сеттеры нарушают инкапсуляцию. Не вижу смысла вообще их генерить и использовать
0
Похоже вам стоит перечитать определение инкапсуляции еще раз.
И Можно еще почитать вот это
+1
Создается впечатление, что вы не умеете пользоваться инструментом и говорите, что он не нужен.
Вы сами-то эту статью читали?) Автор говорит о том, что аксессоры — зло лишь тогда, когда они втупую проксируют приватное поле. А вы возводите кричащий заголовок в абсолют.
+1
Генерируемые это и делают. Просто проксируют поля, чем и нарушают инкапсуляцию.
Генерировать их чтоб были — смысла нет и вообще вредно.
К тому же, будет более изящней заменить SetX(X value), на набор бизнес-методов. Как-то enableX() \ disableX() или markAsNew() \ markAsPending() \ etc… Тем самым инкапсулировав логику внутри агрегата
0

Они генерируются синтаксисом, а не просто вообще для всех полей. возможностью перекрытия. Как в с#


public int X -> public int X {get;} -> public int X { get { return myWebService.method1() }}


Так же это полезно для любой вещи, где вы думаете о чем-то кк о характеристике объекта — это говорит UI что можно отрендерить нечно как поле и прочее.


enableX / disableX — это значит что у вас есть X который у вас голове связан с enable и disable, а в интерфейсе сущности X нет.


Фактически вы генерируете код только ручками.

0
вот такой подход — наиболее логичный.
собсно в котлине его и приняли
0
Раскрытие состояние объекта действительно нарушает инкапсуляцию. Объект предоставляет поведение, и скрывает состояние. Именно поэтому в некоторых языках программирования интерфейсы позволяют декларировать только методы, но не свойства.

Мысль заключается в том, что геттеры/сеттеры предоставляют доступ к состоянию, но не предоставляют поведения. Т.е. придают объектам свойства структур данных, образуя собой объекты-гибриды, недостатки которых хорошо раскрыл Robert C. Martin в своей книге «Clean Code».

Посмотрите, как устроены правильные OO-языки (Smalltalk, Objective-C, Ruby и т.д.). Объекты общаются посредством сообщений. Интерфейс — это протокол взаимодействия. Геттеры/сеттеры никакого взаимодействия не осуществляют, и в большинстве случаев (разумеется, не всегда) просто воплощают Code Smell под названием Feature Envy.

Посмотрите письма Alan Kay, того самого, кто и провозгласил термин OOP:
«I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning – it took a while to see how to do messaging in a programming language efficiently enough to be useful).» (Alan Kay)
«OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.» (Alan Kay)
Собственно, упомянутая oxidmod статья именно об этом. Письма Alan Kay можно найти в интернете, два наиболее важных из них я цитировал здесь. Кстати, статья по ссылке тоже посвящена этому вопросу, только уже на уровне паттерна «Event Sourcing».
0
Мысль заключается в том, что геттеры/сеттеры предоставляют доступ к состоянию, но не предоставляют поведения.

Мне кажется даже во времена дельты присваивание значения свойству вызывало какое-то поведение. Например изменение текста кнопки. То есть это как бы "интерфейсное состояние" изменение которого есть поведение.


Акцессоры — это просто группа сообщений о которой снаружи удобно думать как о состоянии. При этом за ними может крыться какое-то поведение. Насколько, я знаю, в смолтоке акцессоры есть.

0
С оппонентом выше договорились о том, что это спор о терминологии.
+6
Если я понятия не имею, почему люди не любят джаву, то что мне делать?
+14
Искать другое место. Достоин только тот кандидат, который точно знает. Тот, который за последнюю неделю что-то узнал, и пятилетний сын которого умеет делать транзакции Юникодом.
Тот, который на собеседовании написал минимум три образца плохого кода.

На его футболке написано: «Единство дизайна означает элитность архитекторов».
UFO landed and left these words here
0
Ну как сказать, я в жизни ни строчки кода не написал на Java, но при этом вполне себе имею представление о ее достоинствах и недостатках, и даже фольклор с этим связанный вспоминается. Тут уже вопрос скорее на кругозор в современном мире :)

А если серьезно, то по-моему вполне логично ожидать, что в зависимости от позиции, в вопросах вместо Java будет %your_languange% или %your_platform%.
-2

Так вопрос не о достоинствах и недостатках (хотя многие недостатки исключительно субъективны), а о том, "почему многие разработчики не любят Java". А вот это уже бред, ибо не любить можно за что угодно (например, что там "if" а не "если")

+1

Так собеседующему интересно мнение собеседуемого, пускай даже "там "if" а не "если"". Вопрос не подразумевает обязательного перечисления недостатков близкого к объективному или субъективной позиции "почему я не люблю Java". Вопрос подразумевает, скорее всего, осведомленность в области "джавасрачей". :)

+3
Какой ваш самый нелюбимый язык программирования и почему именно Java?
+55
>> транзакции в СУБД пятилетнему ребёнку.
Ну, как тут не вспомнить гениальное:
XXX шо есть транзакцыи?
YYY как бы тебе объяснить.
YYY вот ты бежышь срать в толчок.
YYY но по дороге не донёс.
YYY и обосрался.
YYY так вот с транзакциями можно сделать так, будто ваще и не бежал и не обосрался
+1
Пример без говна: чтобы поставить киоск, надо дать взятку пожарникам, санинспекции и в администрации города. Пожарник взял, санитары взяли, а в администрации не взяли. Транзакция — это когда заранее ставится условие, что если кто-то не возьмёт, предыдущие взявшие вернут.
+3
хехе, я как минимум на треть вопросов не ответил бы, это я такой глупый или вопросы?
да и некоторые ответы могут превратиться в нехилый холивар вместо собеседования :D
0

я middle php разраб и ответил всего на 80% вопросов (не знаю java, нуб в nosql и не teamLead для открытых вопросов) при чем по ощущению правильных ответов процентов 40-50. Это нормально?

+3
middle php разрабы пишут слово «причем» именно так. вы уверены насчёт 80%?
+1

Извиняюсь, забыл отправить комментарий на проверку моему личному grammar nazi

-11
Для таких забывчивых придумали pre-commit хуки. А пока — давай, до свидания.

P.S. Чем форма «извиняюсь» отличается от «прошу прощения» объяснять надо, или тоже в школе не доучили?
0

Объясните мне, я до сих пор уверен, что не отличается практически ничем.

-1
Ну, типа «извиняюсь» — это за то, что ты собираешься сделать, а «прошу прощения» — за уже совершенное. «Извиняюсь, можно я пройду? Ох, я наступил вам на ногу, прошу прощения.» В английском excuse me/I am sorry вроде бы точно так же работает.
0

Различие форм "извиняюсь" и "прошу прощения" — для эстетов. И классические объяснения училок "извиняю себя" некорректно, т.к. форма скорее несёт смысловую нагрузку "приношу извинения", а в такой формулировке разница ещё более никакая.

0
Я полагаю если на собеседовании более чем 1 человек ответит правильно на все вопросы то значит что ваш тест плохой, так как вы не сможете понять кто больше знает.
+2
ПМСМ, самый лучший вопрос: «Объясните ${базовая_технология} пятилетнему ребёнку.»
Часто бывает так, что работать надо не со знакомым языком/ технологией, а с чем-то специализированным. К примеру, 1С-ники иногда поддерживают groovy-код, а джависты попадают в Perl или JavaScript или вообще в ABAP, питонисты попадают в 1С и т.п…
И тут тимлид ищет тех, кто знает основы (сетевые протоколы, устройство юникода и принципы работы СУБД).
+4
Часто бывает так, что работать надо не со знакомым языком/ технологией..

а с пятилетними детьми

UFO landed and left these words here
+8
Как-то определиться надо или они зло или нет.
Темной силы стороной владеть уметь необходимо!
0
Это похоже на кальку с английского «if they are evil or not». Я начал за своей дочерью 5 лет замечать нетипичные для русского языка конструкции типа этой, у нее есть оправдание — она пошла в англоязычную школу, но дома говорит только на русском, конструкции стала уже путать.
-2

Да там прям ниже "Как произвести рефакторинг такого кода" с кучей уровней вложенности, который идеально рефакторится goto

+1
А можно идеальный пример с goto? А то у меня как-то так получилось:
function()
{
    if(!SUCCEEDED(Operation1()))
        return OPERATION1FAILED;

    if(!SUCCEEDED(Operation2()))
        return OPERATION2FAILED;

    if(!SUCCEEDED(Operation3()))
        return OPERATION3FAILED;

    if(!SUCCEEDED(Operation4()))
        return OPERATION4FAILED;

    return S_OK;
}

UFO landed and left these words here
0
Пример не мой, а тот, о котором вы писали: «идеально рефакторится goto».
+3

Да любой более-менее сложный конечный автомат. Например: https://www.thibault.org/newhome/thoughts/goto-and-fsms.html
Согасен с тем, что goto никаким злом не является. Просто конструкция, которую стоит применять обдуманно.


Спуститесь на уровень пониже (в ассемблер), и (о боже!) там везде goto! Безусловные и условные переходы по-другому и не работают.


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

+1
Излишняя демонизация 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% точного формального вопроса, в моих глазах у него будет минус.

0
Речь шла о рефакторинге конкретного кода, автор комментария написал, что он идеально рефакторится с помощью goto. Я попросил пример этого рефакторинга.

Примеров, где goto может использоваться я и так предостаточно знаю, но практически в любом случае можно без него обойтись (об ассемблере я не говорю).
UFO landed and left these words here
0

Но при этом легко обойтись и без него.


1) когда перед return есть работа, мы ее вложим в фигурные скобочки или вынесем в функцию.
2) когда разные if дают одинаковый результат, условия объединяют в одном if


Вообще, ничего не имею против goto, лишь бы не в моём проекте.

UFO landed and left these words here
0
я имел ввиду когда if(!SUCCEEDED(Operation1())) и if(!SUCCEEDED(Operation2())) должны сделать одинаковую работу. Но сами if' разные.

Тогда их можно соединить через && (в некоторых языках).


Вообще, это похоже на монаду или исключения. :)

0

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

+1

Это все зависит от языка и задачи. На ассемблере без goto вообще никак. В функциональных языках "дополнительные функции" создаются вообще на лету.

0
Всех демонов надо прогнать через SWOT анализ. Каждое благое немерение надо проверить, на предмет — в какой ад оно ведёт.
0
CMP DX,	00  ; Compare the DX value with zero
JE  label_yes      ; If yes, then jump to label L7
JMP	label_no
LABEL_YES: ... 
LABEL_NO:...
+3
Нуу, ответ, видимо, в том, что goto провоцирует писать код с глупыми ошибками или код, в котором крайне трудно разобраться.
Например, в вашем примере написано «деинициализируем в обратном порядке», а порядок тот же.
+2
Я думаю в его случае там опечатка и имелось ввиду:

foo(...)
{
    if (!init_some1())
        goto deinit_some1;
    if (!init_some2())
         goto deinit_some2;
    // и так далее

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

    deinit_some2:
        //
    deinit_some1:
       //
       // и так далее
}


Неоднократно видел такое в сишных прогах.
+1
И чем это лучше скобочек (которые неявные, зато контролируемые, goto)?
Вложенность кода понижаем? Если 1-5 уровней — можно и вложить, если больше — кривота и смелл, что с goto, что без.
0

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

0
Почему нельзя так?
foo(...)
{
    var int flag1 = 0, flag2 = 0;
    if (!init_some1())
        flag1 = 1;
    if (!init_some2())
         flag2 = 1;
    // и так далее

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

    if flag2:
        //
    if flag1 || flag2:
       //
       // и так далее
}
+1

Потому что часто компоненты 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);
}
0
по мне лучше
Так
void foo()
{
    int stage = 0;
    Window *wnd = CreateWindow();
    if (wnd) { 
       stage++;
       Context *ctx = GetContext(wnd);
       if (ctx) { 
             stage++;       
             Renderer *renderer = GetRenderer(ctx);
             if (renderer) {
                  stage++;             
                  renderer->drawline(0, 0, 100, 100);
              }
         }
   }

  switch(stage) {
   case 2:
       FreeRenderer(renderer);
   case 1:
       FreeContext(ctx);
   case 0 :
       DestroyWindow(renderer);
}


Или так
Так

#define  WINDOW_STAGE 1
#define CONTEXT_STAGE 2
#define RENDER_STAGE 3

void foo()
{
    Window *wnd = CreateWindow();
    if (!wnd) { 
       release(WINDOW_STAGE); 
       return;
    } 
   Context *ctx = GetContext(wnd);
   if (!ctx) { 
           release(CONTEXT_STAGE); 
           return;
   } 
   Renderer *renderer = GetRenderer(ctx);
   if (!renderer) {
           release(RENDER_STAGE); 
           return;
      }           
     renderer->drawline(0, 0, 100, 100);
 }

void release(int stage)
{
 switch(stage) {
   case RENDER_STAGE :
       FreeRenderer(renderer);
   case CONTEXT_STAGE:
       FreeContext(ctx);
   case WINDOW_STAGE:
       FreeRenderer(renderer);
 }
}


0
Не заметил, естественно нужно переменные Context *ctx, Renderer *renderer объявлять до первого блока и передавать в функцию release.
0

В первом случае:
Допустим, в случае полного успеха уничтожать ничего не надо. Делаем if перед свичом?


Во втором случае:
Вот уже появилась функция о четырех переменных, вместо простого гоуту
Зачем плодить сущности без необходимости?

0
Допустим, в случае полного успеха уничтожать ничего не надо. Делаем if перед свичом?

Нет. в случае успеха stage = 3 и свич не выполнится.

Вот уже появилась функция о четырех переменных, вместо простого гоуту

Во-первых, не всегда с 4 переменными, при классах в C++ переменные могли быть полями, так же они могут быть глобальные, частями одной структуры или даже массива (вы же все равно их как-то использовать и освобождать будете? Тогда код в примере выше все равно неправильный, так как созданные объекты в случае успеха никогда не удалятся).

Во-вторых, в случае программирования бритва Оккама не работает. Принцип единственной ответственности и чистый код советуют делать функции с одной ответственностью — в данном случае, их две — создать и очистить в случае ошибки. Поэтому с определенной стороны (для понимания другими разработчиками), две функции лучше чем одна, но большая.

P.S. Вопрос, что будет если вы в последнем goto вместо goto cleanup_renderer напишите goto cleanup_ctx? Правильно утечка памяти, причем другой программист голову сломает это специально так задумано (может вы по каким-то причинам решили пока рендер не очищать) или вы ошиблись.
Goto чуть-чуть экономит место, но делает код сложнее для понимания. Оно того стоит?
+2

В ваших примерах окно не очищается.
Так какой код лучше: с багом или без?

+3
Использование «проваливающихся» case — практически то же самое что использование goto. Но код с goto при этом чище выглядит…
UFO landed and left these words here
0
Ну, так все циклы это тоже goto по большому счету, (while(...) {} это m: if(...) {… goto m;}). :)

В ваших примерах окно не очищается.
Так какой код лучше: с багом или без?

Это называется описки (увы, писал без компа), исправить примеры ничего не стоит.
+1
А если залезть в ассемблер… То там фактически все условные операторы (jnz, jz, je и тд) — goto в чистом виде.
+1
В более объемном и сложном коде goto — зло, так как вносит серьезную путаницу и усложняет чтение. А для такого простого кода ни goto ни switch не нужны:

void foo()
{
    Window *wnd = CreateWindow();
    if (wnd) {
        Context *ctx = GetContext(wnd);
        if (ctx) {
            Renderer *renderer = GetRenderer(ctx);
            if (renderer) {       
                renderer->drawline(0, 0, 100, 100);
            }
            FreeRenderer(renderer);
        }
        FreeContext(ctx);
    }
    DestroyWindow(wnd);
}

*Это если предположить, что нам действительно зачем-то нужно очищать пустые объекты, как у вас в примере, иначе даже проще получится.
0

А разве такое использование if-ов или свичей у vedenin1980 — не тот же code smell?!!! Имхо лучше как-то так:


void foo() {
    Window *wnd = CreateWindow();
    if (wnd) {
        context(wnd);
    }
    DestroyWindow(wnd);
}
void context(Window *wnd) {
    Context *ctx = GetContext(wnd);
    if (ctx) {
        render(ctx);
    }
    FreeContext(ctx);
}
void render(Context *ctx) {
    Renderer *renderer = GetRenderer(ctx);
    if (renderer)
        renderer->drawline(0, 0, 100, 100);
    FreeRenderer(renderer)
}
0
У Вас даже если init_some1() вернет 0, init_some2() всё равно выполнится. Лучше так:
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();
    }
    //
    // и так далее
}


С ООП было бы, конечно, гораздо красивее и понятнее.
+1
С ООП было бы, конечно, гораздо красивее и понятнее.

Вот именно. Дядьки объектную модель придумали не для того, чтобы круг от элипса наследовать, а потому что задолбались управлять ресурсами вручную. Хочется жить, а нужно следить за порядком выделения и освобождения памяти — даже о крепких нервах взвоешь.

P.S. Код ваш еще хуже того, что с goto. Вторая и последующие строки будут без надобности исполняться, хотя уже в первой может стать очевидно, что этого не требуется. Плюс замена условий выражениями. Не плюс, а минус, конечно. Ибо абстракции протекли уже во второй строке, где «init2_success» по смыслу является «init1_and_init2_success». Это путь к головокружительному дебагу, слезам, мату и дурной репутации. Не нужно так.
0
объектную модель придумали не для того, чтобы круг от элипса наследовать, а потому что задолбались управлять ресурсами вручную

Вот это для меня новость. Вы не могли бы привести ссылку на источник?

0
Мне кажется, что наследовать круг от эллипса наследовать — не самая лучшая идея.
0

То есть о точке зрения дядек вы судите не потому, что прочитали что-то по истории ООП а потому, что вам что-то кажется?

0
Вторая и последующие строки будут без надобности исполняться

bool init2_success = init1_success && !init_some2();

— это точно то же самое, что и
bool init2_success;
if (init1_success) {
    init2_success = !init_some2();
} else {
    init2_success = 0;
}

Мне всегда казалось, что это понятная и распространённая конструкция (разве не так принято писать на С?)
UFO landed and left these words here
UFO landed and left these words here
0
Ну в приведенном вами случае, goto это своеобразная замена exceptions, отсутствующим в чистом Си.
C исключениями этот код будет немного красивее и с меньшей вероятностью допуска ошибки по невнимательности (правда, за счет некого оверхеда).

По-моему, если вопрос поставлен таким образом, то интервьюер хочет услышать именно о плохих примерах :)
0
Надо думать, каждый блок кода, следующий за меткой, должен заканчиваться оператором return? И вот ваша функция уже превращается в блюдо спагетти, пусть даже уложенных ровным слоем. Хотя, возможно, вы просто перепутали последовательность меток в конце функции, и на самом деле они должны следовать в обратном порядке. Вот, кстати, еще один довод в пользу отказа от использования goto — оказывается, можно легко допустить ошибку и не заметить это!

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

Что касается глобальных объектов, да — по большому счёту это зло. Почему — хорошо объясняется, например, здесь: ru.stackoverflow.com/questions/510910/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D0%B3%D0%BB%D0%BE%D0%B1%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5-%D0%BF%D0%B5%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5-%D1%8D%D1%82%D0%BE-%D0%B7%D0%BB%D0%BE-%D0%B0-%D0%BF%D0%BE%D0%BB%D1%8F-%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0%B0-%D0%BD%D0%B5%D1%82. Но иногда глобальные обекты все-же приходится использовать, и thread-safe singletone — это лучший паттерн для этого. Кстати, сфера применения паттерна singletone чуть больше, чем просто объявление глобального объекта.
0
Никто не утверждал, что между вопросами теста должны быть какие-то взаимосвязи, например логические. Каждый вопрос как-бы запускает виртуалку с нуля.
+10
В какой-то момент слушая вполуха собеседования кандидатов на должность, примерно равную моей, пришел к выводу, что на свое место я бы не прошел
+1
Да потому что в процессе работы идет концентрация на чем-то определенном в ущерб другому, даже если что-то знали в прошлом без постоянного применения на практике остается только воспоминаниями, причем чем дальше тем призрачнее.
+1
Не могу сформулировать, где тут расхождение с наблюдениями. Уровень требований явно вырос, а рабочие процессы усложнились умеренно
+4
Слушаешь вполуха собеседование, или даже проводишь его, и думаешь, что себя бы я не взял…
+2
Проходишь собеседование, понимаешь что проваливаешься (это не помнишь, то не знаешь, там не использовал и выводишь решение на месте или рассказываешь как бы сделал с тем, что умеешь и куда бы смотрел чтобы сделать), а потом оказывается что прошёл, поскольку не хуже остальных, можешь понять как решить проблему и работал с аналогичной технологией и представляешь куда копать. Да и задачи сильно уже, чем вопросы.
+2
Занятный конечно же списочек, но интересно какой уровень зарплаты предложат человеку который может ответить на все вопросы)

Ну и самое интересное что если вам кажется что вы ответили на большинство вопросов, то вам это только кажется, т.к. почти каждый можно растянуть на жесточайший холивар, а ответить по верхам это не ответ, ну смысла от него нет никакого.
+17
Занятный конечно же списочек, но интересно какой уровень зарплаты предложат человеку который может ответить на все вопросы)


«Ну, для начала, 25 на руки. Белыми, конечно. По итогам года можно будет говорить о постепенном пересмотре зарплаты, накинем пару тыщ, не обидим. А как вы относитесь к переработкам?»
+3
Вот кстати абсолютно согласен, на практике доказано обратная пропорциональность въедливости с широты распросов на собеседовании и размера зарплаты.
0
Если учесть, что 180 тыс в год в Долине норм, то 25 тыс на руки для начала в месяц совсем неплохо.
+8
Все зависит от «принимающей» стороны. У меня был опыт когда на собеседовании у меня спросили мое отношение к некоторой вещи (подзабыл, что именно было, так как обсуждали несколько вещей). В процессе обсуждения я много рассказывал, что думаю, почему думаю, когда бы стал использовать. В конце мне сказали, что они сами не сторонники этого, но им понравились мои рассуждения. Не часто удается так приятно пообщаться на собеседовании без какого либо холивара и единственно верной точки зрения.
На мой взгляд «открытые вопросы» хороший вариант понять как рассуждает кандидат. Да и вообще понять насколько комфортно общаться с человеком, как он воспринимает критику. Все таки живем и работаем мы чаще в команде и общение играет не последнюю роль.
+1
Почему глобальные объекты и статика — это зло? Можете показать на примере кода?

Чо эт сразу зло-то? В ФП вот всё по умолчанию статика и глобальные объекты. Ну не учитывая разбивку на модули (по сути неймспейс).


Наверное стоит спрашивать почему ИЗМЕНЯЕМЫЕ глобальные объекты зло? Но и это не всегда правда, может у меня есть изменяемый глобально параметр LogLevel, небеса не развернутся если я его буду менять из разных кусков кода.


Многие другие вопросы заранее в себе содержат "правильный" ответ, который собеседуемый должен взять за основу рассуждений (например: почему Java это плохо?).


Короче, плохой опросник.

0
На самом деле, тема статьи намекает.
Для бэкенд-разработчика статика — зло очевидное. Да и за глобальными объектами нужно внимательно приглядывать. Тут даже кода не надо приводить, только 2 волшебных слова: «сервер приложений»
-1
Только статикой они почему-то зовут статические переменные, а не неизменяемые данные для раздачи клиентам.
+1

Я вот бекенд разработчик, занимаюсь "чёрными ящиками" (вход -> магия -> выход) — WebAPI, ETL, Streaming. И мне очевидно две вещи:


  • я хочу всё распараллелить, заасинхронить
  • я не хочу проблем

Поэтому я просто пишу в ФП стиле: иммутабельность везде. Сразу снимает проблемы с рейс кондишнами и проблемой глобальных объектов. У меня всё глобально доступно, но кого это волнует если функции чистые и они не мутируют объекты, а создают новые?


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

0
иммутабельность хорошо, но недостаточно. Ключевые слова «Сервер приложений».
Конечный пользователь берет и устанавливает несколько экземпляров приложения, с разными контекстами, на одной виртуальной машине. Какой будет результат?
Про библиотеки и говорить нечего
-2
Я видимо плохой бекенд разработчик, потому что хороший, судя по опросу, использует для бекенда исключительно ООП.

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

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


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

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


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

0

Пример на F# (но синтаксис у ML подобных языков очень похож)
Глобально объявленный оператор сложения, два значения и результат:


let inline (+) x y = x + y

let a = 1
let b = 2
let c = a + b

объявлять класс не нужно. идентификаторы a,b,c и оператор (+) будут доступны всем желающим.

0
Так это глобальные имена, а не объекты. У этого оператора, равно как и у a, b и c, стейта нет.

Какой-нибудь глобальный IORef можно с натяжкой считать глобальным объектом в хаскеле, но этот IORef нельзя будет создать без unsafePerformIO, который издалека заметен и очень плохо пахнет.
0
Насчет ФП.

В Erlang вообще нет глобальных и статических переменных, только локальные, принадлежащие стеку или куче процесса. Процесс закончился — память очищаем, все в мусорку улетело, все параметры, переменные, результаты, мэйлбокс. Хотите что-то передать — будьте добры явно этим озаботиться. Собственно, для того gen_server и придумали, чтобы можно было эмулировать сохранение состояния.

Есть правда нюанс с бинарниками, самый известный способ все-таки выстрелить себе в ногу, когда большие бинарники лежат в куче и на них передаются ссылки другим процессам. Я так словил знатную утечку памяти один раз, когда еще не знал особенностей. Но если об этом знать и знать решения, то это дело можно купировать.
-2
Вопросы о сервис-ориентированной архитектуре и микросервисах:
• В чём разница между SOA и микросервисами?

А-А-А-А-… как это развидеть ?!?!
0

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

+1
• Что случится, если я отсканирую зеркало?

Люли от владельца сканера? Вообще будет черный лист. Вопрос, судя по формулировке, не предполагает объяснения почему. Честно говоря я не знаю почему, но тем не менее он реально будет черный… а люли не приятными.

• Почему ответы Quora лучше, чем Yahoo Answers?

А что это? Я оба названия первый раз слышу. Или туда берут только тех, кто знает?

• Сыграем в игру: защитите Cobol против современных языков и попробуйте найти как можно больше разумных аргументов.

А если я кобол вообще ни разу в жизни не видел то тоже не подхожу?

upd.
Погуглил… афигеть, оно еще живо… и это с таким-то жутким синтаксисом.
0
Собственно, это его почти единственный плюс — если знать кобол, то тебе будут платить много денег за поддержание жизнеспособности ископаемого приложения на оном.
+1
Но если вдруг решат заменить прогу на что-то новое, то можно внезапно оказаться умирающим мамонтом без какого-либо представления о современных языках и сопуствующих им технологиях.
+2

"Заменить" обычно не моментальный процесс и подразумевает активное участие специалиста по заменяемому. Другое дело, если решат просто выкинуть.

+2
Если бы вы могли вернуться в прошлое, какой совет дали бы молодому себе?

Чувак, я из твоего будущего. Мой тебе добрый совет: иди на кружок бокса, авиамоделирования или дизайна. Не ходи в тот корпус, не ходи.
+6
Это не вопросы для собеседования, а дедовщина самая настоящая.
Выглядит так, будто чувак чудом устроился на работу и теперь на собеседованиях глумится над кандидатами
-1
Объясните Юникод или транзакции в СУБД пятилетнему ребёнку.
Просто объяснить или так, чтобы он понял? Если второе, надо ли в конце проводить проверку того, что пятилетний ребенок все понял правильно? А то, что мозг пятилетнего ребенка недостаточно развит для понимания концепций такого уровня сложности, автора не смущает?
+2
А то, что мозг пятилетнего ребенка недостаточно развит для понимания концепций такого уровня сложности, автора не смущает?
Вы сильно недооцениваете детские мозги. В этом возрасте они такие объемы информации перелопачивают, что людям зрелого возраста и не снились.
-1
Дело не в объемах информации, а в умении строить связи между абстракциями. Это приходит со временем, по мере развития мозга. В среднем по больнице, разумеется.

Можно объяснить первокласснику как решать дифуры. Только вы почитайте про судьбу вундеркиндов сами.
+1
Дифуры — это уже глубокая теория, требующая неплохой базовой подготовки, в которую не каждый зрелый сможет, в отличии от того, что буковки можно обозначать циферками, а некоторые операции можно обратить, как на «машине времени».
0
«Вы просто их не понимаете, раз не можете объяснить пятилетнему ребёнку»(Ц)
0
Скорее — передразнивание тех, кто советует объяснять всё условному пятилетнему ребёнку (а они разные) вплоть до квантовой механики.
-1
У меня двое детей, 2 и 11 лет. У меня есть знакомые с детьми, с кем я довольно часто пересекаюсь (ну и дети дружат, само собой). У одной пары 4 детей — 6, 4, 2 и 1 год, у другой — трое, 5, 3 и 0,5 года. Я отлично знаю, какие у них мозги в каком возрасте. Ну и профильную литературу (о развитии детского мозга) я тоже читал (правда, научпоп).
Вот лет с 9 — 10 уже можно начинать пробовать. Некоторые точно поймут.
+1
Будь вы на собеседовании, то сразу догадались бы, что надо объяснять не пятилетнему ребенку, а той здоровенной детине, что вас собеседует.
0
Безусловно, самое важное для бэкенд-разработчика, так это уметь отвечать на подобные вопросы:

• Составьте рабочее расписание команды, используя гибкий график (то есть без установленного рабочего времени) и политики отпусков «Бери когда понадобится».

• Как бы вы справитесь с очень большой текучкой и убедите разработчиков не покидать команду без повышения зарплаты? Что хорошего может сделать компания, чтобы они остались?

• Какие три главных качества вы цените в коллегах, кроме программирования?

• Какие три главные вещи о программировании нужно знать гуманитариям, по вашему мнению?

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


Чет мне кажется, это не каждому разработчику надо знать. А кому надо, к тому это знание само придет.
+1
Как бы вы справитесь с очень большой текучкой и убедите разработчиков не покидать команду без повышения зарплаты

Пневмопистолет с гвоздями, пару убедить — остальные сами останутся. Небольшая потеря производительности (прибитыми к столу руками код не набрать), но можно оформить их консультантами. Это будет крайне логичным решением, учитывая остальные вопросы при приёме на работу в компании.


вам один месяц и бюджет

А вот и средства для реализации пункта 2.

+1
Компания оплачивает те пару недель пока я буду читать им лекции, которые получатся в результате ответов на те вопросы которые знаю. Некоторые не знаю. Но на одном собеседовании и десяток их не обсудить. А на большинство открытых самый правильный ответ: «текущая мода такая, плюсы такие, минусы такие. Ультимативно запрещать себе какие-то вещи опрометчиво, стоит опасаться того и того, в целом практика такая, мне лично нравится вот так, но вот кейс контрпример где общественно осуждаемая практика быстро и качественно решила бизнес задачу, а потом либо была переделана либо исчерпывающе документирована и оставлена, ибо программы пишут чтоб денег фирма заработала»
+1
А где развёрнутые ответы? Вопросы любой дурак придумать может.
0
«А мы сами не знаем ответа. Давайте вы нам придумаете, а мы подумаем, прошли вы тест или нет» ;-)
+2
Средней креативности вопросы. Но есть и совсем дебильные:
Если Cat — это Animal, то верно ли, что TakeCare Cat — это TakeCare Animal?
+1

О, контрвариантность подъехала. Хотя по вопросу фиг догадаешься, чего вообще они хотят.

0
Догадаться то можно, конечно, но кто нам дал право расширять постановку задачи?
С точки зрения логики вопрос вырожденный.
-1
В такой постановке вопрос не имеет к LSP ровно никакого отношения.
0
Если Cat — это Animal, то верно ли, что TakeCare Cat — это TakeCare Animal?

Слово "это" — ("is a") это как раз про подтипы

-1
Не такой уж и дебильный. Про контрвариантность надо слышать, чтобы ответить.
0
Что вернёт эта функция JavaScript?


function hookupevents() {
  for (var i = 0; i < 3; i++) {
    document.getElementById("button" + i)
      .addEventListener("click", function() {
        alert(i);
      });
  }
}
About Type Erasure, what's the output of this Java snippet, and why?
ArrayList<Integer> li = new ArrayList<Integer>();
ArrayList<Float> lf = new ArrayList<Float>();
if (li.getClass() == lf.getClass()) // evaluates to true
  System.out.println("Equal");

Это специально так? Или это ошибка копипаста?
+1
Суть даже не в этом, а том, что функция то ничего не возвращает. Обработчики кликов навешиваются и есть «заковырка» с переменной i в цикле, но вот функция ничего не возвращает при этом.
+1

o return a value other than the default, a function must have a return statement that specifies the value to return. A function without a return statement will return a default value. In the case of a constructor called with the new keyword, the default value is the value of its this parameter. For all other functions, the default return value is undefined.

0
Ну да, точно. Давайте докопаемся до undefined.

Таким образом тут все вопросы можно разобрать до таких косточек, что HR повесится.
0

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

+6
Вредная статья.Сколько судеб теперь она поломает, сколько отказов в приеме на работу теперь получат именно достойные разработчики!
+3
Если бы мне задавали подобные вопросы на собеседовании, я был бы очень рад. Прекрасно, когда вместо экзамена собеседование превращается в общение будущих потенциальных коллег к обоюдному удовольствию!
Вопросы, в целом, хороши, поскольку они предполагают рассуждения, а не заученные ответы.
0
Приходите вы на пятое собеседование, а там вас ждет тот же список милых дикуссионных вопросов)
+7
Вы знаете почему крышки люка круглые, сколько шариков влезет в школьный автобус и как сдвинуть гору Фудзи?
Вы в совершенстве владеете балансировкой красно-черного дерева?
Ваши коммиты есть в опенс-сорс, решениях используемых в крупных компаниях?
Вы подняли и поставили на ноги более двух стартапов? Вы знаете SQL и no-SQL решения?
Віg Data и Data Science не пустой звук для вас?
Добро пожаловать к нам, на позицию Front-end developer в стабильный с 2002 года крупный enterprise проект документооборота в одном из крупнейших отечественных банков, в ваши задачи будет входить доработка UI части проекта на основе тикетов от группы поддержки.
+3
А нормально, что у меня 10+ лет экспы бэкендера, и мне 70% этой инфы никогда не надобны были? По-моему, это коллекция вопросов от с десятка разрабов занимающихся разными уровнями программирования. Я сторонник специализации, надо быть крутым в конкретной области (какой-то части стека), остальное попахивает дилетантством.
Не встречал еще крутого спеца по морде и по бэкенду одновременно. Что-то из этого будет хромать на фоне дева специализирующегося на чем-то одном, знающего весь инструментарий в совершенстве, когда какие языки и т.п.
0

Подобные вопросы часто ориентированы не на проверку конкретных знаний, а на широту кругозора. Грубо, поняли о чём вопрос — уже плюсик.

+11
Из личного.

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

Не смотря на отличное интервью с HR-ом, забородили на должность архитектора, не задав ни одного вопроса по архитектуре.

HR, пропускающий два раза подряд интервью по скайпу — так тоже бывает.

Давать непрошедшим кандидатам фидбэк — западло.

Лучший способ провести выходные — за решением тестовых заданий. Жена, дети, домашние дела — это всё ерунда.

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

Немного грустно, когда ты квалифицированнее собеседующего тебя «сеньора» и тебя не берут только поэтому.

+2
Походил по собеседованиям и понял одну вещь-все собеседования субъективны, особенно с HR'ами. Профессионализм и тесты-это всё вторично. Будет некая симпатия со стороны собеседников/нанимателей-напишут хороший отзыв даже при «неправильных» ответах, будет антипатия-будут всячески «валить». Никогда не заморачивался по поводу отказов или отсутствия фидбэка-не взяли-мне же лучше, найду лучше работу. И жизнь показывает что так всегда и получается.
0
С философской точки зрения — вы абсолютно правы :) Я просто поделился своей болью :) Хочется видеть более приближённый к решаемым задачам процесс отбора. В большинстве же случаев отбор происходит абсолютно хаотичный, а не по конкретным способностям. Это и удивляет. О чём-то подобном не так давно на хабре была статья.
0
Я замечал такое только в российских компаниях. Иностранцы более прагматичны и рациональны. Умеешь делать это и это? Нас устраивает. Российские очень придирчивые, хотя платят меньше. Парадокс. И ведь уже разъехались все кто мог, уже и рынок ИТ выскоблен до дна, и всё равно жизнь российского работодателя ничему не учит, продолжают привередничать. Ну ладно, подождём ещё лет 5, просто интересно посмотреть чем это всё закончится и когда уже завезённых гастарбайтеров-дворников начнут переучивать на программистов.
+1
Я замечал такое только в российских компаниях. Иностранцы более прагматичны и рациональны.

Эээ, тут вы не совсем правы. У иностранцев (Европа/США и т.п.) еще важнее личное впечатление, если у вас подвешен язык, вы улыбаетесь, на собеседовании шутите и говорите на хорошем английском ваши шансы намного выше чем у замкнутого ботаника, который обладает огромным опытом, но двух слов связать не может. В России с этим даже попроще.
-1
В чём я не прав? Вы же сами и подтверждаете мои слова. Я говорю что российские компании слишком много уделяют внимания непонятным тестам вместо того чтобы брать пусть и не блестящих, но старательных, позитивных и улыбчивых людей.
В России попроще с этим если вы землекоп. Во всех остальных случаях нужны связи и знакомства.
+1
Старательный и улыбчивый идиот — тоже перебор. Не стройте иллюзий по поводу западных компаний. Когда сталкиваешься, то некоторые вещи просто шокируют.
+2
что российские компании слишком много уделяют внимания непонятным тестам

Эти тесты и вопросы про люки, опишите свои недостатки или кем вы себя видите через 10 лет, пришли с Запада.

старательных, позитивных и улыбчивых людей.

Кто сказал, что человек, умеющий себя продавать, старательный? Ну и позитивность и улыбчивость тоже маска для собеседования. Часто вопрос не в блестящести, а просто в том что хорошо приноровившийся продавать себя товарищ мастерски научившийся проходить собеседования может оказаться никаким программистом и работником. Хуже всего что такие специалисты участвуют в собеседованиях и подбирают таких же спецов в команду, в результате в какой-то момент вся команды позитивная, дружная, улыбчивая… и ни черта не делающая и не умеющая.

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

Программисту? Никогда не требовалось, там скорее наоборот нужны связи и знакомства чтобы выйти на хорошего специалиста.
0
На самом деле, моя боль основана не только на российских компаниях :) Беседую и с иностранными. Там тоже местами забавно. Вот, например, американец два раза пропустил назначенное время начала Skype-интервью, а потом удивлялся, почему это я ему через пол часа уже не отвечаю. У меня же дел своих не может быть на другом краю Земли, я могу часами сидеть и ждать его ) Я считаю, что это полностью нормально с моей стороны после 30 минут считать интервью несостоявшимся по вине интервьюера и заняться своими делами.
0
Для крупных компаний на многие вопросы не обязательно знать все правильные ответы. В большинстве случаев проверяется знание математики, стрессоустойчивость кандидата и его умение работать со справочной документацией.
-3

В целом-то неплохой набор для создания собеседования. Правда, вот, не на бекенд и даже не на фронтенд, и даже не на программиста вообще, а на роль автора-теоретика для выпуска какой-нибудь очередной книжки из разряда "Стань программистом на… за… часов". Я не шучу, правда. Вся эта муть интересна, как теория. На практике же это не более, чем повод потолкаться в курилке, на хабре или в обществе себе подобных фриков где-нибудь в большой картонной коробке под мостом (это я про будущее, т.к. скоро программировать будет ИИ вместо нас и ряды маргинальных жителей трущоб пополнятся МИЛЛИОНАМИ небритых, патлатых и одиноких бродяг, готовых за еду на ...)

0
Кому-то придётся управлять ИИ, обучать его и контролировать, поэтому «патлатым» применение всегда найдётся ))
0
«Какие три главных качества вы цените в коллегах, кроме программирования?
Какие три главные вещи о программировании нужно знать гуманитариям, по вашему мнению?»

я считаю, важнее было бы:
— какие три главные качества/вещи вы хотите от вашего руководства?
— интересно ли вам, какие три главные качества/вещи хотят от вас?
0
Мне кажется, я что-то не понимаю в этой жизни. Теоретически, когда приходит специалист к Вам на работу — Вы в нём заинтересованы не меньше, чем он в Вас. А потому было бы справедливо, если бы соискатель также составлял список технических вопросов и это было бы вроде версуса — ты отвечаешь на мои, я на твои. Подготовить вопросы — гораздо проще, чем дать на них ответы да и ещё и в состоянии эмоциональной нестабильности(все волнуются на собеседовании). Дедовщина.
+1
если бы соискатель также составлял список технических вопросов и это было бы вроде версуса — ты отвечаешь на мои, я на твои.

А это можно сделать на любом собеседовании. Вас спрашивают о технологии X, а вы даете ответ и спрашиваете «а как реализовано в вашей компании? А почему именно так?», иногда техническую беседу можно построить в виде одних ваших вопросов «У вас так? А вы не сталкивались с проблемой Y? Сталкивались? Я помню на одном проекте ее решил способом Z. А как это работает с технологией N?», главное задавать вопросы и давать комментарии так чтобы все поняли, что вы в теме (это тоже не легко).
+1

Ну, на некоторых бывает "Вопросы здесь задаю я", но на таких радоваться нужно, что "провалил" :)

0
Или: «Я с удовольствием отвечу на ваши вопросы. Но у нас не осталось времени, к сожалению»
0
Почему в большинстве языков индекс массива начинается с нуля?

В Си массив — это указатель, индекс указывал смещение относительно начала массива.
Ты мог обратиться к элементу несколькими способами. через [], через *(pointer + 2) (не уверен, что правильно написал). Твой код был завязан на то, как массив хранится в памяти

Думаю, остальные языки просто продолжили традицию.
в PL/SQL и Паскале индекс начинается с 1, и всё нормально. В Перле по умолчанию ноль, но можно поменять, хоть на 2.
Думаю нет какой-то специальной причины, почему 0 во многих языках, где тебе похрен на то, как массив хранится в памяти. В других языках у тебя есть некая абстракция «массив», и ты не знаешь, как элементы хранятся в памяти: рядом, не рядом, а обращение к элементу массиву всегда происходит через операцию [] и никак иначе.
+1

Проще: потому что большинство языков старались быть похожими на C, а не на Fortran :)

+2
Паскале индекс начинается с 1

var a: array[-1..1] of integer; и вот он с -1, с 1 начинался во всяких примерах обычно.
Написали array[0… и он уже с 0.
Вот string в OP/Delphi с 1, потому как в 0 длина (и для совместимости в длинных строках).
И вообще массив начинается с low(массив), для динамических array of это 0.

-1
За что некоторые не любят java? При большом количестве понтов есть куча неадекватностей. Например:

1) Компилятор не разбирается в константных выражениях. Этот кусок кода компилируется, хотя содержит ошибку, которую можно выявить уже на этапе компиляции.
int i=(false?0:null);


2) Возможно неожиданное зависание в рекурсивной процедуре. Ни какой ошибки не выдается, просто висит.
 public static void work(){
        try{
            work();
        }finally{
            work();
        }
    }


3) Все говорят о high perfomance в java. IMHO high perfomance связан с утилизацией оборудования на полную катушку, а java далека от этого. Например, мало кто из джавистов знает, чем отличается физическая память от виртуальной, и что такое блокировка блоков в физической памяти. Ушел процесс в swap и будешь терять миллисекунды при просыпании. В примерах на параллелизм нет анализа, сколько процессоров в системе.

4) Все спрашивающие озабочены деталями, как работает сборщик мусора. IMHO в хорошей системе это не должно быть проблемой.

5) При переполнении числа не выдается ошибка, а просто идет по кругу. То есть можно не заметить переполнения и попортить данные.
 int i = Integer.MAX_VALUE+1;


Я нашел пунктов 10, которые меня смущают при всей рекламе крутости java.
+1
При большом количестве понтов есть куча неадекватностей.

Так можно про любой язык сказать если в нём разобраться.

+3
У Java много проблем никто не спорит (многословность, костыли обратной совместимости), но в данном случае у вас полно придирок и неточностей, лень все разбирать, но пример

1) Компилятор не разбирается в константных выражениях. Этот кусок кода компилируется, хотя содержит ошибку, которую можно выявить уже на этапе компиляции.
int i=(false?0:null);

Это и не должен. Такие вещи вроде «Integer x = null; int i = x;» приведут к ошибке, но сознательно не ловятся компилятором. Если программисты хотят они настраивают в IDE статистический анализ, который ловит такие странные вещи и не дает их скомпилировать или сделать коммит.

Во-первых, стандарт языка общий для большого количества Java компиляторов (да их много), усложнение проверок сильно усложнит реализацию стандарта (там и так много тысяч тестов, которые нужно пройти).
Во-вторых, компилятор сознательно не додумывает за программиста, хочешь бесконечный цикл — делай, напишешь так чтобы null pointer в первой строчки будет, компилятор не будет тебе мешать. Хочешь чтобы тебя ловили за руку — статические анализаторы (например, IDEA) тебе в помощь.
В-третьих, компилятор всегда компромисс между скоростью компиляции и количеством функций. Хочешь добавить сто тысяч подобных проверок — ожидай, что компиляция будет как в С идти медленно и печально. Это всем не надо, поэтому этого в стандарте нет.

2) Возможно неожиданное зависание в рекурсивной процедуре. Ни какой ошибки не выдается, просто висит.

Зачем так сложно? Можно же проще:
public static void work(){
       work();
}

Бесконечная рекурсия, где система просто весит и в лучшем случае упадет с стак оферфлоу экспешнеом. А что вы тут ожидали? Можно еще бесконечный цикл написать — тоже система повиснет. Это ожидаемое поведение, компилятор не должен за вас решать нужен ли вам бесконечный цикл/бесконечная рекурсия или нет. Но это тоже ловится статистическими анализаторами, надо — включайте, не надо не включайте.
0
Ну вы уж все разберите, а то у меня сомения, — использовать джаву или нет в своих проектах. Сначала купился на рекламу, а копнул глубже и взялся за голову.
+2
А смысл? Проблемы и плюсы джавы совсем не в том что вы описывает.

3) high perfomance в java — надо понимать, что java почти всегда медленнее C/C++ и его аналогов (Go, D и т.д.), но скорее всего быстрее многих высокоуровневых языков. В целом, просто для серверных приложений, бекэнда, обработки больших данных и т.п. производительности Java хватит с головой, а если тормозить будет то скорее из-за кривых рук. Вопросы кол-ва процессоров, памяти и т.п. можно отдать на откуп виртуальной машине, она в большинстве случаев сама разбирается. Это нелепо когда пытаются оптимизировать производительность на копейки, когда один кривой sql запрос сжирает в тысячи раз больше ресурсов. Для простых задач вы скорее упретесь в пропускную способность сети, кол-во открытых портов, скорость работы жесткого диска или базы данных.
С другой стороны, если вам нужна максимальная производительность на уровне C++ (игрушки, ОС, драйверы, 3D моделирование и прочее) — вам не к Java.

4) Сборщики мусора в Java (их несколько на выбор) очень сложные и отлаженные системы. В 90-95% случаев стандартный и так будет хорошо работать. Но с помощью выбора сборщика и его настройки можно получить приличный выигрыш в оставшихся 5-10%. Поэтому знать его работу — полезно (ну и чтобы не сделать утечек из-за кривых рук).

5) Можно, это решение архитекторов языка. Вероятно причина в производительности (каждый раз проверять на переполнения — дорого), Integer хранит 2 млд. значений, крайне редко кому-то удается вызвать переполнение без танцев c Integer.MAX_VALUE или ошибке в коде, А вызвать переполнения long или BigInteger — вообще крайне сложно. Если у вас может быть переполнения используйте long/BigInteger или специально проверяйте на переполнения.

Сначала купился на рекламу

Зря, у Java есть своя ниша где ей хорошо (бэкэнд, сервера, большие данные), плюсом — огромное кол-во библиотек и открытых проектов на любой вкус и тупо много вакансий, разработчиков и уже существующих приложений.

Но для новых проектов есть более интересные языки в мире JVM (скала, котлин), для десктопных приложений под Вин — лучше взять, скорее всего что-то вроде Net. Если вам интересны самые новые подходы в разработке — в Java новые возможности приходят медленно и печально (впрочем для энтерпрайза это скорее плюс).

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

Как способ всегда иметь кусок хлеба хороша, как средство разработки приложений на десяток лет — тоже, как очень стабильная и продуманная экосистема — тоже, но не как убийца С++ или самый модный язык с самыми последними функциями. Ну и она просто многословна.
0
Примерно понятно, что Вы имеете в виду. У меня круг задач другой был до недавнего времени.
На счет переполнения чисел для меня была самая болезненная проблема в одном проекте, в котором было много математики. Проект работает, работает, а потом фиг знает где начинает что-то глючить. И разобраться трудно. Приходилось обкладывать проверками вручную. На паскале, например, есть опция компилятора, которая заставляет при переполнении вызывать исключение и отладчик.
0
Каждый раз получаю море удовольствия когда работаю в приложениях на джаве. Для примера есть PHPStorm. В проекте с magento 2 (несколько К файлов) индексация занимает до минуты на i7 с 16 гб и, что самое главное, ssd. И вот после этого у меня большие подозрения на скорость выполнения, хотя и кривость кода допускаю, конечно.
+1

Знаете что-то схожее по функциональности с большей скоростью работы?

0
Все что на джаве — похожи. Раньше пользовался NetBeans, он довольно неплох и тормозит меньше, как мне показалось.
0

Не следует ли отсюда, если не вывод, до гипотеза: фичи требуют ресурсов, а язык вторичен?

0
Думаю что следует. Хотя все по-разному. Например, я знаю что исходников у Хрома много и собирать все это тоже долго. Но ведь нет такого что когда Хром 10 лет назад был легче то вкладка открывалась за 1 секунду, а сейчас, когда он в n раз тяжелее, то вкладка открывается 1*n секунд. Количество фич не особо влияет на скорость, я хочу сказать.

А вот когда все в абстракциях и или код не очень, то начинается phpstorm. Это мое мнение дилетанта.
0
С одной стороны мы рискуем уйти в холивар, но с другой от языка ожидаешь некоторого уровня контроля за кодом «по-умолчанию». Вот я бы (на java не пишу) ожидал бы, что в настройках по умолчанию java выведет как минимум 2 варнинга в compile-time.

int i=(false?0:null);

Просто по анализу AST проверить семантику типов в операции. Для языка со строгой типизацией, неужели сложно?

 public static void work(){
        try{
            work();
        }finally{
            work();
        }
    }
Цикл без выходной дуге в графе вызовов? Тоже практически без накладных расходов (при компиляции). И тоже я бы ожидал от java увидеть при компиляции варнинг.
0
ожидал бы, что в настройках по умолчанию java выведет как минимум 2 варнинга в compile-time.

1) Null можно использовать как любой тип. То есть выражение «условие? число: null» — полностью корректно. Если бы было Integer i=(false?0:null); — это было бы 100% рабочее выражение. Если бы была число и скажем строка вместо null — программа бы не собралась.

2) Данное выражение не константа, оно аналогично следующему коду с точки зрения компилятора:
    Integer tmp;
    if(false) {
         tmp = null;
    } else {
         tmp = 0;
    }
    int i = tmp;

Есть общее правило, при касте null к примитивному типу — выкидывается NullPointer, делать исключение только для такого крайне редкого случая когда можно вывести значение при компиляции не стоит. На самом деле, в новых языках пытаются избавиться от проблем с типом null, но 20 лет назад это казалось хорошим решением, а потом уже поздно было ломать обратную совместимость.

Цикл без выходной дуге в графе вызовов? Тоже практически без накладных расходов (при компиляции). И тоже я бы ожидал от java увидеть при компиляции варнинг.

В ряде случаев это корректный код, скажем иногда используется код «for(;;) {...}» для того чтобы один тред висел в бесконечном цикле, а другой делал работу.
0
2) Данное выражение не константа, оно аналогично следующему коду с точки зрения компилятора:


Почему тогда effective final в java вычисляется без проблем? Это ж по сложности вычисления примерно одно и тоже, что и константные выражение.

       int a=1;   // effective final
        class test_a{
            test_a(){
                System.err.println(a);
            }
        }


       int a=1;
        class test_a{
            test_a(){
                System.err.println(a); // ошбика ожидается final или effecive final
            }
        }
a=2;  // переслало быть effective final
0
Подсчитать количество присвоений переменной — просто, вычислять значение переменной — сложно и опасно. Скажем, есть код:

class A {
    private int a1 = 1;
    private final  int a2 = 1;
    private final static int A3 = 1;  
    
    public void method() {
         // Чему равны a1, a2, A3 ? 
    } 
}

Чему равны a1, a2, A3 в method()? Всегда 1? А если возьму Java reflection и поменяю в промежутке между созданием и вызовом method() все значения на 2 (насколько помню это возможно даже для private final static, хотя там могут быть свои подводные камни)? А у вас компилятор уже заложил, что там всегда будет 1.

Зачем заниматься оптимизацией, которая сломает Java reflection, разное поведение для локальных переменных и приватных полей класса — тоже будет сбивать с толку (представьте вы просто перенесли переменную из приватного поля класса в локальную переменную функции и компиляция упала)?

Потом не забывайте простую вещь, по-хорошему каждый Java программист должен знать стандарт языка наизусть (хотя бы для ответа на собеседовании, а что вернет Java в этом коде), то есть каждая такая оптимизация потратит несколько минут/часов жизни у каждого изучающего Java на проф.уровне, а это огромные потери времени в сумме для всех программистов. Оно того стоит?
0

effective final — оно про поля метода и на поля класса не распространяется. А до значения переменной/константы внутри тела метода без дизассемблирования-перекомпиляции (хоть это и возможно на лету) вы никак не доберётесь, в том числе и рефлекшеном. Ну а дизасм-перекомпиляция создадут новый инстанс класса и загрузят его через лоадер.

0
Я отвечаю не про effective final, а про следующее:

Компилятор не разбирается в константных выражениях. Этот кусок кода компилируется, хотя содержит ошибку, которую можно выявить уже на этапе компиляции.
int i=(false?0:null);


Возьмем код

public class A {
    private final B b = null;
    private final static C с = null;

    public method1() {
           b.test();
    }

    public method1() {
           c.test();
    }
}

Вот тут некорректно просить компилятор, чтобы он не стал копилироваться. потому что там будет NullPointerException, потом что в реальности с помощью рефлексии там может быть вовсе не NullPointerException (это нормальное поведение для всяких библиотек типа JPA/Hibernet/Dependecy injection).

Ну и разная компиляция у схожего кода — будет странной:
public class A {
    private final B b1 = null;

    public method1() {
           final B b2 = null;
           b1.test();
           b2.test(); // странно если компиляция b1 и b2 будет
// происходить по разным правилам и b1.test(); пропустит, а  b2.test(); нет.
    }
}


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

Ну наверное не стоит демагогией заниматься. Я ответил на один кокретный ваш комментарий, где вы некорректно отослались к полям класса, как допустимым к вычислению в режим effective final, хотя на самом деле это не так.


В спор про условную корректность компиляции int i = (false:1:null) я вмешиваться не стал.


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

0
У Java много проблем никто не спорит (многословность, костыли обратной совместимости), но в данном случае у вас полно придирок и неточностей, лень все разбирать, но пример

Просто к тому времени, как она появилась (год 95й), я уже несколько лет программировал на С++ и pascal. Сейчас решил перескочить на что-то более удобное. Но впечатления неоднозначные. Особенно с отсутствием контроля переполнения арифметики и кучей «удобств», которые сначала задумывались как лучше, а получилось как всегда. Молодым может и норм, но мне хотелось бы не ходить по кругу, а получить качественный инструмент не хуже того, что я использовал до этого.
0
Когда кэш не нужен и даже вредит?

Когда позволяет читать память других процессов из-за ошибки в реализации спекулятивного выполнения команд процессора?

+1
После такой статьи я ожидал увидеть у автора околонулевую карму. А она 385,5
Да и плюсов у статьи 36.
Хабраюзерские фишки видимо))
+2

Просто не все воспринимают собеседование как экзамен :)

0
1. Это перевод за что автору-то карму снижать?
2. У автора 154 публикации, достаточно чтобы набрать кармы,
3. Часть вопросов полезные, часть вопрос — вредные, но их тоже могут задать на собеседовании. Интервью по этой статье проводить я бы не стал, а вот просмотреть вопросы при следующем поиску работы — имеет смысл.
0
За этот перевод карму немного отняли, так что не волнуйтесь, всё справедливо. :)
-1
Вопросы по логике и алгоритмам:
• Написать пример кода, который создаёт утечку памяти.

Уже третий час не получаеться сделать на javascript, это задание для гениев.
0
Надо знать особенности сборщика мусора. Некоторые сборщики не обрабатывают циклические ссылки изза того, что используется счетчик ссылок. К java не относится. На javascript не проверял еще.
0
Попробовал с циклическими ссылками — не удалось добиться утечки.
Находил такое «IE до версии 8 не умел очищать циклические ссылки».
Также встретил предположение что утечек воможно добиться через замыкание, но достичь желаемого эффетка не удалось, либо V8 слишком умна, либо делал что-то не так.
Т.е. технически такое возможно (к примеру в IE), но т.к. задача находилась в разделе «Вопросы по логике и алгоритмам», считаю случай с IE не показательным, мелкомягкие всегда умели порадовать своих фанов.
0
В java у меня один раз получилось для частного случая. В базе oracle можно писать процедуры на джаве. Я забыл закрывать какой-то объект для передачи UDP датаграм. Думал, что сборщик мусора должен автоматически закрывать системные хэндлы, а он зараза не закрывал. И после некоторой работы все UDP порты были заняты, что приводило к коллапсу системы.
0
Думал, что сборщик мусора должен автоматически закрывать системные хэндлы, а он зараза не закрывал

А с чего ему их закрывать? Сами закрываются они только вместе с JVM

0
Ну вот считай утечка. Пооткрывал всякой всячины: файлов, портов, конектов… Объекты java удалил, а системные хэндлы остались.
0

Это в каком это месте утечка? Или у вас в каких-то других языках хендлеры сами закрываются?
Ну и как написал уже ApeCoder есть удобные языковые конструкции для закрытия хендлеров после окончания использования. Их просто надо использовать. Но никто не заставляет — вдруг у вас какой-то хендлер должен жить весь ЖЦ приложения.

0
В пыхе все само релизится, когда пыха обработала запрос.

зы. если это конечно не реакт-пхп или чтото подобное
0
Потому что время жизни самого приложения на пыхе в большинстве случаев ограничено временем выполнения самого запроса, не? (опять же, как вы верно сказали, если это не какой-нибудь react-php)
0

Ну вы познакомьтесь с понятием ЖЦ приложения и поймёте что это оно. Только в Java сессия жизни не ограничена одним запросом и не вынуждает придумывать способы быстро загрузить/закешировать данные приложения, которые нужны между сессиями. Естественно, при этом, заставляя разработчиков больше думать о других нюансах.

0
А в чем проблема? Берешь цикл, в цикле что-нибудь считаешь и для хранения временных данных создаешь в DOM объекты. Ну, попутно каким-нибудь прилагающимся к DOM методом временные значения обрабатываешь.

Самое главное — не удаляй их. Просто не удаляй. Забудь. Ну цикл еще эдак на миллионов десять итераций.

Профит? :)
+1
«Послушаешь вопросы на собеседованиях — не иначе как гениев ищут. Посмотришь код проекта — и куда только всех гениев дели?»((с)тырено)

Людей следует искать под конкретный проект, конкретную задачу а не «сферического программиста в вакууме». Соответственно этому нужно и готовить список вопросов. В обсуждаемой статье отсутствует цель найти кого-то определённого, т.к. слишком много направлений затронуто (frontend, backend, менеджмент, архитектура...). К тому же, чтобы обстоятельно ответить хотя бы на половину вопросов, да ещё и с неминуемыми уточнениями по ходу разговора, денька два может уйти влёгкую. Пойдёт-ли на такие расходы фирма и согласится-ли на такое, с позволения сказать, собеседование мало-мальски толковый профи — вопрос, думаю, риторический.

Вот как своеобразная шпаргалка, база «дежурных» вопросов (а скорее — тем для построения своих вопросов) эта статья очень даже полезна, как по мне.
0
«Послушаешь вопросы на собеседованиях — не иначе как гениев ищут. Посмотришь код проекта — и куда только всех гениев дели?»((с)тырено)

Видимо причинно-следственная связь иная: гениев на проэкте изначально не было, и в какой-то момент, увидев код, решение становиться очевидным — нужен гений.
0
Я больше склоняюсь к мысли, что тут работает простое и понятное желание получить лучших из лучших (а платить им… в лучшем случае как среднячкам). Вот только очень уж часто работодатели забывают что это всё-же СОбеседовавшие, которое предполагает СОтрудничество. Из чего следует, что потенциального работника нужно таки заинтересовать, а не продемонстрировать/выпячивать своё превосходство.
+1
В принципе, многие вопросы и правда неплохо понимать хотя бы на общем уровне. Вот только если требовать прям глубокие знания по большинству пунктов, то закономерно упираемся в ограничения нашего мозга. Долговременная память и навыки формируются с затратами времени: частой практикой, повторением изученного. Подробнее текст о системной консолидации. Кроме того, поддержание знаний требует ресурсных затрат, и в мозге закономерно работает вытеснение, дабы не тратить ресурсы на ненужное.

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

Т.е. чтоб держать в голове пачку глубоких и порой нечасто используемых знаний, надо себя заставлять их постоянно поддерживать или реально быть увлеченным. Если большая часть времени тратится на задачки для собеседования, вопросы и прочие тесты, то времени и сил на реальные интересы может не оставаться. Стоит ли это редких блистаний у привередливых собеседователей, которые как правило не являются лучшими работодателями и коллегами (согласен с комментарием)? В любом случае, я рад что рынок есть и он довольно свободный. Всегда можно просто не связываться с теми, с кем не удобно. (:
+1
Попадались такие «спринтеры»: собеседование проходят на ура, но ни строчки реального кода не оставили после себя! Заметили закономерность — это «преподаватели» всяких курсов. Полная оторванность знаний от практического применения.
Либо люди с легкой руки одного сотрудника названными «с альтернативным мышлением». Человек либо фанатик в определенной области, что остальные просто выпадают из поля зрения. Либо комплексы двигают показать свое превосходство над кандидатом.
+3

Я воспринимаю вопросы на собеседовании не как требования, а как способ узнать какой кандидат пришел. То есть он может не ответить на какое-то количество вопросов и, может быть, никто не может ответить на них все — но дает представление о кандидатах. Это как линейка которая должна быть длинее измеряемого объекта, но объект может быть меньше линейки и все равно нам подходить.


По результатам может быть вывод "Реально крутой в ООП чувак но хреново с облаком, но у нас есть Вася он его научит".


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

0

Прекрасное сравнение с линейкой! В самом деле, чтобы понять где заканчиваются знания человека, придётся задавать вопросы до тех пор, пока на какой-то он не сможет ответить. Но цель интервью же не в том, чтоб измерить уровень, а в том, чтоб понять. подходит ли человек именно нам.

0

А может быть ответом на вопрос "подходит ли человек нам" не, boolean а функцией? Например, подходит, но при условии что у нас будет эксперт по X. Или подходит, но на новый проект надо нанять Y. Или "в принципе подходит, но если среди пула кандидатов будет чувак знающий Z мы выберем его".

+1
Это как линейка которая должна быть длинее измеряемого объекта, но объект может быть меньше линейки и все равно нам подходить.

знаете, что самое смешное? Метрическая система была задумана как раз с тем, чтобы используя метровую "линейку" можно было измерить километровое поле.

0

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


Еще


Так же, я воспринмаю этот текст как палитру вопросов из которых можно выбрать а не перечень вопросов которые обязательно можно задать все.
0
Но метры ткани и километровые поля наверняка на практике измеряют используя разные инструменты, да?

Конечно да, банально с тканью в большинстве случаев допустима погрешность при условии ускорения измерения. Ну и, соответственно, пользуются разметкой на раскроечном столе. А поле столом не померяешь — в худшем случае берётся деревянная линейка (а то и просто шаблон) на метр-два и с её помощью измеряется. В лучшем случае промер происходит в несколько замеров с использованием оптических измерительных приборов.


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

0

Хорошо. Понятно ли какую мысль я хотел передать своей несовершенной аналогией?

0

В целом понятно, но есть сомнения в полной аутентичности — неудачно модель на процесс ложится...

0
— Как вы отсортируете файл 10 ГБ?
— Что?
— Фильм например, у вас есть блюрей дамп, отсортируйте его.
— …
+3

Если байты по возрастанию значения — один проход counting sort. Если же кадры фильма по убыванию эмоциональной напряженности…

0
Чо то я совсем не пойму как избавиться от ифов в примере про TheService, понятно что можно их спрятать в отдельные методы, но как я понимаю это не будет «тру ооп».
Есть какие нить идеи?
+1
Многие критикуют подобные вопросы. Интересно было бы узнать их мнение — как с определенным процентом уверенности убедиться, что пришедший на собеседование программист достаточно компетентен?

«Почему люки круглые» — плохо.
«Напиши с нуля какой-нибудь из алгоритмов» — плохо.
«Абстрактный вопрос для того, чтобы завязалась дискуссия» — плохо.
«Покажи код на гитхабе» — плохо.

Как убедиться, что человек знает и умеет, а не пытается «проскочить»? Не брать же каждого соискателя на испытательный срок? Пока поймет что к чему и втянется в процесс, пройдет не меньше недели. Так можно месяцами искать.
0
Как убедиться, что человек знает и умеет, а не пытается «проскочить»?
Люки или академические алгоритмы в этом точно помогут? Репозиторий с открытым кодом — это хорошо, если он есть, может быть плюсом.
Спрашивать о том, что будет необходимо в работе? Про интересующие работодателя технологии, как что работает и взаимодействует. Про архитектуру: как бы вы спроектировали то-то и то-то. Иметь компьютер с подготовленным учебным проектом, чтобы предентедт сделал намётки новой фичи или исправил хитрый баг.
Про прошлый опыт попросить рассказать. Ну и ряд вопросов на ширину кругозора (не в зачёт).
0
Многие критикуют подобные вопросы. Интересно было бы узнать их мнение — как с определенным процентом уверенности убедиться, что пришедший на собеседование программист достаточно компетентен?


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

0
Вы не поверите, так и ищутся — месяцами, даже без испытательного срока.

Как вариант NDA + доступ + реальная задача = 1-2 дня и любители халявы отвалились, некоторые не справились, с остальными можно посмотреть.
Only those users with full accounts are able to leave comments. , please.