T>>·>А если у тебя имя спросить? Ты посчитаешь, что тебя детсадовским посчитали?
T>>Я думаю что студентов без опыта нужно спрашивать вопросы по уровню сложности от легких к сложным, а опытных нужно спрашивать наоборот от сложных к легким на примере практической реально сложной задачи которая решалась или будет решаться в компании.
·>Ок, давай вернёмся к нашему примеру. Цель — выяснить как хорошо интервьюверуемый знает C# (нам не нужен бороздитель просторов вселенной, строящий архитектуры систем, нам нужен человек, который умеет писать код) и что "9 лет опыта C#" это не выдумки. С чего нужно начать, чтобы узнать, что человек имеет представление о работе gc и понимает смысл IDisposable/using?

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

T>>>>Студентам без опыта нормально такие вопросы задавать.
T>>·>А если тебя джуниор-коллега, студент-без-опыта такое спросит?
T>>Для меня джуниор это теоретик-справочник, поэтому тупой вопрос что такое using от джуниора я считаю невозможен.
·>Джуниор может быть джуниором в C# и при этом сеньёром в C++. И кстати, как интервьюверуемый отвечает на простые вопросы ещё демонстрирует то как он умеет объяснять "очевидные" вещи.
Синьер в С++ не может прочитать справочник по С#?

·>Он может просто увидеть код с using, подойти к тебе и спросить зачем он тут и что это всё значит.
·>Чаще, конечно, такое случается не с языковыми конструкциями, а с кодом проекта. Ты с этим кодом разботал кучу лет, тебе всё понятно и очевидно, а для новичка некоторые моменты могут быть совсем неизвестны и непонятны. Придётся рассказывать простые и банальные вещи. На интервью способность рассказывать такие вещи просто и понятно легче всего проверить задав простой вопрос о том, что ты заявил ты знаешь 9 лет.

Умение быстро реверсить и понимать гигабайты существующего кода это даже не обсуждается — must have 100% иначе ты уволен.
P.S. Понятно что на проектах без архитектуры, где все свалено в одну большую индусо-копипасте-глобально-мусорную кучу — реверсинг кода может занять значительное время, но здесь уже вам решать оставаться или уходить.

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

scf>К сожалению, первый пункт необходим. Я собеседовал людей с 5+ годами опыта, плавающих в базовых структурах данных и алгоритмах, системах счисления, алгоритмической сложности, неспособных рекурсивно обойти дерево...

scf>Всё из-за кандидатов, писавших n лет код квадратно-гнездовым способом под какой-нибудь фреймворк.

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

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

MM>У меня был такой случай. Чел с очень приличным по годам опытом.

MM>Вопрос: "Расскажите, что такое финализатор".
MM>Ответ: "Знаю только, что его лучше не вызывать".

MM>Наверное, дальше мне стоило спросить, как его вызвать.

Я бы также ответил. Опыт тоже приличный.

29.03.2017 12:52, MxMsk пишет:

> У меня был такой случай. Чел с очень приличным по годам опытом.
>
> Вопрос: "Расскажите, что такое финализатор".
> Ответ: "Знаю только, что его лучше не вызывать".

Если финализатор в дотнете это примерно то же самое, что финализатор в
яве, то я бы скорректировал ответ так "лучше вообще не знать, что такое
есть".

В яве, кстати, ничего не мешает сделать его public и вызвать вручную

--
WBR,
Serge.

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

H>Если финализатор в дотнете это примерно то же самое, что финализатор в
H>яве, то я бы скорректировал ответ так "лучше вообще не знать, что такое
H>есть".
Лучше все-таки знать, когда выставляешь солидный опыт как главное достоинство. Топикстартовый using связан с IDisposable. Чтобы правильно реализовать IDisposable желательно понимать финализатор: то, как он вызывается, и какое влияние оказывает на сборщик мусора. И всё же, я уточню, что это — тема для разговора. Меня удивил ответ, я этим поделился. Не пойму, чего у некоторых бомбануло (не про тебя). Всегда казалось, что отсутствие знаний — не повод для гордости, а подтянуть навыки всегда полезно.

