Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Что спрашивать кандидатов на роль Sr. .Net developer

Всем привет.
Вкратце:
По чем гонять кандидатов на роль Sr. .Net developer?

Детально
В компании созрела необходимость расширяться и меня попросили по собеседовать парочку крутых перцев по .NET с уклоном в web
Выбрать нужно лучшего, поэтому спрашивать тривиальные вещи наверное не имеет смысла. Есть лишь одного ограничение — спрашивать надо по .Net стеку.
Набросал небольшой список вопросов:
— многопоточность
— асинхронные операции
— автоматическое управление памятью
— типы данных (ссылочные, типы значения)
— ООП
— события, делегаты
— Linq
— Паттерны
— всякие заковыристые вопросы по asp.net mvc
— веб сервисы
— Java script
— Jquery
— можно еще алгоритмы/структуры спросить- но думаю это уже будет перебор.
Что еще подскажите?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Если человек в должности snr до вашего проекта проработал лет пять (в одной-двух компаниях), то гонять его по теории — глупая трата времени. Если ему надо будет, он разберется с чем угодно. Лучше расспросите о тех задачах, с которыми ему приходилось сталкиваться, о методологии программирования, которые применяла его команда, об инструментах, которыми он пользуется, о его проектах на github и постах с ответами на stackoverflow , о его личных качествах.
Мало кто может утверждать, что его проект — это то, что перевернет мир. Обычно это обычный продукт для обычного рынка от обычного заказчика. Зачем тогда все эти ужимки? Обычный специалист за рабочий день выдаст решение лучше, чем за 10 минут на интервью.
Распознавайте, сможет ли он это, а не проверяйте его память.

Название темы говорит о том, что вы сами не знаете, какой вам нужен кандидат. Таким способом вы можете найти человека, который больше всех прочитал и ЗАПОМНИЛ перед собеседованием. Хороший специалист не должен знать наизусть кучу теории или всего рихтера (да и найдите мне человека, который может все это запомнить), он должен уметь находить и обрабатывать информацию, необходимую для решения конкретных задач в кратчайшие сроки и выбирать наиболее правильное решение.
Я вижу себе процесс собеседования так:
Вы определяетесь зачем вам нужен человек — к примеру необходимо добавить новый сервис в продукт. Упрощаете задачу до такой, которую можно решить за адекватное время — 2-3 часа. Еще лучше, если вы даете человеку приемочные тесты, с помощью которых определяется процент выполненной работы. Затем приходите и делаете код ревью вместе с ним.
Лучшее собеседование — это эмуляция реального рабочего процесса. Так можно избежать ситуации, когда человека на собеседовании спрашивают одно, а на деле необходимо делать совсем другое.
Если интересно, на techcrunch была статья по поводу тех. собеседований — techcrunch.com/...erview-is-dead

1) многопоточность — особо актуально для тырпрайза с уклоном в веб, да.
2) асинхронные операции — см. 1)
3) автоматическое управление памятью — оно есть, достаточный ответ?
4) типы данных (ссылочные, типы значения) — см. 1)
5) ООП — каждый синьор должен без запинки оттарабанить, чем интерфейс отличается от абстрактного класса, иначе мир поглотит тьма.
6) события, делегаты — что тут спрашивать?
7) Linq — бесполезная хрень, хранимку-то хоть можно отладить через teamviewer на живой базе, в отличие от.
8) Паттерны — о, да, детка, добавь еще этих хрустящих фабрик синглтонов да выпей чаю.
9) всякие заковыристые вопросы по asp.net mvc — вас в детстве побил синьор?
10) веб сервисы — атрибут [WebService]
11) Java script — при чем тут дотнет?
12) Jquery — ага, надо погуглить с этим словом чтобы скачать крутые UI штуки для нашего сайта, например jquery calendar.
13) можно еще алгоритмы/структуры спросить- но думаю это уже будет перебор — та не, нормально, чо. Пусть покажет, какой он крутой, а то зажрались совсем, пока честные пацаны вкалывают. И Кнута, пусть Кнута наизусть цитирует, ска.

Приходит юниор — спрашивают о проектах. Приходит синьор — спрашивают хрень из справочников. Так и живем.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Коментар порушує правила спільноти і видалений модераторами.

Если по вопросам, которые привел топикстартер, реально собеседуют украинских Sr. .Net developer, то боюсь что инфляция тайтлов достигла просто катастрофических показателей. Такими темпами скоро на должность CEO будем спрашивать знание Outlook

