Чем собеседование по скайпу должно отличаться (и должно ли?) от очного собеседования?
Может как-то по-особенному нужно план продумать? Что при этом учесть?
Как лучше: с видео или без? Что бы вы предпочли с точки зрения собеседуемого?
Что обязательно должно быть и чего ни в коем случае не должно?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Чем собеседование по скайпу должно отличаться (и должно ли?) от очного собеседования? _FR>Может как-то по-особенному нужно план продумать? Что при этом учесть? _FR>Как лучше: с видео или без? Что бы вы предпочли с точки зрения собеседуемого? _FR>Что обязательно должно быть и чего ни в коем случае не должно?
Ну с очным собеседованием не очень уместно сравнивать. Лучше с телефонным.
От видео стоит отказаться сразу. Во-первых, не всегда линия может потянуть, а во-вторых, я могу сидеть в трениках, а на заднем плане белье сушится Такой антураж показывать потенциальному работодателю мне бы не хотелось
Из очевидных плюсов — возможность перебросить файло.
Это дает шикарную возможность обсудить проблему, набросать ее решение либо сразу в скайповом чате, либо в отдельном файлике и его переслать.
Как это применить — решать тебе.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Ну с очным собеседованием не очень уместно сравнивать. Лучше с телефонным. SVZ>От видео стоит отказаться сразу. Во-первых, не всегда линия может потянуть, а во-вторых, я могу сидеть в трениках, а на заднем плане белье сушится Такой антураж показывать потенциальному работодателю мне бы не хотелось
Тут кандидат всегда может сказать "камера не работает, давайте голосом". Или сдать бутылки из углов, надеть галстук и ответить "Здравствуйте, рад вас видеть!" К тому же, видео в скайпе (сам удивился) может быть односторонним — заодно можно будет показать кандидату и офис, даже если у него камера не работает :о)) Хотя да, у нас в офисе тоже камеры нет Отпадает.
SVZ>Из очевидных плюсов — возможность перебросить файло.
О как, интересно, действительно, в собеседовании очень полезно.
SVZ>Это дает шикарную возможность обсудить проблему, набросать ее решение либо сразу в скайповом чате, либо в отдельном файлике и его переслать. SVZ>Как это применить — решать тебе.
В чате такое отвратное форматирование, что файл действительно, решит.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Чем собеседование по скайпу должно отличаться (и должно ли?) от очного собеседования? _FR>Может как-то по-особенному нужно план продумать? Что при этом учесть?
Имхо сильно заморачиваться не нужно.
Продумайте как будете передавать друг другу код. Можно например воспользоваться сайтом типа http://pastebin.com, там показываются строчки и подсветка.
Еще я бы побоялся, если собеседуемый будет подглядывать в MSDN или гугл, поэтому возможно я бы попросил его показать рабочий стол. Это можно сделать прямо из скайпа, либо воспользоваться альтренативной программой, например рекомендую teamviewer — очень простое и быстрое подключение и высокая скорость. Теоретически собеседуемого это может напрячь, но имхо это особенность удаленного собеседования — так что можно понять, что претендент может этим воспользоваться и подсматривать, и надо как-то от этого перестраховаться. Лично я бы не возражал (может где-то внутри совсем чуть-чуть напрягся, но работодателя бы прекрасно понял).
_FR>Как лучше: с видео или без? Что бы вы предпочли с точки зрения собеседуемого?
Я бы предпочел чтобы меня спросили, как мне комфортнее. Видео теоретически может дополнительно напрягать собеседуемого от того, что он будет думать что на него смотрять, рассматривают его кривые зубы и прыщи
MC>Еще я бы побоялся, если собеседуемый будет подглядывать в MSDN или гугл,
Вы за уже нанятыми работниками тоже следите, что б не подглядывали в MSDN или гугл?
Если серьезно, что Вам дадут сведения о способности ответить интервьюируемого на вопросы, на которые моментально можно найти ответы в общедоступных источниках?
(кроме того, что человек этими источниками пользоваться умеет)
Здравствуйте, ylem, Вы писали:
Y> Вы за уже нанятыми работниками тоже следите, что б не подглядывали в MSDN или гугл?
ха-ха.
Y>Если серьезно, что Вам дадут сведения о способности ответить интервьюируемого на вопросы, на которые моментально можно найти ответы в общедоступных источниках? Y>(кроме того, что человек этими источниками пользоваться умеет)
Во-первых, в общедоступных источниках можно найти практически все, давайте тогда вообще собеседования не проводить, а брать просто так.
Во-вторых, я хочу брать на работу человека с определенным необходимым уровнем. И если я на собеседовании задам вопрос, например, что такое Open-Closed Principle и попрошу потом привести примеры нарушения этого принципа и решения проблемы, то я хочу узнать знает ли он ответ и применяет ли это в своем опыте, я не хочу, чтобы он открыл втихаря электронную книгу Роберта Мартина и прочитал определение и примеры оттуда.
Y>>Если серьезно, что Вам дадут сведения о способности ответить интервьюируемого на вопросы, на которые моментально можно найти ответы в общедоступных источниках? MC>Во-первых, в общедоступных источниках можно найти практически все
Но не моментально.
MC>если я на собеседовании задам вопрос, например, что такое Open-Closed Principle ... то я хочу узнать знает ли он ответ
Если Вам важно именно "знает ли ответ", то да, доступ к справочникам с готовыми ответами надо исключить.
> и применяет ли это в своем опыте
А вот тут справочник ничем не поможет. Вы же на раз сможете задетектить копипэйст из источника, который интервьюируемый нашел за полминуты(?)
И уж тем более жертва не сможет развить беседу по поводу содранных примеров.
А если сможет, значит она просто ранее читала не те книги, которые читали Вы.
Повторюсь, я по-прежнему убежден, что если ответ находится мгновенно, то
— либо это вопрос про какую-нибудь техническую частность;
— либо вопрос "концептуальный", а подглядывание в литературу помогло обратиться к нужным страницам своего опыта.
Или есть другие варианты?
(у меня не очень большой опыт интервью как с той, так и с другой стороны баррикад)
Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, ylem, Вы писали:
Y>> Вы за уже нанятыми работниками тоже следите, что б не подглядывали в MSDN или гугл? MC>ха-ха.
Y>>Если серьезно, что Вам дадут сведения о способности ответить интервьюируемого на вопросы, на которые моментально можно найти ответы в общедоступных источниках? Y>>(кроме того, что человек этими источниками пользоваться умеет) MC>Во-первых, в общедоступных источниках можно найти практически все, давайте тогда вообще собеседования не проводить, а брать просто так.
вас легко вокруг пальца обведет любой, подсматривающий в ноут стоящий рядом
а "нормальный" человек подумает, что контора-то странноватая, стоит к ней получше присмотреться. и желательно из другой конторы
MC>Во-вторых, я хочу брать на работу человека с определенным необходимым уровнем. И если я на собеседовании задам вопрос, например, что такое Open-Closed Principle и попрошу потом привести примеры нарушения этого принципа и решения проблемы, то я хочу узнать знает ли он ответ и применяет ли это в своем опыте, я не хочу, чтобы он открыл втихаря электронную книгу Роберта Мартина и прочитал определение и примеры оттуда.
именно поэтому нужно задавать такие вопросы ответы на которые искать бесполезно. и стоить оценивать не сами ответы, а ход мыслей
Много писать влом, давайте еще один простой пример. Допустим, я ищу человека на позицию джуниора или миддла, и решу одним из вопросов спросить его в каких случаях возникает боксинг. Человек может в гугле ввести when boxing occurs и уже через 10-15 секунд перейдет по самой же первой ссылке, где есть четкий ответ на этот вопрос. Я подумаю, что он знает эту тему, а он потом будет на работе писать не самый оптимальный код. Вы можете сказать, что раз это можно найти за 15 секунд, то он просто потом это прочитает и все будет ок. Но на самом деле навряд ли, скорее всего он просто даже не будет задумываться, что его цикл на 100000 итераций на каждой итерации создает объект в куче и нагружает garbage collector.
В любом случае, повторюсь, я не хочу брать человека просто так, я ему буду платить деньги и я хочу и имею право удостовериться, что этот человек обладает каким-то минимально необходимым уровнем знаний.
Если Вам удобней на примерах, ну пусть так (в конце концов это мне нужно выяснить, где я ошибаюсь)
MC>решу одним из вопросов спросить его в каких случаях возникает боксинг.
не лучше ли будет спросить, чем может быть плохо ?
var list = new ArrayList();
for (var i = 0; i < 1e6; i++)
{
list.Add(i);
}
(можно поумней пример придумать, про структуры, интерфейсы или еще чего более близкое к реальной жизни)
А уж "в каких случаях возникает", тут надо реально мозг намощить, что б определение вывести.
Лучше уж тогда показать жертве 10 случаев, что она сказала, где возникают, а где нет.
Не подумайте, что пытаюсь Вас учить, но я все еще считаю, что или вопросы неудачные, или ничего страшного, что литературе под рукой нет.
Здравствуйте, ylem, Вы писали:
Y>не лучше ли будет спросить, чем может быть плохо ? Y>
Y>var list = new ArrayList();
Y>for (var i = 0; i < 1e6; i++)
Y>{
Y> list.Add(i);
Y>}
Y>
Да, думаю вы правы, наверное так будет лучше. Т.е. учитывая специфику удаленного собеседования придумывать вопросы так, чтобы ответ нельзя было просто найти.
Здравствуйте, MozgC, Вы писали:
_FR>>Чем собеседование по скайпу должно отличаться (и должно ли?) от очного собеседования? _FR>>Может как-то по-особенному нужно план продумать? Что при этом учесть?
MC>Имхо сильно заморачиваться не нужно. MC>Продумайте как будете передавать друг другу код. Можно например воспользоваться сайтом типа http://pastebin.com, там показываются строчки и подсветка.
А чем это будет удобнее пересылки файла и открытия его в в студии?
MC>Еще я бы побоялся, если собеседуемый будет подглядывать в MSDN или гугл, поэтому возможно я бы попросил его показать рабочий.
Не вижу в этом ничего плохого, даже наоборот. Если человек знает, в каком разделе документации описано то, что ему потребовалось "вспомнить" или может быстро отыскать это, то не нужно ему мешать.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>А чем это будет удобнее пересылки файла и открытия его в в студии?
Лично мне кажется, что если надо показать маленький кусочек кода, то быстрее его вставить на сайте и передать ссылку, чем создавать файл, отправлять его, потом открывать в студии. Я когда обмениваюсь в скайпе маленькими кусочками кода, то мне удобнее так вот, через сайт.
Здравствуйте, MozgC, Вы писали:
MC>Еще я бы побоялся, если собеседуемый будет подглядывать в MSDN или гугл, поэтому возможно я бы попросил его показать рабочий стол. Это можно сделать прямо из скайпа, либо воспользоваться альтренативной программой, например рекомендую teamviewer — очень простое и быстрое подключение и высокая скорость. Теоретически собеседуемого это может напрячь, но имхо это особенность удаленного собеседования — так что можно понять, что претендент может этим воспользоваться и подсматривать, и надо как-то от этого перестраховаться. Лично я бы не возражал (может где-то внутри совсем чуть-чуть напрягся, но работодателя бы прекрасно понял).
Вот поэтому это плохой, негодный вопрос. Человек может знать когда происходит боксинг, но не заморачиваться на этот счет. Или не знать, но писать оптимальный код. Знание, когда происходит боксинг о других знаниях или умениях не говорит ничего.
Если бы у меня стояла такая задача, я бы дал кандидату кусок кода строк на 150-200 с десятком performance issues, попросил оптимизировать и посмотрел, сколько из них он найдет. По каждой проблеме можно попросить оценить ее вклад в производительность. Тут и про большое О можно поговорить и про то, что из найденного стоит исправлять, а что нет. Затем, можно спросить кандидата, всегда ли он пишет оптимальный код. В зависимости от ответа можно свернуть разговор на профайлеры и преждевременную оптимизацию или на алгоритмическую оптимизацию. Если разговор свернул на алгоритмическую оптимизацию, можно дать задачку. В project euler есть прекрасные экземпляры, которые формулируются в одну строку, решаются в 10 строк в уме, но если решать их в лоб работают 1000 лет. Тут и способность писать алгоритмы, и умение оценивать трудоемкость на глаз.
Но лично я бы с боксингом не заморачивался. Эта проблема наверняка будет обнаружена на code review. Гораздо важнее, чтобы человек получив замечания прочитал про боксинг и не делал так больше, а не вставал в позу "ну ведь работает же".
Здравствуйте, MozgC, Вы писали:
MC>Во-вторых, я хочу брать на работу человека с определенным необходимым уровнем. И если я на собеседовании задам вопрос, например, что такое Open-Closed Principle и попрошу потом привести примеры нарушения этого принципа и решения проблемы, то я хочу узнать знает ли он ответ и применяет ли это в своем опыте, я не хочу, чтобы он открыл втихаря электронную книгу Роберта Мартина и прочитал определение и примеры оттуда.
Вы собеседование проводите по электронной почте или все же голосом?
Масштабы бедствия сильно преувеличены, ИМХО.
Я полагаю, что Вы сходу распознаете, отвечает человек знающий или судорожно ищет ответ в инете.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, MozgC, Вы писали:
MC>Во-вторых, я хочу брать на работу человека с определенным необходимым уровнем. И если я на собеседовании задам вопрос, например, что такое Open-Closed Principle и попрошу потом привести примеры нарушения этого принципа и решения проблемы, то я хочу узнать знает ли он ответ и применяет ли это в своем опыте, я не хочу, чтобы он открыл втихаря электронную книгу Роберта Мартина и прочитал определение и примеры оттуда.
Блин. Мне стыдно. Прочитал этот вопрос — выпал в осадок. Что за принцип, почему не знаю... Спросил в гугле, по первому же предложению из википедии понял о чем речь и уже готов разговаривать о нем, приводить примеры из практики, писать примеры кода и прочая, прочая, прочая. Просто, имхо, не настолько сложный принцип чтобы помнить отдельно его название, автора, книгу. Эта концепция как-то сама собой закрепляется в мозгу при применении на практике.
И вот теперь я в раздумьях — то ли я плохой программер (не ответил на простой вопрос), то ли сам вопрос из серии "я недавно прочитал книгу, буду спрашивать".
Здравствуйте, Jesmus, Вы писали:
J>Блин. Мне стыдно. Прочитал этот вопрос — выпал в осадок. Что за принцип, почему не знаю... Спросил в гугле, по первому же предложению из википедии понял о чем речь и уже готов разговаривать о нем, приводить примеры из практики, писать примеры кода и прочая, прочая, прочая. Просто, имхо, не настолько сложный принцип чтобы помнить отдельно его название, автора, книгу. Эта концепция как-то сама собой закрепляется в мозгу при применении на практике.
J>И вот теперь я в раздумьях — то ли я плохой программер (не ответил на простой вопрос), то ли сам вопрос из серии "я недавно прочитал книгу, буду спрашивать".
Стыдится не надо, ну не знали точного названия, что ж теперь. Но вопрос не из этой серии явно. Имхо принципы SOLID — это классика. И насколько я помню, все мои коллеги в разговоре употребляют и понимают названия этих принципов.
Такой антураж показывать потенциальному работодателю мне бы не хотелось 
Отпадает.
