Как из qa в разработку свичнуться ?

[+KPOT+]

Во франт энде надо постоянно учить что то новое, а не просто забирать пэйчек пару раз в месяц. Имхо, это лучше подходит для голодной молодёжи.

[nyekimov]

Во франт энде надо постоянно учить что то новое, а не просто забирать пэйчек пару раз в месяц. Имхо, это лучше подходит для голодной молодёжи.

Постоянно учить что то новое не всегда плохо, тут именно засада в том, что знания не обязательно нужны в накопительном порядке. Если быть ещё более точней, то дешевле взять чувака, который работает только на нужной тебе технологии последний год, чем того, кто работал на ней последний год а до этого ещё на пару, то те знания старых фреймворков скорей всего уже никому не нужны и переплачивать не за что особо.
Когда если у тебя бэкенд на Жаве и спринг, которому много лет, то лучше взять того, кто на нем уже много лет.
Хотя это все так, засрать могут и то и то. Бывают хорошие работы и на бэкенд и на фронтенд. Как бывают и бэкенд команды из сплошных индусов и на таких доисторических технологиях, что лучше я подучу новшества на фронтенд каждый год, чем ковыряться в их говне за вполне может быть и меньшие деньги.
Но пока все ещё многопоточные финансовые транзакции обрабатываются на бэкенд и если вы пишите такой код, то вы явно будете цениться и хорошо оплачиваться и ваши знания будут ценны в накопительной прогрессии.

[valchkou]

А вот ещё такой вопрос к уважаемым участникам форума:

Правильно ли я понимаю что путь во фронт енд легче чем в бэк? Как мне кажется в бэк енд больше конкуренции поскольку придется конкурировать со свежими выпускниками с CS degree а фронт энду вроде там не учат и поэтому мне кажется что путь JS react redux проще чем Java и т.д

путь будет быстрее но не легче.
фронтенд в наши дни стал таким замороченным что не каждый в нем готов ковыряться.
К тому же из-за долгого отсутствия каких либо стандартов там такой зоопарк что иной бакенд покажется детским лепетом.
Сейчас фронтенд это не просто жаваскрипт, действительно нужно очень много и очень быстро изучат.
С другой стороны с 4 годами опыта на модном фронтенд вы практически лид/принципал.
А на бэкенде с тем же сроком вы будете просто мид.

[IvanGrozniy]

Я думаю, что всё-таки на интервью важнее правильно отвечать на вопросы, типа, "Сможешь ли сделать такой-то проект за месяц?". А знание технологий хоть и важны, но не так чтобы очень. Особенно на начальные позиции.

[Lisa]

Я думаю, что всё-таки на интервью важнее правильно отвечать на вопросы, типа, "Сможешь ли сделать такой-то проект за месяц?". А знание технологий хоть и важны, но не так чтобы очень. Особенно на начальные позиции.

На такие вопросы надо отвечать как в анекдоте - «-что 9? -а что приборы?»

[rtogan]

Я думаю, что всё-таки на интервью важнее правильно отвечать на вопросы, типа, "Сможешь ли сделать такой-то проект за месяц?". А знание технологий хоть и важны, но не так чтобы очень. Особенно на начальные позиции.

Это - оригинальная точка зрения Soft skills учитывают лишь при наличии минимума hard skills, тем более на начальные позиции

[tessob]

Я думаю, что всё-таки на интервью важнее правильно отвечать на вопросы, типа, "Сможешь ли сделать такой-то проект за месяц?". А знание технологий хоть и важны, но не так чтобы очень. Особенно на начальные позиции.

Что-то я сомневаюсь, что джун окажется способен дать адекватную оценку трудоемкости проекта. Я постоянно сталкиваюсь с тимлидами, которые имеют с этим проблемы. На мой взгляд, более рациональными выглядят вопросы типа: "Какие подходы, библиотеки, фреймворки, сервера ты планируешь использовать для задачи [имярек] и почему?". Мне гораздо интереснее проследить ход мысли и понять стратегию решения проблемы. Просто многие зависают на этом вопросе, хотя понятно, что на такой вводной ошибиться в выборе технологий практически не возможно. С другой стороны, если человек начинает отвечать, то уровень его технической эрудиции сразу становится понятен.

[alex_127]

Если на форму контролы набросать - то кто угодно даст оценку правильную, если надо сложную и быструю логику - то никто.

[tessob]

Если на форму контролы набросать - то кто угодно даст оценку правильную...

