Как из 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]

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