помощь с теоретическим дизайном integration / application design

Ну да, нагуглить такое врядли получится с ходу. Такое интервью покажет насколько ты опытный разработчик и способен руководить разработкой проекта с нуля. Куда-то на руководящую должность собрался?

И не думаю что здесь есть какое-то обобщенное решение на что намекают упоминая "Can be salesforce or not salesforce related". Просто ты должен рассказать как ты сядешь с нуля запилишь апликейшен и интеграцию. Для первого случаю - если не SF то какой стек технологий / фреймворк ты выберешь, как организуешь дата модель, как запилишь авторизацию/права доступа, придумаешь UI. Во второму случае нужно проявить себя в качестве эксперта по API. Будет ли это третья система которая объединит две по API или будешь использовать возможности одной из систем (SAP/MDM). Какие проблемы/лимиты возможно.

В принципе ничего нового я не написал, а просто перевел своим языком то что у тебя написано в требованиях.

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

Короче задачи - как ты можешь разработать детальное ТЗ на проект. Попробуй поискать инфу по порядку составления похожих ТЗ. Может будет полезно.

спасибо, кое какую инфу почерпнул.
Я более менее разбираюсь да, это всё задачи в выполнимых пределах, просто для меня это интервью довольно важнО и сложно самому понять где надо подкачаться

если бы это была руководящая должность я бы интересовался вопросами типа
"как мне подстроить стиль управления под компанию"
а так все технчиеское :)

Если ты готовишься к SF CTA, то первая задача более-менее знакома.

Практика подготовки к CTA показывает, что для application design нет никаких специальных материалов (я не нашел, может кто найдет), все строится на:

(1) твоих технических знаниях,
(2) практическом опыте,
(3) здравом смысле и
(4) навыках презентации проектов (что само по себе отдельный скил).

я согласен что найти прямо прямой материал сложно, это я уже выяснил. На сэйлсфорс есть неплохой https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_intro_overview.htm но он не все вопросы покрывает
информация выше это то что мне выдал рекрутер. это 2 этапа, еще 2 кодинг
https://www.linkedin.com/jobs/view /1749515974/
(информация что я тут указал - относится к public info, и NDA только на конкретные задачи)

Андрей

Application design. 45 min. Criteria: able to see big picture / identify individual components
Single canonical design question : build application from scratch. Example: Design a ticketing system. Design something more

Это классика, а Application design пилил почти все выходные, потом было 20 минут славы ревью

Очень радует на собесах по Salesforce начили спрашивать нормальные вопросы....

Den Brown

что для application design нет никаких специальных материалов

Вы че бля серьезно.... меня удивляет что вас это удивляет...

Андрей

Design a ticketing system

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

Андрей

это 2 этапа, еще 2 кодинг
https://www.linkedin.com/jobs/view /1749515974/

Круто. Тоже апплаился сюда, но, видимо, из-за того что нужен Visa Sponsorship, пришел автоматический отказ. Как апплаился на эту позицию?

темка скатилась не туда куда мне хотелось бы любой help с конкретными примерами appreciated

понятное дело что я загуглил "design a ticketing system" и просмотрел и system design и OOP design (которые 2 разных типа задач). Чего я не нашел так это application design. Я не совсем понимаю чем application design будет отличаться от system design в данном контексте особенно.

EvAzi

Андрей

это 2 этапа, еще 2 кодинг
https://www.linkedin.com/jobs/view /1749515974/

Круто. Тоже апплаился сюда, но, видимо, из-за того что нужен Visa Sponsorship, пришел автоматический отказ. Как апплаился на эту позицию?

загугли сколько резюме получает гугл в день
или попробуй угадать сколько индусов с 10+ лет опыта которым нужен visa sponsorship подались на эту вакансию в день ее открытия
приехать таким способом подаваясь в интернете сразу в гугл нереально на мой взгляд.... нужно както выделяться + чтобы именно на тебя обратили внимание. И под выделяться я имею ввиду не сертификат, а чтото на уровне популярного технического блога или популярного репо на гитхабе. В гугл проще попасть получив сначала работу в другом офисе и уже оттуда перевестись в США (тогда можно делать L визу а не H1)
гугл кстати давно уменьшил h1 выдачу, причем изначально идея была что прекратят вообще кому либо делать

Андрей

загугли сколько резюме получает гугл в день
или попробуй угадать сколько индусов с 10+ лет опыта которым нужен visa sponsorship подались на эту вакансию в день ее открытия
приехать таким способом подаваясь в интернете сразу в гугл нереально на мой взгляд.... нужно както выделяться + чтобы именно на тебя обратили внимание.

