согласен. хуже нет, когда в тягость тех.интервьюеру проводить собеседование. и проблема, как вы справедливо заметили, обоюдная: и менеджмент заставляет, и работник впрягается в чуждое дело.
в статистику "как оно бывает" по стимулированию. добавлю свой опыт. являюсь тех.интервьюером, дополнительных выплат не получаю, но время проведения собеседования и формирование обратной связи списывается наряду со временем по разработке, и берется в расчет при планировании спринта. т.е. интервьюирование такая же задача. и само собой на performance review учитывается эта активность. но, опять же, никто не заставляет: хочешь - проводи интервью, не хочешь - не проводи, но и не ной какая рутина на проекте или почему Васю повысили, а тебя нет. каждому - свое.
назвал бы вышеперечисленных вами моряками - выглядело бы с моей колокольни логично. опять же можно углубиться, что есть еще работники доков и портов.
также, как если бы вместо слова "программисты" Чернышенко использовал хотя бы слово "айтишники" или "работники IT-отрасли". по логике этого государственного мужа можно сказать, что в стране около миллиона чиновников "вице-премьеров". а какая разница?
именно программистов? а тестировщиков не считал? или системных аналитиков? администраторов различных специализаций?дизайнеров UI?... всех не смогу перечислить, прошу не обижаться, коллеги. или это все едино для вице-премьера курирующего (т.е. должен иметь хотя бы общее понимание) IT- отрасль? и на основании таким никаким образом собранных и преподносимых данных формируются управленческие решения на уровне страны? верной дорогой идём, товарищи! (про конец сарказма писать?)
если оба упёрлись, то никак. у нас, например, для этого есть разработчики (на разных уровнях иерархии) с ролью "техлид", за которыми крайнее для своего уровня решение.
да, именно так. одни понимают или пытаются понять, что под капотом (какая магия), а другим это не интересно. иногда просто не хватает кругозора в компьютерных науках и читать лекции - нет ресурса у ментора. поэтому всякому начинающему свое место. если не подошел одной компании, возможно есть другая где знаний и подхода к делу будет достаточно для трудовой деятельности.
опишу свой опыт, обобщать или описывать чужой не хочу. я - тот самый человек, который работает с начинающими разработчиками. и как бы там не горели глаза (от денег или желания - не знаю, в душу не заглядывал), но не все вывозят то, что требуется (конкретно в нашем проекте. возможно, в другом было бы иначе, но мы ведь не обобщаем). и это именно сравнительная оценка. не с теми, кто давно работает, а начинающих между собой. у меня есть один бриллиант, который тащит теперь лучше имеющихся мидлов. но бриллианты редкость. увы.
сам именно так и провожу интервью - даю кусок кода и в нем уже (неожиданно! ) находим и паттерны, и solid, и структуры данных, и прочие языковые моменты. кандидаты более расположены общаться, нежели спросить "билет 5. вопрос 1. паттерн синглтон")))
аналитика аналитике рознь. поэтому с моей точки зрения было бы уместнее не пытаться объять необъятное, рассказывая о сферическом руководстве аналитикой в вакууме, а поведать свой конкретный опыт. конкретные истории конкретных людей читать любопытнее. к обобщённой информации, отношусь скептически, не обессудьте.
самое приятное впечатление у меня осталось от одной девушки-рекрутера, которая после нашей милой 15 минутной беседы сама сказала на какую цифру в оффере можно ориентироваться и торговаться по итогам предстоящего технического собеседования. она же без прикрас описала проект и стек: "увы, легаси". да и по остальным аспектам не лукавила.
со своей колокольни разработчика делю системных аналитиков на две категории: одна умеет формулировать свои шальные мысли в структурированную совокупность осмысленных предложений письменной речи, другая - не умеет. у некоторых аналитиков уже заголовки задач говорят о той боли, через которую придется пройти, читая описание задачи и уточняя, какие именно мысли вкладывались в этот поток сознания. такое вот бывает айти.
поддерживаю.для статистики: я на свою первую оплачиваемую работу разработчиком попал на 4 курсе ВУЗа только потому, что препод меня посоветовал своему знакомому, который расширял команду и готов был брать без опыта. это потом все выяснилось за бокалом пенного - "мы тебя взяли, т.к. нам сказали, что ты шаришь".
аналогичная история. меня стали приглашать в качестве технического интервьюера, читаю резюме и думаю - как я могу проверить глубину знаний гениев (аналогичных описанным вами). начинаю немного беседовать об основах и пора выносить святых.
у меня был примерно похожий Девон, который не только не уменьшал техдолг, а своими задачами (строго по тз) плодил техдолг. при полном попустительстве свыше. я поговорил с ним, с тимлидом и при первой возможности ушел на другой проект, пусть там сами с ним разбираются.
согласен. просто те, кто пишут дефицит лукавят или подменяют понятия, недоговаривают ради громкого заголовка. вместо "дефицит кадров в отрасли X" следовало бы писать "дефицит кадров, удовлетворяющих моим (автора) требованиям". а полет фантазии в этих требованиях безграничен. более того, можно долго и упорно спорить о правильности этих требований, но дело это неблагодарное, т.к. лежит в плоскости субъективизма.
В российских компаниях встречал еще и такие наименования должностей: разработчик-стажер, младший разработчик, разработчик, старший разработчик, ведущий разработчик, главный разработчик, руководитель группы разработки.
Некоторые из них легко соотнести с классической схемой intern-junior-middle-senior, другие открывают простор для фантазии.
основная проблема при работе с людьми не умение наметить и выполнить план проведения встреч формата 1-1, а умение расположить к себе людей. последнее связано с ресурсом по удовлетворению желаний - а они у всех разные: есть субъективно адекватные, есть субъективно капризы маминого сладкого пирожка. примерный сценарий такой:
первая 1-1. человек рассказывает о проблемах, ведь его просят быть максимально открытым. проблемы обещают решить и не решают. по разным причинам, или забывают, или считают несущественными, или считают нерешаемыми, или нерешаемыми в ущерб другим людям и т.п.
вторая 1-1. человек напоминает о нерешенных проблемах. проблемы не решаются опять.
третья 1-1. человек говорит, что у него все отлично. проводящий 1-1 тешит себя, что он молодец и закрыл проблемы человека, человек счастлив. человек ищет работу и уходит рано или поздно в светлое (как ему кажется) будущее в другую компанию.
проводящий 1-1 думает: как же так? мы человека на помойке нашли, отмыли отчистили, а человек ушел. наверное, негодяй какой-то.
согласен. хуже нет, когда в тягость тех.интервьюеру проводить собеседование. и проблема, как вы справедливо заметили, обоюдная: и менеджмент заставляет, и работник впрягается в чуждое дело.
в статистику "как оно бывает" по стимулированию. добавлю свой опыт. являюсь тех.интервьюером, дополнительных выплат не получаю, но время проведения собеседования и формирование обратной связи списывается наряду со временем по разработке, и берется в расчет при планировании спринта. т.е. интервьюирование такая же задача. и само собой на performance review учитывается эта активность. но, опять же, никто не заставляет: хочешь - проводи интервью, не хочешь - не проводи, но и не ной какая рутина на проекте или почему Васю повысили, а тебя нет. каждому - свое.
на моей практике в случаях, когда перестаёт работать, то у людей, описанных вами начинаются аппеляции "там какая-то магия" и "нужен бубен".
назвал бы вышеперечисленных вами моряками - выглядело бы с моей колокольни логично. опять же можно углубиться, что есть еще работники доков и портов.
также, как если бы вместо слова "программисты" Чернышенко использовал хотя бы слово "айтишники" или "работники IT-отрасли". по логике этого государственного мужа можно сказать, что в стране около миллиона
чиновников"вице-премьеров". а какая разница?именно программистов? а тестировщиков не считал? или системных аналитиков? администраторов различных специализаций?дизайнеров UI?... всех не смогу перечислить, прошу не обижаться, коллеги. или это все едино для вице-премьера курирующего (т.е. должен иметь хотя бы общее понимание) IT- отрасль? и на основании таким
никакимобразом собранных и преподносимых данных формируются управленческие решения на уровне страны? верной дорогой идём, товарищи! (про конец сарказма писать?)если оба упёрлись, то никак. у нас, например, для этого есть разработчики (на разных уровнях иерархии) с ролью "техлид", за которыми крайнее для своего уровня решение.
да, именно так. одни понимают или пытаются понять, что под капотом (какая магия), а другим это не интересно. иногда просто не хватает кругозора в компьютерных науках и читать лекции - нет ресурса у ментора. поэтому всякому начинающему свое место. если не подошел одной компании, возможно есть другая где знаний и подхода к делу будет достаточно для трудовой деятельности.
опишу свой опыт, обобщать или описывать чужой не хочу. я - тот самый человек, который работает с начинающими разработчиками. и как бы там не горели глаза (от денег или желания - не знаю, в душу не заглядывал), но не все вывозят то, что требуется (конкретно в нашем проекте. возможно, в другом было бы иначе, но мы ведь не обобщаем). и это именно сравнительная оценка. не с теми, кто давно работает, а начинающих между собой. у меня есть один бриллиант, который тащит теперь лучше имеющихся мидлов. но бриллианты редкость. увы.
противоречия нет, т.к. компаниям не хватает 100500 рок-звезд по цене мальчиков из внеурочного кружка по пению. о чем и пестрят заголовки газет.
сам именно так и провожу интервью - даю кусок кода и в нем уже (неожиданно! ) находим и паттерны, и solid, и структуры данных, и прочие языковые моменты. кандидаты более расположены общаться, нежели спросить "билет 5. вопрос 1. паттерн синглтон")))
а у вас были кандидаты, которых ваш сеньор с ролью техлида одобрил? может сперва с ним обсудить подход к отбору?
аналитика аналитике рознь. поэтому с моей точки зрения было бы уместнее не пытаться объять необъятное, рассказывая о сферическом руководстве аналитикой в вакууме, а поведать свой конкретный опыт. конкретные истории конкретных людей читать любопытнее. к обобщённой информации, отношусь скептически, не обессудьте.
самое приятное впечатление у меня осталось от одной девушки-рекрутера, которая после нашей милой 15 минутной беседы сама сказала на какую цифру в оффере можно ориентироваться и торговаться по итогам предстоящего технического собеседования. она же без прикрас описала проект и стек: "увы, легаси". да и по остальным аспектам не лукавила.
со своей колокольни разработчика делю системных аналитиков на две категории: одна умеет формулировать свои шальные мысли в структурированную совокупность осмысленных предложений письменной речи, другая - не умеет. у некоторых аналитиков уже заголовки задач говорят о той боли, через которую придется пройти, читая описание задачи и уточняя, какие именно мысли вкладывались в этот поток сознания. такое вот бывает айти.
простите, но точнее я бы так сформулировал: насколько кандидат готов показывать на собеседовании готовность решать странные задачи.
поддерживаю.для статистики: я на свою первую оплачиваемую работу разработчиком попал на 4 курсе ВУЗа только потому, что препод меня посоветовал своему знакомому, который расширял команду и готов был брать без опыта. это потом все выяснилось за бокалом пенного - "мы тебя взяли, т.к. нам сказали, что ты шаришь".
аналогичная история. меня стали приглашать в качестве технического интервьюера, читаю резюме и думаю - как я могу проверить глубину знаний гениев (аналогичных описанным вами). начинаю немного беседовать об основах и пора выносить святых.
у меня был примерно похожий Девон, который не только не уменьшал техдолг, а своими задачами (строго по тз) плодил техдолг. при полном попустительстве свыше. я поговорил с ним, с тимлидом и при первой возможности ушел на другой проект, пусть там сами с ним разбираются.
согласен. просто те, кто пишут дефицит лукавят или подменяют понятия, недоговаривают ради громкого заголовка. вместо "дефицит кадров в отрасли X" следовало бы писать "дефицит кадров, удовлетворяющих моим (автора) требованиям". а полет фантазии в этих требованиях безграничен. более того, можно долго и упорно спорить о правильности этих требований, но дело это неблагодарное, т.к. лежит в плоскости субъективизма.
В российских компаниях встречал еще и такие наименования должностей: разработчик-стажер, младший разработчик, разработчик, старший разработчик, ведущий разработчик, главный разработчик, руководитель группы разработки.
Некоторые из них легко соотнести с классической схемой intern-junior-middle-senior, другие открывают простор для фантазии.
позволю сделать ремарку на основе своего опыта:
основная проблема при работе с людьми не умение наметить и выполнить план проведения встреч формата 1-1, а умение расположить к себе людей. последнее связано с ресурсом по удовлетворению желаний - а они у всех разные: есть субъективно адекватные, есть субъективно капризы маминого сладкого пирожка. примерный сценарий такой:
первая 1-1. человек рассказывает о проблемах, ведь его просят быть максимально открытым. проблемы обещают решить и не решают. по разным причинам, или забывают, или считают несущественными, или считают нерешаемыми, или нерешаемыми в ущерб другим людям и т.п.
вторая 1-1. человек напоминает о нерешенных проблемах. проблемы не решаются опять.
третья 1-1. человек говорит, что у него все отлично. проводящий 1-1 тешит себя, что он молодец и закрыл проблемы человека, человек счастлив. человек ищет работу и уходит рано или поздно в светлое (как ему кажется) будущее в другую компанию.
проводящий 1-1 думает: как же так? мы человека на помойке нашли, отмыли отчистили, а человек ушел. наверное, негодяй какой-то.