Здравствуйте, Олег К., Вы писали:

ОК>Еще бы понять нафиг помнить всякий хлам. Один спросит одну хрень, другой спросит другую хрень, третий спросит еще что-то. Это ж какой объем ненужной информации нужно держать в голове!
Расслабься, тебя уже не взяли.

ОК>На счет сборщика мусора — достаточно знать что он есть и не считать себя (речь об интервьюерах) самым умным.
Непонимание принципов работы GC пожет подкинуть разнообразные сюрпризы в нагруженных приложениях. Если формоклёпить то да, достаточно знать что GC где то там есть.

Здравствуйте, Олег К., Вы писали:

K>>Собственно, что сложного в этих вопросах? Думаю, про базовые принципы работы GC и heap в .Net должен знать каждый, кто с .Net работает.
K>>Даже здесь, на рсдне, в статье про GC, ответы на эти вопросы есть в первых 3-4 абзацах.
ОК>Еще бы понять нафиг помнить всякий хлам. Один спросит одну хрень, другой спросит другую хрень, третий спросит еще что-то. Это ж какой объем ненужной информации нужно держать в голове!
Ну это не то что бы и хлам, до таких глубин многие и не доходят. Эти многие не понимают, к примеру, что такое static переменные и в чем их отличие от обычных, не говоря уже о таких забавных штуках как статичные конструкторы и прочее.

В принципе это все довольно вменяемые вопросы, невменяемые — это про хитрожопые битовые операции, название второго параметра функции (и даже было как-то про название функции), какие-то хакерские штучки типа как определить Big Endian эта машина или Little Endian без сериализации и т.д. Эти все вопросы мне в этом году встречалось.

ОК>На счет сборщика мусора — достаточно знать что он есть и не считать себя (речь об интервьюерах) самым умным.
Вообще, прочитав Рихтера хотя бы 1 раз и порешав задачки из "Cracking the coding interviews", можно смело проходить интервью, на подобные вопросы ты ответишь без проблем. Оно конечно потом выветривается со временем, но все равно что-то полезное остается.

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

ОК>>На счет сборщика мусора — достаточно знать что он есть и не считать себя (речь об интервьюерах) самым умным.
CC>Непонимание принципов работы GC пожет подкинуть разнообразные сюрпризы в нагруженных приложениях. Если формоклёпить то да, достаточно знать что GC где то там есть.
Вся беда в том, что высоконагруженных проектов довольно таки мало, всё обычно сводится именно к формоклепству, где нужны другие скиллы, там больше analytical skills полезны. Вот зачем "формоклепу" знать тонкости GC — непонятно.

Здравствуйте, Олег К., Вы писали:

ОК>Сколько же дури в твоей башке, ну и ЧСВ улетело далеко в космос.
Друг мой давайте помиримся

ОК>Да, те кто такую хрень на интервью спрашивают — все что угодно но не синьйоры.
Вы правы друг мой. Я искренне надеюсь что я уже лет как N перерос уровень пресловутого "синьйора" (чтобы это не значило)

ОК>Да очевидно же, чуваки пишут следущую версию .НЕТа и Си Шарпа.
Знаете иногда действительно хочется поучаствовать (хотя бы дать парочку дурацких советов), но там свои специалисты со своим видением (что в целом ок).

ОК>Ну так и кандидат тоже может "отинтервьюировать" интервьюера. Только кандидат тут в заведомо проигрышном положении поскольку кандидату надо не утвердиться (в отличии от интервьюера) а получить работу.
Я таким никогда не занимался (утверждением себя). Это непродуктивно ни для кандидата ни для интервьюера. Адекватный кандидат — ценная находка для любой компании и только полный кретин может заниматься такой глупостью.

ОК>Готов держать пари что у меня найдется парочка несложных вопросов на которые такой "эксперт" как ты не ответит.
Уверен что так (ну может не на 100% уверен )

ОК>Типичные джуны которые ничего больше и спросить не могут.
Если я сейчас заведу "старую" песню про google и пр. вы конечно скажите что они тоже типичные "джуны" (что за оскорбление такое страшное ?)?

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

ОК>Еще бы понять нафиг помнить всякий хлам. Один спросит одну хрень, другой спросит другую хрень, третий спросит еще что-то. Это ж какой объем ненужной информации нужно держать в голове!
Это часть нашей работы — держать в голове много вещей и уметь применить их на практике.

