Продолжается опрос по языкам программирования. Уже собрано почти 7000 ответов. Заполняйте анкету!
×Закрыть

Middle разработчики по цене Junior-а или «хочу практики»

Всем привет. Я очень хочу в IT, мне ’оно’ нравится, да и способности присутствуют. Я считаю что уже готов для работы, но есть проблема. Побывав на испытательном сроке в одной компании я понял, что они не особо хотят обучать начинающих. Хотят уже обученных, с опытом.

Остается 2 выхода, либо идти на курсы (академии) (Luxoft, SoftServe) или получать практику другим спсобом. Певый вариант не очень интрисует, так как это долгий и не очень продуктивный путь.

Поэтому ищу ментора / единомышленника / компанию(в которой готов работать бесплатно). В день могу тратить от 4 до 8 часов. Готов работать над проектами, связанными с web приложениями.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

что-то заголовок никак к сути топика не клеется

Рад, что автор нашел работу/проект быстро, но хочу таки поделиться своим опытом, может кому-то поможет.

Начнут с того, что согласен с большинством комментаторов и несогласен с автором. Кто хочет научиться, тому надо идти туда, где берут и делать то, что есть. Даже с минимально й ЗП. Альтернатива — придумать себе какую-то среднею сложности задачку и реализовать её в коде. Постепенно усложняя свой pet-project, рано или поздно придется читать книги по архитектуре ... и вырастешь до толкового мидла. Например, у меня есть свой игровой сайт. Денег приносит копейки, но с его помощью я научился программировать (vfm-elita.com). А в процессе работы над ним, приходилось решать МНОЖЕСТВО проблем (из разряда пол-дня гуглишь, пол дня кодишь.. потом опять гуглишь). Вот пример тому мой вопрос (один и большого множества) на форуме программистов: forum.sources.ru/...howtopic=223139

Надеюсь кому-то поможет.

Проект нашел, всем спасибо.

либо идти на курсы
Курсы в вашем случае помогут только «войти в тему» (да и то не всегда). Как первый шаг — возможно, хорошо. Но для получения реального опыта не годится.
или получать практику другим способом
Наиболее продуктивный способ получения практических навыков — это их использование на практике. Тут, конечно, очень многое зависит от обучающего, но необходимо понять основное: особо обучать Вас никто не будет и не заинтересован. Программисты — существа ленивые... Помочь в какой-то локальной проблеме — это да, но рассказывать азы... К тому же, часто это и является критерием продолжения сотрудничества после ИС: если человек не умеет учиться, то ему нужно не работать, а учиться учиться. А последнему учат в ВУЗе, но никак не на рабочем месте...
Поэтому ищу ментора / единомышленника / компанию(в которой готов работать бесплатно)

Поставьте себя на место такой компании. Зачем им подобный человек? Понятно, что бесплатно Вы будете работать только до определенного времени, а потом либо потребуете оплату за работу, либо найдете другое место работы. Итого, компания будет иметь профит только на время Вашего обучения, и то профит сомнительный, т.к. Вы будете занимать время людей, которые уже работают в компании. И очень вероятно, что для компании такой процесс будет убыточный.

Как я вижу выход из ситуации (по своему опыту): первоначально необходимо устраиваться в компании, которым не требуются высококлассные спецы для рабочего процесса, но где будет возможность учиться. Например, это разного рода государственные конторы и учреждения, возможно некоторые банки (суппорт). Работая там, у Вас будет возможность учиться. Рассматривайте работу в таких компаниях как инвестицию в свое образование, т.к. оплата будет минимальной.

госконторы и банки не дадут ничего. это совсем другая область ИТ, после вылета из которой за душой не остаётся ничего нужного.
Единственный плюс — можно поднатаскаться в теории достаточно, чтобы пройти тестирование на ждуна куда-нить в не слишком требовательную контору.
Реального опыта же будет 0.

