— а какие минусы у мобилки? или чем бэк круче?
У меня есть один спорный аргумент – в бэкенде я чаще сталкивался с объективно сложными задачами. Под словом «объективно» я подразумеваю какие-то не вендор-специфичные ограничения, которые обязан обходить. Здесь нужно продумать, как хранить данные денормализованно, чтобы искались быстрее. Сделать механизм транзакций, чтобы все не лочилось намертво. Решая такие задачи, ты понимаешь, откуда берутся ограничения, и они не вызывают у тебя баттхерта. В свою очередь в Android я слишком часто сталкивался с проблемами, которые вызваны только тем, что Android SDK неудобный и ни разу не developer-friendly. Бесчисленное количество раз приходилось сидеть и ловить себя на мысли, что уже в сотый раз пишешь костыли, чтобы просто отрисовать на экране список элементов, и он мог нормально, плавно скроллиться. Это не очень мотивирует.
Если обобщить, то в большинстве случаев мобилка – это тонкий клиент. Т.е. она получает данные с сервера и показывает их в своем интерфейсе. Пользователь жмет кнопку – данные пересылаются на сервер, сервер присылает ответ, клиент перерисовывает интерфейс. Всё. А вся «реальная» работа выполняется на сервере. Точно знаю, что для кого-то этот тезис валидный ответ на вопрос, чем бэк круче мобилки. После перехода из бэка в Android я первое время тоже так считал. Сейчас изменил свое мнение, т.к. все-таки одно без другого смысла не имеет, и просто некорректно сравнивать важность абсолютно разных задач.
В конечном итоге, я теперь понимаю, что никто не круче 🙂 Это просто разные инженерные задачи)
У меня есть один спорный аргумент – в бэкенде я чаще сталкивался с объективно сложными задачами. Под словом «объективно» я подразумеваю какие-то не вендор-специфичные ограничения, которые обязан обходить. Здесь нужно продумать, как хранить данные денормализованно, чтобы искались быстрее. Сделать механизм транзакций, чтобы все не лочилось намертво. Решая такие задачи, ты понимаешь, откуда берутся ограничения, и они не вызывают у тебя баттхерта. В свою очередь в Android я слишком часто сталкивался с проблемами, которые вызваны только тем, что Android SDK неудобный и ни разу не developer-friendly. Бесчисленное количество раз приходилось сидеть и ловить себя на мысли, что уже в сотый раз пишешь костыли, чтобы просто отрисовать на экране список элементов, и он мог нормально, плавно скроллиться. Это не очень мотивирует.
Если обобщить, то в большинстве случаев мобилка – это тонкий клиент. Т.е. она получает данные с сервера и показывает их в своем интерфейсе. Пользователь жмет кнопку – данные пересылаются на сервер, сервер присылает ответ, клиент перерисовывает интерфейс. Всё. А вся «реальная» работа выполняется на сервере. Точно знаю, что для кого-то этот тезис валидный ответ на вопрос, чем бэк круче мобилки. После перехода из бэка в Android я первое время тоже так считал. Сейчас изменил свое мнение, т.к. все-таки одно без другого смысла не имеет, и просто некорректно сравнивать важность абсолютно разных задач.
В конечном итоге, я теперь понимаю, что никто не круче 🙂 Это просто разные инженерные задачи)
Java Developer pinned «Интервью с head of mobile Яндекс.Транспорта На мероприятии от подкаста Подлодка познакомился с Женей Кателла. Узнал, что он не только ведёт подкаст и работает в Яндексе, но ещё добрый открытый парень, который работал раньше джавистом на бэке. Тут я понял…»
Как развиваться разработчику
Изначально вопрос звучал «как развиваться мобильному разработчику?», но ответ Жени тянет на целую статью и будет полезен каждому деву.
Тут у меня ответ многоуровневый. Во-первых, нужна хорошая база. Сюда я отнесу того же Макконелла и Фаулера. Понимание принципов-аббревиатур (SOLID, KISS, DRY и прочее) тоже никогда никому не вредило.
Когда есть какая-то база, нужно прокапывать свою платформу в глубину. StackOverflow driven development никто не отменял, конечно, но с таким подходом глупо надеяться, что сможешь знать эффективные решения повседневных задач. Поэтому стоит изучать документацию, читать исходники, искать источники новых знаний и подходов. Экспериментировать, но без фанатизма.
Например, понимание того, как под капотом работает диспатчинг асинхронных задач в платформе, поможет понимать, что происходит, когда ты вызываешь такой привычный метод из SDK. А вот просто так, без релевантных задач, изучать специфику работы BluetoothAdapter – такое. Узкие знания обычно не задерживаются надолго в голове без постоянной практики.
Есть еще одно направление, которое мне кажется важным для дальнейшего роста. Нужно понимать, как устроены смежные области на твоем проекте. Если ты мобильщик – стоит хотя бы на базовом уровне понять, как работает ваш бэкенд. Написать самому какой-нибудь пет-проект с бэкендом будет плюсом, т.к. помогает под другим углом смотреть на решения, которые принимаются в смежных командах. Количество недопонимания и конфликтов таким образом можно сократить значительно🙂
Изначально вопрос звучал «как развиваться мобильному разработчику?», но ответ Жени тянет на целую статью и будет полезен каждому деву.
Тут у меня ответ многоуровневый. Во-первых, нужна хорошая база. Сюда я отнесу того же Макконелла и Фаулера. Понимание принципов-аббревиатур (SOLID, KISS, DRY и прочее) тоже никогда никому не вредило.
Когда есть какая-то база, нужно прокапывать свою платформу в глубину. StackOverflow driven development никто не отменял, конечно, но с таким подходом глупо надеяться, что сможешь знать эффективные решения повседневных задач. Поэтому стоит изучать документацию, читать исходники, искать источники новых знаний и подходов. Экспериментировать, но без фанатизма.
Например, понимание того, как под капотом работает диспатчинг асинхронных задач в платформе, поможет понимать, что происходит, когда ты вызываешь такой привычный метод из SDK. А вот просто так, без релевантных задач, изучать специфику работы BluetoothAdapter – такое. Узкие знания обычно не задерживаются надолго в голове без постоянной практики.
Есть еще одно направление, которое мне кажется важным для дальнейшего роста. Нужно понимать, как устроены смежные области на твоем проекте. Если ты мобильщик – стоит хотя бы на базовом уровне понять, как работает ваш бэкенд. Написать самому какой-нибудь пет-проект с бэкендом будет плюсом, т.к. помогает под другим углом смотреть на решения, которые принимаются в смежных командах. Количество недопонимания и конфликтов таким образом можно сократить значительно🙂
Когда появилось ощущение, что платформа знакома и понятна, надо принимать для себя важное и осознанное решение: в какую сторону двигаться дальше. Я вижу три варианта: горизонтальный переход, уйти в относительно узкую экспертизу и менеджмент.
Горизонтальный переход. Был Android – стал iOS. Был бэкендщик – перешел в мобилку. Ну и так далее. Тут мне особо нечего прокомментировать, кроме того, что нужно уметь самому себе ответить на вопрос «зачем». Если устал от Android, сил нет больше им заниматься и вообще перегорел – уйти в тот же бэкенд вполне хороший вариант. Просто перейти, потому что там трава зеленее – так себе вариант, т.к. придется много своих прикладных скиллов оставить позади.
Экспертиза. Например, когда раньше писал мобильные приложения, а потом стал заниматься мобильной CI-инфраструктурой. Или всерьез занялся оптимизацией перформанса и пошел пилить узкоспециализированные тулзы. Тут я знаю только, что этот путь с одной стороны снижает количество вакансий, которые лично тебе будут интересны и релевантны. Зато ценность таких сотрудников обычно высокая и работодатели готовы за них побороться.
Менеджмент. Т.е. расти в тимлида и выше. Здесь главное сразу понимать, что большая часть работы будет завязана на общение с людьми. Не всем это подходит и не все к этому готовы. Если ок – значит можно идти по этой ветке.
Горизонтальный переход. Был Android – стал iOS. Был бэкендщик – перешел в мобилку. Ну и так далее. Тут мне особо нечего прокомментировать, кроме того, что нужно уметь самому себе ответить на вопрос «зачем». Если устал от Android, сил нет больше им заниматься и вообще перегорел – уйти в тот же бэкенд вполне хороший вариант. Просто перейти, потому что там трава зеленее – так себе вариант, т.к. придется много своих прикладных скиллов оставить позади.
Экспертиза. Например, когда раньше писал мобильные приложения, а потом стал заниматься мобильной CI-инфраструктурой. Или всерьез занялся оптимизацией перформанса и пошел пилить узкоспециализированные тулзы. Тут я знаю только, что этот путь с одной стороны снижает количество вакансий, которые лично тебе будут интересны и релевантны. Зато ценность таких сотрудников обычно высокая и работодатели готовы за них побороться.
Менеджмент. Т.е. расти в тимлида и выше. Здесь главное сразу понимать, что большая часть работы будет завязана на общение с людьми. Не всем это подходит и не все к этому готовы. Если ок – значит можно идти по этой ветке.
По развитию в ветке менеджмента у меня есть несколько практических рекомендаций, которых лично я придерживался. Не уверен, что получится сильно системно рассказать, но я попробую.
1. Всегда стоит смотреть не только на свои задачи, но и за пределы. Тимлид должен быть драйвером изменений в команде. Если есть амбиции тимлида – нужно учиться подмечать проблемы и точки улучшений, чтобы превращать их в задачи для команды. Разработчик, который помимо своих задач часто приносит какие-то здоровые адекватные инициативы по улучшению качества кода, всегда будет особенно заметен на радаре своего руководителя.
2. Второй скилл очень связан с первым. Нужно учиться смотреть на любые задачи, технологии, рефакторинги и процессы с точки зрения их влияния на продукт в целом. Нужно всегда уметь ответить на вопрос «а зачем я это делаю»? Условно, вот хочу я затащить библиотеку для DI. Если я это делаю, потому что она сейчас в тренде и все авторитеты индустрии выступают на конференциях, рассказывая про нее – это плохой знак. Надо всегда уметь дать максимально внятно оценить соотношение того, сколько сил придется потратить на какое-то действие к тому, какое влияние оно окажет на проект.
3. Нужно учиться общаться и выстраивать культуру общения в команде. Один человек, будь это даже самый матерый тимлид, вряд ли будет так же эффективен при принятии решений, как целая команда. Поэтому стоит задуматься о том, чтобы решение принимала команда. А такую культуру надо развивать и прививать. Недостаточно вбросить вопрос, а потом дождаться от команды ответа. Иногда люди в процессе обсуждения могут нагенерировать новых идей и в итоге запутаться или разругаться. Поэтому тимлид должен уметь фасилитировать такие обсуждения, чтобы с одной стороны создать атмосферу, в которой каждому будет комфортно предложить идею, а с другой – чтобы при отсутствии согласия в команде либо найти компромисс, либо взять на себя ответственность и самому принять решение.
4. Также, во многих компаниях и командах тимлид – это важный партнер менеджера, будь то продакт или проджект-менеджер. Поэтому всегда стоит быть в курсе того, как устроены процессы, и постоянно думать о том, что в них можно подтюнить. Это больше про проджектовую часть. Если говорить про продуктовую – надо учиться не стесняться задавать вопрос «а зачем мы это делаем». Не во всех командах есть здоровая культура общения продуктового менеджмента с разработкой, поэтому задачи могут прилетать от людей, которых видишь только раз в год на корпоративе. С этим надо бороться. Если продакт и тимлид регулярно общаются – это помогает обоим принимать более качественные решения.
1. Всегда стоит смотреть не только на свои задачи, но и за пределы. Тимлид должен быть драйвером изменений в команде. Если есть амбиции тимлида – нужно учиться подмечать проблемы и точки улучшений, чтобы превращать их в задачи для команды. Разработчик, который помимо своих задач часто приносит какие-то здоровые адекватные инициативы по улучшению качества кода, всегда будет особенно заметен на радаре своего руководителя.
2. Второй скилл очень связан с первым. Нужно учиться смотреть на любые задачи, технологии, рефакторинги и процессы с точки зрения их влияния на продукт в целом. Нужно всегда уметь ответить на вопрос «а зачем я это делаю»? Условно, вот хочу я затащить библиотеку для DI. Если я это делаю, потому что она сейчас в тренде и все авторитеты индустрии выступают на конференциях, рассказывая про нее – это плохой знак. Надо всегда уметь дать максимально внятно оценить соотношение того, сколько сил придется потратить на какое-то действие к тому, какое влияние оно окажет на проект.
3. Нужно учиться общаться и выстраивать культуру общения в команде. Один человек, будь это даже самый матерый тимлид, вряд ли будет так же эффективен при принятии решений, как целая команда. Поэтому стоит задуматься о том, чтобы решение принимала команда. А такую культуру надо развивать и прививать. Недостаточно вбросить вопрос, а потом дождаться от команды ответа. Иногда люди в процессе обсуждения могут нагенерировать новых идей и в итоге запутаться или разругаться. Поэтому тимлид должен уметь фасилитировать такие обсуждения, чтобы с одной стороны создать атмосферу, в которой каждому будет комфортно предложить идею, а с другой – чтобы при отсутствии согласия в команде либо найти компромисс, либо взять на себя ответственность и самому принять решение.
4. Также, во многих компаниях и командах тимлид – это важный партнер менеджера, будь то продакт или проджект-менеджер. Поэтому всегда стоит быть в курсе того, как устроены процессы, и постоянно думать о том, что в них можно подтюнить. Это больше про проджектовую часть. Если говорить про продуктовую – надо учиться не стесняться задавать вопрос «а зачем мы это делаем». Не во всех командах есть здоровая культура общения продуктового менеджмента с разработкой, поэтому задачи могут прилетать от людей, которых видишь только раз в год на корпоративе. С этим надо бороться. Если продакт и тимлид регулярно общаются – это помогает обоим принимать более качественные решения.
Планы на 2020 год
Самое время, чтобы придумать, чем заняться в новом году. Что нельзя пропустить в 2020м? Какие курсы стоит изучить? Что почитать? Какие фильмы посмотреть? Какие приложения скачать? Куда записаться? На какие мероприятия сходить?
Самое время, чтобы придумать, чем заняться в новом году. Что нельзя пропустить в 2020м? Какие курсы стоит изучить? Что почитать? Какие фильмы посмотреть? Какие приложения скачать? Куда записаться? На какие мероприятия сходить?
Итоги 2019
В 2019 году было очень много технологических новостей. Вспомним быстро, бегущей строкой.
Первая фотография чёрной дыры, первая летающая платформа, первый складной смартфон, первые спутники Starlink и первый твит через них же. Microsoft купил GitHub, Kotlin стал основным языком для разработки под Android, все мы глубже погрузились в DevOps, выросла популярность Go. ИИ стал умнее, а киберпанк всё ближе: расплодились нейросети, дипфейки, боты.
Это в мире. В России же всё веселее: Яндекс создаёт, Сбербанк покупает, а Рамблер отжимает.
В 2019 году было очень много технологических новостей. Вспомним быстро, бегущей строкой.
Первая фотография чёрной дыры, первая летающая платформа, первый складной смартфон, первые спутники Starlink и первый твит через них же. Microsoft купил GitHub, Kotlin стал основным языком для разработки под Android, все мы глубже погрузились в DevOps, выросла популярность Go. ИИ стал умнее, а киберпанк всё ближе: расплодились нейросети, дипфейки, боты.
Это в мире. В России же всё веселее: Яндекс создаёт, Сбербанк покупает, а Рамблер отжимает.
Forwarded from 🤖 The Bell Tech
🥂 Друзья, мы поздравляем вас с наступающими праздниками и желаем хорошо отдохнуть! А мы уходим на каникулы до 9 января. Пока нас нет, почитайте итоги года и даже десятилетия для российского интернета:
🔺2019-й во многих отношениях стал кризисным годом: закон о суверенном рунете, кибервойна США и Китая, разочарование инвесторов и невзлетевшие идеи, обещавшие технологические революции. Обо всем этом и о том, что ждет за поворотом — тут.
🔻Рунет за десять лет изменился до неузнаваемости: в 2009 интернетом пользовался 31% россиян, сейчас — почти 80%. Из маргинального пиратского царства российский интернет превратился в место, где можно подать документы на загранпаспорт, а за контент почти привыкли платить. И, конечно, рунетом заинтересовалось государство. Итоги десятилетия — тут.
🔺2019-й во многих отношениях стал кризисным годом: закон о суверенном рунете, кибервойна США и Китая, разочарование инвесторов и невзлетевшие идеи, обещавшие технологические революции. Обо всем этом и о том, что ждет за поворотом — тут.
🔻Рунет за десять лет изменился до неузнаваемости: в 2009 интернетом пользовался 31% россиян, сейчас — почти 80%. Из маргинального пиратского царства российский интернет превратился в место, где можно подать документы на загранпаспорт, а за контент почти привыкли платить. И, конечно, рунетом заинтересовалось государство. Итоги десятилетия — тут.
The Bell
Итоги года в технологиях: политика, деньги, безопасность и наука
Цифровой 2019-й во многих отношениях стал кризисным годом. В России вступил в силу закон о суверенном рунете, США и Китай погрузились в холодную кибервойну, инвесторы разочаровались в стратегии пристраивания арабских миллиардов в западные стартапы, а многие…
Java Марафон 2
Новому джава марафону быть. Про предыдущий можно прочитать здесь — https://yangx.top/java_developer/424. Новогодние праздники выдались продуктивными, и я почти дописал программу марафона. Подробности будут через неделю, когда все начнут выходить из спячки. Кодовое название марафона Java Core Challenge
Новому джава марафону быть. Про предыдущий можно прочитать здесь — https://yangx.top/java_developer/424. Новогодние праздники выдались продуктивными, и я почти дописал программу марафона. Подробности будут через неделю, когда все начнут выходить из спячки. Кодовое название марафона Java Core Challenge
Как быть востребованным разработчиком
Один из самых крутых постов, которые прочитал за прошлый год.
Один из самых крутых постов, которые прочитал за прошлый год.
Forwarded from In Silico
Есть очень хороший способ проверить, готовы ли вы к наступлению будущего: если все компании мира хотят вас нанять и к тому же готовы платить вам бесконечно много денег — вероятно, вы умеете что-то действительно важное. Если никто вас нанимать не хочет, либо хочет, но не слишком уж сильно, — стоит поскорее начать искать точки роста.
В IT-тусовке, к счастью, собралось достаточное количество занудных людей, готовых систематизировать всё подряд. Поэтому и оценку по приведённому выше критерию сделать просто: компании для этого придумали процесс интервью. Разработчиков в большинстве ситуаций проверяют по набору вечных ценностей: алгоритмическому программированию, system design и, опционально, data science. Первые два пункта универсальны и пригодятся любому, а третий, хоть и опционален, востребован до такой степени, что игнорировать его уже невозможно.
Интернет пестрит инструкциями по прохождению секций в те или иные компании, да они и сами не прочь рассказать миру о том, что для них важно. И этим нужно пользоваться! Поэтому я решил взять и помочь вам, собрав свои любимые ссылочки на эти темы.
1. Алгоритмы и программирование
Умение программировать — оно как умение играть на скрипке, требует практики. Если вы прошли пачку алгоритмических курсов и прочитали томик Кормена, совсем не факт, что вам удастся отлично справляться с решением реальных задач. Вы отлично пишете код только тогда, когда пишете его постоянно. Поэтому решение 200 простых задачек на leetcode.com — отличная инвестиция, и именно этим нужно заниматься в первую очередь, если вы хотите освоить программирование с нуля, выучить новый язык, подготовиться к интервью или просто поддержать программистскую форму.
Но, конечно, можно и посмотреть, и почитать. Два моих видео про алгоритмические секции в Яндексе: задача попроще и задача посложнее. Мой же текст на ту же тему на хабре. Стоит иметь в виду инструкцию от Facebook и, конечно же, книжку от leetcode.com.
Но в первую очередь решайте задачки. Много задачек.
2. System Design
Чтобы стать реально высокооплачиваемым специалистом, нужно уметь строить сложные системы.
Эта область очень широка, и для погружения в неё полезно ознакомиться с решением как можно большего количества различных задач. Для этого подходят видеоролики: раз, два, три, четыре, пять, шесть, семь и так далее. После седьмого вы наверняка поймёте, как найти ещё, а заодно станет понятно, какие именно акронимы стоит посмотреть на википедии, да и вообще — что изучать дальше и блоги каких компаний изучить. Смотреть эти ролики намного увлекательнее и уж тем более полезнее, чем смотреть сериальчики! Да и снято их не меньше...
Есть два неплохих гайда, которые точно стоит почитать: hiredintech и interviewbit.com. Их рекомендуют, например, при подготовке к интервью в Facebook. Ну а я готов рекомендовать их и при подготовке к интервью в Яндекс!
3. Data science
В области ML & DS многие совершают ошибку, фиксируя своё внимание только на алгоритмах обработки данных или обучения. В реальных задачах львиную долю сложностей составляют получение формулировки задачи, репрезентативной выборки, первого базового решения и способа правильной приёмки нового метода. Про это я тоже записал ролик и написал текст.
Это широкая область, как и system design и метод подготовки тут тоже похожий. Стоит почитать форумы на kaggle (обсуждения задач), записи Open Data Science с тренировок по машинному обучению и просто посты технологических компаний. Например, наши посты про предсказание запроса пользователя, персонализацию Поиска, алгоритмы Палех и Королёв; в целом хаб машинного обучения на Хабре; посты про AlphaGo, AlphaStar (что первый, что второй) и т.п. тоже подходят, да и вообще у DeepMind отличный блог.
При этом не нужно обязательно быть экспертом по глубокому обучению или, скажем, статистическому ML. Хотя, бесспорно, это очень полезно.
Продолжение следует
#career #interview
Алексей Шаграев
В IT-тусовке, к счастью, собралось достаточное количество занудных людей, готовых систематизировать всё подряд. Поэтому и оценку по приведённому выше критерию сделать просто: компании для этого придумали процесс интервью. Разработчиков в большинстве ситуаций проверяют по набору вечных ценностей: алгоритмическому программированию, system design и, опционально, data science. Первые два пункта универсальны и пригодятся любому, а третий, хоть и опционален, востребован до такой степени, что игнорировать его уже невозможно.
Интернет пестрит инструкциями по прохождению секций в те или иные компании, да они и сами не прочь рассказать миру о том, что для них важно. И этим нужно пользоваться! Поэтому я решил взять и помочь вам, собрав свои любимые ссылочки на эти темы.
1. Алгоритмы и программирование
Умение программировать — оно как умение играть на скрипке, требует практики. Если вы прошли пачку алгоритмических курсов и прочитали томик Кормена, совсем не факт, что вам удастся отлично справляться с решением реальных задач. Вы отлично пишете код только тогда, когда пишете его постоянно. Поэтому решение 200 простых задачек на leetcode.com — отличная инвестиция, и именно этим нужно заниматься в первую очередь, если вы хотите освоить программирование с нуля, выучить новый язык, подготовиться к интервью или просто поддержать программистскую форму.
Но, конечно, можно и посмотреть, и почитать. Два моих видео про алгоритмические секции в Яндексе: задача попроще и задача посложнее. Мой же текст на ту же тему на хабре. Стоит иметь в виду инструкцию от Facebook и, конечно же, книжку от leetcode.com.
Но в первую очередь решайте задачки. Много задачек.
2. System Design
Чтобы стать реально высокооплачиваемым специалистом, нужно уметь строить сложные системы.
Эта область очень широка, и для погружения в неё полезно ознакомиться с решением как можно большего количества различных задач. Для этого подходят видеоролики: раз, два, три, четыре, пять, шесть, семь и так далее. После седьмого вы наверняка поймёте, как найти ещё, а заодно станет понятно, какие именно акронимы стоит посмотреть на википедии, да и вообще — что изучать дальше и блоги каких компаний изучить. Смотреть эти ролики намного увлекательнее и уж тем более полезнее, чем смотреть сериальчики! Да и снято их не меньше...
Есть два неплохих гайда, которые точно стоит почитать: hiredintech и interviewbit.com. Их рекомендуют, например, при подготовке к интервью в Facebook. Ну а я готов рекомендовать их и при подготовке к интервью в Яндекс!
3. Data science
В области ML & DS многие совершают ошибку, фиксируя своё внимание только на алгоритмах обработки данных или обучения. В реальных задачах львиную долю сложностей составляют получение формулировки задачи, репрезентативной выборки, первого базового решения и способа правильной приёмки нового метода. Про это я тоже записал ролик и написал текст.
Это широкая область, как и system design и метод подготовки тут тоже похожий. Стоит почитать форумы на kaggle (обсуждения задач), записи Open Data Science с тренировок по машинному обучению и просто посты технологических компаний. Например, наши посты про предсказание запроса пользователя, персонализацию Поиска, алгоритмы Палех и Королёв; в целом хаб машинного обучения на Хабре; посты про AlphaGo, AlphaStar (что первый, что второй) и т.п. тоже подходят, да и вообще у DeepMind отличный блог.
При этом не нужно обязательно быть экспертом по глубокому обучению или, скажем, статистическому ML. Хотя, бесспорно, это очень полезно.
Продолжение следует
#career #interview
Алексей Шаграев
Про важность коммьюнити
В жизни очень важны знакомства и общение! В профессиональной среде это так же ценно. Реально, нет ни одной специальности, в которой не важно поддерживать связь и состоять в каком-то сообществе с коллегами (даже у таксистов есть свои чаты).
Расскажу про свой опыт: когда проходил первый курс по Джаве, я познакомился с кучей классных ребят со всей России. У каждого из нас своя история, почти все пришли в программирование из других сфер, для кого-то это был первый опыт поиска работы.
Хорошо, что после курса, мы не потерялись, и вовремя поняли, как можем быть полезны друг другу в дальнейшем. У нас организовался чат, который существует до сих пор. Нас больше 30 человек, которые теперь работают в 30 крутых и неочень(Рамблер) компаниях. Конечно же мы делимся друг с другом инсайдами: обсуждаем внутреннюю кухню, зп, собеседования, технологии, проекты в этих компаниях. Это очень помогает!
У меня на памяти несколько примеров, когда ребята в чате узнавали о вакансиях в других компаниях, где тоже работали выпускники наших курсов, и переходили туда на более высокую зп. Такие знакомства помогают решиться на релокацию. Двое парней сейчас работают в Берлине, они также знакомы между собой благодаря чату. Теперь у нас международное коммьюнити. Еще периодически мы устраиваем встречи в Питере и в Москве, это всегда очень шумно и весело!
Поверьте, такие знакомства с единомышленниками из вашей профессиональной среды могут быть также полезны, как и сами курсы/обучения, после которых можно как раз стать частью подобного активного коммьюнити. Не теряйте контакт! И спасибо вам, парни и лейдис из чата выпускников!
В жизни очень важны знакомства и общение! В профессиональной среде это так же ценно. Реально, нет ни одной специальности, в которой не важно поддерживать связь и состоять в каком-то сообществе с коллегами (даже у таксистов есть свои чаты).
Расскажу про свой опыт: когда проходил первый курс по Джаве, я познакомился с кучей классных ребят со всей России. У каждого из нас своя история, почти все пришли в программирование из других сфер, для кого-то это был первый опыт поиска работы.
Хорошо, что после курса, мы не потерялись, и вовремя поняли, как можем быть полезны друг другу в дальнейшем. У нас организовался чат, который существует до сих пор. Нас больше 30 человек, которые теперь работают в 30 крутых и неочень(Рамблер) компаниях. Конечно же мы делимся друг с другом инсайдами: обсуждаем внутреннюю кухню, зп, собеседования, технологии, проекты в этих компаниях. Это очень помогает!
У меня на памяти несколько примеров, когда ребята в чате узнавали о вакансиях в других компаниях, где тоже работали выпускники наших курсов, и переходили туда на более высокую зп. Такие знакомства помогают решиться на релокацию. Двое парней сейчас работают в Берлине, они также знакомы между собой благодаря чату. Теперь у нас международное коммьюнити. Еще периодически мы устраиваем встречи в Питере и в Москве, это всегда очень шумно и весело!
Поверьте, такие знакомства с единомышленниками из вашей профессиональной среды могут быть также полезны, как и сами курсы/обучения, после которых можно как раз стать частью подобного активного коммьюнити. Не теряйте контакт! И спасибо вам, парни и лейдис из чата выпускников!
JAVA CORE CHALLENGE
20 января запускаю Java челлендж для начинающих. Он продлится 4 недели. За это время участники познакомятся со средой разработки, изучат основы Java, научатся избегать типичные ошибки в коде, решат множество задач и получат код ревью. А так же самое ценное – прокачают навыки самостоятельной работы, познакомятся с новыми людьми из будущей профессиональной среды и поймут, куда двигаться дальше.
Акцент сделаем на четырёх важнейших темах, каждой из которой уделим одну неделю, и задачи будем решать соответствующие. План такой:
1. основные типы данных;
2. условные операторы и циклы;
3. строки;
4. массивы.
Цена участия за месяц курса – 990 рублей. Вернуть деньги, если материал покажется вам неподходящим/сложным/лёгким, можно в первые два дня. Количество мест на курсе ограничено.
Позже я расскажу более подробно о том, как будет проходить работа и чего ожидать от курса.
20 января запускаю Java челлендж для начинающих. Он продлится 4 недели. За это время участники познакомятся со средой разработки, изучат основы Java, научатся избегать типичные ошибки в коде, решат множество задач и получат код ревью. А так же самое ценное – прокачают навыки самостоятельной работы, познакомятся с новыми людьми из будущей профессиональной среды и поймут, куда двигаться дальше.
Акцент сделаем на четырёх важнейших темах, каждой из которой уделим одну неделю, и задачи будем решать соответствующие. План такой:
1. основные типы данных;
2. условные операторы и циклы;
3. строки;
4. массивы.
Цена участия за месяц курса – 990 рублей. Вернуть деньги, если материал покажется вам неподходящим/сложным/лёгким, можно в первые два дня. Количество мест на курсе ограничено.
Позже я расскажу более подробно о том, как будет проходить работа и чего ожидать от курса.