ReactJS, TypeScript, Micro FrontendsReact fwdays | 27 березня. Долучайся!
×Закрыть

Образование и IT: интерны в CQG

Продолжаем разговор о программах обучения от украинских девелоперских компаний. На сей раз в фокусе — компания CQG, уже достаточно интересная тем, что в отличие от большинства софтверных гигантов, практикующих активную подготовку молодого поколением (таких как GlobalLogic, Luxoft, EPAM и т. д.) является продуктовой, при этом занимающейся разработкой очень узкоспециализированных решений.

Да и модель обучения у CQG немного необычная, «двухступенчатая». Помимо открытых курсов обучения, на которых студенты могут получить необходимые знания и умения, у компании имеется так называемая программа интернатуры, internship — ребятам, которые отличились в процессе обучения, предлагается позиция разработчика. С небольшими «ограничениями» — у интернов гибкий график и 50%-ная аллокация рабочего времени.


© CQG Ukraine

Таким образом, интернатура в компании позволяет студентам старших курсов без ощутимых усилий совмещать учёбу и работу (при этом настоящую, профильную и хорошо оплачиваемую). Задачи у новичков проще, чем у бывалых разработчиков, но, тем не менее, это уже опыт разработки реальных коммерческих проектов. О результатах трёхлетней деятельности internship-программы в киевском офисе CQG любезно согласился рассказать Дмитрий Гайворонский, Resource Director компании.

— Расскажите немного о компании и её деятельности?

— CQG была создана более 30 лет назад в США. Изначально компания предоставляла программно-аппаратные решения по доставке биржевых данных. В данный момент в CQG работают около 500 человек в 15 офисах по всему миру, 6 из которых занимаются исключительно разработкой. Головной офис разработчиков находится в Денвере, и примерно равнозначные подразделения расположены в Москве, Киеве, Самаре, Зеленограде и Ереване. Мы не являемся аутсорсинговой компанией в широком смысле этого слова — мы продуктовая компания с единственным продуктом, который мы создали за 30 лет и который де-факто является стандартом на биржевом рынке. В принципе большинство решений, созданных нами, за 30 лет становились стандартами. В частности, представление биржевой информации, которое CQG придумала ещё в 90-х, сейчас используется повсеместно, потому что оно оказалось весьма удобным.

Наши решения в первую очередь ориентированы на крупные компании, которые заинтересованы в большой скорости доставки данных, минимальных временных задержках при доставке и высокой надёжности. Наши клиенты — это хедж-фонды, некоторые банки, в том числе Citibank of America и J.P. Morgan, наши конкуренты на определённых рынках — Bloomberg и Reuters, а коллеги — Dow Jones, с которыми у нас было несколько совместных проектов.

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

Надёжность в нашем случае является одним из критических параметров — ведь суммы ордеров, с которыми работают наши клиенты, весьма высоки, они должны передаваться вовремя и без потерь.

Это определяет специфику людей, которые у нас работают. Мы не можем себе позволить создать продукт и забыть о нём, мы не предлагаем «коробочных» решений. А создать подобную архитектуру и решения, удовлетворяющие таким требованиям достаточно тяжело, если уровень ваших разработчиков — средний. Я никоим образом не хочу умалять достоинств и требований других компаний, занимающихся разработкой, но зачастую выходит так, что люди, работающие у нас на позиции middle-девелопера, могут уйти в другие компании lead- или senior-разработчиками. Или наоборот, те люди, которые приходят с гордым титулом лид-девелопера, у нас на проверку оказываются миддлами — хорошими, уверенными программистами, но не хватающими звёзд с неба.

Это в принципе проблема рынка, и, что характерно, не только в Украине — и в России, и в Ереване и в Штатах наблюдается инфляция тайтлов, представления о собственных знаниях у тех людей, которых мы собеседуем.

— А идея интернатуры, обучения кадров возникла давно?

— Свою internship-программу мы начали в 2007 году, ещё до первого кризиса, в Зеленограде. Цель, которую ставит перед собой компания, — дать возможность работать у нас молодым начинающим разработчикам. К сожалению, на рынках труда Украины, России (не скажу о Ереване, ситуация там схожая, но подробных данных у меня нет) мы видим, что качество образования, не теоретического, а, скорее, практического и уровень знаний, которыми обладают выпускники ВУЗов, ниже требований компаний. Особенно компаний, требовательных к девелоперам, как наша.

