Согласен, но обычно такой уровень "всплывает" на более общих вопросах. А если есть сомнения в том, что кандидат знает базовые вещи, можно действительно вернуться в к основам: спросить про сборщик мусора или замыкания/прототипы в javascript. Возможно мне всегда попадались опытные кандидаты, которых про GC спрашивать смысла не было.
Да и мне лично надоедает на вопрос о GC из раза в раз читать пятиминутную "молитву" про поколения и финализацию, когда уже видно, что никто меня не слушает =)
Полностью согласен с автором статьи, в регулярном посещении собеседований есть определенный смысл. Как минимум можно узнать о своих пробелах и об условиях работы в других компаниях.
Когда только начинал ходить по собеседованиям стал вести конспект (cheat sheet) со всеми незнакомыми вопросами, дополняю до сих пор. Конспект увеличился до отдельных монструозных документов по базам, архитектуре, сетям, javascript и основному языку.
Помню насколько было интересно оказаться по другую сторону баррикад, когда допустили участвовать в собеседованиях. Поначалу со страхом наблюдал, как мои коллеги разносят кандидатов, спрашивая про тонкости работы виртуальной машины, специфические конструкции/структуры языка sql, позже и сам пытался придумать как можно более изощренные вопросы. Сейчас уже не вижу особого смысла задавать вопросы для проверки эрудиции кандидата, все таки основная цель собеседований - за ограниченное время понять, сможет ли кандидат выполнять задачи в команде или нет. Поэтому и собеседования, в которых я сейчас участвую, могут показаться очень простыми: только поверхностные вопросы по языку, архитектуре и пр., проверяющие необходимый минимум знаний.
Также когда сам прохожу собеседования, могу понять какие из заданных вопросов, действительно имеют смысл, а какие смысловой нагрузки не несут. Если кандидат может рассказать про работу сборщика мусора, это говорит лишь о том, что ему уже задавали этот вопрос на предыдущих собеседованиях, но ничего не говорит о том, как человек будет решать задачи.
Что касается отказов после получения оффера, считаю что компании должны быть готовы к отказам, пока на собеседованиях задают вопросы вроде: “назовите 4 авторов GoF?”, “что вернет GetHashCode если его не переопределить?”, “что будет если поместить структуру в lock?”, “что вернет метод переопределенный с помощью оператора new?” (примеры из .NET).
Здравствуйте, мог бы забрать одну из следующих книг (в зависимости от наличия) завтра где-то в 18:30:
React Up & Running
Architecturing for Scale
Linux System Programming
У автора достаточно много проектов на github. Очень хорошее начало, сразу видно, что человеку действительно нравится программирование. Все мы когда-то были студентами =)
Повторюсь, выбор был сделан до моего подключения к проекту. Если бы я писал проект с нуля — использовал бы resx.
В общем, если использовать для локализации средства WPF (с утилитой LocBaml), так или иначе приходиться тянуть строки из словарей ресурсов. Да, локализация WPF не самый лучший инструмент по сравнению с resx.
Локализация с помощью RESX файлов действительно удобнее. Однако бывают ситуации, когда выбор уже был сделан в пользу локализации WPF. Приходится работать с тем что есть. В этом случае кстати выручает Text Template, описанный в предыдущей статье.
На ум приходят две ситуации, когда приходится из xaml тянуть ресурсы/контролы в code behind:
1. При создании кастомных контролов приходится разносить ControlTemplate и класс контрола на отдельные файлы если мы хотим, чтобы от нашего контрола можно было наследоваться. Для обращения к внутренним элементам контрола из кода приходится также обращаться к xaml.
2. При использовании WPF локализации, увы, строки приходится хранить в xaml-ресурсах. Доступ к строкам в code behind как раз осуществляется через ресурсы приложения.
VISTALL, изначально я не выбирал конкретный проект, было интересно узнать насколько вообще реально внести изменения в open source продукт. На практике выяснилось, что с проектом SharpDevelop работать проще всего. Кроме того, мне понравилось качество кода, архитектура, реализация плагинной системы и синтаксического анализа (библиотека NRefactory).
Мне тоже задача с кнопкой закрытия показалась странной, однако я решил, что если задача висит на трекере, ее можно выполнить. Это и было моей ошибкой.
Новую функциональность предложить конечно можно, однако непонятно каким образом команда должна «одобрить» задачу. Я, например, создал задачу #4965, однако выполнять её я даже не возьмусь, так как непонятно будут ли изменения приняты командой. Остается только править баги в плеере.
Согласен, но обычно такой уровень "всплывает" на более общих вопросах. А если есть сомнения в том, что кандидат знает базовые вещи, можно действительно вернуться в к основам: спросить про сборщик мусора или замыкания/прототипы в javascript. Возможно мне всегда попадались опытные кандидаты, которых про GC спрашивать смысла не было.
Да и мне лично надоедает на вопрос о GC из раза в раз читать пятиминутную "молитву" про поколения и финализацию, когда уже видно, что никто меня не слушает =)
Полностью согласен с автором статьи, в регулярном посещении собеседований есть определенный смысл. Как минимум можно узнать о своих пробелах и об условиях работы в других компаниях.
Когда только начинал ходить по собеседованиям стал вести конспект (cheat sheet) со всеми незнакомыми вопросами, дополняю до сих пор. Конспект увеличился до отдельных монструозных документов по базам, архитектуре, сетям, javascript и основному языку.
Помню насколько было интересно оказаться по другую сторону баррикад, когда допустили участвовать в собеседованиях. Поначалу со страхом наблюдал, как мои коллеги разносят кандидатов, спрашивая про тонкости работы виртуальной машины, специфические конструкции/структуры языка sql, позже и сам пытался придумать как можно более изощренные вопросы. Сейчас уже не вижу особого смысла задавать вопросы для проверки эрудиции кандидата, все таки основная цель собеседований - за ограниченное время понять, сможет ли кандидат выполнять задачи в команде или нет. Поэтому и собеседования, в которых я сейчас участвую, могут показаться очень простыми: только поверхностные вопросы по языку, архитектуре и пр., проверяющие необходимый минимум знаний.
Также когда сам прохожу собеседования, могу понять какие из заданных вопросов, действительно имеют смысл, а какие смысловой нагрузки не несут. Если кандидат может рассказать про работу сборщика мусора, это говорит лишь о том, что ему уже задавали этот вопрос на предыдущих собеседованиях, но ничего не говорит о том, как человек будет решать задачи.
Что касается отказов после получения оффера, считаю что компании должны быть готовы к отказам, пока на собеседованиях задают вопросы вроде: “назовите 4 авторов GoF?”, “что вернет GetHashCode если его не переопределить?”, “что будет если поместить структуру в lock?”, “что вернет метод переопределенный с помощью оператора new?” (примеры из .NET).
React Up & Running
Architecturing for Scale
Linux System Programming
Хочу отдельно отметить, что стиль изложения в этой части лучше. Текст гораздо легче читается.
В общем, если использовать для локализации средства WPF (с утилитой LocBaml), так или иначе приходиться тянуть строки из словарей ресурсов. Да, локализация WPF не самый лучший инструмент по сравнению с resx.
1. При создании кастомных контролов приходится разносить ControlTemplate и класс контрола на отдельные файлы если мы хотим, чтобы от нашего контрола можно было наследоваться. Для обращения к внутренним элементам контрола из кода приходится также обращаться к xaml.
2. При использовании WPF локализации, увы, строки приходится хранить в xaml-ресурсах. Доступ к строкам в code behind как раз осуществляется через ресурсы приложения.
Новую функциональность предложить конечно можно, однако непонятно каким образом команда должна «одобрить» задачу. Я, например, создал задачу #4965, однако выполнять её я даже не возьмусь, так как непонятно будут ли изменения приняты командой. Остается только править баги в плеере.