госконторы и банки не дадут ничего
Реального опыта же будет 0.
ИМХО: не дадут ничего только в том случае, когда не стоит цель что-то взять. Но, думаю, это везде так...
можно поднатаскаться в теории достаточно
Как раз теория — это чисто самообразование. В таких конторах теоретические знания никого не интересуют (по правде говоря, качество кода очень часто тоже). Есть фронт работ — он должен быть закрыт. Как это будет сделано — отдается на откуп ИТ-отдела. ИТ-отделы в таких организациях представляют из себя смесь сотрудников пред- и после- пенсионного возраста и вчерашних студентов. Думаю, что толковый студент при должном самообразовании сможет вынести базовые практические навыки, с которыми уже не стыдно идти на собеседование в более-менее приличную контору. Естественно, сеньором в таких местах не стать, но джуном<->пре-миддлом — вполне возможно...

Еще один плюс: есть возможность спрыгнуть с разработки в сферу аналитики. Часто в таких компаниях процессы разработки идут на тяп-ляп, как исторически сложилось. И если подберется коллектив инициативных студентов, то есть все шансы внести свежую струю и смело писать строчку в резюме по поводу построения «правильных» процессов разработки ПО в организации (системы контроля версий, WorkFlow и т.д.). Все зависит от инициативности, самоорганизованности и желания приобретать нужные практические навыки.

Конечно, можно просто работать «от забора до обеда», не вникая ни во что дальше своего фронта работ. В этом случае, действительно, реального опыта будет 0, и думаю, лучше уже на этом этапе выбрать другую профессию.

умаю, что толковый студент при должном самообразовании сможет вынести базовые практические навыки, с которыми уже не стыдно идти на собеседование в более-менее приличную контору.
это если попасть в отдел разработки, где всерьёз разрабатывают собственный продукт. В остальном кроме как поддержки по телефону, еникейских мелочей и поведения в большом коллективе получить получится мало что.
Вот приват, вроде, более-менее серьёзно разрабатывает. Но на разработку берут не стажёров.
CVS, CI, тестирование, языки, планирование, — этого не будет. Будет доза екстремального программирования в широком смысле єтого слова, свободное время, возможно возможность поднять и полуподпольно поддерживать интранет ресурс и набор скриптов автоматизации.
Певый вариант не очень интрисует, так как это долгий и не очень продуктивный путь.

Вы не правы, если считаете, что вариант, когда Вас будут по шесть часов в день на протяжении полу года учить есть «долгим и не очень продуктивным».

Поэтому ищу ментора / единомышленника / компанию(в которой готов работать бесплатно). В день могу тратить от 4 до 8 часов. Готов работать над проектами, связанными с web приложениями.
Выбрось эти глупости из головы пока не поздно, иначе пополнишь ряды 40-летних безработных.
Побывав на испытательном сроке в одной компании я понял, что они не особо хотят обучать начинающих.
Плаксивое настроение не помогает достижению цели.
E синьйора, к которому вас прикрепляют вполне хватает своего напряга и поэтому он не будет с вами нянчиться целый день, но на сложные вопросы ответит.

Суть обучения: научиться работать самостоятельно, это вам скажет любой лид. Есть задача и требования — пошел гуглить, читать stack-overflow, разные хаки и прочее, я когда учился в 2011 году кодил 1 час в день, а 8 часов гуглил/читал/применял разные хаки. Тратил все свои выходные, было адски тяжело, но я справился и в свои те 35 лет стал junior-ом с з.п. 350$, потом повышали, да и технологии давались легче.
Feel the difference!

А вы хотите сразу стать миддлом после пары книжечек?

Я не могу полностью описать ситуацию, но поверьте я не ною, и с заданием я справлялся. Проблемы были в тонкостях, название переменных / не полная обработка ошибок / применение патернов. А кодить 1 час и 8 гуглить, как по мне непозволительная роскошь.

