Comments 24
Меня всегда удивляла такая критика. А кто проводит технические собеседования - не разработчики?
Сначала поныл, а потом сам начал учавствовать у процессе найма с такими же вопросами?
Может быть, это отпечаток университетских лет
Нет, не поэтому. Так делают потому, что так проводят собеседования в самых коммерчески успешных компаниях мира. Когда изобретут новые методы проведения собеседования, и компании практикующие эти новые методы станут успешнее других, то и везде станут делать по-новому.
Мы на собеседовании не спрашиваем теорию. И код писать не просим. Мы правда со-беседуем. Разговариваем. Это нормально. Правда)
Представьте себе известного писателя, такого как Стивен Кинг, который задал вопрос о разнице между deus ex machina и Мэри Сью. Изменит ли его ответ качество его книг?«Который задал» = «которому задали»?
Плохой пример) Эти термины знает любой образованный человек, интересующийся литературой. Тем более Стивен Кинг, который как раз попадает в категорию учителей: он написал книгу «Как писать книги», в которой дает советы писателям.
но я могу использовать это, и я могу использовать это во благо
Что-то вы путаетесь в показаниях. Если вы реально пишете сложные расширяемые и отказоустойчивые приложения, то какой для вас труд пояснить мотивацию своих действий? А кристаллизованная правильная мотивация - это как раз и есть всякие солиды, паттерны, лучшие практики и т.д.
Сколько я собеседую людей, столько я убеждаюсь в том, что чем лучше человек понимает как работает та или иная технология, тем эффективнее он будет ее использовать.
Если разработчик не понимает алгоритмическую сложность операций, его код приведет к проблемам перфоманса.
Если админ не понимает как работает NUMA, он будет ловить гуков, что два одинаковых сервера работают по-разному.
Если сетевик не понимает как работает BGP, он объявит что-нибудь ненужное на весь интернет.
И так далее.
Какой дешёвый перевод, не говоря уже про слабость статьи-оригинала
Что такое компьютер? Что такое электричество? Что такое электрон? Никто не знает точно.
Каждый раз, когда я включаю свой компьютер, это чудо. Я понятия не имею, что происходит, но оно просыпается, оживает
И не стыдно же признаваться в тупости...
Я не оправдываю статью, да и вам плюс поставил. Однако сложные системы мы знаем лишь с определённой степенью детализации. Лично я про включение компьютера могу рассказать про кольца защиты, GRUB, но наверняка кроличья нора сильно глубже. Ну и признаваться в тупости совершенно не стыдно, а иногда и полезно :)
Фейнман говорил, что на любой вопрос мы можем дать ответ лишь до какого то уровня понимания. Он приводил пример - почему человек сидя на стуле не падает? Любой может ответить потому что его держит стул, кто-то более грамотный скажет что сила притяжения уравновешена силой сопротивления стула, а потом все глубже и глубже, надо объяснить что такое сила гравитации и как появляется сила сопротивления, что такое поля, как они взаимодействуют на атомном уровне и с какого то момента он уже сам не знает как оно там все работает на более детальном уровне.
Так на собеседованиях обычно не спрашивают про инструкции ассемблера. Для написания программы не обязательно знать микроархитектуру процессора.
Но, например, умение оценить "сколько памяти расходуется при выполнении алгоритма" - уже важно. Иначе простая операция пожрет все ресурсы, а программист будет пенять на сисадмина, который сервер плохо настроил.
Не знать каких-то вещей не стыдно. Стыдно оправдывать нежелание разобраться - философскими рассуждениями про "монстров Франкенштейна". Тем более когда эти вещи имеют непосредственное отношение к твоей работе.
Не стыдно признаваться в том, что не знаешь чего-либо. Особенно, если собираешься это исправить. Или если это знание не относится к общеобразовательным и не касается профессиональной области. А когда программист не знает школьный курс физики, не понимает хотя бы в общих чертах принципов работы компьютера, да ещё и считает это нормальным - это глупость, которой стоит стыдиться.
"что такое электричество" это какой-то мем современной молодежи, не раз уже слышал. Нет бы хоть что поинтереснее придумать - что такое ноль, например
Каждый раз, когда я включаю свой компьютер, это чудо. Я понятия не имею, что происходит, но оно просыпается, оживает, и я могу общаться с ним на его собственном возвышенном и тонком языке.
Так что еще раз я должен повторить священную мантру:OM. SOLID SOLID SOLID. Fabric, Decorator, Dependency Injection. OM.
Для того и спрашивают теорию - убедиться, что человек понимает суть того с чем он работает. А не заучил как мантру, аки техножрец из вархаммера.
Надеюсь, автор не забывает перед каждым включением натирать компьютер священным маслом и окуривать ладаном. All praise to the Omnissiah.
Когда тебе следует остановиться? остановиться, чтобы сказать себе: вот это не стыдно не знать. Ты можешь выбрать эту линию самостоятельно, а можешь поручить определить её кому-то другому. Но ты можешь быть совершенно уверен, что, например, будешь полнейшим болваном, когда утверждая, что знаешь Java, ты не будешь Thinking in Java.
Но вот тебя берут и покупают. И делают из твоего thinking то, что диктует рынок. Так они покупают твоё мышление, даже не зная о твоём лично существовании, и, что самое грустное, – тебе за покупку тебя ничего не платят.
Всё это они называют необходимостью постоянно учиться в IT. Хотя необходимость постоянно учиться в IT это про то, что говорится здесь в первом предложении, а не про то, как хомячки в колесе бегут за морковкой маркетологов, изучая модные в этом сезоне техно-мантры.
Многие проводят собеседования по некому шаблону не понимая зачем они это спрашивают. Ну типа потому что яндекс так делает или гугл. Загадывают ребусы алгоритмические и прочую ахинею, которая никак не оценит вас как специалиста.
Знаю что многие проходят собесы просто уверенно вызубрив теорию, а потом их увольняют, потому что не тянут и нет опыта.
Тенденция идёт к отказу от таких бредовых собесов, надо проверять мышление и опыт, а не зубрил. Сейчас большинству компаний наплевать на ваш опыт и сделанные проекты, главное чтобы вы решили загадки, ребусы и красиво рассказывали паттерны проектирования.
главное чтобы вы ... красиво рассказывали паттерны проектирования.
В чем проблема рассказать про паттерны, которые вы реально используете? Допустим, у вас микросервисы и вы используете паттрен API Gateway. Вы испытываете затруднения объяснить, зачем он нужен? Или вы пишете на Node.js и используете паттерн Reactor (aka Event Loop). Снова пояснить не можете? Или вы пишете на Spring и у вас по всему коду расставлены аннотации Transactional. Что, опять какая-то проблема пояснить, как работают прокси? Может не в плохих собесах дело?
Ну а если из вас настойчиво трясут то, что вы в глаза не видели, то голосуйте ногами из такого места.
Так с опытом как раз и приходит понимание, для чего нужна вся эта скучная теория, и как оно все работает под капотом.
Собеседования в компании проводят люди. Люди, которые раньше пришли в эту компанию. Если эти люди при устройстве тоже проходили через теоретические вопросы/алгоритмические секции/загадки, то закономерный вопрос - "Я, понимаешь, через весь этот shit прошел, почему ты, дорогой кандидат, должен этого избежать?" Вот и воспроизводят то, что было с ними в прошлом. Разумеется, все это на подсознательном уровне происходит. А уж кто это занес в компанию - это другой вопрос.
Это как с коррупцией в органах власти. Там же, когда человек туда приходит, никто не учит схематозу, откатам и прочее. Люди просто видят, что вокруг происходит и воспроизводят/копируют успешное поведение.
Оно живое