ОК>На счет сборщика мусора — достаточно знать что он есть и не считать себя (речь об интервьюерах) самым умным.
Я представляю себе собеседование — заходит московский архитектор. Ему вопрос — расскажите про c#. Он отвечает — вам достаточно знать что он есть увальни!

__> Задавались довольно простые вопросы типа:

Вопросы не сложные, скорее специфичные. Я бы отметил, что некоторые из вопросов относятся к нестабильной части CLR в том смысле, что вендор особенно сильно предупреждает, что знание этой специфики нельзя пытаться использовать на практике. Насколько оно полезно в этом случае — вопрос не однозначный.

У меня вопрос к вам тематический, впрочем (задам здесь, чтобы не выносить, т.к. вы, похоже, разбираетесь в теме). Видимо, вы сталкивались с проблемой фрагментации памяти для LOH-объектов. Как вы ее решали, если исключить несколько сомнительное и не очень эффективное решение (ну и ограниченное, кстати) из блогов на MSDN? Я не буду пока говорить, как решали ее мы, чтобы не замыливать глаз, хочется услышать, возможно, новый, более эффективный подход. Мне показалось, что руки у разработчика сильно связаны в этих случаях.

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

ОК>>На счет сборщика мусора — достаточно знать что он есть и не считать себя (речь об интервьюерах) самым умным.
CC>Непонимание принципов работы GC пожет подкинуть разнообразные сюрпризы в нагруженных приложениях. Если формоклёпить то да, достаточно знать что GC где то там есть.

Бла-бла-бла! А теперь потрудись ответить на следущие вопросы:

1. Над какими нагруженными приложениями ты успел поработать?
2. С какими-такими сюрпризами тебе пришлось иметь дело?
3. Как тебе помогло знание (а точнее запоминание) ответов на выше-озвученные вопросы?
4. Объясни уж нам серым и убогим что такого ты сделал со сборщиком мусора, о великий ТВОРЕЦ который всячески выше "какого-то ГУИ."

ОК>>>На счет сборщика мусора — достаточно знать что он есть и не считать себя (речь об интервьюерах) самым умным.
CC>>Непонимание принципов работы GC пожет подкинуть разнообразные сюрпризы в нагруженных приложениях. Если формоклёпить то да, достаточно знать что GC где то там есть.
B>Вся беда в том, что высоконагруженных проектов довольно таки мало, всё обычно сводится именно к формоклепству, где нужны другие скиллы, там больше analytical skills полезны. Вот зачем "формоклепу" знать тонкости GC — непонятно.

1. Советую все-таки с уважением относиться к любой работе.
2. Знание это одно. А простая память это другое. Помнишь все-таки то с чем работаешь. А то с чем не работаешь выветривается из голову за ненужностью.

ОК>>На счет сборщика мусора — достаточно знать что он есть и не считать себя (речь об интервьюерах) самым умным.
B>Вообще, прочитав Рихтера хотя бы 1 раз и порешав задачки из "Cracking the coding interviews", можно смело проходить интервью, на подобные вопросы ты ответишь без проблем. Оно конечно потом выветривается со временем, но все равно что-то полезное остается.

Опять-таки, что это за интервью такое перед которым нужно перечитывать Рихтера да еще и решать задачки из "Cracking the coding interviews"? Снова приходим к тому что люди (интервьюеры) в силу своего низкого уровня ничего больше и не могут спросить кроме книжных вопросов или задачек.

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

K>У меня вопрос к вам тематический, впрочем (задам здесь, чтобы не выносить, т.к. вы, похоже, разбираетесь в теме). Видимо, вы сталкивались с проблемой фрагментации памяти для LOH-объектов. Как вы ее решали, если исключить несколько сомнительное и не очень эффективное решение (ну и ограниченное, кстати) из блогов на MSDN?

Очень коротко — использовался пул pinned objects. Про "сомнительные" решения из блогов к сожалению ничего не знаю Надеюсь смог ответить

ОК>>Сколько же дури в твоей башке, ну и ЧСВ улетело далеко в космос.
__>Друг мой давайте помиримся

Да я вроде и не ссорился с тобой, что, однако, не отменяет твоей дури и ЧСВ.

ОК>>Да, те кто такую хрень на интервью спрашивают — все что угодно но не синьйоры.
__>Вы правы друг мой. Я искренне надеюсь что я уже лет как N перерос уровень пресловутого "синьйора" (чтобы это не значило)

Не дорос ты еще до синьйора, и это видно из твоих вопросов.