Вы не находите, что это как-то очень мелко для целого проекта? С другой стороны, что вам даст ответ: "нууу... э... думаю, шмогу"? Вы ему сразу же дадите весло и логин от джиры?

...если надо сложную и быструю логику - то никто.

А деньги как зарабатывать планируется? Или новый раунд не за горами? Мы же сейчас про коммерческую разработку. Ресурсный план -- это основа любого проекта, которая помогает определить бюджет. Гребцы в его разработке не участвуют и их мнение с оценками там не учитываются, т.к. не реально понять, что в эти их оценки заложено. Смысл спрашивать у джуна какие-либо оценки, если он будет просто размахивать веслом?

[alex_127]

Если на форму контролы набросать - то кто угодно даст оценку правильную...

Вы не находите, что это как-то очень мелко для целого проекта? С другой стороны, что вам даст ответ: "нууу... э... думаю, шмогу"? Вы ему сразу же дадите весло и логин от джиры?

...если надо сложную и быструю логику - то никто.

А деньги как зарабатывать планируется? Или новый раунд не за горами? Мы же сейчас про коммерческую разработку. Ресурсный план -- это основа любого проекта, которая помогает определить бюджет. Гребцы в его разработке не участвуют и их мнение с оценками там не учитываются, т.к. не реально понять, что в эти их оценки заложено. Смысл спрашивать у джуна какие-либо оценки, если он будет просто размахивать веслом?

я не видел ни разу чтобы в сложном случае оценка сошлась с результатом. это за 25 лет индустрии. когда нужна оценка по деньгам - все нужно упрощать сразу, чтобы было просто и понятно. без науки, без изысков - но зато можно сказать сумму сразу.

[tessob]

Всегда есть какая-то часть, которую можно оценить и та, где оценку дать сложно. В этом месте можно пойти и договариваться о разделении этих рисков с клиентом. Если усе не понятно, то нужно менять техлида/архитектора. Порой проще вообще отказаться и не брать заказ, т.к. есть масса других, более приятных, способов пролюбить бюджет.

Хотя в моей практике бюджеты начинают гореть тогда, когда проблемы начинают заливаться человеками. Многим "эффективным" менеджерам сложно понять, что если ты последние 10 раз добавлял в команду нового гребца и не получал пропорционального прироста фич, то 11-й тоже ничего не даст. Количество не трансформируется в качество. Просто, команда как нейтронная звезда достигает критической массы и становится черной дырой, которая готова утилизировать любое количество ресурсов. В этом месте нужно увеличивать средний скилл, но тут обычно встает другая проблема -- нормальные кандидаты часто заваливают интервью, т.к. вместо того, чтоб говорить про добавление volatile & synchronized, начинают объяснять интервьюеру, что разделяемая память не бесплатная и создание потоков тоже не бесплатное и оверхед будет cn^2, а интервьюера к такому мама не готовила. Короче все скатывается в балаган, оутсорс и лейофф.

[nyekimov]

Всегда есть какая-то часть, которую можно оценить и та, где оценку дать сложно. В этом месте можно пойти и договариваться о разделении этих рисков с клиентом. Если усе не понятно, то нужно менять техлида/архитектора. Порой проще вообще отказаться и не брать заказ, т.к. есть масса других, более приятных, способов пролюбить бюджет.

Хотя в моей практике бюджеты начинают гореть тогда, когда проблемы начинают заливаться человеками. Многим "эффективным" менеджерам сложно понять, что если ты последние 10 раз добавлял в команду нового гребца и не получал пропорционального прироста фич, то 11-й тоже ничего не даст. Количество не трансформируется в качество. Просто, команда как нейтронная звезда достигает критической массы и становится черной дырой, которая готова утилизировать любое количество ресурсов. В этом месте нужно увеличивать средний скилл, но тут обычно встает другая проблема -- нормальные кандидаты часто заваливают интервью, т.к. вместо того, чтоб говорить про добавление volatile & synchronized, начинают объяснять интервьюеру, что разделяемая память не бесплатная и создание потоков тоже не бесплатное и оверхед будет cn^2, а интервьюера к такому мама не готовила. Короче все скатывается в балаган, оутсорс и лейофф.

К сожалению встречаю больше менеджеров, которые думают, что если одна женщина рожает ребёнка за 9 мес, то 9 родят соответсвенно за 1.
Вот на мелких Фирмах обычно легко могут определиться со сроком и людей имеют мало. Но проекты на самом то деле простые, и например когда я работал на таком вдвоём, мне было тесно, так как работы не хватало на одного. Но денег там тоже платить нормально не могли, если проект просчитывается по технологиям и прочему на срок легко, то денег там много нет .