Поэтому получается, что мы стараемся набрать ребят, которые демонстрируют хорошие способности на 4-5 курсе, и дать им те знания, которые они никогда бы не получили в ВУЗе, если бы ограничивались только институтской программой образования. То есть мы не спорим, что достаточно часто у ребят есть хорошая математическая подготовка, у многих выпускников желание и стремление работать на высоте, даже больше чем у человека, который уже десять лет занимается разработкой, но практических знаний и, в частности, знаний об особенностях работы в компании, команде. В той или иной форме компания CQG сотрудничает со студентами, ВУЗами по крайней мере в трёх городах (Самара, Зеленоград и Киев), бесплатно обучая студентов, после чего некоторым из них делает предложения об интернатуре в компании CQG.


© CQG Ukraine

В Киеве мы начали в 2009 году и работаем по следующей схеме — даём объявление о начале занятий и отбираем группу из абитуриентов. Занятия длятся три месяца, мы учим студентов четыре дня в неделю по два часа. Ограничений при отборе практически нет, это может быть студент, это может быть начинающий разработчик, это может быть разработчик, который работает в другой компании и хочет поднять свой уровень. Условия одинаковы для всех — мы отбираем студентов с достаточными знаниями С++ или C#, компьютерных технологий, и преподаём им курсы Advanced C++, Advanced Databases, Software Development Processes, рассказываем о финансовых рынках и биржевых технологиях. Это не считая мелких единичных лекций. Через два месяца такого обучения мы предлагаем им сделать курсовой проект, который, скорее всего, будет отличаться от всего, с чем они работали в своей жизни до этого момента. Потому что это работа — коллективная.

За три года мы уже убедились в том, что даже самые одарённые студенты, которые уже пишут код, увлекаются технологиями, не имеют никакого опыта коллективной работы.
Максимум, что было у ребят — лабораторные работы или небольшие самостоятельные проекты. В большинстве случаев люди могут хорошо владеть IT-технологиями, разбираться в С++, знают, как выглядит стек функции при вызове, но при этом абсолютно не представляют что представляет собой разработка в компании. И это именно то, чему мы собираемся их научить на нашем модельном проекте.

Мы видим, что из года в год интерес к программе растёт. В первый год мы отобрали группу в 10 студентов из, примерно, 20 претендентов, во втором, 2010, была группа из 12 человек на 40 соискателей, в этом году был настоящий бум. Для того, чтобы попасть в число соискателей, необходимо было зайти к нам на сайт, выбрать одну из четырёх предложенных задач, решить её на языке программирования и прислать нам. Мы инспектируем код решения, примерно так же, как каждая компания инспектирует код тестовых заданий, просто предъявляя не такие высокие требования, и приглашаем студентов на собеседование в офис. Тех, людей, которые справились с задачей (что обычно составляет достаточно малый процент из активных студентов) в этом году было порядка 100 человек! Из них на собеседовании было порядка 50 или 70, точно не помню, и мы постарались пойти навстречу и увеличили группу до 15 человек. Хотя это уже лимит комфортного преподавания, потому что это происходит в рабочее время, в рабочей обстановке и мы не можем забрать много ресурсов у наших проектов.

— И какова эффективность подобной программы обучения, если оценивать профессиональные навыки выпускников?

— Опыт показывает, что интерес для крупной компании после окончания образовательной программы среди этих ребят вполне могут представлять 50-60%. То есть это люди, которые могут прийти в компанию на позицию джуниор-разработчика.

Это, разумеется, очень сильно зависит от того, какие требования у компании к проектам. Если, к примеру, это что-то достаточно несложное в техническом плане: веб-сервисы, клиентские приложения, то этот процент может доходить и до 80.


© CQG Ukraine

Мы не планируем определённого числа вакансий в интернатуре, у нас нет конкурса, но практика показывает, что примерно один из 4-5 студентов, прошедших у нас обучение остаётся у нас же и работать. Сначала интерном, потом, когда оканчивает обучение в институте — на полный рабочий день.

— Какие интересные моменты в подготовке будущих специалистов вам хотелось бы отметить?

— К примеру, то, что для студентов эта программа — первые шаги в командной работе. Одно дело написать продукт, когда ты целиком контролируешь требования, процесс разработки, конечный результат и дизайн. Как в лабораторной работе, или небольшом приложении под Android или iOS. Совсем другое дело, когда вы работаете в группе из нескольких человек, и вам нужно выработать общие требования, дизайн системы, возможно, интерфейс, по которому ваша система будет общаться с другими.