ОК>>Да очевидно же, чуваки пишут следущую версию .НЕТа и Си Шарпа.
__>Знаете иногда действительно хочется поучаствовать (хотя бы дать парочку дурацких советов), но там свои специалисты со своим видением (что в целом ок).

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

ОК>>Ну так и кандидат тоже может "отинтервьюировать" интервьюера. Только кандидат тут в заведомо проигрышном положении поскольку кандидату надо не утвердиться (в отличии от интервьюера) а получить работу.
__>Я таким никогда не занимался (утверждением себя). Это непродуктивно ни для кандидата ни для интервьюера. Адекватный кандидат — ценная находка для любой компании и только полный кретин может заниматься такой глупостью.

Бла-бла-бла. Все тут прямо святые. Я сейчас расплачусь от умиления.


ОК>>Типичные джуны которые ничего больше и спросить не могут.
__>Если я сейчас заведу "старую" песню про google и пр. вы конечно скажите что они тоже типичные "джуны" (что за оскорбление такое страшное ?)?

Я не откажусь от своего мнения. Задавать вопросы из книжки да тупые задачки только джуны и могут. И да, Гугл все-таки согласился что ихние интервью ничего не дают.

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

Уже и гениев сюда приплел.

ОК>>Еще бы понять нафиг помнить всякий хлам. Один спросит одну хрень, другой спросит другую хрень, третий спросит еще что-то. Это ж какой объем ненужной информации нужно держать в голове!
__>Это часть нашей работы — держать в голове много вещей и уметь применить их на практике.

Ну давай, потрудись объяснить как ты применяешь на практике "ответы на свои же вопросы выше."

ОК>>На счет сборщика мусора — достаточно знать что он есть и не считать себя (речь об интервьюерах) самым умным.
__>Я представляю себе собеседование — заходит московский архитектор. Ему вопрос — расскажите про c#. Он отвечает — вам достаточно знать что он есть увальни!

Опять-таки, вопрос поставлен с точки зрения читателя книжек который на большее и не способен.

K>>У меня вопрос к вам тематический, впрочем (задам здесь, чтобы не выносить, т.к. вы, похоже, разбираетесь в теме). Видимо, вы сталкивались с проблемой фрагментации памяти для LOH-объектов. Как вы ее решали, если исключить несколько сомнительное и не очень эффективное решение (ну и ограниченное, кстати) из блогов на MSDN?

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

__>Очень коротко — использовался пул pinned objects. Про "сомнительные" решения из блогов к сожалению ничего не знаю Надеюсь смог ответить

Ну так что за проблема-то возникла что тебе пришлось использовать пиннд обджектс. Опиши сам проект и что там было не так.

__>Очень коротко — использовался пул pinned objects. Про "сомнительные" решения из блогов к сожалению ничего не знаю Надеюсь смог ответить

Хм, пул pinned objects? Сдается мне, таким образом скорее можно добиться как-раз фрагментации, за счет неиспользуемого пространства.

Может я чего-то не понимаю. Можете описать сценарий использования? Каким алгоритмом выяснялись размеры для pinned objects в пуле? Как происходило управление пулом, было ли выделение/очистка (может быть он был сложный)?

ОК>Тебе в первую очередь надо было бы спросить что за проблема (более высокоуровневая) у них возникла а не сразу как они ее решали.

Фрагментация — она сама по себе проблема Хотя контекст приложения играет определенную роль, соглашусь.

Здравствуйте, Олег К., Вы писали:

ОК>Ну так что за проблема-то возникла что тебе пришлось использовать пиннд обджектс. Опиши сам проект и что там было не так.
По моим подсчётам уже третья просьба "Олега К", привести хоть какое-то описание реальной задачи/проекта, где пригодились эти сакральные знания,
сопровождается глухим молчанием.
Вывод напрашивается сам собой — они нужно только чтоб кандидатов на собеседовании потрепать.

DA>Ты и спам-ботам отвечаешь?
Ты предлагаеш поставить знак равенства "хрюша = спамбот" ?

DA>>>Потому, что ищут дотнетчиков?
E>>Хз.
DA>Ну да.
Я не знаю кого они ищут, у меня в резюме стоит C++ и никакого сишарпа нету.

DA>Какому вопросу-то?
DA>Тебя удивляет требование заграна для девелопера?
Меня удивило появление этого вопроса, в предыдущих N-письмах от луксофта его не было.