[IvanGrozniy]

Я думаю, что всё-таки на интервью важнее правильно отвечать на вопросы, типа, "Сможешь ли сделать такой-то проект за месяц?". А знание технологий хоть и важны, но не так чтобы очень. Особенно на начальные позиции.

Что-то я сомневаюсь, что джун окажется способен дать адекватную оценку трудоемкости проекта. Я постоянно сталкиваюсь с тимлидами, которые имеют с этим проблемы. На мой взгляд, более рациональными выглядят вопросы типа: "Какие подходы, библиотеки, фреймворки, сервера ты планируешь использовать для задачи [имярек] и почему?". Мне гораздо интереснее проследить ход мысли и понять стратегию решения проблемы. Просто многие зависают на этом вопросе, хотя понятно, что на такой вводной ошибиться в выборе технологий практически не возможно. С другой стороны, если человек начинает отвечать, то уровень его технической эрудиции сразу становится понятен.

Тест не прошли с таким ответом
Етсь такие люди (наверное большинство среди начальников), спрашивающие такой вопрос, который ждут ответ "волоса на попе рвать буду, кровь из носу, но в сроки уложусь". Адекватно ответить можно, но тогда скорее всего не возьмут. А потом, когда наняли, поработаешь месяц, то одно из двух обязательно случится:
1. Накидают дополнительных требований к проекту, которые на интервью не обсуждались. Поэтому можно запросто отмазаться, мол, слишком много дополнительных переменных появилось, нужно еще 3 месяца работы... 100% моих контректов так проходило. Идешь на один проект, потом начальство добавляет все больше и больше и проект затягивается на дольший срок.
2. Есть такое наблюдение. Спроси айтишщника сколько времени займет задача и потом смело умножь на 3. Так же и здесь, под конец срока просто скажи начальнику, что не понимал всех деталей и нужно больше ресурсов (время и/или больше программистов) на этот проект. Обычно входят в положение. Были у меня примеры наема моих коллег под определенную задачу. Они обещали все сделать. На деле сами так и не смоглу в тему въехать и приходилось им помогать. Коллеги продолжали работать дальше без всяких увольнений.

[tessob]

"волоса на попе рвать буду, кровь из носу, но в сроки уложусь".

Зачем так жить?

[alex_127]

а зачем вам волоса на попе? а тут депилляцию предлагают, да еще и денег платят...

[tessob]

К сожалению встречаю больше менеджеров, которые думают, что если одна женщина рожает ребёнка за 9 мес, то 9 родят соответсвенно за 1.

Это одна из форм закидывания проблем человеками. Наверное, вторая по популярности после службы в армии. Я наблюдал недавно как 20 человек пилили одну шину данных с разных концов. Они наверное процентов 60 времени убили только на то, чтобы договориться как это делать. Причем и я, и каждый из них понимали, что 2-3 человека сделали бы это месяца за 4, а не за полтора года.

Вот на мелких Фирмах обычно легко могут определиться со сроком и людей имеют мало. Но проекты на самом то деле простые, и например когда я работал на таком вдвоём, мне было тесно, так как работы не хватало на одного. Но денег там тоже платить нормально не могли, если проект просчитывается по технологиям и прочему на срок легко, то денег там много нет.

Если мелкая фирма работает в своей нише, а не пытается конкурировать с галерами вроде EPAM, то там все ОК с доходом. У нас доход на инженера позволяет платить хорошо выше рынка. Работа маленькими командами, человек по 10, которые абсолютно автономны на время проекта и даже имеют свой небольшой бюджет, который сами решают как потратить. Хотят в пабы идут, хотят на конференции едут. Задачи -- всякая прикладная оптимизация в корпоративных финансах, производстве, логистике. Никакого говнокода 20-летней давности, так как сервисы дизайнятся чтобы прожить примерно 3-4 года после старта. Например, производство какой-нибудь картонной упаковки -- это очень низкомаржинальный бизнес и производитель хочет закупать сырье по фьючерсам выгодным для себя образом. Так что у нас полно всякой математики и порно-сайнса. Есть маленькие фирмы, где может быть не тесно. ))

[IvanGrozniy]

"волоса на попе рвать буду, кровь из носу, но в сроки уложусь".

Зачем так жить?

Правильно. Так жить не нужно. Основная задача, чтобы на работу взяли. Потом приходишь и делаешь дела по умному.

[tessob]

Основная задача, чтобы на работу взяли.

