Почему полезно изобретать колёса

[aamonster]

Ошибка в переводе — Java вместо Javascript в первом абзаце (а потом думаешь: "что, в Java тоже есть промисы?")

[gecube]

Полностью поддержу. Мой взгляд тоже зацепился. Только я подумал, что речь про энтерпрайз разработку, как, оказывается, что речь про JS.
И, да, Java тоже умеет в промисы/futures.

[JustDont]

Он писал код сразу на доске

Когда уже наконец вымрут люди, считающие, что код в какой бы то ни было ситуации уместно писать на доске?

[ip1981]

Чем доска отличается от Вима?

[Cerberuser]

Тем, что на доске нельзя написать :sh?

[Neikist]

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

[Enfriz]

От доски можно отойти в любой момент, а вот выйти из вима…

[maxzhurkin]

:q!
не благодарите

[vba]

Хм, по мне так вы довольно таки вольно перевели(как и сам заголовок статьи):

Разработчики считают готовый код самоочевидным (Developers Take Abstractions For Granted)

Я бы сказал что тут речь идет о том что разработчики воспринимают абстракции как данность. Смысл абзаца под заголовком это подчеркивает.

А так по сути статьи, могу сказать, что на мой взгляд у автора(не переводчика) в голове каша. Не хотите абстракций, попросите собеседуемого, наваять вам простенькую версию "протокола HTTP 1", желательно на ассемблере.

А проверить понимание концепций можно простыми вопросами, от простого к сложному.

[Amareis]

Ну кстати для себя я сформулировал это как "понимаешь — это когда можешь сделать сам". Если человек понимает промизы — он может набросать их черновую реализацию. Замыкания, генераторы, event loop и что там ещё популярно на собеседованиях? То же самое, хотя такие низкоуровневые вещи обычно всё же пишутся уже на другом уровне. Прототипное наследование и оператор new можно написать и на js.

Поэтому и существует подход "пишем свой react/mobx/эмулятор процессора и т.д.", ведь в обратную сторону тоже работает — если можешь сделать сам, значит понимаешь. Хотя тут свои нюансы есть.

UPD: а, подзаголовок оригинала так и звучит: To truly understand the wheel, you need to reinvent it

[wormball]

> Ну кстати для себя я сформулировал это как «понимаешь — это когда можешь сделать сам».

Это не вы, это Фейнман.

[TheShock]

Сформулировал сам — понял Фейнмана

[TerraV]

Мне нравятся подобные собеседования потому что позволяют при минимальных временных издержках избежать разочарований и нервотрепки работы со «звездами». С учетом необъятности технологий фокусироваться на деталях реализации это только тешить свое самолюбие. Естественно спрашивающий лучше подготовлен и может свысока поплевывать на кандидатов — «о, еще один недосеньор, что он там о себе возомнил». Вообще сеньорство это не про технологии. Мне нравится определение junior — пишет код, middle — решает проблемы, senior двигает компанию вперед. Сеньор это человек который смотрит за горизонт. Старается предугадать проблемы которые еще только возникнут, старается понять потребности бизнеса и за счет телефонного разговора на 10 минут может сэкономить 2 месяца разработки. В интервью выше даже возможности раскрыть потенциал не было. Потому что «надо знать реализацию промисов».

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

[gecube]

Золотые слова. Т.е. с Вашей колокольни — любой человек ценен, но возможно, что не в этой компании, не в этой команде.

[TerraV]

Скажем так, я считаю это хорошей отправной точкой для начала диалога.