Вхід і реєстрація
Про роботу · 16 лютого 2014, 0:20 17946
Den Di

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

💡 Усі статті, обговорення, новини про .NET — в одному місці. Приєднуйтесь до .NET спільноти!

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

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

Теми: .NET, співбесіда
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

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

Dmytro Shchurov 16.02.2014 18:02

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

Перейти до дискусії
Oleksii Pysanko 16.02.2014 14:37

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

Перейти до дискусії
Stanislav Sklyarov 17.02.2014 08:08

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
Vasyl Hukalyuk Head of HR Department 19.01.2017 14:46

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

Artyom Krivokrisenko 17.02.2014 08:32

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

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

Відповісти
Підтримати
Ivan Pomidorov 17.02.2014 10:06

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

Відповісти
Підтримати
Artyom Krivokrisenko
Laneta 18.02.2014 13:34

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

Відповісти
Підтримати
Ivan Pomidorov
Ivan Pomidorov 18.02.2014 13:39

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

Відповісти
Підтримати
Gabriel Angelos
Stanislav Sklyarov 17.02.2014 08:08

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) можно еще алгоритмы/структуры спросить- но думаю это уже будет перебор — та не, нормально, чо. Пусть покажет, какой он крутой, а то зажрались совсем, пока честные пацаны вкалывают. И Кнута, пусть Кнута наизусть цитирует, ска.

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

Відповісти
Підтримати
Anton Kovalev 17.02.2014 10:15
Приходит юниор — спрашивают о проектах. Приходит синьор — спрашивают хрень из справочников. Так и живем

Так синьор же по определению сам ракеты в космос запускает каждый день. Осталось только узнать как он теорию запуска ракет знает. А то без теории никуды...
Відповісти
Підтримати
Stanislav Sklyarov
Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 17.02.2014 19:37
добавь еще этих хрустящих фабрик синглтонов да выпей чаю
Утащил в свой цитатник!
Відповісти
Підтримати
Stanislav Sklyarov
Dmytro Shchurov Frontend/React Developer в KAJO s.r.o. 16.02.2014 18:02

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

Відповісти
Підтримати
Igor Golodnitsky те самые 5k$ в PreciseQ 22.07.2014 15:21

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

Відповісти
Підтримати
Dmytro Shchurov
Oleksii Pysanko VPE в Woolf 16.02.2014 14:37

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

Відповісти
Підтримати
Anton Kovalev 16.02.2014 14:58

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

Відповісти
Підтримати
Oleksii Pysanko
Gabriel Angelos 16.02.2014 15:25

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

Відповісти
Підтримати
Anton Kovalev
Дмитро 16.02.2014 15:42
Хороший специалист не должен знать наизусть кучу теории... он должен уметь находить и обрабатывать информацию, необходимую для решения конкретных задач в кратчайшие сроки и выбирать наиболее правильное решение.

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

Відповісти
Підтримати
Oleksii Pysanko
Anton Kovalev 16.02.2014 16:11

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

Відповісти
Підтримати
Дмитро
Oleksii Pysanko VPE в Woolf 16.02.2014 16:34

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

Відповісти
Підтримати
Дмитро
Дмитро 16.02.2014 16:43

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

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

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

Відповісти
Підтримати
Дмитро
Pavel Kruchina CTO 16.02.2014 17:09

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

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

Відповісти
Підтримати
Дмитро
Дмитро 16.02.2014 19:57

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

Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 16.02.2014 21:57

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

Відповісти
Підтримати
Дмитро
Дмитро 16.02.2014 22:18

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

данная теория не нужна
потому что нельзя дать задачу на проверку теори.
Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 17.02.2014 08:18

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

Відповісти
Підтримати
Дмитро
Дмитро 17.02.2014 08:41

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

Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 17.02.2014 10:45

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

Відповісти
Підтримати
Дмитро
Gabriel Angelos 17.02.2014 10:51
Скажем, в большинстве случаев, вам не нужно знать, как реализована стандартная сортировка.
Это крайне неправильное допущение.
Без таких знаний теории вы легко напишете код, который вешает всю систему.
Хотя для менеджера это не страшно
Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 17.02.2014 10:57

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

