Процитировал в той части, чтобы стало очевидным что в определении термина А используется термин В, а в определении термина В - термин А. Это настолько же странно, как доказывать теорему А на основании теоремы В, а теорему В на основании теоремы А. Остальное для сообщения было незначимо.
На дальнейшую дискуссию про пятистенки, признаться, не рассчитал :)
об отличиях REST и SOAP - зачем сравнивать архитектурный стиль и протокол
К сожалению кандидаты в большинстве своём не знают что REST это архитектурный стиль. Более того, я не уверен что они знают чем "архитектурный стиль" отличается от "протокола". Для них REST и SOAP - одного поля ягоды.
Поэтому вопрос принимается как естественный и имеющий смысл, и они пытаются отвечать по мере своего разумения.
Мхм, я где-то писал что ищу специалистов уровня Junior? Попадались и вполне нормальные ребята, которых чуток подтянуть - и полноценная боевая единица готова. Джунам разумеется надо задавать совсем другие вопросы.
Поиск прошел нормально, доля собеседований которые закончились оффером близка к моей средней.
Читая вашу статью, я вижу требования к senior и начальный уровень архитектора
Это очень интересно, потому что в статье нет вообще никаких требований :) Где вы их там нашли?
Ещё момент про книжки, где вы берете время, чтобы их читать?
Есть у меня такая дурацкая привычка - читать. Примерно час-полтора в день получается. Понятно что это не только профессиональная литература, но и она тоже.
Нигде не было утверждения что аналитику надо знать разницу между СУБД. С моей точки зрения это не требуется.
Но если кандидат указывает в резюме в разделе "Ключевые (!) навыки" две СУБД, то логично ожидать что он про них что то знает. А если знает - то может сравнить.
Проблема не в том что не знают разницу между СУБД, а в том что в резюме пишут ерунду и потом не могут подтвердить написанное.
Ага, у меня есть правило что сотрудники должны быть способны к самостоятельному мышлению. Отказываться от него не планирую. И да, я очень расстроен тем, что не все люди это могут - мир был бы гораздо лучше.
По первому пункту - вы даёте просто отличный ответ на кейс. К сожалению такого ответа от кандидатов я не получаю.
По второму - ну вот вам пример, про область применения ложки и вилки. Кандидат озвучивает прошлый опыт: ложкой я ел грибной суп и манную кашу, а вилкой - спагетти. Это прекрасно, но для нормального ответа на вопрос стоит дать обобщение - что ложка нужна для жидкой пищи, а вилка - для твёрдой. Без обобщения ответ слабый.
Если вы про ГОСТ 34, то он на автоматизированные системы, а не на ПО. Поэтому ТЗ по ГОСТ 34 содержит много того, что не является требованием к ПО. Что вполне логично. Если про ГОСТ 19, то я признаться уже не помню что там в ТЗ.
Порядок разработки или порядок приемки - это не требование к самому ПО, это требование к процессу его создания. Их принято разделять. Требования к процессу создания ПО - это менеджерская история, аналитику они скорее для информации.
В вашей точке зрения есть своя правда. Но в том же babok или у Леффингуэлла определение термина "требование" приводится.
"Делюсь субъективными переживаниями" - совершенно верно, только личный опыт и никаких претензий на объективность. Насчет "завышенных зарплатных ожиданий" - на этом не акцентировался, не готов судить какой уровень зарплаты адекватный, а какой завышенный. Возможно где-то в другом месте нужен кандидат именно с этими навыками и его оторвут с руками. "Пригорело" - нет, ничего не пригорало, скорее удивление и легкое разочарование.
Я ищу на рынке кадры, которые эффективны в конкретных условиях. Что такое "эффективны" - тема для отдельной статьи, там много аспектов.
Функция системного аналитика - разработка и сопровождение требований к программному обеспечению. В профстандарте "Системный аналитик" нормально написано про это.
Лично имел дело с одним человеком, который знал только BPMN и использовал его для всего. И диаграммы состояний, и диаграммы взаимодействия, и потоки данных, и алгоритмы - все рисовал на BPMN. Понятно что часто стандарту это не всегда соответствовало, но понять было можно (приложил определенные когнитивные усилия).
Если бы в "ящике с инструментами" было больше нотаций - можно было бы под каждый случай выбирать наиболее подходящую. Это и более общепринято, и рисовать проще, и понимать легче. Но поскольку в ящике лежит только BPMN - имеем то что имеем.
Если не проверить наличие "глубокого анализа" (ну ладно, не глубокого, хотя бы какого-нибудь) и "системного подхода", то есть высокая вероятность набрать таких исполнителей, глядя на результаты работы которых хватаешься за голову и спрашиваешь - "ЗАЧЕМ ты это сделал?"
Не "ЧТО", а именно "ЗАЧЕМ". Потому что сделано может быть быстро, аккуратно и технически грамотно - к этому не придраться. А вот с целеполаганием и соответствием окружающей действительности - просто беда.
Отчасти вы правы - 10 лет назад такие вопросы (не про "перенос гор", а указанные в статье) мне бы показались абсолютно бесполезными и вообще верхом тупости - зачем это спрашивают, какое отношение это имеет к работе?
При проведении собеседований в те годы (как раз в 2012 году был первый опыт в роли интервьюера на позицию аналитика) упор был на техническую составляющую: на собесе составляли требования, рисовали различные диаграммы, прототипы и т.д.
С возрастом шкала оценки меняется - сейчас по технике спрашиваю буквально пару кейсов. Основная часть беседы - проверка способности к самостоятельному мышлению.
Так что да, это в том числе и старческое брюзжание. Сократ на обложке это подчеркивает.
Инструменты и технологии - дело наживное, тем более для СА. От Senior я бы ждал наличия какого-то набора инструментария, который является "продолжением руки". Причем не так важно какого именно - просто как подтверждение наличия опыта и "ремесла в руках". От других уровней - не так важно.
"Хорошая память" вообще не критерий, скорее "наличие навыка работы с информацией".
"Умение смотреть на ситуацию сверху", "формулировать определения" - это всё про одно и то же, про уровень мышления.
Мне кажется вы не учли контекст - "собеседование СА с опытом 1.5-3 года".
Пример ответа выше не претендует на фактологическую точность и не должен быть таковым - ну откуда СА это знать? Это то, что можно сказать на основании общей эрудиции, здравого смысла, базовых знаний SQL и общеупотребимых слухов - что и может быть в голове у СА среднего уровня или ниже.
Если человек не знает, но при этом даёт внятный ответ, при этом четко отделяя факты от допущений - это прямо медаль на грудь и оффер на собеседовании.
P.S. Ну и писать в одном посте сразу "Oracle тоже можно использовать бесплатно" и "если сравнивать EE с полным фаршем за сотни нефти" - как-то странно.
Процитировал в той части, чтобы стало очевидным что в определении термина А используется термин В, а в определении термина В - термин А. Это настолько же странно, как доказывать теорему А на основании теоремы В, а теорему В на основании теоремы А. Остальное для сообщения было незначимо.
На дальнейшую дискуссию про пятистенки, признаться, не рассчитал :)
Дискуссия в комментариях в основном идёт на следующие темы:
Конструктивная дискуссия по теме статьи. По мере сил своих в этом участвую.
Чем отличается Oracle от PostgreSQL. К статье никакого отношения не имеет, но почему бы про это не поговорить.
У автора (или в компании автора) проблемы и он все делает не так.
Требования к вакансии имеют отношение только к третьей теме. Она мне не интересна и участвовать в её обсуждении не планирую.
К сожалению кандидаты в большинстве своём не знают что REST это архитектурный стиль. Более того, я не уверен что они знают чем "архитектурный стиль" отличается от "протокола". Для них REST и SOAP - одного поля ягоды.
Поэтому вопрос принимается как естественный и имеющий смысл, и они пытаются отвечать по мере своего разумения.
Мхм, я где-то писал что ищу специалистов уровня Junior? Попадались и вполне нормальные ребята, которых чуток подтянуть - и полноценная боевая единица готова. Джунам разумеется надо задавать совсем другие вопросы.
Поиск прошел нормально, доля собеседований которые закончились оффером близка к моей средней.
Это очень интересно, потому что в статье нет вообще никаких требований :) Где вы их там нашли?
Есть у меня такая дурацкая привычка - читать. Примерно час-полтора в день получается. Понятно что это не только профессиональная литература, но и она тоже.
Нигде не было утверждения что аналитику надо знать разницу между СУБД. С моей точки зрения это не требуется.
Но если кандидат указывает в резюме в разделе "Ключевые (!) навыки" две СУБД, то логично ожидать что он про них что то знает. А если знает - то может сравнить.
Проблема не в том что не знают разницу между СУБД, а в том что в резюме пишут ерунду и потом не могут подтвердить написанное.
Как минимум для меня
И вероятно для какой то доли остальных обителелей нашего мира
Долю оценить затрудняюсь
Ага, у меня есть правило что сотрудники должны быть способны к самостоятельному мышлению. Отказываться от него не планирую. И да, я очень расстроен тем, что не все люди это могут - мир был бы гораздо лучше.
По первому пункту - вы даёте просто отличный ответ на кейс. К сожалению такого ответа от кандидатов я не получаю.
По второму - ну вот вам пример, про область применения ложки и вилки. Кандидат озвучивает прошлый опыт: ложкой я ел грибной суп и манную кашу, а вилкой - спагетти. Это прекрасно, но для нормального ответа на вопрос стоит дать обобщение - что ложка нужна для жидкой пищи, а вилка - для твёрдой. Без обобщения ответ слабый.
Если вы про ГОСТ 34, то он на автоматизированные системы, а не на ПО. Поэтому ТЗ по ГОСТ 34 содержит много того, что не является требованием к ПО. Что вполне логично. Если про ГОСТ 19, то я признаться уже не помню что там в ТЗ.
Понятно что это тема для отдельной дискуссии.
Порядок разработки или порядок приемки - это не требование к самому ПО, это требование к процессу его создания. Их принято разделять. Требования к процессу создания ПО - это менеджерская история, аналитику они скорее для информации.
В вашей точке зрения есть своя правда. Но в том же babok или у Леффингуэлла определение термина "требование" приводится.
"Делюсь субъективными переживаниями" - совершенно верно, только личный опыт и никаких претензий на объективность. Насчет "завышенных зарплатных ожиданий" - на этом не акцентировался, не готов судить какой уровень зарплаты адекватный, а какой завышенный. Возможно где-то в другом месте нужен кандидат именно с этими навыками и его оторвут с руками. "Пригорело" - нет, ничего не пригорало, скорее удивление и легкое разочарование.
Я ищу на рынке кадры, которые эффективны в конкретных условиях. Что такое "эффективны" - тема для отдельной статьи, там много аспектов.
Функция системного аналитика - разработка и сопровождение требований к программному обеспечению. В профстандарте "Системный аналитик" нормально написано про это.
Да
Канта я пробовал читать, но его честно не осилил
Очень тяжело идет :(
СУБД здесь не лучший пример.
Лично имел дело с одним человеком, который знал только BPMN и использовал его для всего. И диаграммы состояний, и диаграммы взаимодействия, и потоки данных, и алгоритмы - все рисовал на BPMN. Понятно что часто стандарту это не всегда соответствовало, но понять было можно (приложил определенные когнитивные усилия).
Если бы в "ящике с инструментами" было больше нотаций - можно было бы под каждый случай выбирать наиболее подходящую. Это и более общепринято, и рисовать проще, и понимать легче. Но поскольку в ящике лежит только BPMN - имеем то что имеем.
Если не проверить наличие "глубокого анализа" (ну ладно, не глубокого, хотя бы какого-нибудь) и "системного подхода", то есть высокая вероятность набрать таких исполнителей, глядя на результаты работы которых хватаешься за голову и спрашиваешь - "ЗАЧЕМ ты это сделал?"
Не "ЧТО", а именно "ЗАЧЕМ". Потому что сделано может быть быстро, аккуратно и технически грамотно - к этому не придраться. А вот с целеполаганием и соответствием окружающей действительности - просто беда.
Вот для этого нужен разум.
Отчасти вы правы - 10 лет назад такие вопросы (не про "перенос гор", а указанные в статье) мне бы показались абсолютно бесполезными и вообще верхом тупости - зачем это спрашивают, какое отношение это имеет к работе?
При проведении собеседований в те годы (как раз в 2012 году был первый опыт в роли интервьюера на позицию аналитика) упор был на техническую составляющую: на собесе составляли требования, рисовали различные диаграммы, прототипы и т.д.
С возрастом шкала оценки меняется - сейчас по технике спрашиваю буквально пару кейсов. Основная часть беседы - проверка способности к самостоятельному мышлению.
Так что да, это в том числе и старческое брюзжание. Сократ на обложке это подчеркивает.
Еще можно вспомнить про существование множества всех множеств, которое при этом не является подмножеством самого себя.
Вопрос множеств действительно ключевой в математике.
Инструменты и технологии - дело наживное, тем более для СА. От Senior я бы ждал наличия какого-то набора инструментария, который является "продолжением руки". Причем не так важно какого именно - просто как подтверждение наличия опыта и "ремесла в руках". От других уровней - не так важно.
"Хорошая память" вообще не критерий, скорее "наличие навыка работы с информацией".
"Умение смотреть на ситуацию сверху", "формулировать определения" - это всё про одно и то же, про уровень мышления.
Комментарий мощный, спасибо.
Признать я так далеко не заходил, и всегда считал GERAM и иже с ним не применимым на практике отвлеченным умствованием.
Но возможно я не прав и при достижении определенного уровня осознанности приходит понимание его роли и смысла.
Мне кажется вы не учли контекст - "собеседование СА с опытом 1.5-3 года".
Пример ответа выше не претендует на фактологическую точность и не должен быть таковым - ну откуда СА это знать? Это то, что можно сказать на основании общей эрудиции, здравого смысла, базовых знаний SQL и общеупотребимых слухов - что и может быть в голове у СА среднего уровня или ниже.
Если человек не знает, но при этом даёт внятный ответ, при этом четко отделяя факты от допущений - это прямо медаль на грудь и оффер на собеседовании.
P.S. Ну и писать в одном посте сразу "Oracle тоже можно использовать бесплатно" и "если сравнивать EE с полным фаршем за сотни нефти" - как-то странно.
А мне нравится "квартира" и "многоквартирный дом" в ЖК РФ:
Многоквартирный дом - здание, состоящее из двух и более квартир
Квартира - помещение в многоквартирном доме
По отдельности каждое определение выглядит нормально, а вместе какая то рекурсия.