Странная рекомендация. Начну с начала. Зачем собеседуем?
Мы пытаемся понять, подходит ли кандидат в команду. Кандидат пытается понять, надо ему или нет. Если сосредоточится на первой части, то логично прийти на собеседование со списоком вопросов, которые должны обеспечить получение информации о кандидате и сравнить его с другими.
И тут очевидно торчат ушки некоторой систематизации вопросов, их категоризации. И применения простого и всегда работающего принципа "в хорошем вопросе половина правильного ответа". На собеседовании еще проще, так как мы ж не задаем вопрос про неизвестное нам. Мы знаем, если ты тимлид, что должно быть в ответе.
Все. Зная ответы, строим вопросы так, чтобы либо их получить, либо получить четкий сигнал, что кандидат этого не знает.
Как именно? Предполагается, что тим лид уже умеет говорить с людьми, и в состоянии лидить разговор, чтобы прийти тому, что ему надо.
А в статье ... зачем придумали http? Кому это было надо? Спроси меня такое, я подумаю, что с той стороны сидит идиот 60+, которому реально хочется получить буквальные ответы на эти вопросы и поговорить о временах, когда трава была зеленее и дальше по списку
Если о самом языке - то это формализованная штука. Очень. Советую написать что-то типа семантического разбора математического выражения, сразу придет понимае :)
С точки зрения сути - язык программирования, это способ изложить свои мысли в рамках определнной парадигмы программирования :) Т.е. это не живой язык, а то, что связано с мвшлением определнным образом, например объекто-ориентированное.
Т.е. мышление первично, а язык связан с ним. Это что-то похоже на связь мышления и языка в философии. Но мышление первично.
А где гуманитарий и объекто-ориенировавнное программирование надеюсь пояснять не надо?
Сложная ситуация. Честно говоря, аналитики все разные и на собеседовании сложно выявить
Да, легко проверить технические знания, ем более часто там проверять особо нечего.
Можно попросить нарисовать схему процесса, но ценным является не ее срисовка, а умение понять потребность заказчика и нарисовать то, чего нег, но будет работать
Можно попросить рассказать, как контролировать полноту требований, скоуп, но на реальном проекте вылезет, что аналитик не понимает проект и этого не может сделать в принципе
Самое важное:
Землеройка, аналитик не пишет кол, он склеивает заказчика и разработку и его обязанности часто формально недоопределены. Поэтому копать до побеы - обязательное условие
Коммуникабельность и умение работать с конфликтами. Птица говорун по сути бесполезна. Важно уметь слушать всех, запоминать и сводить в одну точку. И эту точку описать максимально прозрачно для всех. Но если не можешь - не все потеряно, можно работать на вторых ролях, если на проекте больше одного
Ориентированность на результат. Это основное, код, строиз, 100500 выполненных задач - по фиг, если продукт не работает так как надо. Надо понимать цель и под нее строить все, в том числе заказчик, который первый готов уйти убсуждать шрифты или цыювет фона. Все меряется продуктом - вышло хреново, аналитика на кол, как минимум главного. Не понимая цели, можно получить 100500 тасок, которые не собиратся в целое
Готовность слушать всех и прочить помощь зала. Аналиьик часто самый слабый спец во всем. Технически он слабее любрго дева, в бизнесе все равно шaрит меньше чем SME, в дизайне ... и так во всем. Агалиьик не должен брать на себя, он должен собиоать все мнения и помогать выйти на решение
КАк проверить? Не знаю. По рекомендации. Это более менее раьотает
Остальное - честно, ты либо попадешь в проблему, либо узнаешь потом.
В целом в статбе все неплохо, но из опыта есть куча примеров, что у коассного на вид спеца был скелет в шкафк, который его помножил на ноль
Корона на голове
Спорщик
Безинициативная все уточняющая овечка
Небрежность
Хитросделанная редиска, которая имеет огромный опыт эмуляции работы
На последних собеседованиях тим лид просил рассказать о преймуществах микросервисом перед монолитом. Мне же (я больше выполнял функцию постороннего оценщика) после каждого ответа собеседуемого было интересно привести пример, что приведенное в пример преймущество достижимо и в монолитной архитектуре и послушать ответ,из которого понять, человек реально думает или просто заучил
Но интересно другое ... в реале разницы особо нет :) Точнее есть, но скорее не на уровне могу/не могу, а ближе к дискуссии уровня левый руль/правый руль
Как минимум, для обычных бизнес задач
С другой стороны, ценнсть того, что в данный момент все в команде шагают в ногу реально важна, путь даже и ритм просто один из
Мне кажется, суть статьи во фразе "И все они, как и я, испытывают очень серьезные затруднения при поиске новой работы."
Т.е. статья написана человеком, который имеет сложности с поиском работы и вращается в круге таких же. Это в целом достаточно :)
По собеседования ... по опыту, если ищешь человека на не очень большую ставку, отсев очень большой. Реально, можно играть в игру "я закончу собеседование за 10 минут ... а я за 9 ... ок, собеседуй". Многие кандидаты просто не знают элемкнтарных вещей, вообще. И так было и раньше. Помню в 2000е искали кандидатов, где главный технический критерий был знание SQL. Было 4 запроса, от простого к сложному. Сложный был что-то вроде выбрать сначала с чем-то самым большим, а потом с ними еще что-то сделать. Ничего заумного, реально. До 4го не доходил почти никто, да и до третьего тоже
По своему негативному опыту. Было собеседование (архитектор), когда спрашивали кучу терминов, которых я не знал. Я их и сейчас наверное не знаю, но им было очень важно.
Было неуспешное, когда искали спеца на нишевые задачи в базах и реально спрашивали нюансы, на фоне которых щнание сайд эффекта от ключа, не подпертого индексом кажутся цветочками. Наверное и хорошо
Хорошие србеседования, когда с той стороны сидит умный человек и вы просто беседуете. Есть о чем, можно обменяться мыслями и в конце прийти к соглашению о потенутале возможного сотрудничества. Жаль, трудно понять, насколько ты являешьс таким человнком, когда собеседуешь :)
Не знаю, по итогу и о чем. Я бы скпзал, сто либо автор не склонен все струтктурировать, либо у него было настроение просто писать как пишется. И потом сразу опубликовать :)
Про козлов да, но к сожалению они маскируются. Но точно надо их увольнять
Из своего опыта, лениво счиьпть, но наверное кандидатов 50 было самвх разных должнлстей. Я под позицию выделяю 5-6 основных скиллов/умений/качеств и под них пишу вопросы
После собеседования ставлю оценки, потом кандидаты сравниваются. Легко сказать, что этот тут лучше или хуже и видится картина
Как минимум я пвтаюсь понять, почему этот учше того
Мне кажется статья очень поверхностно описывает суть явления "рок-звезды" в ИТ организации. С позиции не организации, где эта "звезда" может оказаться одним из 10000 записей в зарплатной ведомости, именно этого человека в роли эсперта.
Даже в такой отрасли, как командный спорт, потеря звезды может не являться проблемой для результатов команды и организации. Есть куча примеров, когда потеря звезды пошла на пользу, равно как и обратных. Есть примеры достижения спротивного успеха вообще без звезд (но редко, а часто на коротких турнирах). Но там звезды нужны, и работа с ними, в том числе расставание является частью процессов управления командой. Но даже в таком, казалось бы ориентированном на звезд бизнесе, звездой может оказаться тренер (интересно, кого-то смушает, что он уже не может бить по мячу?) или даже менеджер (что правда почти не интересно фанатам). Но если копнуть еще чуть-чуть, то окажется, что успешность клубов определяется не столько спортивными достижениями, а прибылью. Спортсмены вообще тотальные лузерв, если мерять не отдельными матчами, а турнирами. Победитель один, остальные проиграли и статистика очень сильно против каждого :)
Но вот быть прибыльным многие годы, наращивать фпнатскую базу и спонсорские контракты - эта невидимая и основная часть работы клуба. И она определяет общий его потенциал, так как в конечном итоге система превратит количество в качественный, пусть даже и единичный результат.
Тоже самое в ИТ. Только хуже. Разработка такая же маленькая, не, намного меньшая часть общих процессов компании. И локальная звездочка этого процесса - реально очень малая величина на фоне всего неба :)
Про остальное - тейлоризация: вы попробуйте реализовать на практике :)
Особенно в живом проекте. Ну факты типа спецификации входящего сообщения - можно, но и в коде можно посмотреть. Описание логики работы метода - сомнительно. Описание почему сделали так - вообще никогда. А это самое важное, так как все "грабли" тут
Если просто, то тимлид - это прораб. Основная личная задача, которая именно на нем - рабочий процес разработки. Если человек еще не понял, как это сделать - он максимум сеньор.
Остальное - по желанию/возможности. Есть gap в части архитектуры - заполняй. Есть время кодить - бери тикеты.
"Азы" вы все равно получаете самостоятельно, курсы могут дать только направление для изучения. Зачем вам автоматизация - я вообще не понимаю. Вы еще не умете делать базовые вещи, а вам уже рассказывают как делать doing shit faster.
Равно как и разные виды тестирования, которые отличаются от "базового" функционального. Вы не написали, читают вам это или нет (я мог невнимательно прочитать ваш опус), но вам это все равно бесполезно пытаться понять сейчас.
При попытке устроиться на работу ваше резюме будет таким же как и у 90% соискателей и сильно повезет, если оно не полетит сразу в шредер.
Попытайтесь усьроитьсч на реальную работу за копейки, чтобы полусючить опыт и вообще понять ... может вам стоит заняться репетиторством
Не очень удобно, когда статья о большей части это отсылки к каким-то более ранним темам, комментариям и т.д. Может потеряться идея и возможно я понял что-то не так. Но тем не менее:
1) спеки вперед - отличная идея. Перед спеками - соглашения о структуре, типах и других глобальных вещах
2) Технический инструмент - в идеале такой, который соответствует коду. Обычно это легче всего достигнуть, если он оттуда генерится. Тогда как минимум код будет соответствовать контракту.
3) Фронт генерит контракт - скорее нет, чем да. Тем более АПИ может быть одно, а фронтов и вообще, его пользователей много :)
4) В мелких проектах можно создать ситуацию, в которой хвост вертит собакой (фронт пишет контракты для бэка) ... но для мелких проектов такие проблемы скорее говорят о том, что два-три человека просто не общаются, а для крупных смотри выше
Так как все равно не взлетит, надо чтобы было понятно, что это не из-за тебя
Мучить себя, пытаясь сделать мертвый проект никакого смысла нет. Получишь неудовлетворение результатом и мину в карму, так как могут назначить виноватым
Странная рекомендация. Начну с начала. Зачем собеседуем?
Мы пытаемся понять, подходит ли кандидат в команду. Кандидат пытается понять, надо ему или нет. Если сосредоточится на первой части, то логично прийти на собеседование со списоком вопросов, которые должны обеспечить получение информации о кандидате и сравнить его с другими.
И тут очевидно торчат ушки некоторой систематизации вопросов, их категоризации. И применения простого и всегда работающего принципа "в хорошем вопросе половина правильного ответа". На собеседовании еще проще, так как мы ж не задаем вопрос про неизвестное нам. Мы знаем, если ты тимлид, что должно быть в ответе.
Все. Зная ответы, строим вопросы так, чтобы либо их получить, либо получить четкий сигнал, что кандидат этого не знает.
Как именно? Предполагается, что тим лид уже умеет говорить с людьми, и в состоянии лидить разговор, чтобы прийти тому, что ему надо.
А в статье ... зачем придумали http? Кому это было надо? Спроси меня такое, я подумаю, что с той стороны сидит идиот 60+, которому реально хочется получить буквальные ответы на эти вопросы и поговорить о временах, когда трава была зеленее и дальше по списку
Статья о том, что мы потратили много денег и довели до конца то, что нам посоветовали "крутые" консалтере
Даже не так, это доклад для конференции, где собрались большие дядьки за много денег, и мы решили рассказать, как мы потратили много денег.
Так это всегда так
Тоже самое с курсами по всяким методологиям и т.д.
Заработок точно у тех, кто ведет курсы :)
Человек кодом не говорит
А записывает результаты мыслительного процесса в определенной парадигме
Если она тебе не известна - ничего не поймешь
И да, слово "язык" многозначно :)
Язык программирования ...
Если о самом языке - то это формализованная штука. Очень. Советую написать что-то типа семантического разбора математического выражения, сразу придет понимае :)
С точки зрения сути - язык программирования, это способ изложить свои мысли в рамках определнной парадигмы программирования :) Т.е. это не живой язык, а то, что связано с мвшлением определнным образом, например объекто-ориентированное.
Т.е. мышление первично, а язык связан с ним. Это что-то похоже на связь мышления и языка в философии. Но мышление первично.
А где гуманитарий и объекто-ориенировавнное программирование надеюсь пояснять не надо?
Интересно, на чем это мнение основано? :)
Сложная ситуация. Честно говоря, аналитики все разные и на собеседовании сложно выявить
Да, легко проверить технические знания, ем более часто там проверять особо нечего.
Можно попросить нарисовать схему процесса, но ценным является не ее срисовка, а умение понять потребность заказчика и нарисовать то, чего нег, но будет работать
Можно попросить рассказать, как контролировать полноту требований, скоуп, но на реальном проекте вылезет, что аналитик не понимает проект и этого не может сделать в принципе
Самое важное:
Землеройка, аналитик не пишет кол, он склеивает заказчика и разработку и его обязанности часто формально недоопределены. Поэтому копать до побеы - обязательное условие
Коммуникабельность и умение работать с конфликтами. Птица говорун по сути бесполезна. Важно уметь слушать всех, запоминать и сводить в одну точку. И эту точку описать максимально прозрачно для всех. Но если не можешь - не все потеряно, можно работать на вторых ролях, если на проекте больше одного
Ориентированность на результат. Это основное, код, строиз, 100500 выполненных задач - по фиг, если продукт не работает так как надо. Надо понимать цель и под нее строить все, в том числе заказчик, который первый готов уйти убсуждать шрифты или цыювет фона. Все меряется продуктом - вышло хреново, аналитика на кол, как минимум главного. Не понимая цели, можно получить 100500 тасок, которые не собиратся в целое
Готовность слушать всех и прочить помощь зала. Аналиьик часто самый слабый спец во всем. Технически он слабее любрго дева, в бизнесе все равно шaрит меньше чем SME, в дизайне ... и так во всем. Агалиьик не должен брать на себя, он должен собиоать все мнения и помогать выйти на решение
КАк проверить? Не знаю. По рекомендации. Это более менее раьотает
Остальное - честно, ты либо попадешь в проблему, либо узнаешь потом.
В целом в статбе все неплохо, но из опыта есть куча примеров, что у коассного на вид спеца был скелет в шкафк, который его помножил на ноль
Корона на голове
Спорщик
Безинициативная все уточняющая овечка
Небрежность
Хитросделанная редиска, которая имеет огромный опыт эмуляции работы
Соглашусь
На последних собеседованиях тим лид просил рассказать о преймуществах микросервисом перед монолитом. Мне же (я больше выполнял функцию постороннего оценщика) после каждого ответа собеседуемого было интересно привести пример, что приведенное в пример преймущество достижимо и в монолитной архитектуре и послушать ответ,из которого понять, человек реально думает или просто заучил
Но интересно другое ... в реале разницы особо нет :) Точнее есть, но скорее не на уровне могу/не могу, а ближе к дискуссии уровня левый руль/правый руль
Как минимум, для обычных бизнес задач
С другой стороны, ценнсть того, что в данный момент все в команде шагают в ногу реально важна, путь даже и ритм просто один из
Мне кажется, суть статьи во фразе "И все они, как и я, испытывают очень серьезные затруднения при поиске новой работы."
Т.е. статья написана человеком, который имеет сложности с поиском работы и вращается в круге таких же. Это в целом достаточно :)
По собеседования ... по опыту, если ищешь человека на не очень большую ставку, отсев очень большой. Реально, можно играть в игру "я закончу собеседование за 10 минут ... а я за 9 ... ок, собеседуй". Многие кандидаты просто не знают элемкнтарных вещей, вообще. И так было и раньше. Помню в 2000е искали кандидатов, где главный технический критерий был знание SQL. Было 4 запроса, от простого к сложному. Сложный был что-то вроде выбрать сначала с чем-то самым большим, а потом с ними еще что-то сделать. Ничего заумного, реально. До 4го не доходил почти никто, да и до третьего тоже
По своему негативному опыту. Было собеседование (архитектор), когда спрашивали кучу терминов, которых я не знал. Я их и сейчас наверное не знаю, но им было очень важно.
Было неуспешное, когда искали спеца на нишевые задачи в базах и реально спрашивали нюансы, на фоне которых щнание сайд эффекта от ключа, не подпертого индексом кажутся цветочками. Наверное и хорошо
Хорошие србеседования, когда с той стороны сидит умный человек и вы просто беседуете. Есть о чем, можно обменяться мыслями и в конце прийти к соглашению о потенутале возможного сотрудничества. Жаль, трудно понять, насколько ты являешьс таким человнком, когда собеседуешь :)
Не знаю, по итогу и о чем. Я бы скпзал, сто либо автор не склонен все струтктурировать, либо у него было настроение просто писать как пишется. И потом сразу опубликовать :)
Про козлов да, но к сожалению они маскируются. Но точно надо их увольнять
Из своего опыта, лениво счиьпть, но наверное кандидатов 50 было самвх разных должнлстей. Я под позицию выделяю 5-6 основных скиллов/умений/качеств и под них пишу вопросы
После собеседования ставлю оценки, потом кандидаты сравниваются. Легко сказать, что этот тут лучше или хуже и видится картина
Как минимум я пвтаюсь понять, почему этот учше того
Чего-то люто до фига. Стоит порыться в себе :)
Мне кажется статья очень поверхностно описывает суть явления "рок-звезды" в ИТ организации. С позиции не организации, где эта "звезда" может оказаться одним из 10000 записей в зарплатной ведомости, именно этого человека в роли эсперта.
Даже в такой отрасли, как командный спорт, потеря звезды может не являться проблемой для результатов команды и организации. Есть куча примеров, когда потеря звезды пошла на пользу, равно как и обратных. Есть примеры достижения спротивного успеха вообще без звезд (но редко, а часто на коротких турнирах). Но там звезды нужны, и работа с ними, в том числе расставание является частью процессов управления командой. Но даже в таком, казалось бы ориентированном на звезд бизнесе, звездой может оказаться тренер (интересно, кого-то смушает, что он уже не может бить по мячу?) или даже менеджер (что правда почти не интересно фанатам). Но если копнуть еще чуть-чуть, то окажется, что успешность клубов определяется не столько спортивными достижениями, а прибылью. Спортсмены вообще тотальные лузерв, если мерять не отдельными матчами, а турнирами. Победитель один, остальные проиграли и статистика очень сильно против каждого :)
Но вот быть прибыльным многие годы, наращивать фпнатскую базу и спонсорские контракты - эта невидимая и основная часть работы клуба. И она определяет общий его потенциал, так как в конечном итоге система превратит количество в качественный, пусть даже и единичный результат.
Тоже самое в ИТ. Только хуже. Разработка такая же маленькая, не, намного меньшая часть общих процессов компании. И локальная звездочка этого процесса - реально очень малая величина на фоне всего неба :)
Про остальное - тейлоризация: вы попробуйте реализовать на практике :)
Документация ... удачи в чтении :)
Особенно в живом проекте. Ну факты типа спецификации входящего сообщения - можно, но и в коде можно посмотреть. Описание логики работы метода - сомнительно. Описание почему сделали так - вообще никогда. А это самое важное, так как все "грабли" тут
Если просто, то тимлид - это прораб. Основная личная задача, которая именно на нем - рабочий процес разработки. Если человек еще не понял, как это сделать - он максимум сеньор.
Остальное - по желанию/возможности. Есть gap в части архитектуры - заполняй. Есть время кодить - бери тикеты.
"Азы" вы все равно получаете самостоятельно, курсы могут дать только направление для изучения. Зачем вам автоматизация - я вообще не понимаю. Вы еще не умете делать базовые вещи, а вам уже рассказывают как делать doing shit faster.
Равно как и разные виды тестирования, которые отличаются от "базового" функционального. Вы не написали, читают вам это или нет (я мог невнимательно прочитать ваш опус), но вам это все равно бесполезно пытаться понять сейчас.
При попытке устроиться на работу ваше резюме будет таким же как и у 90% соискателей и сильно повезет, если оно не полетит сразу в шредер.
Попытайтесь усьроитьсч на реальную работу за копейки, чтобы полусючить опыт и вообще понять ... может вам стоит заняться репетиторством
Не очень удобно, когда статья о большей части это отсылки к каким-то более ранним темам, комментариям и т.д. Может потеряться идея и возможно я понял что-то не так. Но тем не менее:
1) спеки вперед - отличная идея. Перед спеками - соглашения о структуре, типах и других глобальных вещах
2) Технический инструмент - в идеале такой, который соответствует коду. Обычно это легче всего достигнуть, если он оттуда генерится. Тогда как минимум код будет соответствовать контракту.
3) Фронт генерит контракт - скорее нет, чем да. Тем более АПИ может быть одно, а фронтов и вообще, его пользователей много :)
4) В мелких проектах можно создать ситуацию, в которой хвост вертит собакой (фронт пишет контракты для бэка) ... но для мелких проектов такие проблемы скорее говорят о том, что два-три человека просто не общаются, а для крупных смотри выше
В нерабочем проекте надо:
Развивать свои скиллы
Так как все равно не взлетит, надо чтобы было понятно, что это не из-за тебя
Мучить себя, пытаясь сделать мертвый проект никакого смысла нет. Получишь неудовлетворение результатом и мину в карму, так как могут назначить виноватым