Відповісти
Підтримати
Gabriel Angelos
Gabriel Angelos 17.02.2014 11:08

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

Как часто вам приходилось создавать собственную функцию сортировки?
Этого я не говорил, зачем придумывать.
Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 17.02.2014 11:14

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

в большинстве случаев, вам не нужно знать, как реализована стандартная сортировка.
Или вы знаете языки,в которых стандартная сортировка — это пузырьком?
Этого я не говорил, зачем придумывать.
Отлично, значит я таки прав.
Відповісти
Підтримати
Gabriel Angelos
Gabriel Angelos 17.02.2014 11:32
Отлично, значит я таки прав.
Правило демагога № 47 «Помни, в споре нет победы, поэтому смело в любой момент объявляй, что ты победил, умыл, урыл и ткнул оппонента.»
Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 17.02.2014 11:38
Этого я не говорил, зачем придумывать.
Уже сказали :)
Відповісти
Підтримати
Gabriel Angelos
Виталий Кеценко 17.02.2014 11:40

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

Відповісти
Підтримати
Gabriel Angelos
Gabriel Angelos 17.02.2014 11:43
И всё-таки, как часто Вам приходится выбирать какую сортировку использовать?
Часто на back-end-е, а это примерно 3-4 раза в месяц, как во время написания своего кода, так и во время поиска узких мест профайлером в существуюем. Места — обработка больших наборов объектов в коллекциях.
Відповісти
Підтримати
Виталий Кеценко
Pavel Kruchina CTO 17.02.2014 11:48

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

Відповісти
Підтримати
Gabriel Angelos
Anton Kovalev 17.02.2014 11:08

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

Відповісти
Підтримати
Gabriel Angelos
Gabriel Angelos 17.02.2014 11:10

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

Скажем, в большинстве случаев, вам не нужно знать, как реализована стандартная сортировка.
это сделать проблематично.
Відповісти
Підтримати
Anton Kovalev
Pavel Kruchina CTO 17.02.2014 11:16

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

Відповісти
Підтримати
Gabriel Angelos
Pavel Kruchina CTO 17.02.2014 11:36

отлично,

Реализация, прирост производительности — в студию.
Відповісти
Підтримати
Gabriel Angelos
Дмитро 17.02.2014 11:09
нет, я просто её не знаю/не помню.
абсолютных примеров вы привести не можете. ситуативные как мы выяснили — не аргумент, для однозначных заявлений.
Как же тогда однозначно можете писать — «нет»?

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

Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 17.02.2014 11:21

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

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

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

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

Відповісти
Підтримати
Дмитро
Дмитро 17.02.2014 11:29

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

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

Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 17.02.2014 11:35

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

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

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

Відповісти
Підтримати
Виталий Кеценко
Виталий Кеценко 17.02.2014 12:07

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

Відповісти
Підтримати
Дмитро
Pavel Kruchina CTO 17.02.2014 12:09

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

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

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

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

Відповісти
Підтримати
Дмитро
Anton Kovalev 17.02.2014 12:14

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

Відповісти
Підтримати
Дмитро
Pavel Kruchina CTO 17.02.2014 12:19

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

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

Відповісти
Підтримати
Anton Kovalev
Anton Kovalev 17.02.2014 12:24

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

Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 17.02.2014 12:59

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

Відповісти
Підтримати
Anton Kovalev
Anton Kovalev 17.02.2014 13:35

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

Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 17.02.2014 13:39

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

Відповісти
Підтримати
Anton Kovalev
Gabriel Angelos 17.02.2014 13:40
Где тут логика?
В менеджерском подходе — созвать митинг/вылить кучу слов + найти виноватого, это и называется «результатом» с его точки зрения.
Відповісти
Підтримати
Anton Kovalev
Gabriel Angelos 17.02.2014 13:41

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

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

Відповісти
Підтримати
Anton Kovalev
Anton Kovalev 17.02.2014 13:51
Если девелопер не смог изобразить синглтон на бумажке, то это катастрофа, страшно подумать шо он в коде напишет.
Пойду повешусь.
Есть у меня знакомый девелопер, который знает наизусть все GOF 23 шаблона + несколько кастомных. Ни один внятно не может объяснить, а придумывает совершенно дикие аналогии и прыгает от темы к теме. В общем с ним общаться крайне тяжело.
Это все потому что у нас собеседования такие.
Відповісти
Підтримати
Gabriel Angelos
Gosha Nemo 01.03.2018 11:26

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

