Вы уж извините, но читаю ваш топик и смеюсь. Это какую же звезду нужно словить, что бы уходить с собеседования из-за того, что при устройства на техническую позицию кандидату задали ... технический вопрос?

Вы вообще себе представляете, какие кандидаты порой встречаются на собеседованиях? Да можно такого "спеца" с "многолетним опытом" работы встретить, что потом хоть в запой уходи — они ничего не знают. Ноль без палочки. И в резюме могут такое нафантазировать, что мама не горюй.
Поэтому никто наслово никому не верит. Всем плевать, что вы там понаписали, собеседующему необходимо выяснить ваш реальный уровень знаний. Может быть вы балду последние годы гоняли, может быть вы вообще никакой.

И вопросы были вам заданы абсолютно нормальные. И задачака по strrev — это отличная задачка. Во-первых, он простая, там надо 10 строк кода написать. Во-вторых, она сразу же даст представление насколько вы умеете писать эффективный код (например, будете ли вы для этого аллоцировать новый массив). В-третьих, она дает стартовую точку про более глубокий разговор про массивы/указатели, про работу с памятью, про то, как это все завести в многопоточной среде. Это отличная задача.

Ну а ваше "я пришел на тимлида" — это вообще что-то с чем-то. Ну пришли, и что? Что вам теперь надо в ноги кланяться и ни в коем случае вопросы технические не задавать? Тимлид это в перву очередь технарь, опора для младших коллег, и уже во вторую очередь руководитель. Поэтому они и заинтересовались в первую очередь вашими техническими компетенциями, а не менеджерскими, и правильно сделали.

Резюме:
1) Уверен, что эти ребята ни секунды не сожалели, что вы ушли. Такие высокомерные в нормальном коллективе не нужны.
2) А вы словили конкретную звезду, потеряли связь с реальностью. А потом еще и сопли на форуме развели: "Как так? Мою корону никто не заметил!" Рекомендую спуститься на землю.

Собственно, разговор, наверное, нужно начать с того, что предложение о вакансии было предложено через КА и выглядело вполне неплохо. Но не так уже чтобы завораживающие. Решил посмотреть. Теперь есть что рассказать.

На собеседование со стороны компании пришло сразу четыре человека. Кто эти люди, их должности, или хотя бы имена, остались за кадром. Количество людей аргументировалось "разными" вакансиями. Странно, вроде шёл на какую-то конкретную (руководитель группы). Далее последовало стандартное предложение "расскажите о себе, о чём занимаетесь на текущем месте работы.". Хм... Но как-то рассказал, хотя это больше походило пересказ резюме с дополнительными подробностями. На это ушло не меньше получаса. Один человек ушёл — рассказчик из меня видимо, никудышный.
Дальше перешли к "технической" части. Ладно, вопрос чем отличается map от vector можно ещё отнести к разогревочным. Но что люди ожидают услышать на вопрос "слышали ли о многопоточности?". Или ещё лучше "Какие объекты синхронизации Вы знаете?". Нет, с одной стороны вопросы вполне корректны (а чего не спросить-то?), но с другой стороны никак не соответствуют не заявленной вакансии, ни опыту кандидата. Ну, ладно. Далее вопрос, который поставил меня в тупик: "Какие типы эвентов бывают?". Щито?! Не буду томить, но оказывается типизация производится по признаку автоматического/не автоматического сброса. В ответ предложил свою — именованный/не именованный. Хотя может это вопросы из разряда "поговорить?". Закончилось всё предложением написать на бумажке функцию strrev. Отказался, надеюсь, что вежливо.

Собственно к чему я всё это. В моём личном рейтинге худших собеседований уверенное третье место. Сложилось впечатление, что люди банально поленились подготовиться к собеседованию: подготовить вопросы соответствующие вакансии; прочесть резюме кандидата и так далее... Да просто ноутбук принести, в конце концов. И это печально. Хотя люди приятные. Так что имейте ввиду, может и не стоит туда ходить, если нет лишнего времени "на поговорить".

P.S.
Рейтинг худших собеседований (названия фирм потерялись за давностью лет):
1. "Ой, вы знаете, человек который должен быть вас собеседовать не пришёл, поэтому пришёл я, но я знаю что у Вас спрашивать".
2. "Ещё в Советском Союзе я получил авторское свидетельство. Сейчас наше ООО продаёт продукцию американцам. Круче никого нет" (итак целый час).

Здравствуйте, Andrusha, Вы писали:

A>"Это ваши проблемы" (один известный персонаж). Меня как соискателя это несколько не колышит кто к ним приходит.
Вот так и знал, что услышу что-то в духе "мне пох", мой диагноз про звезду подтверждается. Вы человек. Вы живете в обществе людей. Люди взаимодействуют друг с другом. И это взаимодействие тем лучше, чем лучше они понимают мотивы друг друга. Я вам объяснил, почему работодателя начинают распросы о базовых вещах даже у опытных кандидатов — потому что ваши слова в резюме сами по себе ничего не значат. Если вы не хотите понимать других людей, если вы считаете себя пупом земли, то грош вам цена как специалисту, и уж тем более вы не можете быть тимлидом, который должен уметь понимать своих коллег, понимать почему у них возникают те или иные проблемы, и помогать им их решать. Точно так же тимлид должен понимать и мотивы своего руководства. Он должен понимать политические подоплеки, он должен понимать, какие группы влияния существуют, он должен понимать почему требования у продукта могут меняться за день до релиза. И так далее. Вы же не командный игрок, вы не видите дальше своего носа. "Меня не колышит" — сколько всего сокрыто в этой фразе.

A>Задача для чего? Писать библиотечные функции? Зачем?
A>На момент формулирования данной задачи "собеседование продлилось" уже час (60 минут). Куда ещё развивать тему?
Я уже объяснил зачем — что бы проверить ваши базовые знания. Если вы первом делом заалоцируете новый массив, то какой вы тимлид? Каким образом ваша команда будет писать качественный код? Вам дали элементарнейшую задачу на 10 строчек кода. Вам, что, впадлу было взять в руки ручку и потратить 5 минут своего драгоценнейшего тимлидовского времени на ее решение?

A>Я работал в разных компаниях и везде тим-лиды занимались разными вещами. Описанное вами не очень коррелирует с моим опытом. Впрочем, не будут спорить — может у вас и так. Только в таком случае надо более подобно/внятно/обстоятельно составлять предложение о вакансии. Или, что лучше, в начале собеседования сказать что интересно услышать от соискателя, а что нет. Этого не было.
А может быть это вам надо было спросить во время телефонного общения, в чем именно заключается вакансия? Чего это вы так резво переложили вину за непонимание на других?

Здравствуйте, devcoach, Вы писали:

D>Вы уж извините, но читаю ваш топик и смеюсь. Это какую же звезду нужно словить, что бы уходить с собеседования из-за того, что при устройства на техническую позицию кандидату задали ... технический вопрос?

Это технический вопрос не соответствующий сути заявленной вакансии. Это как если спросить, знаете ли вы как работает MOSFET транзистор?

D>Вы вообще себе представляете, какие кандидаты порой встречаются на собеседованиях? Да можно такого "спеца" с "многолетним опытом" работы встретить, что потом хоть в запой уходи — они ничего не знают. Ноль без палочки. И в резюме могут такое нафантазировать, что мама не горюй.

Вот ни разу в жизни такого не встречал, хотя собеседую людей уже лет 10. Если у человека хотя бы пара лет приличной конторы в бэкграунде, можно даже не проверять, наверняка квалификация соответствует заявленной. Проверять внимательно надо либо нубов, либо людей меняющих область деятельности.

D>Поэтому никто наслово никому не верит. Всем плевать, что вы там понаписали, собеседующему необходимо выяснить ваш реальный уровень знаний. Может быть вы балду последние годы гоняли, может быть вы вообще никакой.

Это паранойя, вам бы укольчиков, а не людей собеседовать.

D>И вопросы были вам заданы абсолютно нормальные. И задачака по strrev — это отличная задачка. Во-первых, он простая, там надо 10 строк кода написать. Во-вторых, она сразу же даст представление насколько вы умеете писать эффективный код (например, будете ли вы для этого аллоцировать новый массив). В-третьих, она дает стартовую точку про более глубокий разговор про массивы/указатели, про работу с памятью, про то, как это все завести в многопоточной среде. Это отличная задача.

Во-первых, это задача сложная. Больщинство программистов никогда не пишет такой код с нуля, а пользуется библиотеками. Даже если такой код пишется с нуля, он пишется не за пять минут, а за пару дней с проектирование, тестовым покртием, гуглением источников. Во-вторых, эта задача входит в стандартный курс подготовки к собеседованиям и ее информативность чуть менее чем никакая. В-третьих, по моему опыту с люди которые кидались решать эту задачу с ходу и таки ее решившие впоследствии вызывали кучу проблем. Как правило они начинали городить жуткие велосипеды прикрываясь разговорами об эффективности в которых потом годами отлавливали баги. Я, слава богу, отучил своих превращать собеседование в состязание по решению дурацких задачек.

D>Резюме:
D>1) Уверен, что эти ребята ни секунды не сожалели, что вы ушли. Такие высокомерные в нормальном коллективе не нужны.

И очень хорошо. Пока есть такие привередливые ребята, другие ребята, вроде нас, смогут нанять хорошего спеца задешево.

D>2) А вы словили конкретную звезду, потеряли связь с реальностью. А потом еще и сопли на форуме развели: "Как так? Мою корону никто не заметил!" Рекомендую спуститься на землю.

Вообще интересно как за каких-то пять лет характеристика "звезда" стала оскорблением. А ведь не так давно считалось что программирование сродни шоу бизнесу.

A>Опыт чего? Вакансия, обращаю внимание, "руководитель группы". Вопросы я ожидаю примерно о том, как руководить группой. Да, можно задать вопросы по технической части, но не уровня "слышали ли вы про многопоточность", а на уровне архитектуры проекта. Можно обсудить нюансы реализации тех или иных библиотек, чтобы понять какие человек использовал или как принимает решения. И так далее.

Руководитель группы == team lead == техническая специальность. Если ты не владеешь технологиями на одном уровне с группой, как ты будешь руководить?

Ты может попутал "руководитель группы" и "руководитель проекта"? Хотя я сам сторонник того, что руководитель проекта в технологиях тоже должен понимать.

Здравствуйте, Vzhyk, Вы писали:

V>Вообще-то да, должны.
Ну да, ну да. Есть такой тип людишек, которым все вечно что-то должны, потому что они такие красивые/умные/занятые/соизволили приехать на собеседование — выбрать по вкусу. Запомните, Vzhyk — никто вам ничего не должен, кроме тех, кто брал у вас взаймы.

V>В упор не увидел у ТС,
Вы примерили ситуацию на себя, — как это так, я соизволил придти к ним на собеседование, а они ДАЖЕ РЕЗЮМЕ НЕ ПРОЧИТАЛИ! В данном конкретном примере вы солидаризируете свою позицию с топикстартером. Значит, у вас точно такое же раздутое ЧСВ как и у него. Потому что такая мысль может придти в голову только человеку с непомерным ЧСВ и в принципе не может придти в голову человеку, у которого его нет. Это просто, как дважды два.

V>а вот от некоторых, пишущих здесь за контору,
V>таки да, ЧСВ гигантское.
Не фантазируйте, его у меня нет. Я в конторе занимался вполне заурядной офисной автоматизацией, а не "передовыми биржевыми технологиями". Такая автоматизация есть в любых "рогах и копытах" и я не считаю, что я чем-то лучше/умнее/способнее людей, которые делают ту же работу в других компаниях. И когда на собеседования ходил, то не залупался из-за того, что мое резюме, видите ли, не выучили наизусть. Никаких проблем — расскажу о себе хоть десять раз десяти разным людям на собеседовании, если попросят.

V>А не мог бы ты пояснить, что имеешь в виду под словами неплохо
V>строиться. Пока я увидел работать за троих и можно попросить зарплату.
Двое/трое (за которых приходится работать нынешним сотрудникам) — это отсутствующие работники, т.е.вакансии. Как только возьмут на них людей, необходимость в этом должна отпасть. Условия действительно можно [было — см.ниже] выторговать себе приличные, потому что у биржи с РТСной ТС сейчас задница и люди им нужны [были] срочно.

Экс-биржевик.

PS. За время этой дискуссии вакансия топикстратера (руководитель группы) и вакансия его непосредственного подчиненного (старший разработчик) исчезли с сайта HH. Вероятно, таки нашли людей. Думаю, что те, кого взяли на эти должности, не погнушались чиркнуть несколько строк кода на бумажке и не кривили физиономию, когда их просили устно повторить то, что изложено в их резюме.

02.09.2013 16:02, Andrusha пишет:

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

A>Правда, в таком случае на такие собеседования надо со своей раскладушкой приходить и запасом еды на несколько дней. Зато работодатель будет уверен, что нанял настоящего профессионала:

В данном случае работодатель может быть уверен, что не нанял дерганного обидчивого человека. Win.

Здравствуйте, robin_of_the_wood, Вы писали:

___>Более того ведь тот факт, что Вы забыли обьявить переменную — это полностью Ваш просчет и его правильно бы было как можно незаметнее исправить.
Меня аж передернуло от этой фразы. К реальной работе этот "просчет" не имеет вообще никакого отношения.

Здравствуйте, landerhigh, Вы писали:

L>Написание strrev на бумажке относится к созданию программного продукта примерно так же, как и прием солнечных ванн в нерабочее время.
L>Нет, не не просто. Код пишется в компьютере. Большинство программистов что-то пишут на бумажке, когда рисуют квадратики во время brainstorm и когда счет в ресторане кредиткой оплачивают. Рисовать же на бумажке фигурные скобочки — это вообще онанизм.

Вот интересно, какие такие неразрешимые проблемы возникают при написании strrev на бумажке, которые решит IDE?

Здравствуйте, Vzhyk, Вы писали:

V>10.09.2013 12:54, robin_of_the_wood пишет:

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

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

Так что тестирование — не панацея и не серебрянная пуля, смотрите, не обожгитесь

09.09.2013 11:28, genre пишет:

> реально не могут написать 10 строк не очень сложного кода без ошибки?
Пока тесты не пройдены, я всегда предполагаю, что код делает не то, что
нужно.

Здравствуйте, Берсерк, Вы писали:

Б>Здравствуйте, Andrusha, Вы писали:

A>>Собственно, разговор, наверное, нужно начать с того, что предложение о вакансии было предложено через КА и выглядело вполне неплохо. Но не так уже чтобы завораживающие. Решил посмотреть. Теперь есть что рассказать.

Б>Вполне нормальный подход. Ты вопросы про гору Фудзи ждал или гномиков? Именно таким и должно быть интервью, на мой взгляд. Обсудить опыт плюс пара простых вопросов, что бы отсеять совсем неадекватных.

