Здравствуйте, ukrspecs, Вы писали:
U>Факт на лицо, что компания не собиралась меня нанимать, а держала как запасной вариант. Хотя бы по причине не рыночной зарплаты могу судить.
Я так понимаю, что это всё-же предположение? Какой смысл опрашивать человека просто так (как запасного)?
Или это футбольный клуб мировой лиги, где обязательно должна быть "скамейка_запасных"?
U>Они же убеждали меня , что рейт им подходит (нагло врали). Но уверен, что дело именно в деньгах, а не абстрактных классах.
Рейт может и подходил, но толко до того самого момента, пока к ним не пришёл кандидат, продающий себя за меньшую сумму.
Здравствуйте, netch80, Вы писали:
N>Не требуется комментирования, просто учтите, что так делать нежелательно даже на таком полемическом форуме.
Это в полной мере относится и к вам. Вы додумываете за меня какую-то хрень и я вынужден потом с этом что-то делать.
N>Ну вот, вы, оказывается, сами понимаете, что доводить до абсурда — бессмысленно. Тогда зачем всё это было?
В моем случае целью было показать насколько обозначенный подход порочен. Видимо, получилось.
N>"Сходу" — неточно, "без ошибок" — перебор (хотя сильно зависит от типа ошибки — естественно, опечатки, порядок аргументов и пр. — не в счёт), писать на бумаге — разве что на каплю хуже, чем на доске. N>Хотя я согласен, что по умолчанию лучше предлагать доску — потому что уметь сделать на бумаге так, чтобы читалось даже со 100500 помарками, это уже скилл старшего поколения (может, ещё такого, как я, что помнит перфокарты).
Еще раз: в жизни встречаются случаи, когда соискателей заставляют писать код на бумаге не давая возможности пользоваться справочниками и/или IDE, а потом доколупываются до ошибок в названиях методов/функций или пропущенных знаках препинания (незакрытых скобках). Мотивируя это, например, так "Ну вы же заявили отличное знание C++ и STL, так как же вы не помните трех функций из <algorithm>?"
Именно о таких паталогиях я и писал в смысле, что дальше уже некуда.
При этом я ничего не говорил про написание кода на бумаге/доске в процессе собеседования в других условиях. На эту тему у меня есть сообращения, возможно, близкие к вашим, но речь шла не о таких сценариях.
S>>Вам серьезно нужна статистика случаев, когда на собеседовании просят рассказать что выведет напечатанный на бумажке код, а после приема на работу программист никогда такими вещами по работе заниматься больше не будет? Вы, блин, серьезно?
N>Да, я серьёзно.
Да уж, тяжелый случай.
N>Потому что я не считаю различие "на бумажке" и "в IDE" сколь-нибудь значимым самим по себе, без прочих параметров, как сложность, объём и всё такое.
Речь не об этом. Речь о том, что в своей работе когда программист сталкивается с непонятным кодом, то он может позволить себе запустить его и посмотреть результаты. Ну или выделить фрагмент в обособленный автономный пример и поэкспериментировать с ним. Т.е. может получить обратную связь и корректировать свои представления о том, что и как должно было бы быть, посредством актуальных результатов.
Когда программиста вынуждают предугадывать результат просто смотря на код на бумаге, не имея возможности скомпилировать и проверить, это создание каких-то искусственных условий, в которых затем разработчик вряд ли будет работать.
И один из вопросов, который при этом у меня возникает, это: "Ну и нафига?"
N>Ничего фатального тут в бумаге нет, пока не требуются специфические возможности IDE (о которых уже упоминал). N>И вот почему бумага вас так отпугивает тут — непонятно — это и есть тот ваш странный абсолют, который сбивает конструктивность дискуссии.
Еще раз, дело не в бумаге. Дело, как минимум, в оторванности от жизни.
S>>Если да, то мне бы хотелось увидеть пример того, когда программиста брали на работу для того, чтобы он затем смотрел на распечатанные куски чужого кода и рассказывал, что произойдет в результате работы этого кода.
N>Читать код — норма.
Норма. Не норма, это когда вам приносят код и требуют сказать, что будет в результате его работы.
N>Понимать, что делает код, если он объёма, например, до экрана и все вызываемые средства понятны — тоже норма.
А вот эта "норма" уже из области фантастики. Ну типа когда кода мало. И когда все понятно.
Сами часто в таких условиях оказываетесь, особенно с чужим кодом?
N>Перенос, как вы описали — что на работе будет тоже бумага — не имеет смысла.
Еще как имеет. Но если вы его не видите, то это не значит, что его нет.
Ах да, примера-то ожидаемо не было.
N>И тем не менее вы привели как положительный — пример, для которого хотели однозначный ответ.
Пример для использования в качестве капчи.
S>>>>c) есть более эффективный подход с использованием распечатанного на бумаге кода. N>>>Какой? S>>Внимательнее, пожалуйста, читайте то, что вам пишут. Я уже говорил: дайте соискателю распечатку реального кода и попросите рассказать, что он о нем думает.
N>А это ничего, что я предложил как раз осмысливание кода вслух? Вы теперь то же самое говорите мне.
Я вам это с самого начала говорил. Но говорил про примеры кода для которых нет однозначно верного ответа.
Наличие этого самого ответа создает дополнительные критерии оценки соискателя и это невольно искажает восприятие у обоих сторон. А вот если соискатель изучает код, для которого не требуется отвечать на вопрос "что мы увидим на экране", то такого искажения не будет.
Разница небольшая, но принципиальная.
S>>Кстати говоря, вы почему-то решили, что здесь речь должна идти о стиле кода. Непонятно почему.
N>Потому что стиль тоже важен. И я написал
>>> а потом и к стилю перейти?
N>"потом" тут принципиально.
Так вы не ответили на вопрос о том, почему вы решили, что речь пойдет о стиле? Стиль при таком подходе -- это последнее, что нужно обсуждать. Если кто-то думает, что стиль важен.
Опять же, возможно, мы "стиль" трактуем по-разному. Я в данном случае поразумеваю camelCase/snake_case, переносы и расставление скобочек.
S>>Мы должны хотя бы определиться с тем, кого мы ищем: середнячков, коих нужно набрать в товарных количествах, дабы они работу работали и были взаимозаменяемы, либо мы стараемся отбирать людей, производительность которых будет в два-три раза выше и которые будут предлагать нешаблонные решения, но которыми может быть гораздо труднее управлять. Разные задачи, разные подходы.
N>И что из этого должно следовать?
То, что для разных целей нужно использовать разные походы. Если вам нужно набрать большое количество людей, что означает: a) большой поток соискателей, поэтому каждому из них вы не сможете уделять много времени, и b) относительно невысокий уровень у большинства соискателей, поэтому вам потребуется какой-то повторяемый критерий, который позволит отсеивать людей с самым низким уровнем без привлечения ценных интервьюеров.
Если вы ищете буквально 4-5 крутых сотрудников, чтобы с нуля поднять совершенно новую тему, то подходы будут другие.
N>Вот я предлагаю прочитать 10-строчный пример с бумаги. Он тут же разворачивается и хлопает дверью, как ТС по рассказам его критиков?
Соискатель может повести себя как угодно. Я про другое: если вы даете соискателю 10-строчный пример и просите рассказать, что будет в результате его работы, то с моей точки зрения как интервьюер вы так себе. Ну или вам нужно за 3 месяца набрать 50 гребцов на галлеру, дабы закрыть потребности нового клиента.
N>В чём вы пытаетесь меня убедить — что если кто-то предложил прочитать с бумаги, то он робот, действующий по алгоритму и он отбракует самых интересных?
Я говорю о том, что есть более интересные и, с моей точки зрения, более адекватные подходы. И что если человек вместо них использует порочные методы, то есть вопросы к его профпригодности.
N>"Оценка по количеству правильных ответов" != "оценка только по количеству правильных ответов" N>Уже говорил: я такое проходил. Вначале дали тест, на пачке коварных примеров. Потом пошло обсуждение. Просто тест сам по себе недостаточен, но заведомо непригодных позволяет отсеять.
Да без разницы. Важен сам факт того, что количество неправильных ответов влияет на итоговый результат. И это при том, что в реальной работе у вас потом этот человек ни с одним из ваших коварных примеров не столкнется. А если и столкнется, то у него будет возможность написать тестик и посмотреть что к чему. И все это без присущего собеседованию стреса.
N>"Когда изучал", был после этого реальный фидбэк?
Народ не жаловался. И отрицательных отзывов от наших собеседований потом не слышал.
N>>>Тема знаковости char и тема его отличия от signed char и unsigned char — разные. Мой вопрос был не к тому, что какой смысл в знании знаковости char (и тем более в компиляторе от MS), а в том, как это связано с примером. S>>Меня очень бы порадовал ответ типа такого: "Я думаю, что ответ будет вот таким, но следовало бы еще проверить, если ключиком компилятора выставить char как unsigned". Это сразу бы был большой бонус соискателю.
N>А то, что именно тут ключ не влияет — для вас несущественно?
Для меня существенно то, что человек усомнился и упомянул вариант устранения этих сомнений.
Если же человек знает, что char != signed char != unsigned char, да еще вне зависимости от ключей компилятора, то он вообще ответит однозначно и вопросов к нему не будет.
Но редко кто сможет дать абсолютно правильный ответ на эту задачку с перегрузками. Я не дал. Вы не дали.
N>Если идти по собеседованиям — да, надо знать. Потому что если таких заметная часть, придётся к этому готовиться, даже если знаешь, что внутри есть реальные задачи. N>Это не очевидно?
Нет. Для меня сейчас не очевидно вы сейчас про чью точку зрения говорите: собеседующих или собеседуемых.
Меня больше заботит точка зрения собеседующих, т.е. как выстроить процесс интервьюирования так, чтобы не отсеивать самых толковых соискателей. И чтобы при этом не создать своей компании подмоченную репутацию. А это можно запросто сделать, если будет плохой сарафан от тех, кто не прошел интервью.
Однако, когда система интервьюирования выстроена, то нужно задасться следующим вопросом: а пройду ли через нее я сам? И если не пройду, то хорошо ли это.
Так вот, с точки зрения выстраивания системы интервьюирования совершенно без разницы, как часто на собеседованиях в других компаниях пересчитывают гномиков и/или определяю форму крышек люков.
N>>>Вторая, если я правильно понял, о чём речь — совсем не принципиальна (разве что для разработчика компилятора — и то не всегда). S>>Поскольку никто причин потенциально провальной компиляции не озвучил, то даже не буду гадать, что вы подразумеваете.
N>Я оценивал в следующем порядке: 1) 'C++' (до 20-го) 2) отсутствие include.
Первый пункт не понял. Там же по std::cout, auto и использованию universal references очевидно, что это, как минимум C++11 (код в режиме C++11 компилируется, кстати).
Второй пункт -- да, в точку. Но вот я не сразу обратил внимание. Привык к тому, что примеры в презентациях обычно дают в сокращенном виде, без необходимых прологов. Однако, если брать именно как есть, то не скомпилируется.
Еще есть такой момент, что если в компиляторе выставить -Wall (-Weverything) и -Werror, то будет ошибка компиляции из-за неиспользуемых аргументов в нешаблонных функциях f и multibyte character constant. Не зря же я говорил "что у меня такой код вообще не соберется". Мол, я всегда с -Wall/-Werror компилируюсь
Re[4]: Когда 15 лет опыта, а интервью как для студента
Здравствуйте, scf, Вы писали:
scf>...почему наследование УГ
scf>но интерфейсы норм, что композиция рулит, про современное ООП с иммутабельными объектами, потом можно на DDD перейти.
Нужно просто понимать — какие задачи решает, а какие не решает наследование, интерфейсы и всё ООП.
Также нужно понимать, что без осмысления пользовательских требований (aka ТЗ) и основ прикладной области,
совершенно бесполезно тешить себя идеей о знаниях ООП
Ну накрутим мы, без понятия бизнес-задачи, кучку классов и интерфейсов.
Но они в этом случае окажутся скорее вредными, нежели полезными.
Re[13]: Когда 15 лет опыта, а интервью как для студента
Здравствуйте, AlexGin, Вы писали:
AG>Уважаемый so5team, я могу только глубоко посочуствовать тому программисту, который: AG>1) Не в состоянии разобраться в 10-15 строках кода, распечатанных на бумаге.
Не стоит делать таких громких заявлений после такого
Здравствуйте, so5team, Вы писали:
S>Уважаемый AlexGin, позволю себе напомнить, что предметом этого локального обсуждения являются не качества проходящего собеседования программиста, а профпригодность собеседующего.
Как AlexGin понимает несколько строчек можно вот тут
Здравствуйте, Skorodum, Вы писали:
S>>Уважаемый AlexGin, позволю себе напомнить, что предметом этого локального обсуждения являются не качества проходящего собеседования программиста, а профпригодность собеседующего. S>Как AlexGin понимает несколько строчек можно вот тут
Хорошо и приятно, что кто-то находит твои старые посты, о которых уже и сам забыл
Плохо, что кто-то так и не понял, даже после прошествия времени, о чем там говорилось.
Re[17]: Когда 15 лет опыта, а интервью как для студента
про не жить догмами.
AG>Хорошо и приятно, что кто-то находит твои старые посты, о которых уже и сам забыл AG>Плохо, что кто-то так и не понял, даже после прошествия времени, о чем там говорилось.
Самокритичны. Это хорошо.
Теперь бы еще матчасть подучить.
Re[17]: Когда 15 лет опыта, а интервью как для студента
Здравствуйте, AlexGin, Вы писали:
AG>Хорошо и приятно, что кто-то находит твои старые посты, о которых уже и сам забыл
Свежо и больно уж с тоном контрастирует
AG>Плохо, что кто-то так и не понял, даже после прошествия времени, о чем там говорилось.
Блин, да это уже дабл фейспалм...
ты написал полную фигню, это на простейший код из 10 строчек...
S>Не согласен?
Нет там никакой фигни, ещё раз прочитав тогдашние мои сообщения, могу сказать — только изложение точки зрения есть.
Для ясности подскажу, что решения, подобные приведенным там и защищиемые (как мной, некоторыми другими форумчанами) —
имеют место и в многочисленной литературе по C++ и на сайтах (SO, codeproject и т.д).
Посему считаю — что выражена точка зрения, применимая для многих задач на современном C++.
Да, она не соответствует универсальному подходу к выделению памяти (в т.ч. на кофеварках и в часах).
Но делать всё универсальным бессмысленно:
типа на вот тебе робот-пылесос, но у него степени защиты ПО как в авионике,
правда стоит он как новое авто из салона
Согласись, что такой подход именуется "из пушки по воробьям".
P.S. Sorry, уважаемый Skorodum, если прежнее моё мнение о вас у меня изменилось
Здравствуйте, AlexGin, Вы писали:
AG>Нет там никакой фигни, ещё раз прочитав тогдашние мои сообщения, могу сказать — только изложение точки зрения есть.
AG>Для ясности подскажу, что решения, подобные приведенным там и защищиемые (как мной, некоторыми другими форумчанами) - AG>имеют место и в многочисленной литературе по C++ и на сайтах (SO, codeproject и т.д).
Re[18]: Когда 15 лет опыта, а интервью как для студента
Здравствуйте, Skorodum, Вы писали:
AG>>Плохо, что кто-то так и не понял, даже после прошествия времени, о чем там говорилось. S>Блин, да это уже дабл фейспалм...
Это яркий пример 15 лет опыта (думаю что у него даже побольше будет) при которых человек так и застрял на базовом уровне.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, ukrspecs, Вы писали:
U>>А эта компания еблая и пушистая, с идеальной репутацией.
AG>Это опечатка, или вывод?
Как вам угодно.
Мне больше второй вариант нравится.
Re[4]: Когда 15 лет опыта, а интервью как для студента
Здравствуйте, AlexGin, Вы писали:
AG>Я так понимаю, что это всё-же предположение? Какой смысл опрашивать человека просто так (как запасного)? AG>Или это футбольный клуб мировой лиги, где обязательно должна быть "скамейка_запасных"?
AG>Рейт может и подходил, но толко до того самого момента, пока к ним не пришёл кандидат, продающий себя за меньшую сумму.
На одну эту позицию было как минимум несколько кандидатов, как максимум — десятки. Объявление висело везде, где мог пройти разработчик. Так что думаю им было из чего выбрать. И решающим фактором, как по мне, стала цена и возможно псих. совместимость. Все же не могу назвать себя супер командным игроком, хотя сто раз работал в команде и тим лидом в том числе.
Re[19]: Когда 15 лет опыта, а интервью как для студента
Здравствуйте, John1979, Вы писали:
J>Это яркий пример 15 лет опыта (думаю что у него даже побольше будет) при которых человек так и застрял на базовом уровне.
Причем это вещи, которые сейчас считаются само-собой разумеющимися, их активно обсуждали и искали решения лет 15 назад.
Re[11]: Когда 15 лет опыта, а интервью как для студента
Здравствуйте, AlexGin, Вы писали:
AG>Отрасль IT как раз и характерна тем, что люди, в разных компаниях — работают с совсем разными сущностями. AG>В нашей отрасли очень часто получается так, что "здесь" под основами предполагается одно, а "там" — несколько другое. AG>Даже несмотря на то, что и "здесь" и "там" — очень схожие стеки технологий.
Это же основы! Но для их понимания нужно поработать и здесь, и там. А откуда такой опыт у вчерашнего студента?
Re[4]: Когда 15 лет опыта, а интервью как для студента
Здравствуйте, Closer, Вы писали:
mgu>>По моему опыту, более 80% лиц с высшим образованием неспособны писать на родном языке без ошибок хотя бы на уровне начальной школы. На ЯП они кодируют соответственно, полагая, что если компилятор прожевал, то всё в порядке.
C>Это опять же не уместная аналогия (что-то их много в этой теме).
C>Навыки письма на натуральном и искуственном языке это разные навыки и никак друг с другом не связаны.
Можете считать меня британским учёным, но я заметил строгую корреляцию между обоими навыками.
C>С такой "логикой" можно прийти к выводу что какой-нибудь корректор в газете или журнале, должен быть вообще супер-программистом раз родной язык отлично знает (включая тонкости граматики с орфографией) и за всеми ошибки исправляет Но это же не так. Просто из-за специализации в этой области он делает эту работу лучше чем большинство других людей.
Так "корректор" есть и в любой современной IDE, тот самый, который подсказывает про, скажем, "не все пути возвращают значение". Это формальная проверка, которая не спасает от ядрёных (core) проблем в коде.
Re[4]: Когда 15 лет опыта, а интервью как для студента
Здравствуйте, Abalak, Вы писали:
bnk>>Ну вот скажи например, что есть "эксепшен" ("исключение")? Я так сходу пожалуй и не отвечу
A>Исключительная ситуация, когда что-то пошло не так. А дальше, можно развернуть.
Я бы сказал "исключаемая".
Re[9]: Когда 15 лет опыта, а интервью как для студента
Здравствуйте, AleksandrN, Вы писали:
AN>Т.е. — граница между интерфейсом и абстрактным классом в C++ очень размыта. В отличие других языков, например Java, где эти понятия жёстко разделены.
Хе-хе. В Джаве №8 в интерфейсах разрешили имплементацию методов по умолчанию. Я живо представил, как я это сообщаю специалистам по допотопным версиям, и как они гонят меня ссаными тряпками.