DA>А?
DA>Так ты еще и свой сервачок держишь, чтобы с Хрюшами общаться?
Сервачок я держу для другого, но там да еще и почтовик крутится. А что тебя смущает ?

Здравствуйте, Олег К., Вы писали:

ОК>>>На счет сборщика мусора — достаточно знать что он есть и не считать себя (речь об интервьюерах) самым умным.
B>>Вообще, прочитав Рихтера хотя бы 1 раз и порешав задачки из "Cracking the coding interviews", можно смело проходить интервью, на подобные вопросы ты ответишь без проблем. Оно конечно потом выветривается со временем, но все равно что-то полезное остается.
ОК>Опять-таки, что это за интервью такое перед которым нужно перечитывать Рихтера да еще и решать задачки из "Cracking the coding interviews"? Снова приходим к тому что люди (интервьюеры) в силу своего низкого уровня ничего больше и не могут спросить кроме книжных вопросов или задачек.
По научному это называется "sharpen your skills", ничего плохого в перечитывании Рихтера, кстати, не вижу, и необязательно перед интервью. Ну а перед поиском новой работы грешно не потренироваться в кодинге на бумажке.

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

P>Вполне пристойно. Если с первого курса начинать работать, то это 6 лет опыта. Вполне достаточно для сеньёрства. Ну а если жевать сопли 6 лет в универе, тогда действительно фейспалм.

Перефразируя: — Все пишут. — И вы пишите.

Я себе тоже гордо написал сеньер в 24 года, потом правда через несколько лет стер, что бы не позориться.

Здравствуйте, Олег К., Вы писали:

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

ОК>Я не откажусь от своего мнения. Задавать вопросы из книжки да тупые задачки только джуны и могут. И да, Гугл все-таки согласился что ихние интервью ничего не дают.
Не пытаюсь вас переубедить. То что они с чем-то согласились еще на означает что они изменили систему рекрутинга. На career cup все те же вопросы

ОК>Ну давай, потрудись объяснить как ты применяешь на практике "ответы на свои же вопросы выше."
ОК>Ты давай не уходи в сторону. Ты лучше объясние зачем "сакральные" знания (а точнее тупая память) на вопросы выше тебе нужны в работе.
Простой реальный пример:
представьте себе — вы делаете server application на c# которое должно принимать фин. данные (напр. котировки) и пересылать клиентам по определенному протоколу порции этих данных (напр. вы используете TIBCO RVR — это не так уж и важно). Перезагружать приложение нельзя — трейдинг не может ждать. И вот со временем вы начинаете замечать что память в системе куда-то утекает. Итог незнания работы .net memory model будет OutOfMemoryException. И тогда вам придется таскать пакеты трейдерам руками А если бы вы знали особенности .net memory model, вы бы проверили вашу систему with Perf Counters и могли бы найти подходы для решения проблемы.
Могу привести и примеры для asp.net.

__>И вот со временем вы начинаете замечать что память в системе куда-то утекает. Итог незнания работы .net memory model будет OutOfMemoryException.

Ну и как же вы решили эту проблему? Как вам помогли ваши знания? Мой вопрос на ваш весьма странный ответ про "пул pinned objects" вы оставили без ответа. Пока как раз похоже, что вы втихаря, несмотря таки на то, что "трейдинг не может ждать", таки перезапускали свой сервис. Вдоволь насмотревшись перед этим (зачем-то) на перфоманс каунтеры.

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

__>представьте себе — вы делаете server application на c# которое должно принимать фин. данные (напр. котировки) и пересылать клиентам по определенному протоколу порции этих данных (напр. вы используете TIBCO RVR — это не так уж и важно). Перезагружать приложение нельзя — трейдинг не может ждать. И вот со временем вы начинаете замечать что память в системе куда-то утекает. Итог незнания работы .net memory model будет OutOfMemoryException.
А можно я задам глупый вопрос ?
Зачем это (выделено) писать на шарпе и делать непрямые пинки gc, когда можно написать на плюсах без всяких gc и непонятных задержек, да еще применить форк для расцепления рабочего демона и контролирующего демона (как только чайлд помер отфоркнуть нового чайлда, но можно и сторонними тулзами). ?

__>А если бы вы знали особенности .net memory model, вы бы проверили вашу систему with Perf Counters и могли бы найти подходы для решения проблемы.
Для мониторинга производительности — пожалуста всякие счетчики, но работать на основе их показаний — это уже близко к хакам, такого в нормальном состоянии не должно быть, ИМХО.