А кодить 1 час и 8 гуглить, как по мне непозволительная роскошь.
Как хотите, в АТБ всегда не хватает персонала.
Проблемы были в тонкостях, название переменных / не полная обработка ошибок / применение патернов.
Это естественные шаги обучения, ни один интерн эти вещи не делает нормально, да и не каждый джун. Единственный путь преодолеть — почитать умные книги, а затем очень много практиковаться и со временем уже будучи миддлом, можно обсудить с senior-ом называние переменной или паттерн :-), но это не прерогатива trainee.
А кодить 1 час и 8 гуглить, как по мне непозволительная роскошь.
Как хотите, в АТБ всегда не хватает персонала.
Я код трачу больше времени чем на гугл, я это имел в виду.
Это естественные шаги обучения, ни один интерн эти вещи не делает нормально, да и не каждый джун. Единственный путь преодолеть — почитать умные книги, а затем очень много практиковаться и со временем уже будучи миддлом, можно обсудить с senior-ом называние переменной или паттерн :-), но это не прерогатива trainee
Я собственно об этом и говорю. Мне практика нужна.
Я код трачу больше времени чем на гугл, я это имел в виду.
Вот это очень часто и является признаком, что «что-то в консерватории нужно подправить». Это те грабли, на которые наступают практически все новички в профессии: сначала кодим, потом понимаем, что мы накодили, а потом начинаем понимать, что нужно было закодить... Сам вначале своего пути очень часто наступал на эти грабли и много шишек набил. Но мне повезло с начальником, для кот. алгоритм решения задачи был с точностью до наоборот: «понять, что нужно кодить; понять, как нужно кодить; кодить»

Спасибо, но я думаю это все же от ситуации очень зависит.

я не помню где видел, но если считать количество строчек, выданых «на-гора» в день толковым спецом, то там получаются смешные цифры. Иные начинающие от пхп (делфи, питон, сишарп етц) делают этих спецов в разы, а поди ж ты — спецы остаются спецами, а начинающие всё ещё продолжают начинать)

Есть только одна ситуация когда кодить важнее — срочный фикс деплоя/билдов, при условии, что вы в курсе что и как делается в принципе и придерживаетесь проектных стандартов.

Во всех остальных случаях гораздо полезнее подумать полдня, нарисовать схемы, прикинуть кусочки кода, затем обсудить с девелоперами и тестерами (они добреют и заводят меньше багов) и за оставшиеся 1-1,5 дня сделать.

В противном случае если тупо кодить, то будут проблемы с интеграцией в команде, т.к. чуваки будут просто не в курсе где и что вы пишете = гарантированные проблемы с merge-ом в начале (превед svn) или в конце когда подливаешь свою ветку (git), а тестеры потом тупо взбесятся, что не понимают как это работает — и отомстят — заведут баги, «тут точки нет в тексте», «подвинь кнопку на 2px» и т.д.

Выводы делайте сами.

Ну вы закрутили. Да вообще суть топика в другом.

Думать некогда, кодить надо )))
Вы рассуждаете как мидл, который только паттерны изучил. И сидит, ломает голову, как всё продумать, чтобы всё сразу заработало. Но если вы пару недель думаете, а на кодинг ушло 1-1,5 дня, значит вы почти две недели ни хрена не делали, производительность низкая. Если бы вы начали писать с ошибками и увидели ошибки, переписали, то получилось бы не, допустим 1-1,5 дня, а 2-2,5. Что все равно быстрее двух недель. И даже если вы сверхумно всё продумаете, не верю, что то, что за 1.5 дня написано, не будет переписываться ни разу.

код == работа. Всё остальное от лукавого. Хотите думать, думайте в процессе. Код — это черновик ваших мыслей.

По поводу:

Проблемы были в тонкостях, название переменных / не полная обработка ошибок / применение патернов
Названия переменных принимаете как принято в проекте. Плохо или хорошо не важно, хуже, когда по разному. Это спрашивать не надо у синьйоров, по коду видно. Ошибки не обрабатываем, пусть падает. Серьезный недостаток новичков в том, что они считают, что ошибки надо всегда и везде обрабатывать. (Я про язык с эксепшинами). Паттерны читать, критически осмысливать, применять только в крайней необходимости, когда код упрощается с ними, а не усложняется (такое бывает, когда хотят на будущее сделать так, чтобы потом что-то проще менять, а на самом деле код «на сейчас» усложняется).
и отомстят
Меняем работу. Что за неуставные отношения )) Как это, в колективе мстители? Не на базаре ж.
код == работа
есть мнение, что как раз таки работа заключается в том, чтоб думать, а не как абизяна код писать, потом по 100500 раз переделывать.
То же касается и этого.

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