В прошлых 2009-2010 годах финальный проект выглядел следующим образом: на реализацию давался месяц (16 занятий/48 часов). Группа из 12 человек разбивалась на команды по 3-4 человека, перед всеми была поставлена одинаковая задача — написать поисковик по локальной файловой системе (аналог Google search, Copernic и т. п.). При этом наши сотрудники и я в том числе выступали с одной стороны в роли бизнес-экспертов, ставящих задачи, а с другой — в роли отвечающих на вопросы «военных советников», по терминологии наших занятий. Мы ставили задачу, принимали у них требования, советовали, как эти требования доработать до полноты, корректности и т. д. Но при этом мы не принимали участия в разработке дизайна, хотя могли помочь советом.

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

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

Из интересных цифр: примерное соотношение по производительности между программистом с 8-10 годами стажа разработки и толковым энергичным студентом, который только начинает — приблизительно 4:1.
Это повторяется не первый год, и проверялось не на одной задаче. Все задания, которые мы предлагаем студентам, мы писали самостоятельно с нуля. В среднем ту задачу, реализация которой у нас занимает 20-30 минут, студенты смогут решить за полтора-два часа, и не факт, что решение будет работать. Поэтому если нам удалось сделать работающую систему за неделю по вечерам, то ребятам гарантированно потребуется месяц.

В этом году мы немного усложнили подход. Предварительно мы ввели в курс несколько лекций по реализации графики в приложениях и работе с сетью. Задача была сформулирована следующим образом — ребятам предлагалось написать игру Galcon. Но при этом группа была разбита на четыре команды, три из которых занимались по отдельности разработкой собственного клиентского приложения, а четвёртая работала над серверной частью. Это оказалось очень серьёзным испытанием, потому что выяснилось, что от успеха «серверной» команды зависит успех всех остальных. Процесс был весьма интересен: часть «клиентских» команд реализовала эмулятор сервера, для того, чтобы тестировать свои приложения, кто-то предусмотрел возможность локальной игры, без эмулятора. Сказать честно, мы были откровенно удивлены, потому что все четыре команды справились, практически без глюков и дефектов, на зачёте отлично порубились в skirmish.

Процесс разработки полностью совпадал с процессом разработки серьёзного проекта. Ребята сами задавали функциональные требования — к протоколу, производительности, допустимому времени задержек и т. д. Они писали код на С++ с использованием сетевого слоя, графического слоя, при этом весь код лежал на GitHub, поэтому можно было посмотреть, что и как реализовано у конкурентов.

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

После того, как образовательная программа заканчивается, мы собираем фидбеки. На их основании мы разрабатываем программу на следующий год. Вот, к примеру, сейчас мы планируем уделять в будущем меньше внимания базам данных и сделать больше практических занятий по сетям. Не буду открывать все карты, но возможно мы добавим больше языков программирования, вероятней всего это будет C# (вдобавок к С++).

— А что, собственно, компания получает в результате проведения подобных мероприятий? Вы довольны результатами, намерены продолжать программы обучения?

— Нужно понимать, что мы, прежде всего, коммерческая компания, задача которой — создание продукта, и программа internship для нас содержит три цели. Во-первых, это обучение и поиск новых сотрудников. Во-вторых, (и это самое интересное) — это фан внутри компании. Потому что очень интересно внезапно переключиться из режима «крутой разработчик» в режим «преподаватель», и вдруг обнаружить, что ты чего-то не знаешь. Или о чём-то успел забыть. Команда наших преподавателей немножко менялась из года в год, но в целом порядка 25% сотрудников так или иначе задействованы в нашей программе: они преподают программирование, дебаггинг, базы данных, процессы разработки. При этом очень много внимания уделяется именно «боевому» опыту использования технологий — то, что вы не найдёте ни в одной книге.

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

Будем ли мы продолжать — да, конечно, будем, не думаю, что подход компании изменится в ближайшие несколько лет. Нам нравится рассказывать об этом, нравится находить людей, у которых горят глаза и мы хорошо знаем, что недостаток знаний компенсируется желанием создавать что-то. Люди, которые приходят к нам преисполненными энтузиазма, буквально через полгода могут показать то, чего от себя совсем не ожидали.

— В других городах модель работы такая же, как в Киеве?

