Анх АНУ-д мастердаа сурахаар ирж байхад senpai нар байнга interview өгөж бай, маргааш interview өгөөд өөр ажилд ороход бэлэн бай гэхэд нь сайн ойлгодоггүй байж. Санаа нь: чиний авж байгаа цалинг чинь нугалаад өгье, чаддаг юм бол interview-ээ даваад ороод ир гэсэн газрууд зөндөө, энэ АНУ-д, тиймээс байнга л бэлтгэлтэй байвал тэр амлаад байгаа айхтар цалинг нь авч чадна. Үгүй бол одоо байгаадаа сэтгэл хангалуун, levels.fyi or teamblind орж сэтгэлээ унагахгүйхэн шиг явах нь зүйн хэрэг.
Senior Software Engineer-р interview өгөхөд ер нь Junior/Mid level -тэйгээ адилхан бүтэцтэй.
1. Resume-гээ явуулна
(эсвэл Recruiter өөрөө reach out хийнэ.)
2. Recruiter-тэйгээ initial call хийнэ
(цалин пүнлүү, ямар багт ормоор байна, аль хотод очиж ажилламаар байна гэх мэтээ ярьна)
3. Phone Screen хийнэ
(ямаршуу project дээр одоо ажиллаж байгаа, ер нь энэ орох гэж байгаа төсөл нь дажгүй юмуу гэдэг мэдээллээ солилцоно. Дараагаар нь ганц алгоритмын /LC Medium/ бодлого бодно.)
4. Full On-Site явна.
4.1. энэ үе дотроо 4-с 5-н interview авна. Бүтэн өдөр толгойгоо гашилгатал юм болно.
4.2. Junior Mid Level-ээс ганц ялгаа нь 1 эсвэл 2 System Design Interview орж ирнэ.
4.3. Нийтдээ 2-с 3 алгоритм, 1 behavioral, 1-с 2 System Design гэсэн үг.
(Junior/Mid Level-р ажил хайж байгаа бол энэ нийтлэл биш доорхыг уншихад болох байх. Microsoft-д орохдоо хэрхэн бэлдсэнээ бичсэн байгаа: Microsoft-д орохдоо хэрхэн бэлдсэн бэ?
System Design гэдэг үгнээс байнга л айж ирсэн, яагаад ч юм маш хол зүйл шиг л сонсогддог байж билээ, саяханыг хүртэл.
Гол ажилдаа орцгооё, ганц ялгаатай interview нь System Design Interview:
Ер нь бол нэг систем зохио гээдл маш open ended question өгчихөнө. (Instagram хийгээдэх гэдэг ч юмуу) Өөрийнхөө туршлага төсөөллөөр энэ системийн дизайныг гаргаад явчихана гэж бодож байвал аль хэдийн Hard Pass авчихлаа бро.
Энэ interview-ийн хамгийн гол зарчим бол: Do not assume, ask questions and gather requirements.
Instagram нь зураг, видео постоор оруулах, Story оруулах, Reel оруулах, Direct Messaging, Search гэх мэт маш олон функцтэй. Аль хэсэг дээр нь хоёулаа өнөөдөр анхаарч ажиллах вэ? гэх мэт асуултаар эхлээд, хэчнээн хүн хаанаас яаж хандах (traffic constants, DAU, QPS) талаар үргэлжлүүлээд ямар ямар мэдээлэл хадгалах (Database Design, CAP) ёстойгоор өндөрлөж болно. Interview авч байгаа хүнтэйгээ Vibe нийлээд Click болчихвол аясаараа л яваад өгнө.
Ямар өгөгдлийг ямар бүтэцтэйгээр хаана яаж хадгалах вэ?
Ямар api endpoint-ууд байх вэ?
Тэр api endpoint-уудын input/output нь юу байх вэ?
Ямар сервисүүд хаана яаж ажиллах вэ?
гэх мэт энгийн зүйлсүүдэд бол зоолттой хариулна.
-DB Жишээ: зураг, бичлэгнүүдээ blob дээр байршуулна. User Metadata-гаа nosql DB дээр байршуулна ч гэдэг юмуу. Мөн entity-нүүд нь ямар2 field-үүдтэй байх юм мөн өөр table байгаа бол тэрэнтэйгээ хэрхэн уялдах юм гэх мэт. Тайлан report хэрэгтэй бол ямар job/background task ажиллах юм...
-API Жишээ, Rest vs GraphQL байхуу:
GET: 127.0.0.1:8080/api/user?id
Output: {user}
Эхлээд Minimum Viable Product (MVP)-гээ гаргах дээрээ төвлөрөх хэрэгтэй. Хэрвээ MVP-гээ гаргаж байх явцад scale-тэй холбоотой асуултууд асуувал тэрийгээ дараа нь цаг гарвал хариулна/шийднэ гээд тэмдэглээд явах хэрэгтэй. MVP-т юу орох уу гэхээр, юутай ч асуултанд ирсэн function-ууд end-to-end ажилладаг байх ёстой. example flow: Хэрэглэгч өгөгдлөө орууллаа тэр нь DB-д хадгалагдлаа, тайлан тооцоо гарлаа, тэрийгээ харлаа ч гэдэг юмуу. Basic CRUD-ээ хийдэг болцон байх дээр анхаарах хэрэгтэй гэсэн үг.
Эдгээрийн дараа л нөгөө сүртэй2 buzzword-уудруугаа орох нь байна:
1. CAP Theorem - Consistency, Availability, Partition.
You can't always get what you wantBut if you try sometimes, well, you might findYou get what you need
"You can't always get what you want" by Rolling Stones гээд дууны үг энд л санаанд ордог юм. Дээрх гурваас 2-ыг нь л сонгож болно. CA; AP; or CP гэсэн гурваас сонголтоо хийх хэрэгтэй. Бидний мэдэх ихэнх application-ууд CA байдаг. Энэ бичлэг их энгийнээр тайлбарласан шиг санагддаг.
2. CDN - Content Delivery Network.
Гол санаа нь Ази-д байгаа хэрэглэгч хаа байсан АНУ-д байгаа серверрүү хүсэлт явуулах шаардлагагүй. Ази-д байгаа Regional instance-рүүгээ хандаад тэндээ учраа олж, хужраа тунгаана. Azure-н ихэнх бүтээгдэхүүнүүд бүгд regional instance-үүд CDN-ийн ард ажиллаж байдаг.
АНУ-ынхан GEO location-оороо East US, West US, US Central гэх мэт region-руудруугаа явчихна, EU-нхан ч мөн адил хамгийн ойролцоох region-руугаа хүсэлтээ явуулчихна. Одоо дараагийн зүйлсүүд бүгд region дотроо яригдах болно. [NOTE: In some special cases, you have to make a scatter call to all the other regions. One example could be: if you are trying to create a globally unique resource and have to check if the name or id is unique across the globe.]
Энэ нийтлэл нилээн товч тодорхой тайлбарласан санагдсан.
3. Traffice Manager + ILB + VMSS
Эдгээр ойлголтууд нь Region дотроо хүсэлт орж ирсэний дараа яригдана.
-Traffic Manager-ийг switch гээд ойлгочиход болно. Энгийнээр, ирсэн хүсэлтүүдийг энэ IP-руу явуулна эсвэл өөр IP-руу явуулна гэдгийг switch-л хийх зорилготой.
-Load Balancer-ийг бол мэдэж байгаа байх, гэхдээ сэргээхэд: N тооны сервер ажиллаж байлаа гэж саная. Load Balancer нь урдаа нэг PIP-тэй (public ip address), орж ирсэн хүсэлтийг өөрийн тань сонгосон алгоритм-р N тооны сервэрүүд рүү илгээнэ. Хамгийн түгээмэл бас ойлгоход амархан алгоритм нь round robin, хүсэлт ирлээ эхний серверлүү явууллаа, дараагийн хүсэлт ирэхэд хоёр дахьруу явууллаа гэх мэтчилэн тойрог хэлбэрээр явуулна. Load Balancer нь өөрөө бас Health Check-тэй байна, тодорхой хэдэн секунд тутамд N серверүүдлүүгээ Healthprobe явуулна, 2 удаа дарааллан unhealthy response ирвэл unhealthy server гэж үзээд шинээр ирсэн хүсэлтүүдийг тус серверлүү хуваарилахаа болино.
-VMSS- Virtual Machine Scale Set гэсэн үгний товчлол, яадаг вэ гэхээр тодорхой rule зааж өгөөд серверийнхээ instance-ийг автоматаар нэмэх буюу хасах боломжтой. Мөн minimum instance and maximum instance-ээ зааж өгнө. Жишээ нь: Манай апп хамгийн багадаа байнга 2 instance асаатай байна, хамгийн ихдээ 50 instance асааж болно. Харин аль нэг instance-ний CPU usage 80% хүрвэл дараагийн instance-ийг асаана, эсвэл instance-ний CPU usage 20% болвол унтраана, мэдээж minimum instance number-аас илүү бол гэх мэт Rule зоож өгөж болно.
Traffice Manager + ILB + VMSS гэж хэлээд тайлбарлачих юм бол region дотроо хичнээн ч хүсэлт ирсэн handle хийчихэж болох нь. Гэхдээ явж2 нөгөө олон request чинь ямар нэгэн байдлаар өгөгдлийн сантай харьцах хэрэг гарна. (next bottleneck)
4. Caching
Байнга давтагдаж уншигдаад байгаа мэдээллүүдээ олоод cache-лана гээд хэлээдэхвэл хөөрхөн кок болоод явчихна. Өгөгдлийн санруугаа хандахаас өмнө caching заавал шалгах хэрэгтэй (Cache miss, cache hit), тэр тусмаа interview дээр бол. Write through cache, Read through cache (Cache Policy) гэсэн хоёр ойлголт байгаа. Загварчилж байгаа системээсээ хамаараад алийг нь ашиглахаа ярилцаж тохиролцох хэрэгтэй. Хамгийн энгийн, ойлгоход болон хэрэглэхэд амарханаар нь Redis-н талаар дэлгэрүүлж үзээрэй. Энэ бичлэгийг гүйлгэж үзээд нилээн ойлгочихож болно байх.
5. Sharding
Мянга cache-лсан ч тухайн application чинь баазруу өгөгдөл бичнэ эсвэл өгөгдөл уншиж л таарна. CDN тавьцан, Traffic Manager + LB + VMSS хийцэн, дээр нь Caching apply хийлээ ч DB-ээ яах вэ? гэдэг асуулт эцсийн дүндээ гарч ирэх л болно. Үүнийг дараахаар шийдэж болно: Зөвхөн ганц DB-тэй бус N тооны өгөгдлийн сан үүсгэлээ гэж бодъё. Тэгээд дээр нь consistent hashing apply хийгээд баазаас авах хүсэлтүүдээ дараах байдлаар уншиж болно: getConsistentHash(getHash(userId)) үүнээс getHash function нь бол зөвхөн Hash боловсруулах үүрэгтэй. getConsistentHash нь дээрхээс гараад ирсэн Hash нь аль DB instance-д харъялагдах вэ гэдгийг хэлж өгнө. Ингэснээр нэг DB instance нь тодорхой range-ний hash-уудын өгөгдлийг хадгална. Яагаад дахиж нэг layer нэмээд байгаа вэ гэвэл: DB instance-ээ нэгээр нэмэх (N+1) эсвэл нэг DB instace-ээ tear down (N-1) хийхэд маш бага ажил хийх болно. Бас энэн дээрээ нэмээд Read-Only DB, and Write-Only DB гэсэн бүтэц оруулж өгч илүү complex болгоод явж болно. Мэдээж ачаалал ихсэх тусам write-only DB instance-ээ нэмээд явж болно. Гэхдээ энэ нь N тооны instance бүр дээрээ read only + write only гэсэн бүтцээ нэмнэ гэсэн үг. Илүү ихийг ОРИ-гоос.
5 газар system design interview (Amazon, Meta, LinkedIn, Workday, Oracle) өгч, хоёроос нь ажлын санал авсан туршлагаас харахад тухайн interview авч байгаа хүн юу хүсэж байна вэ? гэдгийг мэдрэх нь чухал санагдсан. Зарим хүн scale хэрхэн хийх вэ дээр их анхаарч байхад зарим нь яг дата нь яаж flow хийх вэ дээр анхаардагч юмуу эсвэл хаанаас ямар репорт гаргах вэ? гэдэг дээрээ их анхаардаг ч гэдэг юмуу.
Microsoft-д манай баг шинэ бүтээгдэхүүн (Azure Orbital) хөгжүүлж байсан учраас маш олон brown bag sessions, design discussions болдог байсан. Энэ нь ч System Design-ий interview-ийг давахад маш их хэрэг болсон гэж бодож байна. Design meeting-д ороодл лаг лаг юм яриад байдгүүмаа гэхэд адаглаад сонсоод passive learning хийж байх нь маш том дэм болно. Бас компани чинь wiki-тэй бол тэрнээс хэрэгтэй юмнуудаа сайн уншиж байгаарай.
Thumbnail дээр байгаачлан Oracle компанийн үүлэн технологи болох Oracle Cloud Infrastructure-н Cloud Security багт Senior Software Engineer-ээр Bay Area-д ажиллахаар болсон. Finally in the Silicon Valley!
Microsoft -> Oracle
Azure -> OCI
C# -> Java
IC2 -> IC3
East Coast -> West Coast
"Манай энэ ч юм мэддэг хүний хажууд ичмээр дамшигдаа" гэмээр юм бичсэн байхвийдээ лол.
DAU- Daily Active Users
QPS- Query Per Second
LB- Load Balancer
ILB- Internal Load Balancer
VMSS- Virtual Machine Scale Set
VM- Virtual Machine
PIP- Public IP
CDN- Content Delivery Network
MVP- Minimum Viable Product
CRUD- Create, Read, Update and Delete
.png){kind=link}