Мне всегда почему-то на интервью подрывает выяснять где находятся "границы дозволенности" у такого кандидата. Очень интересные ответы бывают.

[IvanGrozniy]

Основная задача, чтобы на работу взяли.

Мне всегда почему-то на интервью подрывает выяснять где находятся "границы дозволенности" у такого кандидата. Очень интересные ответы бывают.

Ну это интревью-стиль из темы "готча", так понимаю. Где нужно поймать интервьюируемого на лжи...
А я вот совесткий мультфильм "Жадный богач" вспоминаю. Если заказчик хочет 12 шапок из одной звериной шкуры, то я их ему сделаю

[tessob]

Ну это интревью-стиль из темы "готча", так понимаю. Где нужно поймать интервьюируемого на лжи...

Нет. У нас всего один вопрос для интервьюеров, на который они должны ответить -- "В чем кандидат лучше чем я?". Вопросы кандидату не имеют значения. Для нас это гарантия, что мы не становимся очередной черной дырой из моего предыдущего поста. Если команда знает, что у нас в данный конкретный момент пробел в оптимизации виртуальной машины, то мы будем очень точечно искать именно этот скилл, т.к. HR департамента у нас нет и публичных вакансий тоже нет. Бывали случаи, когда кандидата вообще ни один из интервьюеров не попросил написать код. Мы маленькая компания, мы можем страдать любой херней... и никаких разочарований.

[IvanGrozniy]

Ну это интревью-стиль из темы "готча", так понимаю. Где нужно поймать интервьюируемого на лжи...

Нет. У нас всего один вопрос для интервьюеров, на который они должны ответить -- "В чем кандидат лучше чем я?". Вопросы кандидату не имеют значения. Для нас это гарантия, что мы не становимся очередной черной дырой из моего предыдущего поста. Если команда знает, что у нас в данный конкретный момент пробел в оптимизации виртуальной машины, то мы будем очень точечно искать именно этот скилл, т.к. HR департамента у нас нет и публичных вакансий тоже нет. Бывали случаи, когда кандидата вообще ни один из интервьюеров не попросил написать код. Мы маленькая компания, мы можем страдать любой херней... и никаких разочарований.

Ну тогда ответ очень прост - "ни чем", так как автор идет на начальную позицию.

[alex_127]

Ну это интревью-стиль из темы "готча", так понимаю. Где нужно поймать интервьюируемого на лжи...

Нет. У нас всего один вопрос для интервьюеров, на который они должны ответить -- "В чем кандидат лучше чем я?". Вопросы кандидату не имеют значения. Для нас это гарантия, что мы не становимся очередной черной дырой из моего предыдущего поста. Если команда знает, что у нас в данный конкретный момент пробел в оптимизации виртуальной машины, то мы будем очень точечно искать именно этот скилл, т.к. HR департамента у нас нет и публичных вакансий тоже нет. Бывали случаи, когда кандидата вообще ни один из интервьюеров не попросил написать код. Мы маленькая компания, мы можем страдать любой херней... и никаких разочарований.

на меня один кандидат в hr оставил feedback что после phone screen он не хочет идти в такую агрессивную компанию что спрашивает "where you are better than the rest?"

[tessob]

Автору нужно понять в чем он силен. Туда и идти. Я знаю автомехаников, которые зарабатывают больше обычного программиста. Идти чисто из-за денег в ИТ -- это просто недальновидно. Деньги там где твое настоящее место. Просто большинство программистов, на которых все равняются, реально прет от программирования. Можно сделать достойную карьеру и в QA, если смотреть на это не как на рутину, а как на минимизацию рисков всего проекта. Идти нужно туда, где ты хочешь быть профессионалом.

[tessob]

на меня один кандидат в hr оставил feedback что после phone screen он не хочет идти в такую агрессивную компанию что спрашивает "where you are better than the rest?"

Мы интервьюера спрашиваем, а не кандидата.

UPD: Я еще после любого негативного фидбека, предлагаю кандидату пройти дополнительные интервью. Бывает, когда человек нормальный, с нормальными скиллами, но готовился рвать на жопе волосы, а тут такие вопросы. )))

[IvanGrozniy]

на меня один кандидат в hr оставил feedback что после phone screen он не хочет идти в такую агрессивную компанию что спрашивает "where you are better than the rest?"

Мы интервьюера спрашиваем, а не кандидата.

Ну тогда старожили-работники будут про "агрессивность" думать и в конце-концов свалят из-за потери уверенности в своих способностях!