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

K>спрашивает где ошибка

Я б вот так написал:

Console.WriteLine((flag ? A : B)());

Дурак интервьюер. Раз языка не знает.

ВП>чего такой нервный?

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

S>Какой город?

Самара

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


ВП>>чего такой нервный?

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

и что с того?
вежливо скажи что у тебя пригорело,встань и уйди

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

Не, ну не надо смешивать синтаксис, проверку которого легко переложить на компилятор, и сборку мусора. То, что это не потребовалось, говорит всего лишь о ммм... специфике задач. Только без обид У меня на текущем месте это тоже потребовалось ровоно один раз — на собеседовании.
А вот на прошлом месте были (не часто, но были) интересные задачи.
Ну например: приложение, где обрабатывается куча данных, начинает отжирать немеряно памяти.
Задача: устранить утечку.
Анализ: утечки (в таком объеме) не выявлено. Выявлено, что интенсивное использование всяких сериализаторов и zipовальщиков приводит к выделению объектов в LOH. Больших таких, десятки и сотни мегабайт, и, что обидно, время их жизни невелико. Учитывая, что в LOH еще много кто выделяет память, и учитывая проблемы с дефрагментацией — получаем неконтролируемый рост потребления памяти.
Решение: 1) поменять порядок инициализации, чтобы большинство желающих хранить что-то в LOH сохранили это в самом начале. 2) где можно — заранее выделяем буферы, и подсовыввем их всяким сериализаторам. 3) где нельзя выделить буфер (потому что размер большой или потому что размер труднопредсказуем) — используем chunk array.
Так что знание внутренностей — они сильно полезно.

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

K> Console.WriteLine(flag ? A() : B());
K>спрашивает где ошибка

уверен что правильно воспроизвел и скобки на листочке были?

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

Про сабж (что задолбали).
А меня наоборот на нескольких интервью научили новым умным и важным вещам, поэтому я с большим интузиазмом воспринимаю новые знание от умных интервьюверов.
Например, сравнительно недавно я узнал, что в Java блокировку совместно используемых объектов в многопоточной программе путем двойной проверки (double checking locking) использовать некомильфо, надо всегда блокировать через synchronized и весь объект, а желательно и весь класс. Потому как даже введение volatile 10+ лет назад не исправило ситуацию. Ну и, как обычно бывает, в JVM есть баги. Поэтому, вообще, лучше блокировать на уровне системы. Желательно через заведение специального файла. Мудрость веков, так сказать, она проверена временем и всегда актуальна, независимо от компиляторов и фреймворков.

Другой интервьювер, несколько лет назад, увидев у меня в резюме название компании, где работал на тот момент, с радостью сказал, что они используют дженерики в C# года два и очень довольны, что работают они так же как и в С++ и даже лучше, потому как байт-код. Они вот недавно перелопатили код и по той же технике, как в C++ отнаследовались от класса, переданного параметром дженерика. Ну или не совсем от этого параметра. Может от другого дженерика, которому этот параметр передали, а тот уже в свою очередь от переметра. Точно не помнит, но как-то так. Но да, это круто, что в C# появились дженерики. Рекомендовал почитать книжки. Я записал на листике названия. Полезно, когда учат и ссылки дают.

Двигаясь дальше в глубь времени, когда C++ еще был больше распространен, третий интервьювер научил меня легко и просто определять адрес памяти, переданный в функцию, является ли он памятью выделенной в куче или на стеке. Я начал говорить что обычно куча располагается по меньшим адресам, чем стэк, но из-за опций компилятора надежно сказать нельзя. Упомянул про то, что в винде можно выделять и убивать кучу и пр. Но тут он меня прервал и сказал, чтобы я не гнал чушь, она к делу не относится. Говорит, подумай обобщенно, глобально так сказать, без оглядки на компиляторы и платформы. Спрашивает, куча куда растет? Ну вверх. Правильно. А стэк куда? Ну стек наоборот сверху вниз. Вот, говорит, молодец. А теперь, говорит, представим, что нам передали массив в функцию. Если мы возьмем адрес первого элемента. Потом увеличим его на единицу. Куда попадем? Ну попадем во второй элемент, отвечаю. Вот, молодец, говорит, соображаешь, люблю таких. А вот теперь, если мы указателю на массив применим операцию инкремент (слышал про такую, да?), ну вот, ptr++. Если адрес увеличился, значит массив из кучи, а если адрес уменьшился, значит, массив из стека. Усек? Я говорю, вот здорово-то! Так просто! Как я так не догадался с самого начала, просто не представляю. Он говорит, ну ничего страшного, язык C++ сложный, за 6 лет я и сам его не до конца изучил, но стараюсь.
После чего я пообещал почитать еще книжек.