H>В яве, кстати, ничего не мешает сделать его public и вызвать вручную
В C# он реализуется а-ля деструктор, без области видимости и без имени. Его GC дергает при определенных обстоятельствах.

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

MM>Лучше все-таки знать, когда выставляешь солидный опыт как главное достоинство. Топикстартовый using связан с IDisposable. Чтобы правильно реализовать IDisposable желательно понимать финализатор

А какая между ними связь?

MM>В C# он реализуется а-ля деструктор, без области видимости и без имени. Его GC дергает при определенных обстоятельствах.

В С# он реализуется как метод Finalize, его можно найти и вызвать рефлекшном через GetMethod("Finalize",...) например.

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

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

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

Зачем путать необходимое с достаточным?

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

T>·>Ок, давай вернёмся к нашему примеру. Цель — выяснить как хорошо интервьюверуемый знает C# (нам не нужен бороздитель просторов вселенной, строящий архитектуры систем, нам нужен человек, который умеет писать код) и что "9 лет опыта C#" это не выдумки. С чего нужно начать, чтобы узнать, что человек имеет представление о работе gc и понимает смысл IDisposable/using?

T>Что значит знает С#? Теоретически можно знать все ключевые слова и даже знать для чего они используются но при этом писать говняный код на C#.
T>Умение хорошо архитектурить как раз и определяет будущее качество кода (не видел я паршивого кода с красивой архитектурой, а вот паршивого кода с кривой архитектурой или без архитектуры очень много видел)
У тебя с логикой проблемы. "необходимое условие, достаточное условие"? Помнишь такое в школе проходили недавно? Или вы ещё не проходили?
Да, знание ключевых слов не гарантирует знание языка и умение писать код. Но мне не приходилось видеть людей, которые имели опыт более 5 лет, писали хороший код, но не понимали смысл основных ключевых слов языка. Приведи мне пример правдоподобной ситуации, что человеку за 9 лет написания хорошего кода ни разу не пришлось использовать using и он ни разу не видел эту конструкцию в коде?

T>>>Для меня джуниор это теоретик-справочник, поэтому тупой вопрос что такое using от джуниора я считаю невозможен.
T>·>Джуниор может быть джуниором в C# и при этом сеньёром в C++. И кстати, как интервьюверуемый отвечает на простые вопросы ещё демонстрирует то как он умеет объяснять "очевидные" вещи.
T>Синьер в С++ не может прочитать справочник по С#?
Может, но это займёт больше времени, чем ответ на вопрос, тем более в контексте кода проекта, над которым вы работаете. Назначение using можно объяснить за 10-30 секунд, особенно синьёру. Это дольше чем гуглить и читать.

T>Умение быстро реверсить и понимать гигабайты существующего кода это даже не обсуждается — must have 100% иначе ты уволен.
T>P.S. Понятно что на проектах без архитектуры, где все свалено в одну большую индусо-копипасте-глобально-мусорную кучу — реверсинг кода может занять значительное время, но здесь уже вам решать оставаться или уходить.
Ага-ага. Программист программисту — волк.

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

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

MM>Здравствуйте, MxMsk, Вы писали:
Покормлю, но в последний раз.

MM>А какая между ними связь?
MSDN:

class BaseClass : IDisposable
{
   public void Dispose()
   { 
      Dispose(true);
      GC.SuppressFinalize(this);           
   }
   
   // Protected implementation of Dispose pattern.
   protected virtual void Dispose(bool disposing)
   {
    ...
   }

   ~BaseClass()
   {
      Dispose(false);
   }
}

MM>>В C# он реализуется а-ля деструктор, без области видимости и без имени. Его GC дергает при определенных обстоятельствах.
MM>В С# он реализуется как метод Finalize, его можно найти и вызвать рефлекшном через GetMethod("Finalize",...) например.
Видимо на "а-ля" решил не обращать внимание. Ок, снова MSDN:

The C# compiler does not allow you to override the Finalize method. Instead, you provide a finalizer by implementing a destructor for your class.