Не совсем, многое зависит от местной специфики. К примеру, Зеленоград находится недалеко от Москвы, там расположен Московский институт электронной техники, МИЭТ. И наше зеленоградское подразделение активно сотрудничает с этим институтом, курс разработки программного обеспечения преподаётся не на стороне CQG, а на базе ВУЗа. Студенты отбираются по среднему баллу, кроме того, есть возможность прохождения собеседования. Курс читается не группе из 10-15 человек, а целому потоку, человек в 60, по субботам в помещении института нашими сотрудниками. Что-то мы перенимаем у преподавателей института, что-то они у нас. Но в целом схема обучения в каждой отдельной стране зависит от близости ВУЗов, отношений и модели взаимодействия с ними, желания и возможностей наших людей работать в таком режиме и т. п.

Чем-то подход Зеленограда нам импонирует, по крайней мере, отбор студентов там происходит проще. Всё-таки отбор по среднему баллу — это фактически, обращение к базе данных студентов. Чем-то, по нашему мнению, киевская модель более удачна — для того, чтобы отобрать будущих интернов из 60 человек, нужно иметь чёткую систему контроля, оценки кода. Но мы вместо этого можем видеть на протяжении трёх-четырёх месяцев, как ребята работают, как они себя проявляют, кто берёт на себя проектирование системы а кто является по духу хакером и работает по ночам. Репозиторий GitHub позволяет отслеживать, как люди комментируют свои проекты. Забавно видеть, как человек в четыре часа ночи перед каким-нибудь ответственным экзаменом в институте комментит два килобайта кода, потому что он проснулся и захотелось что-то написать. И в подавляющем большинстве своём те люди, которые здесь работают 5, 10, 15 лет — мы все такие, мы приходили точно так же, с горящими глазами. И нам очень нравится передавать свои знания дальше!

В Ереване модель совсем другая — там очень сильна математическая база, там другие задачи и другой подход к набору людей. Но в целом программа работает так, как у нас. В Самаре используется приблизительно киевская модель.

Пока что мы видим, что даже те ребята, которые не попали к нам после окончания internship-программы, практически моментально находят работу в других компаниях.
Им гораздо легче найти работу и вообще работать, и дело здесь как в практических знаниях, так и в весе, которые разработчики CQG имеют на локальном киевском рынке, в позитивном реноме компании.

— Проекты, над которыми работают студенты, носят чисто образовательный/игровой характер, ничего коммерческого или более-менее практического вы им не даёте?

— Большинство проектов, с которыми мы имеем дело, слишком требовательны к качеству и к дизайну, чтобы мы могли позволить в них участвовать студентам. Второй момент — эти продукты существуют уже больше десяти лет, и code base настолько велик, что даже когда в компанию приходит разработчик со стажем, мы считаем, что в 80% он сможет быть эффективен в разработке не ранее, чем через три месяца. На деле, лучшие разработчики, которые приходили к нам на позиции архитекторов и тим-лидов въезжали в курс дела не ранее, чем через полгода. Поэтому давать практические примеры студентам просто нереально.

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


© CQG Ukraine

Разработчикам в процессе собеседования мы тоже даём какие-то абстрактные задачи. К примеру, реализовать модуль проверки орфографии. И на самом деле нам важно лишь увидеть, как человек пишет код — знает ли он С++/C#, обладает ли он знаниями стандартных библиотек .NET, не изобретает ли «велосипеды», какой стиль написания. По коду о человеке можно сказать очень многое — это то, в чём мы убеждаемся последний десяток лет. Такие задачи не имеют в принципе никакого отношения к нашим проектам. И весело получать отзывы от людей, которые не прошли наши собеседования в духе «CQG использует решения и наработки своих кандидатов для создания коммерческих продуктов» (да, было и такое), зная уровень синтетических задач для собеседования и реальных продуктов.

— Насколько соотносится с реальной методология разработки, использующаяся в образовательных проектах?