Особенно если «алгоритмы/структуры это уже перебор»

На должность СЕО никто ничего не спрашивает.

А я то думаю, почему мой знакомый туда подался ) разработчик с него был никакой (видимо собеседование на сениора не мог пройти), а в СЕО и так взяли :)))

Не только сам себе, у меня аж 10 человек в конторе.

1) многопоточность — особо актуально для тырпрайза с уклоном в веб, да.
2) асинхронные операции — см. 1)
3) автоматическое управление памятью — оно есть, достаточный ответ?
4) типы данных (ссылочные, типы значения) — см. 1)
5) ООП — каждый синьор должен без запинки оттарабанить, чем интерфейс отличается от абстрактного класса, иначе мир поглотит тьма.
6) события, делегаты — что тут спрашивать?
7) Linq — бесполезная хрень, хранимку-то хоть можно отладить через teamviewer на живой базе, в отличие от.
8) Паттерны — о, да, детка, добавь еще этих хрустящих фабрик синглтонов да выпей чаю.
9) всякие заковыристые вопросы по asp.net mvc — вас в детстве побил синьор?
10) веб сервисы — атрибут [WebService]
11) Java script — при чем тут дотнет?
12) Jquery — ага, надо погуглить с этим словом чтобы скачать крутые UI штуки для нашего сайта, например jquery calendar.
13) можно еще алгоритмы/структуры спросить- но думаю это уже будет перебор — та не, нормально, чо. Пусть покажет, какой он крутой, а то зажрались совсем, пока честные пацаны вкалывают. И Кнута, пусть Кнута наизусть цитирует, ска.

Приходит юниор — спрашивают о проектах. Приходит синьор — спрашивают хрень из справочников. Так и живем.

Приходит юниор — спрашивают о проектах. Приходит синьор — спрашивают хрень из справочников. Так и живем

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

Если человек в должности snr до вашего проекта проработал лет пять (в одной-двух компаниях), то гонять его по теории — глупая трата времени. Если ему надо будет, он разберется с чем угодно. Лучше расспросите о тех задачах, с которыми ему приходилось сталкиваться, о методологии программирования, которые применяла его команда, об инструментах, которыми он пользуется, о его проектах на github и постах с ответами на stackoverflow , о его личных качествах.
Мало кто может утверждать, что его проект — это то, что перевернет мир. Обычно это обычный продукт для обычного рынка от обычного заказчика. Зачем тогда все эти ужимки? Обычный специалист за рабочий день выдаст решение лучше, чем за 10 минут на интервью.
Распознавайте, сможет ли он это, а не проверяйте его память.

Нафига говорить о методологиях, я не понимаю (вчера спрашивали на интервью), да мы клеяли стикеры на доску и правда у нас был багтрекер?

Название темы говорит о том, что вы сами не знаете, какой вам нужен кандидат. Таким способом вы можете найти человека, который больше всех прочитал и ЗАПОМНИЛ перед собеседованием. Хороший специалист не должен знать наизусть кучу теории или всего рихтера (да и найдите мне человека, который может все это запомнить), он должен уметь находить и обрабатывать информацию, необходимую для решения конкретных задач в кратчайшие сроки и выбирать наиболее правильное решение.
Я вижу себе процесс собеседования так:
Вы определяетесь зачем вам нужен человек — к примеру необходимо добавить новый сервис в продукт. Упрощаете задачу до такой, которую можно решить за адекватное время — 2-3 часа. Еще лучше, если вы даете человеку приемочные тесты, с помощью которых определяется процент выполненной работы. Затем приходите и делаете код ревью вместе с ним.
Лучшее собеседование — это эмуляция реального рабочего процесса. Так можно избежать ситуации, когда человека на собеседовании спрашивают одно, а на деле необходимо делать совсем другое.
Если интересно, на techcrunch была статья по поводу тех. собеседований — techcrunch.com/...erview-is-dead

99% интервьюеров не способны на такое

значит им пора сменить работу на ту, где они смогут.

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

Во времена гугл и еще сотен тысяч таких же «хороших специалистов» без знаний теории, можно склепать в кратчайшие сроки целое приложение из оптимальных решений, которые вам подберет stackoverflow посчитав все лайки.