Відповісти
Підтримати
Anton Kovalev
Gosha Nemo 01.03.2018 11:28

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

Відповісти
Підтримати
Anton Kovalev
Sergey Litvinov .Net Developer в DataArt 16.02.2014 20:21
Если человек, вместо изобретения велосипеда полезет в гугл — это замечательно.
Если человек полезет и скопипастит из гугла код, совершенно не понимая как он работает, и он его оставит, так как оно как-то все же работает, то потом когда начнут вылазить следствия копипаста — может быть печально.
Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 16.02.2014 22:00

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

Відповісти
Підтримати
Sergey Litvinov
Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 17.02.2014 19:45
Если человек полезет и скопипастит из гугла код, совершенно не понимая как он работает
... то он скорее всего индус!
Я, честно говоря, такого на своей памяти не встречал в наших широтах. Хотя уже давненько с джунами дела не имел, с другой стороны. Но синьоров это уж точно никак не касается.
Відповісти
Підтримати
Sergey Litvinov
Dmytro Shchurov Frontend/React Developer в KAJO s.r.o. 16.02.2014 18:07

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

Відповісти
Підтримати
Oleksii Pysanko
Kostiantyn Kudriavtsev Head of .NET team в DXC Luxoft 16.02.2014 13:52

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

Відповісти
Підтримати
Anton Kovalev 16.02.2014 13:57

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

Відповісти
Підтримати
Kostiantyn Kudriavtsev
Gabriel Angelos 16.02.2014 13:09

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

Відповісти
Підтримати
Anton Kovalev 16.02.2014 13:16

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

Відповісти
Підтримати
Gabriel Angelos
Gabriel Angelos 16.02.2014 13:18

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

Відповісти
Підтримати
Anton Kovalev
Maksim S 16.02.2014 23:27

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

Відповісти
Підтримати
Gabriel Angelos
digitalizer 16.02.2014 16:46

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

Відповісти
Підтримати
Gabriel Angelos
Victor Gladkikh 16.02.2014 12:44

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

Відповісти
Підтримати
Дмитро 16.02.2014 12:16

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

Відповісти
Підтримати
Pavel Kruchina CTO 16.02.2014 12:13

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

Відповісти
Підтримати
Anton Kovalev 16.02.2014 11:44

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

Відповісти
Підтримати
Anton Kovalev 16.02.2014 11:49

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

Anton Kovalev 16.02.2014 11:22

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

Відповісти
Підтримати
Oleg K 16.02.2014 11:32

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

Відповісти
Підтримати
Anton Kovalev
Anton Kovalev 16.02.2014 11:37

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

Відповісти
Підтримати
Oleg K
Oleg K 16.02.2014 12:07

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

Відповісти
Підтримати
Anton Kovalev
Anton Kovalev 16.02.2014 12:38

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

Відповісти
Підтримати
Oleg K
Oleg K 16.02.2014 12:47

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

Відповісти
Підтримати
Anton Kovalev
Anton Kovalev 16.02.2014 13:08

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

Відповісти
Підтримати
Oleg K
Den Di 16.02.2014 13:19
То есть раз в месяц приходиться выбирать используя having или раз в месяц просто выбирать?
Немного удивляет такие вопросы. У нас очень часто приходится разработчикам работать с базами "ручками«- и запросы на выборку с группировками и условия по групировкам- это не высшая математика.
Я уж про индексы молчу, это отдельный «вид спорта».
С индексами тоже всё просто- надо просто понимать как работает конкретная rdbms, уметь пользоваться explain plan, встроенными отчетами, трассировками и отладочными средствами, другими словами- человек с тайтлом Sr. — обязан знать свои инструменты.
Відповісти
Підтримати
Anton Kovalev
Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 16.02.2014 13:23

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

Відповісти
Підтримати
Den Di
Gabriel Angelos 16.02.2014 13:25

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

Відповісти
Підтримати
Tim Tretyak
Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 16.02.2014 18:34

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

