Comments 687
Если в реальной работе на каждый вопрос лезть в Гугл — очень долго результата ждать будут. Обычно без Гугла не могут любители СтекОверфлоу-дривен-девелопмента.
А чтобы понять, что решение на СО подходит для специфики — это тоже можно нагуглить? А недостатки решения, о которых не сказали, потому что для примера автора это не недостаток, а для нашего приложения это критично тоже на СО нагуглится?
Я пять лет собеседовал людей в свою команду для разработки игр на js в Варгейминге. И я знаю, что большинство решений на СО нельзя вставлять в свой код без предварительной подготовки?
От те все минусы указывают, что здесь значительно больше людей обиженных на окружающих за собственную неудачу на собеседовании, Чем людей, которые имеют реальный практический опыт с двух сторон — кандидата и собеседующего.
Ну от нагуглит он мне первый попавшийся более менее подходящий ответ. И что мне это даст для понимания, подходит ли в команду этот человек? Ведь это даже не покажет, понимает ли он — может просто неудачно вкладку открыл.
Люди думают, что если бы Гугл, то сразу же на синьйорные позиции, которые раньше имнедоступны были они бы сразу смогли устроится?
Неужели вы думаете, что технари, которые проводят собеседования такие идиоты? Что мы не можем отличить, когда человек запутался, потому что нервничает или забыл синтаксис, который ему подскажет иде от людей, которые просто слишком слабы для этой позиции?
Может для типичных сайтиков бездумный СОДД вполне подходит. А в чем-то менее типичное всегда есть своя специфика.
На физтeхe (во всяком случае в моe врeмя) на многих экзамeнах, включая по-моeму гос по физикe, официально можно было использовать учeбники. Это очeнь правильный подход и на рeальный рeзультат — провeрку понимания, а нe зубрeжки — никакого негативного влияния нe оказываeт.
Если Вы решили вспоминать алгоритм на собеседовании — Вы, скорее, его завалили. ИМХО.
Ну и проверка на адекватность. Если не помнишь, то нужно просить описание алгоритма, а не пытаться натужно его вспомнить.
А сможете описать суть например БПФ?Вы о простом "разделяй и властвуй" подходе? Собственно этих слов плюс пары наводящих вопросов должно быть достаточно для приличного программиста, чтобы реализовать БПФ.
Хотя для интервью (волнение, руки дрожат, голова «кипит») это всё же сложновато IMO.
К примеру, реальная задача: есть легаси REST сервис, который крутится на Tomcat и есть HTTP-клиент для этого сервиса. Вместо русского текста: сервис возвращает краказябры, клиент возвращает краказябры, в логах краказябры. Поэтому нужно начать везде использовать UTF-8 и проверить, что это действительно так.
Как решал бы здоровый человек — убедился бы, что:
1. БД использует правильный collation (ага, гуглим какой для кириллицы:
Cyrillic_General_CI_AS);2. JDBC-драйвер использует UTF-8 (ага, гуглим параметры инициализации:
useUnicode=true;characterEncoding=UTF-8);3. установил кодировку сервлета в параметрах Tomcat (снова гуглим, выясняется:
URIEncoding="UTF-8" в настроечном файле);4. на этом этапе сервис начинает работать нормально, гуглим про клиента. По умолчанию он общается с сервисом в Latin1, документация подсказывает второй параметр в конструкторе про кодировку. ОК.
5. и вишенка на торте — ставим везде UTF-8 в логах:
<encoder>
<charset>UTF-8</charset>
<encoder>
На все ушло порядка 10 минут, с проверкой на каждом этапе. А вы здесь говорите про «бездумное гугление». Я понимаю, для кого-то не проблема переключить в голове пять разных технологий, но блин. Кто-то пишет калькуляторы, а кто-то — компиляторы. Это нормально.
СО хорош чтобы подсмотреть дополнительное мнение, если у разработчика есть свое. Если разработчик неспособен без СО даже поговорить на собеседовании с другим технарем, то он может подойти разве что на вакансию джуна или слабого мидла.
Не забывайте, мы сейчас говорим именно про собеседования.
Если вы считаете иначе — либо у вас феноменальная память, либо слишком простая работа.
Или вы думаете, что я, как собеседующий — это такой робот, который сверяет, совпадает ли ответ с листочком и если нет, то отказывает даже талантливому кандидату?
Да и вообще — полным полно таких задач, на которые было бы неплохо найти хоть какое-нибудь решение, а потом уже его совершенствовать.
Я думаю есть вопросы над которыми надо думать, а есть вопросы, которые надо гуглить. И это разные вопросы. Вы на собеседовании какие задаёте?
Я думаю есть вопросы над которыми надо думать, а есть вопросы, которые надо гуглить. И это разные вопросы
Ну так «в продакшене» и на собеседовании требования к вопросам различаются. Тот же «написать алгоритм чего-то» в боевых условиях предполагает нагуглить и проверить реализацию, а на собеседовании означает «пошевелить мозгами и придумать реализацию самому».
К ответам?
Если требования на собеседовании отличаются, значит отбирать вы будете не тех, кто нужен в продакшене. Конкретно с вашим примером — велосипедостроителей. А приличный человек на такой вопрос может и обидеться.
Задавать вопросы на собеседовании — это как KPI выставить. Что попросите, то и получите.
К ответам?
К вопросам.
Если требования на собеседовании отличаются, значит отбирать вы будете не тех, кто нужен в продакшене. Конкретно с вашим примером — велосипедостроителей.
Нет. Конкретно с моим примером — программистов :)
Вы, (если вы программист, конечно), должны прекрасно понимать, что такое абстракция. Задание на собеседовании — абстракция, которая показывает умение программиста решать задачи какого-то там типа. Реализовать, грубо говоря, хеш-таблицу на собеседовании — это не означает, что выполнивший это задание программист способен делать только хеш-таблицы, и ничего более, и если его посадить за разработку, он будет переписывать хеш-таблицы, алгоритмы сортировки и поиска по ключу. Это всего лишь значит, что он умеет придумывать алгоритмы, а значит, в принципе профпригоден.
А приличный человек на такой вопрос может и обидеться.
Ну, не приличный, а слишком нежный. Взрослый человек переживёт, не помрёт. Вы же, приглашая на собеседование человека, которого не видели в работе и не имеете по нему рекомендаций, не можете знать заранее, так ли он крут, как написал в резюме.
В целом, велосипедостроитель — профпригодный программист. Не эффективный, но профпригодный.
Только вот по хеш-таблице нельзя сделать вывод о том, что он умеет придумывать алгоритм. Он его вспомнил. Его на прошлом собеседовании тоже хеш-таблицу спрашивали, а на позапрошлом — пузырёк.
> Взрослый человек переживёт, не помрёт.
Конечно не помрёт. Но лично у меня некоторые собеседования вызывают неприязнь, а другие интригуют. Если я прихожу и вижу темный подвал, 17" мониторы и странные вопросы на собеседовании — я туда работать не пойду.
Ну конкретно написать хеш-таблицу — это не странный, но очень скучный вопрос.
Только вот по хеш-таблице нельзя сделать вывод о том, что он умеет придумывать алгоритм. Он его вспомнил.
Может быть и вспомнил. Если вдруг это стало трендом и спрашивают везде, конечно. Я, например, не вспомню, я просто знаю принцип и буду придумывать, если спросят. Но практика показывает, что трендом не стало, и даже банальный пузырёк люди обычно выводят, а не вспоминают.
Если я прихожу и вижу темный подвал, 17" мониторы и странные вопросы на собеседовании — я туда работать не пойду.
А если вы приходите, видите обычный офис, 24" мониторы, и у вас просят написать алгоритм — вас это меньше пугает, чем тёмный подвал и 17" мониторы?
Ну конкретно написать хеш-таблицу — это не странный, но очень скучный вопрос.
Ну извините. Если что, попросите собеседующего рассказывать вам анекдоты ;)
Лично мне хватает хитрости притвориться, что я «вывожу» )
Если собирать бинго для собеседования, то пузырёк, хеш и синглтон там точно будут.
> А если вы приходите, видите обычный офис, 24" мониторы, и у вас просят написать алгоритм — вас это меньше пугает, чем тёмный подвал и 17" мониторы?
Да, меньше. Но при прочих равных, что я пойду работать не туда, а в офис класса А с 2 27" мониторами. И где анекдоты рассказывают.
Вступлюсь за TheShock. Человек, вообще-то дело говорит.
К примеру, я сам не помню ни одной реализации алгоритмов сортировки. Оно мне не нужно по специфике работы.
Но, если понадобится, то я отлично знаю, где мне достать реализацию этих алгоритмов — гугл и СО.
А вот по каким критериям выбрать наиболее подходящий, отшлифовать его, и правильно применить мне помогут мои знания в голове. Их на СО быстро не схватишь. Они пришли из книг, из мануалов. Именно эти знания помогают моим продуктам работать, а не загибаться, моля о том, чтоб их пристрелили.
Зазубрить 3 разных алгоритма — круто, но бесполезно, если не знать, что такое, узко говоря, вычислительная сложность, а широко говоря — теория алгоритмов.
И в этом кардинальный минус СтекОверфлоу-дривен-девелопмента. Люди собирают куски кода, лепят всё вместе, но не понимают почему, например, в финансовых операциях (и то — не всех) нужно использовать банковское, а не математическое округление: какое было в найдёном примере — то и возьмут.
Каждый второй новоиспечённый гэймдевелопер — это вчерашний дизайнер. Эти ребята проходят недельный курс С++, находят какую-нибудь биржу кода и контента, лепят лепят, а на выходе получают эффективный прожигатель заряда акума телефона. Им невдомёк, что сцена отрисовывается в несколько слоёв не просто так, а для повторного использования многих слоёв в последующих кадрах. Им — пофиг. Ведь можно взять куски кода, слепить их… уяк, уяк — в продакшн!
Они думают, что NoSQL решения реально круче RDBMS. Потому что маркетологи им так сказали. А спроси их что такое RDBMS? "британский бойз-бэнд, да?"
Широкий кругозор очень важен для любого программиста. Что мы имеем сегодня? Нежелание мыслить.
Кто смотрел сериал "Друзья", вспомнит отличную зарисовку: Джо взял хорошо написанное письмо, и каждое слово заменил тезаурусом на синоним. Каждое, отдельно от контекста. Получилась белиберда, хотя и смешная (https://www.youtube.com/watch?v=yGR78nzyznM).
Такой же нелепый результат получается и при использование СО/гугл, обладая лишь поверхностными знаниями. Продукт получается, вроде бы как проходящий по спецификации, но воняет жутко: мобильный апп — батарею сжирает, сайт визитка — проц на 100% загружает, сервер — дедлокит...
Будет хороший проект на JS, обращусь за помощью к TheShock — программистов с таким критическим образом мышления всё меньше остаётся в нашем, хипстерами пропитанном, мире.
Совершенно верно, есть большая разница между "помнить" и "понимать".
Без гугла моя работа будет менее эффективна не потому, что не хватает знаний, а потому, что знаю суть, но не помню деталей, и их намного быстрее нагуглить, чем вспоминать или выводить.
@TheShock просто неудачно сформулировал свою мысль, уверен, что он имел ввиду не такую ситуацию, а именно тупой копипаст с SO.
Нет, конечно. Но там есть требование писать синтаксически правильный код :)
То, что он в реальной жизни сможет нагуглить сортировку, это и так понятно. А вот нагуглить алгоритм работы контроллера насосной станции, которые мы изготавливаем, он не сможет. У него будет блок-схема от инженера-гидравлика, и ему самому нужно будет сочинять алгоритм работы машины состояний и т.д. Вот это я и хочу увидеть на примере сортировки массива, способен ли человек взять задачу, разложить её на шаги и запрограммировать.
Мы же на эти задачи ищем не программистов с опытом работы с насосами, а программистов, имеющих опыт программирования микроконтроллеров. Обычное программирование промышленных контроллеров, ничего военного и уникального.
Навскидку я писал непубличный софт для:
- медицины, включая работу с датчиками кардиометрии в реанимационных отделениях, где ложноположительные результаты просто летальны
- банков и кредитных организаций
- биржевых брокеров
- машиностроительных заводов с подключением к станкам для мониторинга
- автопроизводителей для эксплуатации в авто, включая приложения для смартфонов, интегрированных в локальную сеть авто (с ридонли, правда, доступом к системам управления железом, типа показывать скорость, состояние дверей и т. п.)
- обычных "купи-продай" организаций с миллионными оборотами
Это не считая "сайтиков", краулеров, конверторов и т. п., где предметная область по сути чистая информатика — взять информацию в одном виде и показать/сохранить её в другом. И без них минимум с десяток программно-аппаратных платформ (включая гетерогенные сети на экзотических ныне основах) по 2-3 языка на каждую часто.
Неужели думаете, что какие-то насосы (пускай даже несущие угрозу миллионам людям) меня испугают, а DrPass откажет мне лишь потому, что у меня нет опыта работы конкретно с насосами?
cl Dog ext Anim (
eat(IMeal meal)
list.add(meal)
bool isHungry()
ret list.len == 0
)
С точки зрения языка тут много ошибок, но если вы понимаете тему настолько, что можете устно объяснить ее — это очень легко.
За всю мою карьеру мне каким либо алгоритмом, который нужно было реализовать самому, пришлось сталкиваться 2 раза. Оба раза гугл помог мне найти гораздо более лучшее решение, нежели я бы написал сам.
После 12 лет в деле, написать сортировку на доске звучит как оскорбление. Вам надо сортировки писать, или вам нужно что-бы кто-то исправил ваше приложение, которое заваливает 5 серверов, где должен справиться 1 веб сервер + сервер базы данных?
вам нужно что-бы кто-то исправил ваше приложение, которое заваливает 5 серверов, где должен справиться 1 веб сервер + сервер базы данных?Нам нужно чтобы «кто-то» не создавал приложение, которое заваливает 500 серверов притом что задача, которую он решает, может быть решена и одним.
К тому же, если мы говорим о 500 серверах, то о сортировке пузырьком спрашивать вообще глупо.
Давайте не будем мешать тёплое с мягким — мы говорим не только о разных позициях, но и о разных уровнях, типах задач и инструментах.
Я не работаю с алгоритмами, я не планирую с ними работать и лезть в науку или обработку огромных массивов данных — это не моя область. Если мне понадобится это делать — я найму специалиста, который этому посвятил свою карьеру.
Я не работаю с алгоритмами, я не планирую с ними работать и лезть в науку или обработку огромных массивов данных — это не моя область.Если бы все были так честны и не пытались устраиваться на software engineerа обладая знаниями application engineerа — мир был бы гораздо светлее. Но, увы, в реальном мире это не так.
К тому же, если мы говорим о 500 серверах, то о сортировке пузырьком спрашивать вообще глупо.Почему глупо? Вы можете себе представить человека способного создать распределённую сортировку на кластере в 10000 машин, но не способного написать пресловутый «пузырёк»? Я — нет. Никто же не говорит о том, что вы должны уметь писать только пузырёк!
За всю мою карьеру мне каким либо алгоритмом, который нужно было реализовать самому, пришлось сталкиваться 2 раза.
Простите, а кем вы работаете? Не программистом же, ведь бОльшая часть работы обычного программиста и состоит в реализации алгоритмов, когда поданных сверху, когда придуманных самим. Весь написанный нами код (по крайней мере императивный) и является записью алгоритмов в конкретной нотации, будь то PHP, C, Assembler или Python, записью последовательности действий по достижению нужного выходного состояния при определенном входном.
Одно дело придумать алгоритм для решения бизнес-задачи, и совсем другое сделать свою реализацию алгоритма для решения технической задачи.
Если вы только придумываете алгоритмы, но их не реализуете, то вы не программист, а, например, аналитик, который ставит задачи программистам.
Я о том, что «реализовать алгоритм оформления заказов» и «реализовать алгоритм сортировки с вот такой сложностью» это разные понятия «реализовать алгоритм». Первая бизнес-задача, вторая техническая. Реализации первых используют реализацию вторых. И вот реализацию вторых во многих случаях делать не надо, потому что они уже есть в виде библиотек или встроенных возможностей.
Я о том, что «реализовать алгоритм оформления заказов» и «реализовать алгоритм сортировки с вот такой сложностью» это разные понятия «реализовать алгоритм». Первая бизнес-задача, вторая техническая.
Вообще, нет. Это просто разные предметные области. А суть работы одна и та же. Может быть, сложность конкретной задачи отличаться. Причём не факт, что оформление заказов будет проще — например, если в процессе присутствует функция расчета автоматического дозаказа.
А суть работы одна и та же.
Если бы это было так, никто бы не давал задачи на алгоритмику. Проверяли бы только ООП и умение закодить задачу.
Причём не факт, что оформление заказов будет проще
Вот про это многие и говорят, а другие говорят, что это и не программирование вовсе)
Если бы это было так, никто бы не давал задачи на алгоритмику. Проверяли бы только ООП и умение закодить задачу.
Следует различать задачи на алгоритмику ("реализовать сортировку с временной сложностью O(n*log n)", "реализовать воркфлоу заказа с такими-то ограничениями"), то есть на придумывание или поиск готовых алгоритмов, и задачи на реализацию готовых алгоритмов ("реализовать сортировку массивом пузырьком", "реализовать воркфлоу заказа конечным автоматом с таким-то графом переходов статуса заказа")
Не согласен. По крайней мере в случае обычного разработчика, пускай и уровня выше среднего ("сеньора"), но без исполнения функций аналитика.
И там, и там на входе алгоритм, оперирующий какими-то сущностями и задача разработчика перевести его в код. Если разработчик не может реализовать алгоритм сортировки таких простых сущностей как коллекция целых чисел, то можно ли его подпускать к более сложным типа товаров в корзине покупателя интернет-магазина?
Опять же, одно дело любая сортировка, которая решает задачу (сортирует), и другое конкретный алгоритм с конкретной сложностью и требованиями по памяти. Одно дело, когда дается полное описание алгоритма, и надо по нему написать код, и другое, когда дается название, а описание и характеристики должен сказать разработчик на собеседовании и без гугла.
Заменим на «алгоритм шифрования», желательно каким-либо более устойчивым, чем SHA1, и останется 1% тех, кто собственно работал в разработке алгоритмов шифрования.
Давайте не будем цепляться к словам — понятно же, что человек писал не об алгоритмах вообще, а именно о технических алгоритмах, которые есть не на SODD а в виде best practice.
Да в том-то и дело, что нормальный программист должен уметь на бумаге набросать алгоритмы сортировки, хеширования и шифрования. Неоптимальные, работающие только на простейших случаях, но должен.
Но зачем писать простейший, пусть даже работающий, но совершенно небезопасный алгоритм шифрования, который в принципе не рекомендовалось бы использовать даже в хобби-проектах?
Проще спросить на словах, чтобы человек пояснил теорию что такое соль и как ее применять, что такое коллизию и привел пример. Но просто писать на бумаге, пусть даже псевдокодом…
В общем окей, у каждого свое видение как подбирать команду.
Просто проверить способность человека из вольного описания алгоритма создать его формальное описание на псевдокоде, близкому к целевому языку.
И снова, соль — это не про шифрование, а про хеширование. Уже стоит задуматься, хотел ли бы я с вами работать. А то вот так спросишь про шифрование, а тебе про соль, коллизии и SHA1 толкать начнут...
Устроят ли тогда такие ответы: сортировка — пузырёк; хэширование — разбиение данных на блоки по 4 байта и последующий XOR, шифрование — XOR 4-байтных блоков с фиксированным ключом?
Или нужно блеснуть знаниями и вспомнить, как вычисляется MD5 или SHA1, вспомнить, как работают RSA и AES? Особенно при условии, что на практике будут использоваться только библиотечные реализации этих алгоритмов.
Заменим «алгоритм сортировки» на «алгоритм хеширования», И вот уже 90% программистов отсеивается из программистов.
Заменим на «алгоритм шифрования», желательно каким-либо более устойчивым, чем SHA1, и останется 1% тех, кто собственно работал в разработке алгоритмов шифрования.
SHA1 как раз алгоритм хеширования, а не шифрования.
И тут вдруг обнаруживается, SHA1 — это алгоритм хеширования, а не шифрования… Фейл.
UPD, а, уже сказали. Ну ладно, будет ещё раз.
как жаль, что таких людей мало среди интервьюеров =)
Отсеивать тех, кто понимает, что без Гугла он ничего сделать не сможет в рамках целевого языка. Опять же по себе сужу. С гуглом я на абсолютно незнакомом языке (со хорошо знакомой парадигмой типа ПП и ООП) скорее всего решу какую-то простую задачу типа пузырьковой сортировки за разумное время.
Проверка разных навыков. Для проверки, что человек может сделать, когда у него все инструменты под рукой — есть тестовое задание, которое можно решить дома.
А задачки на доске/на листочке, теоретически, нужны лишь для того, чтобы поговорить о решении (ну не дашь для этого сложную задачку, зато возможности адаптации решения — хорошая тема для разговора). Но на практике — почему-то люди на них отсеиваются (в примере с сортировкой — как если бы человек не то что не воспроизвёл по памяти quick sort или пузырёк, но даже не смог бы на коленке придумать хоть какую-то сортировку за O(n²) или написал вместо неё slow sort)
Мне кажется умение делать исследование вопроса — лучшее качество для разработчика.Это может быть лучшее положительное качество. А собеседование призвано отсеять людей обладающих отрицательным качеством. Всё что эти тесты позволяют сделать — избавиться людей, которые будут решать задачу квадратно-гнездовым способом.
Перед тем как оценивать вашу способность решать сложные, творческие задачи и разбираться в хитрых хитростях (с Гуглом, конечно, куда ж без него) нужно убедиться в том, что вы простейшую, самую тривиальную задачу не решите так, что потом нужно будет консилиум собирать, чтобы разрушения чинить.
Просто потому что если вы «увязните» в сложной задаче — у нас найдутся десятки, сотни людей, которые смогут вам помочь и разобраться. А вот если вы «налажаете» в чём-то простом… то может оказаться что два датацентра встанут и мы получим убытки примерно в размере вашей зарплаты за 100 лет.
Вот и всё. Как вы умеете решать сложные задачи — несомненно важно, но куда важнее — знать умеете ли вы решать задачи простые.
Около месяца назад смотрел выступление на тедтолкс, где человек говорил тоже самое. https://youtu.be/YyXRYgjQXX0. Его выступление конечно же не про собеседование разработчиков, но про собеседования вообще. Забавно, но только сейчас я понял его совет.
Он говорит что при собеседовании важнее исключить неподходящих людей, чем пропустить подходящего. Можно сказать что False Positive ошибка предпочтительнее, чем False Negative при стремлении недопустить в команду неправильных людей.
Зря вы зацепились за гиверов и тейкеров, тут вопрос не о людях и их работе, а о целях собеседования. я не имел ввиду что нужно переложить концепцию выявления гиверов при собеседовании разработчиков. Я имел ввиду что идея «лучше отсеять вредителей, чем не нанять приносящего пользу» мне понравилась. Как это делать совсем другой вопрос.
так нет же, соискатели тоже заинтересованы в том, чтоб не ходить на заведомо неподходящее собеседование и прийти на перспективное, и в резюме они обычно пишут, что умеютВашими бы устами. Нормальные соискатели — да. Проблема в то, что на собеседовании вам, в подавляющем большинстве будут встречаться подобные персонажи. Их, в общем потоке не так много, но за счёт того, что «нормальные кандидаты» проходят одно-два интервью и устраиваются на работу, а вот эти вот «выпускники курсов на которых их обучали не говорить что у них нет опыта» интервьюируются в сотни компаний — их процент «на входе» резко повышен.
И как вы их предлагаете отсеивать?
но почему бы просто не проверять нужные навыки сразу, а не придумывать под это идеологию какую-то?Ещё раз: потому что важнее не то, что кандидат умеет делать, а то чего он не умеет — но пытается.
вот только в этом случае я вижу плюсы от проверки пузырькаВы вообще сколько людей в своей жизни проинтервьюировали? За исключением тех, которых вам знакомые порекомендовали?
А если я вам скажу что на телефонном интервью больше половины соискателей не могут написать ничего? Ну вот совсем ничего — ни FuzzBuzz, ни пузырка, ни чего-либо подобного?
Давайте обсудим:
1. с какой стороны меня это характеризует как специалиста?
2. чем плохо для компаний меня нанимать?
1. с какой стороны меня это характеризует как специалиста?
Либо вы в любой мало-мальски сложной ситуации теряетесь, либо вы действительно так себе специалист. Для меня непонятно, как можно не написать тот же самый физбаз на бумажке, если человек знает хоть какой язык программирования. Синтаксис циклов, условий и определения массивов — это штука, которая в любом случае должна быть в голове, а не в гугле. Разработчик без локального кеша самых основных знаний так же неконкурентоспособен, как и процессор без кеша.
2. чем плохо для компаний меня нанимать?
Ну как минимум риски выше, чем в случае кандидатов без этих проблем.
Если встретите кандидата, который не может написать физбаз, спросите его номер телефона, день рождения или что-нибудь еще, что он вроде «должен» знать. И удивитесь…
Люди разные. У кого-то собеседование вызывает заметный стресс и с каждым случаем нужно разбираться. Времени ровно час. Мы все куда-то спешим.
Если встретите кандидата, который не может написать физбаз, спросите его номер телефона, день рождения или что-нибудь еще, что он вроде «должен» знать. И удивитесь…
Это абсолютно разумный критерий проверки, но есть нюанс. На собеседования же никто «с места в карьер» не скачет. Т.е. не бывает такого, что приходит кандидат, ему сразу говорят: «Берите ручку, первый вопрос физбаз, второй баблсорт. Садитесь, пишите, время пошло.»
Есть этап знакомства, есть этап общих вопросов. И когда доходит до практической задачки, уже и так прекрасно видно, кандидат растерян/перепуган, или нормально всё воспринимает. Поэтому и к результатам теста уже относишься вполне объективно.
у вас правда в конторе десятки-сотни народу ничем не занимаются, только решают чужие проблемы?И близко нет. И всех есть свои задачи. Но если вы «увязните», если задача вам окажется «не по зубам» — помощники найдутся.
или всё-таки у них есть свои задачи, от которых еще надо оторваться, въехать в чужую проблему, решить ее, а потом опять вспоминать свою задачу столько же времени?Разумеется есть. Потому писать пресловутый «пузырёк» они за вас не будут. А вот исправлять приложение, которое заваливает 500 серверов и с которым вы уже месяц совладать не можете — будут.
Потому умение вами самостоятельно справиться с пузырьком важнее, чем умение совладать с 500 серверами.
А зачем вообще на собеседованиях просить что-то писать? Дайте тестовое задание похожее на то чем сотрудник будет заниматься на работе. Пусть дома спокойно сделает его и даст вам код. А вы так же спокойно никуда не торопясь посмотрите его. И пусть хоть чем пользуется. Какая разница в гугле он посмотрел алгоритм, в толстом бумажном справочнике или сам на ходу придумал, главное чтоб он задачу решал за отведенное время.
Мы на собеседовании вообще не просим решать какие-то задачи, т.к. у нас уже есть код который кандидат написал в качестве тестового задания и по нему очень хорошо видно его уровень.
2) На удалёнку ищем. Это, во-первых. Во-вторых, я бы как соискатель отказался от такого тестового, что за контроль такой? Недавняя история с устройством на работу в Амазон вспоминается; то ли тут, то ли на гиктаймс была статья. Как следствие, я бы таким образом явно не стал человеку тестовое давать. Это, как минимум, не слабый стресс для него.
3) Разработчик как правило ищет работу не в конкретную контору. При прочих равных, вряд ли он будет тратить время на тестовое в таких условиях.
Разработчик выбирает одну работу из множества примерно одинаково заинтересовавших. В одних просят прийти на собеседование, в других просят сначала сделать тестовое задание, а потом прийти на собеседование. Зачем делать тестовое, если предложения одинаковые?
В итоге, пока вы делаете тестовое (даже оплачиваемое) для одной компании, можете упустить рабочее место в другой. Вон у zagayevskiy можно спросить. Он несколько недель потратил на тестовое для ZeptoLab. За это время вакансию, где тестового нет, уже и закрыть могут. Правда, в его случае, он целенаправленно в ZeptoLab шёл…
Лично для себя вижу два варианта, когда соглашусь делать тестовое не "на бумажке" прямо на собеседовании на 10-15 минут:
- очень хочу в конкретную фирму
- условия заметно выделяются среди рыночных, скажем, предлагают процентов на 20 больше или офис в пешей доступности от дома.
Скорее наоборот, например заметно выделяются среди рыночных предложение с условием "Кратко о себе: https://google.com"
2) Довольно хороший подход из моего опыта как со стороны кандидата, так и со стороны собеседующего.
3) Тут уже зависит, есть ли подходящие задачи для такого аутсорса.
С простыми задачками, которые писать три минуты, можно сделать проще — во время скайп-интервью попросить расшарить экран и написать код (конечно, надо заранее предупредить об этом, чтобы человек подготовил себе среду разработки). Быстрый отсев имеет смысл, только если у вас поток кандидатов огромный, а на таком отсеется процентов 80. Вряд ли это такой частый случай. Зато видно, что человек не гуглил готовое решение.
Гуглятся, кстати, зачастую неэффективные, брутфорсные решения, не удовлетворяющие требованиям по алгоритмической сложности.
Но то, что гуглится, позволяет сэкономить время: там часто удобнее сначала написать брутфорсный вариант, а потом уже искать "правильное" решение, используя брутфорсный в качестве теста. Гуглом можно сэкономить минут 5-10.
(То, что полный бред — не оспариваю и целиком согласен, см. мой коммент ниже.)
Я до отправки гуглил только последнюю, которую не решил. Когда нагуглил решение (причем это был не код, а статья об олимпиадной задаче и формула, описывающая суть решения) — офигел, понял, что у меня на это ушло бы часа три, реально олимпиадная мозгодробилка. Вместо решения поставил комментарий со ссылкой и написал, что копипастить не хочу, а сам решить не смог. :)
Первые две потом погуглил — правильных решений не нашел, одни брутфорсные. Видимо, свежие задачки попались. Я их решил, но в граничных условиях немного накосячил. Сразу после отправки понял, где, и написал об этом в емейле, проканало. :)
Codility — это вообще фигня бессмысленная. Умение решать околоолимпиадные задачки очень слабо коррелирует с умением решать прикладные задачи.
Я его прошел только потому, что хотел попасть на toptal, а там это стандартный этап отбора. Покоробило, но решил — что уж там, один раз — не гондурас. :) Была бы вакансия в какую-нибудь ничем особо не примечательную конторку — отказался бы сразу.
А что мешает человеку, выполнившему тестовое задание быстро, впоследствии работать медленнее остальных? Мой опыт говорит — ничего не мешает. Мой опыт также говорит, что медленнее — не значит хуже (если вы, конечно, не студия-потогонка). А вот детальное обсуждение результатов тестового задания, с дополнительными сопутствующими вопросами — дает отличное представление о том, что человек умеет и знает на самом деле.
А что мешает человеку, выполнившему тестовое задание быстро, впоследствии работать медленнее остальных?Да ничего. Правда, в таком случае с человеком придётся распрощаться.
Мой опыт также говорит, что медленнее — не значит хуже (если вы, конечно, не студия-потогонка).Я число 3 не просто так привёл. Этот сотрудник делал таски в 3 раза медленнее, а баги в его коде мы отлавливаем до сих пор.
Минус, безусловно, и в нашу сторону, у нас нет нормального процесса код ревью =\
А вот детальное обсуждение результатов тестового задания, с дополнительными сопутствующими вопросами — дает отличное представление о том, что человек умеет и знает на самом деле.Проблема в том, что тестовое должно быть не слишком большим. Как следствие, довольно сложные штуки туда не впихнёшь. Тестовое показывает, что человек владеет технологией/движком. А вот уже при работе с конкретными вещами на проекте возникают проблемы.
при работе с конкретными вещами
Тестовое задание любого объема должно включать в себя "скользкие места", которые, если даже не будут замечены, можно (нужно) будет разобрать при обсуждении.
баги в его коде мы отлавливаем до сих пор
Ну вот попался вам криворукий персонаж, это понятно, но почему из этого опыта вы делаете странный вывод о том, что скорость выполнения задания — главный параметр, по которому его стоило отсеять? ИМХО в Ваш случай — это чистый фейл того, кто проводил техническое интервью.
Ну вот попался вам криворукий персонаж, это понятно, но почему из этого опыта вы делаете странный вывод о том, что скорость выполнения задания — главный параметр, по которому его стоило отсеять?Я такого не говорил. Я лишь сказал, что нам не нужен разработчик, который работает очень медленно и при этом косячит.
Проблема с тестовым в том, что неясно сколько по факту человек времени потратил на его решение.
Я при устройстве на нынешнее место работы заранее знал, что смогу взяться за задание не раньше, чем через неделю — просто не было времени, работал (отделка, сантехника, всё такое, а дома нет возможности поставить MS SQL). Поэтому меня этот вопрос (демонстрация реально затраченного времени) затрагивал очень сильно. Так что неделю я потратил на анализ ТЗ на бумаге и задавал много вопросов — предупредив, впрочем, когда смогу реально приступить к проекту. А готовый проект отправил вместе с репозиторием (типа трекинг работы). В результате оказалось, что про Гит там ни сном, ни духом (мне, впрочем, разрешили — в моём единоличном ведении отдельное приложение), а решающую роль сыграли заданные вопрсы...
Это не фриланс заказ на какой-то небольшой скрипт, который работает и ладно.
1) Проблема вхождения в проект
2) Нет гарантий, что результаты пойдут в работу, а деньги платить надо. Предлагать же вариант "если мы возьмём вас на работу, то оплатим и время, потраченное на тестовое" очень похоже на развод, особенно если с десяток соискателей на одну позицию.
Это суть испытательного срока
Я число 3 не просто так привёл. Этот сотрудник делал таски в 3 раза медленнее, а баги в его коде мы отлавливаем до сих пор.
А человека, который делает таски в 3-5 (буквально) раз медленнее, но баги вылазят через полгода и связаны с неверно сформулированными в тз граничными условиями, а на ревью правится разве что кодстайл вы бы тоже не взяли?
Проблема была не в ТЗ, так как другой сотрудник по такому же ТЗ нормально всё сделал.
Как неверно сформулированные в ТЗ граничные условия могут привести к багам в коде? Баг — неверно реализованное ТЗ, а если ТЗ не соответствует бизнес-задаче, но верно реализовано в коде, то баг в ТЗ, а не в коде.
Мне кажется такие вещи скорее исключение чем правило. Мой опыт осмотра более сотни тестовых заданий показывает что если человек его нормально сделал то и задачи он делает нормально в том числе и по скорости, а те кто медленно работает у них и по тестовому были проблемы.
У нас был только один случай когда человек сделал на почти отлично тестовое задание, а потом не справлялся со своей работай. Но это стало понятно в первый же месяц испытательного строка и мы с ним быстро распрощались. Я так думаю что тестовое задание он просто не сам делал. Но это опять таки исключение. Чтоб отлавливать такие исключения есть испытательный срок.
Я был пару раз на месте этого сотрудника — когда на проекте куча легаси, сакральные знания утеряны пару поколений программистов тому назад, либо они в головах "дедов", с которыми они делиться не хотят. Вы точно уверены, что ввели его в проект, или сразу винтовку в руки и на передовую?
2)
Если второе — то это не плохоЧем же хорошо? Я приведу конкретный пример. У нас в игре есть различные персонажи, у каждого свои спелы. Стояла задача сделать спелы для нового персонажа. Человек провозился несколько недель. Уже прошло несколько месяцев после увольнения, но баги то тут, то там всплывают.
Другой сотрудник для уже следующего нового персонажа сделал все спелы за пару дней. Ну да, сложность проектирования новых спелов +- может отличаться, но не в 3-4 раза по времени.
Что меня бесит — так это когда некоторые функции можно использовать исключительно используя клавиатуру, некая «недоступность» для изучения/напоминания, ты просто должен запомнить все эти комбинации.
2) У вас такой пример. У меня есть другой пример. Человек пишет код довольно быстро и крайне бездумно. Любит приступать сразу же, без какой-либо подготовки. Никаких паттернов, никакой выдержанной структуры, продуманной архитектуры. Разные отступы? Ой, ну и ладно. Спагетти-код all the way. Зато да, якобы работает. Тестируется всё это дело так же как и пишется — на глазок.
Ну и что такого, что медленно набирает? Программист — не секретарь. Главное — решение задачи за приемлемые сроки.
Я бы с большим подозрением смотрел на человека, который бы не использовал отладчик. Да, есть люди, которые пользуются только отладочным выводом, потому что отладчик — слишком сложно. И я не о консольном gdb говорю, а о обычных IDE.
Ну и что такого, что медленно набирает?
Главное — решение задачи за приемлемые сроки.Вы в своих же сообщениях противоречия не видите? Две недели тратить на таск, который делать 2 дня — это как раз-таки не укладывается в приемлемые сроки.
Вы в своих же сообщениях противоречия не видите? Две недели тратить на таск, который делать 2 дня — это как раз-таки не укладывается в приемлемые сроки.
Нет, не вижу. У обычного программиста скорость набора выше, чем скорость мысли.
Или задача сводилась просто к бездумному набору большого количества кода?
Мне эта информация никак не помогает оценить количество кода, необходимое для решения задачи.
Скорее всего, дело не в скорости набора кода, а в том, что претендент был тугодумом, т.е. просто долго пытался понять, что и как надо делать.
А как бы вы посмотрели на человека, который устанавливает отладчик на продакшен сервер?
Медленно набирает. Hot keys почти не использует.
Так вам наборщик кода нужен или разработчик? К примеру я мало набираю кода в течении дня, большая часть времени уходит на проектирование, нахождение решения, профилирование, оптимизацию, отладку бизнес логики… то чем должен заниматься разработчик, а не строчить гавнакод
Скажите, за использование нестандартной цветовой схемы в IDE у вас сразу увольняют, или сначала выговор?
Вы что упоротый фанат командной строки ненавидящий графические интерфейсы?
Вы что упоротый фанат командной строки ненавидящий графические интерфейсы?Нет, я человек, который хочет нанять сотрудника, который будет помогать нам в разработке проекта, а не человека, который будет просиживать часы и за это получать з/п.
сам факт того, что он даже copy/paste делает мышкой
и что? я работал с человеком который пользовался трекболом, его в топку? я еще как то наблюдал за кибер «спортсменами», были крутые чуваки которые одной мышкой с доп. кнопками делали хот кейшиков… дело в навыках и моторике
Тестовые задания люди не любят делать, если просто ищут работу, рассматривая множество предложений.
Мы с такими не работаем. Если человек не хочет делать тестовое задание то просто дальше с ним не общаемся. В моей практике было два случая когда взяли без тестового задания:
Я сам тогда рядовым сотрудником работал. Кандидат на собеседовании сказал что-то типа "чего это я такой крутой и буду тут тестовое делать?". Начальник его взял. Гонору от него было… И делал он проект один месяца три. Так и не сделал. Потом я за него почти с нуля за неделю все написал. Все сроки профукали. Через год со скандалом уволился.
- Тут кандидат просто сказал что вот я для других делал почти такое же, может его посмотрите. Тут все понятно.
Сениор тем более должен делать тестовое. Ооооочень много случаев когда собеседовались на должность сениора, при этом не могут сделать тестовое задание на сениора (задача взята из реального проекта и подобная задача возникает в каждом втором проекте). А когда предлагаешь сделать тестовое на мидла, то выясняется что и его не все могут сделать. Если ты такой крутой программист, что хочешь быть сениором, то сделать тестовое тебе не составит труда.
Если ты такой крутой программист, что хочешь быть сениором, то сделать тестовое тебе не составит труда.
"Вас много, а я один". Одно дело, когда одно-два интересных предложений и на них предлагают тестовое задание на день работы где-то и совсем другое, когда предложений с десяток и на каждом предлагают тестовое на день работы.
И вы на все хотите пойти и на всех условия одинаковые что все задания надо делать?
Ну тестовое задание на день работы сениора это действительно многовато. Наше где-то на 2-4 часа расчитано (я надеюсь).
"нас устраивает запрошенная вами в резюме на сайте ххх сумма, когда вам будет удобно прийти на собеседование? Кратко о себ: занимаемся разработкой" вс "нас устраивает запрошенная вами в резюме на сайте ххх сумма, сделайте тестовое задание во вложении и сообщите когда вам будет удобно прийти на собеседование? Кратко о себ: занимаемся разработкой". Куда сначала пойдёте? Начнёте ли писать тестовое для второй, если в первой сспросят "прямо сейчас готовы приступать?", а на ответ "у меня ещё одно собеседование запланировано" скажут "приступайте прямо сейчас и мы вам даем на 15% больше чем вы просили".
Еще одной причиной был обычный для IT дифицит кадров. настолько большой, что компании боятся отпускать более-менее вменяемых кандидатов. Если сегодня вы не берете кандидата «сходу» и предлагаете ему тестовое задание, то завтра он примет офер другой компании.
Наверное поэтому нам и тяжело найти сениора :).
Но не представляю как можно брать человека на работу не видя того что он может сделать. Ну да, open source всякий можно использовать, но большое количество проектов (кода) далеко не у всех хороших программистов есть в open source (сам тому пример, буквально пара небольших открытых проектов есть). Всякие статьи/конференции тем более не показатель.
Но это все уже немного другой вопрос, как мне кажется
Зря вы так думаете. Знаю не мало хороших программистов (про себя скромно умолчу) у кого очень мало open source. И уж тем более репутация на SO (это я бы вообще не рассматривал, т.к. чтоб заработать там репутацию надо не столько знания, сколько время). Далеко не у всех есть время чтоб занимать open source'ом. Хорошо если начальство/клиент позволит выложить в open source то что было в рабочее время написано. А если нет, то где взять время даже не представляю.
Я с самого начала и сказал: мы разное понимаем под понятием «сеньор».
Да, действительное разное. Я под сениором понимаю программиста который умеет, в первую очередь, сложные задачи решать, над архитектурой думать, умеет понимать место проекта в бизнесе клиента и т.д. А не то где и как он работает.
Вы прям в каком то идеальном мире живете. Себя я не буду брать (я, можно сказать, фрилансом занимаюсь, и при желании могу хоть сколько часов на OS выделять, но в ущерб деньгам), но доводилось сталкиваться с хорошими программистами которые работают на ставке мидла и тянут весь проект и просто не знают насколько они хороши и что в другом месте они могли бы получать больше и иметь лучшие условия. От чего они по факту не перестают быть сениорами.
покажите вашт наработки в этой области
Закрыты NDA — ещё вопросы? И ваша классификация явно не укладывается в общепринятую. Менторские качества от сеньора обычно не требуются, это качества для лидов, которые должны вести людей за собой. От сеньоров требуется в этом плане консультировать интернов, джунов и мидлов при необходимости (определяется лидом или ПМ-ом в общем случае), а не тащить их.
Зачем мне искать, я от них отбиваюсь :)
Людьми, которые ищут себе сотрудников. Понимая под миддлом сотрудника, который может решать обычные задачи самостоятельно в разумное время, а под сеньором сотрудника, который может самостоятельно решать сложные задачи в разумное время, проводя декомпозицию и простые их части делегируя при возможности менее квалифицированным.
Сеньор — это должность, Senior Software Engineer/Developer, в русском бюрократическом переводе — старший инженер/техник-программист. Лид — тоже должность, ведущий инженер-программист.
Да, не может быть сеньоров много, вернее больше чем миддлов/джунов в устоявшемся режиме развития или даже стагнации отрасли, поскольку каждый сеньор должен побывать джуном/миддлом, но не каждый джун/миддл дорастет до сеньора. Но поскольку отрасль развивается и каждый день число джунов растёт уже много лет, то растёт и число сеньоров каждый день.
Очень у вас обширное понятие.
Высшая ступень — техлиды, ведущие инженеры по советско-российским классификаторам.
Но как рахз они даже и в 2017м редко чего выкладывают на GitHub! В лучшем случае там может оказаться код, который они писали несколько лет назад!
Тут скорее научные статьи и конференции могут быть, чем профиль на GitHub…
Ну если у вас после них идут кто-то у кого в названии есть слово Staff, то мы вряд ли поймем друг друга.Разумеется. Я живу в мире, где иерархия устроена примерно так. Вы либо никогда не сталкивались с задачами, выходящими за рамки компетенций Senior Software Engineer'а просто. Или, скорее, живёте в каком-то выдуманном вам мире, похоже, имеющем мало отношения к реальности. С учётом безумного напора на важность GitHub'а и Stack overflow — при полном нежелании на вашем примере показать чего ж там такое должно быть, чтобы Senior был Senior'ом я скорее к этому варианту склоняюсь.
И код — не парное мясо, с годами не протухает.Код — нет, а человек — может и да. Вы на работу код собрались нанимать или человека?
Подведем итог спора:
- Один считают сениором того кто знает все алгоритмы и может посреди ночи за 5 секунд написать любой алгоритм на перфокартах
- Другие считают сениором того кто имеет кучу OS проектов на гитхабе и напсиал 100500 пул реквистов в чужие
- Третьи — того кто имеет высокий рейтинг на SO
- Четвертые — тех кто выступает на конференциях и имеет не меньше тысячи статей на хабре и все с рейтингом не меньше сотни
- Пятые — тех кто умеет решать задачи
Осталось запилить новый пост на хабре с опросом и выяснить кого больше :)
Сеньор это тот кто получает зарплату сеньора в соответствующей должности:)
Потому что в итоге именно работодатель решает подходит ли оный кандидат на должность сеньора или нет.
То есть вы попросту путаете понятия «сеньор» и «гуру».
А для нас, «тёмного» народа, сеньор — это в первую очередь позиция в команде. Да, конечно, есть какой-то средний по отрасли уровень скила, который определяет этот уровень, но он и сильно гуляет от команды к команде и состоит в основном из навыков, непосредственно связанных с работой.
Вот у нас есть конкретные тезисы:
У всех людей, могущих претендовать на позицию сеньора есть мегабайты кода в open source и минимум несколько тысяч репутации на SO.и
Остальных — я на сеньора даже резюме смотреть не стану.
И есть конкретный кандидат. Без «портфолио», без open-source проектов, без репы на Stack Overflow.Закрыты NDA — ещё вопросы?Нет, больше никаких вопросов, до свидания.
Так как: таки «давай досвиданья» — или может ещё подумать?
Даже pull request в публичный репозиторий, используемый в работе, может быть рассмотрен как нарушение NDA, коммерческой тайны и т. п. Локальный форк для внутренних патчей и всё. Более того, есть конторы в которых использование опенсорса запрещено, вернее запрещено использовать софт без прямого двустороннего лицензионного договора с правообладателем или его законным представителем в России.
Есть вполне адекватные работодатели, которые не считают допустимым делиться со всем миром (прежде всего с конкурентами) бесплатно тем, за что они платят деньги.
И не путайте наличие портфолио и наличие истории вкладов в опенсорс проекты.
С этим критерием отбора вы рискуете получить специалиста, который:
а) решает прежде всего задачи сообщества, а не ваши, но за ваш счёт
б) не считает нужным вообще хранить в тайне какую-то информацию
в) будет конфликтовать даже по поводу лицензий под которыми выкладывать рабочий код, скажем, будет считать что MIT недостаточно православна
Был такой печальный опыт.
Это вы называете настоящими сеньорами людей, у которых есть доказательства того, что они активно участвуют в жизни опенсорс проектов. При этом у них может не быть ни дня опыта промышленной разработки.
Наверное, всё дело в том, что программисты, пишущие код только под NDA, не имеют возможности для саморазвития. Они просто исправно пишут код, за который им платят деньги, а не который им самим хочется писать.
Сообщений с десяток, если не больше, вы навязываете именно этот критерий отсева как первый из решающих :) Я же правильно понимаю, что вы даже на собеседование не пригласите человека, если у него на гитхабе, битбакете и т.п. нет аккаунта?
Насколько я понял, аккаунт, что Вы мне показали — рабочий, т.е. там представлена работа, за которую Вам платят деньги? Тогда да, этот аккаунт мне не интересен. Вам чертовски повезло, что Ваш работодатель так относится к сообществу и активно делится наработками. Это здорово! Но я вижу сложившуюся ситуацию так, что бОльшая часть компаний всё ещё закрывает свои наработки. Поэтому всё, что сможет показать разработчик на собеседовании, каким бы крутим он ни был — свои личные проекты, которые он делает в свободное от работы время. Увы. Вот мне и интересно, какая у меня должна быть активность в разработке pet-проектов, чтобы котироваться организацией, подобной Вашей как годный разработчик.
Я опущу ту часть про Ваши путешествия как не имеющую отношения к сути разговора (если вдруг Вы считаете, что эта проблема связана с географией — нет, не связана; я вот в американской компании работаю; такого пристального слежения за кодом нигде пока ещё не видал).
напрямую не закрыт NDAЭто какой код то? Какие-нибудь вспомогательные скриптики? Может, ещё что-то? Насколько его много относительно того, что напрямую покрыт NDA? Думаете, в других проектах его много?
Вы правда считаете, что разработчики в «закрытых» компаниях не стремятся делиться с сообществом? Стремятся. И посылаются далеко. Нашу команду начальство посылало на 4 буквы (в английском нет известных мне направлений из трёх букв) пару раз. И аргументы их не интересовали. Вы, конечно, можете сказать, что недостаточно эти разработчики старались, надо было сильнее жопу рвать (ну, как Вы, например). Но что, если Вам просто немного… да, с тем, что Вы имеете возможность публиковать свои рабочие наработки — Вам, помимо всего прочего, повезло. Это, кстати, ничуть не умаляет Ваших заслуг. В том числе на поприще популяризации OpenSource.
Хорошо, давайте пойдём с другой стороны. Покажите мне любой GitHub-аккаунт, которым, по Вашему мнению, стоит обзавестись, чтобы считаться сеньором. Изначально то меня именно это интересовало.
Есть тренд, что чем больше запретов, тем выше зарплата.
Есть тренд, что когда ты не первый месяц в профессии, зарплата не играет первостепенного значения, да и второстепенного тоже.
Это целиком и полностью зависит от ваших потребностей, а не от стажа. Я, например, хочу домик в хорошей европейской стране. Но домик в 30 км от Женевы стоит порядка $700K. А зарплаты хорошего программиста, увы, хватает и на еду, и на хороший отпуск, и на неплохую машину… но на домик в Женеве не хватает.
И если мне предложат зарплату, которая сделает его ближе, я прекрасно обойдусь без, ах божечки, твиттерного трёпа в течении 8 часов в день, и без работы над пет-проектами в оплаченное работодателем время. Тоже мне, ценности нашли.
И уж тем более, споров с работодателем/заказчиком на тему, можно ли выкладывать мой код, сделанный по его ТЗ, на гитхаб в публичные репозитории. Да ради бога, он за него заплатил, он вправе решать его судьбу. Я абсолютно бесплатно сделаю так, как он попросит, даже без всяких NDA.
В твиттер ходят, чтобы ссылки на актуальные статьи в своей профессиональной области получать сегодняшним днем, а не в ужасном переводе на желтушном сайте типа говнохабра.
Вы, наверное, единственный пользователь твиттера, который использует эту свалку студенческого трёпа с такой целью. Если вам, конечно, поверить.
Да всем нравится, и что?
Ну просто потому, что вас вряд ли возьмут на работу, которая вам позволит достичь какой-то связанной с финансами цели, если вы будете качать свои права на всякую откровенную чушь.
Ну, за исключением того, что в Швейцарию я не то, что жить, я на конференции езжу с неохотой: такая скука, что хочется запить через 20 минут после приземления
Я не уверен, что вас туда приглашали. Не из-за профессиональных качеств (их я не знаю), а просто потому, что я там был, и знаю, что вы говорите ерунду. Ни Женева, ни Цюрих ничем в плане времяпровождения не отличаются от любого другого крупного европейского города.
Даже не знаю, какая фамилия вас заинтересует. Джоэл Сполски, например, ведет активный интересный твиттер
Нууу… и как, там есть что-то, повышающее вашу квалификацию? Если вам так нужны для развития рассуждения Спольски или рассказы Кармака, ну расскажите начальству, что без этого никак. Вам разрешат. В конце-концов, ваш собственный телефон или планшет у вас практически нигде, кроме сверхсекьюрных контор, не отберут, можно подобную публицистику для убивания времени хоть учитаться при желании.
Как из этого следует необходимость вылизывать жопу начальству?
Понимаете, есть наёмная работа, есть фриланс. Если вы фрилансер или предприниматель, то у вас нет начальства, и вообще непонятно, к чему этот спор. Если же вы наёмный работник, то вы выполняете условия, под которые заключили сделку, в том числе и соблюдаете правила распорядка (то, что вы почему-то называете «вылизывать жопу»), нравятся они вам или нет, а работодатель выполняет со своей стороны (обеспечивает условия для работы и платит зарплату). Если вы этого не делаете, то вы просто как специалист — говно. Хорошего специалиста характеризует не только умение писать код, но и добросовестность отношения к своему делу.
Я все время говорю о том, что в условия договора на берегу надо закладывать важные для тебя вещи.
Ну тогда вам надо и понять, что «запреты болтовни в твиттере» или там «рабочий графис с Х часов до У часов» при нормальном отношении работодателя и хорошей компенсации для большинства спецалистов абсолютно несущественные вещи. А рассуждать на тему «как это я могу опуститься до такого уровня, что буду работать там, где не одобряют твиттер», это все равно что заявлять, «я не готов работать в такой убогой конторе, где мне, элитному суперразработчику, скрам-мастер не будет ласково чесать яички во время митингов».
Я до сих пор не бросил эту ветку только ради тех, кто, может быть, придет, почитает, и взвесит все за и против наших подходов: вы-то пока теоретизируете насчет домика в скучной стране, а я уже живу там, где мне хочется и работаю так, как мне нравится.
… и почему-то свято уверены, что ваше непонятное «нравится» — такое хорошее, что его надо рекламировать до усрачки. Поверьте, в мире не существует такой потребности в высокооплачиваемых и необременённых ответственностью специалистах, чтобы у вас появилось сколько-нибудь значительное количество последователей. Если вы, конечно, высокооплачиваемый, а не живёте в копеечной съемной квартире где-нибудь в испанском колхозе.
Вот вам вид из окна нашего офиса, так сказать, в подтверждение моей точки зрения
Так сразу бы и сказали, «парни, я затеял этот спор, дабы понтануться, смотрите у меня тут море-океан под окном и дефки на пляже в бикини, а вы там давитесь в своих кубиклах» :)
Я рассказываю, откуда берется тот открытый код, которым сейчас многие любят пользоваться. Рассказываю, что отдавать — полезнее, чем тупо получать. Окупается сторицей.
Я — человек аполитичный. В 20 лет поработал админом в одной известной в 1990-х политической партии, посмотрел на эту штуку изнутри, увидел, сколько там говна, и больше туда ни ногой. Поэтому ваши политические/коммунистические лозунги про открытый код я тоже воспринимаю крайне скептически.
Потому что открытый код — это просто открытый код. Вы, как автор своего кода, абсолютно вольны с ним делать что угодно, хранить под замком, продавать или раздавать всем. Если вы сделали код по заданию работодателя, то это служебная задача, и имущественные права на неё у заказчика, и что делать с кодом, это уже его дело. Если это не закреплено документально, то это можно оспорить при желании, но это уже нифига не fair play, и мы такой вариант не обсуждаем.
И вот говорить, что надо раздавать свой код другим — это все равно что говорить «надо раздавать свою зарплату другим». Не надо. Хорошо раздавать или не хорошо раздавать чей-то код, вы не можете знать. Этой информацией обладает только его владелец.
И ничего особо страшного в том, что какие-то библиотеки являются проприетарными, тоже нет. Код — это не лекарства и не продукты первой необходимости. Мы так или иначе почти все занимаемся коммерческой разработкой. Если нашли бесплатный код, который решает вашу проблему, ну ок, спасибо, сэкономили денюжку вашему заказчику. Если какая-то нужная библиотека не является бесплатной, совершенно не проблема её купить или написать.
Повторюсь, я не агитирую, я просто рассказываю случайно зашедшим людям
Давайте расскажем случайно зашедшим людям более полезные вещи:
Представляю, какой вы код пишете, если не в состоянии уследить на нитью простой дискуссии
свой выкидыш
1. Переходить на личности плохо.
2. Хамить плохо.
3. Навешивать ярлыки, всего лишь на тех людей/организации, которые делают не так, как вы, плохо.
4. А дружит ваша компания с сообществом или нет — как раз пофигу.
Поэтому ваше «рассказываю случайным людям» приносит куда больше вреда, чем пользы. Но по крайней мере, у вас есть возможность понтануться офисом, это у вас не отнять.
Недвига, кстати, в Испании нынче недорогая, как и еда, как и шмотки. Куда дешевле, чем в Москве. Позволить себе это несложно. Другое дело, что там, скажем так, тоже на любителя. Летом там днём такая жарища, что никакими деффками в бикини меня туда не заманишь.
Вот я люблю, когда о стране судят по дешевым курортам
А как цена курорта связана с климатом??
Лично ездил по всей Испании летом, и так же не хотел бы там работать летом. Что на юге, что на севере, что в центре. Жара — она не для всех.
пацаны-то не в курсе
Вы меня подловили, сдаюсь.
типа pornhub, хабрахабр и подобных
Хорошо, что вы стесняетесь не ресурсов, а именно своего присутствия на них. Если бы я писал то, что пишите вы — тоже бы стеснялся.
Мне прям интересно стало, что, а главное в какой манере, вы там — на pornhub, комментируете :D
Какое замечательное сравнение.
Вы бы подправили Википедию тогда, а то пацаны-то не в курсе, что там у них жара-не-для-всех.
Для меня, например, идеальная температура на улице — от 15 до 20 градусов, а температура выше 25 градусов просто некомфортна. Поэтому если в Москве я испытываю дискомфорт только 1-2 месяца в году, то в Сан-Себастьяне будет 4-5 месяцев неприятной жары.
И я лишь говорю, что для современного разработчика, претендующего на работу мечты — github и SO существенно ускоряют ее, этой самой работы мечты, осуществлени
Несколько изменена тональность по сравнению с утверждениями, что без гитхаба и СО разработчик сеньором не может быть по определению.
@am-amotion-city — ну напишите ссылку еще раз, пожалуйста. Нагуглить ваши репозитории легко не удалось.
Да где искать-то? Трудно написать?
Если вы про https://github.com/KronicDeth/ — то это не его/её, насколько я понял.
Ну что же — будем ждать комментария от am-amotion-city.
А вам вот вроде и нужно, но не судьба, видать
Серьёзно? Вы себя таким/-ой незаменимым и важным почувствовали вдруг?
Мне не нужно — это вы тут всем доказываете, что опенсурс — наше всё, что все вокруг дураки, и вы — снизошли до общения с низшим сословием, обитающем на ресурсе хабрахабр.
А на прямой вопрос показать портфолио… показать оказалось нечего?!
Да вы неуловимый джо!
Тот Ваш аккаунт, что гуглится «за пять минут» — весьма… пустой; ибо не имеет открытых репозиториев (он и есть личный, верно?). Я бы усомнился, что это Ваш аккаунт после всего, что Вы тут написали. И не зря: у Вас ведь есть ещё один (или даже больше).
Отсюда ещё вопрос: Вы уверены, что TheShock нашёл «тот самый» аккаунт?
Ну что, Леша, как программист — ты хорош. А как человек — ты мудак.
Дабы сэкономить время остальным: https://github.com/am-kantox
А слабо показать портфолио?
Назовите такую компанию? А желательно хотя бы десяток таких компаний, и желательно, чтобы они выжили на рынке хотя бы лет 5. Затем мы посмотрим сколько рабочих мест подобные компании могут обеспечить на все население земного шара.
> Повторюсь, я не агитирую, я просто рассказываю случайно зашедшим людям, что это выгодно на длинном отрезке времени. А просто гнать бабло — нет. Вот и все.
Вот и выясним действительно ли это так. Потому что взять да тот же один Microsoft — IMHO он один может покрыть по количеству рабочих мест все те компании, которые вы назовете.
Бывают и другие материальные интересы кроме выживания.
Да пилить обычно никто не запрещает, запрещают выкладывать рабочие наработки.
Если ваши задачи при этом выполняются хорошо, то какая разница, чьи ещё задачи и когда он решает?
Большинство работодателей не любит недозагруженных работников.
Работотаделю выгодно максимально быстрое решение своих задач, поэтому ситуация, когда эффективный работник выполняет норму, а затем отдыхает, работодателя не устраивает. Работодатель предпочтёт платить такому сотруднику больше, лишь бы он не занимался посторонними задачами.
Я никак не пойму, что вы пытаетесь доказать: что есть неадекватные работорговцы, работа с которыми приводит к деградации разработчиков?Он пытается указать на один простой факт: время между созданием чего-то, соответствующего статусу сеньора и его попаданием в открытые источники зачастую измеряется годами.
Да, вы отрыли часть вещей, которые Джефф Дин создал несколько лет назад. Вещи, которые он делает сейчас — вы не увидите ещё три-пять лет (а часть — не увидите никогда в принципе). И что — вы будете о нём судить вот о той верхушке айсберга, которая всплыла на github'е? Вот по этим нескольким случайно убежавшим процентам того, что он сделал?
Тенденция такова: у достойных внимания на позицию сеньора разработчиков всегда (ну хорошо, за редчайшим исключением) есть портфолио.Извините, но вы несёте чушь сейчас. Подавляющее большинство компаний свой код никому показывать не хочет и не будет. Тот факт, что сейчас на github кода, выложенного разработчиками из Гугла составляет несколько процентов от всего кода, который ими написан как бы говорит сам за себя.
Да, мы рискуем пропустить маньяка-йети, который программирует не выходя из леса.Нет — мы рискуем пропустить нормальных 90% кандидатов и набрать людей, которые, вместо того, чтобы решать поставленные перед ними задачи, тратят время на разные второстепенные вещи. Если вас это устраивает — да ради бога. Но не нужно делать вид, что это — нормальный подход.
Вы упоролись, что ли?То есть Джефф стал сеньором не тогда, когда создал базовую инфраструктуру Гугла, а когда часть проектов, к которым он «в свободное от работы время» приложил руку попала на github?
https://github.com/google/protobuf
и еще дозиллион строк кода: https://research.google.com/pubs/jeff.htmlТам нет кода.
А для задач выдающихся есть чифы, светочи знаний, постигшие дзен решения задач, которые уходят на неделю в
На вопрос: «Оплачивается?», ответили «Нет». И это уже на собеседовании предложили (предупредить с берегу, видимо, никак). Разумеется, я от такого щедрого предложения отказался, они, в свою очередь, тоже мне отказали…
И подобное хотел каждый из десятка предлогателей, физически невозможно выполнить все тестовые из отобранных предложений.
Какие то тестовые были сделаны за ради интереса самой задачи.
Конкретно мне тестовые задания нравятся, позволяют работать мозгам в интересных областях, но тут нужно быть осторожным, что бы не поработать бесплатно на «эффективных» менеджеров.
Если мне говорят «вот доска/лист» — спасибо за приглашение, но досвидание. Опять же, ищут не пойми кого и заниматься придётся задачами которые не соответствую моему уровню.
А причина проста — в резюме записана пачка проектов, которые я делал. Часть из них под капотом имеют то, с чем 95% разработчиков просто не сталкивается. К тому же есть Github, где можно посмотреть код/issues/обсуждения. С багажом в 12 лет за плечами гораздо важнее впишусь ли я в команду или нет, а не могу ли я написать сортировку из головы — нет, не могу и даже не буду пытаться готовиться к этому. Они мне за потраченные на дорогу и собеседование время денег не платят, а я теряю по факту целый день абсолютно бесполезно (нормально работать в этот день уже не получится). Ну и плюсом они тратят свои деньги бесполезно, потому что сами не знают что хотят. А это уже звонок, в какой обстановке придётся работать.
Если честно, то лично я там где дают тестовое задание сразу отказываю — это означает, что они ищут мидла, а не сеньора/тимлида.
Это означает что мозги у соискателя либо атрофировались либо не было. Нагуглить решение — 98% людей. Особой ценности не представляют, то что у вас резюме, это показывает участие, а не вклад.
wait($some_time); // надо подождать так как он долгий
я очень далек от глобального мира программирования, но я очень лизок к IT и людям.
Так сошлись звезды, что я 10 лет управляю и обучаю людей в любой области IT.
Последние 2 года нахожусь в Мобильной разработке и занимаюсь аккумуляцией занний в организации + управлением отделом разработки + обучением. Сам много раз был на собеседованиях на программиста и в 90% случаев я как баран смотрел на человека, который задавал явно те, вопросы, которые он сам может выполнить только потому что он проводит это собеседование.
У меня уже давно наступил порог запоминаемости, чтобы запомнить что то новое — я забываю что то старое.
Решение простое. То что записано и можно найти за 2-10 секунд, можно забыть.
Никогда не понимал требований написать алгоритм. Ты должен знать отличие одних от других, должен знать когда какой использовать, сколько кто стоит, но от руки писать — идите работать в писари.
Никогда не понимал требований написать алгоритм. Ты должен знать отличие одних от других, должен знать когда какой использовать, сколько кто стоит, но от руки писать — идите работать в писари.
Ну тут работает принцип «не помнишь — придумай», задачи специально «детские», чтобы могло подойти «наивное» решение в лоб. Адекватный технарь не будет требовать идеального решения, ему важнее увидеть, как вы думаете, когда решаете задачу, как реагируете на критику (вы же наверняка точку с запятой пропустите или индексом промахнетесь — это нормально!). У интервьюера час времени, чтобы определить, кто перед ним находится. Любая такая крупица информации о вас будет ценной.
А вот вы помните, например, алгоритмы численного интегрирования, а?
Ну если схематично, то помню (особенно, если нарисовать кривую и стобики под/над ней, а потом вспомнить, что это могут быть не прямоугольные столбики, а трапеции, и что это, кажется, как-то было связано с фамилией Симпсон). Только что это лично вам как интервьюеру бы дало? :-)
Хотя парочку самых простых сортировок придумаю на раз два и один из них окажется тем же пузырьком.Так не молчите об этом! Адекватный интервьюер это оценит.
Причем для каждого, внезапно, окажутся разными эти наборы детских алгоритмов, которые все должны знать, причем еще и со всеми вариантами наименования…Согласен, во всем нужна мера.
a, b = b, a
Собеседующий явно ожидал другой вариант, этот его не устроил. Объяснить, почему я не могу пользоваться естественными возможностями языка не смог. Но в попытках предложил написать на другом языке. Дальше был std::swap из С++. Он даже сбегал с листочком к компьютеру. Потом был чисто Сишный вариант с xor'ом, уже из вредности. И многое другое, вплоть до ассемблера, где мы начали обсуждать вопрос о том, являются ли регистры третьей переменной. Работу я, конечно же, не получил, но после первого примера уже и не хотел.
Когда уже встретился с пяткой языков, иногда забываю как цикл писать на пацтоне( правда я и собеседования по нему не прохожу) и такие вещи гуглю. Половина вопросов к гуглу это посииск документации еще треть это гуглинг ошибки. Конечно, без Гугла вам будут долго в док-ции копаться.
даже способный на решение весьма нетривильных задач (например, придумать RoR), на интервью вдруг с треском проваливается, мыча что-то не очень внятное, глядя на, казалось бы, «детскую» задачу
Я в это не верю, а DHH, мне кажется, просто троллит тупых, но очень самонадеянных "программистов на рельсах".
Вот я и говорю, что троллит. Это и по форме "признания" заметно. В поиске описания алгоритма нет проблем, если бы, к примеру, меня, поразил тяжёлый приступ амнезии и я забыл суть алгоритма пузырька, я бы в первую очередь попросил интервьюера мне его напомнить. Это абсолютно нормально. Но в статье DHH пишет, что он якобы подглядывает детали реализации, код. Полагаю, что в таком случае "программист" (не заигрывающий с публикой DHH), не способный по описанию алгоритма написать реализацию пузырька, не способен написать практически ничего. Ну, то есть то, что он будет способен написать не будет представлять коммерческого интереса. И зачем кому-то такой "работник". Это как лётчик, который умеет летать аж на вертолёте, но только по прямой. А чтобы поворачивать ему нужно каждый раз гуглить.
Ну вот если мне вдруг понадобится реализовать алгоритм сортировки пузырьком (не понятно правда зачем, т.к. есть и более эффективные алгоритмы) я тоже в гугл полезу конкретную реализацию смотреть на конкретном языке. Да, я помню основной принцип. Но конкретную реализацию я буду как минимум час-два писать, чтоб все красиво было. А нагуглить это можно минут за пять. И может быть сделано красивее и эффективнее чем я бы сам написал в итоге. Если случится вдруг такое что я буду в бункере без интернета с таблетками бессмертия (чтоб было не ограниченное время), то я смогу написать реализацию не хуже, а может и лучше. Но пока мы живем в реальном мире где время стоит дорого быстрее будет погуглить.
В качестве примера можно провести аналогию с машиной. Я могу сам поменять резину на колесах машины, но я поеду в специализированный сервис, потому что там это сделают быстрее и качественнее.
если мне вдруг понадобится реализовать алгоритм сортировки пузырьком (не понятно правда зачем, т.к. есть и более эффективные алгоритмы) я тоже в гугл полезу конкретную реализацию смотреть на конкретном языке. Да, я помню основной принцип. Но конкретную реализацию я буду как минимум час-два писать
Это означает, что если вы на такой тривиальный код тратите два часа, то на чуть более сложный будете тратить времени ещё больше. Так бывает. Возможно, вам поэтому дают совсем банальные задачки, либо вашего работодателя по какой-то причине устраивает такая неэффективность вашего труда.
Но пока мы живем в реальном мире где время стоит дорого быстрее будет погуглить.
Ну, мир не устроен из совсем примитивных задачек. Я, как правило, работаю над задачами, реализация которых сильно сложнее "пузырька" и кода для которых ещё нет в гугле (по правде говоря, не понимаю зачем работать над такими задачами — они ж уже решены). Ну, а такие простые пишутся вообще не включая голову. Я пузырёк первый (и последний) раз писал приблизительно 23 года назад, не вижу проблемы написать его реализацию минут за пять. Красивую. Там чтобы некрасивую написать специально думать надо.
В качестве примера можно провести аналогию с машиной. Я могу сам поменять резину на колесах машины, но я поеду в специализированный сервис, потому что там это сделают быстрее и качественнее.
Это так если вы способны только на примитивные действия в рамках рода деятельности. Задача смены колёс не входит в задачу вождения машины. Задача реализации алгоритмов напрямую входит в область деятельности программиста. Особенно таких примитивных. Более качественную аналогию я привёл. Вы способны водить машину. Но только по прямой. Если надо повернуть, то вы вызываете эвакуатор, он вас грузит, разворачивает в нужном направлении, выгружает, вы едите до следующего поворота.
Это означает, что если вы на такой тривиальный код тратите два часа, то на чуть более сложный будете тратить времени ещё больше.
А вы вот сами попробуйте написать. Ну и скринкаст запишите в качестве подтверждения. Я посмотрю за сколько вы напишите. С нуля. Ничего заранее не продумывая. На месте вспоминая как это пишется. Включая отладку, рефакторинг и оптимизацию. Сильно сомневаюсь что быстрее уложитесь.
Возможно, вам поэтому дают совсем банальные задачки, либо вашего работодателя по какой-то причине устраивает такая неэффективность вашего труда.
А откуда вы знаете какие задачи мне дают и какая моя эффективность? Не надо делать предположений на пустом месте. ;)
Ну, мир не устроен из совсем примитивных задачек. Я, как правило, работаю над задачами, реализация которых сильно сложнее "пузырька" и кода для которых ещё нет в гугле (по правде говоря, не понимаю зачем работать над такими задачами — они ж уже решены).
Ну вот может тогда стоит тратить время на разработку этих алгоритмов, а не тех что уже давно сотни раз разработаны и оптимизрованы? Как бы об этом и речь.
Задача реализации алгоритмов напрямую входит в область деятельности программиста.
Программисты тоже разные бывают. Есть прикладные программисты, а есть те кто разрабатывают библиотеки. Для первого важно знать библиотеку из которой он может взять функцию сортировки, для второго важно знать наилучший способ сортировки и уметь его реализовывать с закрытыми глазами.
Включая отладку, рефакторинг и оптимизацию.
Крайне редко это требуют на собеседованиях. В худшем (для соискателя) случае попросят отладить, если валится и даёт на простейших данных неверный результат, а если на каких-то граничных случаях валится или даёт неправильный результат, то скорее спросят как будет фиксить, как будешь рефакторить и оптимизировать, а не требовать продакшен код.
Ну я в своем комментарии говорил не о собеседованиях (как и оригинальный топик), а об обычной работе. И вот в обычной работе ну вот совсем не нужно это знание (зависит конечно от специализации). И речь о том что если вдруг возникла такая задача, то вместо того чтоб тратить время пытаясь вспомнить и идеально реализовать этот алгоритм, проще погуглить.
А вы вот сами попробуйте написать. Ну и скринкаст запишите в качестве подтверждения. Я посмотрю за сколько вы напишите. С нуля. Ничего заранее не продумывая. На месте вспоминая как это пишется. Включая отладку, рефакторинг и оптимизацию. Сильно сомневаюсь что быстрее уложитесь.
Гм. 23 года не брал я в руки шашек…
for (int i=0; i<a.length; ++i)
for (int j=0; j<a.length-i-1; ++j)
if (a[j] > a[j+1]) swap(a[j], a[j+1] );
Две минуты на планшете.
Рефакторинг? Оптимизация? Для реализации баблсорта? Отказать.
Ну вот может тогда стоит тратить время на разработку этих алгоритмов, а не тех что уже давно сотни раз разработаны и оптимизрованы? Как бы об этом и речь.
Вр4мя тратить н4 надо. Мы говорим о проверке способности кандидата реализовать простейший алгоритм на три строчки. Если кандидата вгоняет в ступор вложенный цикл с условием, то достаточно очевидно, что более сложные алгоритмы ему и вовсе давать на реализацию бессмысленно. Не бывает так, чтобы человек, не умеющий делать простые вещи умел при этом делать более сложные.
А откуда вы знаете какие задачи мне дают и какая моя эффективность? Не надо делать предположений на пустом месте. ;)
Почему на пустом? Я исходил из вашей же оценки этой задачи.
Программисты тоже разные бывают. Есть прикладные программисты
По-вашему, прикладные программисты это те, которые копипастят уже решённые задачи? По-моему, это и не программисты вовсе.
Есть прикладные программисты, а есть те кто разрабатывают библиотеки. Для первого важно знать библиотеку из которой он может взять функцию сортировки
Какая библиотека, о чём вы? Если для человека отклонение от линейного алгоритма (а он ведь тоже, ужаснитесь — алгоритм! Хоть и линейный) представляет непосильную задачу, то это не прикладной программист, а никакой программист. Водитель, который может ехать только прямо.
для второго важно знать наилучший способ сортировки и уметь его реализовывать с закрытыми глазами.
Ну, давайте вам прикладную задачку подкину — вам надо много раз быстро сортировать массивы из трёх чисел. Или, даже, из четырёх. Какой фреймворк станете разворачивать? Какой эсимейт на решение этой мегапроблемы?
Вы меня не понимаете и говорите совсем о других вещах о которых я писал. Приводите примеры не подходящий тому что я описывал. Не вижу смысла продолжать дальше спор. Какой-то спор глухого со слепым.
Приводите примеры не подходящий тому что я описывал
Переведите это на русский.
говорите совсем о других вещах о которых я писал
Как это о других? Вы же сами просили:
А вы вот сами попробуйте написать
Не ваши слова, не? Ну, вы тогда кошку, что ли, накажите, которая за вас это написала. Чтобы хоть какой-то повод был от собственных слов отказаться. А то вот так прямо, на ровном месте… Это сильно… Посильнее фауста гёте. На таких раскладах и правда бессмысленно о чём-то разговаривать.
Как это о других? Вы же сами просили:
А вы вот сами попробуйте написать
Ну давайте уж полностью приведем цитату что я просил:
А вы вот сами попробуйте написать. Ну и скринкаст запишите в качестве подтверждения. Я посмотрю за сколько вы напишите. С нуля. Ничего заранее не продумывая. На месте вспоминая как это пишется. Включая отладку, рефакторинг и оптимизацию. Сильно сомневаюсь что быстрее уложитесь.
Тем не менее ваш коментарий был на 2 часа позже моего. Поэтому я не знаю сколько вы реально затратили времени. И вы уверены что ваш алгоритм оптимален? (я не утверждаю что не оптимален, но и не уверен что оптимален). А как оптимален по времени или по используемой памяти? И на каком языке? Вроде бы СИ. А если надо, скажем на питоне? Я вот, например, питон не знаю. Мне уже как циклы делать надо будет гуглить.
Но в целом вы почему то не соглашаетесь со мной, хотя говорите о том же что и я только другими словами. Поэтому считаю что спор бесполезен.
Тем не менее ваш коментарий был на 2 часа позже моего. Поэтому я не знаю сколько вы реально затратили времени
Ну, разумеется, все два часа обдумывал эти три строчки. Рефакторил. А сначала провёл сам с собой стендап-митинг и плэннинг-покер. А в конце ретроспекцию.
И вы уверены что ваш алгоритм оптимален?
Задачи алгоритмизации не стояло. Стояла задача реализации заранее заданного алгоритма. Реализация оптимальна, если можно применить это определение к этой реализации. Сам алгоритм можно улучшать, оставаясь в рамках алгоритма, но делать это следует только в очень редких случаях, когда входные данные отвечают определённым условиям. В общем случае — это бессмысленно. Любому программисту (то есть не специалисту по копи-н-пэйст) это понятно.
И на каком языке? Вроде бы СИ
На любом удобном. Нет, это сиподобный псевдокод.
А если надо, скажем на питоне? Я вот, например, питон не знаю.
Не знаете питона и идёте устраиваться на работу питонистом? Такое бывает, но в этом случае надо заранее известить об этом интервьюера и тогда он не станет требовать от вас писать именно на питоне.
хотя говорите о том же что и я только другими словами.
Разве? Я утверждаю, что работа программиста заключается в реализации алгоритмов. Вы утверждаете, что якобы есть какие-то "прикладные программисты", которые не занимаются реализацией алгоритмов (а чего они тогда делают?).
Поэтому я не знаю сколько вы реально затратили времени. И вы уверены что ваш алгоритм оптимален?Как-то даже весело со стороны это наблюдать.
— А это точно пузырёк?
— А вы уверены, что он оптимален по времени?
— А по памяти?
Причём кода-то — 3 строчки ))))
Вы упоролись? Это сортировка пузырьком. Алгоритм такой, общепринятый. У него квадратичная сложность и константная память, это общеизвестно (а кому неизвестно, могут посчитать самостоятельно из описания). Какая оптимальность, о чём вы вообще?
for (int i=0; i<a.length; ++i), последний проход вроде как лишний, достаточно for (int i=0; i<a.length-1; ++i).
Насколько я понимаю, пузырек имеет смысл применять только если исходный массив «почти отсортирован».
Неправильно понимаете.
а вот в реальном мире все же лучше погуглить
Да не надо тут гуглить, ситуация же простейшая. Если даже это нужно гуглить, то это говорит лишь о профнепригодности человека.
Вы, к примеру, тест не прошли сразу по двум критериям:
- Не поняли техзадание (оно состояло в реализации алгоритма, а не в анализе его применимости)
- Провалили анализ этого простейшего алгоритма (возможно, это было бы следующим вопросом :).
ЗЫ. "пузырёк" может быть применён в реальном мире. Навскидку пара вариантов — сортировка коротких массивов из трёх, возможно, четырёх элементов (помимо самостоятельной задачи, это можно использовать для сортировки коротких "хвостов" в том же qsort'е). Только циклы желательно развернуть, если уж до такой оптимизации дело дошло. Ещё вариант, когда у нас есть "эн пополам" параллельных синхронных(!) процессов. Например, "сортировщик", реализованный в железе. Чтобы более-менее эффективно применять пузырёк к "почти отсортированным" массивам надо его изрядно модифицировать — сделать двунаправленным и отсекать начальные отсортированные последовательности в каждом из направлений.
ЗЫ. "пузырёк" может быть применён в реальном мире. Навскидку пара вариантов — сортировка коротких массивов из трёх, возможно, четырёх элементов (помимо самостоятельной задачи, это можно использовать для сортировки коротких "хвостов" в том же qsort'е).
В .NET сортировка вставками (тот же пузырёк), судя по документации, используется до массивов длиной до 16 элементов при вызове Array.Sort.
Кстати, для массивов фиксированного размера я бы вообще использовал сортировочную сеть.
Мне так лениво быть занудой, ну да побуду немного…
<Зануда_mode>
Вы почему-то хотите подмять условия под себя и выглядеть д'Артаньяном… Ну ок, развлекйтесь. Вы например постоянно пытаетесь свести исходную задачу shir к задаче на собеседовании, хотя он четко дал понять, что речь идет о промышленном коде. Если вам в промышленном коде не приходится заниматься анализом алгоритмов, то я рад за вас. Наверное.
Лично я когда встала задача «написать сортировку пузырьком в промышленном коде», не могу абстрагироваться от контекста и тупо фигачить пузырек. Даже если эту задачу поставил мне истинный Гасконец-архитектор со всеми регалиями. Я предполагаю, что какие-то доводы на реализацию этого пузырька (которым многие здесь присутствующие не пользовались десятки лет) были. Единственный посыл, который я знаю — «почти отсортированный массив». Вы, кстати описали один такой — массив из 3-4 элементов. А если из 7 то уже бутылочное горлышко? А если 50? А если из 300 млн, состоящих из блоков по 3 числа, причем блоки уже отсортированны, и только числа внутри блоков нет? Пузырек перестает быть эффективным? Нужно просто не забыть остановить его через 2 прогона. Или досортировать массив строк уже отсортированный по префиксам?
Я к чему веду — контекст имеет значение. Ни я ни вы не знаем какой контекст был в голове у shir, когда он говорил про два часа, но вы вместо того чтобы задать вопрос сделали выводы. Я тоже не представляю, чем там 2 часа можно заниматься, но это профессионально по-вашему? Если контекст был таким — каким вы его себе видете — ваши выводы адекватны. А если нет — то ваша категоричность неадекватна. И вот тогда прогуглить под конкретный контекст — один из способов сэкономить время. Может в итоге и не пузырек вовсе был нужен?
Точно так же вы поступили, когда не удосужились выяснить моего определения «почти отсортированного массива» :). Бросились делать выводы и обвинять в некомпетентности. Зато шпага сверкает.
</Зануда_mode>
На второй такой пост занудства меня вряд ли хватит — времени жалко, так что можете воспользоваться этим, и смело обвинять меня в чем вашей душе угодно. Я наверняка некомпетентен и профнепригоден в огромном количестве областей :).
Какой еще тест? Я к вам на собеседование еще не приходил ;).
А какая разница, если ваши рассуждения лежат либо за пределами темы дискуссии, либо просто неверны.
Вы например постоянно пытаетесь свести исходную задачу shir к задаче на собеседовании, хотя он четко дал понять, что речь идет о промышленном коде.
Ну, вообще-то, если бы вы внимательно посмотрели, то исходная задача — моя :). А если ещё внимательнее, то и не моя и даже не топик-стартера, а DHH. А если ещё вни… Впрочем, ладно. Это как раз shir пытался её свести к какой-то другой, но так и не пояснил к какой. К "какой-то, которая требует гугления, рефакторинга и занимает два часа" ;).
Единственный посыл, который я знаю — «почти отсортированный массив». Вы, кстати описали один такой — массив из 3-4 элементов.
Он не почти отсортированый, он просто короткий.
А если из 7 то уже бутылочное горлышко? А если 50?
Ну, тут надо анализировать альтернативы и более точно считать операции, чтобы определить есть ли решения у уравнения вроде А n^2 = В n * log_2 n, при n>1. Если я ничего не напутал.
А если из 300 млн, состоящих из блоков по 3 числа, причем блоки уже отсортированны, и только числа внутри блоков нет? Пузырек перестает быть эффективным?
Пытаетесь подогнать задачу под ответ? Да, разумеется, оригинальный "трёхстрочный" пузырёк будет иметь здесь всё те же сложность "триста миллионов в квадрате". Модифицированный отработает быстрее. И если бы вы внимательно прочли, то обнаружили бы, что я даже уже расписал способ модификации.
Точно так же вы поступили, когда не удосужились выяснить моего определения «почти отсортированного массива» :).
А это не очень важно. Мой способ подходит и для вашего случая тоже, несмотря на то, что я думал о другом.
Хотя конечно предположение что вы писали 3 строчки 2 часа тоже за гранью адекватности.
Я не могу писать чаще, чем раз в час :). А почему написал не через час, а через два — не помню уже. Хотел через час.
Да, сейчас мы видим его простым и изящным, но за несколько минут его невозможно придумать, только вспомнить.
Можете рассказать эту историю? Какова была первоначальная идея и что именно там додумали? Там же идея примитивная её и упрощать-то дальше некуда.
Что касается "придумать", то да, с нуля у большинства придумывается идея сортировки вставками. Но и пузырёк без труда придумывается. Кроме того, напоминая, задача не стоит в придумывании пузырька, задача в реализации уже придуманного пузырька. Ничего не надо вспоминать.
Да, сейчас мы видим его простым и изящным, но за несколько минут его невозможно придумать, только вспомнить.
Вы знаете, мне когда-то было 15 лет, у меня был советский компьютер «Поиск-1», и я ещё не слушал курс лекций «Модели и структуры данных», но вот отсортировать массив мне уже было надо. Поэтому я не могу оценить труды тех учёных мужей, я на лично примере помню, что придумать простую сортировку — детская забава.
Хороший опытный программист, скорее всего, имеет какую-то свою наработанную специализацию, и она, скорее всего, не из области алгоритмов из учебника. Формальный подход дает формальный результат и победители олимпиад по программированию в боевых условиях часто сильно проигрывают практикам.
победители олимпиад по программированию в боевых условиях часто сильно проигрывают практикам
На самом деле нет: черты характера, позволившие человеку стать победителем олимпиад по программированию (усидчивость, хорошая память, внимание к мелочам и т.п.), могут при достаточной мотивации сделать из него и отличного промышленного программиста. Знаю много людей, которые совмещают и те и другие навыки; хотя прямой связи между этими навыками действительно нет.
Дело не в чертах характера, а натаскивании "нейросети" из собственной черепной коробки на определенный круг задач. Вот тут-то и выясняется, что для олимпиад и практики — эти задачи весьма непохожи (что для многих — контринтуитивно, говорят-то, вроде, об одном и том-же, о программировании). А так — да, и боксер может стать хорошим программистом при достаточном рвении. Но это совсем не значит, что его боксерские навыки ему помогут. Аналогичный пример — вундеркинды: мало кто из них добивается чего-то заметного в жизни, это общеизвестный факт.
В рельности все неоднозначно, конечно, и случаи разные бывают. Но в основном «олимпиадники» работают в фэйсбуках с гуглами и зачастую успешно. Просто потому, что это обычно умные и способные люди.
У Вас богатая фантазия, но, боюсь, она увела Вас далеко от реальности. Мое утверждение никак не связано с поливанием кого-то грязью и принижением чьих-то заслуг. Также Вы понятия не имеете о моих достижениях. Я говорю только о том, что навыки для решения разных специфичных задач — требуются разные. Мой опыт указывает на это со всей очевидностью.
Пример с корреляцией весьма забавный. Во-первых, все мы знаем, что correlation does not imply causation. Во-вторых, как бы там ни было, но пройти собеседование в Гугл определенно легче олимпиаднику.
На одной странице код на C++, а на следующей — его откомпилированная версия под целевую платформу на Assembly )))).
P.S. Это просто абстрактная шутка не касающаяся конкретных людей, так как есть разные условию и лучше делать как есть возможность на данный момент, идя к своей цели.
Даже примерно не помню ни одного алгоритма сортировки, если попросят написать без гугла — изобрету парочку. В работе мне оно как веб разработчику не нужно совершенно. Я не хочу сказать что мне это вообще не интересно, просто когда-то сдал и забыл за ненадобностью, так же как и многое другое, даже гораздо более близкое к реальной разработке. Вот например синтаксис SQL иногда приходится гуглить, так как обычно все решает ORM, и забывается он на ура. Никогда таких вещей не стесняюсь, на собеседовании если заставляют писать SQL на бумажке обычно вообще отказываюсь, и ничего, еще ни разу из за этого не получил отказ.
Зря вы так с sql
Аргументы?
ORM решения универсальны, но не оптимальны, годятся только для проектов где производительность (по каким-то причинам) не важна вообще. Таких много, таких большинство, но все же это далеко не 100%.
«Грязный костыль» sql запросов проложенный в обход ORM может ускорить загрузку веб-сайта в 10 раз легко и так же потребление ресурсов снизить, что уж тут говорить о чисто интегрированном sql решении в веб-сайт, вместо ORM.
Ну, это просто значит что понятие «архитектура БД» для Вас мало что значит.
Ничего себе вывод. А как это получилось из того что я плохо помню синтаксис SQL? Я уж молчу что понятие «архитектура БД» включает в себя не только реляционные БД.
ORM решения универсальны, но не оптимальны, годятся только для проектов где производительность (по каким-то причинам) не важна вообще.
От 90% запросов в обычном проекте (где производительность вообще-то важна) будут одинаковыми по производительности (да и вообще различия будут чисто синтаксические) если их писать руками или с помощью ORM. Для остальных я знаю чего мне нужно добиться и пишу SQL если приходится. Вот тут то и приходится гуглить. И кстати, не считаю что это «Грязный костыль», даже в кавычках (при условии что не нарушена инкапсуляция итд).
А как это получилось из того что я плохо помню синтаксис SQL?В основном это получилось из «все решает ORM»:) Ни в коем случае не настаиваем на правоте.
Вот что Вы скажете человеку высказавшему мысль что «в автомобиле все решает газ и тормоз»? Не, ну так-то конечно решает, но заподозрить такого человека в глубинном знании устройства авто и принципов контраварийного вождения трудно.
Проблема заключается в соотношении стоимости разработки к стоимости использования и поддержки продукта. Обычно покупка десятикратного количества серверов обходится дешевле.
Нужно переписывать код, а чтобы понять, какие хинты дать ORM, надо спуститься на уровень SQL.
Проблема заключается в соотношении стоимости разработки к стоимости использования и поддержки продукта. Обычно покупка десятикратного количества серверов обходится дешевле.Последнее время все больше наблюдаем отход от этого, несмотря на рост мощностей серверов.
Когда проект только начинается, разница между 1000 за сервер и 10000 за 10 серверов выливается в 9 тысяч за сервер в месяц, это мало того что не такая уж маленькая сумма, но и может являться гранью между рентабельностью и не рентабельностью.
Кроме того, есть нюанс по разработке. Один сервер достаточно легко масштабируется до 3 (просто разбросом базы, веб-морды и кода на разные сервера), но дальнейшее масштабирование подразумевает наличие хорошего архитектурного решения позволяющего распределять нагрузку на 10 серверов.
Вынос в облако не всегда решает, т.к. это все же обычно дороже плюс не все и всегда туда можно вынести в принципе.
Автор, вы выдаете желаемое за действительное. Все твиты кроме первого говорят о технических деталях, а не об алгоритмах (длина строки, SQL). И мне кажется, что 4 твита — не слишком большая выборка для столь громкого заголовка, он звучит как "все программисты в мире". Алгоритмы знать нужно, хотя бы понимать смысл работы. И готовиться к собеседованию тоже нужно.
Они все тоже про технические детали. Не знаю метод или класс. А топик-стартер лучше бы потратил пять минут на википедию. Тем более, он знаковая фигура в мире рельс, и теперь еще больше джуниоров начнут говорить, что алгоритмы не нужны.
а нафига они нужны? Я за 20 лет только в геймдеве алгоритмы писал. И нет, такие алгоритмы не учат в вузах. Сейчас если тебе нужен алгоритм ты просто берешь либу. Или гугл в помощь. Имхо, Пытаться все знать заранее — это какая-то болезнь, которую развивают в учебных учреждениях.
Работа чистого программиста заключается в основном в переводе алгоритмов в код. Мы пишем алгоритмы в строго формализованном виде и по сути ничего другого и не делаем.
ЗЫ Знаю что толсто, просто на веселье пробило. Понедельник, все такие серьезные.
И даже если используешь готовые алгоритмы из фремворка, знать эти алгоритмы крайне желательно, чтобы, как минимум, оценить границы применимости, сложность и т. д.
Я учился во времена, когда программы писались на листе и сдавались для запуска на перфорацию.
Поэтому навыками рукописной работы с кодом овладел еще в вузе (кстати в одном интервью мне удалось написать корректно сортировку пузырьком, хотя я просто его помнил, так как имел опыт преподования программирования для студентов).
Но значимо ли это умение для оценки программиста на работу?
Думаю нет.
Все-таки любое интервью является стрессовой ситуацией, что не способствует сосредоточенности, необходимой для корректного написания кода, тем более, что наличие сред разработки предупреждает многочисленные описки, что снижает уровень навыков внутреннего синтаксического контроля.
Мне кажется, что в ходе интервью необходим рассказ о предыдущих выполненных проектах
И при необходимости лучше дать тестовое задание и обсудить его результаты при собеседовании
Имхо, как-то дико хвастаться пробелами в школьных знаниях. Во всяком случае, мне в 90х в обычной школе далеко в тундре рассказывали про деревья, двоичный поиск, сортировку пузырьком и вставками.
Со специфичными вопросами по языкам/фреймворкам всё немного не так — ответы на них показывают опыт работы с конкретным языком/фичами. Если кандидат рассказывает о своей сложной базе на рельсах, он не может не помнить синтаксис миграций. Если кандидат не знает, как найти длину строки в питоне, то питон точно не его основной язык.
К примеру, заезженный вопрос по джаве "какие есть методы у класса Object". Интервьювер ожидает не заучивание явадока, а список методов, которые кандидат использовал настолько интенсивно, что они намертво застряли у него в памяти.
вопрос по джаве «какие есть методы у класса Object»
Прочитал, подумал про себя, с ужасом понял, что не помню ни одного.
4 года подряд опыта разработки софта на java… когда пишу код, мой мозг при этом не участвует… пишут какие-то гномики
Мда? Ни разу не использовали toString()? Не знаете, что для того, чтобы положить объект своего класса в HashMap, надо консистентно реализовать equals() и hashCode()? Ну это из простого, без всяких wait()/notify() и прочих clone() (привет, Cloneable!)
У меня для вас плохие новости.
Правда про объект — делаю несколько иначе.
Я обычно такой ерундой себе голову просто не забиваю. Мой кэш памяти не слишком большой, в жизни есть более важные вещи. А когда сажусь решать конкретную задачу, то быстро понимаю где прочитать документацию и оперативно подгрузить данные в мозг. Когда код написан — данные из памяти мгновенно стираются. Помогает вне офиса не думать о работе. И на сон положительно влияет.
А так, и наследование, и инъекции, и ORM (что по xml, что по аннотациям), собственноручный парсер JSON (еще до появления этой либы), сокеты и т.д.
А вот на такие мелочевки в памяти ни места, ни приоритетов.
Ну так вам вопрос задали, нужно как-то взять себя в руки и вспомнить, блин. Потому что если вы не знаете про equals/hashCode, то никакой гугл вам не поможет, пока баге в проде не полезут.
положить объект своего класса в HashMap,
Правда про объект — делаю несколько иначе.
Еще раз повторюсь, что работа с объектом у меня проблемы не вызывает — есть отличная библиотека, что позволяет работать безопасно. Я использую ее.
*Безусловно, понимаю, что это «не спортивно». Но скажем так, современные технологии и приемы проникают в нашу жизнь постоянно. Если завтра нас отключат от гугла, то и это не будет лично для меня проблемой — предложений на работу у меня хватает со всего северного полушария. Если гугл исчезнет совсем, то опять же эти знания не будут иметь ровно никакой ценности — будет важней навык выживания в постъядерном мире.
**Ваша жизнь — она ваша, а моя остается моей. Вам я никак не запрещаю помнить нативные реализации, считаете что это для вас весьма важно — никаких проблем :)
Однако для меня это ценности никакой не имеет. Вот правильно сделать архитектуру, чтобы спустя пару-тройку лет команда не поимела кучу боли — это в моей шкале более ценно.
мне в 90х в обычной школе далеко в тундре рассказывали про деревья, двоичный поиск, сортировку пузырьком и вставками.
Повезло вам, нас в 2000х учили пользоваться паинтом, браузером, включать компьютер и т.п., ну и в конце вершиной было написание программы решения квадратных уравнений на qbasic
вопрос по джаве «какие есть методы у класса Object»Мне подобный вопрос задали по C#. На тот момент было 5 лет опыта работы на C#.
Завис на какое время. Кое-как вспомнил парочку. Никогда не приходилось об этом задумываться, не глядя при этом в IDE.
Считаю подобные вопросы не правильными. Высокий шанс нанять того, кто вчера это просто зазубрил, но не пользовался. Эффективней показать список методов класса Object и попросить рассказать, что они делают.
Хм. Ну не знаю. Когда я это спрашиваю — я ожидаю совсем не этого. Хотя бы потому, что никогда сам не использовал «настолько интенсивно» именно их. Это сильно зависит от задач.
И кстати, по той же причине — никогда не понимаю, когда меня о них спрашивают, что именно человек ждет получить. Слишком о разном можно рассказывать.
Если кандидат рассказывает о своей сложной базе на рельсах, он не может не помнить синтаксис миграций.
Семль лет (или уже восемь?) разработки на рельсах. За плечами десяток разных проектов. И нет, я не помню синтаксис миграций. Что-то там генерируется… Ну да, как колонку описать помню. Помню как индекс описать. Хотя как удалить индекс уже приходится подглядывать, помню только что синтаксис немного отличается от создания. Как сделать реверсивную миграцию уже не получается запомнить. Что-то там revers.... А вот как описать таблицу с нуля уже точно не помню. Вы не поверите, но после работы с некоторыми проектами где база редко меняется, я забываю как генерировать миграции :)
Интересно, а как именно он понял, что это считали ошибкой? Попытался исправить у него вырвали ручку и указали на дверь?
А алгоритмы — да, stackoverflow и вперёд. Не вижу никакого смысла держать это в голове.
не сделаешь switch на пять позиций, когда есть ощущение как обойтись наследованиемПодвис на этой фразе минут на пять. Можно пояснить, как связан switch и наследование? А то ночь без сна провести боюсь
case Type.Type1
DoSomthing(1)
break
case Type.Type2
DoNothing(2)
break;
case Type.Type3
Cool(5)
DoSomthing(1)
brear;
default:
Standart(8)
break;
Что то такое, и так в каждом из методов.
Если вижу что-то типа такого
class MathOperation
{
double Execute(double op1, double op2, string operation)
{
switch (opearation)
{
case "+": return op1 + op2;
case "-": return op1 - op2;
// etc...
}
}
}
то сразу хочется сделать что-то такое
class AddOperation : MathOperation
{
override double Execute(double op1, double op2, string operation)
{
return op1 + op2;
}
}
class BinOp(object):
impl = {'+': lambda x, y : x + y, '-': lambda x, y: x - y, ...}
def execute(self, x, y, op):
return BinOp.impl[op](x, y)
Какие вопросы однозначно придут (должны однозначно прийти) нам в голову перед написанием данного приложения?
1.Отличается ли написание кода для вывода различных фигур?
Однозначно, да! Вы не сможете вывести идентичным алгоритмом треугольник и квадрат, поскольку количество вершин уже говорит само за себя. Следовательно, для вывода каждой из этих фигур нужно будет написать разный код.
2. Будут ли добавляться новые фигуры для вывода?
Если «нет» сейчас, то не факт, что потом заказчику не придет в голову начать развивать свой продукт. И тут новые программисты придут и будут
После ответа на вышестоящие вопросы, в худшем случае мы придем к выводу, что программа должна поддерживать отрисовку каждой фигуры отдельно и обладать способностью внедрения новых фигур.
Для воплощения есть два принципиально разных подхода: Структурный или ООП-шный. Дабы не рассусоливать здесь столько, сколько бы хватило на целую статью я приведу примеры каждого в коде:
Структурный:
public class FigureShower{
public void render(Figure figure){
switch(figure.index){
case 0: //Cube
...
case 1: //Sphere
...
case n: //Arbitary chosen figure
...
}
}
}
ООП-шный:
public interface Displayable {
public void render();
}
public class Cube implements Displayable {
public void render(){
//instruction for cube rendering
}
}
public class Sphere implements Displayable {
public void render(){
//instruction for sphere rendering
}
}
...
public class NFigure implements Displayable {
public void render(){
//instruction for n-figure rendering
}
}
Можете воскликнуть: да тут то особой разницы по величине кода да и нет! И вы будете правы. Но есть пару моментом на которые стоит обратить внимание.
1.Если программист пользователь захочет сделать фигуру выводимой, то в первом «структурном» случае ему самому вспомнить, что прога не работает, потому что он забыл добавить в switch новые инструкции. В ООП-ном компилятор сам напомнит реализовать функцию.
2. Читается ООП-шное творение куда приятнее. Ну это, конечно, больше дело вкуса…
За большей информацией обращайтесь к Роберту Мартину и его творению «Чистый код»
Однозначно, да! Вы не сможете вывести идентичным алгоритмом треугольник и квадрат, поскольку количество вершин уже говорит само за себя. Следовательно, для вывода каждой из этих фигур нужно будет написать разный код.
Смогу. Обычный алгоритм рисования произвольного многоугольника, заданного упорядоченной коллекцией координат вершин с выделением функции рисования отрезка и передачи ей пар вершин в цикле с возможным выделением функции рисования точки. В принципе любую задачу вывода планиметрических фигур или проекций стереометрических можно свести к функции рисования точки, вызываемой из цикла, получающего коллекцию точек для входа. Для разных типов фигур, для разных типов их задания функции получения коллекций точек будут разные, но это стандартные задачи решения геометрических задач численными методами.
Насчет ООП — подобный вопрос позволяет легко выяснить уровень кандидата.
Джуниор начнет рассказывать про синтаксис языка, ключевые слова class, extends и implements, ну и вспомнит заученную мантру инкпслц-нслдвн-плмрфзм. Сеньор или хороший миддл расскажет про принципы SOLID и подобные вещи, причем не заученное из учебников, а свой опыт.
Вот, кстати, да. Не каждый миддл слышал про SOLID.
Хабр не каждый миддл читает :) Реально люди даже с десятком лет опыта могут про SOLID не знать, ограничиваясь документацией к языку/феймворкам, причем справочной её частью. Ну или слышали абреввиатуру, но содержания не знают. С другой стороны в беседе может оказаться, что сами принципы знают и используют, просто не знают, что это имеет собственно название, за эти десять лет сами пришли к тому, что у класса должна быть единственная ответственность и т. д.
Но после 5 лет разработки я сходу не вспомню алгоритма.
Почему? Да потому что ни разу за это время она мне не пригодилась, всегда использовал методы/функции языка, и в большинстве случаев они были эффективнее.
Если вдруг мне понадобится написать оптимальную сортировку для набора данных я в первую очередь проанализирую эти данные и постараюсь выбрать наибелее подходящий алгоритм и 99% что это будет НЕ метод пузька.
Так что не считаю что все должны его помнить, врочем то же самое относится и к большинству других алгоритмов.
То, что подобное спрашивают на собеседованиях можно сравнить со случаем если бы вам не продали газету с объявлениями если вы не отгадали часть кроссворда. С очень большой долей вероятности эти знания вам не понадобятся в чтении объявлений (работе).
В тех собеседованиях что я учавствовал было 4 типа проверки знаний:
1) Беседа о реализованных проектах, применённых технологиях, трудностях.
2) Вопросы об основах работы (сеть, протоколы, ОС, браузер).
3) Тестовое задание. При этом алгорим рассказывали сразу, спрашивали как собираешься делать, иногда рассказывали о фейлах других собеседующихся и смотрели на реакцию.
4) Реализация алгоритма/задачки на месте. Опять же алгоритм рассказывали сразу, если была необходимость. Смотрели как реализуешь, просили проговаривать мысли вслух.
Эти подходы были отдельно либо вместе на одном собеседовании.
Именно их считаю правильными.
Но после 5 лет разработки я сходу не вспомню алгоритма
Так задача и не стоит в придумывании или вспоминании этого алгоритма. Никому (ну, кроме гугла и яндекса) не интересно помните вы его или нет. Задача стоит в проверке вашей способности реализовать заданный алгоритм. Пузырёк здесь выбран исключительно потому, что он настолько прост, что его трудно забыть. Но если вы с молотилки упали и страдаете ретроградной амнезией, то нет ничего страшного, если вы попросите напомнить суть этого алгоритма.
Надо не запоминать, а понимать.
Я не собираюсь забивать себе голову всякой ерундой, которая мне нужна раз в три года. Ну или в случае алгоритма сортировки пузырьком — не понадобится никогда.
То же самое касается нечасто используемых функций/методов стандартных библиотек. Зачем мне это помнить, если IDE подскажет?
Впрочем, пузырек или merge sort я легко воспроизведу — суть понятна из названий. А вот quicksort я хрен вспомню просто так. В общих чертах что-то припоминаю, не более того. Но мне это никогда не понадобится, потому что уже есть эффективные стандартные реализации.
Вот, написал за 5 минут:
void qsort(T *arr, int left, int right)
{
if (left >= right)
return;
int l = left, r = right;
T pivot = arr[(left + right) / 2];
while (left < right)
{
while (arr[l] < pivot) l++;
while (arr[r] > pivot) r--;
if (l < r)
swap(arr[l++], arr[r--]);
}
qsort(arr, left, r);
qsort(arr, l, right);
}Помню только потому, что раньше (в 90-е) он не являлся стандартным алгоритмом, и его постоянно приходилось писать.
Сейчас, понятное дело, только IDE, только библиотеки.
В 90-е я был школьником, на найденной дискетке с турбо-бейсиком (это где-то 93-й год был, или 94-й) была реализация quicksort без рекурсии. Не то, чтобы я знал и про рекурсивную тогда, но разобрался.
А щас вот нифига не помню, ну, то есть, теперь-то вспомнил :)
И тут сразу 2 ошибки: Первое — цикл while у вас по left/right, а внутри меняються l и r.
Второе — может быть случай, когда задается массив из двух чисел, то один из указателей не будет сдвинут и в рекурсивном вызове вы с теми же параметрами вызовитесь и будет бесконечная рекурсия.
Это хороший пример — вызубрить эту реализацию сложно, можно знак перепутать легко. Но если понимать, что тут происходит, да еще и с подсказкой интервьювера, эту ошибку очень просто отловить.
И тут сразу 2 ошибки: Первое — цикл while у вас по left/right, а внутри меняються l и r.
Верно. У меня сначала не было l и r, я изменял значения left и right, но потом я вспомнил, что старые значения left и right нужно сохранить, и ввёл две новые переменные, забыв исправить условие.
Второе — может быть случай, когда задается массив из двух чисел, то один из указателей не будет сдвинут и в рекурсивном вызове вы с теми же параметрами вызовитесь и будет бесконечная рекурсия.
Да, вместо l < r нужно использовать l <= r. Один раз накалывался.
Впрочем, если в начале функции делать проверку на длину массива и при длине меньше 8 вызывать простую сортировку, то эта ошибка бы не вылезла.
О, а я, кстати, не заметил про left/l и right/r. :) По общей картинке алгоритм вспомнил и не обратил внимания — в голове "прочитал" там именно l и r.
Думаю, если человек это пишет не молча, а рассуждая вслух, то понятно, что не вызубрил.
Кстати, вопрос именования, если назвать не left/right, а, скажем, low/high, ошибка сразу очевиднее. Вот на эту тему можно было бы и побеседовать.
Но всё надо «пропускать через руки». Простое понимание, от того что вы прочитали и скопипастили — не поможет. Эффективней для запоминания — это набрать руками. Возможно выше я не совсем точно определил границы — не только алгоритмы, но и функции и методы — все нужно набирать руками, а не копипастить.
А, вы про это. Честно говоря, не припоминаю ситуаций, когда я что-то копипастил.
Разве что когда была необходимость выполнить функции сисадмина и настроить какой-нибудь там exim или named, в детали которого я погружаться не желаю и хочу чтобы просто все заработало.
А с программированием — ну не знаю, не помню таких случаев. Гуглишь-то какие-то детали и идею, а реализацию все равно писать самому под свои условия и свою архитектуру. Единственный, наверное, случай, это когда изучаю что-то совсем для себя новое, читаю какой-нибудь онлайн-туториал — тогда могу скопипастить пример и уже его править, чтобы разобраться, как это повлияет. Да и то сейчас для такого чаще есть возможность склонировать гит-репозиторий.
Те несколько раз, когда я собеседовал людей по Javascript, спрашивал лишь самые базовые вещи — приведение типов, hoisting и замыкания – всё на базе подготовленых мной примеров кода, не требуя никаких формальных определений.
Гуглокодеров видно сразу и не по незнанию алгоритмов, а по неумению подходить к решению задачи. Я предлагаю что-то нестандартное для человека, например, спроектировать описание комнаты или описать процесс забивания гвоздя в стену. Умиляют ответы типа я же не строитель. Т.е абстрактное мышление отсутствует как область. Но кодеров, например, раньше готовило ПТУ, а если у вас высшее образование, то и должны уметь больше. И не писать на листочке, а проверяю способность излагать свои мысли.
Но знание алгоритмов тоже мало что показывает. Например, большинство олимпиадников, которые знают кучу алгоритмов, в жизни слабо ориентируются, т.к. она нелогичная. Опять же прогресс не стоит на месте и скорей всего есть более совершенная реализация и как инженеру вам лучше ее использовать. Но ориентироваться быстро в предметной области нужно обязательно
Давать задания дольше, чем на 1 час — нельзя, так как личное время важно.
Просить написать код на листочке — нельзя, т.к. на работе пишут не на листочке.
Спрашивать какое-то API — нельзя, так как оно может меняться и зубрить не имеет смысла.
Спрашивать Кнута-Кормена — нельзя, так как выветрилось из головы еще на 2 курсе.
Спрашивать ООП нельзя — так как для компилятора это не играет никакой роли.
Спрашивать Design Patterns нельзя — так как кроме синглтона, фабрики, обзервера, команды и адаптера не используется.
Надо было начинать твиты с фразы "Привет, я программист и я не умею программировать. Просто повезло, что железо мощное и оперативки много. Поэтому мой код работает и зарабатывает".
Спрашивать ООП нельзя — так как для компилятора это не играет никакой ролиЗато для других разработчиков в команде играет.
Спрашивать какое-то API — нельзя, так как оно может меняться и зубрить не имеет смысла.Если проект пилится на конкретной версии, то почему нет? Как вы и сами сказали, от версии к версии многое меняется, посему знать различия довольно полезно.
А статья пробует преподносить это как то, что «знаю английский со словарем» для переводчика нормально, а ответ программиста на собеседовании «если мне надо знать как цикл пишется я посмотрю, а если мне понадобятся паттерны ооп я их за пять минут найду».
Но если нанимается переводчик, от него ожидается работа по переводу, а если программер, то работа по программированию… если бы нужен специалист по гуглению знаний — такого бы и наняли.
При чем если это выливается в то, что программер 70% времени гуглит как что-то написать — это еще можно терпеть.
Хуже когда наступает этап, когда у программера всплывает необходимость разобраться в чужом коде. Потому что если нагуглить «алгоритм пузырьков» с целью его реализации еще можно, то вот увидев «алгоритм пузырьков» программер не сможет нагуглить что это и будет неделю втыкать и пытаться разобраться спрашивая на форумах.
Именно отсюда появляются люди, которые не могут понимать чужой код и кончается это старым известным «да этот код говно лучше написать новый». Конечно лучше блин, если ты в старый воткнуть не можешь, что тебе еще говорить?
p.s.: И да, создателям языков и людям с 30 летним стажем все эти вещи разумеется знать уже не надо, т.к. они не рядовые программеры и это уже далеко от них, задачи сделать подобное они спускают вниз, а не выполняют сами. Но если ты не руководитель проекта с подчиненными 100 программистами, то утешать себя способностью нагуглить функцию длины строки это бред.
Собственно обычно берут на работу человека, чтобы он программировал в "реалтайме". Если нужен "батч", то берут подрядчика на аутсорс, перекладывая на него ответственность за организацию работы "реалтайм".
Кстати, у вас не возникает вопроса, почему книга «Идеальный код» вообще не об алгоритмах?
Я понимаю "реалтайм программирование" как реализацию предоставленных алгоритмов в коде за разумное время без дополнительных исследований. Если человеку для написания цикла или инициализации массива в языке, который он позиционирует как свой основной, нужно лезть в "словарь", то вряд ли мне захочется с ним работать.
Потому что она именно о "реалтайм" программировании. О том как идеально реализовать уже решенную алгоритмически задачу без поминутного заглядывания в "словарь", чтобы решив выделить метод не лезть в спеку языка смотреть, а как вообще методы в целевом языке декларируются.
Обычно всё это в стандартной библиотеки языка. Никто не запрещает её использовать обычно. Равно как де-юре не стандартные, но очень популярные. А вот тратить время на исследование вопроса есть ли готовая библиотека для задачи, сколько их, какая из них лучше для проекта подходит и т. п. уже выходит за рамки "реалтайм" программирования, если своя наивная реализация, которую потом можно будет оптимизировать или заменить на стороннюю, пишется за полчаса. Тем более, что, как правило, вопрос о включении стороннего кода в проект это не ответственность отдельного разработчика и даже не команды разработчиков и(или) её лидера. Как минимум ещё юристы должны дать добро, что предполагаемый сценарий использования не нарушает лицензии и прочих прав третьих лиц, возможно бухгалтера на баланс поставить и т. п.
Нет, не конвейер точно. Но если мне говорят (или я кому-то говорю), что надо какую-то получасовую фичу взять и сделать "вчера", то это значит что времени на гугление нет, надо брать и делать, чтоб работало. Потом можно заниматься исследованиями, поисками более красивых/быстрых/меньших решений, но сейчас надо брать и делать способом, не требующем исследований.
Это не запрет на использование стороннего кода и просмотр документации, можно использовать уже используемый, можно вводить хорошо знакомый, можно смотреть в документацию, но нельзя тратить время на исследования если наивная самостоятельная реализация не занимает много времени, а оценка времени на исследования значительно больше. Никто не скажет слова против, если на просьбу оценить сроки скажешь "дайте минутку, я погуглю, может есть готовое и простое в использовании решение и сделаю на его базе за 15 минут, а если нет, то за полчаса сделаю сам", но если через минуту скажешь "вроде нашел что-то похоже, но надо полчаса на то, чтобы разобраться подходит или нет технически, да лицензия не входит в список одобренных юристами", то скажут "пиши сам",
Касательно «не математики», то я был на защите магистерской работы одного теоретика, он придумал алгоритм для какой-то задачи, который улучшал предыдущие известные алгоритмы. Так вот на защите его спросили, а сравнивал ли он реализацию своего алгоритма с другими, на что он ответил, что он не силен в реализации, так что алогритм он придумал, но реализовывать его не стал. Т. е. математики, очевидно, тоже не всегда могут реализовывать свои алгоритмы. Вопрос, а кто же тогда будет реализовывать эти алгоритмы?
Ну и как факт, за пол часа я вполне могу реализовать Heap Sort, Merge Sort или Quick Sort. Не то чтобы это требовалось мне часто, но если вы понимаете алгоритм, то не понятно какие проблемы могут быть с тем, что бы его закодить. Код для Heap Sort может быть довольно массивным, но как не суметь реализовать простой Merge Sort, я не очень понимаю.
Не каждый кандидат приходящий в компанию на собеседование — Кармак. И оценивать кандидатов так, как-будто все они «как Кармак» — смешно и не дальновидно. Более того, то, что вы можете найти решение каких-то задач в Интернет, не значит, что вы сможете найти там адекватное решение любой задачи, т. е. не значит, что вы не должны уметь решать задачи самостоятельно.
Элементарно, чтобы оценить найденное на просторах Интернет решение вы уже должны обладать каким-то уровнем понимания, чтобы проверить его корректность и чтобы оценить его эффективность.
Да, люди, которые знают мало, работают с тем же темпом, что и те, которые знают много. Знания, они, в среднем, слабо влияют на скорость нажатия клавиш.
Но всё упирается в проект. Если нужна посадочная страница, которая поживёт месяц, то вполне сгодится мало знающий. Если же это серьёзный проект, то малое количество знаний выливается в крупное количество бабла при масштабировании проекта.
С посадочной не всё просто. Если средний пользователь из-за низких знаний разработчика не дожидается загрузки страницы и закрывает её, то очень много бабла на продвижение может оказаться потраченным впустую.
Как человек, работавший и над маленькими, и над большими проектам, могу сказать, что маленькие не взлетают чаще именно из-за концентрации рисков на 1 человеке. В то время как большой проект — это система, её завалить сложнее.
2. Перед собеседованиями в одну не безизвестную компанию, где спрашивают простые алгоритмические задачи, меня специально предупреждали, что главное не решение, а мысленный процесс. Т. е. то, что они оценивают — это как вы ищите решение задачи. И, в этом смысле, алгоритмические задачи ничем не хуже любых других.
3. Сортировка и алгоритмы сортировки — не абстракные понятия. Идеи используемые в различных алгоритмах, конечно, абстрактны, но конкретных примеров их применения вполне достаточно. Так что, не смотря на абстрактность понятий, польза от них вполне конкретна.
Среди моих утверждений не было:
1. только алгоритмические вопросы и никакие другие;
2. алгоритмическиме вопросы работают для всех;
Среди моих утверждений было:
1. нет ничего плохого в попытке оценить мысленный процесс;
2. нет ничего плохого в использовании алгоритмических вопросов для оценки мысленного процесса;
3. алгоритмические задачи встречаются в реальной жизни;
4. инженер — интеллектуальная работа, т. е. он должен уметь искать решение задач.
Это не инженер, это банальный кодер (monkey).
Если надо брать человека для клепания страничек на базе какого-то фреймворка/CMS, то я буду гонять его по ним.
Если надо брать человека для реализации в коде алгоритмов, придуманных бизнесом/аналитиками/мною, то посмотрю как он реализует хорошо известный алгоритм типа пузырька (если вдруг не знает или забыл, то дам описание), просто чтобы не пугать его реальными алгоритмами оперирующими терминами предметной области, зачастую имеющимися и в разработке, но отличающимися значениями типа "операция" и "транзакция"
Если надо брать человека для придумывания и последующей реализации эффективных алгоритмов для решения задач бизнеса, то будут задачи соответствующие типа в 23:59:59 у пула сущностей в сотни тысяч должно быть одно значение атрибута, при запросе к веб-морде начиная с 00:00:00 должно быть другое, в зависимости от состояния на 23:59:59, а к 2:00:00 новые состояния должны лежать в базе с учетом изменений прошедших за это время, а на расчёт нужно порядка 8 часов.
Когда переводчик переводит приложение, а не транслирует речь в реал тайм, то нет ничего плохого смотреть в словарь.Есть. Две важнейших вещи
1) Это время. Переводчика нанимают на 40 рабочих часов в неделю что бы он 40 рабочих часов в неделю переводил. А не 10 часов переводил, а 30 часов гуглил переводы, имея по факту эффективность в 25% и 75% времени занимаясь не работой, а самообразованием.
2) Это качество. Если переводчику нужно смотреть в словарь, это значит он не понимает ни нюансов перевода этого слова, ни уместных способов применения этих слов, ни контекста, ничего — потому что словарь всего этого не дает. Перевод это нечто большее чем проставление тупого соответствия слов одного языка словам другого.
В случае с программингом (как и с любой другой профой) играют роль те же факторы.
Видите ли, именно поэтому компании предпочитают нанимать специалистов, да еще и с опытом, а не новичков вообще ничего не знающих (но несомненно умеющих нагуглить как перевести с урду на латынь). Все промежуточные варианты это по сути рыба второй свежести.
Какие-то узкоспециальные вещи можно не знать, какие-то могут выпасть из памяти, но это должно быть редчайшим исключением, а не предметом для гордости с аргументом наизготовку «если что нагуглить», потому что нагуглить может кто угодно, но профессионализм тогда в чем?
В том, чтобы уметь это применить. Знания в голове это тоже своего рода гугл, только встроенный.
А если это у Вас в гугле вместо головы, то Вы с этим незнакомы.
А вот прочитаю, и буду знаком. После прочтения ведь оно появится в голове. Естественно, это не с каждой задачей работает, есть такие, с которыми даже с гуглом надо не один час разбираться. Но и встречаются они реже, чем простые.
Вопрос риторический. И чем Вы тогда лучше любого дворника? Он тоже прочитает и будет знаком, у него тоже появится это в голове.
В свое время знаковой строкой в резюме было «легко обучаем», это означало что работник не фига не знает и надеется на авось, на то что его обучат, на то что пронесет. Сейчас это звучит как «знаю английский со словарем» и «нагуглю если что».
Это эпик фэил, и самая трагедия тут в том, что человек считающий что «он все нагуглит, а значит он и есть профессионал в переводе» искренне убежден в своей правоте.
90% выпускников вузов носители теории «если что нагуглю я крут» с прицелом на зарплату «овер 3к в месяц» так и остаются за бортом пару лет, пока в голове что-то не проясняется.
Погуглите на эту тему, будете знакомы:)
И чем Вы тогда лучше любого дворника? Он тоже прочитает и будет знаком, у него тоже появится это в голове.
Тем, что умею это применять.
и самая трагедия тут в том, что человек считающий что "он все нагуглит"
Считать так тоже неправильно. Поэтому я и написал, что задачи бывают разные.
Тем, что умею это применять.Не прочитав? Уже умеете? Это сильно:)
Диалог был такой:
— А вот прочитаю, и буду знаком.
— И чем Вы тогда лучше любого дворника? Он тоже прочитает и будет знаком.
— Тем, что умею это применять.
Где вы увидели, что "не прочитав"?
В последней фразы Вы утверждаете что умеете это применять, хотя из первой фразы прямо следует что Вы еще не прочитали.
Последняя фраза подразумевает действия после прочтения, потому что нельзя применять то, чего еще нет. В общем-то весь этот тред подразумевает знания, уже полученные из гугла. А первая и вторая подразумевают условное наклонение, а не изъявительное. Поэтому третья это действие после выполнения условий.
И чем Вы тогда лучше любого дворника? Он тоже [может прочитать] и будет знаком, у него тоже появится это в голове.
Тем, что умею [потом] это [которое появилось] применять.
В терминах плиточников это будет по другому — Вы пригласили бригаду класть плитку и вот они приезжают в количестве 5 человек и оппа… достают ноуты, один гуглит какую плитку лучше купить, другой какой раствор лучше купить, третий как его лучше класть, четвертый напоминаем им что есть еще яндекс и бинг.
Эдакая бригада плиточников-хипстеров :)
Ваш пример непонятен, т.к. непонятно что для Вас не «brown fox» и что собственно означают top 5% в топ тесте (мы не переводчики и особо не задумываясь в топ 10% попали, при этом сделав несколько ошибок).
поветухе и говорит: Слышь бабуль вот все дети как дети, а у меня гайка
вместо пупка. Что делать?
Это длинная история.
Пойдешь за тридевять земель в тридевятое царство, будешь идти тридцать
три года три дня и три месяца. Сносишь трое железных сопогов, сломаешь
трое железных посохов. Придешь туда, увидишь дуб на дубе будет ларец в
ларце будет заяц в зайце будет утка в утке будет яйцо и в яйце найдешь
то, что тебе надо.
Ну и пошел мальчик за тридевять земель в тридевятое царство, шел
тридцать три года три дня и три месяца. Сносил трое железных сапогов,
сломал трое железных посохов. Пришел туда, дуб завалил, ларец сломал
зайца убил, утку убил яйцо ломает а там гаичный ключ внутри.
Он гайку на пупке откручивает, у него жопа отваливается.
Мораль: Не ищи на жопу приключений.
Чужой код переписывать безусловно иногда можно и нужно, но идея переписывать код «не воткнувшись в его работу настолько, что бы корректно внести доработку», это чревато.
Если Вы не знаете особенностей старого кода настолько, что даже его работу не понимаете для доработок, то у Вас по определению не может быть уверенности в том, что Ваш новый код будет выполнять работу старого корректно.
Это как вообще звучит: «я не понимаю что делает старый код и почему, но мой новый код будет делать это лучше и понятнее»©?
Потому что интерфейс.
Переформулирую. Можно убрать старый код, не разбираясь в нем, и написать новый, если знать, что он получает на вход и возвращает на выходе.
Пример. У вас есть функция генерации отчета
GenerateReportByLocations, и там что-то типа такого:string sql = "DECLARE @TransportReturnOrdersID varchar(10), @ReceivingOn datetime, @sourceLocationName varchar(255), @OldsourceLocationName varchar(255), @targetLocationName varchar(255), @ItemName varchar(100), @OldItemName varchar(100), @EstimatedQuantity int, @ActualQuantity int, @Variance int, ";
sql += "@SubTotalEstimatedQuantity int, @SubTotalActualQuantity int, @SubTotalVariance int, @TotalEstimatedQuantity int, @TotalActualQuantity int, @TotalVariance int ";
...
По ТЗ, готовому отчету, и входным параметрам функции можно написать ее заново, не разбираясь в этой куче кода.
У которого есть вход, выход, и побочные эффектыИ вот их-то Вы никогда не предугадаете.
Даже если предположить что вход и выход и контекст 100% полно и корректно описаны, что бывает только в сказках.
По ТЗ, готовому отчету, и входным параметрам функции можно написать ее заново, не разбираясь в этой куче кода.Ее писать не надо, она уже есть.
А написать Вы можете только аналог, аналог будет работать аналогично. Но не так же. Например, в нем может не оказаться гаечки и жопа таки отвалится:)
Уже писал ниже, повторюсь.Уже опровергли ниже, повторяться не будем, можете прочитать там:)
Полностью переделать процедуру возвращающую данные — это вообще рутинная операция при оптимизации работыПри условии что Вы понимаете что, как, в каком контексте и почему делает эта процедура. А как мы с Вами выше уже решили — Вы этого не понимаете, потому что Вам слишком сложно разбираться с этим.
И вот их-то Вы никогда не предугадаете.
Их не надо предугадывать. Если в алгоритме нет ни одного insert или там присвоений глобальным переменным, то не важно, что там происходит локально. Если есть, можно поискать по названиям.
В любом случае их надо убирать. Если есть тесты, то проблемы нет. Запустили тесты, проверили, что и где отвалилось. Если нет, то можно основное проверить руками. В крайнем случае ошибка все равно себя проявит рано или поздно. А если не проявит, то и значит и неважно.
Не раз делал рефакторинг полным переписыванием на основе интерфейса/описания/целей. Никакой проблемы нет. А если код настолько критичный, и при этом такого качества, что его трогать нельзя, то проблема явно не со способом рефакторинга.
Ее писать не надо, она уже есть.
Есть функция, которая работает неправильно. Либо из-за ошибки, либо из-за изменившихся требований. Иначе бы никто в нее не полез.
отвалится
Ну если у вас в коде от каждого изменения что-то отваливается, значит у вас плохой код.
Их не надо предугадывать. Если в алгоритме нет ни одного insert или там присвоений глобальным переменным, то не важно, что там происходит локально. Если есть, можно поискать по названиям.
Если в алгоритме вызывается другая функция, внутри которой третья, и т.д. на десять уровней вложенности, и десятая функция при каких-то определённых условиях меняет значения глобальных переменных — то очень долго вы будете искать такой побочный эффект поиском по коду.
(Например, программисту может показаться, что у
printf нет побочных эффектов; но на самом деле она в случае ошибки изменяет errno, и раз в сто лет это может внести в код трудновыявимый баг.)то очень долго вы будете искать такой побочный эффект поиском по коду
Я и при разборе непонятного кода буду долго искать такой побочный эффект. Не лазить же на 10 уровней вложенности в каждую функцию. Так что здесь нет разницы.
Тут есть небольшая путаница. "Что делает код" имеет разное значение в зависимости от контекста. В одном случае это цель/результат — зачем он это делает. В другом средство — какие действия он делает. Если я знаю цель, но не понимаю средства, я могу просто взять другие средства — полностью переписать код. Если я не знаю цель, то просто переписать конечно не получится.
Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.
И зная, что на входе, а что нужно получить на выходе, бываетПроблема в том, что такого не бывает:)
Точнее бывает, но только если код простой, изолированный, узкоспециализированный, документированные и… (фанфары) в таком случае в нем разобраться проблемы нет.
Пример с мальчиком не убедил. Переделывать или разбираться со старым кодом, ради того, что бы «отвернуть гайку», у меня не было столько свободного времени, обычно очередь задач висела над головой.Мальчик не понимал что делает старый код (гайка) и пытался избавиться от него (отвинтить гайку) вероятно заменив на что-то свое (разумеется гениальное), что привело к потере жопы (ибо есть правило — работает, не трогай).
У Вас правда столько времени, что бы разбираться с проблемами вызванными отключением старого кода? Или с проблемами вызванными отличием старого кода от нового в каких-то нюансах?
Да не должно быть в пупке гайки. И мальчик это понимал. В его контрукции, оказалось что гайку прилепили, что бы очко не отваливалось. Это плохо. Поэтому старую конструкцию выкинуть и сделать по человечески, а не тюнинговать гайку.Должно быть или не должно быть — Вы этого знать не можете, пока не разберетесь в коде. А разбираться в нем Вы отказываетесь, потому что Вам это слишком сложно и проще написать свой, чем разбираться в чужом. В этом и проблема.
На идеологию «весь мир разрушим, а потом...» народ уже насмотрелся в масштабах куда побольше чем программинг.
Вы игнорируете одни аргументы и цепляетесь к другим. Это… скучно.1) Ошибаетесь. 2) На анекдот.ру тогда лучше сходите:)
Вы взяли за аксиому, что я переделывают код заново, потому, что не понимаю, что делает старый код.Так и есть, и Вы это лишний раз подтвердили сказав:
Это значит, что я понимаю, что должен делать код
Попробуйте все же осознать разницу между «я понимаю что должен делать код» и «я понимаю что он делает». При этом первого без второго в сложном проекте не будет никогда.
Мне больше знакома другая ситуация — 200+ компонентов в проекте, 1 баг, который надо отловить (или небольшое изменение). В этом случае, хочешь не хочешь, надо разобраться в чужом коде, понять, что откуда берется, куда передается дальше, на что влияет и почему (в случае бага) работает не так. А потом вписать свое решение таким образом, чтобы ничего не сломать. Можно, конечно, попробовать переписать с 0, но это совершенно другая задача, с совершенно другими сроками.
В норме должно быть так, что на багрепорт/фичереквест к плохо знакомому коду, нужно взять разумное время на его изучение и после изучения дать оценку насколько быстро можно исправить локальным патчем, насколько он впишется в существующую архитектуру и какова вероятность того, что у применения патча не будет глобальных последствий. Ну и оценку сколько потребует ресурсов переписывание с нуля.
Мой преподаватель по китайскому закончил лучший вуз страны по этому направлению, часто занимается синхронными переводами. Однако, когда ему нужно ехать в командировку помогать переводить по какой-то конкретной тематике (например, военным), читает словари соответствующей направленности. Потому что все тонкости держать в голове невозможно.
Но не говорит же военным уже в процессе работы: подождите, я сейчас в словарь гляну, не уверен, как правильно перевести "кучность" в военном контексте.
Есть переводчик. Когда он встречает необходимость перевода по незнакомой ему тематике, он перед этим читает словари, потом при переводе использует эти знания.
Есть программист. Когда он встречает необходимость решить ранее незнакомую ему задачу, он перед этим ищет информацию, потом во время решения задачи ее использует.
На подобных собеседованиях дают задачи, которые должны быть известны каждому программисту, в крайнем случае опишут в терминах, которые должны быть понятны каждому программисту, а смотрят как он её решает при наличии всей нужной информации по задаче, но без предоставления информации по способу решения (синтаксису языка, стандартным библиотекам и т. п.).
Хуже когда наступает этап, когда у программера всплывает необходимость разобраться в чужом коде. Потому что если нагуглить «алгоритм пузырьков» с целью его реализации еще можно, то вот увидев «алгоритм пузырьков» программер не сможет нагуглить что это и будет неделю втыкать и пытаться разобраться спрашивая на форумах.
Если алгоритм сортировки вынесен в функцию BubbleSort или даже вынесен в отдельный класс, да ещё и покрыт тестами, то код переписывать не стоит. Если же сортировка пузырьком заинлайнена (ну а что? всего 5 строчек), то такой код должен быть переписан, логично же.
У меня интересный момент был, в условиях собеседования нормально написал merge sort, а с пузырьком затупил наоборот.
Найдите 10 отличий?
Нам на многих предметах на экзамене разрешалось пользоваться учебниками.
Смысл в том, что если не понимаешь, даже с учебником не решишь.
А был класс преподавателей, которые «УБРАТЬ ВСЁ СО СТОЛА»
Ну а потом люди выходят из института и переносят их правила на внешнюю жизнь.
Эти "убрать всё со стола" обычно весьма тупые по-жизни. Ценят способность зубрить, а не мыслить. И по жизни: настолько "правильные" бывают, что убить хочется :)
Помню даже в школе было: по математике получал оценки меньше соседа, потому что задачки решал не так, как в учебнике — учителю было не важно, что я более рациональный способ применял. Не "по ГОСТу" — минус бал!
Или на английском: были девчонки, которые тексты на пересказ зазубривали. На английском никак не говорили, но вот тексты рассказывали буква в букву: что написано, то и вещали. Их классно было перебивать — пересказывать начинали с самого начала :) Но некоторые учителя это ценили.
Работаю на европейском рынке, поэтому про Россию конкретно ничего не скажу (в целом уровень знаний тех немногих, с кем работал — очень высокий).
У меня с некоторых пор есть один единственный критерий отбора кандидатов: желание работать и совершенствоваться. Да, я предпочитаю, чтобы человек писал код в Visual Studio. Но если он этот же код пишет быстрее в блокноте — не вопрос. Если человек способен мыслить самостоятельно, то не важно откуда он будет черпать свои знания для роста: курсы, книги, гугл, стэк оувэрфлоу, что угодно.
Такие вещи, как дипломы, сертификаты, корочки — вообще не котируются, т. к. зачастую владельцы оных представляют из себя ходячие энциклопедии без признаков разума. То есть если пример поставленной задачи имеется в их "энциклопедиях" — они это сделают. Если же задача отличается от примера на 5-10%, то решить не могут.
Простым языком: такие люди щеголяют своими знаниями о том, что помидор — ягода. Основываясь на этих знаниях, и опуская стадию мышления, кладут помидор во фруктовый салат.
Сам за последний год получил много корочек, чтобы щеголять перед клиентами, но по моему скромному мнению наличие корочек и наличие знаний не коррелируют.
Что касается "подглядываний" в гугл среди профессионалов: все этим занимаются, никто об этом не говорит :) И я с подозрением отношусь к людям, которые утверждают, что способны удержать в своей голове мануалы по всем используемым технологиям, да еще и в разных версиях. Правда я таких встречал только в историях про "друга моего друга".
Это общие наблюдения. Конечно же бывают исключения из правил.
Первые две недели даю человеку самые разношерстные задачи. Но маленькие, чтобы не потратил все две недели на одну. При чём достаточно типовые, т. е. те, на которые решения у нас уже существуют. Но не такие, чтобы найти решение погуглив.
Например для dev-DBA типовым может быть: пара таблиц + автоматизированные таблицы истории + ограничения через constrasints и триггеры + удобные SP/UF + документация для разработчиков. Важный момент: дать как можно больше разного, чтобы не всплыло через полгода, что человек про индексы не слышал :)
И дальше смотрю, как человек работает. Если, например, везде суёт циклы из курсоров, от недостатка знаний, немножко намекаю как можно улучшить. Дальше самое интересное: ленивые делают ровно столько, сколько я сказал, и ровно так, как я сказал (а я же заведомо не говорю идеальное решение). Не ленивые же откапывают, и делают гораздо больше. Так же я обязательно требую пояснить, почему сделано так, или иначе: это сразу "светит" тупо списавших, остальные же расширяют свой и мой кругозор в процессе беседы.
Метод, возможно, и затратный, но очень эффективный. В последствие на, таким образом отобранных ребят, можно положиться.
А по поводу алгоритмов… Опять таки, тенденция сводится к тому, что фреймворки и библиотеки все больше выступают не в роли вспомогательного инструмента, а в роли абстракций над языком. И получается так, что одна группа людей пишет библиотеки, улучшает их, делает их более эргономичными, увеличивает скорость отклика, и совершенно другая группа людей на их основе строит приложения. И, по все правилам, если абстракция хороша, то конечному пользователю фреймворка должно быть глубоко наплевать на то, какими средствами он там внутри устроен.
Ну, то есть, именно к этому же стремятся люди, когда пишут библиотеки и фреймворки — перестать раз за разом реализовывать одни и те же алгоритмы и паттерны. Чтобы ты кнопочку нажал и, «вжух!», магия произошла. Снижение затрат на обучение, снижение затрат на реализацию. В этом как бы весь смысл, чтобы можно было нанять человека, который не знает алгоритмов и ООП, который бы смог приносить прибыль компании.
То есть, с точки зрения компании, даже лучше, если человек заточен под какой-то один инструмент. Его чек от этого можно смело сокращать.
Правда, я хоть и понимаю все это, но все же хочу знать Computer Science как можно лучше, просто потому, что это определенно дает преимущество. В конечном счете, это просто увеличивает сумму чека и позволяет браться за те задачи, которые представляют интерес.
Прочитал все, и захотелось ещё немного уточнить один важный вопрос.
На собеседованиях одни люди оценивают других людей. И там, и там не машины, которые могут успешно или нет пройти/зачесть определённый тест. Есть известный уровень допуска, когда оценивается не только формализованная сторона вопроса, но и берутся во внимание более абстрактные детали: как именно кандидат решает задачу, какой у него ход мыслей и так далее. Это понятно. Поэтому ни я, ни, думаю, DHH не имеем ввиду крайность вида «всё нагуглю, если надо». Очевидно, если кандидат, допустим, на позицию JS middle не умеет работать с массивом или не знает, что такое замыкание, ему нечего делать на запрашиваемой позиции.
Однако данный топик может навести на мысли про более общий вопрос: как далеко зашёл т.н. «вынос мозга» — делегирование некоторых функций собственного мозга машинам. Кто как, а я могу сказать за себя: дело в том, что со школы у меня что-то вроде «врождённой грамотности» — я с неохотой учил правила русского языка, но достаточно редко ошибался в написании. А вот с приходом интернета появилась странная привычка: часто хочется проверить, не ошибаешься ли ты в написании даже известных, часто употребимых слов. Лёгкость проверки как бы провоцирует подсмотреть, удостовериться. Таким образом вырабатывается нехорошие привычки, которые, наверное, до известной степени нас всех расхолаживают.
Или высвобождают ресурсы на более полезные/интересные/приятные занятия. :)
Другими словами, ввиду требований бизнеса, с одной стороны, и огромного количества инструментов, с другой, средний программист часто вынужден скакать по верхам.
Конечно же пример с сортировкой пузырьком надуманный, его нормальный программист напишет и на бумаге. А вот алгоритм в 20-30 строк на бумаге написать уже сложно. Надо будет переписывать на новый листок чтобы вставить новые строки. И возникает вопрос, как определить правильность сложного алгоритма написанного на листочке на псевдокоде, если кандидатов несколько, они решили задачу, то какого выбрать?
Ведь подготовка к собеседованию с написанием алгоритмов на листочках может занять несколько месяцев, а в реальной работе это окажется почти бесполезно потраченное время.
В адекватных местах дают писать код не на доске/бумажке, а на ноутбуке в текстовом редакторе (не IDE). Автодополнения и подсветки нет, но можно вставлять строчки и копипастить. При этом абсолютной компилябильности кода тоже никто не просит.
Потому что у всех своя любимая IDE и ее настройки. Всем не угодишь, и это создает нечестные приемущества.
Второе, в случае с IDE логично будет требовать компилирования кода, и тут возможно много проблем. К коду "на доске" требования гораздо меньше — это экономит кучу времени и нервов на интревью. Если бы мне дали выбирать — пиши в IDE и компиль или пиши в блокноте, я бы выбрал блокнот.
Тестовое задание где надо именно написать полностью рабочую программу — это другой формат интервью, который требует на порядок больше времени. Мало задач можно успеть написать и оттестировать за 45 минут да еще и обсудить детали с интервьювером.
Почему не акварель, почему карандаш? Хороший программист должен уметь итак и эдак…
Если берёшь человека на прикладное программирование, необязательно требовать с него детали алгоритмов, но надо чтобы он понимал общий смысл. Но при этом не сортировку пузырьком, а ту сортировку, которая используется в его языке программирования. Скажем, если речь о Java, программист обязан знать, что в Arrays.sort() используется TimSort, который похож на mergesort, только прокачанный, он гарантирует стабильность, может жрать дополнительную память, супербыстр, когда массив уже упорядочен в прямом или обратном порядке (тогда требуется n-1 сравнение) и весьма быстр, если массив почти упорядочен. Если человек не знает этого, это дурной знак. Он напишет нагрузочный тест с упорядоченными данными, а в продакшне окажется, что они случайные и сортировка займёт на порядок дольше.
Или, например, TreeMap. Надо знать, что внутри сбалансированное двоичное дерево, которое поддерживается в состоянии, когда его глубина пропорциональна логарифму от числа элементов, значения в левой ветке меньше текущего узла, а в правой больше. Гарантия глубины достигается наличием некоторого инварианта (если кандидат не знает, что такое инвариант, то лесом его), который восстанавливается при вставке и удалении элемента за логарифмическое время. Всё. Можно попросить написать в псевдокоде поиск (это тривиально из вышесказанного), но требовать реализовать вставку на доске неразумно. Также простительно, если кандидат не знает что там конкретно, RB или AVL, например.
- Да много.
- IntelliJ IDEA.
Ага, попались! Не удержусь от оффтопа! :)
Делитесь инсайдом — что там с IDEA-63201? Легендарный тикет уже, 7 лет ждем!
Если к вам идут люди писать IDE для java (причем лучший IDE для java)
так конечно они должны знать как написать реализацию TreeMap, в этом их работа будет — на уровне java api и ниже.
Холивар о том нужно ли серверному разработчику уметь писать сортировку в уме
Зависит от того, над каким проектом ему работать. Я, скажем, знаю внутреннюю реализацию структур данных в PHP, но мне никогда в голову не придет задавать такой вопрос (разве что кандидат будет уж очень хорош, и захочется порыть совсем глубоко). На практике достаточно знать временную сложность и сложность по памяти, а что там внутри, несущественно.
Скажем, если речь о Java, программист обязан знать, что в Arrays.sort() используется TimSort
При условии, что сортируются объекты, а не инты, например. Да и нет никакой гарантии, что алгоритм не поменяется в будущем.
В подавляющем числа случаев имеет значение только один факт: асимтотика O (N log N). Всё остальное важно только при написании приложений на Java для высокопроизводительных вычислений, что само по себе уже звучит странно.
Или, например, TreeMap.
Здесь надо знать, что добавление и удаление элементов имеет асимптотику O(log N), и что используется двоичное дерево — из этого следует, например, рандомный доступ к памяти. Всё остальное не имеет значения. RB, AVL — приходилось ли хоть раз их самостоятельно реализовывать и использовать в проектах?
При условии, что сортируются объекты, а не инты, например.
Да, про это надо знать, естественно.
Да и нет никакой гарантии, что алгоритм не поменяется в будущем.
Да, если алгоритм поменяется, надо быть в курсе. Следить за новостями в своей отрасли — отличительная черта хорошего специалиста.
RB, AVL — приходилось ли хоть раз их самостоятельно реализовывать и использовать в проектах?
Вы невнимательно читали моё сообщение. Я разве сказал, что надо уметь их реализовывать?
Подобные вопросы — они рассчитаны на джуниоров, на выпускников универа, которые это относительно недавно изучали и еще должны что-то помнить. Задавать им более глубокие вопросы, на которые они все равно не смогут ответить, поскольку ответ требует опыта, которого у них заведомо нет, бессмысленно. Миддлам и сеньорам обычно задают совсем другие вопросы. Когда такие вопросы задают миддлам-сеньорам, то вряд ли ожидают написания на доске синтаксически корректного безошибочного кода — скорее ждут быстрого объяснения алгоритма, так как бы объяснял его коллеге. А если забыл и не получается быстро вспомнить — вести себя так, как бы вместе с коллегой вспоминал (или переизобретал) этот алгоритм, пользуясь доской для пояснения хода мыслей. Если где-то от сеньоров ждут ответа как от джуниора, что сказать, это глупо.
Ждать синтаксически корректного кода на доске (не от джуниора) — тоже величайшая глупость, конечно. Да и требовать высматривать глазами ошибки типа off-by-one — тоже не особо умно: если человек ищет ошибки пристальным взглядом вместо того, чтобы написать тест и воспользоваться отладчиком, он явно непродуктивен. Я бы гораздо больше оценил, если бы рядом с псевдокодом алгоритма был псевдокод юнит-теста.
И еще один момент.
Собеседование — это не экзамен в институте. Собеседование — это переговоры двух сторон, цель которых — установить, подходят они друг другу или нет.
К сожалению, часто проводится именно экзамен. Это во многом из-за того, что мы тут гики и нерды, и не умеем вести переговоры — ни собеседуемый, ни собеседующий. Много где такое устоялось, но я уверен, что бизнесу это только вредит.
Это не относится к собеседованиям, там однозначно подготавливаться придется, то есть прокачать базу надо, а потом можно снова забыть))
P.S. Разработчик в моём понимании — программиста с базовыми знаниями, обучаемый и умеющий находить решения или изобретать велосипеды, если на то появляется потребность. Кодер для меня — это человек который изучил язык и знает как на нём писать, но при этом не обладает хорошими знаниями в своей области и слаб на принятие правильного решения или нахождение этого самого решения, и при обучении новой области у него возникнут проблемы, которые повлекут за собой его увольнение, а компанию на поиск нового сотрудника.
Если бы у меня на собеседовании на позицию senior спросили, что такое рекурсия, я бы сразу уточнил, не ошибся ли я дверью. :) Все перечисленное должен знать даже джуниор с претензиями на миддла.
Другое дело, что бывают места, где senior-ами считают тех, кто в других местах и на джуниора не потянет.
А вот ваше капс и общий тон комментария — повод задуматься о том, стоит ли вообще устраиваться к вам.
По-разному понять можно. По резюме, по ссылке на гитхаб. Если на более серьезные вопросы человек ответить не может — тогда, конечно, можно и к таким вопросам перейти, сказать, что на сеньора не тянет и предложить миддла.
Не удивлюсь, если нормальный senior ваше собеседование пройдет, но работать у вас не захочет.
А что к вам такие приходят — так может денег мало предлагаете? ;)
Про гитхаб — считаю, что если кандидат прислал ссылку на свой код, демонстрирующий определенный достаточно высокий уровень, то спрашивать его про факториал циклом-рекурсией — это сразу обидеть человека ни за что. (Если не прислал — это, конечно, ни в коем случае не минус.)
Если утрируете — то понятно, сразу бы так и сказали. :)
Так что я лучше пару вопросов по базовым вещам задам, а то может «До свидание!» — чего время терять.
Если к собеседованию надо готовиться, то это уже получается экзамен, а не проверка реальных знаний. Потому что подготовился — ответил на все вопросы — через неделю забыл, потому что на практике не нужно.
К любой встрече надо готовиться.
Ну да, зарядить телефон, ноутбук, проверить, взят ли с собой паспорт, найти адрес на карте, посмотреть пробки.
Что такое реальные знания?
Знания, которые постоянно используются на практике.
Обидно же если знаешь, по подзабыл.
В этом-то и прикол экзаменов: легко сдать практически любой экзамен на пять, просто потратив три дня на подготовку. Но сдача экзамена не означает способность применения знаний на практике.
Поэтому я не понимаю интервьюверов, которые пытаются проверить академические знания. Может быть, для студентов без опыта работы это единственный вариант их хоть как-то оценить, но для программиста со стажем такая проверка будет непоказательна.
В этом-то и прикол экзаменов: легко сдать практически любой экзамен на пять, просто потратив три дня на подготовку.
Не согласен. Будучи в свое время разработчиком Java считал, что я ее хорошо знаю. Готовясь к сертификации понял, что знаю ее плохо. Сдав экзамен понял, что теперь знаю хорошо.
Поверьте, программист со стажем затратит на элементарные вопросы 5-10 минут, далее мы покапаем поглубже.
Ага, есть люди, которые специально ходят по собеседованиям не с целью устроиться на работу, а с целью понять, какие знания сейчас востребованы.
Сдав экзамен понял, что теперь знаю хорошо.
И не забыли через неделю-месяц эти знания за ненадобностью? Везёт!
Я, например, абсолютно уверен в том, что не знаю всех нюансов C++, что не мешает мне на нём программировать. Просто невозможно знать всё.
Поверьте, программист со стажем затратит на элементарные вопросы 5-10 минут, далее мы покапаем поглубже.
Это как в анекдоте: "Вам шашечки или ехать?"
Сколько программирую — не помню. На C++ я пишу не очень много — только низкоуровневый код для обработки изображений, для высокоуровневых же вещей предпочитаю что-нибудь поудобнее. Поэтому ничего, кроме STL, не использую.
Но я в курсе новых стандартов, постоянно слежу за ними и активно использую новые возможности. Но постоянно вылезает что-то интересное: достаточно посмотреть высокорейтинговые вопросы на SO (ссылка), чтобы понять, насколько язык сложен и сколько в нём ещё секретов.
Но знание этих секретов в основной массе только удовлетворяет моё любопытство, потому что в продакшне спорные моменты недопустимы.
Реализовать в коде какой-то алгоритм — повседневная задача для программиста любого уровня. Придумать алгоритм и реализовать его — повседневная задача для программистов среднего и высокого уровня.
Адекватный работодатель не откажет вам, если вы не понимаете задачу "вычислить факториал рекурсией", сообщит формулу (читай — алгоритм вычисления) факториала и определение рекурсии, а потом будет смотреть как вы реализуете уже известный вам алгоритм. Если вы рекурсивные функции постоянно используете, просто не знаете, что они так называются, то справитесь. Если вас концепция, что функция может вызывать саму себя, вводит в ступор, то вряд ли вы подходит даже на джуна.
У одного кандидата я однажды спросил, чем отличается интерфейс от абстрактного класса. И он обиделся! И я рад, что он у нас не работает. Потому, что
- если ты работаешь в индустрии и любишь свое дело, то почему пусть даже детские вопросы тебя обижают? я бы ожидал здесь другую эмоцию, но никак не обиду
- почему ты думаешь, что интервьюер изначально знает, насколько ты крут? Знал бы заранее — интервью было бы не нужно.
- почему ты думаешь, что целью вопроса было узнать твои энциклопедические знания? Вопрос мог касаться твоего умения внятно излагать свои мысли.
- или ты заранее ожидаешь пакости от собеседующего? тут уже вопрос адекватности имхо
Вы (гипотетический вы) не пошли работать «холопом» (а на самом деле не подошли в качестве винтика механизму по зарабатыванию денег), а контора не стала трудоустраивать человека, который ей не подошел (не взять человека на работу всегда дешевле, чем его уволить впоследствии).
Все счастливы и цель коммуникации достигнута.
Кстати, время (читай деньги) компании вы тоже потратили.
Приходит программист на собеседование, а у него чего там только не написано. И то знает, и это, и там участвовал, и здесь проектировал. Интервьюер сходу говорит «Вы нам подходите! Мы вам даем 10 млн годового дохода в долларах. Пожалуйста, покупайте только Феррари, т.к. на Бугати у нас ездит только Генеральный. Не пользуйтесь, пожалуйста, корпоративным самолетом чаще 2-х раз в неделю для посещения вашей виллы в Испании, которая надеемся будет достаточно скромна, не более 10 млн. долларов»
Кандидат кричит: «Да Вы гоните!». Интервьюер спокойно: «Вы первый начали. Оставьте в резюме только то, что действительно знаете».
Хороших спецов я нанял очень много, работая в разных компаниях. Построил не один отдел с нуля. Кол-во реализованных проектов — огромно. От предыдущих работодателей слышу только хорошие отзывы на бывших своих коллег. Со всеми, которые прошли испытательный срок до сих пор прекрасные отношения.
Резюме — лишь первый уровень отсеивания неподходящих кандидатов и обычно с достаточным уровнем объективности проверить можно лишь малую часть, указанной в нём информации..
Есть одна общая проблема. Сейчас зачастую программист мыслит квадратиками, не понимая как этот квадратик устроен. Для ряда задач — так и надо делать — дешево и сердито. И таких спецов большинство. Ребята и девчата, которые имеют писать квадратики, знают внутренности других квадратиков и понимают где можно соединить квадратики беспроблемно, а где придется таки писать серьезный код — вот этих кандидатов стало меньше.
Тех усилий, которые прилагают большинство программистов, хватает этим программистам на хлеб с маслом.Может и яснее, но это своершенно другое утверждение по сравнению с:
Так яснее?
И работает принцип Парето. 20% усилий дают 80% результата.Кроме сомнительного использорвания принципов, у вас еще есть плохая привычка говорить за других (большинству хватает, где вы взяли эту информацию?) и использорвать взятые из воздуха числа (100-1000, сотни тысяч, откуда это?). И про спрос на серьезных кандидатов попадает в эту же кучу, большие компании практически не переставя ищут кандидатов, и не каких папало.
Они приложили свои 20% усилий и получили 80% своего результата. Принцип Парето для них срабатывает.
Да с чего вы это взяли?
Вот специально для вас сходил на hh.ru
Распределение по з.п. С++
до 55 000 руб — 177
от 55 000 до 105 000 — 102
от 150 000 до 200 — 69
от 200 000 — 29
Итого всего 377 вакансий? Вам не кажется это число маленьким, чтобы делать на его основании какие-то выводы?
Сколько вакансий высококлассных спецов в больших компаниях?Вы, очевидно, не поняли мое утверждение, мое утвержджение — большие компании набирают специалистов (и не только классных) постоянно, не только когда у них открыласаь какая-то вакансия для классного спеца. Потому что классному специалисту (и это чуть более высокий уровень, чем умеет реализовать сортировку пузырьком — не великое достижение) работа в большой компании найдется. При условии, что он знаком с базовыми вещами и умеет свои мысли превращать в алгоритмы, а алгоритмы в код.
Все? Или таки меньшее количество?
А ЗП в районе 100 000, это весьма неплохая ЗП.Если вы живете в Питере -> Красноярске -> Хабаровске, то может быть. А если вы живете в Дублине, то очень сомневаюсь.
И ее вполне может хватать для того, что бы дальше не напрягаться.
Ну как вариант.
Не нравится, предложите свой.
Мне в первую очередь не нравится аргументация вашей своей позиции, на что я и пытаюсь обратить ваше внимание.
Вы абстрагироваться от конкретных чисел умеете?Я то умею, а вы? Напомню вам, что это вы назвали конкретное число взятое опять же из воздуха лишь бы было какое-нибудь.
Дайте свой вариант, почему «хороших» программистов не так много, как бы хотелось, с вашей отличной аргументацией.Я вам ничего давать не буду, как я уже сказал, я показываю вам слабость вашей аргументации, а вы пока только в штыки все воспринимаете.
Я указал вам на факт, что спрос на специалистов есть (не каких попало и не только крутых, а самых нормальных — разбирающихся в основах) как минимум в больших компаниях, откуда он берется, учитывая, что каждый год куча вузов выпускает кучу «программистов» по всему миру, для меня загадка. Но факт есть факт — специалистов не хватает.
Что если ты делаешь ThreadPool из 10 потоков и видишь, что очередь растет, то надо подумать об увеличении кол-ва потоков.
А на утечку памяти можно предложить поставить побольше памяти в сервер, да перегружать сервис по расписанию.
Надо знать:
- сколько у нас доступных потоков в системе;
- что делают задачи: потребляют ли много CPU или постоянно находятся в режиме ожидания;
- насколько критична скорость выполнения задач: иногда лучше, чтобы задача помариновалась в очереди, но выполнилась быстро;
- насколько задачи независимы: есть ли блокировки, которые могут значительно замедлить выполнение большого количества задач.
Если ты делаешь постоянные вставки в середину списка, то ArrayList не лучшее решение и т.д.
Не факт, что асимптотически лучшие алгоритмы будут быстрее, если длина массива небольшая.
Ну так это потому что уровней абстракции становится все больше и больше, и требуется все более глубокое погружение, чтобы добраться до сути.
Тем не менее, фундаментальные знания все те же, и людей, ими владеющих, меньше, мне кажется, не стало. Другое дело, что стало больше укладывателей квадратиков — но это только потому, что для многих задач и этого достаточно.
Знаете, по итогам этой ветки у меня создалось ощущение, что вот этот комментарий я написал в том числе и для вас.
Буду рад, если ошибаюсь. :)
Мой поинт как раз в том, что ошибка у вас.
Да, один спрашивает, а другой отвечает. Но уже и на этом этапе кандидат делает свои выводы. По тому, какие вопросы задают — выводы о том, какие знания потребуются и какого рода задачи надо будет решать. Если я претендую на вакансию senior, а вопросы задали джуниорские и на этом закончили, то мне, скорее всего, будет неинтересно. Если видно, что мое резюме не читали и присланные примеры кода не смотрели, наверняка работа примитивная и в компании большая текучка. Если проводят стрессовое собеседование, наверняка в компании неприятная атмосфера.
Так что переговоры, пусть и неявные, уже тут начинаются.
Если кандидату задали джуниорские задачи и на этом закончили, то значит он даже с ними не справился.
Далеко не факт. Возможно просто в компании нет никого, кто мог бы задать неджуниорские вопросы.
Я так работу предыдущую получил. Потом выяснилось, что итогом собеседования было: "Я почти ничего не понял, но мужик явно больше меня шарит".
К слову, мы его сделали и заказчик остался доволен :)
Переписать на рекурсию лучше попросить вычисление чисел Фибоначчи. Тут-то и выяснится понимание сложности алгоритмов (особенно — бесполезной сложности). Не отказался — звоночек. Обиделся — ушёл. Объяснил культурно, почему это неправильно — плюс в карму. Да, это провокация, но она даёт ответы и на профессиональные, и на поведенческие вопросы.
Реальная разработка не имеет ничего общего с решением глупых задачек на листочках и уж наверняка никто из синьоров не практикуется в такой ерунде, потому чтобы пройти такие интервью им надо готовиться, как к экзаменам в институте. Но мало кто будет. Очень наивно думать, что вы хороших людей отбираете, в лучшем случае случайных среднестатистических, а то и вообще хуже среднего, но хорошо умеющих проходить интервью.
Но я так понимаю, что вам все равно, это какой-нибудь аутсорс или крупная компания, где и так все подряд сойдут.
Но не с ходу, в незнакомой обстановке, под присмотром чужих людей, со стрессом, с кучей предубеждений в свою сторону по поводу внешнего вида, манеры общения и т.д.
Ну а зачем тогда вообще ходить на собеседования, если это такая сложная штука, незнакомая обстановка, чужие люди и предубеждения, что отшибает напрочь способность решить детскую задачку? А что он будет делать, если у него в реальной работе вдруг случится дедлайн, или у крупного клиента выскочит крупный и срочный баг? Я понимаю, что бывают гениальные парни, которым прощаешь все их чудачества, но с другой стороны, в мире полно хороших инженеров без подобных психологических проблем.
Моё ИМХО — нет ничего страшного, если вы нечаянно отсеете специалиста, который по каким-то особенностям мышления не смог решить простую задачку на собеседовании. Это куда лучше, чем если вы нечаянно возьмете на работу специалиста, который эти простые задачки в реальной жизни нормально решать не умеет.
А что он будет делать, если у него в реальной работе вдруг случится дедлайн, или у крупного клиента выскочит крупный и срочный баг?
Сядет спокойно и будет делать, это же совсем другая ситуация. Или чужие люди тоже будут ходить наблюдать за ним и оценивать дальнейшую его судьбу каждый раз? Тогда такую работу никто не выдержит.
На самом деле нет никаких «психологических проблем», те же экзамены без подготовки никто не сдает. Интервьюверы просто сами не понимают, что делают.
нет ничего страшного, если вы нечаянно отсеете специалиста
А если нечаянно не отсеете не специалиста? Сейчас же есть даже курсы всякие для подготовки к таким глупым интервью, кто угодно может пролезть.
Сядет спокойно и будет делать, это же совсем другая ситуация
Не такая уж и другая. Это стресс, это письма от тимлида, звонки от менеджера и т.д.
На самом деле нет никаких «психологических проблем», те же экзамены без подготовки никто не сдает. Интервьюверы просто сами не понимают, что делают.
Ну так и участников собеседования тоже ведь не по результатам анонимного голосования выбирают. Если человек явился на собеседование, то очевидно же, что он до этого общался с эйчаром, где-то публиковал своё резюме, как-то заинтересован в этой вакансии и имеет (или хотя бы считает, что имеет) соответствующую квалификацию. Наоборот, это на экзамены многие «приплывают по течению», потому что раз попал в ВУЗ, хоть добровольно, хоть потому что папа с мамой отправили, от них уже не денешься. А собеседование, это как раз сознательный шаг взрослого человека.
И если для этого взрослого человека оказывается неожиданностью и неразрешимой проблемой то, что на этом собеседовании вдруг оказались чужие незнакомые люди, да ещё и спрашивают чего-то, то я даже и не знаю, как к нему относиться. По-моему, работать в команде ему в любом случае противопоказано. Благо, любой, самый нездоровый интраверт, сейчас вполне сможет найти удаленную работу практически без необходимости общаться с живыми человеками.
А если нечаянно не отсеете не специалиста? Сейчас же есть даже курсы всякие для подготовки к таким глупым интервью, кто угодно может пролезть.
А к каким именно «глупым интервью»? Напомню, мы говорили про интервью, где задают вопросы, непосредственно касающиеся профессиональной компетенции. У сеньора в круг его обязанностей разработка софта также входит, и ему тоже надо уметь программировать.
непосредственно касающиеся профессиональной компетенции
Нет, извините, такие вопросы не касаются профессиональной компетенции. Это все не пересекается с реальной разработкой.
Когда-нибудь поймете или нет, не знаю, знаю что некоторые жалеют со временем, что такими глупостями занимались. Но обсуждать тут это похоже бесполезно, да и все равно у абсолютного большинства этот процесс не излечим, особенно у аутсорса и крупных компаний. Там всегда практически кто попало будет набирать людей абы как, без малейшего понятия. Что и хорошо, так они талантливым командам конкуренции составлять никогда и не будут.
Реальная разработка в разы сложнее чем прохождение интервью. Именно поэтому у меня нет четкого алгоритма проведения интервью. С каждым кандидатом все с чистого листа. Вариант с хорошо проходящими интервью у меня не проходит.
Поскольку я нанимаю для себя, то мне как раз не все равно. Потому и заморачиваюсь.
На красные носки и зеленые кроссовки мне наплевать.
Редко требует менее 1-4 часов, как на собеседовании.
И уж тем более эти навыки никак не коррелируют с хорошим уровнем программирования.
Я уже говорил. Мне нужен не только хороший программист, но и член команды.
И даже если Вам это не важно, собеседник этого не знает.
Именно поэтому надо приходить в нейтральной одежде. Знаете есть такое понятие casual. Можно в smart casual. Кстати, металлист в футболке с любимой группой ко мне приходил. Нанял — работает.
Стюардесса после тряски говорит: «Ну что вы так разволновались? Это обычная турбулентность. Спокойно. Успокаиваемся. Все? Нормально? Капитан? Первый пилот? Молодцы. Пойду успокою пассажиров.»
Так вот я никого по головке гладить не буду. Детский сад на прогулке закончился. Взрослая жизнь трудна и сурова.
— Вот я и говорю, — подавленно говорил он слегка заплетающимся языком. — Применение всех этих стандартных библиотек скотинит и развращает программиста. Низводит его до состояния быдла. Животного. Собаки Павлова. Загорелась зеленая лампочка — вызывай эту функцию. Загорелась синяя — другую. А почему?! П-почему лампочки загораются?!
Последнюю фразу Ксенобайт произнес с тоскливым надрывом. Гордо выпрямившись, ударил себя кулаком в грудь, потом снова сник.
— Н-никто не помнит. Никто не помнит, откуда там эти лампочки и почему горят. Ты меня понимаешь? Понимаешь, что я чувствую, когда смотрю на эти лампочки?
Мужик мрачно кивнул, выдав что-то вроде «угу» и сдвинул с Ксенобайтом стаканы.
Призрак. «Бета-тестеры»
Каждый раз смотрю и удивляюсь — как же люди в споре суть его упускают. И ведь даже озвучивают порой ключевые разногласия, но спор не прекращают. Спор ради спора.
А ведь как всё просто (и было сказано уже не раз): программисты разные нужны, программисты разные важны. :)
Просто слово на всех одно.
Так почему же спорщики так уверенно трактуют в универсальный вариант «правильного программиста» частное суждение «мне нужны вот такие» или «я считаю правильными именно вот этих». Но ведь не бывает универсальных программистов.
Не проще ли уж начать дополнять термин? Типа «нужен хороший программист на фабрику данных», или «спец по моделированию физических процессов», или «умеющий в одно лицо создать систему поддержки бизнеспроцесса», или даже «мастер скоростного кодирования по готовому ТЗ». Тогда сразу будет понятно, почему один должен алгоритмами дышать, а второму они до лампочки :)
Пара моих личных примеров.
Я сам «матёрый» программист, начинал ещё в 90-х, и всю жизнь имею дело с реальным бизнесом. Именно поэтому любая задачка для меня начинается с user stories & use cases. Потом добавляем потенциал развития и жизненный цикл программы/системы. Потом уже можно подумать о том, как и что писать. И вот как-то до явной реализации алгоритмов я доходил пару-тройку раз, не более. Да, в институте писал алгоритмы, и помню некие общие подходы… Главное, что в жизни пригождается — понимание вычислительной сложности. Ибо без него можно на ровном месте систему в down уложить. Чаще, конечно, за этим следить надо в области sql.
Зато понимание общих концепций, паттернов и т.п. — это то, что спрашиваю у senior-ов. (Весьма забавно получить ответ про паттерны от tech lead/architect в духе «да пофиг что использовать, ибо decorator, wrapper, adapter и façade суть одно и то же»). И да, про паттерны я спрашиваю только про те, которые собеседуемый сам заявляет как понятные и используемые.
С другой стороны, сам, проходя собеседования, если натыкался на кучу вопросов по алгоритмам, честно говорил «ребята, вам нужен не я. Вот систему запроектировать — это ко мне, а алгоритмы… потребуются — найду. А помнить без нужды — нафиг надо»…
По первой части приведу простой пример плохого кода, вызванного тем, что человек не понимает структуру хранения данных. Надо провести итерацию по парам key-value в HashMap. Делаем цикл по ключам и достаем внутри цикла значение get-ом. Дурное абсолютно решение и все равно так пишут.
Другой пример — надо осуществить поиск в неупорядоченном массиве. Можно написать в две строчки — sort и binarySearch, а можно подумать правильно ли это. А еще можно подумать если надо осуществлять поиск, то может надо как-то перепроектировать, чтобы поиск делать по чему-то более быстрому.
И вы хотите сказать, что тут не нужно знание в базовых алгоритмах?
По первой части приведу простой пример плохого кода, вызванного тем, что человек не понимает структуру хранения данных. Надо провести итерацию по парам key-value в HashMap. Делаем цикл по ключам и достаем внутри цикла значение get-ом. Дурное абсолютно решение и все равно так пишут.
Кстати, в JavaScript только так и можно делать.
Тут нужно. А чтобы правильно выделить бизнес-сущности, правильно спроектировать работу бизнес-процессов с этими сущностями, правильно организовать хранение в постоянном хранилище и загрузку их оттуда, и запрограммировать все это с использованием всяких SOLID, не нужно.
А если вы скажете, что мол в БД тоже всякие хитрые алгоритмы, то это не важно, потому что я все равно не могу их поменять. Для их использования достаточно описания в документации или пояснений на хабре/SO, которые можно найти как раз через гугл.
Ну может где-то аналитики и архитекторы составляют подробное задание для программеров типа сделать вот такие сущности, вот так хранить их в БД, вот такое наследование/композицию сделать, вот так сделать инъекцию зависимостей, а программисты потом по списку просто кодируют. Но я такого не встречал.
Зато встречал необходимость правильной организации кода и правильного использования имеющихся инструментов. И какой-нибудь binarySearch это один из винтиков на уровне конкретной реализации. Для каких-то задач программирования своя реализация таких алгоритмов нужна, для каких-то нет.
Говоря про ваши примеры, у меня первый вопрос в голове — а зачем это нужно? какие данные на входе, что нужно на выходе? в каком case это будет использоваться? Ведь даже тот же неупорядоченный массив… Мне чаще встречаются задачи вида «выбрать из
И уж совсем отдельный вопрос, что же такое «базовые алгоритмы»? :)
Знание каких базовых алгоритмов помогло бы в 2000-м превратить обычный asp-сайт в веб-ферму?
приведу простой пример плохого кода, вызванного тем, что человек не понимает структуру хранения данных
Каким образом знание структуры хранения в конкретной реализации HashMap для конкретной JDK поможет не писать дурной код? Или что, если заменить HashMap на TreeMap, вышеописанный подход станет верным? Банальное отсутствие опыта и вкуса, проверяется за 10 минут просьбой поревьюить кусочек плохого кода.
а можно подумать правильно ли это
Так если вам нужны люди, умеющие думать, зачем у них спрашивать заученные строчки из википедии? Может, попросить у них подумать «на камеру» вместо этого?
Так некоторые не утруждают себя даже тем, чтобы заучить «строчки из википедии». :-) А подумать «на камеру» у всех будет шанс. У меня заковыристых задач в голове достаточно.
А давайте, может, раз уж мы все тут такие эксперты по внутренностям JDK собрались, вспомним про реализацию EnumMap? Может, если мы используем EnumMap, тыкаться каждый раз get'ом в цикле будет нормальной идеей? Мы ведь ЗНАЕМ ее внутренности и как они работают, почему бы и не завязаться на это, да?
А вот почему быстрее — вы сможете узнать, когда, например, хотя бы один раз заглянете в исходный код этих мапов, т.е. изучив структуру хранения
А можно я изучу исходный код JIT и, возможно, узнаю, что он сможет развернуть одно выражение в другое без потери производительности? Что, получается, как в «Камень-Ножницы-Бумага», знание JIT бьет чтение исходников HashMap? Тогда, получается, вам нужно переставать спрашивать внутренности коллекций и просить цитировать исходники компилятора? Или, может, все-таки задуматься над прекращением попыток сопоставить кругозор кандидатов с собственным, игнорируя все за пределами их пересечения?
А «строки из википедии» я тоже не заучиваю. Время — слишком ценный ресурс, чтобы тратить его на удовлетворение самолюбия местечковых Software Development-царьков.
есть и другие JDK, свободные и весело-вендорские, со своими реализациями, ошибками и заморочками
Есть, но только в промышленности они не используются. Пришлите мне реализацию HashMap, кардинально отличающуся от Сана-оракловой?
Может, если мы используем EnumMap, тыкаться каждый раз get'ом в цикле будет нормальной идеей?
Да ладно? ;-) Т.е. доступ по ref (итерация по keySet) + доступ по idx (массив) лучше чем просто доступ по ref (итерация по entrySet)?
наличие вкуса и умение читать документацию важнее заучивания наизусть кишок оракловой реализации
Эх! Почитали бы исходный код, тогда бы увидели, что HashMap и EnumMap на одном абстрактном классе построены. А если бы посмотрели как реализован ConcurrentHashMap поняли бы, что такую высококлассную реализацию мог сделать только человек, реально знающий «кишки» виртуальной машины в части синхронизации.
А можно я изучу исходный код JIT
Нужно. Это уже высший класс. И если мне на собеседовании вы расскажете, что JIT компилятор сделает так, что в случае EnumMap «тыкаться get-ом в цикле» быстрее, то это будет оценено по верхнему уровню.
Или, может, все-таки задуматься над прекращением попыток сопоставить кругозор кандидатов с собственным, игнорируя все за пределами их пересечения?
Кругозор у меня широкий. У большинства кандидатов — его подмножество (я же читаю и исходный код и документацию, а вы только документацию. :-) ) Новое не игнорирую, а вот Вы за пределами прочитанной документации не вылезаете. При чем настолько не вылезаете, что даже элементарные вещи забываете.
Про царьков посмешило. Про википедию тоже. Есть вещи, которые ты просто знаешь. Алфавит, русский язык, таблица умножения и т.д. — совсем базовые знания. К этому добавляются базовые профессиональные знания — базовые алгоритмы, базовые структуры. Вы гордитесь тем, что не знаете элементарных вещей? Не царское дело? Ну и кто здесь царек? :-)
вот как-то до явной реализации алгоритмов я доходил пару-тройку раз, не более.
А что вы понимаете под алгоритмом? user stories & use cases для вас не алгоритмы? Пускай примитивные линейные даже, но это чистой воды алгоритмы.
Не нравится, что на собеседовании требуют написать алгоритм сортировки — не пиши, если хочешь обоснуй почему это не является критерием для выбора — уверен, адекватные интервьюеры адекватно оценят такой отказ.
Если тебе не все равно, то ты можешь понять, что именно хочет увидеть интервьюер, и показать ему это. Он реально хочет увидеть доскольное знание алгоритмов сортировки? — Вряд ли, а если и хочет, а ты не знаешь, то и не надо тратить время друг друга.
От потенциально опытных кандидатов ждали совсем другого, в большей степени задавались вопросы по предстоящим задачам и проблемам (актуальным или уже решённым командой), чтобы понять, на сколько кандидат «в теме» реальных боевых ситуаций…
Наверное, мне везло работать с очень толковыми и адекватными людьми.
Мне правда интересно. Мне кажется, тут есть корреляция.
Первое — маст для инженера.
Зазубрите алгоритмы факториала, сортировки, вертения деревьев, складывания чисел, переводы в другую систему, стеки, списки.
Не говорите про деревья, а то попросят вертеть их на листочке.
Выучите теорию по ооп — постебите собеседователя: перегрузка, и просто знак "+" для цифр и строк — это частный случай полиморфизма, а собеседователь этого 99% не знает.
Выучите пару паттернов и названия остальных — но не называйте их, а то заставят написать примеры. Что вы последнее назовёте — то и спросят подробнее. Уверен что собеседователи ничего кроме синглтона и фабрики никогда не использовали. Это коммерческая компания, а не исследовательский институт проблем матана и оптимизации. Узнайте что такое агрегация итп и как это рисуется на схемах uml-like, стрелочки, узнайте как правильно закрашивать стрелочки. ))
Найдите долбанутые логические задачи, например про ханойские башни, индейцев в колпаках, почему люки круглые и прочий бред от г-гонтор. Есть книги с такими задачами для собеседований белых досок стиля.
Посмотрите задачки по sql, почитайте про нормализацию. С вашим ORM вряд ли что-то напишите на sql когда спросят у доски.
Почитайте Кнута. Не тратье время на чтение 10000 страниц про ваш фреймворк и его глубокое изучение и синтаксис языка — его спрашивать не будут. Всё равно спросят про сортировку и вертение деревьев.
Будьте готовы писать на листочке или на компе где нет IDE. Попадались такие д-бы которые пишут в блокноте, ладно бы оперативки из-за джавы не было, лет 10-5 назад, но сейчас чтобы тупо «поддерживать себя в форме». Видать много денег у конторы где пишут без автодополнения и проверки ошибок средой. Наконец возьмите с собой флешку со всем необходимым — своими наработками, сорсами, IDE на флешки в конце концов.
Почитайте про протоколы, OSI, TCP/IP, REST, SOAP, COM… технологии из смежных других областей. всякая вёрстка, фронтенд, бэкэнд, админство, ассемблер, гит, аджайл-маджайл-канбан-ватерфол-акулум-мукулум… бывает любят задавать вопросы из другой области — хотят чтобы вы были на все руки мастер т.к. у г-контор денег нет на узких специалистов.
Привентивно пройдете тесты на каком-нибудь it.mail.ru. Возможно будет что-то из этого.
Поищите на гитхабе сорцы по названию конторы. Наверняка кто-то выкладывал тестовое. Запилите его привентивно.
Узнайте как компания относится к опенсорсу: контрибутит или нет. Если заядлая проприетари типа ms, то удалите\скройте всё с гитхаба, типа вы чтити nda. Если контрибутят, то наоборот открывайте.
Правильные ответы на другие вопросы:
Семейное положение: женат\есть девушка, есть дети\жена беременна. Даже если их нет. (Типа вы не свалите с конторы в другую контору или город быстро).
Проживание: местный, ипотека. (не привязанных к городу не горят желанием брать)
Армия — отслужил/не берут по здоровью.
Хобби — программировать, решать сверурочно задачи из конторы за бесплатно, ни в коем случае не кататься в байкер клубе.
Для девушек — не люблю детей и не хочу их (чтобы в декрет не свалили).
Где родители\поехали бы к ним если они заболели — умерли.
Оставались ли до ночи в конторе — да.
Почему свалили с прошлой конторы — тут сами соврите чё-нить правдоподоное.
Для того, чтобы придумать алгоритм Дейкстры не требуется глубоких мыслей, он придумывается «влёт».
Я понимаю если бы вас КМП, БМ или там BFPRT просили на интервью придумать. Но Дейкстру? Это ж база! Этому алгоритму больше лет, чем вам, скорее всего, и он не был придуман ещё раньше просто потому что понятия алгоритм 100 лет назад не существовало!
Умение придумывать алгоритмы — это и есть базовый навык software engineerа и если вы не можете придумать Дейкстру, то что вообще вы сможете придумать? Шаг влево, шаг вправо — расстрел? Если на Stack Overflow алгоритма нет — то всё?
Люди имеют в голове разные трактовки. При столкновении с чужим, отличным от своего, мнением возникает пресловутый когнитивный диссонанс, устранить который люди пытаются спором.
Вот на примере профессии «водитель».
1. Согласно ПДД
Водитель — лицо, управляющее каким-либо транспортным средством, погонщик, ведущий по дороге вьючных, верховых животных или стадо.
2. В бытовом понимании — водитель легковой или грузовой машины.
3. А еще есть водитель спортивного автомобиля.
Три этих трактовки под одним словом. И если пытаться требования к водителю спортивной машины предъявить рядовому водителю — это будет нелепо.
Так с чего же мы спорим о том, нужны алгоритмы или нет, или там знание определенных структур данных?
Точно так же
1. Если человек будет писать простые сайты на CMS — нафига ему алгоритмы? Гораздо важнее, чтобы он владел стэком front-endа, который сегодня переживает очередной бурный виток развития. Ибо за 1 день реакт или там ангулар не выучишь.
2. Если человек будет заниматься поддержкой и развитием, например, криптографического софта — его базовые алгоритмы, конечно, спросят. Но гораздо больше потенциальных работодателей будет интересовать знание матаппарата из соответствующей области (малая теорема Ферма какая-нибудь, гипотезу Танияма-Шимуры могут спросить ради интереса, или математику асимметричных алгоритмов шифрования типа RSA)
3. Если человека будут брать на Highload — скорее всего, спросят про архитектурный опыт. Про понимание, какие технологии он пробовал в боевых проектах, знает ли их слабые места (Redis, который забит весь, при падении не взлетит при перезагрузке сервера; какие-нибудь там распределенные файловые системы, тюнинг Postgres, или банальность, что нельзя кэш-файлы класть в одну папку — при огромном числе на определенных файловых системах читать оттуда будет очень долго).
4. Если человека будут брать на разработку SQL — спросят про индексы, про какие-то особенности работы оптимизаторов запросов, еще что-нибудь.
Ну а в конторы типа Гугла, Фейсбука и тд берут людей, которые имеют хорошее базовое фундаментальное образование — Computer Science + матан. Потому что да, там могут бросить человека и пилить фрэнд-фид в фейсбуке, и систему распознавания лиц на фотках, и даже вообще свою файловую систему или там транслятор PHP в плюсы / вариант виртуальной машины, чтобы не закупать 100500 новых серверов под растущий трафик.
И да, освоение базовой программы на уровне понимания дает гарантию, что у человека есть данные, такие, как талант к программированию в классическом понимании, хорошая память на технические штуки. Это дает гарантию, что мозги у него заточены от природы под такие задачи плюс в них вложено то, что должно быть вложено (=экономия средств компании на обучение).
В свою очередь можно сказать, что есть разные пути к успеху, и можно, не зная этих алгоритмов и не идя стандартным путем, при наличии большого таланта, сделать какой-нибудь крутой продукт (типа распознавания предметов или фильтрации спам-комментов — очень актуально, кстати), и тебя либо купят, либо возьмут вместе с командой.
tl;dr Конечным для компании является то, может ли человек решать задачи, которые будут перед ним вставать, хватит ли у него таланта и опыта. Отсеивают либо по стандартным параметрам (если освоил CS / матан => пойдет), либо по достижениям (успешные проекты на Гитхабе, или взлетевшие стартапы).
А вы, как кандидат, можете честно прикинуть, в чем вы сильны (или вас прет и вы можете стать сильны). И не пытаться втиснуться в прокрустово ложе чужих идеалов, а выбрать ваш путь.
Успехов вам в нашем нелегком деле. Ведь сегодня в мире — наше время.
и я писал похожий по смыслу комментария пост
https://habrahabr.ru/post/279651/
Вся соль в детализации требований, кто такой этот «программист».Вы, конечно, правы. Когда мы долго и упорно обсуждаем статью, которая, на минуточку, посвящена процессу интервьюирования в Amazon'е, Facebook'е и Google, а потом в комментариях вдруг возникают заказчики, которым нужно дёшево, то я даже не знаю что об этом сказать…
Люди имеют в голове разные трактовки. При столкновении с чужим, отличным от своего, мнением возникает пресловутый когнитивный диссонанс, устранить который люди пытаются спором.
Ну не было у этих компаний заказчиков никогда! И не будет! Некому там «жопится из-за каждого потраченного часа»! А посчитать и припомнить убытки, которые фирма понесла из-за вашего «срезания углов» (или, наоборот, прибыль от того, что вы снизили потребности в железе) — вам могут. Уж не говоря о том, что руководителями этих компаний (у Amazon'а — подразделения) работают люди, знакомые с алгоритмами и программированием не по-наслышке.
Как можно обсуждать этот мир с позиций «заказчиков» и «ввода в эксплуатацию проекта»?
Программисты не могут написать алгоритмы без помощи: ещё раз про интервью