В прошлую субботу выступал в качестве спикера в Белграде на IT-митапе по софт скилам (@belgradeitmeetups). Тема: "behavior собеседования на западном рынке".
Основные тезисы:
1. CV - упор на Achievements вместо Responsibilities
2. English - основная причина провала технарей из СНГ на собеседованиях в иностранные компании
3. Необходимо мыслить с точки зрения вашего value для компании, а не с точки зрения какой вы классный или классная и сколько задачек вы успеваете делать.
По-моему эти три пункта отвечают за 20% усилий и 80% успеха с точки зрения поведенческой оценки кандидата с рынка СНГ для западных компаний. Более того - вчерашнее обсуждение этой темы с моим проджект менеджером из США подтвердило эти тезисы.
В следующих постах раскрою подробнее каждый пункт.
Основные тезисы:
1. CV - упор на Achievements вместо Responsibilities
2. English - основная причина провала технарей из СНГ на собеседованиях в иностранные компании
3. Необходимо мыслить с точки зрения вашего value для компании, а не с точки зрения какой вы классный или классная и сколько задачек вы успеваете делать.
По-моему эти три пункта отвечают за 20% усилий и 80% успеха с точки зрения поведенческой оценки кандидата с рынка СНГ для западных компаний. Более того - вчерашнее обсуждение этой темы с моим проджект менеджером из США подтвердило эти тезисы.
В следующих постах раскрою подробнее каждый пункт.
CV - Responsibilities vs Achievements
Какое же основное отличие резюме для западного рынка и резюме с рынка СНГ? Из моего опыта - это упор на достижения вместо описания зоны ответственности. Особенно удручающе выглядят фразы типа “написание кода”, “исправление багов”, “проведение код ревью” - это похоже на “ответсвенный, коммуникабельный стрессоустойчивый, легкообучаемый” что, конечно, является огромным клише. Итак, вместо “разработка функционала” лучше написать “реализовал рекоммендательную систему, которая увеличила прибыль на 40%”. Вместо “оптимизация кода” лучше написать “оптимзировал главную страницу на 200 мс, что улучшило конверсию на 30% и сэкономило на оборудовании 20%”. Вместо “проведение код ревью” лучше написать “внедрил автоматический процесс проверки качества кода который экономит 20 человекочасов разработчиков IT-департамента еженедельно”. Так уж сложилось что на западном рынке не смотрят на, что специалист делал ежедневно, Намного важнее, чего он достиг и как он поможет бизнесу зарабатывать больше денег. В конце концов зарабатывать деньги - и есть цель любого бизнеса.
Бонусом же к такому подходу в составлении CV будет и то, что и на рынке СНГ такое CV не выглядит чужим. Оно выглядит нормально для западных компаний и свежо для компаний рынка СНГ.
Какое же основное отличие резюме для западного рынка и резюме с рынка СНГ? Из моего опыта - это упор на достижения вместо описания зоны ответственности. Особенно удручающе выглядят фразы типа “написание кода”, “исправление багов”, “проведение код ревью” - это похоже на “ответсвенный, коммуникабельный стрессоустойчивый, легкообучаемый” что, конечно, является огромным клише. Итак, вместо “разработка функционала” лучше написать “реализовал рекоммендательную систему, которая увеличила прибыль на 40%”. Вместо “оптимизация кода” лучше написать “оптимзировал главную страницу на 200 мс, что улучшило конверсию на 30% и сэкономило на оборудовании 20%”. Вместо “проведение код ревью” лучше написать “внедрил автоматический процесс проверки качества кода который экономит 20 человекочасов разработчиков IT-департамента еженедельно”. Так уж сложилось что на западном рынке не смотрят на, что специалист делал ежедневно, Намного важнее, чего он достиг и как он поможет бизнесу зарабатывать больше денег. В конце концов зарабатывать деньги - и есть цель любого бизнеса.
Бонусом же к такому подходу в составлении CV будет и то, что и на рынке СНГ такое CV не выглядит чужим. Оно выглядит нормально для западных компаний и свежо для компаний рынка СНГ.
English
Много раз собеседовался в иностранные компании и получил несколько инсайдов из западных же компаний по поводу главных причин отказа ребятам из России. Несложно догадаться - это уровень английского. Большинству технически сильных кандидатов отказывают из-за низкого уровня коммуникации - для мидловых, а особенно сеньорных ролей, это критически важный момент. Причем такой фидбек и дают: "кандидат технически крутой, но коммуникация это труба, как потом с ним взаимодействовать?". С кандидатами из других стран это проблема намного менее ярко выражена.
Причина? Так уж исторически сложилось, что в русскоговорящем сегменте было много проектов нацеленных на внутренний рынок и много своих кандидатов, потому что русскоговорящий рынок это 250 миллионов культурно похожих и близко проживающих людей. Т.е. всегда можно найти что-то на своем рынке и нет необходимости учить язык. Европейские страны такого свойства были лишены поэтому там уровень знания английского сильно выше.
Что делать, если хотите работать на западном рынке? Учите английский.
Много раз собеседовался в иностранные компании и получил несколько инсайдов из западных же компаний по поводу главных причин отказа ребятам из России. Несложно догадаться - это уровень английского. Большинству технически сильных кандидатов отказывают из-за низкого уровня коммуникации - для мидловых, а особенно сеньорных ролей, это критически важный момент. Причем такой фидбек и дают: "кандидат технически крутой, но коммуникация это труба, как потом с ним взаимодействовать?". С кандидатами из других стран это проблема намного менее ярко выражена.
Причина? Так уж исторически сложилось, что в русскоговорящем сегменте было много проектов нацеленных на внутренний рынок и много своих кандидатов, потому что русскоговорящий рынок это 250 миллионов культурно похожих и близко проживающих людей. Т.е. всегда можно найти что-то на своем рынке и нет необходимости учить язык. Европейские страны такого свойства были лишены поэтому там уровень знания английского сильно выше.
Что делать, если хотите работать на западном рынке? Учите английский.
В новой компании в слаке есть канал #insights куда падают feature-реквесты от пользователей и куда кидают результаты опроса-фидбека по поводу причин почему пользователь начал или прекратил пользоваться услугами компании.
Очень нравится быть намного ближе к пользователям и возможность тут же обсудить их идеи с коллегами, а может и забрать что-то в беклок. Сразу начинаешь и по своим небольшим задачам понимать необходимсть / пользу / критичность.
Очень нравится быть намного ближе к пользователям и возможность тут же обсудить их идеи с коллегами, а может и забрать что-то в беклок. Сразу начинаешь и по своим небольшим задачам понимать необходимсть / пользу / критичность.
Value
И наконец, третье отличие рекрутингового процесса на западе и СНГ-рынка - это ориентация на ценности (или value). По сути эта ориентация в процессе интервью позволит не просто пройти интервью, но и получить позитивную, а зачастую и восторженную, обратную связь от менеджеров. В самом примитивном варианте value - количество заработанных для компании денег, т.е. в процессе интервью показывайте сколько денег сэкономлено или заработано в прошлых компаниях и сколько заработаете для этой. Более продвинутый вариант - это почитать на сайте о ценностях компании и излагать опыт и умения с точки зрения ценностей для конкретной компании. Но последним мерилом ценности и полезности все равно являются деньги, поэтому деньги - универсальная метрика, которая помогает компании оценивать профессионалов. Если доказать, что будете приносить компании $30к, то можно легко просить обоснованную зарплату в $10к.
И наконец, третье отличие рекрутингового процесса на западе и СНГ-рынка - это ориентация на ценности (или value). По сути эта ориентация в процессе интервью позволит не просто пройти интервью, но и получить позитивную, а зачастую и восторженную, обратную связь от менеджеров. В самом примитивном варианте value - количество заработанных для компании денег, т.е. в процессе интервью показывайте сколько денег сэкономлено или заработано в прошлых компаниях и сколько заработаете для этой. Более продвинутый вариант - это почитать на сайте о ценностях компании и излагать опыт и умения с точки зрения ценностей для конкретной компании. Но последним мерилом ценности и полезности все равно являются деньги, поэтому деньги - универсальная метрика, которая помогает компании оценивать профессионалов. Если доказать, что будете приносить компании $30к, то можно легко просить обоснованную зарплату в $10к.
Запостил новую статью про то как делать какие-то прикидки насколько быстро или долго может выполняться тот или иной запрос:
https://hackernoon.com/how-to-make-rough-estimates-of-sql-queries
Но конечно все равно такие вещи сводятся к мониманию архитектуры баз данных, а еще глубже - к знанию как работает железо.
https://hackernoon.com/how-to-make-rough-estimates-of-sql-queries
Но конечно все равно такие вещи сводятся к мониманию архитектуры баз данных, а еще глубже - к знанию как работает железо.
Hackernoon
How to Make Rough Estimates of SQL Queries | HackerNoon
To do estimates of SQL queries we need to understand how DB works with queries. Let's find out what exactly the db do with queries.
Недавно дошло, почему у меня в целом редко бывают рутиные задачи в обычной деятельности, хотя почти на каждом рекрутинговом интервью спрашивают "А как ты относишься к рутиным задачам?".
Дело в том, что суть любого программиста - это автоматизировать рутину. И вот буквально каждый мой рабочий момент, где я сталкиваюсь с рутиной или местом, где мне нужно скопипастить сотни, а то и тысячи строк, чтоб добавить функциональность/фичи, я начинаю искать как же это можно автоматизировать или унифицировать и как-то само собой рутиная задача превращается в интересный челлендж "как же сделать правильно то, что не сделали до тебя другие". И почти всегда можно найти ошибки в дизайне / проектировании / идее, которые привели к появлению рутины в том месте, где этого можно было избежать или создать инструмент чтоб твои заказчики/пользователи сами с помощью инструмента решали свои рутиные хотелки.
Помните об этой возможности каждый раз когда получаете рутиную задачу. Рутина - это не для тех, кто не умеет в программирование и архитектуру.
Дело в том, что суть любого программиста - это автоматизировать рутину. И вот буквально каждый мой рабочий момент, где я сталкиваюсь с рутиной или местом, где мне нужно скопипастить сотни, а то и тысячи строк, чтоб добавить функциональность/фичи, я начинаю искать как же это можно автоматизировать или унифицировать и как-то само собой рутиная задача превращается в интересный челлендж "как же сделать правильно то, что не сделали до тебя другие". И почти всегда можно найти ошибки в дизайне / проектировании / идее, которые привели к появлению рутины в том месте, где этого можно было избежать или создать инструмент чтоб твои заказчики/пользователи сами с помощью инструмента решали свои рутиные хотелки.
Помните об этой возможности каждый раз когда получаете рутиную задачу. Рутина - это не для тех, кто не умеет в программирование и архитектуру.
Dependency Inversion для процессов разработки
Представьте, что у вас есть команда, отвечающая за бекофис банка. У вас есть несколько сотен тысяч клиентов, с которыми периодически что-то происходит - у кого-то баг, кому-то что-то не привезли, кто-то решил закрыть аккаунт. Выделена команда, которая реализует бекофисную "очередь запросов" требующую от менеджеров вовлечения - аппрув чего-либо, расширение лимитов, ревью из-за подозрения в мошенничестве или отмывании денег, запрос документов и т.д.
Команда может быть загружена на 100% реализацией каждого вида запроса - нужно делать серверную интеграцию, фронтенд часть, отображение информации и т.д. Но что если посмотреть на эту задачу с другой точки зрения? Можно создать инструмент для создания таких фич для других команд и сервисов, чтоб они сами регистрировали новые типы кейсов, требующих ревью менеджеров, и сообщали в наш сервис коллбек поинт с вариантами возможных действия для решения кейса.
Таким образом, мы можем развернуть зависимость и создать инструмент для других инженерных команд. Другие команды знают детали своих серверов сильно лучше и могут эффективнее и быстрее интегрировать свои бизнес процессы самостоятельно. Нужно лишь дать им несколько эндпоинтов. А бекофисная команда может сфокусироваться на создании и апгрейде самого инструмента и применении своих сил для других, не рутинных, дел.
Короче, такой "продуктовый DI" в конце концов изменяет процессы разработки и повышает эффективность работы и этой команды и других. Не стоит зацикливаться на реализации каждой отдельной фичи, лучше создать инструменты, которые позволят другим командам интегрировать свои сервисы самостоятельно.
Представьте, что у вас есть команда, отвечающая за бекофис банка. У вас есть несколько сотен тысяч клиентов, с которыми периодически что-то происходит - у кого-то баг, кому-то что-то не привезли, кто-то решил закрыть аккаунт. Выделена команда, которая реализует бекофисную "очередь запросов" требующую от менеджеров вовлечения - аппрув чего-либо, расширение лимитов, ревью из-за подозрения в мошенничестве или отмывании денег, запрос документов и т.д.
Команда может быть загружена на 100% реализацией каждого вида запроса - нужно делать серверную интеграцию, фронтенд часть, отображение информации и т.д. Но что если посмотреть на эту задачу с другой точки зрения? Можно создать инструмент для создания таких фич для других команд и сервисов, чтоб они сами регистрировали новые типы кейсов, требующих ревью менеджеров, и сообщали в наш сервис коллбек поинт с вариантами возможных действия для решения кейса.
Таким образом, мы можем развернуть зависимость и создать инструмент для других инженерных команд. Другие команды знают детали своих серверов сильно лучше и могут эффективнее и быстрее интегрировать свои бизнес процессы самостоятельно. Нужно лишь дать им несколько эндпоинтов. А бекофисная команда может сфокусироваться на создании и апгрейде самого инструмента и применении своих сил для других, не рутинных, дел.
Короче, такой "продуктовый DI" в конце концов изменяет процессы разработки и повышает эффективность работы и этой команды и других. Не стоит зацикливаться на реализации каждой отдельной фичи, лучше создать инструменты, которые позволят другим командам интегрировать свои сервисы самостоятельно.
Через пару недель вместе с замечательной @xuyanet планируем провести стрим с обсуждением IT рыночка и в качестве бонуса разберём и покритикуем несколько резюмешек. Если хотите чтоб ваша резюмешка попала в разбор - кидайте мне в личку, самые типовые ошибки обсудим, а самые интересные CVшки разберём на стриме.
На прошлой неделе схлестнулись мы с коллегами по одной теме о том, как же правильно писать компоненты на React, я из-за некоторых болячек пересмотрел подходы к базовому паттерну в проекте и имплементировал кое-что попроще (с моей точки зрения), но коллегам не нравилось это, хотя альтернативы были хуже и экстремальнее (с моей точки зрения). А их только одна небольшая деталь в общем-то не устраивала, но как ее сделать правильно ни я, с 6 месяцами опыта на реакте, ни кто-нибудь из них не втыкали. Вот так и просидели 4 мидло-сениора три часа на коле ничего не решив и только проспорив про подходы.
А на следующий день я вместе с ChatGPT обсудил проблему, рассказал ему чего там у меня в компонентах и он показал на примере как можно упростить мою штуку. Коллеги сказали "Да, это подходит".
А выводов пока что не будет. Вот посоветую только интересную статью как тот самый Т9 доэволюционировал до ChatGPT: https://thebell.io/evolyutsiya-neyrosetey-ot-t9-do-chatgpt-obyasnyaem-na-prostom-russkom-kak-rabotayut-yazykovye-modeli
А на следующий день я вместе с ChatGPT обсудил проблему, рассказал ему чего там у меня в компонентах и он показал на примере как можно упростить мою штуку. Коллеги сказали "Да, это подходит".
А выводов пока что не будет. Вот посоветую только интересную статью как тот самый Т9 доэволюционировал до ChatGPT: https://thebell.io/evolyutsiya-neyrosetey-ot-t9-do-chatgpt-obyasnyaem-na-prostom-russkom-kak-rabotayut-yazykovye-modeli
The Bell
Эволюция нейросетей от Т9 до ChatGPT. Объясняем на простом русском, как работают языковые модели
НАСТОЯЩИЙ МАТЕРИАЛ (ИНФОРМАЦИЯ) ПРОИЗВЕДЕН И РАСПР
Начал все больше использовать ChatGPT. Всякие рутиные задачи он конечно классно снимает, например тут для генерации таблицы для статьи.
Интересно ли вам читать для кейсы использования ChatGPT?
Anonymous Poll
77%
да
23%
нет, надоело уже из каждого утюга
Fill Factor для РСУБД
Fill Factor — это параметр, определяющий, какой процент каждого блока данных базы данных будет использоваться для операций вставки (INSERT). Оставшееся пространство будет использоваться для операций обновления (UPDATE). Это означает, что если в том же блоке имеется свободное пространство, строка будет перезаписана в тот же блок, что в свою очередь не потребует пересчета индекса.
Для некоторых паттернов нагрузки на таблицу, например, если ваша таблица часто получает запросы по определенному индексу (не первичному) и возвращает более одной строки, а также имеет много запросов на обновление отдельных записей, установка Fill Factor ниже 100% позволит хранить часто запрашиваемые данные вместе, избегая фрагментации. В результате, это приведет к уменьшению случайных чтений (Random Reads) с диска и увеличению процента последовательного чтения.
Применяя Fill Factor и команду CLUSTER в одном из моих недавних экспериментов на продакшен-базе на сервере Google Cloud SQL, мне удалось ускорить выполнение критических запросов в ~1000 раз для наиболее сложных сценариев. Конечно, все зависит от характера нагрузки на таблицы, но у меня сложилось ощущение что это может вылечить многие сложные случаи.
Fill Factor — это параметр, определяющий, какой процент каждого блока данных базы данных будет использоваться для операций вставки (INSERT). Оставшееся пространство будет использоваться для операций обновления (UPDATE). Это означает, что если в том же блоке имеется свободное пространство, строка будет перезаписана в тот же блок, что в свою очередь не потребует пересчета индекса.
Для некоторых паттернов нагрузки на таблицу, например, если ваша таблица часто получает запросы по определенному индексу (не первичному) и возвращает более одной строки, а также имеет много запросов на обновление отдельных записей, установка Fill Factor ниже 100% позволит хранить часто запрашиваемые данные вместе, избегая фрагментации. В результате, это приведет к уменьшению случайных чтений (Random Reads) с диска и увеличению процента последовательного чтения.
Применяя Fill Factor и команду CLUSTER в одном из моих недавних экспериментов на продакшен-базе на сервере Google Cloud SQL, мне удалось ускорить выполнение критических запросов в ~1000 раз для наиболее сложных сценариев. Конечно, все зависит от характера нагрузки на таблицы, но у меня сложилось ощущение что это может вылечить многие сложные случаи.
Снова про ChatGPT
В последнее время так получилось что я работаю с фронтендом и много пишу на React/TypeScript. До начачала использования ChatGPT я просто полагался на свой большой опыт в бекенде, некоторые интуитивные штуки и гуглеж. Но сейчас ИИ стал прям постоянным бадди который четко отвечает на вопросы, помогает писать некоторые куски кода, скидывает мне примеры, описывает плюсы и минусы разных подходов. По моим ощущениям продуктивность изучения технологии, эффективность реально ощутимо выросли. Изначально было и про выросшее качество кода но тут видел в тви ссылку на исследование что ИИ приводит к понижению качества кода, так что тут еще посмотрим :) субъективно - растет, объективно - не знаю.
Это вот то самое пресловутое "рост производительности труда". Как писали умные люди - к безработице это не приведет, но приведет к необходимости переучиваться, еще большему количеству новых рабочих мест, и росту среднего благосостояния.
Наскринил рандомных мест из диалога для примера (появятся в комментариях к посту). Это по сути я в новой для себя технологии занимаюсь архитектурными делами + одновременно изучаю эту самую технологию и докапываюсь до всяких непонятных мне деталей. А этих непонятных деталей в каждой новой технологии всегда полно.
Так что если вам не хватает ментора - за 20 долларов в месяц его легко сейчас найти :)
Скоро еще сделаю пост с различными хаками которые помогают работать с ИИ эффективнее.
В последнее время так получилось что я работаю с фронтендом и много пишу на React/TypeScript. До начачала использования ChatGPT я просто полагался на свой большой опыт в бекенде, некоторые интуитивные штуки и гуглеж. Но сейчас ИИ стал прям постоянным бадди который четко отвечает на вопросы, помогает писать некоторые куски кода, скидывает мне примеры, описывает плюсы и минусы разных подходов. По моим ощущениям продуктивность изучения технологии, эффективность реально ощутимо выросли. Изначально было и про выросшее качество кода но тут видел в тви ссылку на исследование что ИИ приводит к понижению качества кода, так что тут еще посмотрим :) субъективно - растет, объективно - не знаю.
Это вот то самое пресловутое "рост производительности труда". Как писали умные люди - к безработице это не приведет, но приведет к необходимости переучиваться, еще большему количеству новых рабочих мест, и росту среднего благосостояния.
Наскринил рандомных мест из диалога для примера (появятся в комментариях к посту). Это по сути я в новой для себя технологии занимаюсь архитектурными делами + одновременно изучаю эту самую технологию и докапываюсь до всяких непонятных мне деталей. А этих непонятных деталей в каждой новой технологии всегда полно.
Так что если вам не хватает ментора - за 20 долларов в месяц его легко сейчас найти :)
Скоро еще сделаю пост с различными хаками которые помогают работать с ИИ эффективнее.
Сидел сейчас рефакторил очередной сложный кусок и интересная мысль пришла в голову:
Написание чистого кода требует чистой головы. А чтоб ваш разум был чист в процессе работы - он не должен быть забит знаниями о том, как будут работать те или иные вызовы на 4 уровнях абстракции ниже или выше. Чем большим количеством текущего контекста забита голова, тем меньше места остается на непосредственную текущую задачу.
Я люблю писать красивый и чистый код, и наверное поэтому я постоянно пытаюсь все упростить до максимального состояния :) и именно доведение каждого слоя приложения до самостоятельного независимого состояния в итоге и приводит к тому что очень легко становится с ним разбираться и не нужно "знание" о том как работает другой уровень, чтоб внести изменения на текущем.
Написание чистого кода требует чистой головы. А чтоб ваш разум был чист в процессе работы - он не должен быть забит знаниями о том, как будут работать те или иные вызовы на 4 уровнях абстракции ниже или выше. Чем большим количеством текущего контекста забита голова, тем меньше места остается на непосредственную текущую задачу.
Я люблю писать красивый и чистый код, и наверное поэтому я постоянно пытаюсь все упростить до максимального состояния :) и именно доведение каждого слоя приложения до самостоятельного независимого состояния в итоге и приводит к тому что очень легко становится с ним разбираться и не нужно "знание" о том как работает другой уровень, чтоб внести изменения на текущем.
Завтра залейтайте к нам на стрим! :) мы немного изменили планируемую тему с рекрутинговой на ИИшную но надеюсь это будет более интересно :)
Forwarded from ROSLOVETS: Product, Startup, IT
Как использовать GPT-4
😐 Создание контента: 📝 От создания блогов до составления привлекательных подписей в социальных сетях, GPT-4 кардинально меняет подход к созданию контента.
😐 Персонализированное образование: 🎓 ИИ-репетиторы на базе GPT-4 могут предоставлять индивидуализированные пути обучения, определяя сильные и слабые стороны каждого ученика. Это позволяет предлагать настроенные уроки, упражнения и обратную связь, чтобы помочь студентам справиться с их уникальными трудностями и преуспеть в учебе.
😂 Перевод языков. Ну тут все понятно.
🎮Игровая индустрия: GPT-4 может помочь создать погружающиеся и динамичные сюжеты, генерируя диалоги и взаимодействия персонажей, которые кажутся более реалистичными и интересными.
🔥🔥🔥🔥Ну а мы тем временем готовим эфир совместно с Андреем Сундуковым, адептом чистого кода, Senior-разработчиком американской компании Step Mobile про то, как мы используем GPT-4. Андрей использует его как программист каждый день, я как не программист))
Поговорим про:
- как использовать GPT-4 эффективно
- какие ежедневные задачи может закрыть ИИ
- мои кейсы и кейсы Андрея, как мы их использовали и что из этого вышло
🚀🤖 Раскрываем сценарии использования в прямом эфире завтра 1 апреля в 11.00 по Москве по ссылке! 🤖🚀
PS: вступление и вот этот реплаенный пост сгенерированы GPT)))
🎮Игровая индустрия: GPT-4 может помочь создать погружающиеся и динамичные сюжеты, генерируя диалоги и взаимодействия персонажей, которые кажутся более реалистичными и интересными.
🔥🔥🔥🔥Ну а мы тем временем готовим эфир совместно с Андреем Сундуковым, адептом чистого кода, Senior-разработчиком американской компании Step Mobile про то, как мы используем GPT-4. Андрей использует его как программист каждый день, я как не программист))
Поговорим про:
- как использовать GPT-4 эффективно
- какие ежедневные задачи может закрыть ИИ
- мои кейсы и кейсы Андрея, как мы их использовали и что из этого вышло
🚀🤖 Раскрываем сценарии использования в прямом эфире завтра 1 апреля в 11.00 по Москве по ссылке! 🤖🚀
PS: вступление и вот этот реплаенный пост сгенерированы GPT)))
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Заменит ли ChatGPT программистов? Обсуждение использования нейросети с Senior разработчиком
🔥 Запишись на курсы для инженеров, подними свою квалификацию на новый уровень: https://inzhenerka.tech/?utm_source=youtube_marybrenly
Канал Андрея в телеграмме https://t.me/developers_mind
Кто не слышал про ChatGPT? Какие возможности есть у нейросети,…
Канал Андрея в телеграмме https://t.me/developers_mind
Кто не слышал про ChatGPT? Какие возможности есть у нейросети,…
по мотивам использования ChatGPT написал в итоге статью с кучей рабочих скриншотов, читать тут:
https://ru.hexlet.io/blog/posts/chatgpt-kak-instrument-programmista
https://ru.hexlet.io/blog/posts/chatgpt-kak-instrument-programmista
Хекслет
8 полезных функций ChatGPT для программиста
Рассказываем, как разработчик с помощью ChatGPT может упростить себе работу и стоит ли вообще доверять нейросети писать код.