T>>Что значит знает С#? Теоретически можно знать все ключевые слова и даже знать для чего они используются но при этом писать говняный код на C#.
T>>Умение хорошо архитектурить как раз и определяет будущее качество кода (не видел я паршивого кода с красивой архитектурой, а вот паршивого кода с кривой архитектурой или без архитектуры очень много видел)
·>У тебя с логикой проблемы. "необходимое условие, достаточное условие"? Помнишь такое в школе проходили недавно? Или вы ещё не проходили?
·>Да, знание ключевых слов не гарантирует знание языка и умение писать код. Но мне не приходилось видеть людей, которые имели опыт более 5 лет, писали хороший код, но не понимали смысл основных ключевых слов языка. Приведи мне пример правдоподобной ситуации, что человеку за 9 лет написания хорошего кода ни разу не пришлось использовать using и он ни разу не видел эту конструкцию в коде?

У тебя какой то хороший код в вакууме всегда выходит. Понимать и умение об этом хорошо рассказать — это разные скилы. Можно понимать но ничего не рассказать — но для тебя это будет выглядеть как чел ничего не понимает. Это как уметь плавать — попробуй объясни почему ты плаваешь, а другой не может хотя с виду делает тоже самое что и ты.

T>>Синьер в С++ не может прочитать справочник по С#?
·>Может, но это займёт больше времени, чем ответ на вопрос, тем более в контексте кода проекта, над которым вы работаете. Назначение using можно объяснить за 10-30 секунд, особенно синьёру. Это дольше чем гуглить и читать.

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

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

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

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

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

Основная проблема собеседований (только в России?) в узколобых кодерах, которые почему-то думают, что им платят за знание семантики using, while или jnz.
То, что им платят за решение проблем, и большинство опытных людей для решения проблем используют не while, а list comprehensions, в узенькую кодерскую головенку, отягощенную роговыми наростами, не помещается.

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

A>Я бы также ответил. Опыт тоже приличный.

Пару раз использовал Finalize, когда работал с COM и плагинами. Изучил детали в MSDN, использовал, затем благополучно выкинул эти знания подальше.
Самое смешное, что вышеупомянутые узколобые собеседователи, чего ни коснись вне пределов их узенькой кочки зрения, используют ровно тот же подход.
А кочку зрения с using используют строго ради почесывания ЧСВ и удовлетворения чувства собственной неполноценности, возниающего от вида бухгалтерш и продажников, получающих значительно больше кодера без всяких десятилетий заучиваний этюдов C#.

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

MM>>А какая между ними связь?
MM>MSDN:

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

MM>Видимо на "а-ля" решил не обращать внимание.

Да, на предложения, не несущие смысловой нагрузки я внимания не обращаю

MM>>>В C# он реализуется а-ля деструктор, без области видимости и без имени.
MM>>В С# он реализуется как метод Finalize, его можно найти и вызвать рефлекшном через GetMethod("Finalize",...) например.
MM>

MM>The C# compiler does not allow you to override the Finalize method. Instead, you provide a finalizer by implementing a destructor for your class.

И к чему вы это тут написали? Какое это вообще имеет отношение к "без области видимости и без имени"?

"Деструктор" в С# реализуется в виде автогенерённого метода Finalize, который вполне имеет и имя и видимость(protected). Это говорится в любом букваре по C#, сразу после "не трогайте эту дрянь".
Зная эту нехитрую информацию можно даже не предпологать(интересоваться), а просто быть увереным в том, что его, этот метод, можно найти и вызвать.

Вместо тысячи слов:

    static void Main(string[] args)
        {
        var mfo = new MyFinalizeObject();
        mfo.GetType().GetMethod("Finalize", BindingFlags.NonPublic |BindingFlags.Instance |BindingFlags.DeclaredOnly).Invoke(mfo, null);
            Console.ReadLine();

    }

    class MyFinalizeObject
        {
            ~MyFinalizeObject()
            {
                Console.WriteLine("Hello, MxMsk, I'm finalizer");
            }
        }

В сухом остатке в вашем утверждении "единственный вариант(вызвать деструктор — ММ), возможно, рефлексия, но я не интересовался" неверно вообще всё: не единственный и не "возможно" а точно, и тут не надо ничем интересоваться, достаточно самых базовых знаний.
На самом деле совершенно не страшно если кто-то этого не знает: штука редкая, мало исспользуемая... Но вот то, что этот "кто-то" при этом же еще и задаёт на эту тему вопросы на собеседовании — это уже "ой!". Ну а вишенка на торте — что всё это происходит в теме "ну они тупыыыые ололо" и при этом с редким упрямством упорствуете в отрицании элементарных вполне самоочевидных вещей.

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

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