Тут стоит глянуть на запад и обратить внимание что у НИХ обычно еще стоит условие 8+ лет опыта для Sr. (в среднем). И не надо тут рассказывать что выслуга лет ничего не значит, теория без практики мертва.
С таким практическим опытом за плечами можно и методом гугления в случае чего работать. Все в голове не умещается.

То есть вы не пользуетесь гугл и стэковерфлоу?))
Ну а если по делу — я не писал «тупо взять и скопировать код», я написал «обрабатывать информацию» и «выбирать наиболее правильное решение», что требует определенных навыков.
Объять необъятное нельзя — вы не можете держать в памяти вообще все, что когда либо читали, учили или использовали. Это свойство человеческой памяти — заменять неиспользуемую информацию той, которая востребована в данный момент. Гугл и стэковерфлоу появились в нашем мире не просто так, а как решение конкретных проблем — поиск информации, коллективное обучение и передача опыта, если говорить более абстрактно.
Но этими инструментами нужно уметь пользоваться — вот это и будет отличать «хорошего специалиста» от действительно хорошего специалиста.
Для этого и нужен совместный код ревью — если код бездумно скопирован, это станет понятно очень быстро. Как альтернативу можно использовать статический анализатор кода.

Правда где-то посередине.
Ну тут вы не правы.

Хороший специалист не должен знать наизусть кучу теории
раз уж речь про технических специалистов.
Но этими инструментами нужно уметь пользоваться — вот это и будет отличать «хорошего специалиста» от действительно хорошего специалиста.
Хорошего специалиста отличают совершенно другие качества и навыки. Уметь пользоваться api-reference должен любой программист, а не только хороший. И если кто-то нагуглил что-то быстрее это отнюдь не определяющий криетрий уровня квалификации хорошего специалиста.

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

Если человек, вместо изобретения велосипеда полезет в гугл — это замечательно. Умение пользоваться справочниками — тоже одно из требований к грамотному спецу.

P.S. Если интервьюер вместо прямого вопроса по теории, не может дать задачу на проверку этой теории — то либо данная теория не нужна, либо интервьюер плох.

Можете дать пример такой теории в дотнете?

Какой? Которой интервьюер не может найти применение?

той, в которой срабатывает правило

данная теория не нужна
потому что нельзя дать задачу на проверку теори.

Я не знаю теории, на которую не смог бы дать задачу/задачи.

выходит в абсолюте бесполезной теории не бывает?

нет, я просто её не знаю/не помню.
К тому же, есть различные контексты задач. Скажем, в большинстве случаев, вам не нужно знать, как реализована стандартная сортировка.

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

Как часто вам приходилось создавать собственную функцию сортировки? Реализация, прирост производительности — в студию.

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

Как часто вам приходилось создавать собственную функцию сортировки?
Этого я не говорил, зачем придумывать.

Вы хоть читали мой комментарий? :)

в большинстве случаев, вам не нужно знать, как реализована стандартная сортировка.
Или вы знаете языки,в которых стандартная сортировка — это пузырьком?
Этого я не говорил, зачем придумывать.
Отлично, значит я таки прав.
Отлично, значит я таки прав.
Правило демагога № 47 «Помни, в споре нет победы, поэтому смело в любой момент объявляй, что ты победил, умыл, урыл и ткнул оппонента.»
Этого я не говорил, зачем придумывать.
Уже сказали :)

И всё-таки, как часто Вам приходится выбирать какую сортировку использовать? У меня в 99% случаев сортировка происходит на уровне БД, а редкий 1% обходится стандартной быстрой сортировкой, уже любезно реализованной майкрософт, и как правилоь там максимум пару сотен значений, обычно десятки, поэтому даже если бы я заюзал пузырьковую это бы роли не сыграло

И всё-таки, как часто Вам приходится выбирать какую сортировку использовать?
Часто на back-end-е, а это примерно 3-4 раза в месяц, как во время написания своего кода, так и во время поиска узких мест профайлером в существуюем. Места — обработка больших наборов объектов в коллекциях.

чувааак, не томи, прирост производительности, и на что меняли. Это ж самое интересное в оптимизации.

Стандартных алгоритмов хватает. Сначала потратим день на придумывание «супер алгоритма», еще день на реализацию, а потом выясним что и медленнее и памяти жрет... Конструирование велосипедов не самое лучшее занятие.

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

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

Повторюсь, вам где-то, кроме собеседований, приходилось юзать что-нибудь кроме .sort() и ей подобных?

отлично,