Самое удивительное, из всех трех компаний, несмотря на недостаточность знаний, мне дали оффер. То ли лицо смазливое у меня было (кто их тут в гей-эрии разберет), то ли вид лихой и придурковатый. В общем, решили, надо брать меня, по ходу дела доучат. Я прикинул, и во всех трех случаях решил, что буду обузой для принимающей компании. Мне слишком много придется читать и учить, чтобы работать на уровне с их специалистами. Но с тех пор к собеседованиям готовлюсь тщательнее. Особенно когда собеседую. Неловко окажется, если претендент ответит на мой вопрос лучше, чем я его знаю. И я всегда с благодарностью принимаю опыт и знания интервьюверов. Их не зря поставили спрашивать претендентов, они — цвет и свет компании, в которую я стремлюсь. Меня много приходит на вакансию, а они одни. Их время, уделенное на мое обучение, очень ценно. Так вот сходишь на 10-20 интервью, и научишься программировать. И все благодаря умным интервьюверам. Да и чай-кофе халявный наливают. Иногда печеньки дают. Можно с утра не завтракать, халява.

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

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

WP>А вот теперь, если мы указателю на массив применим операцию инкремент (слышал про такую, да?), ну вот, ptr++. Если адрес увеличился, значит массив из кучи, а если адрес уменьшился, значит, массив из стека. Усек? Я говорю, вот здорово-то! Так просто! Как я так не догадался с самого начала, просто не представляю. Он говорит, ну ничего страшного, язык C++ сложный, за 6 лет я и сам его не до конца изучил, но стараюсь.
WP>После чего я пообещал почитать еще книжек.

Операция '++' то увеличивает, то уменьшает значение указателя? Это нынче с++ такой? Можно пример кода, просто любопытно?

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

Я наоборот хватаю такое — это отличный способ научиться нужному.

Согласен, зачем человеку обращать внимание на то, с чем справляется прекрасно препроцессор.

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

WP>А меня наоборот на нескольких интервью научили новым умным и важным вещам, поэтому я с большим интузиазмом воспринимаю новые знание от умных интервьюверов.

Был в нашем полку аналогичный случай. Спросили меня как-то, как в ASP.NET заполняется View State. Ну, у меня это запечатлелось где-то в подкорке, поэтому я с энтузиазмом начинаю толкать про системную JS-функцию __onFormSubmit_или_как_то_так__, которая подсовывается рантаймом и бегает по всему DOM-у, вычитывая филды, заодно дергая функции валидации, иф презент, генеря этот самый View State с попутной конвертацией в base64... и по вытягивающимся лицам интервьюверов понимаю, что они НИКОГДА не залезали отладчиком в кишки асп.нета настолько глубоко. А ответа, очевидно, ожидали какого-то другого, судя по попыткам меня перебить.
Двигаемся дальше. "А расскажите нам про прототипы в JavaScript". С энтузиазмом уточняю — Вы про свойство prototype? — Да, да, расскажите про прототипы.
Ну, говорю, имеется у некоторых специальных объектов некоторого типа такое свойство... не всегда, правда.
Собеседующий озадаченно чешет бейцо ухо — В смысле как не увсех? как не всегда? тогда наследование бы не работало!!!! И огорченно отворачивается, мол о чем с таким дебилом дальше говорить.
Про 1.8.5 и различие классического от паразитического наследований мне рассказать уже не дали, свернули разговор.


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

WP>Так что, меня не задолбали. О рекрутерах расскажу в следующий раз. Чрезвычайно полезные люди. Извините, сейчас некогда. У меня по расписанию дня наступило время чтения книжек.