«Думать» никто у вас не отбирает.
Три стадии «достижения просветления»:
1) не могу копать
2) могу копать!
3) могу не копать

Где-то соотносится с программированием.
1) Пишу быстро, куйня получается
2) Начал учиться думать перед написанием, стал код чище
3) Пишу быстро, получается сравнительно качественно и быстро.

Т.е. есть техники, как писать, как переписывать, как в конце концов моделировать предметную область. Вы же всегда даже в уме это делаете по частям, а не всё сразу. Когда научитесь сразу по частям и записывать — вы получаете сразу в процессе мышления продукт. Позже, когда научитесь, будете думать, как вы без этого раньше обходились? Продумывая и не записывая ничего, это где-то аналогично, что играть в шахматы без доски. Мазохизм. Хотя в шахматах он имеет смысл, не очень удачная аналогия, то в программировании совсем почти не имеет смысл всё держать в уме.

Это так же может зависеть от сферы разработки. Я чаще в энтерпрайз работал. Не над чем особо думать. А требования меняются чаще, чем пятницы.
Но работал и в проектах, требующих производительность, алгоритмы и всё такое. То же самое. Конечно, если не знакомы с подходами к задаче, нужно почитать. Но думать тоже особо не над чем: нужен код, нужны замеры и реальные цифры, а не решать в воображении, что производительно, а что нет.

Где-то так

Моя ценность — решать проблемы, за которые мне платят деньги. Можно их решать костылями абы-как, как делают индусы и люди, «управляющие хаосом», который сами себе и создают, а можно самому себе сделать легче, если немного подумать.
Такое ощущение, что вы не программист, а неудавшийся журналист судя по ответам.

А я не предлагаю писать костыли. Это долгая тема, как надо разрабатывать эволюционно, по ТДД и тому подобное.

По сути, это не про костыли. А про «думать», но в процессе и с хорошей самодисциплиной в этом думании. Т.е. с определенным подходом, в какой последовательности думать и обязательно в этом процессе всё записывается в код. Т.е. представьте, что вы думаете с листочком бумаги, рисуя там чертежи. Это то же самое. Плюс подхода в том, что по окончанию процесса именно думания вы уже получаете готовый продукт.

Извините, если я как-то так ответил с оскорблением. Это так привык )) (Луговский стайл)

Как раз, по-моему, программисты на втором этапе своего развития пытаются все время думать, перед тем как писать. Дело не в том, что они думают, а в том, что они продумывают слишком много, ничего не записывая. В итоге получается водопад. Когда человек планирует всё наперед и живет по плану. В эволюционном же проектировании программист тоже думает, но думает по частям, обладая самодисциплиной и не забегая наперед, не планируя далеко свои действия. Тогда, он пишет вполне достойный и хороший код. Не идеальный, но качество достаточно высокое, а производительность как программиста очень высокая.

Советую для вхождения в тему книгу
Кент Бек «Экстремальное программирование: разработка через тестирование»

То, что я пишу: практика, давно и хорошо себя зарекомендовавшая. Это гораздо глубже, чем можно себе не ознакомившись с темой представить.

Миддлы не так уж и плохи, как по мне лучше занимать адекватную должность, чем делать хорошую мину при плохой игре.

Был у нас в команде один украинский senior с высоким самомнением и снисходительным отношением к миддлам, так он умудрялся растягивать 2-х дневный таск на 3-4 недели, мотивируя это большой занятостью и делая «морду кирпичом», хорошо что свалил в другую команду уже, но его код пришлось переделывать мне и ушло на это чистых 2 недели, ах да, он был не покрыт тестами, была куцая проверка входных параметров = вылеты на некоторых исходных данных, сам код — гов*нокод уровня чуть лучше индуса.

