iOS Makes Me Hate
3.94K subscribers
1.17K photos
167 videos
15 files
1.34K links
Авторский канал про iOS разработку. Путь продуктовых самураев в MAANG.

Самое больше iOS сообщество практиков: https://boosty.to/lionbond/

Автор: @lvbond Senior iOS Yandex, ex-Avito, VK
Download Telegram
по поводу собесов

на меня недавно вышел чел в инстаграмме. Говорит: "сам свитчер, хочу прийти в ит и пройти собесы, зарабатывать. Увидел тебя на всяких сайтах обучения, но решил найти тебя в инсте".

Я лично считаю, что в индустрию надо идти по внутреннему самочувствию, а не по внешнему экономическому климату. Но запрос есть запрос.

На фоне запроса решил описать вообще типы собесов. Тут как с билетами. Где-то тебе выпадет легкий, где-то по-серьезней. Побывав на около 60-70 собесов я попробую разделить их на категории.

1. Собес "Жили-Были". Рассказ о том че делал, какие проекты выполнял, как относишься к Путину. Проводится часто в устной форме. Считаю самым легких из всех, ибо проверяется не хард скиллы, а больше софт.

Такие собесы подходят часто для легких проектов.

2. Собес "Ищу программиста для одежды на вырост". Такие собесы проводятся людьми, кто следит за индустрией. Любят спрашивать вчерашнюю статью уже сегодня. Мало кода, много теоритических задач, которые никогда на проекте не встречались, но их почему-то внедрили в программу для собеседований

Такие собесы подойдут для любителей прокачивать технические бренды

3. Собес "Задрот алгоритмов". Ну тут обратная сторона монеты предыдущей категории. Чел нелюбитель общаться в команде и его любимый девиз "программист должен только программировать". Меньше слов — больше действий. Здесь мы будем 3 часа решать задачи с литкода из категории "бог олимпийских игр".

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

Окей. А что же норм? Я думаю, норм — это гибридный вариант

человек должен показать как он пишет код. Как он общается с тимейтами. Какие общие взгляды или наоборот.

Идеальный собес должен тестить как работу в команде, так и исполнительность. Как написание кода (пусть даже стрессовое), так и лидирование задач.

Не знаю, подготовит ли это к конкрентой компании, в конкретное настроение ревьюера. Но лично мне кажется, что этот вариант самый компромиссный
👍7
хорошие писатели должны читать хорошие книги.

поэтому открываю тут такую рубрику разбирать топ контрибьюторов в гитхабе и их проекты.

на первом месте сеульский прогер, который упростил многим жизнь библиотекой then

я честно нелюбитель ни scope фукций котлина. ни подобных самописных расширений в свифт и особого профита в них не вижу.

может у кого-то есть комментарии чем они полезны. интересно узнать почему же либа в топе гитхаба
🔥2
по поводу подготовки

"думай как математик" одна из полезнеших книг по самообразованию вообще. да, я так считаю.

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

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

https://www.ozon.ru/product/dumay-kak-matematik-kak-reshat-lyubye-zadachi-bystree-i-effektivnee-oakli-barbara-254359820/?sh=blZTywAAAA
🔥12
#ЦифраДня: В своем новом рейтинге лучшей работы Glassdoor поставил Enterprise Architect на первое место в США и Java Developer на первое место в Великобритании. Интересная аномалия заключается в том, что, хотя Мобильный Инженер (Mobile Engineer) занимает 12-е место в Великобритании, эта работа даже не входит в число 50 лучших в США. Это может быть связано с относительно низкой заработной платой или с оценкой удовлетворенности менее 4 из 5.
😢8😱1
Forwarded from Product Developer
Продукт vs проект, и в чем разница для разработчика.

Представим проект по постройке дома на заказ. Есть чертежи, есть план работ, сроки. Всё посчитано, всё оптимально. Берешь ресурсы, делаешь по плану, в срок сдаешь дом. Звучит просто.

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

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

Что это значит для разработчика?

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

В продукт постоянно приходят новые разработчики и уходят старые. Ротация кадров для продукта — нормальное явление. Приходя в продукт, надо быть готовым иметь дело с легаси. Потому что оно приносит деньги. И нужно уметь дорабатывать легаси и строить рядом с ним новые направления. И при построении чего-то нового нужно уметь заложить архитектуру и инженерные практики такие, чтобы не испытывать проблем, когда это станет легаси. У продукта нет конца как у проекта, поэтому разработчики имеют дело со своим же легаси через год-два-пять.

Поэтому в продукте так важно «правило бойскаута»:
«оставь место стоянки чище, чем оно было до твоего прихода». Чистка не обязательно должна быть глобальной, достаточно почистить хотя бы небольшой кусок кода, режущий глаз.
© Роберт Мартин
сегодня приснился сон как я работал в нетфликсе (моя компания мечты). поэтому проснувшись я немного причесал свой старый репо с задачами из литкода + сортировки + дата структуры + функции высшего порядка

буду ежедневно пушить туда решения всякие.

road to escape from russia

(скоро сделаю еще по систем дизайну репозиторий)

https://github.com/levabond/Algorithms
👍12🔥3
очень часто встречаю ребят, кто за 6-8 месяцев концептуально и теоретически понимают много крутых вещей, чего не понимали и разрабы с несколькими годами опыта

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

истории замечательные, но не забывайте о продакшен опыте

https://www.youtube.com/watch?v=y-i445LN8Kg
👍2👎1
с бинарного поиска начинаются почти все книги по алгоритмам. но иногда встречал вопрос, а где же его использовать его на практике?

Допустим, в очередной раз приходит менеджер с великолепной таской. Задача: найти быстро загаданное клиентом число. Вы почесав голову спрашиваете "число больше n?". И дальше по понятному многим сценарию. Вместо перечисления каждого числа по-очереди мы делим отсортированный порядок на 2 части и отсекаем лишнее

https://leetcode.com/explore/learn/card/binary-search/
🔥3
но одна из самых интересных задач в бинарном поиске — это поиск в развернутом массиве. На литкоде эта задача сложности медиум. Я не смог решить за час и пошел искать решения в ютубе.

поэтому лучше приступать к ней после уверенного решения хотяб пары изи
🔥2
кстати, тоже одна из практических задач с бинарным поиском — поиск первой невалидной версии апи
тоже не про мобилку, но попробую связать алгоритмы + теорию принятий решений

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

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

https://www.youtube.com/watch?v=hfwIhCNDj6k
👎3👍1
О ритуалах и удаче

Когда я работал в мелких конторах, то видел тотальную неэффективность

Ритуальное соблюдение церемоний превращалось в перебор новых хайповых слов.

Стэндапы и планирования были ежедневными молитвами, которые не выполняли функцию. Это было слепым соблюдением догм священных писем, которые мало кто понимал.

Я буду просто это делать. И быть может создатель вознаградит меня удачей.

Формальное проведение таких церемонии ни к чему не приводило, а скорее просто забирало время.

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

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

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

Шесть признаков перфекциониста:
- Страх провала
- Подход «все или ничего»
- Не умеет делегировать
- Часто прокрастинирует
- Слишком сильно сфокусирован на результате
- Тяжело принимает конструктивную критику

Подробный рассказ про эти шесть признаков и подходы к управлению такими людьми
👍7