Здравствуйте, StandAlone, Вы писали:
SA>·>Скажи честно, ты много видел программеров с опытом c# 9 лет, которые используют list comprehensions (в c#? linq что-ли?) SA>А ты кроме LINQ других применений не знаешь, что ли?
Каких применений? Где ещё в c# есть LC?
SA>Я видел целую херову гору других, особенно часто на собеседованиях, которые прекрасно знаю все про while, но даже краем уха не слышали ни про LC, ни про инварианты, ни про верифицируемость кода. SA>Не умеют ни декомпозицию толком делать, ни про масштабируемость и поддерживаемость думать. SA>Им это просто не надо, они шлепают в своем императивном стиле процедуры на пять окон с десятью вложенными циклами и в ус не дуют. И убеждены, что этот подход единственно правильный. Вот прямо как ты или автор темы.
Тоже с логикой беда. Причину и следствие путаешь. Ты лучше расскажи, где ты видел людей, которые знают LC, инварианты и т.п. но не ничего не могут сказать о while или using?
SA>За множество лет не припомню, когда бы я в сознательном состоянии написал while. Всегда хватало фора, форича или иных, более высокоуровневых конструкций. SA>А вот в первый год работы я этот while знал назубок! Был ли я тогда нравственным персонажем программистом способным эффективно решать задачи? Не особо. SA>Если же теперь когда-то и понадобится while, то естественно из подсознания всплывет что нужно. В случае же если что-то забыто, то упадет тест(см. выше про инварианты) или завалится компиляция, что будет поправлено за минуту и дальше, к станку. SA>Проверять знание while это как проверять знание таблицы умножения.
И что такого-то? Как будто таблицу умножения знать — зазорно.
SA>·>и что делает using? SA>Легко! Представь, что ты несколько лет писал бизнес-логику в слое WCF. Тебе этот using нужен? Да тебе терабайты надо помнить про эту бизнес-логику и соприлегающие области. Все ненужное, согласно правилу мистера Холмса, прочь с чердака. SA>Using-ами пусть себе головенку забивают низкооплачиваемые низкоквалифицированные кодеры, которые ни на что выше кодера и саппортера-багофиксера не тянут.
Понятно, т.е. знаний ЯП нет, а просто code-monkey конкретного фреймворка. Топикстартеру такие значит не нужны.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, turbocode, Вы писали:
T>·>И зря. Уверен, что если ты поднаберёшься опыта, то изменишь своё мнение. T>Моё мнение пока такое: брать тех которых не нужно учить(они самообучаемые), которые умеют во всем сами разобраться имея на руках минимум информации
Это требование для джуниоров.
T> и придерживаются техники самодокументированного кода с хорошими архитектурными скилами.
А если ещё и это, то для миддлов.
Сеньёры же ещё должны уметь разговаривать с теми же джуниорами/миддлами (а не тупо посылать в rtfm) и с заказчиками/не-технарями, чтобы уточнять задачи и разбираться в требованиях.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
M>>>>GC вычистит ненужный более объект (ушедший из поля видимости). Только using для этого не обязателен, это уже я поспешил замечание сделать. using нужен был, если требовалась очистка, даже при словленном исключении, то есть, это фактически аналог try{}finally{}
IT>>>Давай без using. Нет его. Влияют ли скобки на время жизни объекта? С областью видимости переменной всё понятно. А как с объектом?
M>>По идее тоже заканчивается за блоком, если только не static.
M>На коленке :
M>
M>{
M> var o = new MyClassWithFinilizer();
M>}
M>GC.Collect
M>GC.WaitForPendingFinilizers()
M>GC.Gollect
M>
M>Упадёт объект? Нет студии под рукой проверить
"objects aren’t guaranteed to live throughout a method’s lifetime"
(c) J. Richter
Объект может быть собран даже до закрывающей фигурной скобки метода, где объявлена локальная ссылка на него, если он перестает использоваться. Ищите по цитате у Рихтера.
T>>·>И зря. Уверен, что если ты поднаберёшься опыта, то изменишь своё мнение. T>>Моё мнение пока такое: брать тех которых не нужно учить(они самообучаемые), которые умеют во всем сами разобраться имея на руках минимум информации ·>Это требование для джуниоров.
T>> и придерживаются техники самодокументированного кода с хорошими архитектурными скилами. ·>А если ещё и это, то для миддлов.
·>Сеньёры же ещё должны уметь разговаривать с теми же джуниорами/миддлами (а не тупо посылать в rtfm) и с заказчиками/не-технарями, чтобы уточнять задачи и разбираться в требованиях.
Если синьор посылает в RTFM то значит первое и вторые условия не выполняются. С заказчиками работают саппорт, PM-ы и еще бывает аналитики если предметная область специфическая.
Здравствуйте, turbocode, Вы писали:
T>Для 9-ти лет опыта ваш вопрос звучит как оскорбление, радуйтесь что не получили по щам. T>Тупые вопросы можно было задать удаленно. Предупредить соискателя что у вас практикуется экзамен по С#, а не разговор по душам.
Ох, нельзя тебе людей нанимать давать. Разоришь контору после таких собеседований по душам. Про удаленно, в принципе, согласен. Обычно эти вопросы задаются на первом телефонном интервью. Второе телефонное или личное обычно происходит в 1-2 случаях из 10, независимо от количества лет опыта в резюме.
A>Ох, нельзя тебе людей нанимать давать. Разоришь контору после таких собеседований по душам. Про удаленно, в принципе, согласен. Обычно эти вопросы задаются на первом телефонном интервью. Второе телефонное или личное обычно происходит в 1-2 случаях из 10, независимо от количества лет опыта в резюме.
Не совсем по душам но и далеко не экзамен.
У других которые брали по результатам экзаменов был достаточно большой процент по увольнениям в итоге.
Здравствуйте, turbocode, Вы писали:
T>Не совсем по душам но и далеко не экзамен.
Я, честно говоря, у ТС экзамена особо не заметил. Я тоже задаю этот вопрос вторым по счеты, обычно минуте на пятой интервью, после краткого рассказа о нас и кандидате о себе. Потом плавно переезжаем в GC и т.п. Заканчиваю обычно задачками из реального проекта, где человек может продемонстрировать ход мыслей и предыдущий опыт. Если конечно до этого доходит. Про юзинг, кстати, отвечают процентов 70%.
T>У других которые брали по результатам экзаменов был достаточно большой процент по увольнениям в итоге.
Это тоже не дело. Любой индус пройдет такой экзамен очень быстро. У меня есть простенький вопрос про immutable типы. Кстати, редко когда, но бывает, что не отвечали. Один индусик бодро рассказал мне на примере стринга, что к чему. Но у меня закралось сомнение и я спросил, а как он реализует свой собственный immutable тип. Когда задавал, подумал про себя, что не дело такие элементарные вещи спрашивать. Но чел не ответил, даже после наводящих вопросов и подсказок. Все мямлил про переопределение оператора =.
Здравствуйте, scf, Вы писали:
A>>А я видел людей блестяще знающих алгоритмы, в том числе те, о которых большинство программистов не слышали. При этом они умудряются на ровном месте написать алгоритм с квадратической зависимостью, хотя знания чтобы так не делать у них есть.
scf>Зачем путать необходимое с достаточным?
Я не путаю. Для написания и поддержки программ, знание популярных алгоритмов не является ни необходимым, ни достаточным.
Такие вопросы проверяют в лучшем случае эрудицию. Но если человек не знает, где находится Гватемала, то что он теперь и программу написать не сможет? Особенно забавно, когда проверяют алгоритмы сортировки.
A>Я, честно говоря, у ТС экзамена особо не заметил. Я тоже задаю этот вопрос вторым по счеты, обычно минуте на пятой интервью, после краткого рассказа о нас и кандидате о себе. Потом плавно переезжаем в GC и т.п. Заканчиваю обычно задачками из реального проекта, где человек может продемонстрировать ход мыслей и предыдущий опыт. Если конечно до этого доходит. Про юзинг, кстати, отвечают процентов 70%.
Это проверка прочел ли кандидат о работе GC перед собеседованием или нет?
A>У меня есть простенький вопрос про immutable типы. Кстати, редко когда, но бывает, что не отвечали. Один индусик бодро рассказал мне на примере стринга, что к чему. Но у меня закралось сомнение и я спросил, а как он реализует свой собственный immutable тип. Когда задавал, подумал про себя, что не дело такие элементарные вещи спрашивать. Но чел не ответил, даже после наводящих вопросов и подсказок. Все мямлил про переопределение оператора =.
Слишком большая зацикленость на мелочах. Такое впечатление что ваши индусики делать что нибудь сложнее одного класса не будут.
Здравствуйте, turbocode, Вы писали:
T>Это проверка прочел ли кандидат о работе GC перед собеседованием или нет?
Ниже как раз пример про то как прочитал, но оказалось недостаточным. А если таки прочитал, то хорошо, и без разницы перед интервью или 5 лет назад. Значит внутренностями дотнета интересуется, что есть гут.
T>Слишком большая зацикленость на мелочах. Такое впечатление что ваши индусики делать что нибудь сложнее одного класса не будут.
Блин, это всего лишь малая часть обсуждаемого. Конкретно — 2 первых вопроса первого собеседования. Откуда такие выводы? И привел я их тут только для того, что бы показать, что и с 10-ю заявленными годами опыта люди не отвечают на элементарные вопросы. Из этого я делаю вывод, что такие вопросы задавать нужно. Я вообще, когда составлял список вопросов, глянул на него и подумал, что как-то совсем все элементарно. Ошибался — большинство и половины не осиливало. А с теми кто осиливал беседа выходила далеко за рамки списка и плавно переходила в разговор за жизнь и второе собеседование, где уже только за жизнь.
Здравствуйте, Abalak, Вы писали:
A>Это тоже не дело. Любой индус пройдет такой экзамен очень быстро. У меня есть простенький вопрос про immutable типы. Кстати, редко когда, но бывает, что не отвечали. Один индусик бодро рассказал мне на примере стринга, что к чему. Но у меня закралось сомнение и я спросил, а как он реализует свой собственный immutable тип. Когда задавал, подумал про себя, что не дело такие элементарные вещи спрашивать. Но чел не ответил, даже после наводящих вопросов и подсказок. Все мямлил про переопределение оператора =.
А что тут ожидается в качестве ответа?
Вот у нас есть immutable тип. Это значит, что после создания объект этого типа внутреннее состояние не меняет.
Если же у объекта есть операции, подразумевающие изменения(например, Add для immutable коллекции или Replace для string), то этот метод при вызове на основе текущего состояния создает новый объект с состоянием, соответствующим проведенной операции.
Учесть детали реализации: у пропертей убрать setter-ы, в геттерах пропертей mutable типов возвращать не хранимую ссылку, а копию.
Что-то еще ожидается?
Или же надо на каком-то конкретном примере? Спроектировать урезанный List/string?
A>А с теми кто осиливал беседа выходила далеко за рамки списка и плавно переходила в разговор за жизнь и второе собеседование, где уже только за жизнь.
Я не ставил бы элементарные вопросы на первое место потому что могут неправильно вас понять и у кандидата всякое желание пропадет с вами продолжать разговор, а дальше кандидат либо скатится в тролинг либо сам уйдет. В индусов менталитет скорее другой и они по умолчанию рассчитывают что их будут пороть на собеседовании независимо от их опыта.
Здравствуйте, turbocode, Вы писали:
T>Я не ставил бы элементарные вопросы на первое место потому что могут неправильно вас понять и у кандидата всякое желание пропадет с вами продолжать разговор, а дальше кандидат либо скатится в тролинг либо сам уйдет. В индусов менталитет скорее другой и они по умолчанию рассчитывают что их будут пороть на собеседовании независимо от их опыта.
Тут дело не в менталитете. Основной массе народу с Индии просто нет никакого доверия, они сами себя дискредитировали. Потому что они постоянно врут про реальные навыки и их "опыт" мало коррелирует с действительно полезными рабочими навыками. Ну, если не учитывать плетение корпоративных интриг и трындеж.
KP>Тут дело не в менталитете. Основной массе народу с Индии просто нет никакого доверия, они сами себя дискредитировали. Потому что они постоянно врут про реальные навыки и их "опыт" мало коррелирует с действительно полезными рабочими навыками. Ну, если не учитывать плетение корпоративных интриг и трындеж.
Если бы дискредитировали то их бы даже не приглашали.
Здравствуйте, turbocode, Вы писали:
KP>>Тут дело не в менталитете. Основной массе народу с Индии просто нет никакого доверия, они сами себя дискредитировали. Потому что они постоянно врут про реальные навыки и их "опыт" мало коррелирует с действительно полезными рабочими навыками. Ну, если не учитывать плетение корпоративных интриг и трындеж.
T>Если бы дискредитировали то их бы даже не приглашали.
А их приглашают?
Если есть выбор между раджикумаром и белым человеком — у раджикумара шансов практически 0.
Здравствуйте, turbocode, Вы писали:
T>Если бы дискредитировали то их бы даже не приглашали.
Как ты это себе представляешь "не приглашали бы"? Ты работаешь в компании и тебе рекрутер присылает резюме Кумара которое формально подходит под все требования вакансии. Отказать на основании того, что это Кумар, а не Джон ты не можешь. В итоге ты должен провести с ним собеседование, даже если он не в зуб ногой вообще ни в чем. А вот если его резюме попадет в команду других кумаров, то тут уже будет важнее на сколько человек хороший и на сколько приятно с ним на обед ходить, нежели профессиональные качества. В результате в больших компаниях есть целые команды из кумаров, производящие просто редчайший треш, но зато люди там очень хорошие.
using нужен был, если требовалась очистка, даже при словленном исключении, то есть, это фактически аналог try{}finally{}