Реализация, прирост производительности — в студию.
нет, я просто её не знаю/не помню.
абсолютных примеров вы привести не можете. ситуативные как мы выяснили — не аргумент, для однозначных заявлений.
Как же тогда однозначно можете писать — «нет»?

это тип как я пока не встречал инопланетян, но ответственно заявляю — они существуют? :)

читайте внимательно, и последовательно:

Если интервьюер вместо прямого вопроса по теории, не может дать задачу на проверку этой теории — то либо данная теория не нужна, либо интервьюер плох.
Могу перефразировать: «Если интервьюер не знает практического применения теории, то стоит заменить интервьюера или признать, что данная теория не существенна»

Я довольно быстро забываю теорию, если не знаю, как её использовать.

P.S. Табличку Менделеева часто на собеседованиях спрашиваете?

представьте и про ПДД меня на собедеования тоже не спрашивают :)

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

Собеседование — это проверка. Если вы проверяете «какие-то локальные абстрактные вещи» — то вы получите человека, который хорошо умеет писать «какие-то локальные абстрактные вещи». Лично мне нужны несколько другие сотрудники.

представьте и про ПДД меня на собедеования тоже не спрашивают :)
Ну если Вы устраиваетесь водителем, то конечно важно и про ПДД спросить.
Не так давно на ДОУ была дискуссия, должен ли интервьювер уметь найти угол треугольника, задачка для 5-го класса. Вроде и задача элементарная, но встаёт вопрос — вы ищете программиста или школьника? Т..е Вам шашечки или ехать?

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

Когда начинаешь много знать, возникает такая естественная проблема — мозг начинает забывать то что ты хорошо знал раньше, но долго не использовал. Т.е. я например раньше хорошо решал тригонометрию, но сейчас не освежив формулы в памяти я не смогу решить наверно и простейшего уравнения. Аналогично и с сортировкой, в универе писал разные сортировки, но за 10 лет работы если не считать собеседования, то в реальных проектах только 1 раз пришлось написать сортировку, и то быструю сортировку, а не какую-то экзотическую, по причине того что её реализации там где мне нужно было (Win CE) — не было на тот момент. Сейчас она по-моему есть везде.
Т.е. если спросить, смогу ли я написать какую угодно сортировку — я отвечу что смогу, но если на собеседовании попросить написать сортировку слиянием или вставками, я с ходу без подготовки не напишу, несмотря на то, что с пол года назад освежал знания по сортировкам (ну как освежал, читал статьи на хабре)). Ну вот не хочет мозг помнить хорошо то, что он считает что мне нафиг не нужно

Вопрос не в противопоставлении, вопрос в компоновке, и подборе теории.

Один из самых ярких примеров у меня был, когда меня брали на должность senior php dev. Меня спросили про интерфейс-абстрактный класс и работу с указателями (в пыхе указателей нет).

А работать пришлось с drupal6(фреймворк на функциях, ООП только как хранилища данных). Но о нем на собеседовании не было ни слова.

Вопрос: нахер нужно такое собеседование?

Вопрос в том что не все физически способны держать в голове дословно такие запасы информации «дословно». Скажем если я сейчас не напишу по памяти феншуйную реализацию синглтона на бумажке — я однозначно плохой специалист? Читал сто раз, но как то вот использовалось редко. Зато я знаю где найти эту информацию в течении пол минуты. Вопрос в том, что нахера теорию помнить напамять? :)

Если вы не сможете на бумажке, на *ваш выбор ЯП* написать класс, в котором закрыт конструктор (если ЯП позволяет) и есть статическая функция для возврата экземпляра класса — то таки я бы начал сомневаться, что вы за программист :)

Ну а если вы просто не знаете что такое «синглтон» — то и фиг с ним. Хотя общению может мешать.

Там «не все так просто» ;) Регулярный срач на тему как лучше возникает раз в пару лет:
habrahabr.ru/post/147373
msdn.microsoft.com/...y/ff650316.aspx
А некоторые считают что это антипаттерн и плохой подход
blogs.clariusconsulting.net/...bientsingleton
accu.org/...hp/journals/337
По моему скромному мнению, далеко не самый используемый паттерн(да и паттерн ли), та же абстрактная фабрика или команда используются чаще и более актуальны для собеседования. Но нет, будем мучать синглтон.

А это уже совсем другой вопрос :)

То есть разработчик который не знает что такое синглтон лучше, чем тот который не может его по памяти на бумажке изобразить? :))) Где тут логика?

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

