Я не знаю, что там были за задания, но конкретно у меня такие соображения.
В любом случае вряд ли будет 100% попадание в опыт. Грубо говоря, когда вы туда придете там будет куча технологий, которых снаружи просто нет и вам все равно придется чему-то учиться.
Или например, Вася недавно этот алгоритм использовали, а вы использовали несколько другой и у Васи будет преимущество. А Петя вообще не по алгоритмам — у него нет фундаметальных знаний и ему надо университетский курс преподать. Вот чтобы отличить вас с Васей от Пети можно вам дать тему для подготовки, чтобы уменьшить вашу разницу с Васей.
Хотя это может у меня такая работа где все время что-то новое и надо учиться (хотя какой-то маломобильный фундамент помогает), а у вас — заучил на всю жизнь и пользуйся.
А что прочитать, чтобы выучить социальные взаимодействия — непонятно.
Пытались ли вы гуглить ответ на этот вопрос? Вообще это лучше тренировать и чтобы рядом был человек, который может посмотреть на вас со стороны и дать обратную связь.
Если все относятся друг к другу доброжелательно и хотят закоммитить качесвенный код, то ревью воспринимается как помощь. Принципиальные разногласия случаются редко, кратковременные случаются, но обычно решается аргументами.
С точки зрения фнукционального программиста обман — каждое новое состояние — это другой человек. А с точки зрения объектно-ориентированного — не обман. У человека есть идентичность и состояние. :)
В принципе собеседующий может закладываться на то, что человек может подготовиться и умение подготовиться может быть плюсом — все равно на работу будет ходить третий человек а через месяц четвертый. С точки зрения ФП.
Это тс вашей точки зрения необязательно. А с точки зрения reuniko обязательно. А то ж разработчиками придется обращаться и у них должны быть софтскиллы. Это было явно написано ранее
Я не знаю что такое высокий коммуникативный скилл по-вашему, но с моей точки зрения для того чтобы рассказать о себе он не нужен. Такое же умение структурировать информацию и слышать собеседника как и при коммуникации между программистами.
Я не очень понимаю зачем надо создавать single point of failure в виде тимлида причем тимлида с идеальной памятью. С моей точки зрения лучше чтобы сеньоры могли его поменять хотя бы в каких-то областях.
Это зависит от подхода обоих. Если вы сильно нужны, то к вам будут приспосабливаться даже если вы не хотите пойти навстречу. С другой стороны если вы покажете что искренне хотите понять собеседника и рассказать, что он хочет слышать, то вам будет плюс.
Ну вот мне нужен, допустим, человек в команду. Надо делать такую-то работу, но при прочих равных хотелось бы чтобы он мог делать что-то еще, например, иметь перспективу вырасти на должность выше.
Какая вам разница был он первый, кто прошел тесты или один из 1000? Он же всем вашим требованиям удовлетворяет.
А если сеньёра нет, но сойдет и мидл, но если есть сеньёр лучше сеньёра?
Как в кафе — хочу кашу на завтрак, но если ничего уж совсем нет — давайте ваш эгг макмаффин.
чтобы дать формальную причину докопаться и отказать
Адекватному интервюэру не надо докапываться до чего-то ему нужно понять с кем он беседует и стоит ли его принимать на работу. Специально валить кого-то никому не надо. А если надо, то он вам не нужен, наверное?
А перебивать — невежливо
Ну это по ситуации — можно перебить вежливо да так, что перебиваемому понравится. Мне так рекомендовали делать когда человек завел шарманку, уставился в пространство и нудит что-то свое не обращая внимание на то, что это неинтересно собеседникам.
А с низкими софт-скиллами ещё и не заметишь что говоришь не то, что ожидают, а потом вынесут вердикт "робот, а нам нужен человек" или "рассказал о семье, о хобби, но нафигам нам это — балабол"
Ну и еще мне не понятно, как можно донести до другого человека собственный опыт, полученный не из лекций в университете, не из статей на хабре, не из документации или роликах на ютюбе и не из разговоров с другими людьми. Опыт, полученный в результате реальной работы, проб и ошибок и их исправления — непередаваем языком.
Т.е. статьи на хабре, разговоры, книжки и ролики получаются из других разговоров, статей, книжек и роликов и никак не из опыта.
А первую статью, книжку, разговор или ролик нам передал бог или инопланетяне!
Возможно, у нас разный уровень кандидатов. У меня значительное количество тех, кто не может проверить работоспособность простого кода — проверяют, например, только позитивные сценарии.
То что он там забудет название ф-ции, перепутает в ней аргументы или забудет точку с запятой, это же никакой дополнительной информации не дает.
Я не даю заданий на память. Только на логику и дизайн. Если человек, например, пишет в резюме 5 лет работы с технологией, то вроде с IDE он должен справиться — если забудет точку с запятой она подскажет. А потом интересно, как он будет убеждаться в работоспособности. А еще интересно как он трансформирует код. Например, использует буфер обмена или рефакторинги. Всякие мелочи я сам ему подскажу.
А проверяющий, в своей обычной обстановке и почему-то не своей головой проверяет решение, а пользуется машиной.
Понимаете, тут нет никакого соревнования между проверяющим и кандидатом. Есть соревнование между кандидатом и другими кандидатами. Так что неравенство здесь не играет роли.
Ну не знаю зачем это вам. Мне было бы интересно сможете ли вы сами добиться работоспособности кода и каким образом вы будете его тестировать. Т.е. какой общий подход.
Я не знаю, что там были за задания, но конкретно у меня такие соображения.
В любом случае вряд ли будет 100% попадание в опыт. Грубо говоря, когда вы туда придете там будет куча технологий, которых снаружи просто нет и вам все равно придется чему-то учиться.
Или например, Вася недавно этот алгоритм использовали, а вы использовали несколько другой и у Васи будет преимущество. А Петя вообще не по алгоритмам — у него нет фундаметальных знаний и ему надо университетский курс преподать. Вот чтобы отличить вас с Васей от Пети можно вам дать тему для подготовки, чтобы уменьшить вашу разницу с Васей.
Хотя это может у меня такая работа где все время что-то новое и надо учиться (хотя какой-то маломобильный фундамент помогает), а у вас — заучил на всю жизнь и пользуйся.
Пытались ли вы гуглить ответ на этот вопрос? Вообще это лучше тренировать и чтобы рядом был человек, который может посмотреть на вас со стороны и дать обратную связь.
А почему собственно это плохо. Возможно их интересует ваша способность подготовиться?
Если все относятся друг к другу доброжелательно и хотят закоммитить качесвенный код, то ревью воспринимается как помощь. Принципиальные разногласия случаются редко, кратковременные случаются, но обычно решается аргументами.
С точки зрения фнукционального программиста обман — каждое новое состояние — это другой человек. А с точки зрения объектно-ориентированного — не обман. У человека есть идентичность и состояние. :)
В принципе собеседующий может закладываться на то, что человек может подготовиться и умение подготовиться может быть плюсом — все равно на работу будет ходить третий человек а через месяц четвертый. С точки зрения ФП.
Это тс вашей точки зрения необязательно. А с точки зрения reuniko обязательно. А то ж разработчиками придется обращаться и у них должны быть софтскиллы. Это было явно написано ранее
Расскажите пожалуйста о своей практике в рекомендуемой вами методике приема.
Вот например принимается три новых человека на полставки на одно место. Допустим, им не надо три рабочих места — все работают удаленно.
Дальше из всех надо обучить — это делает непременно тимлид, он же делает всё код ревью и вообще всю коммуникацию по всей команде.
Как его на все хватает? Кто играет его роль, когда он уходит в отпуск? Сколько тимлидов нужно команде?
Я не знаю что такое высокий коммуникативный скилл по-вашему, но с моей точки зрения для того чтобы рассказать о себе он не нужен. Такое же умение структурировать информацию и слышать собеседника как и при коммуникации между программистами.
Я не очень понимаю зачем надо создавать single point of failure в виде тимлида причем тимлида с идеальной памятью. С моей точки зрения лучше чтобы сеньоры могли его поменять хотя бы в каких-то областях.
Ну да ладно мы тут пошли по кругу
Да, но не весь: знанияможно передать через общение, а умения и навыки вырабатываются самостоятельно.
А почему нельзя "всех посмотреть"? Конкурсы запрещены внутренними правилами или законодательством?
Это зависит от подхода обоих. Если вы сильно нужны, то к вам будут приспосабливаться даже если вы не хотите пойти навстречу. С другой стороны если вы покажете что искренне хотите понять собеседника и рассказать, что он хочет слышать, то вам будет плюс.
Ну вот мне нужен, допустим, человек в команду. Надо делать такую-то работу, но при прочих равных хотелось бы чтобы он мог делать что-то еще, например, иметь перспективу вырасти на должность выше.
А если сеньёра нет, но сойдет и мидл, но если есть сеньёр лучше сеньёра?
Как в кафе — хочу кашу на завтрак, но если ничего уж совсем нет — давайте ваш эгг макмаффин.
Адекватному интервюэру не надо докапываться до чего-то ему нужно понять с кем он беседует и стоит ли его принимать на работу. Специально валить кого-то никому не надо. А если надо, то он вам не нужен, наверное?
Ну это по ситуации — можно перебить вежливо да так, что перебиваемому понравится. Мне так рекомендовали делать когда человек завел шарманку, уставился в пространство и нудит что-то свое не обращая внимание на то, что это неинтересно собеседникам.
Эти ваши выводы на каких фактах основаны?
Т.е. статьи на хабре, разговоры, книжки и ролики получаются из других разговоров, статей, книжек и роликов и никак не из опыта.
А первую статью, книжку, разговор или ролик нам передал бог или инопланетяне!
Я думаю, у вас на интервью должно быть предположение о том, что именно интересно о вас знать. Так что вполне можно как-то более конкретнее, нет?
Интервью это не монолог. Спросивший вполне может направить беседу в интересующее его русло.
С моей точки зрения пользоваться гарантированно корректными трансформациями кода — это плюс — быстрее и меньше возможности совершить ошибку.
То есть как. Вы вообще всех нанимаете кто хоть как-то подходит? Если их пришла 1000 наймёте 1000 — не будете искать одного лучшего?
Возможно, у нас разный уровень кандидатов. У меня значительное количество тех, кто не может проверить работоспособность простого кода — проверяют, например, только позитивные сценарии.
Я не даю заданий на память. Только на логику и дизайн. Если человек, например, пишет в резюме 5 лет работы с технологией, то вроде с IDE он должен справиться — если забудет точку с запятой она подскажет. А потом интересно, как он будет убеждаться в работоспособности. А еще интересно как он трансформирует код. Например, использует буфер обмена или рефакторинги. Всякие мелочи я сам ему подскажу.
Понимаете, тут нет никакого соревнования между проверяющим и кандидатом. Есть соревнование между кандидатом и другими кандидатами. Так что неравенство здесь не играет роли.
Ну не знаю зачем это вам. Мне было бы интересно сможете ли вы сами добиться работоспособности кода и каким образом вы будете его тестировать. Т.е. какой общий подход.