Да, мы используем некую упрощённую модель, однако она не абстрактная, а соответствует нашей схеме разработки. Мы — компания с очень серьёзно поставленными процессами и сбором метрик по этим процессам. Наш процесс выработан под нас, это результат проб, ошибок, анализа данных и размышлений не одного десятка умных людей. Это гибрид Waterfall-модели, Scrum, Agile, словом то, что нам нужно для данной конкретной цели. А специфика заключается в том, что между всеми командами, работающими в CQG, идёт достаточно плотное сотрудничество, поскольку несмотря на разные задачи мы работаем над одним глобальным проектом. Внутри команды методология разработки может быть произвольной — кто-то предпочитает Scrum, кто-то Waterfall, кто-то устраивает ежедневные митинги, кто-то обходится без них. Однако общими для всех команд являются некие итерации, определённой периодичности, отчёты и демонстрации. Наш процесс со студентами и интернами в целом отвечает этой большой модели, но ясное дело, мы не собираем метрик в том объёме, не устраиваем обязательных Scrum-митингов для каждой команды (этим они занимаются по желанию самостоятельно). Мы требуем, чтобы в процессе создания продукта были выработаны бизнес требования и функциональные требования, дизайн, достаточного уровня для понимания системы, может быть концептуальная UML-модель, дополненная sequence-диаграммой, детальным описанием класса или интерфейса.

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

Мы раздумываем над тем, чтобы сделать модель более формальной, но как гласит тот же agile: задача — создать продукт, а не перекладывать бумажки из одной папки в другую. Поэтому мы стараемся процесс и в компании и на internship держать минимально формальным.

— На обучение приходят студенты из различных киевских ВУЗов, можно ли выделить какие-то тенденции, из каких институтов больше всего соискателей?

— Политех — на первом месте. В целом, за три года более 90% интернов были представлены тремя ВУЗами — КПИ, Университетом и КМА. К слову о Могилянке — оттуда приходят очень образованные и целеустремлённые люди. Не могу такого же сказать по Политеху и Университету — ощущение такое, что общий дух там более «хакерский», но Могилянка — это люди, которые целенаправленно чего-то хотят в жизни и многие этого добиваются. Большинство киевлян, которые работают в CQG — они из Политеха, по крайней мере, больше половины.

— В чём, по вашему мнению, главный недостаток современной системы обучения в ВУЗах?

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

— Спасибо!

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

Похожие статьи




Підписуйтесь: SoundCloud | Google Podcast | YouTube


13 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Спасибо за идеи, есть очень ценные. Но всё-таки мне кажется автор недооценил результативность этой технологии. При случае опробую сам, но могу сказать одно: соотношение производительности 4:1 — слабый результат. Если производительность юниора всего 25%, то на что тратится 75%? Хорошо если на обучение, но даже в этом случае где-то есть колоссальная утечка возможностей.

Где именно — буду знать если сам приму участие в подобных мероприятиях (в любой роли), уверен у меня результат будет выше.

4:1 — здесь речь идет о том, что один опытный разработчик, хорошо знакомый с технологиями и системой, которую он разрабатывает, заменит как минимум 4 новичков только-только со школьной скамьи.

Поддерживаю про школьную скамью, высшее прогерам уже не требуется. Как кстати и среднее.
Но боюсь 4:1 как раз речь шла о ОПЫТНЫХ с опытом 10 лет, и юниорах (до года, ПОСЛЕ их курсов). Именно так я и сказал — если 75% времени на обучение, тогда ДА!, но терзают смутные сомнения.

как мне говорил Дима, «привезены контейнером из Штатов» :)

Мені б таке начальство. Думаю про те, щоб самому купити, але Амазон сюди не доставляє, а в Києві ціна х2.

ebay доставляет, но дорого (больше $200 кажется), и потом еще ~44% таможне. Само кресло хороше, но ни разу не «silver bullet» — я бы рекомендовал попробовать в нем посидеть перед заказом.

Дякую, тепер ясно чому такі ціни. Є ще варіант привезти з Польщі, може так вийде дешевше.

Попробувати посидіти само собою.

Очень достойные знания дают в CQG интернам. Сейчас и вправду большая инфляция тайтлов, потому-что с этими знаниями можно запросто пройти собеседование на мида, (естественно с небольшим опытом разработки)

И вообще, если вы хотите делать качественный продукт — то вам там должно очень понравиться.

Игры, как подготовка для разработки ПО для трейдинга, однако...

Скорее, игры, как подготовка для разработки ПО :) а разработка ПО для трейдинга — это уже другой курс...

Да, именно так. Игры, особенно с поддержкой network multiplayer — хорошая модель. Тут и сетевой уровень, и бизнес-логика как на стороне сервера, так и клиента, протокол, устойчивость, определенные требования к производительности, etc.

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

Так что, если кому-то нехватает квалифицированых разрабов — начинайте воспитывать их уже сейчас, сами. Завтра их будет нехватать ещё сильнее, а время уже потеряно.

Конечно, без соответствующего опыта сначала будет получаться плохо. Но если не начинать — он и не появится. А время уже будет потеряно...

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