Расскажите пожалуйста, как вы следите за соблюдением контракта в Figma, например, чтобы цвет primary внезапно не стал bgPrimary и не поломал имплементацию палитры? Есть ли какая-то автоматизация таких проверок или только договорённости с дизайнерами?
И ещё один вопрос: почему вы выбрали SVG, а не ImageVector из Compose?
Отличная рекомендация, что пет-проект должен в первую очередь быть полезен для автора! Если пользуешься своим продуктом, то появляется больше желания его развивать.
Поделюсь рекомендациями для петпроектов, которым стараюсь следовать:
Определитесь с целью вашего пет-проекта, и от этого стройте приоритет задач, потому что если делать всё и сразу, то с огромной вероятностью забросите проект, не сделав ничего до конца. И наиболее приоритетные задачи вы делаете в начале. Например, вы хотите попробовать AR – сразу начните работу с AR, если вы первые 3 дня будете делать архитектуру или навигацию, то с огромной вероятностью забросите его, так и не добравшись до самого AR.
Следует из предыдущего пункта. Если вы делаете пет-проект для собственного пользования, воспринимайте его как MVP: ваша задача не написать идеальный код, а создать какую-то ценность для пользователя. Если вы будете регулярно пользоваться своим приложением, то у вас будет и мотивация его доработать, но красивое приложение без функциональности вы запустите пару раз и удалите.
Напротив, если ваш проект нужен для демонстрации работодателям, то код должен быть близок к идеалу. Чем делать новую функциональность, лучше покрыть старую Unit- и UI-тестами. Цель такого проекта - показать, как вы бы работали, поэтому и приоритеты должны быть как на рабочем проекте.
Если вы думаете, что ваш проект будет развиваться, то стоит организовать бэклог задач. Заведите доску в трелло, сделайте столбцы todo, in progress, done, добавьте метки для приоритетности задачи и её вида (фича/архитектура/баг/ещё что-то). Это избавит вас от бэклога в голове, и вы не забудете что-то важное.
Соблюдайте гигиену main ветки в гите. Для начала достаточно просто начать работать в отдельных ветках и вливать их при помощи merge request-ов. Это позволит в master держать только актуальный и проверенный код, а в ветках будет код в процессе разработки, который может не компилироваться/падать с ошибкой/работать на стабах вместо данных. А также вам не придется revert-ить множество изменений, если внезапно потребуется сделать другую задачу или вы просто решите, что нынешняя задача вам не нужна.
Отличный вопрос! Да, мы по ходу интервью задаём вопросы по фреймворкам, но из-за незнания какой-то библиотеки не отказываем кандидатам, т.е. знание библиотек - это "дополнительные баллы". Понимание общих подходов и абстракций для нас важнее: новую библиотеку можно быстро освоить, особенно в окружении инженеров, которые готовы помочь. А вот с пониманием концепций ситуация сложнее.
На дистанции инженеры, понимающие абстракции, приносят больше пользы, чем инженеры, хорошо знающие какую-то конкретную библиотеку.
Подробнее расскажу в следующей статье про интервью по системному дизайну :)
Алгоритмическая задача может быть полезной. Например, в конце интервью дать несложную задачу минут на 10-15, чтобы посмотреть, как кандидат подходит к незнакомой проблеме.
Но вот проводить полноценные алгоритмические секции с leetcode medium/hard за пределами бигтех компаний - это палка о двух концах. Нужно объективно оценивать, настолько ли кандидаты заинтересованы в компании, чтобы полгода готовиться к собеседованию.
Некоторые приложения приходят к нам от партнеров, в том числе от агрегаторов. Мы всегда указываем источник на странице приложения. При этом все приложения, опубликованные в RuStore независимо от источника, проходят проверку безопасности и ручную модерацию — мы не допускаем опасный контент в стор.
Спасибо, что поделились опытом!
Расскажите пожалуйста, как вы следите за соблюдением контракта в Figma, например, чтобы цвет primary внезапно не стал bgPrimary и не поломал имплементацию палитры? Есть ли какая-то автоматизация таких проверок или только договорённости с дизайнерами?
И ещё один вопрос: почему вы выбрали SVG, а не ImageVector из Compose?
Отличная рекомендация, что пет-проект должен в первую очередь быть полезен для автора! Если пользуешься своим продуктом, то появляется больше желания его развивать.
Поделюсь рекомендациями для петпроектов, которым стараюсь следовать:
Определитесь с целью вашего пет-проекта, и от этого стройте приоритет задач, потому что если делать всё и сразу, то с огромной вероятностью забросите проект, не сделав ничего до конца. И наиболее приоритетные задачи вы делаете в начале. Например, вы хотите попробовать AR – сразу начните работу с AR, если вы первые 3 дня будете делать архитектуру или навигацию, то с огромной вероятностью забросите его, так и не добравшись до самого AR.
Следует из предыдущего пункта. Если вы делаете пет-проект для собственного пользования, воспринимайте его как MVP: ваша задача не написать идеальный код, а создать какую-то ценность для пользователя. Если вы будете регулярно пользоваться своим приложением, то у вас будет и мотивация его доработать, но красивое приложение без функциональности вы запустите пару раз и удалите.
Напротив, если ваш проект нужен для демонстрации работодателям, то код должен быть близок к идеалу. Чем делать новую функциональность, лучше покрыть старую Unit- и UI-тестами. Цель такого проекта - показать, как вы бы работали, поэтому и приоритеты должны быть как на рабочем проекте.
Если вы думаете, что ваш проект будет развиваться, то стоит организовать бэклог задач. Заведите доску в трелло, сделайте столбцы todo, in progress, done, добавьте метки для приоритетности задачи и её вида (фича/архитектура/баг/ещё что-то). Это избавит вас от бэклога в голове, и вы не забудете что-то важное.
Соблюдайте гигиену main ветки в гите. Для начала достаточно просто начать работать в отдельных ветках и вливать их при помощи merge request-ов. Это позволит в master держать только актуальный и проверенный код, а в ветках будет код в процессе разработки, который может не компилироваться/падать с ошибкой/работать на стабах вместо данных. А также вам не придется revert-ить множество изменений, если внезапно потребуется сделать другую задачу или вы просто решите, что нынешняя задача вам не нужна.
Отличный вопрос! Да, мы по ходу интервью задаём вопросы по фреймворкам, но из-за незнания какой-то библиотеки не отказываем кандидатам, т.е. знание библиотек - это "дополнительные баллы". Понимание общих подходов и абстракций для нас важнее: новую библиотеку можно быстро освоить, особенно в окружении инженеров, которые готовы помочь. А вот с пониманием концепций ситуация сложнее.
На дистанции инженеры, понимающие абстракции, приносят больше пользы, чем инженеры, хорошо знающие какую-то конкретную библиотеку.
Подробнее расскажу в следующей статье про интервью по системному дизайну :)
Алгоритмическая задача может быть полезной. Например, в конце интервью дать несложную задачу минут на 10-15, чтобы посмотреть, как кандидат подходит к незнакомой проблеме.
Но вот проводить полноценные алгоритмические секции с leetcode medium/hard за пределами бигтех компаний - это палка о двух концах. Нужно объективно оценивать, настолько ли кандидаты заинтересованы в компании, чтобы полгода готовиться к собеседованию.
Некоторые приложения приходят к нам от партнеров, в том числе от агрегаторов. Мы всегда указываем источник на странице приложения. При этом все приложения, опубликованные в RuStore независимо от источника, проходят проверку безопасности и ручную модерацию — мы не допускаем опасный контент в стор.