Последний оффтоп: именно поэтому и спросил у тебя, как получил инвайт на интервью.

А по теме - как мне кажется, судя по сути вопроса, это будет стандартное дизайн-интервью от FAANG-like компаний. Можешь взглянуть здесь https://docs.google.com/document/d/1RwFFqTSQpPJRnFgpIK_gzXkb52aIDHKAX4sZphqiYUo/edit , особенно п. 5, возможно, будет то что нужно.

По System integration, как мне кажется, лучше использовать salesforce-based интеграцию, т.к. есть ограниченный набор API.

Кроме этого, навскидку, никаких вещей не подскажу.

EvAzi

По System integration, как мне кажется, лучше использовать salesforce-based интеграцию, т.к. есть ограниченный набор API.

это не мой выбор. Было бы логично чтобы дали 1 сэйлсофорс и 1 не сэйлсфорс между application и integration designs? но это мое предположение. Рекрутер сказал может быть и то и то.

я подавался через internal reference 3 года назад. Отказали с формулировкой "маловато достижений". Через 2 года сами позвонили я им отказал, потому что доделывал гринкард и не мог менять работу. Получается звонили по той же старой подаче, откуда им моё новое резюме иметь то. Еще через год снова позвонили и вот сейчас общаемся.

Андрей

Чего я не нашел так это application design.

потому что надо не cидеть...) это патерны проектирования есть патерны интеграции так же отдельная тема,по всем темам написаны большие книги, а книги типо Force.com Enterprise Architecture или ссылка выше Андрея, это переработанная и урезаная версия книг по проектированию с описанием фич и особенностей Salesforce. И Вопросы там типо чем Фабричный метод отличается Абстрактной Фабрики.

по-моему

Андрей

Application design. 45 min. Criteria: able to see big picture / identify individual components

это очень очень далеко от

Sergey Prishchepa

чем Фабричный метод отличается Абстрактной Фабрики

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

Den Brown

на таких презентациях никакие основы ООП спрашивать не будут, твои упорные разговоры про программирование будут предательски выдавать в тебе хорошего программиста

Чертовски согласен!

Den Brown

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

По Иронии судьбы неделю назад проходил интервью на Техникал Архитекта, всё что их интересовало ООП и шаблоны проектирования с учето ограничений SalesForce и UML....

Den Brown

в тебе хорошего программиста, а им то нужен хороший архитект...

Боюсь спроисть что в твоем понимании Архитектор.

Den Brown

чем Фабричный метод отличается Абстрактной Фабрики

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

Sergey Prishchepa

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

Мля, в шею гнать надо таких архитекторов. Как только кто-то на проекте такой умный появляется этому проекту пиздец. Уже не раз видел. А так же видел как команды вздыхали свободно когда таких архитекторов сваливали из компании . Не надо мешать людям работать всякими этими высооуровневыми абстракциями. Сейчас работую в небольшой python команде которая просто берет и пилит простые вещи без всякой этой высооруровневой ООП херни и шаблонов проектирования. Одно удовольствие работать - код чистый как слеза младенца, и понятный любому жуну который приходит на проект. Короче из многолетнего опыта могу сказать одно - кто умеет программировать, тот программирует, кто не умеет, тот читает книжки про всякую ООП херню

Dmitry Shnyrev

Короче из многолетнего опыта могу сказать одно - кто умеет программировать, тот программирует, кто не умеет, тот читает книжки про всякую ООП херню

Жаль только что бабла платят больше таким любителям попиздеть
(никого лично не имею в виду, это у меня собирательный образ архитектора в голове сформировался)
Уже ни раз видел как опытнейшие многолетние разрабы позиционируют себя как Developer (хотя имеют кучу топовых сертификатов) и тихо сидят пилят код, и видел как на проект залетают на пару месяцев Архитекторы, наводят кучу хороха, тратят время радрабов и потом сваливают не найдя отклик в коллективе

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

Dmitry Shnyrev

Мля, в шею гнать надо таких архитекторов. Как только кто-то на проекте такой умный появляется этому проекту пиздец.

Вот это я хотел услышать:) Дима любит когда много одинакового кода :). Могу только сказать что за последнию неделю пока готовил тествое задание, для себя очень четко понял, что некоторые задачи без высокого уровня абстракции просто не решить,с точки зрения расширяемости кода. Сейчас еще понял одну проблему Архитекторов донести свои идеи до разработчиков правильно