Где тут логика?
В менеджерском подходе — созвать митинг/вылить кучу слов + найти виноватого, это и называется «результатом» с его точки зрения.

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

Есть у меня знакомый девелопер, который знает наизусть все GOF 23 шаблона + несколько кастомных. Ни один внятно не может объяснить, а придумывает совершенно дикие аналогии и прыгает от темы к теме. В общем с ним общаться крайне тяжело.

Если девелопер не смог изобразить синглтон на бумажке, то это катастрофа, страшно подумать шо он в коде напишет.
Пойду повешусь.
Есть у меня знакомый девелопер, который знает наизусть все GOF 23 шаблона + несколько кастомных. Ни один внятно не может объяснить, а придумывает совершенно дикие аналогии и прыгает от темы к теме. В общем с ним общаться крайне тяжело.
Это все потому что у нас собеседования такие.

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

Я тоже пользуюсь шаблоном Синглтона уже лет 10 минимум, а что он именно синглтон узнал только сегодня :))))

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

Ну так вам же рот не заклеили. Вот и узнавайте, что человек скопипастил и зачем. Это и называется собеседование.

Если человек полезет и скопипастит из гугла код, совершенно не понимая как он работает
... то он скорее всего индус!
Я, честно говоря, такого на своей памяти не встречал в наших широтах. Хотя уже давненько с джунами дела не имел, с другой стороны. Но синьоров это уж точно никак не касается.

Если кандидат за 2 часа нашел решение задачи «добавления нового сервиса», зачем его брать? Сказать «спасибо» и поручить джунам кодинг его решения ))) :light trolling off:

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

+ Умение разобраться в НЕХ и заставить ее работать

1) почему вы ушли с предыдущего места работы?
2) нарисуйте домик !
3) кем вы видите себя через 5 лет?

И обязательно «почему вы хотите работать именно в нашей компании?»

Разумеется и устроить экзамен по их компании — когда основана, кто руководитель, какие копротивные ценности, без этого никак.

«Чем отличается абстрактный класс от интерфейса?» — и проследить за реакцией.

5) «Сыры каких сортов вы предпочитаете в это время суток?» — забыли

«Почему вы хотите, чтобы я у вас работал?
Где вы видите свою компанию через 5 лет?
Напишите пример алгоритма выдачи мне зарплаты»

По платформе, вопросы из Рихтера — CLR via C#.
Если типичный веб asp.net и не legacy технологии)
Хороший Веб-девелопер, должен знать, что происходит в 70-80% случаев в любом месте указанных схем и каким путем можно расширять/подменять эти места для чего + знание интерфейсов на этих звеньях как минимум концептуально.
MVC pipe
WebApi pipe

Задайте сначала себе и вашему руководству один вопрос: «нахер нам нужен этот человек?».
Если действительно только для того, чтоб рассказывать теорию — то юзайте гугл, это дешевле.

По теме:
1. Если человек сейчас без постоянной работы — проще предложить поработать месяц с подневной оплатой и попробовать в бою, так сказать. Ибо знания знаниями, а впишеться ли человек в проект и команду и как... Не нравиться — заплатили и попрощались.
2. Для веба — поспрашивайте по настройке/администрированию IIS под серверной Windows. Сразу будет видно, занимался ли человек вебом, или книжки читал.
Так просто, чисто поржать, каверзный вопрос на тему «очень умного» стандарта ECMA-262 — как записать значение текущей даты в поле в БД.

Коментар порушує правила спільноти і видалений модераторами.

Главное не забыть про having и group by просить (какой то волшебный олень когда то решил что знание ответа на этот вопрос показывает знание баз данных и sql)
upload.wikimedia.org/...palm_statue.jpg
При это, интересоваться на тему ADO или там entity — не обязательно.

Я не писал весь список, а некоторые кстати не знают что это такое...

Как часто вы реально использовали это в работе? Вот именно когда очень важен это нюанс? :)
Или как часто приходиться работать с GC в вебе? :)

если говорить о SQL, ну примерно раз-два в месяц приходится чтото выбрать. Наша база это несколько миллионов записей, так что EF не используем. Если говорить о GC то стоит задумыватся каждый раз когда открываешь файл, соединение или что угодно что требует правильной очистки. Хоть веб хоть десктоп, не имеет значения везде эти знания нужны. Конечно исключение это Веб студии, но это не интересно, как минимум лично мне.