Відповісти
Підтримати
Gabriel Angelos
Anton Kovalev 16.02.2014 18:42

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

Відповісти
Підтримати
Tim Tretyak
Владимир Чернышев Программист 17.02.2014 08:56

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

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

Відповісти
Підтримати
Gabriel Angelos
Anton Kovalev 16.02.2014 13:30

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

Відповісти
Підтримати
Den Di
Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 16.02.2014 19:31
знает все нюансы этого процесса хотя для Oracle и MS SQL
Это очень смелое утверждение. Лично я знаю двух людей в Киеве, более-менее знающих все нюансы оракла и этих людей оракл и ibm барыжит по 5к негривен в день консалтом. И стоит очередь.
Не ДБ-спец в лучшем случае может расчитывать на запросы качества «не огрести от ДБА немедленно», а для майнинга так и «сформулировать ДБ-спецу что надо и получить от него квери/процедуру».
В MSSQL свои приколы, обычно выражающиеся в интересном поведении при большом количестве клиентов и утилизации железа. НЕТ спец это может знать со слов ДБА-ДБ-спеца, но редко по своему опыту.
Відповісти
Підтримати
Anton Kovalev
Anton Kovalev 16.02.2014 20:12

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

Відповісти
Підтримати
Tim Tretyak
Владимир Чернышев Программист 17.02.2014 08:55

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

Відповісти
Підтримати
Anton Kovalev
Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 17.02.2014 19:51

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

Відповісти
Підтримати
Владимир Чернышев
Denis Pakizh Independent Software Engineer 16.02.2014 12:50

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

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

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

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

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

Відповісти
Підтримати
Oleg K
Владимир Чернышев Программист 17.02.2014 08:43

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

Відповісти
Підтримати
Anton Kovalev
Anton Kovalev 17.02.2014 10:06

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

Відповісти
Підтримати
Владимир Чернышев
Владимир Чернышев Программист 17.02.2014 10:33

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

Відповісти
Підтримати
Anton Kovalev
Anton Kovalev 17.02.2014 11:15

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

Відповісти
Підтримати
Владимир Чернышев
Ivan M Software Engineer в Лідер ринку 17.02.2014 21:30

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

Відповісти
Підтримати
Anton Kovalev
Anton Kovalev 17.02.2014 22:09

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

Відповісти
Підтримати
Ivan M
Ivan M Software Engineer в Лідер ринку 17.02.2014 22:19

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

Відповісти
Підтримати
Anton Kovalev
Anton Kovalev 17.02.2014 22:37

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

Відповісти
Підтримати
Ivan M
Oleg K 16.02.2014 09:45

У нас собеседование поделенно на несколько частей:
— 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, так что спрашивать нужно и простые вопросы тоже для начала.

нормальный человек может и обидеться .
пусть обижается, нам такие не нужны :)
Відповісти
Підтримати
Oleg K 16.02.2014 09:46

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

Відповісти
Підтримати
Oleg K
Sergii Voloshyn Product Manager в DOU.ua 16.02.2014 10:35

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

Відповісти
Підтримати
Oleg K
Дмитро 16.02.2014 11:10

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

Відповісти
Підтримати
Oleg K
Oleg K 16.02.2014 11:15

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

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

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

Відповісти
Підтримати
Oleg K
Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 16.02.2014 12:28

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

Відповісти
Підтримати
Oleg K
Oleg K 16.02.2014 12:34

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

Відповісти
Підтримати
Tim Tretyak
Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 16.02.2014 12:45

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

Відповісти
Підтримати
Oleg K
Oleg K 16.02.2014 12:50

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

Відповісти
Підтримати
Tim Tretyak
Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 16.02.2014 13:06

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

Відповісти
Підтримати
Oleg K
tragvar лежу в ванне 16.02.2014 07:20
— автоматическое управление памятью
— типы данных (ссылочные, типы значения)
— ООП
— события, делегаты
— Паттерны
это спрашивают у джунов
есть момент про память, но думаю, что Sr.-у нужно ставить задачи и смотреть как он их решает, а не спрашивать то, что написано в книге.
Відповісти
Підтримати
Grez 16.02.2014 04:10

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

Відповісти
Підтримати
proger 16.02.2014 00:56

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

Відповісти
Підтримати

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.