Полезное дело, пойду тоже почитаю книжек. Про искусство прохождения собеседований.

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

K>Дали тесты на внимательность (как я понял) на листочке (с чем у меня всегда были проблемы и я всегда перекладывал это на компилятор и дебагер )
K>Дал вопрос. код такой:

K>

K>        static void A()
K>        {
K>            Console.WriteLine("A");
K>        }

K>        static void B()
K>        {
K>            Console.WriteLine("B");
K>        }

K>        static void Main(string[] args)
K>        {
K>            bool flag = false;
K>            Console.WriteLine(flag ? A() : B());
K>

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

Тоже подобное получал на интервью.
Смысл этого теста? Завалить джуниора?

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

Браво, какой слог!

WP>Так что, меня не задолбали. О рекрутерах расскажу в следующий раз. Чрезвычайно полезные люди. Извините, сейчас некогда. У меня по расписанию дня наступило время чтения книжек.

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

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

K>потому что не первый раз такое. кстати первый подобный раз был в епам. а этот тоже родом из епам
K>плодят себе подобных по ходу (контора в этот раз не епам, просто чувак там работал раньше)
Кстати, лайфхак по поводу ЕПАМ. Попроси их подобрать интервьюера, который будет упор делать на опыт и остаточные знания, а не вопросами на внимательность оценивать квалификацию. Я разок так попросил, и в принципе интервью было адекватным.

WP>Например, сравнительно недавно я узнал, что в Java блокировку совместно используемых объектов в многопоточной программе путем двойной проверки (double checking locking) использовать некомильфо, надо всегда блокировать через synchronized и весь объект, а желательно и весь класс. Потому как даже введение volatile 10+ лет назад не исправило ситуацию.
Это не относится к кокретному языку вообще.

WP>А вот теперь, если мы указателю на массив применим операцию инкремент (слышал про такую, да?), ну вот, ptr++. Если адрес увеличился, значит массив из кучи, а если адрес уменьшился, значит, массив из стека.
Это полная бредятина.

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

WP>Например, сравнительно недавно я узнал, что в Java блокировку совместно используемых объектов в многопоточной программе путем двойной проверки (double checking locking) использовать некомильфо, надо всегда блокировать через synchronized и весь объект, а желательно и весь класс. Потому как даже введение volatile 10+ лет назад не исправило ситуацию. Ну и, как обычно бывает, в JVM есть баги. Поэтому, вообще, лучше блокировать на уровне системы. Желательно через заведение специального файла.

Бред.


WP>Если адрес увеличился, значит массив из кучи, а если адрес уменьшился, значит, массив из стека. Усек? Я говорю, вот здорово-то! Так просто! Как я так не догадался с самого начала, просто не представляю.

Бред.

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

Видимо знания были какого надо уровня.

Здравствуйте, aik,

WP> А вот теперь, если мы указателю на массив применим операцию инкремент (слышал про такую, да?), ну вот, ptr++. Если адрес увеличился, значит массив из кучи, а если адрес уменьшился, значит, массив из стека. Усек?

Гмм. А я бы в вот этом самом месте встал бы и вежливо попрощался. А ты?

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


G>Так что знание внутренностей — они сильно полезно.
В общем-то для всего перечисленного не сильно нужно знание деталей работы сборщика мусора.
Просто элементарная гигиена.

Когда я занимался играми на J2ME, мы старались сделать, чтобы в основном цикле игры в принципе не было создания новых объектов.

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

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



WP>А вот теперь, если мы указателю на массив применим операцию инкремент (слышал про такую, да?), ну вот, ptr++. Если адрес увеличился, значит массив из кучи, а если адрес уменьшился, значит, массив из стека.

Бредятина.

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

V_S>Здравствуйте, aik,

WP>> А вот теперь, если мы указателю на массив применим операцию инкремент (слышал про такую, да?), ну вот, ptr++. Если адрес увеличился, значит массив из кучи, а если адрес уменьшился, значит, массив из стека. Усек?

V_S>Гмм. А я бы в вот этом самом месте встал бы и вежливо попрощался. А ты?
Я думаю это таки вольный пересказ истории, а не грубость.