T>·>У тебя с логикой проблемы. "необходимое условие, достаточное условие"? Помнишь такое в школе проходили недавно? Или вы ещё не проходили?
T>·>Да, знание ключевых слов не гарантирует знание языка и умение писать код. Но мне не приходилось видеть людей, которые имели опыт более 5 лет, писали хороший код, но не понимали смысл основных ключевых слов языка. Приведи мне пример правдоподобной ситуации, что человеку за 9 лет написания хорошего кода ни разу не пришлось использовать using и он ни разу не видел эту конструкцию в коде?
T>У тебя какой то хороший код в вакууме всегда выходит. Понимать и умение об этом хорошо рассказать — это разные скилы. Можно понимать но ничего не рассказать — но для тебя это будет выглядеть как чел ничего не понимает. Это как уметь плавать — попробуй объясни почему ты плаваешь, а другой не может хотя с виду делает тоже самое что и ты.
Совершенно верно. Обычно в серьёзных компаниях, находящиеся в дорогих городах типа Лондона (как у топикстартера) синьёрские позиции требуют не только умение понимать, но и хорошо уметь общаться, притом не только с коллегами-программерами, но и с бизнесом, саппортом, клиентами, етс, когда надо простыми словами объяснять простые вещи людям которые не в теме.
Тупо-кодеров проще нанимать в бангладешах за копейки.

T>>>Синьер в С++ не может прочитать справочник по С#?
T>·>Может, но это займёт больше времени, чем ответ на вопрос, тем более в контексте кода проекта, над которым вы работаете. Назначение using можно объяснить за 10-30 секунд, особенно синьёру. Это дольше чем гуглить и читать.
T>Это медвежья услуга.
Как повоспитывать, так всегда пожалуйста, а вот как что-то объяснить — внезапно нет скиллов учителя.

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

T>·>Ну вот видишь, радуйся. Ты не пройдёшь такое интервью и не попадёшь в команду, где принято друг-другу помогать, рассказывая "очевидные", попадёшь в предпочитаемые тобой условия волков-одиночек, любителей жоп-секьюрити.
T>Если тебе всё время нужно разжевывать что понаписали десятки человек за десятки лет то боюсь что до решения поставленной тебе задачи ты так никогда и не дойдешь потому что всегда тебе будет что то не понятно и проще тебя уволить.
А если ты считаешь себя самым умным, тяжело и вообще западло делиться своими знаниями, то тебя вообще лучше не нанимать.

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

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

SA>Основная проблема собеседований (только в России?) в узколобых кодерах, которые почему-то думают, что им платят за знание семантики using, while или jnz.
SA>То, что им платят за решение проблем, и большинство опытных людей для решения проблем используют не while, а list comprehensions, в узенькую кодерскую головенку, отягощенную роговыми наростами, не помещается.
Скажи честно, ты много видел программеров с опытом c# 9 лет, которые используют list comprehensions (в c#? linq что-ли?), но не знают как пользоваться while и что делает using?

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

T>>>>Синьер в С++ не может прочитать справочник по С#?
T>>·>Может, но это займёт больше времени, чем ответ на вопрос, тем более в контексте кода проекта, над которым вы работаете. Назначение using можно объяснить за 10-30 секунд, особенно синьёру. Это дольше чем гуглить и читать.
T>>Это медвежья услуга.
·>Как повоспитывать, так всегда пожалуйста, а вот как что-то объяснить — внезапно нет скиллов учителя.
Ты какой то обиженный, видимо ты один из тех кто еще не успел полностью убежать от программирования в менеджмент и тебе коллеги все время указывают на твой плохой код.

·>Так учись объяснять — это чрезвычайно полезный скилл, который повысит твою стоимость на рынке труда.
Повысит если пройдешь в менеджмент, а если нет то понизит.

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

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

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

·>Скажи честно, ты много видел программеров с опытом c# 9 лет, которые используют list comprehensions (в c#? linq что-ли?)