1. То есть раз в месяц приходиться выбирать используя having или раз в месяц просто выбирать? :) Я уж про индексы молчу, это отдельный «вид спорта».
2. GC и открытие файлов и проч. Это вы имеете в виду переодически дергать collect() с целью поубирать различный мусор в памяти? :) Вы считаете это реально правильный подход? ;)
GC я реально вникал один раз, когда работал с железками и DCOM. Вот там да, есть нюансы. Но 99% разработчиков они не нужны.

1. Просто выбирать не совсем простой запрос.
2. Мне интересно знает ли кандидат почему IDisposable паттерн выглядит именно так как он выглядит и зачем там вызывать GC.SuppressFinalize. А что бы это обьяснить нужно знать как GC работает.
Я просто написал список который мы считаем нужным, а Вам уже решать интересен ли он Вам или нет. Не стоит разводить демагогию, где не нужно, мы выбираем людей под наш проект, у вас могут быть другие требования при выборе людей.

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

То есть раз в месяц приходиться выбирать используя having или раз в месяц просто выбирать?
Немного удивляет такие вопросы. У нас очень часто приходится разработчикам работать с базами "ручками«- и запросы на выборку с группировками и условия по групировкам- это не высшая математика.
Я уж про индексы молчу, это отдельный «вид спорта».
С индексами тоже всё просто- надо просто понимать как работает конкретная rdbms, уметь пользоваться explain plan, встроенными отчетами, трассировками и отладочными средствами, другими словами- человек с тайтлом Sr. — обязан знать свои инструменты.

SQL программирование — все же несколько отдельная дисциплина и крайне полезно иметь под нее выделенного специалиста. Т.к. там может крыться до 90% производительности продукта.

Согласен с вами — тонкий тюнинг простыней SQL-запросов лучше отдать DBA.
Но любой senior не-фронт-ендщик обязан знать базовые и расширенные возможности SQL, в т.ч. having и индексы хотя бы 1-й базы, иначе это не senior, а профанация.

Согласен.
Кстати прекрасный тест — попросить вывести селектом записи из одной таблички не горизонтально, а вертикально. ;)

Это даже более «нужный» скилл чем озвученные раньше :)))))))))))))))))

>senior не-фронт-ендщик обязан знать базовые и расширенные возможности SQL

Теперь вроде и фронтендщикам надо это знать — базы делают прямо в браузерах

1. Не все проекты связанны с многомилионными БД.
2. Это работа «Database Engineer». По хорошему. В нормальном раскладе. У нас конечно не так, но надо понимать что человек любой претендующий на должность знает все нюансы этого процесса хотя для Oracle и MS SQL. А ведь есть еще DB2 e.t.c. А так же есть виды спорта когда запрос нельзя поменять...
По мимо этого, есть еще вид спорта типа Data mining.

знает все нюансы этого процесса хотя для Oracle и MS SQL
Это очень смелое утверждение. Лично я знаю двух людей в Киеве, более-менее знающих все нюансы оракла и этих людей оракл и ibm барыжит по 5к негривен в день консалтом. И стоит очередь.
Не ДБ-спец в лучшем случае может расчитывать на запросы качества «не огрести от ДБА немедленно», а для майнинга так и «сформулировать ДБ-спецу что надо и получить от него квери/процедуру».
В MSSQL свои приколы, обычно выражающиеся в интересном поведении при большом количестве клиентов и утилизации железа. НЕТ спец это может знать со слов ДБА-ДБ-спеца, но редко по своему опыту.

Я же не о вообще всех нюансах говорил, так что в целом полностью поддерживаю сказанное вами.

Если у вас есть какие-то отчёты в приложении, будь то отчёт по кассе или статистика убитых мобов, то в 95% случаев правильно будет использовать группировку на уровне СУБД (писать ручками запрос или использовать какой-то билдер — это на вкус, но без понимания что происходит на уровне базы вряд ли что получится хорошее — на днях вот оптимизировал отчёт, вешавший базу на два порядка? просто перечислив поля, которые реально нужны и добавив в группировки ORDER BY NULL). А ещё в 4% — сделать денормализацию и агрегировать триггерами.

Это зависит от того — что для Вас более ценно в данный момент.
Если СУБД перегружена по процу/памяти и доставить недорого уже никак — выносить на апликэйшн, а то и на клиента.
Если дорог трафик — максимум на уровне СУБД.
Если сервак СУБД один (или HA кластер), а апликэйшнов завались — переносить туда.
Ну и еще сотня вариантов.
Наверное это правильно назвать DevOps — работа интересная и очень перспективная по идее.

