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