А может быть вопрос неверный? Человек вообще на данный момент не хочет работать «в вашей компании», он просто присматривается. А вопрос «почему вы хотите работать у нас» сразу ставит компанию выше вас, типа у нас все хотят работать, мы знаем это, даже не спрашивая вас. А то что вы предлагаете ответить — логично отвечать на вопрос «Что вы думаете о нашей компании после собеседования, какие у вас впечатления?»
Поддерживаю статью, но подумалось, что условные юристы, прочитав эту статью, скажут во программисты зажрались, нам самим резюме приходится везде просовывать нерелевантные на вакансии, а тут с точностью да наоборот, рыба сама в сети идет и им не нравится :)
Ну да, давайте сразу писать веб-приложения и продумывать архитектуру под 100 миллиардов пользователей в секунду. Сразу делаем производительное приложение из расчета, что у нас всё население земли будет им пользоваться 24x7 и еще 94 миллиарда инопланетян, которых мы обнаружим
Мне понятно откуда берется желание обесценить, но всё-таки давайте будем разумными и смотреть на цифры и факты. Считать что Яндекс, у которго сотни продуктов, петабайты данных, мегахайлоад, компанией, которая держится на студентах без опыта, посидевших 3 месяца на leetcode это в высшей степени неуважение. У них точно также внутри как у всех есть синьоры, мидлы джуниоры, которые получают разную зарплату в зависимости от опыта. Причем опыт меряется не фреймворками, а более фундаментальными вещами: работа с бд, паттерны проектирования, микросервисная архитектура, профилирование и отладка и т.п… Мерять опыт фреймворками — это тоже заблуждение, о чем я уже писал в предыдущем посте. Если вы пользовались какой-нибудь SuperMegaDistributedYandexDb, то и с Postgresql быстро разберетесь. Кроме того у яндекса есть, как вы выразились «Яндекс.Велосипедофрейморк» под названием ClickHouse. А React — это «Facebook.Велосипедофреймворк». Вы думаете фреймворки в лесу собирают, они там сами растут?
Вы всё с ног на голову перевернули. Человек умеющий оптимизировать запросы, будет разбираться и в алгоритмах, как субд оптимизирует. Человек умеющий реверсить списки на листочке не сможет сразу сказать как оптимизировать запрос без практики оптимизации, тем более если он вообще о субд ничего не знает. Так может и стоит спрашивать оптимизацию запросов на собеседовании если она нужна? Да не бред какой-то, давайте алгоритмы.
Вы серьезно? Да в любую сторону ткни, нужны знания. Одно только поле знания баз данных неисчерпаемое. Как человеку помогут знания алгоритмов в написании эффективного запроса, если он даже SELECT не делал?
По-моему вы домысливаете. Человек умеющий составлять алгоритмы, может составлять алгоритмы. Человеку не умеющему составлять алгоритмы недоступны задачи на алгоритмы. Умение придумывать алгоритмы лучше проверять, если вам нужно умение составлять алгоритмы, если вам нужно что-то другое, лучше проверять что-то другое.
Яндексу нужен опыт, в подтверждении этому у него есть система грейдов, да и на собеседовании он тоже проверяется и от него зависит зп. Да и вы сами подумайте, что вы утверждаете. Вы сейчас уравняли вчерашнего студента зазубрившего алгоритмы и программиста с 10 летним опытом в разработке высоконагруженного проекта. Хотите сказать, что яндексу без разницы кого брать? Если да, то вы сильно ошибаетесь. Да и опыт меряется не только знаниями фреймворка X, есть более фундаментальные вещи.
Вот на чем такие утверждения основаны интересно. Типа я вот щас пошел, посидел три месяца на leetcode и вуаля я готовый сеньор-помидор и знания об архитектуре, базам данных, паттернах программированиях и еще 20+ навыков необходимых для современной разработки у меня автоматически вмонтировались в голову?
Мне это напоминает мем, про то как писатель написал, что занавески синие, а все думают и гадают, что же он имел в виду, может он хотел символизировать тоску и деперессию? Хотя на самом деле ничего кроме того, что занавески были «синие». Так и с яндексом. Ввели они эти собеседования, потому что по ним можно прозрачно оценить прошел ли интервьювер собеседование или нет. Решил задачу лучшим решением, без ошибок написал код — прошел. Нет — не прошел, а то, что к реальному миру эта задача имеет отношение чуть более чем косвенное, ну лучше пока не придумали. А все вокруг бегают и строят теории: да эти задачи показывают как программист мыслит, да яндексу нужны алгоритмисты, да алгоритмисты могут решать любые задачи. Увы нет, всё гораздо проще.
Что вы подразумеваете под выучить джанго? Можно написать сайт визитку с 10 посетителей в день без тестов и собрав с помощью батареек необходимой функционал. А можно писать что-то посложнее с гораздо большим количеством посетителей, где надо, например, знать, что такое zero downtime migrations, грамотно организовать архитектуру app внтури django, покрыть всё тестами, организовать сбор метрик для мониторинга, CI, грамотно интегрировать свои компоненты во фреймворк используя паттерны программирования, оптимизировать SQL запросы, чтобы не было N+1 проблемы. Именно умение делать это и нужно в первую очередь работодателям, а не алгоритмы. И более того, умение алгоритмов не гарантирует АБСОЛЮТНО НИЧЕГО из этих навыков и никаких способностей решать задачу, оно гарантирует только умение решать синтетические алгоритмические задачи.
Джанго — это практика, и именно по ней понятно какой у человека опыт и что он точно уже умеет делать. А алгоритмы сам Яндекс форсит учить перед собеседованием. Вот как раз по ним и надо давать методичку, чтобы выучить, если они понадобятся. Но в том и дело, что не нужны Яндексу алгоритмы в большинстве случаев, об этом программисты говорили в одном видео. А такой способ проверки программиста связан с размером компании, с тем, что с таким подходом меньше субъективности, говоря простым языком — бюррократия(например, чтобы токарь получал больше денег, надо не работать продуктивнее, а сдавать на категорию)
А вот то, что не надо искать человека именно с опытом Джанго и спрашивать от него каких-то хитрых подробностей фреймворка, если ему придется работать с Джанго на текущем месте работы — с этим согласен.
I will not pass him the ball вовсе не обязательно означает будущее время. Здесь может идти речь о настоящем времени, например Он просит у меня мяч, а я не пасую ему. Если вы добавите tomorrow: I wil not pass him the ball tomorrow, то время внезапно меняется на будущее. Как описывали выше, в этом предложении нет уверенности в отличие от если бы использовалась форма going to, которая уже точно означает намерение не делиться мячом с ним завтра. Или другой пример It will not work, например человек пытается что распечатать на принтере и говорит он не работает, а вовсе не он не будет работать как многие могли бы подумать. Как уже описали комментарием выше will переводится как завещаю или изволю именно поэтому контекст важен для понимания о чем идет речь
Не знаю я всех подробностей, мне рассказал историю прораб, который делал ремонт в моей квартире. Вариант с перепайкой озвучивался мастером, но почему он не подходит я прослушал. Как вариант, на ванне стояло два смесителя. Один подключенный правильно, а второй нет.
Приведу пример более жизненный и понятный. В одной квартире делали ремонт в ванной и сантехник перепутал местами трубы у смесителя в ванной, при повороте ручки влево бежала холодная вода, а при повороте направо — горячая, а должно быть наоборот, так нарисовано на смесителе, да и на всех остальных кранах так сделано. Заказчики оказались перфекционистами и потребовали исправления косяка, тем более делов то на 5 минут. Тем более щас же вроде всё есть, лазерные уровни, перфораторы, 1000 разновидностей смесей для каждого вида работа и т.д. и т.д. Но по факту, чтобы исправить косяк, пришлось разломать плиточный экран для ванной, отодрать ванну от стены, раздолбить стену и плитку, куда были утоплены трубы, а потом всё это восстановить, что заняло отнюдь не 5 минут работы. С программированием точно такая же ситуация, только ухудшает ситуацию еще то, что если в ситуации с ремонтом человек хотя бы примерно видит как всё взаимосвязано, то в абстракциях программирования он не разбирается точно.
Насчет diablo 2, ну это не аркада же, а что-то близкое к mmorpg. Или может что-то среднее. Как минимум один из смыслов не в прохождении, а в раскачке персонаже, одевании его в шмот, а квесты и прохождение для того, чтобы было чуть веселее :). После этого можно не только не умирать 5 раз от баала, но и делать на него забеги, причем тратя на каждый буквально несколько минут. Кстати, diablo 2 до сих пор жив, попробуйте посмотрите на ютубе как в него оказывается надо играть :)
Вы прям спрашивает сортировку списка? Я думаю чуть посложнее, например над чем я не справился, реализовать структуру односвязный список(Python) и развернуть её. На словах кажется просто, на деле и бумаге у меня не вышло. Но вообще вопрос в другом: «Почему Алгоритмы?» (Спойлер: потому что гугл это ввёл по своим причинам, а все обезьянничают и сейчас на ходу придумывают объяснения как эти задачи показывают умение думать, видно как программист мыслит и и прочие общие фразы) Почему например не задачки по высшей математике, по мат. логике например? Тоже ведь логику показывают и с программирование перекликаются.
А потом на работу приходишь и алгоритмические задачи никому не нужны, а больше нужно умение написать «чистый код», продумать архитектуру, разбираться в куче софта(docker, очереди, бд и т.п.)
Как-то не очень одно с другим вяжется, не находите?
Мне это напоминает мем, про то как писатель написал, что занавески синие, а все думают и гадают, что же он имел в виду, может он хотел символизировать тоску и деперессию? Хотя на самом деле ничего кроме того, что занавески были «синие». Так и с яндексом. Ввели они эти собеседования, потому что по ним можно прозрачно оценить прошел ли интервьювер собеседование или нет. Решил задачу лучшим решением, без ошибок написал код — прошел. Нет — не прошел, а то, что к реальному миру эта задача имеет отношение чуть более чем косвенное, ну лучше пока не придумали. А все вокруг бегают и строят теории: да эти задачи показывают как программист мыслит, да яндексу нужны алгоритмисты, да алгоритмисты могут решать любые задачи. Увы нет, всё гораздо проще.
А вот то, что не надо искать человека именно с опытом Джанго и спрашивать от него каких-то хитрых подробностей фреймворка, если ему придется работать с Джанго на текущем месте работы — с этим согласен.
А потом на работу приходишь и алгоритмические задачи никому не нужны, а больше нужно умение написать «чистый код», продумать архитектуру, разбираться в куче софта(docker, очереди, бд и т.п.)