Sergey Prishchepa

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

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

Sergey Prishchepa

Сейчас еще понял одну проблему Архитекторов донести свои идеи до разработчиков правильно

Проблема Архитекторов не в том что они не могу донести свои идеи, а в том что в мире идей для архитектуры море. кучи методологий, кучи паттернов ООП, кучи абстракций. И нет единственного верного решения для архитектуры. Каждый архитектор продвигает только те идеи которые он зазубрил и считает верными. А это не правильно. Если Архитекторы такие умные, то чего они сами не создают крутые проекты шедевры, а только прыгают по компаниям и наводят неразбериху в клиентских проектах?

Dmitry Shnyrev

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

Как же ты прав!

Вот так и живем! :)

это позиция разраба я уже скидывал ссылку выше. Просто кое-кто может себе позволить перебирать лучших из лучших.

насчет архитектора - _частично_ задача архитектора даже и состоит в том чтобы вставлять палки в колеса. Но это надо делать очень очень грамотно. Плохой архитект может навредить больше чем плохой разраб. Хороший архитектор с одной стороны замедляет а с другой ускоряет за счет того что во первых ясно дает понять что делать и разграничивает зоны ответственности, во вторых полтима не отвлекается на постоянные production issues, и не фиксят по одному рекорду изза сломаного процесса или изза того что ктото задеплоил код без ревью.

я работаю сейчас с 30 сэйлсфорс разрабами на одном проекте, у нас 8мб кода в орге и я вам скажу что после определенного количества человек и уровня развития орга без архитектора хоть с какимто идеями просто никуда. Начинается такая анархия которую даже невозможно описать, можно спокойно тратить каждый день половину рабочего времени просто чтобы выяснить кто уронил тесты в nightly build в тест энваерменте.
ктото должен ходить на всякие митинги с другими системами и рассказывать что можно сделать в сэйлсфорсе а что нельзя и пытаться не приносить функционал в сэйлсфорс который там не должен быть потому что ERP тоже не хочет его имплементить.
а ооп дизайн это не про архитекторов, во всяком случае не в сэйлсфорсе

Андрей

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

Поддерживаю.

давайте тогда разделим Архитектов на две группы:

(1) Solution Архитект

Это самый массовый тип Архитектов, и самый востребованный. Они работают в консалтинг компаниях (кто помогает клиентским компаниям переводить бизнес процессы на СФ). Его задача проста и всегда одинакова: минимальными усилиями доставить максимум результата. Что такое "минимальные усилия"? Это крайне слабая команда из джунов разрабов, BA and QA (других либо просто нет, либо нет на них денег), и, как всегда, сжатые сроки. Что такое "максимум результата"? Это непрерывная экспансия: каждые три месяца новый проект, переводи на СФ все что возможно, высылай чеки на оплату клиенту! В таких условиях залог успеха- максимальное использование возможностей платформы, при этом создаваемые приложения на 90% основаны на стандартном функционале платформы. И соответствено требования к архитекту: максимальное знание платформы, умения общаться с клиентами на человеческом языке и техническо-предпринимательская жилка.

Именно такие нужны самому СФ и именно в таком ключе проходит CTA экзамен: не технические знания, а способность их использовать (и презентовать, и убедить, и показать джунам как сделать, и самому сделать самую сложную часть).

(2) Сугубо технический Архитект.

Встречаются в продуктовых конторах или на больших клиентах с очень разросшимся оргом, там где действительно есть "глубина" у кастомного функционала. Руководство фактически вынужденно иметь таких технических Архитектов, так без них уже не разрулить работу в Орге или Продукте, но как именно эти архитекты делают свою работу, руководcтво фактически не волнует. Just make it work.

Если кратко, Solution Архитект знает как грамотно решить проблемы руководства, а технический Архитект знает как грамотно решить свои собственные програмистские проблемы.

для топик-стартера: смотри что за компания, и в какую группу попадает вакансия, так и готовся.

Андрей

Темы заранее предопределены и я хочу просто на максимум подготовиться.

Напиши потом, по результату, успешно ли прошел интервью.
Возможно, стоит https://outtalent.com/ написать, это экс разрабы гугла, помогают за деньги кандидатам попасть в FAANG компании, в том числе, готовят к интервью. Думаю, есть и другие компании такого типа.

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