Опыт чего? Вакансия, обращаю внимание, "руководитель группы". Вопросы я ожидаю примерно о том, как руководить группой. Да, можно задать вопросы по технической части, но не уровня "слышали ли вы про многопоточность", а на уровне архитектуры проекта. Можно обсудить нюансы реализации тех или иных библиотек, чтобы понять какие человек использовал или как принимает решения. И так далее.

Впрочем, конечно, я не знаю что у них там за группы, может это и адекватно.

02.09.2013 17:33, Stanislav V. Zudin пишет:

> Мне доводилось собеседовать программистов с 10-летним стажем без навыка
> программирования и не имеющих представления о многопоточности. Как
> умудрились столько продержаться — (возможно сопровождали чужой код с
> минимальными правками).
Вот я и говорил уже много раз в подобных вакансиях нужно писать про опыт
не от стольки-то лет, а до.
А то с опытом начинаешь понимать, что где-то многопоточность необходима,
а где-то вредна и проекты длятся не по 3 месяца, а по 3-5-7 и более лет.

> Так что такие вопросы вполне уместны.
Конечно уместны, зависит от того, кого ты ищешь. Приведу простые
аналогии. Ищут мера города, а на собеседовании просят вымести на время
улицу или другая крайность — ищут дворника, а на собеседовании начинают
спрашивать про устройство городского хозяйства. Кстати, подобным
страдают в основном на програмерских собеседованиях, почему-то.

Здравствуйте, genre, Вы писали:

G>Здравствуйте, landerhigh, Вы писали:

L>>Еще раз — в реальной работе навык программирования ручкой по бумажке не востребован никак.

G>Еще раз спрошу. Чем написание strrev на бумажке отличается от написание ее же в IDE?

Еще раз отвечу — лица, умеющие программировать в IDE, знают, в чем разница. Остальным это объяснять бессмысленно.

Здравствуйте, Andrusha, Вы писали:

___>>Я имел ввиду причину Вашего отказа от написания strrev на бумаге.
A>А, понял. Я написал первую строчку while... потом подумал, что надо сначала объявить переменную, затем понял что на бумаге это уже не влезет. Дальше уже поинтересовался, а что собственно хотят, разговор перетёк в другое русло и всё.
A>Отвечая на ваш вопрос: нежелание переписывать на бумаге стало последней каплей и причиной для завершения собеседования.

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

И еще хочу добавить пару слов про задачки на бумаге. Многие люди их очень с большим трудом решают.
Бумага, "время пошло!" — все это очень сильно отличается от обычной работы.
Но часто для опытного разработчика сложно именно быстро придумать алгоритм, а не закодировать его.
И в этом плане strrev или удаление из строки определенных символов — более простые задачи чем скажем разные сортировки или нахождение циклов в связном списке. Тут ведь нужно всего лишь закодить интуитивно понятный алгоритм, а это после многолетней практики рука уже сама пишет

И еще с точки зрения собеседователей зачастую такие задачи — это еще и проверка умения доводить дело до результата.
Ведь в реальной работе нужно решение. Пусть неоптимальное, пусть с элементами компромисса, но решение, а не высоконаучное обьяснение почему это сделать не получилось. И поэтому отсутствие решения или отказ от решения задачи на бумаге почти всегда приведут к финалу собеседования.

Здравствуйте, MxMsk, Вы писали:

___>>Более того ведь тот факт, что Вы забыли обьявить переменную — это полностью Ваш просчет и его правильно бы было как можно незаметнее исправить.
MM>Меня аж передернуло от этой фразы. К реальной работе этот "просчет" не имеет вообще никакого отношения.

Согласен.
Но в реальной работе будут другие просчеты(мы ведь люди а не роботы), а вот реакция человека на свои просчеты обычно величина довольно постоянная.
И у одних людей она ближе к "Ой спасибо. Сам не заметил. Сейчас исправлю!", а у других больше похоже на "И что же мне теперь это переписывать?"
И работать с первой категорией людей гораздо удобнее и полезнее для нервной системы

Здравствуйте, Vzhyk, Вы писали:

V>Проблемы в написать нет, а в чем проблема — читай весь топик, по второму
V>кругу ходить неинтересно.

Я пока не вижу ничего интересного в обсужденном. пока утверждают лишь:
— я слишком крут для этой задачи
— не люблю писать на бумаге
— без тестов никак не могу написать
— такую задачу на работе решать не придется, зачем я напрягаться буду.

не катит за причину.

V>З.Ы. Тут уже некоторые пытались выкладывать свои решения в 10 строк,
V>которые успешно оказывались или некорректными или безграмотными с точки
V>зрения кывтовцев. А вот обратного я что-то не припоминаю. Это я написал
V>тебе для размышления о 10 строчках кода на собеседовании и собеседующих.

не понимаю какой из этого можно сделать вывод, кроме того, что многие не могут решить простую задачу.

Здравствуйте, Andrusha, Вы писали:

A>>Руководитель группы == team lead == техническая специальность. Если ты не владеешь технологиями на одном уровне с группой, как ты будешь руководить?

A>Не вопрос, что придётся писать код. Это как бы даже и не обсуждаться. Обсуждается уровень вопросов. Я может в каком-то странном мире живу, но мне кажется, что любой человек программирующий на С++ под Windows в районе 12 лет знает что такое многопоточность. Впрочем, я даже готов что это надо как-то уточнить. Но 30 минут рассказов до этого о проектах в которых явно более чем один поток — это к чему? Поговорить?

Мне доводилось собеседовать программистов с 10-летним стажем без навыка программирования и не имеющих представления о многопоточности. Как умудрились столько продержаться — (возможно сопровождали чужой код с минимальными правками).
Так что такие вопросы вполне уместны.

Здравствуйте, devcoach, Вы писали:

D>Вы уж извините, но читаю ваш топик и смеюсь. Это какую же звезду нужно словить, что бы уходить с собеседования из-за того, что при устройства на техническую позицию кандидату задали ... технический вопрос?

Технический вопрос на уровне "видели ли вы компьютер?"

D>Вы вообще себе представляете, какие кандидаты порой встречаются на собеседованиях? Да можно такого "спеца" с "многолетним опытом" работы встретить, что потом хоть в запой уходи — они ничего не знают. Ноль без палочки. И в резюме могут такое нафантазировать, что мама не горюй.
D>Поэтому никто наслово никому не верит. Всем плевать, что вы там понаписали, собеседующему необходимо выяснить ваш реальный уровень знаний. Может быть вы балду последние годы гоняли, может быть вы вообще никакой.

"Это ваши проблемы" (один известный персонаж). Меня как соискателя это несколько не колышит кто к ним приходит.

D>И вопросы были вам заданы абсолютно нормальные. И задачака по strrev — это отличная задачка. Во-первых, он простая, там надо 10 строк кода написать. Во-вторых, она сразу же даст представление насколько вы умеете писать эффективный код (например, будете ли вы для этого аллоцировать новый массив). В-третьих, она дает стартовую точку про более глубокий разговор про массивы/указатели, про работу с памятью, про то, как это все завести в многопоточной среде. Это отличная задача.

Задача для чего? Писать библиотечные функции? Зачем?
На момент формулирования данной задачи "собеседование продлилось" уже час (60 минут). Куда ещё развивать тему?

D>Ну а ваше "я пришел на тимлида" — это вообще что-то с чем-то. Ну пришли, и что? Что вам теперь надо в ноги кланяться и ни в коем случае вопросы технические не задавать? Тимлид это в перву очередь технарь, опора для младших коллег, и уже во вторую очередь руководитель. Поэтому они и заинтересовались в первую очередь вашими техническими компетенциями, а не менеджерскими, и правильно сделали.

Я работал в разных компаниях и везде тим-лиды занимались разными вещами. Описанное вами не очень коррелирует с моим опытом. Впрочем, не будут спорить — может у вас и так. Только в таком случае надо более подобно/внятно/обстоятельно составлять предложение о вакансии. Или, что лучше, в начале собеседования сказать что интересно услышать от соискателя, а что нет. Этого не было.

D>Резюме:
D>1) Уверен, что эти ребята ни секунды не сожалели, что вы ушли. Такие высокомерные в нормальном коллективе не нужны.
D>2) А вы словили конкретную звезду, потеряли связь с реальностью. А потом еще и сопли на форуме развели: "Как так? Мою корону никто не заметил!" Рекомендую спуститься на землю.

1. Возможно.
2. Ещё один доктор-по-фотографиям.

Здравствуйте, Vzhyk, Вы писали:

V>По крайней мере для меня твои восхваления конторы — антиреклама. Ну то
V>бишь, если тебе там нравиться, то мне там не понравилось бы.

А такие как ты там и не нужны

Здравствуйте, avpavlov, Вы писали:

A>Руководитель группы == team lead == техническая специальность. Если ты не владеешь технологиями на одном уровне с группой, как ты будешь руководить?

Вопрос "какие объекты синхронизации знаете" говорит о том, что задающий этот вопрос о многопоточности читал только в книжках. И последний раз это делал где-нибудь в конце 90-х.

Здравствуйте, ArtemGorikov, Вы писали:

AG>Вы либо гений с проблемами в общении, либо удачно троллите.

Вариант дурак с проблемами в общении, надо сказать, тоже не исключен

Здравствуйте, landerhigh, Вы писали:

L>А вот это

L>

L>Еще раз, медленно и по буквам. У настоящего программиста понятие "код" существует только в виде "оформленный согласно принятым coding standards со всеми необходимыми комментариями, юнит-тестами и подготовленный к code review". Такое бывает только в IDE.
L>Код на бумажке бывает только у специалистов по кодированию на бумажках.

L>ты просто не заметил, или возразить нечего?

Заметил. Очень спорное высказывание.
Похоже на точку зрения именно кодера. С его точки зрения "прошел код ревью" — успех!
Но существуют и другие точки зрения.

Код обычно пишут для того, чтобы он работал и приносил прибыль.
И с этой точки зрения совсем не важно наличие всего того, о чем Вы написали.
Код может быть ужасным но работающим, а может соответствовать всем Вашим критериям и быть никому не нужным.

Но это не значит, что я против того, о чем Вы написали.
Однообразное оформление и комментарии упрощают поддержку.
Юнит тесты гарантируют правильность работы частей кода и помогают при рефакторинге.
Но все это бывает и за пределами IDE.
Просто IDE помогает в работе, ускоряет процесс.
И эта помощь очень заметна при больших обьемах кода и почти не заметна для нескольких строк.

Если человек может написать пару строк кода по памяти, то он их напишет и на доске и на бумаге.
А если не может — то уж не бумага в этом виновата

Здравствуйте, landerhigh, Вы писали:

V_S>>А ключевое здесь вот что:
___>>>Ведь в реальной работе нужно решение. Пусть неоптимальное, пусть с элементами компромисса, но решение, а не высоконаучное обьяснение почему это сделать не получилось. И поэтому отсутствие решения или отказ от решения задачи на бумаге почти всегда приведут к финалу собеседования.

L>Если реальная работа состоит в ежедевном написании функции strrev на бумажке, то совершенно верно.

Ну я про свою работу написал.
Причем на разных проектах бывало сильно по-разному, но то, о чем я написал, везде совпадало что характерно.
Если у Вас в результате Вашего опыта работы сложилось иное мнение — расскажите. Я думаю многим будет интересно.

А про strrev на бумажке я вот не совсем понимаю суть проблемы.
Я понимаю конечно, что в общем случае писать на бумажке — гораздо неудобнее чем в IDE.
Но есть ведь граничные случаи, которые из-за своей простоты пишутся по памяти уже после пары месяцев программирования.
Разве нужна IDE чтобы написать своп двух элементов массива?
А для того, чтобы сделать этот своп в цикле для первого-последнего, второго-предпоследнего итд?
И это и есть вся задача, если кто не знал
И заметьте что задачу дают не первокласснику а человеку с техническим дипломом.
Если это уже сложно, то может в другую профессию? Или будем на собеседовании таблицу умножения и алфавит спрашивать?

Судя по тому, что вакансия в Московской Бирже еще не закрыта, можно сделать соответсвующий вывод. Московская Биржа и не собиралась никого нанимать, а эти вакансиии вывешиваются по другим причинам.

Я понял вас. Беру свои слова про звездность обратно, и приношу извинения. Вероятнее всего, здесь просто имело место слишком сильное несоответствие того, что вы ожидали с тем, что получилось на самом деле. Винить компанию в этом не стоит, тут скорее вам надо было узнать как можно больше прежде, чем идти туда.

Тем не менее, я продолжаю настаивать на том, что работодателя необходимо "понимать". Не в смысле "ставить его интересы выше своих", а в том смысле, что вы таким образом можете заполучить дополнительные козыри. Ведь в чем заключается процесс найма? В том, что бы найти максимально хорошего кандидата. А как это сделать? Хз. Нет ни одного инструмента, который достоверно указывал бы на хороших кандидатов. Все имеющиеся инструменты (головоломки, программа на листике, общение "по душам", хороший-плохой полицейские, и т.д.) могут лишь дать какую-то субъективную уверенность, что кандидат хорош. Причем, зачастую эта уверенность является ошибочной. Я тут в качестве примера всегда привожу недавнее интервью VP HR из Google, который заявил, что они провели масштабное исследование, по итогам которого не нашли корреляции между успешным решением кандидатом головоломок на собеседовании и его дальнейшими успехами в компании. На дворе шел 2013 год, Google — одна из самых могущественных IT-корпораций. И только сейчас они поняли, что все эти головоломки — дерьмо на палочке. Что уж тогда говорить про обычные компании? У них нет ни средств, ни возможностей, что бы как-то численно оценивать эффективность тех или иных инструментов найма. Помогает или мешает задачка "на бумажке"? Помогает или мешает тест из 100 вопросов? Помогают или мешают вопросы по сортировкам на конкретную позицию? А хз, никто достоверно не знает. Все умозрительно.
И когда вы понимаете это, вам становится ясно, что работодатель п сути безоружен перед вами. Вым становится ясно, что не только с вами могут играть, но и вы можете играть с ними. Задали вам какой-то отвлеченный вопрос? Отлично! Они хотят вас завалить на нем, что бы сбить зарплату. А вы, если шарите в теме, можете наоборот взять контроль в свои руки, увести мяч на свое поле, и использовать успешные ответ на этот вопрос как аргумент при торгах о зарплате. Ну и т.д. и т.п.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Здравствуйте, Andrusha, Вы писали:

A>>>Руководитель группы == team lead == техническая специальность. Если ты не владеешь технологиями на одном уровне с группой, как ты будешь руководить?

A>>Не вопрос, что придётся писать код. Это как бы даже и не обсуждаться. Обсуждается уровень вопросов. Я может в каком-то странном мире живу, но мне кажется, что любой человек программирующий на С++ под Windows в районе 12 лет знает что такое многопоточность. Впрочем, я даже готов что это надо как-то уточнить. Но 30 минут рассказов до этого о проектах в которых явно более чем один поток — это к чему? Поговорить?