А ты кроме LINQ других применений не знаешь, что ли?
Я видел херову гору программеров, особенно часто на собеседованиях, которые прекрасно знают все про while, но даже краем уха не слышали ни про LC, ни про инварианты, ни про верифицируемость кода.
Не умеют ни декомпозицию толком делать, ни про масштабируемость и поддерживаемость думать.
Им это просто не надо, они шлепают в своем императивном стиле процедуры на пять окон с десятью вложенными циклами и в ус не дуют. И убеждены, что этот подход единственно правильный. Вот прямо как ты или автор темы.


·>но не знают как пользоваться while

Конечно! Прямо сейчас в зеркале вижу. Что я знаю о бриллиантах while?

do
do while
do while break

do while break return
do while break return
do while break return
for if switch case default

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

·>и что делает using?

Легко! Представь, что ты несколько лет писал бизнес-логику в слое WCF. Тебе этот using нужен? Да тебе терабайты надо помнить про эту бизнес-логику и соприлегающие области. Все ненужное, согласно правилу мистера Холмса, прочь с чердака.
Using-ами пусть себе головенку забивают низкооплачиваемые низкоквалифицированные кодеры, которые ни на что выше кодера и саппортера-багофиксера не тянут.

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

T>·>Совершенно верно. Обычно в серьёзных компаниях, находящиеся в дорогих городах типа Лондона (как у топикстартера) синьёрские позиции требуют не только умение понимать, но и хорошо уметь общаться, притом не только с коллегами-программерами, но и с бизнесом, саппортом, клиентами, етс, когда надо простыми словами объяснять простые вещи людям которые не в теме.
T>Такие люди очень плохо программируют поэтому они уходят (я бы сказал сами бегут) поскорее в менеджмент чтобы не видеть код.
Ты причину со следствием перепутал. Те кто плохо программирует — пытается уйти в менеджемент — "а вдруг получится".

T>>>Это медвежья услуга.
T>·>Как повоспитывать, так всегда пожалуйста, а вот как что-то объяснить — внезапно нет скиллов учителя.
T>Ты какой то обиженный, видимо ты один из тех кто еще не успел полностью убежать от программирования в менеджмент и тебе коллеги все время указывают на твой плохой код.
Во-первых, не переходи на личности. Во-вторых, за код меня таки хвалят и о using прекрасно я знаю, хотя опыта c# у меня 9 дней, а то и меньше, в общей сложности. Но чую, если бы я умел объяснять получше, то я мог бы зарабатывать раза в 1.5 больше.

T>·>Так учись объяснять — это чрезвычайно полезный скилл, который повысит твою стоимость на рынке труда.
T>Повысит если пройдешь в менеджмент, а если нет то понизит.
Недотехнарь-менеджер зарабатывает меньше большинства хороших технарей, и уж точно меньше, чем технарь-менеджер.

T>>>Если тебе всё время нужно разжевывать что понаписали десятки человек за десятки лет то боюсь что до решения поставленной тебе задачи ты так никогда и не дойдешь потому что всегда тебе будет что то не понятно и проще тебя уволить.
T>·>А если ты считаешь себя самым умным, тяжело и вообще западло делиться своими знаниями, то тебя вообще лучше не нанимать.
T>То что пишут в книгах я вообще за какие то особые знания не считаю потому что любой может взять книгу и прочитать, а вот то чего не пишут в книгах здесь действительно делиться информацией от меня зависит: хочу я это делать или нет, нужно мне это или нет.
И зря. Уверен, что если ты поднаберёшься опыта, то изменишь своё мнение.

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

·>А если ты считаешь себя самым умным, тяжело и вообще западло делиться своими знаниями, то тебя вообще лучше не нанимать.

А кем себя считают те, кому западло делиться знаниями про Finalize, using или while? И они это свое заподлятское отношение проявляют на собеседованиях?

·>И зря. Уверен, что если ты поднаберёшься опыта, то изменишь своё мнение.
Моё мнение пока такое: брать тех которых не нужно учить(они самообучаемые), которые умеют во всем сами разобраться имея на руках минимум информации и придерживаются техники самодокументированного кода с хорошими архитектурными скилами.