Насчет интервью - только общие детали
В основном дизайн задачи конечно требуют опыт. Чем больше задизайнил тем проще. Лично у меня были ТОЛЬКО SFDC-связанные задачи, может повезло, может у всех так. Очень много времени убил на подготовку к не сэйлсфорсу а этого не было. Вообще было довольно просто, гораздо проще чем я думал, на всех этапах.
из почитать кроме ссылок выше еще рекомендую детально пройтись по всем схемам отсюда
https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_erd_majors.htm

Андрей

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

Поздравляю! Можешь кратко рассказать про этапы собеса? Были ли всеми нелюбимые задачки на алгоритмы?

EvAzi

Андрей

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

Поздравляю! Можешь кратко рассказать про этапы собеса? Были ли всеми нелюбимые задачки на алгоритмы?

этапы - phone call screening
on site (virtual) - 5 rounds - 2 coding, 1 application design, 1 integration design, 1 behavioral (Googliness)

да, была 1, но почемуто на phone call
я так понимаю что может попасться и в обычном но мне не попалась
на самом деле это простые задачи. Я сел за 2 мес подготовки дошёл до того что могу решить leetcode hard, а leetcode medium могу решить в ограниченное время чтобы осталось на доп вопрос. Но ничего такого лично мне не пригодилось и близко. С другой стороны здорово заставил голову снова работать, когда сел за это дело не мог заставить себя 5 минут сфокусироваться на easy задачах. Расслабился.

работаю я теперь в GCP - google cloud
формально офис в Саннивейле, но опять же, в офис я ориентировочно попаду в следующем году
дали мне L4 application developer, кому интересно levels.fyi - очень близко к правде
L5 это уже tech lead/team lead - пока не дотянул, хотят опыт в FAANG и т.д. Я не стал давить чтобы сходу дали L5, но вроде бы можно было, даже не знаю к чему бы привело.
так что все еще есть над чем работать, буду теперь пытаться получить L5. А так работать в гугле это конечно как мечта детства, воспринимается что толково устроился и конечная работа, дальше особо лезть некуда.

Мои поздравления! Молодец!!! Приятно слышать что земляк вырос до такого уровня!!!

Поздравляю! не терял времени на карантине!

Поздравляю!

Андрей

дальше особо лезть некуда.

Да ладно, всегда есть куда стремиться:)

Андрей

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

Поздравляю. Всего хорошего на новом месте!

wilder

Да ладно, всегда есть куда стремиться:)

Ага, пусть потом открывает свою компанию-конкурента гугл

вот еще свеженькие темы, которые предлагают повторить к серьезному Technical интервью на СФ архитекта:

Hands on Dev

MDM

Tech Governance

Den Brown

Hands on Dev, Tech Governance

Интересно что подразумевают под этим.
MDM - если я правильно помню, что нужно всегда выстраивать системы в таком виде, чтобы источник правды в данных был один. Т.е. есть Система1, Система2, СистемаN, SFDC, во всех них лежат данные по одному и тому же клиенту, где-то они пересекаются(например, Email, Name, уникальный Id), где-то они уникальные для системы. Не всегда пересекающиеся данные совпадают в системах. Возникает проблема, что не понятно, где правильные данные, а где нет. MDM как раз решает эту проблему, основная идея - есть СистемаХ, в которой всегда хранятся правильные и актуальные данные, другие системы должны считать СистемуХ источником правды и забирать данные оттуда.

EvAzi

Den Brown

Hands on Dev, Tech Governance

Интересно что подразумевают под этим.
MDM - если я правильно помню, что нужно всегда выстраивать системы в таком виде, чтобы источник правды в данных был один. Т.е. есть Система1, Система2, СистемаN, SFDC, во всех них лежат данные по одному и тому же клиенту, где-то они пересекаются(например, Email, Name, уникальный Id), где-то они уникальные для системы. Не всегда пересекающиеся данные совпадают в системах. Возникает проблема, что не понятно, где правильные данные, а где нет. MDM как раз решает эту проблему, основная идея - есть СистемаХ, в которой всегда хранятся правильные и актуальные данные, другие системы должны считать СистемуХ источником правды и забирать данные оттуда.

упрощенно так и есть, но MDM как Master data management это целая дисциплина. Если у тебя 1 отдельная система которая мастер для всей информации это просто хороший случай
например у тебя может быть одна система мастер отвечающая за информацию по аккаунтам (откуда приходит инфа), сэйлсфорс мастер для Opportunity информации (где вы ведете сделки до продажи) и какойнибудь ERP мастер для квот и финансовых транзакций (где вы ведете учет денег и высланного товара). Ну и MDM это дисциплина которая помогает найти ответы на вопрос как это сделать.