SVZ>Мне доводилось собеседовать программистов с 10-летним стажем без навыка программирования и не имеющих представления о многопоточности. Как умудрились столько продержаться — (возможно сопровождали чужой код с минимальными правками).
SVZ>Так что такие вопросы вполне уместны.

Программисты без навыка программирования — звучит забавно.
В любом случае, проверять на собеседовании надо то, что соответствует вакансии, а не фобиям собеседующих. А то может я умею указатели разыменовывать, а вот алфавит не помню. Или, раз уж это биржа, то с трудом помню математику в объёме 5-го класса. "Какие арифметические операции Вы знаете?", "Слышали ли Вы о дробях?". А то ведь, наверное и такие есть.

Правда, в таком случае на такие собеседования надо со своей раскладушкой приходить и запасом еды на несколько дней. Зато работодатель будет уверен, что нанял настоящего профессионала: и комментарии без ошибок напишет (проверочные вопросы; "Как комментарии обозначаются в исходном коде? А чем отличаются?") и даже файл сохранить сможет (проверочные вопросы "Как выглядит иконка сохранения файла? А что на ней изображено? А что это?").

05.10.2013 18:30, vshemm пишет:

> Как раз бездумное написание тестов — типичный пример ситуации "думать
> некогда, копать/трясти надо"
> Со всеми вытекающими, ага (например
> <http://theiced.livejournal.com/254704.html&gt;).
Показательный пример. Таких писателей, имхо, к программированию на
версту подпускать нельзя.

Здравствуйте, mik1, Вы писали:

M>Когда в той же компании мне приходилось собеседовать людей на рядовые позиции, я их заранее предупреждал, что буду начинать с простых вопросов, т.к. мы применяли идентичный подход ко всем соискателям — их так сравнивать удобнее. Никто не обижался. Через 3-4 минуты переходили к более интересному. Впрочем, код писать я не просил.

у меня есть вот какое наблюдение. Редко, но все-таки встречаются люди по самым разным причинам отказывающиеся отвечать на простые вопросы.
ни разу это не было причиной окончания собеседования, то есть ну нет, так нет, поехали дальше. но ни один из этих людей в итоге собеседование не прошел. как по причинам адекватности (никто из собеседующих работать с этим человеком не захотел), так и из-за знаний.

10.09.2013 12:57, genre пишет:

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

Здравствуйте, Stanislav V. Zudin, Вы писали:


SVZ>Очень удобная позиция — объявляешь код оппонента "говнокодом" и ты в дамках.

Если код "невозможно" покрыть юнит-тестами, то это говнокод. Без вариантов.

SVZ>Давай на примере?
SVZ>Не знаю, чем занимаешься ты, но Вжик упоминал распознавание речи. Возьмем задачу, обратную ему — Text-to-speech.
SVZ>На входе текст, на выходе аудиофайл.
SVZ>Как проверить, что выходной файл содержит то, что надо и в приемлемом качестве?

Ты только что сделал смешно половине местного чати. Давай, ты сначала почитаешь что-нибудь о юнит-тестировании, чтобы мне тут основы не пересказывать?

И таки да, куча use cases и подзадач подобной задачи тестируется элементарно. При условии правильной огранизации кода, конечно, ведь если речь идет о классической монолитной функции "texttospeech" на полтора миллиона строк, то тут остается только закапывать.

SVZ>Ну или из близкого мне. Надо триангулировать полигон. Как проверить, что полученная триангуляция соответствует исходному полигону?

Я понятия не имею об алгоритмах разбиения полигонов на треугольники (термин триангуляция в более привычном мне мире означает нечто совершенно другое) и вообще не занимаюсь 3D графикой, но уже сходу могу назвать несколько тест кейсов, которые я бы написал, и более того, я даже знаю, как именно я бы их начинал писать, учитывая мои нулевые познания в данной области. Более того, я могу их написать вот прямо щас. Еще более того, это самая первая вещь, которую я бы сделал, если бы мне поставили такую задачу — я написал бы тест еще до того, как вбить в гугль "polygon triangulation algorithm".

Всего-то надо обвести все полученные треугольники по внешнему периметру (выкинуть соседние грани) и сравнить получившуюся фигуру с исходной. Хотя бы по трем проекциям. Это не просто элементарно, это третий класс начальной школы. Затем хорошо бы проверить на отсутствие пересекающихся и дублирующих треугольников. Совсем на пять — проверить оптимальность разбиения. Ну и плюс стандартные граничные условия и негативные тест кейсы.
У меня, полного баобаба в 3D все вышеописанной заняло бы ну полчаса от силы. Гораздо меньше, нежели поиск и ломание головы над собственно алгоритмом.

SVZ>Этот пример попроще предыдущего, но трудоемкость написания тестов в несколько раз выше, чем написание собственно полезного кода.

Обломайтис. Тут, как я показал, делать вообще почти нечего.

Здравствуйте, smallpoxlet, Вы писали:

S>Здравствуйте, Vzhyk, Вы писали:

V>>А то с опытом начинаешь понимать, что где-то многопоточность необходима,
V>>а где-то вредна и проекты длятся не по 3 месяца, а по 3-5-7 и более лет.

S>Дело даже не столько в опыте, сколько в том что уже давно появились алгоритмы позволяющие обходиться практически без синхронизаций. Мои программисты даже придумали задачку: дают кусок многопоточного кода и просят переписать вообще без использования синхронизаций но так чтобы код остался потокобезопасным. Все эти мьютексы и семафоры уже никому не интересны, и если про них спрашивают на собеседовании значит контора застряла по технологимя а 90-х.

Вот таких любителей "бессинхронизационных алгоритмов" хочется иногда засунуть в биореактор. Особенно когда разгребаешь после них факапы.

Вот некоторые проблемы, с которыми придется столкнуться при использовании *-free:
— производительность. Очень сложно сделать lock-free алгоритм такой же производительности как на обычных примитивах. wait-free еще сложнее, obstruction-free полегче.
— невозможность тестирования. Единственный способ — строить модель и верифицировать. Причем каждый раз при правках, а дело это небыстрое и человек должен быть явно не джуниором. А потом доказывать, что код соответствует модели (и компилятор правильно его транслирует).
— фактически, на выходе получается write-only код, который невозможно поддерживать, даже автору.

Да, потенциально у них лучшая масштабируемость и консистентность, но в реальности *-free требуются не так часто, как вы думаете. Так что люди с опытом, которые реально могут написать подобное, стараются держаться от них подальше и реализовывать *-free только при наличии очень веских причин.

С примитивами тоже не все так просто, вспомним хотя бы fine-grained и coarse-grained блокировки — опять компромисс по производительности при разных сценариях нагрузки. И т.д., говорить тут можно много К слову, все эти мьютексы и семафоры технологии скорее 60-х, а не 90-х.

Если можно, кусок многопоточного кода в студию, интересно было бы взглянуть

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>У меня сложилось мнение, что существует три типа компаний:
SVZ>1. Одним нужен "копатель" широкого профиля. Здесь годится любой вменяемый программист, способный изучить очередной фреймворк/язык/...
SVZ>2. Другим нужен специалист под конкретную технологию, но такого не найти и компания готова вложиться в человека, обучить его нужным технологиям.
SVZ>3. Третьим нужен специалист под конкретную технологию, но обучать они не хотят (или не могут) и ищут состоявшегося спеца.

SVZ>Ессно во всех трех случаях собеседования должны быть разные. Если и компания, и кандидат это понимают, то и проблем не будет

А у меня сложилось мнение, что третий тип требуется очень редко, но при этом не все об этом подозревают, а те кто о чём-то догадывается поиск производят всё равно для этого случая.

Здравствуйте, Andrusha, Вы писали:

A>Собственно, разговор, наверное, нужно начать с того, что предложение о вакансии было предложено через КА и выглядело вполне неплохо. Но не так уже чтобы завораживающие. Решил посмотреть. Теперь есть что рассказать.

A>На собеседование со стороны компании пришло сразу четыре человека. Кто эти люди, их должности, или хотя бы имена, остались за кадром. Количество людей аргументировалось "разными" вакансиями. Странно, вроде шёл на какую-то конкретную (руководитель группы). Далее последовало стандартное предложение "расскажите о себе, о чём занимаетесь на текущем месте работы.". Хм... Но как-то рассказал, хотя это больше походило пересказ резюме с дополнительными подробностями. На это ушло не меньше получаса. Один человек ушёл — рассказчик из меня видимо, никудышный.

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

По поводу написанного вами — ну не подошли вы, в чем проблема? Зачем пытаться про них что-то плохое написать? Они же про вас здесь не пишут (а я думаю что взгляд с той стороны может быть куда более интересный)?

Здравствуйте, Andrusha, Вы писали:

A> Закончилось всё предложением написать на бумажке функцию strrev. Отказался, надеюсь, что вежливо.

Самый вежливый отказ писать обращение строки.
http://rsdn.ru/forum/decl/5260271.1

Автор: Aleksandr_KPI
Дата: 14.08.13

Здравствуйте, robin_of_the_wood, Вы писали:


L>>Если реальная работа состоит в ежедевном написании функции strrev на бумажке, то совершенно верно.

___>Ну я про свою работу написал.
___>Причем на разных проектах бывало сильно по-разному, но то, о чем я написал, везде совпадало что характерно.
___>Если у Вас в результате Вашего опыта работы сложилось иное мнение — расскажите. Я думаю многим будет интересно.

Реальная работа состоит в создании программного продукта. Она состоит из множества отдельных областей знаний, но ни одна из них не требует навыков программирования на бумажках.

___>А про strrev на бумажке я вот не совсем понимаю суть проблемы.

Написание strrev на бумажке относится к созданию программного продукта примерно так же, как и прием солнечных ванн в нерабочее время.

___>Я понимаю конечно, что в общем случае писать на бумажке — гораздо неудобнее чем в IDE.

Нет, не не просто. Код пишется в компьютере. Большинство программистов что-то пишут на бумажке, когда рисуют квадратики во время brainstorm и когда счет в ресторане кредиткой оплачивают. Рисовать же на бумажке фигурные скобочки — это вообще онанизм.

___>Но есть ведь граничные случаи, которые из-за своей простоты пишутся по памяти уже после пары месяцев программирования.

И часто приходится вручную переворачивать массивы? И часто вообще приходится их в принципе переворачивать? И часто их требуется переворачивать на бумажке?

___>Разве нужна IDE чтобы написать своп двух элементов массива?

В реальной работе код пишется в IDE (или в vim в случае неортодоксов вроде вашего покорного слуги). Хотите проверить навыки реальной работы — дайте IDE (или vim, но имхо если человек просит vim для программирования, код он писать умеет по определению). Навык кодирования на бумажках же к реальной работе отношения не имеет.

___>А для того, чтобы сделать этот своп в цикле для первого-последнего, второго-предпоследнего итд?
___>И это и есть вся задача, если кто не знал

Еще раз, медленно и по буквам. У настоящего программиста понятие "код" существует только в виде "оформленный согласно принятым coding standards со всеми необходимыми комментариями, юнит-тестами и подготовленный к code review". Такое бывает только в IDE.
Код на бумажке бывает только у специалистов по кодированию на бумажках.

___>И заметьте что задачу дают не первокласснику а человеку с техническим дипломом.

Можно еще специалиста-электронщика попросить дроссель намотать. тороидальный. вручную.

___>Если это уже сложно, то может в другую профессию? Или будем на собеседовании таблицу умножения и алфавит спрашивать?

Специалисты по развороту строк на бумажках — это и правда другая профессия, а все пытаются пролезть в нашу.

02.09.2013 17:07, avpavlov пишет:

> Вопрос "что вы знаете про многопоточность" в данном случае просто
> вводное предложение. С этого места надо было вкраце упомянуть
> потоки/семафоры/мутексы/ивенты/итд
Мдас, показательно про многопоточность...

Здравствуйте, avpavlov, Вы писали:

A>Руководитель группы == team lead == техническая специальность. Если ты не владеешь технологиями на одном уровне с группой, как ты будешь руководить?

Руководитель группы это не тимлид в общем случае. А тимлид это не техническая специальность, а оператор багтрекера и карабас-барабас с плеткой. То что на эту роль берут программистов обусловлено лишь желанием протянуть карьерную лестницу для кодеров.

03.09.2013 11:41, UA пишет:

> Хмм, странный вывод
Полностью логичный. Именно этим же в Минске и пользовался, в итоге на
низкую зарплату достаточно легко найти спеца, главное искать того, кто
может задачи предполагаемые делать, а не организовывать экзаменационный
фильтр сотен программистов.

Здравствуйте, landerhigh, Вы писали:

L>Вопрос "какие объекты синхронизации знаете" говорит о том, что задающий этот вопрос о многопоточности читал только в книжках. И последний раз это делал где-нибудь в конце 90-х.

Вопрос "какие объекты синхронизации знаете" — это очень хороший открытый вопрос, который дает возможность собеседуемому на должность тим лида (а не быдлокодера) рассказать целую поэму о современных методах синхронизации, тем самым поразив собеседующих. Не думаешь с такой точки зрения смотреть? Главное во время ответа не "звездеть", вести себя открыто и дружелюбно...

Здравствуйте, smallpoxlet, Вы писали:

D>>И задачака по strrev — это отличная задачка.

S>Во-первых, это задача сложная. Больщинство программистов никогда не пишет такой код с нуля, а пользуется библиотеками.

Просто охренеть... Простите, а что тогда простая задача ?

06.09.2013 22:27, ex-MICEx пишет:

>Или, идя на
> собеседование с вами, все обязаны выучить наизусть ваше резюме?
Вообще-то да, должны.

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

> Ваше
> непомерное ЧСВ не позволяет нормально воспринимать такую ситуацию?
В упор не увидел у ТС, а вот от некоторых, пишущих здесь за контору,
таки да, ЧСВ гигантское.

> Если не залупаться, а идти на сотрудничество и
> снисходительно относиться к некоторым рабочим моментам — можно весьма
> неплохо устроиться.По крайней мере, существенно бОльшую зарплату, чем
> первоначально предлагается, просить точно можно.
А не мог бы ты пояснить, что имеешь в виду под словами неплохо
строиться. Пока я увидел работать за троих и можно попросить зарплату.

Здравствуйте, Vzhyk, Вы писали:

V>Такого программиста нужно или учить или гнать в три шеи.
V>С какого бодуна ты решил, что то что он написал хоть как-то соотносится
V>с задаче?

1. с чего ты взял, что юнит-тест доказывает работоспособность кода в общем случае?
2. что делать с ситуацией когда юнит-тест написать невозможно (невозмонжо в данном случае означает бессмысленно или очень дорого)?
3. как ты проводишь код ревью?
4. ты реально гляда на код не понимаешь, что он делает и не можешь с некоторой степенью вероятность оценить будет он работать или нет?

я понимаю, что ты тут больше на тему поднабросить и потроллить, но будь хоть немного конструктивным или я буду игнорировать твои сообщения.

11.09.2013 11:55, genre пишет:

> непонятно с чего ты вообще взял, что к коду на бумажке нужен юнит-тест.
Если к коду не нужен юнит тест, то грош цена такому коду. Я, например
уже лет 15 такой недокод писать не могу (я не знал тогда, что такие
тесты назовут в будущем юнит-тестами), разучился. Сначала всегда пишу
тест, а потом код, а дальше по мере написания кода корректирую тест.

11.09.2013 12:22, genre пишет:

> То что ты так писать не можешь не значит, что код не покрытый тестами на
> 100% плох. Во-первых тесты не гарантируют работоспособность. Во-вторых
> есть куча задач где написание и поддержка тестов дорога и бессмысленна.
Ты бы так не позорился уже и не мешал все тесты в одну кучу. Хотя, если
у вас основа — гномики, то меня оное не удивляет.
А так да, если код не покрыт юнит-тестами на 99% — это говнокод.
Юнит-тесты пишут сами программисты, во время написания кода.

Здравствуйте, Vzhyk, Вы писали:

V>Не могу понять одного, почему все возможные виды тестирования тут так
V>хотят загнать в юнит-тесты?

потому что изначально речь шла про то, что "не буду писать код strrev на бумажке, потому что юнит-тест к нему не написать", плюс обвинения в говнокоде, только юнит-тесты влияют напрямую на качество кода.

с существованием других видов тестов никто не спорит.

Здравствуйте, Vzhyk, Вы писали:

>> Но это все конечно некомпетентных кадровиков нисколько не оправдывает
V>Я немного не об этом, а об эмоциональной реакции на отказ в стиле: как
V>ты мог нас не возлюбить.
V>И бог с ним, если бы это было только у некоторых недокадровиков, но
V>очень многие здесь такую же точку зрения продвигают в стиле: Если челу
V>не понравилось собеседование, то он безграмотный козел и вообще редиска.

С такой точкой зрения я в общем не согласен. Но апплодировать каждому подобному посту тоже не стоит.
Нужно учитывать как минимум следующее:
1. Постов на тему "Как я прошел собеседование" я что-то не припомню. Может они и были но бурной реакции не вызывали.
А ведь кто-то и проходит даже те собеседования, которые тут всячески критикуют.

2. Посты на тему "Как я не прошел собеседование" в большинстве случаев содержат больше эмоций чем здравого смысла.

3. Собеседование — это не экзамен. Не прошел — это не значит "плохой". Это может значить "хороший. даже очень. но нам сейчас нужен другой"

4. Каждый собеседует как может конечно. Но после нескольких годов собеседования обычно появляются наработки, шаблонные ситуации итд.
Вопросы могут быть очень неожиданными, но то, как они оценены собеседователем — знает только он. Обычно опытный собеседователь не выдает своим поведением свою реакцию. Единственно, где косвенно можно ее узнать — это уточняющие вопросы. Если их нет — ответ уже засчитан. Если есть — ответ в процессе уточнения.
Далеко не все вопросы имеют одинаковый приоритет.
Я например могу задать 10 вопросов и по ответам на пару из них прийму решение. И я думаю что не я один такой
Ведь есть вещи, которым при наличии базовых знаний можно обучить на уровне получасовой лекции, презентации итд.

5. А вот варианты поведения "не буду", "не хочу" многие недооценивают и совершенно зря.
Нанятый кандидат должен не только уметь(что в небольших пределах легко корректируется), но и самое главное _делать_, то что умеет.
В реальной работе подобная фраза от подчиненного — это "избавиться при первой же возможности" и не надо обманывать ни себя ни других.
Правда стоит заметить, что "Давай сделаем по-другому", "В таком варианте не выйдет", "Давай попробуем подкорректировать требования" — это уже совсем другие фразы и с первыми вариантами ничего общего не имеющие.
А собеседование — это исскуственная модель, отображающая многие аспекты реальной работы.

Но в целом я совсем не против обсуждения собеседований и считаю, что это полезно для обоих сторон.

Здравствуйте, landerhigh, Вы писали:

L>Обидели его, заставляют грязной работой заниматься. Тесты писать.

Вы, похоже, даже не читали что он пишет.

L>1. Для функциональных тестов нужно, чтобы система уже функционировала.

Это если у вас система типа "монолит" с единой простынёй от "main(args[])" до "return". На практике это так не всегда.

L>3. Без юнит-тестов невозможен рефакторинг и итеративная разработка. Господа, успокойтесь, то что вы считали рефакторингом, называется иначе: переписывание.

По поводу рефакторинга всё ровно наоборот. Рефакторить хорошо именно с функциональными тестами. В чёрном ящике что-то там изменилось, но функциональные тесты показывают, что всё работает так же как и до. А юнит-тесты половину выкинули, вторая половина — невалидна точно, третью надо глазами посмотреть... Но проще переписать.

L>2. Для обеспечения сравнимого с юнит-тестами покрытия, требуется экспоненциальное количество тестов функциональных. Другими словами — если речь не идет об абстрактной системе в вакууме, прогнать все возможные внутренние сценарии невозможно. Допустим, систма состоит из X юнитов. Для каждого юнита есть три основных тестируемых сценария — на валидных данных, на невалидных данных и на граничных данных. Чтобы покрыть все эти возможные сценарии юнит-тестами, нужно 3*X наборов юнит-тестов. Чтобы добиться такого же покрытия функциональным тестированием (что в общем случае невозможно**), потребуется 3^X тестов. Дерзайте, ребята!

В этом и проблеми юнит-тестов. Они покрывают какую-то абстрактную хрень. Интеграционные тесты покрывают какие-то сценарии, которые скорее всего встретятся. А что покрывают юнит-тесты? Они ловят непонятно что и совершенно не ловят ошибки, возникающие на границе юнитов, при их взаимодействии, а таких ощибок гораздо больше чем.
Модуль пишет и читает, но пишет в одно место а читает из другого... Пишет одно, а читает что-то другое, и вообще оно в другом формате. Ну ошибся программист, неправильно понял, бывает.
Но каждый юнит-функция по отдельности проходит свои тесты. Красота и полный TDD.

У меня вообще солжилось впечатление, что юнит-тесты, которые классичесткие, один тест — один метод, всё замокано и тестируются именно те две строчки в методе придуманы что бы ловить какие-то элементарные ошибки типа описок.

P.S. Кстати типичный прмер секты — это на все неудобные вопросы отвечать "вы ниасилили".

Здравствуйте, sharpcoder, Вы писали:

S>Здравствуйте, Andrusha, Вы писали:

S>Понимаю о ком речь Московская биржа очень хорошая компания, там хорошие условия работы, хорошие сотрудники. Знаю т.к. это один из наших любимых клиентов
1. Московская биржа — большая компания и очень разная. Для кого-то там хорошие условия работы, для кого-то нет, где-то есть текучка. Из айтишников наилучшие условия — у разработчиков ТС. Наихудшие — у ИТ-обслуги. Лично у меня условия были средние — от ТС был весьма далек.
2. Сотрудники там тоже очень разные. По моему, сугубо личному мнению, команда ИТ-менеджеров, которая пришла при Аганбегяне (и после него), некомпетентна. Биржа еще держится на старых ресурсах и кадрах — совсем как нынешняя Россия на технических разработках СССР.
3. Насчет любимого клиента — тут сомнений нет. Бабло платят исправно, а за что платят и действительно ли оно столько стоит — в этом никто не разбирается, ибо некомпетентны. Этим кадрам можно втюхать что угодно, можно даже всучить стандартные компоненты MOSS под видом собственных разработок — проглотят и не заметят.

S>По поводу написанного вами — ну не подошли вы, в чем проблема? Зачем пытаться про них что-то плохое написать? Они же про вас здесь не пишут (а я думаю что взгляд с той стороны может быть куда более интересный)?
Вот здесь полностью с Вами согласен.

Экс-биржевик

Здравствуйте, landerhigh, Вы писали:

L>Здравствуйте, vshemm, Вы писали:


L>>>Это когда "думать некогда, копать надо"? Раз так, не пишите, конечно

V>>Как раз бездумное написание тестов — типичный пример ситуации "думать некогда, копать/трясти надо"
V>>Со всеми вытекающими, ага (например).

L>Высер очередного ниасилившего. Обидели его, заставляют грязной работой заниматься. Тесты писать.

Тоже самое можно сказать и про ваши слова. Чисто из любопытства — неужели это все, что вы реально вынесли с того поста?

L>Функциональные тесты писать тоже можно и нужно. Есть только несколько таких малюсеньких"НО", которые не позволяют забить на юнит-тесты:

Складывается впечатление, что вы не только по ссылкам не ходите, но и не читаете сообщения в этой ветке, даже свои. Речь идет совсем о другом, а именно о 100% незабивании на юнит-тесты. Обязательном незабивании (http://rsdn.ru/forum/job/5293125.1

Автор: vshemm
Дата: 12.09.13

).

L>1. Для функциональных тестов нужно, чтобы система уже функционировала. А от первой строчки кода до запускающейся системы может пройти несколько человеко-лет. Поздно будет тестировать

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

L>2. Для обеспечения сравнимого с юнит-тестами покрытия, требуется экспоненциальное количество тестов функциональных. Другими словами — если речь не идет об абстрактной системе в вакууме, прогнать все возможные внутренние сценарии невозможно.*

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

L>3. Без юнит-тестов невозможен рефакторинг и итеративная разработка. Господа, успокойтесь, то что вы считали рефакторингом, называется иначе: переписывание.

Еще раз, читайте что другие пишут (http://rsdn.ru/forum/job/5291948.1

Автор: vshemm
Дата: 11.09.13

). Для особо одаренных этот пункт не вызывает сомнений.

L>*. Допустим, систма состоит из X юнитов. Для каждого юнита есть три основных тестируемых сценария — на валидных данных, на невалидных данных и на граничных данных. Чтобы покрыть все эти возможные сценарии юнит-тестами, нужно 3*X наборов юнит-тестов. Чтобы добиться такого же покрытия функциональным тестированием (что в общем случае невозможно**), потребуется 3^X тестов. Дерзайте, ребята!

Ну опять бред. Во-первых, с чего вы взяли, что некоторый сценарий можно покрыть юнит-тестом? Пример вам уже приводил (ах, да, вы же не читаете то, что противоречит вашему внутреннему миру..). Во-вторых, откуда взялось 3? На самом деле там некоторое счетное число N (в общем случае, бесконечное). Так что принципиальной разницы в реальных условиях не просто нет, а даже юнит-тесты проигрывают.

L>**. С вероятностью в 99.99% система в своем конкретном условно-стабильном состоянии может не допускать выполнения некоторых внутренних веток кода (они банально отключены). Вероятность того, что в следующем условно-стабильном состоянии блокировка этих юнитов исчезнет, тоже стремится к 1. Делайте выводы.

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

landerhigh, мне надоело "бла бла" если честно, поэтому предлагаю несколько риторических вопросов, разница в ответах по хотя бы одному будет ясно свидетельствовать о фундаментальных различиях в наших мнениях, и, таким образом, ясно покажет бессмысленность дальнейшего разговора про юнит-тесты (все вопросы подразумевают твердое true/false):
1. Правда ли что набор clear тестов (к которым относятся и юнит) не доказывают функционирование программы?
2. Правда ли что набор clear тестов доказывают в лучшем случае только прохождение этих тестов (т.е. ожидаемого поведения только в тех случаях, на которые они запрограммированны)?
3. Правда ли что корректно функционирущий код по определению должен не только делать то что надо, но и одновременно с этим не делать того, что не надо?
4. Правда ли что каждое действие инженера (программиста) должно быть осмысленным (обоснованным)?
4. Правда ли что мозг человека стремится к состоянию с наименьшей энергией?
5. Правда ли что ради денег и п.4 можно вступить в секту и действовать в ее интересах?

Здравствуйте, Vzhyk, Вы писали:

>> Вполне нормальный шаг имхо. И если в ответ будет даже намек на обиду и
>> раздражение — еще один минус собеседующей стороне.
V>Меня как-то хруш одной минской конторки по телефону оскорблял и обзывал,
V>когда я сказал, что они мне не настолько интересны, чтобы тестовое
V>задание для них делать. А ты говоришь раздражение.
V>Хамами себя ведут и наниматели и нанимаемые и зависит это только от
V>конкретных людей, а не от роли в данный момент.

Я не совсем понял слово "хруш", но предполагаю, что Вы имели ввиду кадровика.
А то, что хамское поведение бывает с обоих сторон, так тут чего обсуждать то. Бывает и тут ничего не поделать. Я говорю о своем отношении к этому.
А то мне однажды поздно вечером в подворотне такое сказали... Да бывает.

А насчет тестового задания — это отдельная тема и например мое отношение к ней зависит от очень многих факторов.
Но вкратце примерно так: "Чтобы подняться на ступеньку(любую) надо совершить как минимум лишнее телодвижение".
Те, кто считают потраченные калории и произведенные телодвижения, обычно в самом низу и остаются, постоянно жалуясь на несправедливость бытия.
И это нормально. Имеют право

>> Правда чаще всего кандидат сначала слышит "до свидания" а уже потом
>> заявляет "да не очень то и хотелось"
V>И че?
Ну может информация к размышлению.
Ведь если кандидат устраивает собеседователей, но отказывется продолжать собеседование, то может есть повод проанализировать сам процесс.
Как в том анекдоте "Может в консерватории надо чего подправить?"
А если с ним попрощались потому как не подходит(почему — сейчас не рассматриваем), то и его мнение сами понимаете как важно.

Здравствуйте, hrensgory, Вы писали:

H>Если уж даже я, будучи слесарем по образованию, и то вижу ровно один
H>способ её решения (без аллокации места под новый массив есс-но) — то да,
H>мне непонятно чем это отличается от вышеприведённых примеров.

Не забывай, что простые задачи на собеседовании дают не для того, чтобы понять что-то, а для отсеивания совсес слабых кандидатов.

Очевидно, что каждый собеседующий если он вменяем начинает с собеседование с максимально простой задачи которая еще способна отсеять совсем неадекват.
У каждого собеседующего пул задач вырабатывается со временем. Естественно, что когда есть простая задача которую при этом не решает например 25% кандидатов то интервью всегда начнется с нее. И этого я делаю вывод, что в этом случае у этого собеседующего эту задачу не решают относительно часто.

Но это опыт. Если же человек собеседует раз в полгода и просто не в курсе, то может простим ему эту маленьую слабость, решим за 5 минут и пойдем дальше, к более интересным вещам?

Кроме этого, любая, даже самая простая задача вида "а напишите 5-10 строчек кода" может быть началом разговора как минимум про тесты и про обработку ошибок.

Здравствуйте, vshemm, Вы писали:

V>Оох, двусмысленно высказался. Я имел ввиду не когда априори код говно и его не исправить, а когда функционально нельзя написать идеальный код. Т.е. код идеальный, а тесты написать нельзя.

V>Пример приводил выше, синхронизация. Вот пишите вы стек, скажем, этот алгоритм можно представить как стейт машину. Но программно вы в принципе не сможете пройти через все переходы этой машины, ибо нет софтового способа заставить процессор переупорядочить инструкции. Или на SMP (или NUMA) софтово влиять на алгоритм синхронизации кешей. И т.д. Здесь тесты в принципе нельзя написать, каким бы идеальным код не был. И таких примеров масса.

+1.

Добавлю: или когда результат плохо формализуется и тесты по сложности многократно превосходят собственно код. Дешевле руками запускать и смотреть результат. Таких примеров тоже вагон.

04.09.2013 19:55, Abalak пишет:

> Я например заметил, что далеко
> не каждый программист пишет код для работы с данными и одновременно
> думает об оптимальности,
Вообще-то код должен писаться следующим образом:
1. Пишем, чтобы работало правильно.
2. Рефакторим, чтобы работало правильно и быстро.

Здравствуйте, genre, Вы писали:
__>>да ну будто никто в универе не учился. плохие преподы всегда требуют заученный ответ на свой вопрос не пытаясь даже разобраться в любом другом решении. тут либо выучил, либо нет. так и среди собеседующих сразу видно тех, кто по "паре проверенных вопросов" делает глубокие выводы и тех, кто открыт для разговора.
G>Почему ты собеседующих априори считаешь за придурков? Это такие же программисты как и ты.
у меня история одна была
собеседовался я в одну компанию. компания хорошая, покруче, чем эта биржа. вещами занимаются мощными, задачи сложные. я хотел там работать.
сначала меня собеседовал первый чел (буду называть его чел1). недавно повышенный, самоуверенный, нагловатый. спросил пару вопросов, разочарованно покачал головой и сказал, что нет, такие говенные программисты в их контору не нужны.
но мне неожиданно позвонили еще раз и предложили провести еще одно собеседование в другой отдел. у меня был опыт в одной очень узкой области, которая им, как оказалось, была нужна. собеседовал меня другой чел. постарше первого, мы с ним просто мило поговорили и меня взяли. на меньшую з.п. правда, но в остальном меня все устроило.
чел1, видя меня в офисе, косился, презрительно косился и фыркал по началу, не понимая, зачем такие говнокодеры ихней конторе. прошел где-то год, я заработал какой-то авторитет среди коллег, чел фыркать перестал. потом в результате реорганизации я вдруг попал под его подчинение и мы стали работать совместно. вот когда я уходил, у меня долго и упорно упрашивал остаться, как очень ценного специалиста. это меня вообще веселило.
дело не в том, что собеседующий дураки, а в том, что людей часто интуиция подводит.

Здравствуйте, Andrusha, Вы писали:

A>Собственно, разговор, наверное, нужно начать с того, что предложение о вакансии было предложено через КА и выглядело вполне неплохо. Но не так уже чтобы завораживающие. Решил посмотреть. Теперь есть что рассказать.

Вполне нормальный подход. Ты вопросы про гору Фудзи ждал или гномиков? Именно таким и должно быть интервью, на мой взгляд. Обсудить опыт плюс пара простых вопросов, что бы отсеять совсем неадекватных.

Здравствуйте, avpavlov, Вы писали:

A>>Опыт чего? Вакансия, обращаю внимание, "руководитель группы". Вопросы я ожидаю примерно о том, как руководить группой. Да, можно задать вопросы по технической части, но не уровня "слышали ли вы про многопоточность", а на уровне архитектуры проекта. Можно обсудить нюансы реализации тех или иных библиотек, чтобы понять какие человек использовал или как принимает решения. И так далее.

A>Руководитель группы == team lead == техническая специальность. Если ты не владеешь технологиями на одном уровне с группой, как ты будешь руководить?

Не вопрос, что придётся писать код. Это как бы даже и не обсуждаться. Обсуждается уровень вопросов. Я может в каком-то странном мире живу, но мне кажется, что любой человек программирующий на С++ под Windows в районе 12 лет знает что такое многопоточность. Впрочем, я даже готов что это надо как-то уточнить. Но 30 минут рассказов до этого о проектах в которых явно более чем один поток — это к чему? Поговорить?

A>Ты может попутал "руководитель группы" и "руководитель проекта"? Хотя я сам сторонник того, что руководитель проекта в технологиях тоже должен понимать.
Речь не о том.

Здравствуйте, Andrusha, Вы писали:

A>Дальше перешли к "технической" части. Ладно, вопрос чем отличается map от vector можно ещё отнести к разогревочным. Но что люди ожидают услышать на вопрос "слышали ли о многопоточности?". Или ещё лучше "Какие объекты синхронизации Вы знаете?". Нет, с одной стороны вопросы вполне корректны (а чего не спросить-то?), но с другой стороны никак не соответствуют не заявленной вакансии, ни опыту кандидата. Ну, ладно. Далее вопрос, который поставил меня в тупик: "Какие типы эвентов бывают?". Щито?!

Нормальные вопросы, меня в каспере вообще по всему рихтеру прогнали, кроме пожалуй фиберов и ничего, не жалуюсь. Знать какие бывают типы евентов win программер обязан.

Здравствуйте, smallpoxlet, Вы писали:

S>Дело даже не столько в опыте, сколько в том что уже давно появились алгоритмы позволяющие обходиться практически без синхронизаций. Мои программисты даже придумали задачку: дают кусок многопоточного кода и просят переписать вообще без использования синхронизаций но так чтобы код остался потокобезопасным. Все эти мьютексы и семафоры уже никому не интересны, и если про них спрашивают на собеседовании значит контора застряла по технологимя а 90-х.

Нельзя код с блокировками вот так просто взять полностью и заменить на lockfree код т.к. lockfree код обычно по производительности хуже кода с блокировками. Стоит всё таки подучить матчасть, каждый тип многопоточного/параллельного подхода для своих задач.

Здравствуйте, Andrusha, Вы писали:

A>... если это базовые вещи, то тогда начинайте с них, раз это уже так сильно важно (очень сомневаюсь). А если за 60 минут не удалось даже выяснить умеет ли писать человек код, то как это можно назвать?

Ну как минимум 30 минут из этих 60 отнял у них ты сам. Никто, никогда не ожидает на собеседовании монолога о себе в течении 30 минут. Тут надо укладываться а 5, максимум 10 минут и уметь заострить внимание на сильных сторонах. По собственному опыту скажу, что наговорить просто так с наскоку очень сложно, к такой мини-презентации нужно готовиться.
.

Здравствуйте, landerhigh, Вы писали:

L>ЕМНИП, торговый движок мамбы разработан одной сиднейской компанией. Удивлюсь, если они его сами ковыряют.
ПВНИ — действительно, австралийцы около 20 лет назад сделали систему и передали ее бирже. С исходными кодами — таково было условие. Еще работают на бирже люди, летавшие в загран.командировку в Австралию. А теперь все-таки придется удивиться — уже полтора десятилетия система развивается без участия австралийцев.

L>Хорош пальцы гнуть. Ну недополучит пара типа инвесторов чего-нить, беда какая. Тут вон люди пишут код, перед сдачей которого всерьез просчитываются вероятность наличия бага, который может привести к открытию не той заслонки не в том трубопроводе не в то время, в результате чего будет выброшен не тот газ и не туда и жители близлежащей деревни выблюют собственные кишки.
Были сбои, люди конкретно попадали на баблосы. Были серьезные предъявы бирже. Как урегулировали — не знаю.

L>Кстати, вопрос об объектах синхронизации от сотрудника подобной компании навевает на невеселые мысли.
Ядро ТС написано на ANSI C. Не думаю, что старый код, использующий примитивы синхронизации, бывшие эталоном 20 лет назад, кто-то рискнул серьезно "потрогать".

Экс-биржевик

Здравствуйте, Andrusha, Вы писали:

A>Не, прикол с типизацией эвентов, конечно, может бросить тень, но в любом случае это скорее из забавного.

Ага, смешной прикол.

A>Я тоже вектор с листом перепутал (не использую их).

И ещё один прикол! А ты прикольным был бы техлидом...

04.09.2013 20:46, landerhigh пишет:

> А вот это можно и нужно выяснять псевдокодом или квадратиками.
А надо-ли тебе эта оптимизация, если код используется один раз в 100 лет
и единственное требование, он должен работать правильно.

Просто я очень часто видел, когда программист оптимизирует то, что не
надо, зато в тех частях систем, где нужна оптимизация его не видно.
Оптимизация имеет смысл только после того, как бизнес поставил такую
задачу и провели профилирование.

Здравствуйте, UA, Вы писали:

UA>>>Если текущая ЗП значительно выше рынка то штудировать переворот строки чтобы получить в итоге предложение на еще меньше денег как то глупо.
A>>Она не будет выше рынка, если только работодатель не занимается благотворительность. Человек ведь от него и так никуда не денется.
UA>Это относится только к винтикам, а начальник отдела может получать выше рынка и за другие заслуги перед компанией и понятно что другой компании на эти заслуги будет наплевать поэтому они скорее всего предложат даже меньше чем есть сейчас.

От себя добавлю, что начальник, получающий "по рынку" — это лох. Настоящий начальник должен уметь организовать себе доход, не зависящий от рынка. Равно как и от жизни конторы, к-рую он при необходимости может поменять.

On 09.09.2013 15:03, genre wrote:

> не понимаю какой из этого можно сделать вывод, кроме того, что многие не
> могут решить простую задачу.

Мне вот неясно почему интервьюеры, собеседующие людей на позицию
тимлида/архитектора начинают сразу с такой высокоуровневой задачи. Им бы
сначала убедиться, что подопытный умеет самостоятельно и качественно
вытирать себе жопу, потом небольшой диктант на "жи-ши пишется через и",
решение квадратного уравнения, проверка знания столицей чего является
Канберра. Потом уж только выдавать бумажку для написания переворота строки.

Просто прикиньте на себя — стали бы вы выполнять тестовые задания по
приведённому выше списку, и если нет — то почему?

--
WBR,
Serge.

Здравствуйте, Vzhyk, Вы писали:

>> непонятно с чего ты вообще взял, что к коду на бумажке нужен юнит-тест.
V>Если к коду не нужен юнит тест, то грош цена такому коду. Я, например
V>уже лет 15 такой недокод писать не могу (я не знал тогда, что такие
V>тесты назовут в будущем юнит-тестами), разучился. Сначала всегда пишу
V>тест, а потом код, а дальше по мере написания кода корректирую тест.

То что ты так писать не можешь не значит, что код не покрытый тестами на 100% плох. Во-первых тесты не гарантируют работоспособность. Во-вторых есть куча задач где написание и поддержка тестов дорога и бессмысленна.

Здравствуйте, landerhigh, Вы писали:

L>Сушествует очень малое, практически бесконечно малое количество случаев, когда юнит-тест написать невозможно. Более чем уверен, что собеседовать программистов, разрабатывающих такие системы, тебе не придется.

Ну написать юнит-тест, действительно, можно практически к любой функции. Но смысл этот юнит-тест имеет отнюдь не всегда.

L>Мои наблюдения показывают, что на реальных проектах от подобных персонажей ничего, кроме вреда, не бывает.

А мои показывают, что корреляции нет. У кого наблюдения длиннее?

Здравствуйте, Vzhyk, Вы писали:

V>А так да, если код не покрыт юнит-тестами на 99% — это говнокод.
V>Юнит-тесты пишут сами программисты, во время написания кода.

Я тебе больше скажу. код покрытый тестами на 100% тоже очень часто говнокод. Вывод — вообще почти весь код — говнокод.

Здравствуйте, vshemm, Вы писали:

V>Здравствуйте, __kot2, Вы писали:

__>>Здравствуйте, vshemm, Вы писали:
V>>>Ситуаций, когда юнит-тестирование бесполезно или вообще невозможно — масса. Пример невозможности вообще написать юнит-тесты я приводил в этой ветке выше.
__>>таких случаев д-но масса
__>>легко написать код, который невозможно тестировать

__>>но да, это будет говнокод

V>Можно, но речь о другом. О коде, на который либо неэффективно писать тесты, либо невозможно. Такого кода много.

Оох, двусмысленно высказался. Я имел ввиду не когда априори код говно и его не исправить, а когда функционально нельзя написать идеальный код. Т.е. код идеальный, а тесты написать нельзя.

Пример приводил выше, синхронизация. Вот пишите вы стек, скажем, этот алгоритм можно представить как стейт машину. Но программно вы в принципе не сможете пройти через все переходы этой машины, ибо нет софтового способа заставить процессор переупорядочить инструкции. Или на SMP (или NUMA) софтово влиять на алгоритм синхронизации кешей. И т.д. Здесь тесты в принципе нельзя написать, каким бы идеальным код не был. И таких примеров масса.

Здравствуйте, vshemm, Вы писали:


L>>Сушествует очень малое, практически бесконечно малое количество случаев, когда юнит-тест написать невозможно. Более чем уверен, что собеседовать программистов, разрабатывающих такие системы, тебе не придется.

V>Ситуаций, когда юнит-тестирование бесполезно или вообще невозможно — масса. Пример невозможности вообще написать юнит-тесты я приводил в этой ветке выше.

Их примерно два. Называются "некомпетентность" и "лень".

А те случаи, что ты приводил не входят в зону ответственности юнит-тестов.

Здравствуйте, Vzhyk, Вы писали:

V>Не могу понять одного, почему все возможные виды тестирования тут так
V>хотят загнать в юнит-тесты? И на основе этой странной фантазии пытаются
V>утверждать о невозможности написания юнит-тестов на 99% кода.
V>Просьба к вам, почитайте еще раз книжки по TDD.

Кучу раз было сказано, что бывают случаи, когда юнит-тестирование неэфективно(по разным причинам), надо исспользовать другие тесты. И каждый раз в ответ "нет, только юнит-тесты, только хардкор"

Сам загоняет, сам объявляет это фантазиями и сам же спрашивает "почему?"
Высший пилотаж тролинга.

Здравствуйте, Andrusha, Вы писали:

A>>>"Это ваши проблемы" (один известный персонаж). Меня как соискателя это несколько не колышит кто к ним приходит.
A>На данном этапе времени это не моя команда и поэтому решать ли мне проблемы людей, которых я вижу в первый раз жизни вопрос открытый.
A>И ещё. Возможно, я бы написал эту функцию, но на ноутбуке. На листочке мне это делать неудобно...
A>У них мой телефон был, у меня — нет.

Ленив, привередлив, эгоистичен. Чуть что ищет не решение, а оправдание. Ну что ж, это жизнь — бывает...

Здравствуйте, genre, Вы писали:

G>Здравствуйте, 1303, Вы писали:

G>>>если бы эта аналогия была верна, я бы даже согласился с тобой. Но мне пока не доводилось встречать программиста в ежедневной работе которого не встречалось бы задач вида "написать 10 строчек кода реализующего несложный алгоритм".
1>>Ты забыл добавить "на бумажке".

G>еще раз поинтересуюсь, чем написание 10 срок на бумажке отличается от 10 строк в иде. только придумай что-нибудь новое, про юнит-тест этих 10 строк и автокомплит слова for тут уже отвечали.

Я попробую. Мой ответ — "Так никто не делает. Это никому не нужно. Это неудобно. Это идиотизм.".
Но, безусловно, моё мнение — заранее предвзято. Советую обратиться к независимым специалистам. Просто выйди из подъезда, подойди к лавочке и задай вопрос бабульке — "Что нужно программисту для работы?, варианты ответа — 1)Бумажка, 2)Компьютер, 3)Посраться на форуме" (можешь добавить свои варианты).

Здравствуйте, landerhigh, Вы писали:

L>Здравствуйте, Undying, Вы писали:

U>>Здравствуйте, landerhigh, Вы писали:

L>>>Сушествует очень малое, практически бесконечно малое количество случаев, когда юнит-тест написать невозможно. Более чем уверен, что собеседовать программистов, разрабатывающих такие системы, тебе не придется.

U>>Зато существует бесконечно большое количество случаев, когда писать юнит-тесты невыгодно.

L>Это когда "думать некогда, копать надо"? Раз так, не пишите, конечно

Как раз бездумное написание тестов — типичный пример ситуации "думать некогда, копать/трясти надо"
Со всеми вытекающими, ага (например).

Здравствуйте, vshemm, Вы писали:


L>>Это когда "думать некогда, копать надо"? Раз так, не пишите, конечно

V>Как раз бездумное написание тестов — типичный пример ситуации "думать некогда, копать/трясти надо"
V>Со всеми вытекающими, ага (например).

Высер очередного ниасилившего. Обидели его, заставляют грязной работой заниматься. Тесты писать.

Функциональные тесты писать тоже можно и нужно. Есть только несколько таких малюсеньких"НО", которые не позволяют забить на юнит-тесты:
1. Для функциональных тестов нужно, чтобы система уже функционировала. А от первой строчки кода до запускающейся системы может пройти несколько человеко-лет. Поздно будет тестировать
2. Для обеспечения сравнимого с юнит-тестами покрытия, требуется экспоненциальное количество тестов функциональных. Другими словами — если речь не идет об абстрактной системе в вакууме, прогнать все возможные внутренние сценарии невозможно.*
3. Без юнит-тестов невозможен рефакторинг и итеративная разработка. Господа, успокойтесь, то что вы считали рефакторингом, называется иначе: переписывание.


*. Допустим, систма состоит из X юнитов. Для каждого юнита есть три основных тестируемых сценария — на валидных данных, на невалидных данных и на граничных данных. Чтобы покрыть все эти возможные сценарии юнит-тестами, нужно 3*X наборов юнит-тестов. Чтобы добиться такого же покрытия функциональным тестированием (что в общем случае невозможно**), потребуется 3^X тестов. Дерзайте, ребята!
**. С вероятностью в 99.99% система в своем конкретном условно-стабильном состоянии может не допускать выполнения некоторых внутренних веток кода (они банально отключены). Вероятность того, что в следующем условно-стабильном состоянии блокировка этих юнитов исчезнет, тоже стремится к 1. Делайте выводы.

Здравствуйте, Abalak, Вы писали:

A>Здравствуйте, Vzhyk, Вы писали:

>>> Я например заметил, что далеко
>>> не каждый программист пишет код для работы с данными и одновременно
>>> думает об оптимальности,
V>>Вообще-то код должен писаться следующим образом:
V>>1. Пишем, чтобы работало правильно.
V>>2. Рефакторим, чтобы работало правильно и быстро.

A>Не должен. Сразу не судьба? А то обычно на второй пункт времени не остается и получается откровенное дерьмо...

Конечно судьба. Если знаешь, как написать "чтобы работало правильно и быстро", то так и пишешь, надо исключать пессимизацию. Но речь скорее идет про преждевременную оптимизацию. В качестве примера пара статей из книги Саттер Г. — "Стандарты программирования на С++. 101 правило и рекомендация":



8. Не оптимизируйте преждевременно

9. Не пессимизируйте преждевременно

Здравствуйте, genre, Вы писали:
G>Ну и чтобы не опираться на интуицию, грамотные собеседующие со временем вырабатывают некий алгоритм, корреляция которого известна и после получаса разговора уже могут делать выводы. Например в одной
конторе на входе давали совершенно идиотский тест, с вопросами уровня чему равно 2х2 и где на клавиатуре пробел, но каким бы идиотским он не был по нескольким сотням интервью за сколько-то лет было видно, что если человек не набирает больше ХХ% в этом тесте, то он точно не пройдет собеседование.
как известно — "какой вопрос, такой и ответ"
собеседование это обоюдный процесс.
не только смотрят что за человек, но и человек смотрит, что за команда. бессмысленно рассказывать всем о крутизне работы в компании, а потом задавать идиотские вопросы.
то есть как бы на самом деле ничего плохого в этом нет. это просто характеризует компанию и критерии набора сотрудников. если компания набирает людей спрашивая про гномиков и глобус Украины, но значит, там и работают большие специалисты в этих вопросах. конечно нет смысла работать в такой компании, если конечно не хочется усовершенствоваться в этих вопросах ну или просто нужна любая работа работать.

Здравствуйте, genre, Вы писали:
G>Человек пришел на собеседование, то есть заинтересовался вакансией,
во-первых, он заинтересовался несколькими компаниями и вакансиями, у него есть выбор

G>узнал что-то о компании в которую пришел, погуглил там, на форумах пошарил,
тут часто инфы очень мало или она устаревает из-за ротации кадров. а в случае больших компаний вообще сложно что-то сказать, отделы ведь такие разные. вот, есть, например, Яндекс. это хорошая компания или плохая? да кто ее знает, я так и не понял, пока сам не придешь не посмотришь и непонятно.

G>потратил время, компания, задачи
про задачи обычно ничего не известно. и я лично предпочитаю выбирать команду, а не компанию и задачи.

G>и деньги его предварительно устраивают.
вилка обычно достаточно широка (а в некоторых компаниях ее вообще не говорят), до начала собеседования еще неизвестно предложат ли нижнюю ее границу или верхнюю — тут, в общем, тоже часто наугад идешь.

G>и он сознательно заваливает собеседование из-за того, что ему дали задачку решать которую он считает ниже своего достоинства?
а приходишь и видишь людей, которые тебя спрашивают про гномиков. фу, думаешь, придурки какие-то, нашли о чем поговорить. и сваливаешь.

причем тут достоинство? если бы дело было в школе и нужно было там рассказать о решении таких задачек, конечно я бы и рассказал бы и показал все с большим удовольствием. просто если эти вопросы лучшее, что они могут придумать, то даже если компания замечательная, то создается ощущение, что ты пришел в "придурошный отдел" (а такие кунсткамеры есть в любой компании, где хотя бы пара десятков человек набирается), и сомневаешься, а стоит ли с такими людьми вообще связываться.

Здравствуйте, robin_of_the_wood, Вы писали:

_>>Я можно также отвечать на собеседованиях?

___>Нельзя.

Почему тогда так отвечаешь? У тебя собеседование — это односторонний допрос твоих собеседников?

_>>На требование конструктивности ответа требовать конструктивность самого вопроса или задачи. Это проявление обиды?

___>Нет. Это не проявление обиды.
___>Это простая логика. Я не требовал конструктивности вопроса. Я попросил дополнительную информацию.
___>Для конструктивного ответа нужно понимать цель вопроса. Пример приводить не буду. Они Вам, как показала практика, не помогают

Ты потребовал конструктивности вопроса: как и почему возник этот вопрос.

Цель вопроса — узнать твой психологический портрет, за одно поговорить по душам о конструктивизме, логике (булевой, нечеткой, квантовой, какие там еще логики бывают?). Должны ли правила игры действовать на всех или кто-то может трактовать их по своему.

Так как ты специалист по эмоциям и психологии команды, то думаю ты легко мог увидеть в этом вопросе психологический тест. Мог бы конструктивно рассказать. Было бы интересно узнать как сами психологи интерпретируют результаты психологических тестов.

_>>И можно ли во время собеседования пользоваться помощью зала?
___>Нет.

А почему мне советуешь провести референдум. Вопрос был задан тебе.

_>>за неконструктивный ответ.

___>А я еще не отвечал ничего. Я задал уточняющий вопрос.

Какой еще уточняющий вопрос? Ты даже не выбрал понравившуюся фигуру. Зачем тебе подсказка когда требуется твое чисто субъективное мнение? У тебя есть свое мнение?

Все хватит с меня. Можешь не отвечать. Сдаюсь.

Здравствуйте, Vzhyk, Вы писали:

V>А то с опытом начинаешь понимать, что где-то многопоточность необходима,
V>а где-то вредна и проекты длятся не по 3 месяца, а по 3-5-7 и более лет.

Дело даже не столько в опыте, сколько в том что уже давно появились алгоритмы позволяющие обходиться практически без синхронизаций. Мои программисты даже придумали задачку: дают кусок многопоточного кода и просят переписать вообще без использования синхронизаций но так чтобы код остался потокобезопасным. Все эти мьютексы и семафоры уже никому не интересны, и если про них спрашивают на собеседовании значит контора застряла по технологимя а 90-х.

V>Кстати, подобным страдают в основном на програмерских собеседованиях, почему-то.

Потому что в программисты идут интроверты которых в детстве не научили нормально общаться.

Здравствуйте, robin_of_the_wood, Вы писали:

___>Здравствуйте, fin_81, Вы писали:

_>>На сколько формализован процесс поиска работы/работника?

___>Меня лично такие глобальные данные никогда не интересовали.
___>Но с теми людьми, в выборе которых я принимал участие, проблем у меня ни разу не было.

То есть твой (можно на ты?) личный опыт — это твой личный опыт и ничего больше. Другие люди/фирмы могут применять твои методы на свой страх и риск. Все твои рекомендации — это чуть приукрашенная биография.

___>Я принимал участие в собеседованиях в разных компаниях и организация этого процесса очень зависела от конкретной компании.
___>Иногда я мог выбирать метод проведения, иногда нет. Иногда я собеседовал один, иногда в составе группы из нескольких человек.
___>Но всегда была возможность некоторого влияния на процесс.
___>Сейчас от меня требуют только вердикт в виде "да/нет" руководствуюясь простым правилом "Тебе с ними работать. Решай сам"
___>То есть я в принципе могу воспользоваться Вашим советом
___>Но вот, если честно, ни разу не было такого желания.

У меня есть подозрение что тебя используют как биологический /dev/random: "могу так, могу этак, а могу вообще ничего не делать, как повезет".

Но это мое субъективное мнение, мой личный опыт. Поэтому не смею рекомендовать для повсеместного использования.

Здравствуйте, robin_of_the_wood, Вы писали:

___>Вот почти реальный пример:
___>Есть два разработчика неплохого уровня но работающих в провинции. Им обоим предлагают удаленку но с тестовым заданием.
___>Первый программист подсчитывает время, перемножает на хороший рейт и гневно заявляет — фиг вам! Это же все равно, что я вам эти деньги подарил.
___>А второй, думая так-же, молча делает задание, получает работу и делая то-же самое удваивает свой месячный заработок.
___>Кто в результате выиграл по деньгам?

Я здесь вижу способствование паразитизма. Берем человека, который решает надуманные проблемы чужой фирмы скорее всего в рабочее время. Зато он умеет показывать правильные эмоции своему работодателю, подлизываться.

___>Конечно, возможно и другое развитие сюжета. Но в общем случае идея надеюсь понятна.
___>И кроме того я нисколько не критикую действия первого разработчика из примера. У него такая стратегия — и это его выбор.
___>Я лишь хотел напомнить про существование иной стратегии, которая тоже достойна упоминания

Стратегии разные нужны, стратегии разные важны. Только вот так и не понял как оценивать эти стратегии. По мне все одинаково эффективны, просто выбор зависит от настроения и эмоций работодателя и работника: хочет ли он заморочиться над придумыванием или решением искусственных проблем.

Может задания давать не исскуственные? Хоть как-то будут практиковаться в постановке реальных задач и их решении.

Здравствуйте, Vzhyk, Вы писали:


>> Еще раз, медленно и по буквам. У настоящего программиста понятие "код"
>> существует только в виде "оформленный согласно принятым coding standards
>> со всеми необходимыми комментариями, юнит-тестами и подготовленный к
>> code review". Такое бывает только в IDE.

V>В качестве IDE и notepad пойдет, но про код я с тобой согласен на 146%.

Да пофиг что, лишь бы шрифт был моноширинный и раскладка клавиатуры была общепринятой. И не emacs

V>А на собеседовании можно накорябать нечто, имеющее очень отдаленное
V>отношение к коду.

Вообще, абстрактные рассуждения о переворотах сферических строк в вакуумах разбиваются о суровую реальность ежедневной работы, когда приходится брать плетку, чтобы таки заставить нерадивых коллег писать комментарии и тесты и в принципе следовать единому стандарту оформления кода.

Здравствуйте, neFormal, Вы писали:

___>>Тут ведь нужно всего лишь закодить интуитивно понятный алгоритм, а это после многолетней практики рука уже сама пишет

F>а кто тут много лет практикуется в написании strrev?

Практикуются в написании кода. И этого вполне достаточно, чтобы такой простой алгоритм реализовать на уровне автоматизма.
Ну strlen я думаю и школьник любой напишет. А тут ну совсем немножечко посложнее.
Или для этого уже нужно много лет тренировки?

Здравствуйте, smallpoxlet, Вы писали:

M>>Кстати финансово вы практически гарантированно прогадали.

S>Ой не факт. Даже если сегодня они заплатсят больше, в долгосрочном плане все равно будет невыгодно.

Это после педаления движка биржи? Ню-ню.

Здравствуйте, alzt, Вы писали:

A>Здравствуйте, sharpcoder, Вы писали:

S>>По поводу написанного вами — ну не подошли вы, в чем проблема? Зачем пытаться про них что-то плохое написать? Они же про вас здесь не пишут (а я думаю что взгляд с той стороны может быть куда более интересный)?

A>Тебе процесс их отбора нравится?

О процессе отбора ничего не знаю, знаю тех кто его прошел — адекватные

Здравствуйте, landerhigh, Вы писали:

L>Реальная работа состоит в создании программного продукта. Она состоит из множества отдельных областей знаний, но ни одна из них не требует навыков программирования на бумажках.

Работа состоит из задач а не из областей знаний.
Навыков программирования именно на бумаге не существует.
Есть навыки просто программирования. Ну у одних есть а у других соответственно нет. А уж на бумаге ручкой писать все в школе учились.
Поэтому написание _элементарных_ конструкций на бумаге по памяти проверяет именно навыки программирования.
И если их нет то ни IDE ни юнит тесты ни код ревью не помогут.

Это как если Вы попросите навигатор чтобы дойти от своей остановки до своего дома — то вы видимо только вчера переехали.
Многократное повторение некоторых операций просто доводит их до автоматизма. И программирование не исключение.

А пользование vi-ем(или чем другим) совсем ничего не говорит об уровне программиста.
Я встречал людей виртуозно владеющих этим делом, но очень посредственных программистов.
Мне даже показалось, что у них голова под завязку забита командами vi(чем они очень гордятся) а вот для программирования там уже места не осталось

Здравствуйте, alzt, Вы писали:

A>В целом согласен, но ведь самое главное — в большинстве мест требуется именно то, что ты делал. Т.е. ты отлично справишься с работой, но ASP.NET не знаешь, поэтому собеседование вряд ли пройдёшь. И потеряет работодатель, т.к. тут уже случай, когда язык программирования становится не важен.

Все-таки ASP.NET это не синтаксис, а технология и тут важны количество грабель, кототрые человек уже встречал и способен обойти за минимальное количество времени, как собственно и в WPF и много где еще. С опытом приходит понимание процессов и количество грабель даже в незнакомой ситуации снижается. Вот тут и нужно работодателю найти золотую середину и понять, кто его устроит. Так что об однозначной потере говорить нельзя.

Здравствуйте, __kot2, Вы писали:

__>причем тут достоинство? если бы дело было в школе и нужно было там рассказать о решении таких задачек, конечно я бы и рассказал бы и показал все с большим удовольствием. просто если эти вопросы лучшее, что они могут придумать, то даже если компания замечательная, то создается ощущение, что ты пришел в "придурошный отдел" (а такие кунсткамеры есть в любой компании, где хотя бы пара десятков человек набирается), и сомневаешься, а стоит ли с такими людьми вообще связываться.

Прикол заключается в том, что если поискать по форуму обсуждения собеседований, то окажется, что по мнению форума абсолютно все вопросы на собеседовании — идиотские.
тестовое задание давать — да вы офигели, платите за него.
тесты на входе — я че лох какой-то тесты решать
код на листочке — нет я без иде не могу 10 строк написать, а без тестов так и вообще.
поговорить про винапи — че я вам мсдн какой-нить.

ну и так далее.

И что же получается? У каждого из нас есть свои нелюбимые вопросы, свое мнение о том как проводить собеседование, свои обиды на "меня не так поняли, зря меня не взяли итд".
Но разве это повод считать всех кто задает плохие на твой взгляд вопросы "придурошными"?
Вон по мнению Вжика вообще все кто задает вопросы придурки.

Ты бы сам хотел работать в компании где набирают не задавая вопросов? Да уж лучше гномики пускай.

Здравствуйте, landerhigh, Вы писали:

L>Сушествует очень малое, практически бесконечно малое количество случаев, когда юнит-тест написать невозможно. Более чем уверен, что собеседовать программистов, разрабатывающих такие системы, тебе не придется.

Зато существует бесконечно большое количество случаев, когда писать юнит-тесты невыгодно.

Здравствуйте, Andrusha, Вы писали:

Им скорее всего нужен был тим лид который бы мог помочь или заменить разработчика в трудный час и который бы сам участвовал в разработке когда не нужно никем управлять.
P.S. Все должны писать код бл@#$

A>Не вопрос, что придётся писать код. Это как бы даже и не обсуждаться. Обсуждается уровень вопросов. Я может в каком-то странном мире живу, но мне кажется, что любой человек программирующий на С++ под Windows в районе 12 лет знает что такое многопоточность. Впрочем, я даже готов что это надо как-то уточнить. Но 30 минут рассказов до этого о проектах в которых явно более чем один поток — это к чему? Поговорить?

Вопрос "что вы знаете про многопоточность" в данном случае просто вводное предложение. С этого места надо было вкраце упомянуть потоки/семафоры/мутексы/ивенты/итд

Рассказа о проектах не всем достаточно, чтобы убедиться в твоей профессиональных знаниях, потому что непонятно как отличить тех кто делал от тех кто рядом сидел.

Здравствуйте, avpavlov, Вы писали:


A>>Не вопрос, что придётся писать код. Это как бы даже и не обсуждаться. Обсуждается уровень вопросов. Я может в каком-то странном мире живу, но мне кажется, что любой человек программирующий на С++ под Windows в районе 12 лет знает что такое многопоточность. Впрочем, я даже готов что это надо как-то уточнить. Но 30 минут рассказов до этого о проектах в которых явно более чем один поток — это к чему? Поговорить?

A>Вопрос "что вы знаете про многопоточность" в данном случае просто вводное предложение. С этого места надо было вкраце упомянуть потоки/семафоры/мутексы/ивенты/итд
Опять не о том речь. Вы случайно не один из тех 4-х незнакомцев?

Да, кстати, вы зря переиначили вопрос про многопоточность.

A>Рассказа о проектах не всем достаточно, чтобы убедиться в твоей профессиональных знаниях, потому что непонятно как отличить тех кто делал от тех кто рядом сидел.
Да может я и про мьютексы с ивентами прочёл/услышал, но сам их никогда в глаза не видел. В чём разница-то? Выучить страничку из msdn всяко проще, чем рассказывать о проекте к которому не имеешь никакого отношения.

Если человек занимался проектам (проектировал, программировал), то в разговоре это сразу станет ясно. Можно спросить о каких-то нюансах, сложностях, подробности реализации какой-то части. Да просто в лоб: "что вы использовали для того-то?".

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Здравствуйте, Andrusha, Вы писали:

SVZ>>>Мне доводилось собеседовать программистов с 10-летним стажем без навыка программирования и не имеющих представления о многопоточности. Как умудрились столько продержаться — (возможно сопровождали чужой код с минимальными правками).
SVZ>>>Так что такие вопросы вполне уместны.

A>>Программисты без навыка программирования — звучит забавно.

SVZ>Ничего забавного, на самом деле.
SVZ>Мне, например, пару раз приходилось вносить изменения в проект на ASP.NET. При этом ASP я видел впервые в жизни И, думаю, что на собеседовании я имел бы такой же вид, как и те, кого я собеседовал.

Опыт программирования же есть, да? Фреймворк, язык — это уже вторично в такой формулировке.
Так что пример не удачен. Да и даже в этом случае правки же были не деструктивны, а полезны? То есть ничего страшного не произошло?

A>>Правда, в таком случае на такие собеседования надо со своей раскладушкой приходить и запасом еды на несколько дней. Зато работодатель будет уверен, что нанял настоящего профессионала: и комментарии без ошибок напишет (проверочные вопросы; "Как комментарии обозначаются в исходном коде? А чем отличаются?") и даже файл сохранить сможет (проверочные вопросы "Как выглядит иконка сохранения файла? А что на ней изображено? А что это?").

SVZ>А напрасно юродствуешь. Если ты "в теме", то развить беседу и перевести ее в нужное русло труда не составит. Тебе это было неинтересно, поэтому вы остались каждый при своем интересе.

Это опять сводиться к "а поговорить". Да, это не интересно. Если у собеседующих людей время собеседования — это оплачиваемое рабочее время и они находятся на рабочем месте, то для соискателя это простой в работе (не важно фриланс ли это или работа в другом месте). Поэтому когда собеседования перетекают в русло "а вы видели указатели? А как они выглядят?" по вине потенциального работодателя, то никакого желания продолжать беседу с ним возникает. Именно об этом и было первое сообщение.
Если же люди хотят поговорить "за жизнь" "за программирование", то это называется как угодно, но не собеседование. И в данном случае, как это не удивительно, проблемы что к ним приходят люди не умеющие программировать меня абсолютно не волнуют. Пусть составляю более качественные предложения о вакансии, разговаривают по телефону — в общем, решают свою проблему каким угодно способом, но без меня. Именно об этом я хотел предупредить других соискателей в первом сообщении.

Здравствуйте, Andrusha, Вы писали:

A>В WinAPI нет типов эвентов.

Т.е. евенты с ручным/авто сбросом никак не могут быть разделены на два разных типа? Вы филолог или программист?

Здравствуйте, sysenter, Вы писали:

S>Здравствуйте, Andrusha, Вы писали:

A>>В WinAPI нет типов эвентов.

S>Т.е. евенты с ручным/авто сбросом никак не могут быть разделены на два разных типа? Вы филолог или программист?

Могут, но зачем? Это всего лишь один флаг задаваемый при создании объекта. Например, на мой взгляд, именованный или не именованный эвент — и то более логичная классификация. Но даже в ней я не вижу смысла. Тем более что, в msdn такой классификации нет. Зачем плодить сущности да ещё спрашивать об этом на собеседовании?

И всё таки вопрос: зачем и откуда такая классификация? Ответите?

Здравствуйте, Andrusha, Вы писали:

A>Собственно, разговор, наверное, нужно начать с того, что предложение о вакансии было предложено через КА и выглядело вполне неплохо. Но не так уже чтобы завораживающие. Решил посмотреть. Теперь есть что рассказать.

А теперь пара слов от человека работавшего там на аналогичной должности в течении пары лет.
Судя по описанию, речь шла о Си. Насколько я понимаю, речь идет о торговом движке ММВБ либо о чем-то с РТС (я ушел до слияния).
При приеме на не рядовые позиции на бирже смотрят с одинаковым весом как на технические скилы, так и на психологические. Если вы показали "звездочку" — вас вряд ли возьмут, там работать надо, а не пальцы распускать веером. Даже если и ваша фамилия — Александреску. Тем более, если речь идет о торговом движке — если там что-то слетит, биржа автоматом попадает в новости и нервы там нужны железные.

Кстати финансово вы практически гарантированно прогадали.

Больше писать на эту тему ничего не буду.

Здравствуйте, Andrusha, Вы писали:

A>Закончилось всё предложением написать на бумажке функцию strrev. Отказался, надеюсь, что вежливо.
Блин, да вы все тут круты, слово strrev знаете! Я только из этого топика и обсуждения узнал, что есть такая функция в некоторых диалектах Си. Хотя за жизнь на собеседованиях два раза её писал на листке.

Здравствуйте, sharpcoder, Вы писали:

S>По поводу написанного вами — ну не подошли вы, в чем проблема? Зачем пытаться про них что-то плохое написать? Они же про вас здесь не пишут (а я думаю что взгляд с той стороны может быть куда более интересный)?

Тебе процесс их отбора нравится?
Если нравится, то в чём проблема, человек разрекламировал эту компанию, теперь более адекватные кандидаты туда косяками пойдут.
А если кажется, что что-то не так в этом собеседовании, то может есть разница между "работать в компании" и "работать с компанией"?

Здравствуйте, smallpoxlet, Вы писали:

S>Что и требовалось доказать. Требуются надежные исполнительные негры чтобы педалить код. "Руководитель группы" в данном случае означает не что он будет кем-то реально руководить, а то что у него зарплата будет чуть повыше и должность чуть погромче.

Вы там работали, чтобы так уверенно заявлять?

Здравствуйте, smallpoxlet, Вы писали:

S>И nginx по производительности хуже чем апач, ага.

Nginx использует мультиплексирование, почитайте что такое epoll. Для использования epoll нужно переходить в контекст ядра, а это порядка нескольких сотен-тысяч инструкций. Epoll не является алгоритмом позволяющим обходиться без синхронизации, epoll это syscall для ожидания готовности файловых дескрипторов для дальнейшего ввода-вывода.
Вот вам и ага, путаете термины многопоточный код и код без блокировок, учите мат.часть.

Здравствуйте, devcoach, Вы писали:

D>Вы уж извините, но читаю ваш топик и смеюсь. Это какую же звезду нужно словить, что бы уходить с собеседования из-за того, что при устройства на техническую позицию кандидату задали ... технический вопрос?

по техническому вопросу также можно оценить уровень собеседующего как и по ответу. Если твой уровень ниже уровня кандидата то ему проще прекратить общение и поискать более вменяемых.

Высокомерие оправдано когда между тимлидом и кодером пропасть. Меньше времени уходит на объяснения — делай как я сказал и всё.

Вы либо гений с проблемами в общении, либо удачно троллите. В обоих случаях неясно, как это поможет руководить командой.

Здравствуйте, Vzhyk, Вы писали:

V>03.09.2013 12:53, UA пишет:

>> Далеко не факт что "Пока есть такие привередливые ребята, другие ребята,
>> вроде нас, смогут нанять хорошего спеца задешево."
V>Ну неужели элементарную логику нужно разжевывать — именно, что факт.

Пока что ты факты путаешь со своей фантазией

Здравствуйте, mik1, Вы писали:

L>>Вопрос "какие объекты синхронизации знаете" говорит о том, что задающий этот вопрос о многопоточности читал только в книжках. И последний раз это делал где-нибудь в конце 90-х.

M>Вопрос "какие объекты синхронизации знаете" — это очень хороший открытый вопрос, который дает возможность собеседуемому на должность тим лида (а не быдлокодера) рассказать целую поэму о современных методах синхронизации, тем самым поразив собеседующих.

И получить клеймо "умник", потому что собеседующие, для которых все многопоточное программирование — это "объекты синхронизации", нихрена из сказанного не поймут.

Вот вопрос "опишите основные проблемы многопоточного программирования" или "расскажите о вашей практике/подходе к MT программированию" поставлен правильно и раскрывает умного человека, с которым все подобные проблемы приятно обсудить.

Здравствуйте, Abalak, Вы писали:

A>Это после педаления движка биржи? Ню-ню.

Обрисуй, какие ты видишь перспективы. Уехать в NYC на 120к? За вычетом налогов это всего 230 тр. в месяц, а цены там ни разу не московские. При том что следующее повышение будет лет через 5 и то не факт.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Ничего забавного, на самом деле.
SVZ>Мне, например, пару раз приходилось вносить изменения в проект на ASP.NET. При этом ASP я видел впервые в жизни

Если вы успешно вросили что-то asp.net-специфичное в проект первый раз видя этот asp.net, значит вы — хороший специалист, понимающий основные принципы "как оно работает под капотом". И вас вполне можно ставить в проект на asp.net. Ну может под чьим-то чутким урководством на первое время.

SVZ>И, думаю, что на собеседовании я имел бы такой же вид, как и те, кого я собеседовал.

Конечно. Надо задолбать кандидата вопросами про настройки пула приложений в iis, уничтожить вопросами про тонкую настройку http.sys, сделать ему "такой же вид" и выгнать с позором это ничтожество.

Здравствуйте, Vzhyk, Вы писали:

V>Адекватным вообще быть невозможно, можно быть адекватным чему-либо или
V>кому-либо. Здесь — они адекватны sharpcoder'у.

Два или три года назад в Москве был закрытый совместный эвент, на котором мне к сожалению пришлось принять участие в качестве одного из "собеседователей". "Собеседователей" было достаточно, поэтому в основном ограничивался функцией переводчика если требовалось и слушал. Человек из ммвб (это то же самое что московская биржа?), который позиционировал себя как крутой архитектор, проявил себя мягко говоря не блестяще. Я думаю, это нормально, это жизненная ситуация и для кандидатов и для интервьюэров.
Поэтому хотел понять sharpcoder оценил адекватность. Может на том собеседовании что-то просмотрели?

Здравствуйте, robin_of_the_wood, Вы писали:

___>Но часто для опытного разработчика сложно именно быстро придумать алгоритм, а не закодировать его.
Нет, нет и нет!
Чем опытнее разработчик, тем дольше он должен обдумывать алгоритм. Обычно с опытом растёт и зона ответственности, и любая ошибка имеет более серьёзные последствия.
Поэтому, если юниор где-то ошибётся, не проблема. Исправит через пару дней. А если человек, проектирующий систему, то потом эти косяки годами будут мешать работать, но исправить их уже будет не легко.

05.09.2013 10:56, robin_of_the_wood пишет:

> Может я не совсем точно выразился, но хотел подчеркнуть тот факт, что
> если алгоритм прост и очевиден, то реализация его много сил не потребует.
Когда-то давным давно (1985) я поступал на ФПМ в БГУ. А подготовка у
меня была 19 школы Минска. Вот прихожу на экзамен, беру билет, вижу
задача элементарная. Но я же знаю, по олимпиадам, что то, что на первый
взгляд простое, может оказаться очень сложным.
В общем я достаточно долго решал ту задачу 5 разными способами, причем
так и не найдя подвоха, пока решил сдать экзаменатору. Оказалось что
задача действительно элементарная. Просто я с уровня своего опыта не мог
поверить в это.

Ничего не напоминает эта притча в варианте с strrev?

Здравствуйте, fin_81, Вы писали:

_>Эмоция — это выражение своего (субъективного) мнения, в том числе рефлекторного (несознательного) мнения о раздражителе. Обида — это эмоция. По твоему не хорошо выражать эмоции на работе, то есть не хорошо иметь свое субъективное мнение.

Мнение можно выразить и без эмоций.
Иметь субьективное мнение совсем не значит выражать эмоции.
Выделенный фрагмент Вашего утверждения показывает, что вы строите ложные причинно-следственные связи.
При этом часто очень сильно искажаете слова собеседника и, как показал предыдущий пост, не придаете этому особого значения.
И выходит как в том анекдоте "То ли он украл, то ли у него украли..."

Во всем этом нет абсолютно ничего страшного, кроме разве что пропадания желания продолжать с вами беседу

_>Ты занимаешься программированием сознания, промывкой мозгов?

Простите. Я не хотел. Ваш мозг надеюсь не сильно пострадал?

Здравствуйте, UA, Вы писали:

A>>Останется на месте с той же зарплатой. А искать он будет больше.
A>>Поэтому если программистов таких не берут, то зарплаты расти у них не будут.

UA>Если текущая ЗП значительно выше рынка то штудировать переворот строки чтобы получить в итоге предложение на еще меньше денег как то глупо.
Она не будет выше рынка, если только работодатель не занимается благотворительность. Человек ведь от него и так никуда не денется.

Здравствуйте, landerhigh, Вы писали:

L>Еще раз — в реальной работе навык программирования ручкой по бумажке не востребован никак.

Еще раз спрошу. Чем написание strrev на бумажке отличается от написание ее же в IDE?

06.09.2013 14:03, UA пишет:

> Если это начальник отдела продаж еще можна с вами согласится, а если
> начальник отдела программистов, тогда что?
Ну как, компы тыбзить и на ближайшей барахолке толкать.

Здравствуйте, Andrusha, Вы писали:

A>Собственно, разговор, наверное, нужно начать с того, что предложение о вакансии было предложено через КА и выглядело вполне неплохо. Но не так уже чтобы завораживающие. Решил посмотреть. Теперь есть что рассказать.

На правах экс-инсайдера МБ (перестал им быть в прошлом году) прокомментирую все, что с вами произошло. Контрольный вопрос: наводили ли справки о компании и как это делали?

A>На собеседование со стороны компании пришло сразу четыре человека. Кто эти люди, их должности, или хотя бы имена, остались за кадром.
То что не представились — им в минус. Однозначно. Тогда надо было просто спросить — извините, а с кем имею дело?

A>Количество людей аргументировалось "разными" вакансиями. Странно, вроде шёл на какую-то конкретную (руководитель группы).

Либо недоговариваете, либо недопонимаете. Руководитель группы — это не вакансия, это должность. Вас могли собеседовать на руководителей разных групп либо на сходную должность "на другой стороне". Либо еще один "куратор" от кадров. Либо молодого взяли, чтоб учился собеседование проводить.Либо спецы по разным темам. Возможных вариантов — масса. А вы сразу напряглись зачем-то.

Тут необходимо дать кое-какие пояснения. "Московская биржа" образована недавно слиянием ММВБ и РТС. Соответственно, в ней есть две группы "разработчиков ТС" — ММВБшная и РТСная. Группы разработчиков, как собственно и системы, полностью ортогональны. Вас собеседовали в РТСную, только там есть "руководители группы". Сейчас РТСники разбегаются с биржи как зайцы из причалившей к берегу лодки деда Мазая. Не исключено, что у них несколько вакансий на такую должность — точной информацией я не владею по понятной причине. Также могли прийти на вас посмотреть "люди с другой стороны" — "а что? — а вдруг?"

A>Далее последовало стандартное предложение "расскажите о себе, о чём занимаетесь на текущем месте работы.". Хм... Но как-то рассказал, хотя это больше походило пересказ резюме с дополнительными подробностями. На это ушло не меньше получаса. Один человек ушёл — рассказчик из меня видимо, никудышный.

Одна из вакансий отпала (человек увидел, что вы явно не подходите) либо ушел "куратор" от кадров, убедившись, что все идет нормально. Хоть извинился перед уходом?

A>Дальше перешли к "технической" части. Ладно, вопрос чем отличается map от vector можно ещё отнести к разогревочным. Но что люди ожидают услышать на вопрос "слышали ли о многопоточности?". Или ещё лучше "Какие объекты синхронизации Вы знаете?". Нет, с одной стороны вопросы вполне корректны (а чего не спросить-то?), но с другой стороны никак не соответствуют не заявленной вакансии, ни опыту кандидата.

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

A>Ну, ладно. Далее вопрос, который поставил меня в тупик: "Какие типы эвентов бывают?". Щито?! Не буду томить, но оказывается типизация производится по признаку автоматического/не автоматического сброса. В ответ предложил свою — именованный/не именованный. Хотя может это вопросы из разряда "поговорить?".

Не понял, о каких событиях здесь идет речь. Если о событиях OS Windows, то я бы ответил Error/Warning/Information и далее по списку.

A>Закончилось всё предложением написать на бумажке функцию strrev. Отказался, надеюсь, что вежливо.

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

A>Собственно к чему я всё это. В моём личном рейтинге худших собеседований уверенное третье место. Сложилось впечатление, что люди банально поленились подготовиться к собеседованию: подготовить вопросы соответствующие вакансии; прочесть резюме кандидата и так далее... Да просто ноутбук принести, в конце концов. И это печально. Хотя люди приятные. Так что имейте ввиду, может и не стоит туда ходить, если нет лишнего времени "на поговорить".

Надо учесть, что, возможно, трое из четверых действительно не читали ваше резюме, потому что их "выдернули" на собеседование в самый последний момент — как экспертов по конкретным вопросам. Или, идя на собеседование с вами, все обязаны выучить наизусть ваше резюме? Этим людям сейчас приходится работать за двоих-троих (см. ниже). Ваше непомерное ЧСВ не позволяет нормально воспринимать такую ситуацию?

Информация для прочих соискателей:

На МБ сейчас идет активный "исход" РТСников — их пачками сманивают прежние руководители и коллеги по РТС, открывающие новые проекты. Соответственно, в этой части биржи — дикий кадровый голод, ситуация очень серьезная. Если не залупаться, а идти на сотрудничество и снисходительно относиться к некоторым рабочим моментам — можно весьма неплохо устроиться. По крайней мере, существенно бОльшую зарплату, чем первоначально предлагается, просить точно можно. Особенно, если имеется необходимая для должности квалификация и есть соответствующий опыт. Вот об этом и надо было говорить на собеседовании топикстартеру. Считаю, что собеседование он просто провалил.

Но надо иметь в виду следующее: ТС РТС будет "убита" на МБ в перспективе нескольких лет (моя оценка — лет 5). Рекомендую учитывать это в своих планах.

Экс-биржевик

Здравствуйте, Vzhyk, Вы писали:

V>Уже и удаленка и провинция и еще куча если. Переходим на обсуждение
V>маловероятных вариантов (1 из 100)?
V>Пока речь про офис и для жителей города, где офис — 99% процентов вакансий.

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

Во всех подобных случаях есть еще один маленький, но часто существенный момент.
Высокая самооценка — это в общем случае нормально. Более того, часто она может соответствовать реальной ситуации.
И варианты поведения типа "да мне да с моим то опытом" и подобные в принципе не лишины смысла.
Более того нередко хорошему и нужному спецу позволяются некоторые капризы, непозволительные для других.
Но тут очень важно соблюсти последовательность — сначала показать/доказать свою значимость(это требует и сил и времени), а уж только потом капризничать.

Отсюда вырисовывается очень простой вывод — не стоит начинать капризничать прямо на собеседовании

Здравствуйте, 1303, Вы писали:

вот мне только одно на самом деле интересно. все высказавшиеся тут за ide и против листочка и против вообще задач на собеседовании, что реально не могут написать 10 строк не очень сложного кода без ошибки?

Здравствуйте, genre, Вы писали:

>>> реально не могут написать 10 строк не очень сложного кода без ошибки?
V>>Пока тесты не пройдены, я всегда предполагаю, что код делает не то, что
V>>нужно.

И все-таки возвращаясь к собеседованиям. Не понимаю.
Если собеседуемый может написать 10 строк кода, то в чем проблема их написать, учитывая, что это собеседование.
Если не может — то к чему эти понты про "я так крут, что решать ваши простые задачи не буду".

09.09.2013 13:18, genre пишет:

> И все-таки возвращаясь к собеседованиям. Не понимаю.
> Если собеседуемый может написать 10 строк кода, то в чем проблема их
> написать, учитывая, что это собеседование.
> Если не может — то к чему эти понты про "я так крут, что решать ваши
> простые задачи не буду".
Проблемы в написать нет, а в чем проблема — читай весь топик, по второму
кругу ходить неинтересно.

З.Ы. Тут уже некоторые пытались выкладывать свои решения в 10 строк,
которые успешно оказывались или некорректными или безграмотными с точки
зрения кывтовцев. А вот обратного я что-то не припоминаю. Это я написал
тебе для размышления о 10 строчках кода на собеседовании и собеседующих.

Здравствуйте, landerhigh, Вы писали:

L>

L>Еще раз, медленно и по буквам. У настоящего программиста понятие "код" существует только в виде "оформленный согласно принятым coding standards со всеми необходимыми комментариями, юнит-тестами и подготовленный к code review". Такое бывает только в IDE.
L>Код на бумажке бывает только у специалистов по кодированию на бумажках.

L>ты просто не заметил, или возразить нечего?

Интересно в какую прострацию впадает этот программист если юнит тест написать практически невозможно(или очень дорого, например), а комментарий повторяет название метода.

Здравствуйте, genre, Вы писали:
G>Здравствуйте, __kot2, Вы писали:
__>> если компания набирает людей спрашивая про гномиков и глобус Украины, но значит, там и работают большие специалисты в этих вопросах. конечно нет смысла работать в такой компании, если конечно не хочется усовершенствоваться в этих вопросах ну или просто нужна любая работа работать.
G>Внимание вопрос. Означает ли то, что компания набирает гномиками, то что там работают плохие программисты?
у человека есть всегда огромный выбор какой вопрос задать. у него всегда огромный выбор действий. и то, что он делает, он считает самым лучшим среди всех возможных вариантов (наш мозг так работает). по сути на собеседовании мы приблизительно проверяем как работает мозг друг друга.
одна сторона лучший вопрос, на который способная другая, та в свою очередь лучший ответ на этот вопрос.

если человек начнет выковыривать козявки и обсуждать их цвет, а потом достанет куклу барби и начнет обсуждать ее волосы, означает ли, что он плохой программист? да нет, не всегда. но явно у него с головкой бо-бо, как и у тех, кто спрашивает про гномиков на собеседовании.

10.09.2013 17:55, __kot2 пишет:

> дело не в том, что собеседующий дураки, а в том, что людей часто
> интуиция подводит.
И где тут интуиция? Чел просто живет в своих предрассудках и очень
удивляется, когда обнаруживает, что его убеждение ничего более, чем
предрассудок.
Так и с гномиками, те кто их задают верят, что гномики имеют отношение к
их работе и тот, кто их сортирует — уж точно специалист. Прикольно потом
наблюдать за такими, когда они обламываются, он же гномиков круто
сортировал, а работает плохо.

11.09.2013 11:14, genre пишет:

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

11.09.2013 11:59, landerhigh пишет:

> G>в какой-такой логике утверждение "решает задачи про гномиков значит
> плохой программист" истинно?
>
> Корелляция почти 100%
Тебя словили на эмоциональное некорректное высказывание. Типичный прием
старого опытного тролля.
Вообще между решением задач про гномиков и умением программировать
корреляция около 0. Есть небольшая корреляция между уровнем образования
и умением решать задачи про гномиков по причине прямой зависимости:
более высокий уровень образования требует более сильное развитие
определенных мыслительных процессов, а эти влияют на умение решать
различные задачи, в том числе и про гномиков.

11.09.2013 12:46, genre пишет:

> Вообще именно задача про гномиков она реально сложная(если я не ошибаюсь
> изначально она была на какой-то математической олимпиаде, всероссийской
> кажется или типа того) и конечно она не оценивает умение
> программировать, но послушать как человек рассуждает тоже может быть
> полезно для кого-то.
Когда собеседовал никогда таким не страдал, гораздо интереснее послушать
что человек делал на прошлых работах, как и почему так, а не иначе.
А вот если человек сильно увлекается такими задачами про гору Фудзи, то
у меня сразу же последует после вопрос, а есть ли у тебя девушка, жена
(для женщин вопрос обратный про парня и мужа), чем еще ты увлекаешься.
Ибо человек, что тратит свое время в зрелом возрасте, на столь странные
вещи, вызывает подозрение в его нормлальности.