А что не так с EF? Или вы сразу несколько миллионов записей селектите?

Если говорить о GC то стоит задумыватся каждый раз когда открываешь файл, соединение или что угодно что требует правильной очистки.
Да, стоит задуматься об освобождении памяти и unmanaged ресурсов. То есть юзать using, Dispose() и т.д. К GC это имеет весьма косвенное отношение.

Ну если у вас все так просто то я очень рад... :)

о GC то стоит задумыватся каждый раз когда открываешь файл
Например
using (var fs = new FileStream("dummy.txt", FileMode.Open)) { }
И много здесь работы для GC? И о чем тут думать каждый раз то?

И спасибо что порадовались за меня, оччень приятно

Если человек не может внятно ответить по having и group by, то SQL он явно не знает.

Вот откуда ноги растут у данного убеждения? :)))

Потому что эти конструкции важная часть SQL. Я бы сказал, что лишь чуть менее важная, чем различные JOIN. И это не какие-то вендорские расширения, а часть стандарта. Да, в некоторых проектах группировка не используется, но вообще задача агрегации данных из таблиц очень частая и делать её на стороне приложения без понимания того, что её можно сделать на стороне СУБД, без адекватного обоснования почему мы её делаем на апп-сервере, а не средствами СУБД — в лучшем случае преждевременная оптимизация. В худшем — умышленное причинение вреда работодателю, саботаж.

Или сокращение затрат на разработку и повышение «прозрачности» решения ;)

Таким макаром можно любую лажу оправдать

Мы здесь работу работаем, а не коллайдер строим. Понимать надо, глубину глубин © Еще очень приятные уху заказчика аргументы — повышение капитализации бизнеса, эффективности и диверсификация рисков. «Принимая подобное проектное решение мы однозначно повышаем гибкость и диверсифицируем риски разработки, тем самым повышая эффективность работы команды и уровень сатисфакции вас как заказчика. Достигается это за счет повышения прозрачности нашего решения и удешевления стоимости дальнейшей поддержки как следствие, что значительно повышает нашу конкурентоспобность... blah-blah-blah»
Вы еще кипятите? Тогда мы идем к вам
Ну и по этим принципам 99% энтерпрайза софта строиться. Ни одному лидеру рынка не нужен красивый, чистый, быстрый прозрачный продукт. Нужен гибрид соковыжималки и адронного колайдера с пердежом и скрипом выполняющий свои задачи и дающий работу разработчикам, прибыль компании разработчику и компаниям интеграторам, прибыль торговцам железом, консультантам, армии QA... Да если хоть кто то где то сделает действительно хороший продукт мы все без работы останемся :)))))))))))))))))))

Это все хорошо. Но девелопер должен знать как сделать правильно, даже если иногда приходится делать лажу.

Это вообще не вопрос нашей с вами дискуссии. Работу делать надо, ежику понятно. "Унижай и доминируй«©. ТС очень надо показать крутым перца которые придут на собеседование кто здесь папочка. Иначе скоро он перестанет быть главным :)) при этом даже как то рыть инет самому лениво, а мозгов самому придумать нет... Все просто ;)
Правда может быть мотив боязни взять «настолько крутых» перцев, что ещё и вылетит потом за них. И никаких высоких материй

У нас собеседование поделенно на несколько частей:
— General
• Cильные/слабые стороны?
• Чем можите гордиться?
• Интересная задача за последние 3-4 месяца?
• Хороший код, что это такое?
...

— Базовые вопросы (здесь не сами вопросы а топики, а вопросы можно находу придумывать и углублять)
• .NET
◦ Multithreading
◦ GC + Finalizers
◦ Concurrency
◦ GAC
• ASP.NET
◦ Modules
◦ Handlers
◦ Sessions
• ASP.NET MVC
◦ Какие то базовые вопросы
◦ Async controller
◦ etc. в общем что нужно и где написать что бы сделать ЧТО-ТО.
• SQL
◦ GROUP BY и HAVING
◦ Indexes
◦ и всякое другое
• JS
Ну тут всякие задачки, типа что делает этот код ибо JS такой забавный язык
• HTML/CSS
Ну тут какие то базовые вопросы ибо мы ж не крутые верстальщики :)

