Лига программистов
Пересмотри своё собеседование
В статьях про собеседования часто говорят о пользе обратной связи после интервью. Беда в том, что компании нечасто дают обратную связь. Вы получаете либо оффер, либо отписку в духе "извините, но вы нам не подходите".
Вы можете быть отличным специалистом. Вы можете потратить тонну времени на изучение нового материала, щёлкать задачи с leetcode, знать теорию и практику прохождения собесов. Но один небольшой аспект может всё испортить. Держитесь неуверенно? Путано излагаете мысли? Пропускаете ключевые детали, в результате чего изложение выглядит рваным и несвязным? Зависаете при ответе на вопрос?
В случае онлайн-собеседований у вас есть уникальная возможность посмотреть на себя со стороны. Запишите всё: аудио, видео со своей камеры и монитор с собеседником. На Linux для записи экрана удобен Kazam.
По видеозаписи вы сможете выявить свои косяки, которые совершенно не заметны без взгляда "со стороны". Кроме того, вы можете словить реакцию собеседующего на ваши ответы. В процессе интервью сделать это сложно — мозг занят другими вопросами.
После прохождения интервью просмотрите запись и выявите систематические ошибки. Легко сказать — выявить ошибки. На деле совсем не просто найти проблемы в своём же интервью.
Хорошим вариантом будет получить мнение со стороны. Попросите друзей посмотреть вашу запись свежим взглядом и подметить проблемы. Прямо по пунктам, где и что не так.
Все полученные замечания нужно критически обработать. Проанализируйте и проработайте каждый пункт, чтобы не повторить ту же ошибку в будущем. Сформулируйте список проблем, которые нужно поправить.
При анализе следующего интервью сверяйтесь со списком проблем. Всё ли получилось исправить?
По результатам просмотра двух первых интервью мои злые друзья нашли 36 проблемных мест. В результате их проработки я сформулировал десяток конкретных пунктов как надо делать и как делать не надо.
Запишите своё следующее интервью и проработайте его. Вы удивитесь, как много нового можно узнать.
Желательно спросить разрешение противоположной стороны на видеозапись. С другой стороны, если вы не планируете запись публиковать, то требуется ли разрешение?
В телеграм-канале DevFM пишу о полезном для разработчика: инструментах, например, Raycast, или об архитектурных схемах, или записываю видео разного уровня, например, для начинающих по FastAPI + Docker. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике, немного подкастов и видео. Вливайся!
Мое - ГолыйAdmin123
не ставлю мое потому что перевел с реддита
ООП. Вспомнить всё
Мэтт Вайсфельд "Объектно-ориентированный подход". Автору удалось осветить в этой книге практически все темы, касающиеся ООП, и сделать это всего лишь на 250 страницах (!): разбор принципов ООП на примерах, рекомендации по проектированию классов, извечный вопрос применимости множественного наследования, разбор принципов SOLID с внятными примерами и даже паттерны! Притом качество и глубина изложения материала не пострадала. Книгу можно читать как новичку, так и разработчику с опытом. Новичок получит в ней ценные ориентиры для дальнейшего углубленного изучения ООП, разработчику с опытом книга поможет упорядочить свои знания или подготовиться к ООП-нагруженному собеседованию.
Технические посты тут t.me/neverending_cpp
Как вкатиться в АйТи: личный опыт
Все ваши курсы — это фигня. Надо взять простой советский Дворец Пионеров году так в 86-м прошлого века и попросить маму, чтобы она отвела вас на ёлку.
А на ёлке вы смогли бы увидеть чудо инженерной мысли — приставку "Видеоспорт-М". Для нас, не избалованных детей СССР, которые только грезили игрой "Ну, погоди!", это был невиданный суперкомпьютер. В тот год я прозрел и понял, чего я хочу, навсегда.
На следующий год я летел на ёлку как на ракете, однако приставок больше не появилось.
Вспомнилось, как однажды взял "Ну, погоди!" в аренду на неделю за ведро карасей, которых я ловил целый день. Целую неделю радости, но 1000 очков так и не набрал, так что мультик не посмотрел :)
Мечта обзавестись подобной приставкой тихо тлела до тех времён, пока более старший сосед Олег не организовал компьютерный клуб с десятью компьютерами ZX-Spectrum.
Я тогда ещё не знал, что такое оргазм, но сейчас понимаю, что испытывал тогда нечто схожее в эмоциональном плане и куда более долговременное. А то, что это можно было продлять по 5 копеек за минуту, вообще выдвигало те эмоции на куда более сильный уровень, нежели оргазм.
Все летние каникулы проходили в режиме: добыча мелочи, сдачей стеклотары и прочей макулатуры, и трата заработанного за ЭЛТ-монитором.
Позже Олег прикрыл эту чудесную лавочку и занялся видеосалоном, как делом более прибыльным. Однако те месяцы окончательно сформировали мой будущий путь в АйТи. Спасибо, Олег.
К сожалению, к окончанию школы я не смог найти вменяемого заведения для обучения этим вашим компьютерам. Однако тяга к радиоэлектронике, которую подтверждал разобранный дома, но тем не менее рабочий телевизор "Рекорд", привела меня в ГПТУ от радиозавода, где обещали научить меня чинить телевизоры и эти ваши компьютеры. Также обучению там способствовал одноклассник Иван, от которого я и узнал об этом замечательном заведении, в коем мы с Ваней и проучились 4,5 года. Спасибо, Ваня.
Особая благодарность моей любимой и, увы, ушедшей бабушке, которая заняла денег у соседки, чтобы я смог купить детальки и спаять свой первый компьютер — ZX-Spectrum. Спаять получилось, когда научился читать схемы и понимать, что куда идёт и какая деталька чем занимается. Это я осилил к окончанию второго курса.
Незадолго до этих событий попал мне в руки австралийский рекламный журнал, где был невероятный IBM PC 286 за 2000$. Спектрум, конечно, скрашивал мой досуг и досуг всех моих друзей часами напролёт, но я теперь хотел PС.
Играть было очень интересно, но гораздо интереснее было то, как эти игры работают, как они устроены, как сделать себе бесконечные жизни или мегапушку. Игры пошли под нож — те, что были на Бейсике. Не было никаких книжек, был только Бейсик Спектрума и знание английского на уровне понимания, что может значить то или иное слово. Кстати, об английском: текстовые квесты на Спектруме изрядно его подтянули.
Но помимо Бейсика была ещё тайна. Некоторые игры состояли из одной строчки:
`randomize poke 65535` или что-то похожее, сейчас уже не вспомню. Это было великой тайной. Тайна была приоткрыта сокурсником, который сказал, что это непосредственный запуск Ассемблера, на котором написана игра, а число — это адрес в памяти, с которого код начинается.
Таким образом это позволило мне найти на рынке и приобрести две синие книжки: "Программируем на Ассемблере Z-80".
Возможно, из-за этого не увидела свет моя первая игра на Бейсике. Это был средневековый симулятор путешественника по поселениям в Африке. Впрочем, Бейсик очень долго пересчитывал экономику поселений после каждого хода. Но вот Ассемблер обещал многое.
Продолжение следует...
Ответ на пост «Сравнение классической системы образования и самообучения: как мы учимся "пить чай"»1
Теория дает понимание. Практика дает навык. Есть много областей, где можно набить руку и работать. Но понимание ещё ни разу не мешало. А в некоторых случаях без него никуда. Понимания можно добиться своими силами, но это тяжелее, и надо как раз курить теорию. А по некоторым вещам учебников вообще нет, так что там только сам. Но. ВУЗ дает ещё и кругозор: понимание что там как у соседа.
Если ты гений-супергерой, учись сам как хочешь, тебе и советы не нужны. Нормальным же людям нужен ВУЗ. Потому что даст кругозор, даст понимание твоего и смежных предметов, заставит выучить то, что нужно. И да, ВУЗа мало! Нужно сверх того учиться самому в ВУЗе и всю жизнь после. Таков путь.
Шпаргалка по git patches
Пост может дополняться и изменяться🙂
Патч - это текстовый файл, который содержит код и (необязательно) метаданные коммита. Патчи используются в некоторых проектах, например, в Linux Kernel и самом Git. Или в командах, которые работают над форками одного и того же open source продукта, но имеют изолированные репозитории.
Создание патча
Создать патч с не закомиченными изменениями:
git diff > <name>.patch
Создать патч только с проиндексированными, но не закомиченными изменениями:
git diff --cached > 0001_fix.patch
Создать патч для последнего коммита:
git format-patch -1
Создать патчи для всех коммитов, сделанных после последних N коммитов:
git format-patch HEAD~<число>
Создание патча для изменений между двумя коммитами:
git diff <commit1> <commit2> > 0001_commit_diff.patch
Применение патча
Применить патч и не создавать коммиты:
git apply 0001-fix.patch
Применить патч и создать коммиты. Работает, если патчи были созданы с помощью git format-patch:
git am 0001-fix.patch
Применить все патчи сразу можно только с помощью git am. Патчи должны быть пронумерованы в порядке применения и должны храниться в одной директории:
git am *.patch
Конфликты при наложении патчей
В случае использования git apply конфликты разрешаются вручную, процесс также продолжается вручную.
В случае использования git am конфликты разрешаются вручную. После исправления конфликтов процесс можно продолжить:
git am --continue
или прервать:
git am --abort
Технические посты тут t.me/neverending_cpp
Сравнение классической системы образования и самообучения: как мы учимся "пить чай"1
Образование – важная часть жизни, и подходы к нему могут кардинально различаться. Давайте рассмотрим классическую систему образования и самообучение на необычном примере – обучении пить чай.
Классическая система образования: теория без практики
В классической системе обучения процесс структурирован и разделён на этапы. Учебный план состоит из последовательного изучения всех аспектов. Например:
Что такое ложка?
На протяжении двух часов изучаются её форма, история изобретения, виды материалов. На экзамене нужно назвать 5 типов ложек и их основные отличия.Что такое кружка?
Ещё три часа посвящаются описанию конструкции кружки, материалов, из которых она изготавливается, а также её роли в культуре и быту.Как нагревается вода?
Ещё несколько часов обсуждаются различные способы кипячения воды, устройство чайника, безопасность обращения с кипятком.
И так далее. Через два года такой учёбы студент узнаёт массу интересных фактов о чае, кружках, чайниках и ложках, но… пить чай он, возможно, так и не начнёт. Почему? Потому что практика откладывается на потом, а теория часто бывает избыточной.
Самообучение: учимся на ошибках
В самообучении всё иначе. Человек сразу переходит к делу:
Попытка номер один: наливаем кипяток, обжигаем руку, понимаем, что горячее нужно наливать аккуратнее.
Попытка номер два: насыпаем сахар руками прямо в чашку. Половина пролетает мимо. Учимся искать ложку.
Попытка номер три: пробуем чай и обжигаем губы. Узнаём, что стоит подождать, пока он немного остынет.
Через несколько дней таких ошибок и проб человек уже уверенно пьёт чай три раза в день. Он может не знать научного названия процесса нагревания воды или всех видов ложек, но его цель – пить чай – достигнута.
Результаты: теория против практики
Классическая система:
После двух лет обучения студент знает множество определений, частично забывает изученное и… часто разочаровывается. Он так и не начинает пить чай, потому что считает это сложным и неудобным.Самообучение:
Человек, который начал пробовать сразу, уже пьёт чай регулярно. Более того, освоив чай, он переходит на кофе. А "классический" ученик теперь спрашивает у него: "Как ты научился пить кофе?"
В ИТ и особенно в программировании, лучше работает второй вариант. Уж счету нет людям которые прошли курсы, и не могут на собесе написать простой кусочек кода, потому что теорию и практику в вакууме им дали, а вот самому нафигачить системку, поднять сервак, написать прикольный код, запилить игру они не умеют :-(