1) Пишу быстро, куйня получается
2) Начал учиться думать перед написанием, стал код чище
3) Пишу быстро, получается сравнительно качественно и быстро.
как раз в тему.

Еще наш senior любил порассуждать о высоких материях на любую тему от японской живописи до Unix-а, не разбираясь ни в одной теме. Кого-то мне напоминает :-)

так, называть себя синьйорами кто угодно может. По-моему синьер должен обладать отменными знаниями в своей области, не писать или хотя бы уметь не писать говнокод и очень стараться этого не делать. И опыта минимум 8 лет. Так как в других странах. Это у нас могут себя назвать через год опыта синьйорами. А через два уже архитекторы и тимлиды.

Бывает. И чаще, чем не бывает ))

Для детей природы спец. пояснение:

Во всех остальных случаях гораздо полезнее подумать полдня

а не то что вы пишете.
Но если вы пару недель думаете, а на кодинг ушло 1-1,5 дня, значит вы почти две недели ни хрена не делали, производительность низкая.

придумать 0,5 дня в 2 недели — лихо вы так? судите по себе?

придумать 0,5 дня в 2 недели — лихо вы так? судите по себе?
Это я утрирую и описываю водопад. Если вы пытаетесь продумать всё перед тем как писать, то это пусть маленький, но водопад. Т.е. такое управление проектом, когда вначале идет фаза проектирования всего и вся, без написания кода. И эта фаза как минимум будет две недели.

Думать даже полдня не записывая — не полезно. У вас нет быстрой обратной связи от кода, вы не пользуетесь средствами программиста, языком программирования. Язык и должен быть инструментом вашего мышления, а код показателем, насколько правильно и естественно вы думаете на этом языке. Если же вы продумываете и не пишете, то это всё равно, что у вас язык программирования не родной, а вы не программист, а, допустим, сантехник. Вам надо нарисовать на языке труб, унитазов и раковин, что вы хотите сделать, а потом заняться переводом на язык, который понимают программисты.
Рисуя UML-диаграммы, например, может казаться, что они красивы и вы нашли красивое решение. Но когда оно ляжет на код, сразу становится видно, что он нечитаем, неочевидный, кривой и тому подобное. Поэтому лучше использовать не схемы, не воображение, а язык программирования. Придумали часть, записали, посмотрели. Не нравится — переписали. Именно «переписали», т.е. «рефакторинг» и дает то, что код остается приемлемым и без костылей.

Есть и место в графике, когда действительно необходимо не писать код, а «осмотреться». Это когда вы читаете документацию или изучаете стандартные подходы для решения таких задач, чтобы не создавать велосипеды с нуля.

Проблемы были в тонкостях, название переменных / не полная обработка ошибок / применение патернов.
Безобразие! Задание на дом: проштудировать «Идеальный Код» Макконела и GOF.
А кодить 1 час и 8 гуглить, как по мне непозволительная роскошь.
Бывает. Час колупаешь документации — 10 минут кодишь. Советую смириться, в нашем деле кодинг, как ни странно, не главное.
А кодить 1 час и 8 гуглить, как по мне непозволительная роскошь.
Считаю, непозволительная роскошь: это 1 час гуглить, 8 часов кодить, 8 часов переделывать то, что накодил (кода сеньор тыкнет в это носом), при этом гугля еще 7 часов. Лучше на первых порах сделать необходимую инвестицию времени в эти «тонкости» — дальше это трансформируется в практический опыт, который будет без особых усилий тиражироваться по коду.

А если копаете «от забора до обеда» — то придется и дальше придерживаться именно такого подход а к рабочему процессу. Думаю, это не является Вашей целью.

Middle разработчики по цене Junior
’оно’ нравится, да и способности присутствуют
Побывав на испытательном сроке
Причем здесь Middle?

Ну «побывал» же на ис в одной компании. Все, мидл.

Подписаться на комментарии