Тот случай, когда нельзя просто так взять и перевести с одного языка на другой. В стране автора, причём в конкретной категории компаний ситуация такая.
может неправ, но создалось впечатление что автор и в своей стране ситуацию плохо знает
собственный опыт это всегда одна точка, по которой экстраполировать нельзя
а может лучше своего опыта достаточно набраться, так сказать что бы без экстраполяций и пр, хотя бы лет 5 в крупной компании поработать, общениe в профильных группах не заменяет собственного мнения
Качество продукта и требуемые для него технические знания для синьор+ важны лишь в мелких продуктовых компаниях. Там, где без технической экспертизы не выжить, а на раздувание иерархии из удобных людей нет денег.
это на основе собственных наблюдений или как?
просто любопытно для каких таких крупных компаний качество продукта и техническая экспертиза не важны, и почему CEO еще не выгнали
Мне кажется, адекватно решать сложные задачи невозможно без «знать на память». Надо очень много знать об устройстве «под капотом» кучи различных систем, чтобы принимать осмысленные решения.
для senior не всегда, работа под стрессом, и частое переключение между проектами требует умения иногда быстро забывать детали предыдущего проекта, приведу пример, скажем делается интеграция системы имеющей порядка 300k lines of code (разумеется написанного не вами), вы потратили 3 месяца на изучение кода, чистку, отладку, нашли и сказали как исправить, вашей работой довольны (дали бонус), и переводят на новый проект в таком же состоянии, типа все правильно, но не работает, в этом случае если за несколько дней не переключиться, и забыть детали предыдущего работать дальше не сможете, сожгете мозги без всякого толку
Вы не поняли, какой смысл я вложил в аналогию с соревнованием… в случае собеседования, если вы прошли, это только начало, дальше нужно работать.
начинаются проблемы, серьезно?
вы лучше намекните сколько в своей жизни проводили интервью, сколько раз сами участвовали, и какой в последнем случае у вас был % успеха
(the offer in mail), типа x/y/z, если хотите сравним, возможно станет нам обоим легче понимать друг друга, консервативно для меня x>200
да бывает всяко, в том числе как вы описываете, но там где мне пришлось работать, все основано на соревновании (хорошо если честном), т. е. на конкуренции, между людьми, командами, компаниями, типа горе тому кто, понимает это слишком поздно, как говорится high stress environment
HR надо проводить собеседования, а не находить подходящего кандидата. Рекрутеры компании, которым действительно нужен новый сотрудник, довольно быстро находят нового коллегу.
такого не видел, стандартная схема — к примеру мне нужен сотрудник, HR связывается с headhunters, приносят кипу резюме, я решаю с кем разговаривать, HR организует интервью, после цикла интервью обсуждаем результаты и решаем, снова у HR чисто техническая роль,
если HR плохо ловят мышей их заменить не трудно, часто они по контракту работают и об этом помнят
Так что штампы бывают на столько странными, что меняют саму суть позиции (в видении нанимателя) до полной неузнаваемости.
на самом деле все даже проще — часто элементарно не умеют проводить интервью и не знают что спрашивать, кто умеет этим с успехом пользуются, например берут весь разговор в свои руки
Вы извините, но это ересь какаято. После статьи у меня прямо перед глазами встал образ очереди сеньоров которые не могут найти работу, но на самом деле в очереди стоят работодатели.
конечно ересь, типа фантазии на тему, чтобы быть в теме автор (некто PenMagnet) должен иметь собственный достаточный опыт проведения интервью, imho senior positions элементарно меньше в разы, поэтому более тщательный отбор, плюс networking имеет гораздо большое значение, часто все уже решено после телефонного разговора, и интервью есть формальность, чем выше senior position тем чаще
Рекомендуете ли вы глубже изучать паттерны архитектуры? Стремиться к «чистому коду»? Или же уйти на пару годиков в веб, поучиться у матерых сеньоров и вернуться с полученными знаниями во встройку?
многое зависит от поставленных личных целей — программирование embedded systems имеет невероятно большой диапазон, соответствующий диапазону систем реального времени, чтобы писать несложные программы для pi и arduino вероятно вполне хватит ресурсов сети, по крайней мере это займет вас на несколько месяцев, и это разумеется даст больше чем «уйти на пару годиков в веб», следующее что будет полезно — это изучение embedded linux и далее например все что связано с yocto, начиная с книг типа «Mastering Embedded Linux Programming» by Chris Simmonds, возможно не лучшая книга, но .pdf нетрудно найти в сети, это займет вас еще на несколько месяцев, если в результате например вы сможете активно участвовать в проекте yocto, это даст большое преимущество в поиске уже настоящей профессиональной работы, до сих пор было про подготовку, теперь о профессиональной карьере, самый короткий путь это для начала 3-5 лет работы в хорошей известной компании, что даст начало вашему резюме, позволит узнать людей, и вообще откалиброваться, при благоприятных результатах искать работу в жизни вам больше не придется, будут звонить сами, надо также заметить, что не смотря на обилие разработок embedded systems по всему миру, максимальная концентрация до сих пор находится в us, соответственно начинать профессиональную карьеру, и учиться программированию проще всего там, теперь про всякие программные технологии — их много, они зависят от размера разрабатываемых систем, назначения и пр, в хорошей компании всему этому вы сможете научиться так сказать на лету, и по мере необходимости совершентвоваться в дальнейшем
>Ключевой момент любой работы — целеполагание.
>Особенно важно это понимание для системного архитектора. Лучшая программа — та, которую не написали.
я бы сказал иначе, в большом числе случаев наиболее сложная часть проектирования — это грамотное переиспользование кода, не всегда было так, конечно, но сейчас пожалуй именно это самое трудное, мне тоже требовалось подолгу выдавать в день порядка 2k lines of code, особым достижением это не считаю, зависит от знания функциональной области, в конкретном случае это были протоколы, типа берешь соответствующую rfc, строишь state machine и поехали, пишется с нуля, и ни от чего кроме спецификации не зависит, но на порядок сложнее использование всевозможных asic specific sdk, их стыковка с другими пакетами функционального sw, это требует более высокой квалификации в том числе от архитектора, причем никакой абстрацией этого не заменишь, необходимо детальное знание продуктов, либо оно есть — тогда вы полезны, либо его нет, время на изучение это накладные расходы, и его как правило нет, примерно так работают программисты, по крайней мере то что приходились видеть там где работал на востоке us, что бы все сделать четко и быстро на работу и берут опытного архитектора
может неправ, но создалось впечатление что автор и в своей стране ситуацию плохо знает
а может лучше своего опыта достаточно набраться, так сказать что бы без экстраполяций и пр, хотя бы лет 5 в крупной компании поработать, общениe в профильных группах не заменяет собственного мнения
это на основе собственных наблюдений или как?
просто любопытно для каких таких крупных компаний качество продукта и техническая экспертиза не важны, и почему CEO еще не выгнали
вероятно еще мягко сказано, но две вещи помогают — networking, и привычка, ну и конечно о резюме надо заботиться
для senior не всегда, работа под стрессом, и частое переключение между проектами требует умения иногда быстро забывать детали предыдущего проекта, приведу пример, скажем делается интеграция системы имеющей порядка 300k lines of code (разумеется написанного не вами), вы потратили 3 месяца на изучение кода, чистку, отладку, нашли и сказали как исправить, вашей работой довольны (дали бонус), и переводят на новый проект в таком же состоянии, типа все правильно, но не работает, в этом случае если за несколько дней не переключиться, и забыть детали предыдущего работать дальше не сможете, сожгете мозги без всякого толку
начинаются проблемы, серьезно?
вы лучше намекните сколько в своей жизни проводили интервью, сколько раз сами участвовали, и какой в последнем случае у вас был % успеха
(the offer in mail), типа x/y/z, если хотите сравним, возможно станет нам обоим легче понимать друг друга, консервативно для меня x>200
да бывает всяко, в том числе как вы описываете, но там где мне пришлось работать, все основано на соревновании (хорошо если честном), т. е. на конкуренции, между людьми, командами, компаниями, типа горе тому кто, понимает это слишком поздно, как говорится high stress environment
такого не видел, стандартная схема — к примеру мне нужен сотрудник, HR связывается с headhunters, приносят кипу резюме, я решаю с кем разговаривать, HR организует интервью, после цикла интервью обсуждаем результаты и решаем, снова у HR чисто техническая роль,
если HR плохо ловят мышей их заменить не трудно, часто они по контракту работают и об этом помнят
на самом деле все даже проще — часто элементарно не умеют проводить интервью и не знают что спрашивать, кто умеет этим с успехом пользуются, например берут весь разговор в свои руки
конечно ересь, типа фантазии на тему, чтобы быть в теме автор (некто PenMagnet) должен иметь собственный достаточный опыт проведения интервью, imho senior positions элементарно меньше в разы, поэтому более тщательный отбор, плюс networking имеет гораздо большое значение, часто все уже решено после телефонного разговора, и интервью есть формальность, чем выше senior position тем чаще
многое зависит от поставленных личных целей — программирование embedded systems имеет невероятно большой диапазон, соответствующий диапазону систем реального времени, чтобы писать несложные программы для pi и arduino вероятно вполне хватит ресурсов сети, по крайней мере это займет вас на несколько месяцев, и это разумеется даст больше чем «уйти на пару годиков в веб», следующее что будет полезно — это изучение embedded linux и далее например все что связано с yocto, начиная с книг типа «Mastering Embedded Linux Programming» by Chris Simmonds, возможно не лучшая книга, но .pdf нетрудно найти в сети, это займет вас еще на несколько месяцев, если в результате например вы сможете активно участвовать в проекте yocto, это даст большое преимущество в поиске уже настоящей профессиональной работы, до сих пор было про подготовку, теперь о профессиональной карьере, самый короткий путь это для начала 3-5 лет работы в хорошей известной компании, что даст начало вашему резюме, позволит узнать людей, и вообще откалиброваться, при благоприятных результатах искать работу в жизни вам больше не придется, будут звонить сами, надо также заметить, что не смотря на обилие разработок embedded systems по всему миру, максимальная концентрация до сих пор находится в us, соответственно начинать профессиональную карьеру, и учиться программированию проще всего там, теперь про всякие программные технологии — их много, они зависят от размера разрабатываемых систем, назначения и пр, в хорошей компании всему этому вы сможете научиться так сказать на лету, и по мере необходимости совершентвоваться в дальнейшем
>Особенно важно это понимание для системного архитектора. Лучшая программа — та, которую не написали.
я бы сказал иначе, в большом числе случаев наиболее сложная часть проектирования — это грамотное переиспользование кода, не всегда было так, конечно, но сейчас пожалуй именно это самое трудное, мне тоже требовалось подолгу выдавать в день порядка 2k lines of code, особым достижением это не считаю, зависит от знания функциональной области, в конкретном случае это были протоколы, типа берешь соответствующую rfc, строишь state machine и поехали, пишется с нуля, и ни от чего кроме спецификации не зависит, но на порядок сложнее использование всевозможных asic specific sdk, их стыковка с другими пакетами функционального sw, это требует более высокой квалификации в том числе от архитектора, причем никакой абстрацией этого не заменишь, необходимо детальное знание продуктов, либо оно есть — тогда вы полезны, либо его нет, время на изучение это накладные расходы, и его как правило нет, примерно так работают программисты, по крайней мере то что приходились видеть там где работал на востоке us, что бы все сделать четко и быстро на работу и берут опытного архитектора