К сожалению, бывают и такие, но в основном в агенствах.
У меня другой забавный момент есть — типовой технологический тест. Он настолько типовой и дебильный, что сениорам его даже давать стыдно. Тем не менее, этот «типовой дебильный тест» очень полезен и решает сразу несколько задач. Во-первых он сразу отсеивает тех джуниоров, которые только отучились в университете и ни разу не интересуются платформой. Во-вторых позволяет бегло оценить навыки кандидата по основному технологическому профилю вакансии. В-третьих является поводом и зацепками для дискуссии.
100% верно давать ответы не считаю обязательным, намного важнее и интереснее комментарии. Скажем, банальное «i++ + ++i». Джуниор его будет пытаться решить в лоб (как и все практические задачи, не задумываясь об их реальном смысле), а миддл и сениор должны честно сказать, что такую ахинею писать нельзя в реальном проекте, а следовательно, какова там будет цифра на выходе — не столь уж важно. И мне эта цифра не столь важна, мне важнее понимание кандидата, что так писать нельзя.
В любом случае, техническое собеседование — это не столь желание найти «максимального» кандидата за минимальные деньги (а такой через полгода просто найдёт место поинтереснее), сколько оценка — могу ли я с кандидатом общаться «на одном языке» (понимая друг друга без тщательного расписывания задачи до мелочей), ну и попытка понять — на какой участок работ данного кандидата имеет смысл ставить. Поверьте, есть огромное желание взять примерно половину приходящих кандидатов, но либо совсем замкнутые-необщительные, либо задачу надо расписывать так, что проще самому взять и сделать, либо задачи+технический навык+амбиции вызовут конкуренцию с существующими членами команды.
Текучка есть, но я бы не сказал, что большая. Основная проблема — взрывной рост бюджета проектов, соответственно, и требований с трудозатратами. За этот год ушло 3 человека (один правда постоянно на удалёнке), взято человек 10…
Почему нет? Последние лет 5 нахожу работу за неделю — понедельник-среда активные поездки по собеседованиям (3-4 в день), четверг — разве что особо интересные запаздавшие предложения, пятница — выбор оффера, понедельник — выход на работу :) Чего тянуть? :)
Не соглашусь. Мне кандидатов ищет замечательная HR, которая на выходе (до технического собеседования) даёт мне два ключевых параметра — сколько в резюме вранья по технологиям и каков психотип у собеседуемого. Исходя из первого техническая часть зачастую сокращается с ~40 минут до ~5 минут, кроме того, во втором случае я не отнимаю времени у своих недешёвых спецов. Ошибки редки — один-два случая на 15-20 кандидатов. При этом помимо моего направления, она ищет ещё java/scala-спецов, sql, ну и по мелочи.
Второй параметр (психотип) — намного важнее, чем первый. Технические скиллы можно (и нужно) развивать, а коммуникативные навыки в реальной работе куда важнее. Взять необщительного гика (сколь бы прекрасный код он не писал) — означает приставить к нему ещё одного специалиста, который будет контролировать процесс, следить, чтобы гик не растекался мыслями по подоконнику и выполнять функции переводчика между ним, аналитиками и менеджерами. В моих реалиях проще взять двух не столь прекрасно пищущих код «говнокодеров», но способных быстро и точно понять цели и задачи заказчика. А то, что в коде местами костыли, а местами и карточные домики — так через полгода-год-два этот код всё равно выкинут на свалку и перепишут в связи с изменениями законодательства. Это всё утрированно, конечно, но основная мысль думаю ясна.
У нас есть scm-manager, юзаем для хостинга git, но пока только неприятные впечатления.
Во-первых при назначении роли пользователю чтобы роль подействовала — нужно обязательно переназначить эту роль хотя бы одному репозиторию (sic!).
Во-вторых про не-AD пользователей почему-то периодически забывает, приходится пересоздавать (в принципе у нас там всего две интеграционные учётки не-AD'шные заведены).
В-третьих примерно раз в месяц начинает при push'е ругаться разными непонятными ошибками — помогает рестарт scm-manager.
При этом не умеет банальной вещи — выдать разные права пользователям на запись в разные ветки.
Если вы активно взаимодействуете с заказчиком на этапе сбора и формализации требований — есть масса трюков, как усложнить жизнь конкурентам по конкурсу. Но нужно чтобы заказчик вам доверял, ибо срыв исполнения бюджета ему ни к чему.
Во, адекватная статья про госсектор. А то все заладили — откаты, откаты… Где они, эти откаты, если на конкурс толком никто не выходит?
Работаю с госсектором в качестве сотрудника компании-исполнителя. Всё так, описано — сотрудничаем много лет подряд, ТЗ пишем сами (точнее ищем баланс между требованиями с четырёх заинтересованных министерств с зачастую противоречивыми требованиями), на конкурс кроме нас особо никто не выходит — бывают прецеденты, но участники рынка весьма ленивы, и воюют в основном торгаши — за тендеры по закупке оборудования.
В плане же разработки — получается вполне себе нормальное многолетнее сотрудничество. Аналитики у заинтересованных лиц со стороны выгодоприобретателя «практически живут», но это необходимые издержки — заказчики из госсектора плохо понимают, что именно им надо, но весьма любят внимание.
В плане реализации — халявы не бывает, сроки жёсткие и как правило очень сжатые. На промежуточных этапах иногда можно оттянуть сроки — в основном путём «а давайте мы это сделаем попозже, зато вот это — пораньше». Т.е. можно договориться обменять приоритеты между задачами. Если заказчик вам доверяет — он весьма лоялен, т.к. ему нужен результат, а не доказательство вашей некомпетентности. Халявы по технической реализации тоже не бывает — всё, что написано в ТЗ придётся отстаивать, показывать и доказывать. Иногда в ТЗ в результате компиляции кучи противоречивых требований попадает откровенная ахинея (в основном благодаря несогласованности терминологии у разных заинтересованных лиц) — приходится прикручивать откровенные костыли и никому не нужный нерабочий функционал только ради демонстрации реализованности пунктов ТЗ — даже если заказчик убеждён в неадекватности ТЗ — ему всё равно нужно основание для приёмки.
А так в основном заказчик адекватный, хочет рабочую систему с конкретными требованиями (если вы, конечно, смогли правильно его понять) и вполне готов за всё это платить. Только вот на рынке мало кто готов тратить силы на общение с заказчиком до тендера, все хотят простых денег и без рисков.
Может я чего-то не понимаю, но по-моему используемые в телефонах MEMS-чипы не сильно больше по размерам (а там те же стандартные ныне 3 акселерометра, 3 гироскопа, магнетометр). Да и если посмотреть аналогичные DIY-компоненты, то там тоже примерно тех же размеров MEMS-чипы, просто напаянные на плату для удобного монтажа.
В общем, так и не понял, в чём именно революционное достижение.
У меня в ниссане (навигационка 08IT) тоже дублирующая инерциальная система. Помимо бесперебойной навигации в тоннелях, паркинагах и т.д. — в момент включения зажигания показывает действительный курс, а не ждёт, пока авто тронется и курс рассчитается по перемещению.
Думал давно уже везде такое. Гироскоп+акселерометр+магнетометр, как и во всех телефонах.
В телефонах видимо просто не используют инерциальный режим всего этого, наверное в связи с энергопотреблением. В авто-то лишние даже 10 ватт потребления погоды не сделают.
Одно плохо — карты, как обычно, шлак. В москве, питере и крупных городах всё отлично, а вот стоит уехать подальше — всё, едем в молоке :) Даже начал формат ковырять, но там полноценная встраиваемая RDBMS (Hitachi Entier), не думаю, что в одиночку смогу когда-нибудь закончить…
Насколько я понимаю, бешеный расход энергии при использовании Я.Карт и Я.Навигатора связан в первую очередь с функционалом определения камер по WiFi. Ибо даже на предыдущих версиях, стоило отключить WiFi — и расход энергии становился мизерным.
Вот выгрузил я целую историю смс с телефона, отфильтровал, оставил только бесполезные.
А как бы автоматизированно их скопом на этот сервис загрузить?
Ну или хотя бы подтверждать один номер телефона один раз кодом из SMS'ки, ибо сейчас на каждую заявку приходится код ждать и вводить, не смотря на то, что номер телефона один и тот же :)
А почему sql должны обязательно учить? Захотел производственник заняться автоматизацией, сходил на курсы по какой-то конкретной линейке железяк, работает себе спокойно, программит производственные процессы.
Я не спорю о том, как кому проще. Просто в топике походу вообще не понимают, сколь разными бывают программисты, воспринимая лишь типовые C/C++/C#/php/js и т.д.
Взять например абапера (ABAP/4). Нафига ему консоль? Нафига ему что-то конфигурить, если BC-спецы ему даже прав таких не выдадут?
У меня другой забавный момент есть — типовой технологический тест. Он настолько типовой и дебильный, что сениорам его даже давать стыдно. Тем не менее, этот «типовой дебильный тест» очень полезен и решает сразу несколько задач. Во-первых он сразу отсеивает тех джуниоров, которые только отучились в университете и ни разу не интересуются платформой. Во-вторых позволяет бегло оценить навыки кандидата по основному технологическому профилю вакансии. В-третьих является поводом и зацепками для дискуссии.
100% верно давать ответы не считаю обязательным, намного важнее и интереснее комментарии. Скажем, банальное «i++ + ++i». Джуниор его будет пытаться решить в лоб (как и все практические задачи, не задумываясь об их реальном смысле), а миддл и сениор должны честно сказать, что такую ахинею писать нельзя в реальном проекте, а следовательно, какова там будет цифра на выходе — не столь уж важно. И мне эта цифра не столь важна, мне важнее понимание кандидата, что так писать нельзя.
В любом случае, техническое собеседование — это не столь желание найти «максимального» кандидата за минимальные деньги (а такой через полгода просто найдёт место поинтереснее), сколько оценка — могу ли я с кандидатом общаться «на одном языке» (понимая друг друга без тщательного расписывания задачи до мелочей), ну и попытка понять — на какой участок работ данного кандидата имеет смысл ставить. Поверьте, есть огромное желание взять примерно половину приходящих кандидатов, но либо совсем замкнутые-необщительные, либо задачу надо расписывать так, что проще самому взять и сделать, либо задачи+технический навык+амбиции вызовут конкуренцию с существующими членами команды.
Второй параметр (психотип) — намного важнее, чем первый. Технические скиллы можно (и нужно) развивать, а коммуникативные навыки в реальной работе куда важнее. Взять необщительного гика (сколь бы прекрасный код он не писал) — означает приставить к нему ещё одного специалиста, который будет контролировать процесс, следить, чтобы гик не растекался мыслями по подоконнику и выполнять функции переводчика между ним, аналитиками и менеджерами. В моих реалиях проще взять двух не столь прекрасно пищущих код «говнокодеров», но способных быстро и точно понять цели и задачи заказчика. А то, что в коде местами костыли, а местами и карточные домики — так через полгода-год-два этот код всё равно выкинут на свалку и перепишут в связи с изменениями законодательства. Это всё утрированно, конечно, но основная мысль думаю ясна.
Во-первых при назначении роли пользователю чтобы роль подействовала — нужно обязательно переназначить эту роль хотя бы одному репозиторию (sic!).
Во-вторых про не-AD пользователей почему-то периодически забывает, приходится пересоздавать (в принципе у нас там всего две интеграционные учётки не-AD'шные заведены).
В-третьих примерно раз в месяц начинает при push'е ругаться разными непонятными ошибками — помогает рестарт scm-manager.
При этом не умеет банальной вещи — выдать разные права пользователям на запись в разные ветки.
Жму кнопку «попробовать облако» — никакой реакции. Никакого всплывающего окна. Думал, в хроме глючит — попробовал в IE10 — то же самое.
В итоге, пользую на батарейках.
Работаю с госсектором в качестве сотрудника компании-исполнителя. Всё так, описано — сотрудничаем много лет подряд, ТЗ пишем сами (точнее ищем баланс между требованиями с четырёх заинтересованных министерств с зачастую противоречивыми требованиями), на конкурс кроме нас особо никто не выходит — бывают прецеденты, но участники рынка весьма ленивы, и воюют в основном торгаши — за тендеры по закупке оборудования.
В плане же разработки — получается вполне себе нормальное многолетнее сотрудничество. Аналитики у заинтересованных лиц со стороны выгодоприобретателя «практически живут», но это необходимые издержки — заказчики из госсектора плохо понимают, что именно им надо, но весьма любят внимание.
В плане реализации — халявы не бывает, сроки жёсткие и как правило очень сжатые. На промежуточных этапах иногда можно оттянуть сроки — в основном путём «а давайте мы это сделаем попозже, зато вот это — пораньше». Т.е. можно договориться обменять приоритеты между задачами. Если заказчик вам доверяет — он весьма лоялен, т.к. ему нужен результат, а не доказательство вашей некомпетентности. Халявы по технической реализации тоже не бывает — всё, что написано в ТЗ придётся отстаивать, показывать и доказывать. Иногда в ТЗ в результате компиляции кучи противоречивых требований попадает откровенная ахинея (в основном благодаря несогласованности терминологии у разных заинтересованных лиц) — приходится прикручивать откровенные костыли и никому не нужный нерабочий функционал только ради демонстрации реализованности пунктов ТЗ — даже если заказчик убеждён в неадекватности ТЗ — ему всё равно нужно основание для приёмки.
А так в основном заказчик адекватный, хочет рабочую систему с конкретными требованиями (если вы, конечно, смогли правильно его понять) и вполне готов за всё это платить. Только вот на рынке мало кто готов тратить силы на общение с заказчиком до тендера, все хотят простых денег и без рисков.
А магнетометр — слишком «шумный» датчик.
В общем, так и не понял, в чём именно революционное достижение.
Думал давно уже везде такое. Гироскоп+акселерометр+магнетометр, как и во всех телефонах.
В телефонах видимо просто не используют инерциальный режим всего этого, наверное в связи с энергопотреблением. В авто-то лишние даже 10 ватт потребления погоды не сделают.
Одно плохо — карты, как обычно, шлак. В москве, питере и крупных городах всё отлично, а вот стоит уехать подальше — всё, едем в молоке :) Даже начал формат ковырять, но там полноценная встраиваемая RDBMS (Hitachi Entier), не думаю, что в одиночку смогу когда-нибудь закончить…
А как бы автоматизированно их скопом на этот сервис загрузить?
Ну или хотя бы подтверждать один номер телефона один раз кодом из SMS'ки, ибо сейчас на каждую заявку приходится код ждать и вводить, не смотря на то, что номер телефона один и тот же :)
Взять например абапера (ABAP/4). Нафига ему консоль? Нафига ему что-то конфигурить, если BC-спецы ему даже прав таких не выдадут?