— Code Review
Даем ноут, код на 2-3 странички написаный абы как, и уходим на 10-15 минут, приходим и человек обьясняет что в этом коде плохо написано и почему и как нужно написать. Предметная область кода должена быть очень простой что бы человек мог понять за пару минут.

— Real Task
За вот те 10-15 минут на предыдущем этапе которые мы выходили придумываем сложную задачку, задача кандидата нарисовать на доске архитектуру как это будет работать, таблички в базе (обычно 1-3 нужно для задачи). А мы стоим и продолжаем придумывать проблемы для этой задачи, например кол-во пользователей резко увеличилось и всякие такие.

ПС: все это занимает около 3 — 3.5 часов :)
Но если кандидит нам не нравится после уже какогото этапа можем сразу сказать пока.

Потом если кандидат нам нравится после всех этапов, то можем дать домашнее задание на 2-3 часа.

Кстати иногда приходят «сеньеры» (в резюме так написано) и не отвечают на простые вопросы по .NET, так что спрашивать нужно и простые вопросы тоже для начала.

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

черт :( все отступы ввиде пробелов проигнорировались :(

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

по вашему списку складываеться впечатление, что у вас Веб пишут десктопники оставшиеся без работы.

Почему? Есть ASP.NET, MVC, JS, HTML/CSS вопросы,real task тоже веб вопрос. Или например проблему concurrency разве не нужно решать в веб проектах?

concurrency
точно не первоочередная проблема.
По аспнету ваши вопросы скорее на проверку прочтения литературы. По сейчас js явно знать надо больше чем понимать особенности слабой типизации языка или контекста выполнения функций. По платформе вопросы для десктопщика, какой multithreading и GAC в веб :), там надо знать асинхронность(TPL) и IIS. По базам знать явно больше надо чем group by. Да и вообще сейчас в дотнет веб технология упор orm абстракции, DI + iqueryable + linq.
По аспнету ваши вопросы скорее на проверку прочтения литературы.
Модули и хендлеры, нужно понимать что это и зачем...
По сейчас js явно знать надо больше чем понимать особенности слабой типизации языка или контекста выполнения функций.
Контекст выполнения функций тоже есть у нас вопрос, я же не писал список вопросов) только топики :)
По платформе вопросы для десктопщика, какой multithreading и GAC в веб :)
Не согласен. Например у нас это не веб сайт, а продукт, у которого есть много веб сервисов wcf сервисов, веб клиент, куча интеграций, так что базовые сборки мы все ложим в гак. Да и многопоточность используем, почему нет?

Отлично, спасибо. Думаю, это как раз то что надо.

Немного странный список, особенно подробностями и применительно к синьору. Вам много так их набрать удалось?
Это я к тому, что этот список по умолчанию предполагает, что вы круче по всем этим вопросам того, кого собеседуете. Что ооочень не факт и есть шанс сесть в лужу да еще и с треском минуте на 15-той. После чего собеседование в цирк превратится.

Да, взяли 4-х по этому списки из 20+.
Я не утверждаю что я лучше кого-то из кандидатов. И если ктото будет лучше то с удовольствием послушаю. Если вы считаете что собеседование это то место где кто то когото загонять приходит, вы ошибаетесь. Кстати, что бы пройти собеседование не обьязательно ответить на все вопросы.

Не поймите меня неправильно — план собеседования это очень правильно и нужно. Просто на должностях от определенного уровня это уже скорее больше разговор или соглашение, чем экзамен. Где-то ниже есть топик, где наш коллега описал как он раскатывал в блин собеседующих «по шаблону» именно потому, что они корчили из себя строгих училок, на деле весьма средне разбираясь в предмете.
Т.е. есть грань, за которой реальный гуру уже начнет обижаться.
А отсеять всякий шлак можно и уточняющими вопросами в процессе описания кандидатом прошлых проектов по идее. Честно говоря не знаю точных критериев, но такое видно обычно довольно быстро.

По этому плану, теория занимает порядка 40%, все остальное это практика. Чему обижаться то ?

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

— автоматическое управление памятью
— типы данных (ссылочные, типы значения)
— ООП
— события, делегаты
— Паттерны
это спрашивают у джунов
есть момент про память, но думаю, что Sr.-у нужно ставить задачи и смотреть как он их решает, а не спрашивать то, что написано в книге.

Спрашивай о том, какой сорт сыра и с каким вином они предпочитают.

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

Підписатись на коментарі