Menü

SDET Mülakat Soruları ve Cevapları (Tam Kılavuz)

sdet interview questions

Sorunları Ortadan Kaldırmak Için Enstrümanımızı Deneyin

Formatı ve çeşitli turlarda sorulan SDET Mülakat Sorularının nasıl yanıtlanacağını öğrenmek için Test Görüşmelerinde Yazılım Geliştirme Mühendisine yönelik bu eksiksiz kılavuzu okuyun:

Bu eğitimde, SDET rolleri için sıkça sorulan bazı mülakat sorularını öğreneceğiz. Ayrıca, genel olarak, görüşmelerin ortak modelini göreceğiz ve görüşmelerde mükemmelleşmek için bazı ipuçları paylaşacağız.

Bu eğiticinin kodlama problemleri için Java dilini kullanacağız, ancak SDET eğitimlerinin çoğu dilden bağımsızdır ve görüşmeciler genellikle adayın kullanmayı seçtiği dil konusunda esnektir.

SDET Mülakat Soruları ve Cevapları

Ne öğreneceksin:

SDET Mülakat Hazırlık Kılavuzu

En iyi ürün şirketlerinin çoğunda SDET görüşmeleri, geliştirme rolleri için görüşmelerin gerçekleştirilme şekline oldukça benzer. Bunun nedeni, SDET'lerin ayrıca geliştiricinin bildiği hemen hemen her şeyi genel olarak bilmesi ve anlamasının beklenmesidir.

Farklı olan, SDET görüşmecisinin değerlendirildiği kriterlerdir. Bu rol için görüşmeciler, eleştirel düşünme becerilerinin yanı sıra, görüşülen kişinin kodlama konusunda uygulamalı deneyime sahip olup olmadığını ve kalite ve ayrıntıya dikkat edip etmediğini araştırır.

İşte bir SDET görüşmesi için hazırlanan birinin büyük ölçüde odaklanması gereken bazı noktalar:

krom için iyi açılır pencere engelleyici
  • Çoğu zaman, bu görüşmeler teknoloji / dilden bağımsız olduğu için, adaylar gerektiğinde ve gerektiğinde yeni teknolojiler öğrenmeye (ve mevcut becerilerden yararlanmaya) istekli olmalıdır.
  • Günümüzde SDET rolleri, birden çok paydaşla çeşitli düzeylerde iletişim ve işbirliği gerektirdiğinden, iyi iletişim ve ekip becerilerine sahip olmalıdır.
  • Farklı sistem tasarımı kavramları, ölçeklenebilirlik, eşzamanlılık, işlevsel olmayan gereksinimler vb. Hakkında temel bir anlayışa sahip olmalıdır.

Aşağıdaki bölümlerde, bazı örnek sorularla birlikte Mülakatın genel formatını anlamaya çalışacağız.

Test Görüşmesinde Yazılım Geliştirme Mühendisinin Formatı

Şirketlerin çoğu, bir SDET rolü için adaylarla görüşme yapmak için tercih ettikleri formata sahiptir, çünkü rol bir takıma çok özeldir ve kişinin işe alındığı takıma mükemmel bir şekilde uyması beklenir.

Ancak, görüşmelerin teması genellikle aşağıdaki noktalara dayanmaktadır:

  • Telefonla tartışma: Yönetici ve / veya ekip üyeleri ile genellikle bir eleme turu olan görüşme.
  • Yazılı tur: Test / test kasasına özel sorularla.
  • Kodlama yeterlilik turu: Basit kodlama soruları (dilden bağımsız) ve adayın üretim düzeyinde kod yazması istenir.
  • Temel geliştirme kavramlarının anlaşılması: OOPS Kavramları, SOLID İlkeleri vb. Gibi
  • Test Otomasyon Çerçevesi tasarımı ve geliştirme
  • Komut dosyası dilleri: Selenyum, Python, Javascript vb.
  • Culture Fit / HR tartışması ve müzakereleri

SDET Mülakat Soruları ve Cevapları

Bu bölümde, SDET rolleri için çalışan çoğu ürün şirketi tarafından sorulan farklı kategoriler için bazı örnek soruları ayrıntılı yanıtlarla birlikte tartışacağız.

Kodlama Yeterliliği

Bu turda, tercih edilen dilde yazmak için basit kodlama problemleri verilir. Burada görüşmeci, kodlama yapılarındaki yeterliliği ölçmenin yanı sıra uç senaryolar ve boş kontroller gibi şeyleri ele almak istiyor.

Bazen görüşmeciler, yazılan program için birim testleri de yazmayı isteyebilirler.

Bazı örnek problemlere bakalım.

S # 1) 3. (geçici) değişkeni kullanmadan 2 sayıyı değiştirmek için bir program mı yazıyorsunuz?

Cevap :

İki sayıyı değiştirmek için program:

public class SwapNos { public static void main(String() args) { System.out.println('Calling swap function with inputs 2 & 3'); swap(2,3); System.out.println('Calling swap function with inputs -3 & 5'); swap(-3,5); } private static void swap(int x, int y) { System.out.println('values before swap:' + x + ' and ' + y); // swap logic x = x + y; y = x - y; x = x - y; System.out.println('values after swap:' + x + ' and ' + y); } }

İşte yukarıdaki kod pasajının çıktısı:

output-swap2nos 8 yeni 1

Yukarıdaki kod parçacığında, görüşmecinin özellikle üçüncü bir geçici değişken kullanmadan 2 numarayı değiştirmeyi istediğini belirtmek önemlidir. Ayrıca, çözümü göndermeden önce her zaman en az 2-3 giriş için kodun üzerinden geçmeniz (veya prova çalıştırmanız) önerilir. Pozitif ve negatif değerleri deneyelim.

Pozitif değerler: X = 2, Y = 3

// swap logic - x=2, y=3 x = x + y; => x=5 y = x - y; => y=2 x = x - y; => x=3 x & y swapped (x=3, y=2)

Negatif değerler: X = -3, Y = 5

// swap logic - x=-3, y=5 x = x + y; => x=2 y = x - y; => y=-3 x = x - y; => x=5 x & y swapped (x=5 & y=-3)

S # 2) Bir sayıyı ters çevirmek için bir program mı yazıyorsunuz?

Cevap: Şimdi sorun ifadesi başlangıçta korkutucu görünebilir, ancak görüşmeyi yapana sorular sormak her zaman akıllıca olacaktır (ancak çok fazla ayrıntı değil). Görüşmeciler sorunla ilgili ipuçları vermeyi seçebilirler, ancak aday çok fazla soru sorarsa, bu aynı zamanda adayın sorunu iyi anlamak için yeterli zaman vermediğini de gösterir.

Burada sorun, adayın da bazı varsayımlarda bulunmasını bekliyor - Örneğin, sayı bir tam sayı olabilir. Giriş 345 ise, çıkış 543 olmalıdır (345'in tersi)

Bu çözüm için kod pasajına bakalım:

public class ReverseNumber { public static void main(String() args) { int num = 10025; System.out.println('Input - ' + num + ' Output:' + reverseNo(num)); } public static int reverseNo(int number) { int reversed = 0; while(number != 0) { int digit = number % 10; reversed = reversed * 10 + digit; number /= 10; } return reversed; } }

Girişe karşı bu program için çıktı : 10025 - Beklenen : 52001

output-reverseNumber 6 yeni

S # 3) Bir sayının faktöriyelini hesaplamak için bir program mı yazın?

Cevap: Faktör, neredeyse tüm görüşmelerde en sık sorulan sorulardan biridir (geliştirici görüşmeleri dahil)
Geliştirici görüşmeleri için, dinamik programlama, özyineleme vb. Programlama kavramlarına daha fazla odaklanılırken, Yazılım Geliştirme Mühendisi Test perspektifinden bakıldığında, maksimum değerler, minimum değerler, negatif değerler vb. Ve yaklaşım / verimlilik gibi uç senaryoları ele almak önemlidir. önemlidir ama ikincil hale gelir.

Negatif sayıları işleyen ve programda faktöriyel işlevi çağırarak işlenmesi gereken negatif sayılar için -9999 gibi sabit bir değer döndüren özyineleme ve for-döngü kullanan faktöryel için bir program görelim.
Lütfen aşağıdaki kod parçasına bakın:

public class Factorial { public static void main(String() args) { System.out.println('Factorial of 5 using loop is:' + factorialWithLoop(5)); System.out.println('Factorial of 10 using recursion is:' + factorialWithRecursion(10)); System.out.println('Factorial of negative number -100 is:' + factorialWithLoop(-100)); } public static long factorialWithLoop(int n) { if(n <0) { System.out.println('Negative nos can't have factorial'); return -9999; } long fact = 1; for (int i = 2; i <= n; i++) { fact = fact * i; } return fact; } public static long factorialWithRecursion(int n) { if(n < 0) { System.out.println('Negative nos can't have factorial'); return -9999; } if (n <= 2) { return n; } return n * factorialWithRecursion(n - 1); } }

Döngüyü kullanan faktöryel, özyinelemeyi kullanan faktöriyel ve negatif bir sayının faktöriyeli (-9999 varsayılan ayar değerini döndürür) için çıktıyı görelim

çıktı-faktöriyel 4 yeni

S # 4) Verilen bir dizgede dengeli parantezler olup olmadığını kontrol etmek için bir program yazın?

Cevap:

Yaklaşmak - Bu, görüşmecinin sadece kodlama yapıları bilgisinden biraz daha fazlasına baktığı biraz karmaşık bir sorundur. Burada beklenti, eldeki problem için uygun veri yapısını düşünmek ve kullanmaktır.

Birçoğunuz bu tür sorunlardan korktuğunuzu hissedebilirsiniz, çünkü bazılarınız bunları duymamış olabilir ve bu nedenle basit olsalar bile kulağa karmaşık gelebilir.

Ancak genellikle bu tür sorunlar / sorular için: Örneğin, Şu anki soruda, dengeli parantezlerin ne olduğunu bilmiyorsanız, görüşmeciye çok iyi sorabilir ve sonra kör bir noktaya çarpmak yerine çözüme doğru çalışabilirsiniz.

Bir çözüme nasıl yaklaşılacağını görelim: Dengeli parantezlerin ne olduğunu anladıktan sonra, doğru veri yapısını kullanmayı düşünebilir ve ardından çözümü kodlamaya başlamadan önce algoritmalar (adımlar) yazmaya başlayabilirsiniz. Çoğu zaman, algoritmaların kendisi birçok uç senaryoyu çözer ve çözümün neye benzeyeceği konusunda çok netlik verir.

Çözüme bakalım:

Dengeli parantezler, parantezler (veya parantezler) içeren belirli bir dizeyi kontrol etmektir, eşit açılış ve kapanış sayısına sahip olması ve aynı zamanda konumsal olarak iyi yapılandırılmış olması gerekir. Bu sorunun bağlamı için, dengeli parantezleri - ‘()’, ‘()’, ‘{}’ olarak kullanacağız - yani verilen dizge bu parantezlerin herhangi bir kombinasyonunu içerebilir.

Sorunu denemeden önce, dizenin sadece köşeli parantez karakterlerini mi yoksa sayıları mı içereceğini açıklığa kavuşturmanın iyi olacağını lütfen unutmayın (bu, mantığı biraz değiştirebilir)

Misal: Verilen bir dize - '{() {} ()} - yapılandırıldığı ve eşit kapatma ve açma parantezlerine sahip olduğu için dengeli bir dizedir, ancak dize -' {(}) {} () '- bu dize - olsa bile eşit açma ve kapama parantezleri yoktur, bu hala dengeli değildir çünkü kapanış olmadan '(' kapattık '}' (yani bir dış köşeli parantez kapatılmadan önce tüm iç parantezler kapatılmalıdır)

Bu sorunu çözmek için bir yığın veri yapısı kullanacağız. Yığının temelleri hakkında daha fazla bilgi edinmek istiyorsanız lütfen bakın İşte

Yığın bir LIFO'dur (Son Giren İlk Çıkar tipi veri yapısı), bunu bir düğünde bir tabak yığını / yığını olarak düşünün - her kullandığınızda en üstteki plakayı alırsınız.

Algoritma:

# 1) Bir Karakter Yığını bildirin (dizedeki karakterleri tutar ve bazı mantığa bağlı olarak, karakterleri itin ve çıkarın).

# 2) Giriş dizesi boyunca ve ne zaman

  • Bir açılış parantez karakteri vardır - ör. ‘(‘, {’Veya‘ (‘- Yığın üzerindeki karakteri itin.
  • Bir kapanış karakteri var - yani ')', '}', ')' - Stack'den bir öğe aç ve kapanış karakterinin zıttıyla eşleşip eşleşmediğini kontrol et - yani karakter '}' ise o zaman Stack pop'ta beklemelisin ' {'
    • Açılan öğe kapanış parantezlerinin tersi ile eşleşmiyorsa, dize dengeli değildir ve sonuçları döndürebilirsiniz.
    • Aksi takdirde, stack push ve pop yaklaşımına devam edin (2. adıma gidin).
  • Dizge tamamen geçilirse ve Yığın boyutu da sıfırsa, verilen dizenin dengeli bir parantez dizesi olduğunu söyleyebilir / çıkarabiliriz.

Bu noktada, bir algoritma olarak sahip olduğunuz çözüm yaklaşımını tartışmak ve görüşmecinin yaklaşıma uygun olduğundan emin olmak isteyebilirsiniz.

Kod:

import java.util.Stack; public class BalancedParanthesis { public static void main(String() args) { final String input1 = '{()}'; System.out.println('Checking balanced paranthesis for input:' + input1); if (isBalanced(input1)) { System.out.println('Given String is balanced'); } else { System.out.println('Given String is not balanced'); } } /** * function to check if a string has balanced parentheses or not * @param input_string the input string * @return if the string has balanced parentheses or not */ private static boolean isBalanced(String input_string) { Stack stack = new Stack(); for (int i = 0; i

Yukarıdaki kod pasajının çıktısı:

dengeli çıktıParantheses 2 yeni

Önceki kodlama sorunlarımız için yaptığımız gibi, kodu en az 1-2 geçerli ve 1-2 geçersiz girişle kurutmak ve tüm durumların uygun şekilde ele alınmasını sağlamak her zaman iyidir.

NOT: Çözümü yüksek sesle düşünmek her zaman iyidir (sadece zihnin içinde değil) ve şaşırtıcı bir şekilde bu, görüşmecilerin aradığı önemli bir özelliktir. Birçok görüşmeci, algoritmayı ortadan kaldırabilir ve bir sonraki problem ifadesine geçebilir.

Yukarıdaki kodlama çözümünde, geliştirici görüşmesi için, görüşmeci, doğrudan yığın yerine diziler kullanarak çözmeyi isteyebilir (yani diziyi yığın olarak kullanmak), ancak genel olarak, kavramsal olarak net olmak ve tüm geçerli ve geçersiz girişler.

Test Otomasyon Çerçevesi İle İlgili

Görüşmenin bu bölümü, test ve SDET sorumlulukları ile ilgili daha spesifiktir. Otomasyon çerçevesi tasarımı ve geliştirmeyle ilgili soruları, farklı yaklaşımları kullanmanın artılarını ve eksilerini vb. Bekleyin.

Aynısı için bazı örnek sorular ve çözümler görelim.

S # 5) Bir web uygulaması için otomasyon çerçevesinin bileşenlerini açıklayın ve tasarlayın?

Cevap: Bu soru biraz özneldir ve görüşmeci, adayın çerçeve tasarımı ve geliştirmesi hakkında ne kadar bilgi sahibi olduğunu ölçmeyi amaçlamaktadır. Bu sorunun cevabı, görüşmecinin adayın sıfırdan özel çerçeveler oluşturup oluşturamayacağını anlamasına yardımcı olur.
Bu sorunun çözümünü yapılandırmanıza yardımcı olacak birkaç noktaya bakalım:

  • Veriye dayalı, Anahtar kelimeye dayalı, Hibrit Çerçeve gibi farklı çerçeve türleri hakkında konuşabilirsiniz.
  • Web uygulamasının farklı sayfalarında / modüllerinde çeşitli öğelerin ayrıntılarını depolamak için Sayfa Nesne Modeli.
  • Yardımcı işlevler, yardımcı programlar, kaydediciler vb. Gibi ortak modüller
  • Test yürütme raporları oluşturma, raporları e-posta ile entegre etme ve test yürütmeyi planlama gibi raporlama modülleri.

Önerilen Okuma => En Popüler Test Otomasyon Çerçeveleri

S # 6) Bir mobil uygulama için test stratejilerini açıklayın?

Cevap: Bu sorular tipik olarak role bağlı olarak sorulur. Rol büyük ölçüde mobil uygulamalarda çalışmaksa, soru daha fazla alakalı. Mevcut veya önceki rollerinizin bir parçası olarak mobil testi planladıysanız, deneyimlerinizden konuşabilirsiniz.

Bu sorunun cevabını yapılandırmak için bazı ipuçları şunlar olabilir:

  • Cihazlarda ve emülatörlerde test etme.
  • Nesneleri / öğeleri farklı ekranlarda tanımlama ve saklama - Misal: Sayfa Nesne Modeli.
  • Bir mobil uygulamayı test etme.
  • Yerel uygulamalar, Karma uygulamalar gibi farklı mobil uygulama türleri hakkında konuşabilir ve bunları test etmek için kullanacağınız stratejileri / yaklaşımları tartışabilirsiniz.

Önerilen Okuma => Mobil Uygulama Testi Eğiticileri

S # 7) REST API'lerini test etmek için bir Otomasyon çerçevesi tasarlıyor musunuz?

Cevap: Bu yine öznel bir sorudur ve görüşmecinin API'nin işlevsel davranışını veya Yük / Performans testi gibi işlevsel olmayan gereksinimleri test etmek için bir çerçeve geliştirmenizi isteyip istemediğini açıklığa kavuşturan sorular sorabilirsiniz.

Cevabınıza aşağıdaki noktaları kapsayarak başlayabilirsiniz:

  • Yerel kurulum, API'nin sahte kurulumu veya Barındırılan API Testi gibi API Otomasyon çerçeve bileşenleri.
  • API Otomasyonu için kullanılan araçlar. REST tabanlı bir API'nin işlevsel yönlerini doğrulamak için kullanıma hazır çeşitli araçlar vardır. Bu tür araçlardan bazıları Postacı, Huzurlu, vb'dir. Farklı araçların ayrıntılı ayrıntıları için makalemize bakabilirsiniz. İşte .
  • API'lerin İşlevsel Olmayan Otomasyonu.
  • Otomasyon testlerinin Planlanmış Yürütülmesi.
  • API'ler için otomasyon testlerini entegre etme.

S # 8) Çerçeveye özgü sorular.

Cevap: Zaman zaman, mülakat yapılan profile bağlı olarak, bir adayın belirli bir çerçevede uzman olması için bir gereklilik olabilir - örneğin. Selenyum, JMeter vb.

Önerilen Okuma => Postacı , Mockito , Specflow , Selenyum , JMeter

Testle İlgili

Nadiren de olsa, ancak profile bağlı olarak, genel test uygulamaları, terimleri ve teknolojileri - hata şiddeti, öncelik, test planlaması, test çerçevesi vb. Gibi sorular olabilir. Bir SDET'in tüm manuel test kavramlarını bilmesi ve aşina olması beklenir. önemli terminolojilerle.

Bu bölümde aşağıdaki gibi sorular bekleyebilirsiniz:

S # 9) Bir test planının farklı bileşenleri nelerdir?

Cevap: Bunlardan genellikle temel test kavramlarını ve zihniyetini doğrulamaları istenir. Bu terimler ve belgeler, her manuel KG'nin ve otomasyon SDET'lerinin bilmesi gereken şeylerdir.
Test planının çeşitli bileşenlerini burada şöyle tartışabilirsiniz:

  • Giriş ve Çıkış Kriterleri
  • Dürbün: Kapsam dahilinde olan test özelliklerini ve nelerin otomatikleştirileceğini tartışın - Yalnızca işlevsel özellikler mi yoksa ölçeklenebilirlik, performans vb. Gibi işlevsel olmayan gereksinimler mi olacak?
  • Zaman çizelgeleri
  • Kullanılacak araçlar
  • Kaynak tahsisi vb.

Önerilen Okuma => İyi bir test planı nasıl yazılır

S # 10) Bir hatanın önceliğini ve önem derecesini ne tanımlar ve buna karar verir?

Cevap: Kusur Önceliği ve Ciddiyeti, örnekler yardımıyla kolayca açıklanabilir. Kaydolma gibi bir özelliğin bozuk olduğunu ve kullanıcıların uygulamaya erişimini engellediğini varsayalım. Bu, yüksek öncelikli ve yüksek önem taşıyan bir sorundur. Benzer şekilde, Düşük Önem / Yüksek Öncelik kusurlarının ve çeşitli diğer kombinasyonların örnekleri olabilir.

Genel olarak,

  • Öncelik konunun önemini belirtir.
  • Önem sorunun, uygulamanın müşterisi veya kullanıcısı üzerindeki etkisini belirtir.

Önerilen Okuma => Kusur Önceliği ve Önem Derecesi

S # 11) Eşdeğer Bölümleme nedir? Bir örnekle açıklayın.

Cevap: Eşdeğerlik Bölümleme, belirli bir alana karşı çeşitli girdi kombinasyonlarını test etmek için çoğunlukla Kara kutu testi için kullanılan bir tekniktir.

Örneğin, Bir ticaret uygulamasını test ediyorsanız ve 'Miktar' alanı için tüm test senaryolarını yazmak istiyorsanız - bu alan için test edeceğiniz farklı girdiler nelerdir?
İşlevsel gereksinim, miktarın 1 ile 100000 arasında pozitif bir tamsayı değeri olması gerektiğidir. Bu nedenle, çeşitli girdileri (hem geçerli hem de geçersiz) test etmek için, bu kategorilerin her birinden 1 girdi için test yapabilirsiniz.

  • Geçerli değerler: 1 ile 100000 arasında -> x> 1 ve x olacak şekilde herhangi bir x geçerli değeri için test edin<100000.
  • Sınır değerleri: İzin verilen sınır değerlerini test edin, yani 1 ve 100000.
  • Geçersiz değerler: İzin verilen aralığın dışında kalan değerler - yani, x 100000 olacak şekilde x için böyle bir değer için test edin.

Önerilen Okuma => Eşdeğer Bölümleme stratejisi

Sistem Tasarımıyla İlgili

Sistem tasarımı soruları genellikle, bir geliştiricinin ölçeklenebilirlik, kullanılabilirlik, hata toleransı, veritabanı seçimi, iş parçacığı vb. Gibi farklı genel kavramlar hakkında geniş bir anlayışa dayalı olarak değerlendirildiği geliştirici görüşmeleri için daha uygundur. Özetle, tüm bilgilerinizi kullanmanız gerekecektir. bu tür soruları yanıtlamak için deneyim ve sistem bilgisi.

Ama yıllarca tecrübe ve yüzlerce geliştiricinin kod yazmasını gerektiren bir sistemin, bir kişi soruyu yaklaşık 45 dakikada nasıl yanıtlayabileceğini hissediyor olabilirsiniz?

Cevap: Burada beklenti, adayın karmaşık problemleri çözerken uygulayabileceği geniş bilgi yelpazesini ve anlayışını değerlendirmektir.

Günümüzde bu sorular SDET görüşmelerinde de atılmaya başlandı. Burada beklenti, geliştirici mülakatı ile aynı kalır, ancak gevşetilmiş değerlendirme kriterleri ile ve çoğunlukla, adayın cevabına bağlı olarak, bir adayın bir sonraki seviye için düşünülebileceği veya daha düşük bir seviyeye taşınabileceği bir bar yükseltme turu ile.

Genel olarak, sistem tasarımı mülakat soruları için adayın aşağıdaki kavramlara aşina olması gerekir.

  1. İşletim sistemlerinin temelleri: Sayfalama, dosya sistemleri, sanal bellek ve fiziksel bellek vb.
  2. Ağ kavramları: HTTP iletişimi, TCP / IP yığını, ağ topolojileri.
  3. Ölçeklenebilirlik kavramları: Yatay ve Dikey Ölçeklendirme.
  4. Eşzamanlılık / İş Parçacığı kavramları
  5. Veritabanı türleri: SQL / SQL veritabanı yok, ne tür veritabanı, farklı veritabanı türlerinin avantajları ve dezavantajları ne zaman kullanılır.
  6. Hashing teknikleri
  7. Temel anlayış CAP teorem, parçalama, bölümleme vb.

Bazı örnek sorular görelim

S # 12) Aşağıdaki gibi bir URL kısaltma sistemi tasarlayın küçük URL ?

Cevap: Çoğu aday, genel olarak URL kısaltma sistemlerini bile bilmeyebilir. Bu durumda, anlamadan dalmak yerine, görüşmeciye sorun ifadesini sormak uygundur.

Bu tür soruları cevaplamadan önce, adaylar çözümü yapılandırmalı ve madde işaretleri yazmalı ve ardından çözümü görüşmeci ile tartışmaya başlamalıdır.

Çözümü kısaca tartışalım

a) İşlevsel ve işlevsel olmayan gereksinimleri netleştirin

İşlevsel gereksinimler: İşlevsel gereksinim, yalnızca müşterinin bakış açısından bakıldığında, büyük (uzun) bir URL ile beslenen bir sistemdir ve çıktının kısaltılmış bir URL olması gerekir.

Kısaltılmış URL'ye erişildiğinde, kullanıcıyı orijinal URL'ye yönlendirmelidir. Örneğin - https://tinyurl.com/ web sayfasında gerçek bir URL'yi kısaltmayı deneyin, www.softwaretestinghelp.com gibi bir giriş URL'sini besleyin ve https://tinyurl.com/shclcqa gibi küçük bir URL almalısınız

İşlevsel olmayan gereksinimler: Sistem, milisaniye gecikmeli yeniden yönlendirme açısından başarılı olmalıdır (orijinal URL'ye erişen bir kullanıcı için ek bir atlama olarak).

  • Kısaltılmış URL'lerin yapılandırılabilir bir sona erme süresi olmalıdır.
  • Kısaltılmış URL'ler tahmin edilebilir olmamalıdır.

b) Kapasite / Trafik Tahmini

Bu, tüm sistem tasarımı soruları açısından çok önemlidir. Kapasite Tahmini, esasen sistemin alacağı beklenen yükü belirlemektir. Bir varsayımla başlamak ve görüşmeci ile tartışmak her zaman iyidir. Bu, sistemin okuma ağırlıklı veya yazma ağırlıklı vb. Olup olmadığına bakılmaksızın veritabanı boyutlandırmasının planlanması açısından da önemlidir.

URL kısaltıcı örneği için bazı kapasite sayılarını yapalım.

Diyelim ki, günde 100.000 yeni URL kısaltma isteği (100: 1 okuma-yazma oranıyla - yani kısaltılmış her 1 URL için, kısaltılmış URL'ye karşı 100 okuma isteğimiz olacak)

Yani sahip olacağız

100k write requests/day => 100000/(24x60x60) => 1.15 request/second 10000k read requests/day => 10000000/(24x60x60) => 1157 requests/second

c) Depolama ve Bellek hususları

Kapasite sayılarından sonra, bu sayıları tahmin edebiliriz,

  • Beklenen yükü barındırmak için gerekli olacak depolama kapasitesi, Örneğin, 1 yıla kadar talepleri desteklemek için bir depolama çözümü tasarlamayı planlayabiliriz.
    Misal: Her kısaltılmış URL 50 bayt tüketiyorsa, bir yıldan uzun süre ihtiyaç duyacağımız toplam veri / depolama şu şekilde olacaktır:
=> total write requests/day x 365 x 50 / (1024x1024) => 1740 MB
  • Belleğe ilişkin hususlar, sistemi okuyucunun bakış açısından planlamak için önemlidir. Örneğin, okuma ağırlıklı sistemler için - oluşturmaya çalıştığımız gibi (çünkü URL bir kez oluşturulacak, ancak birden çok kez erişilecek).
    Okuma ağır sistemleri genellikle daha performanslı hale gelmek ve okuma G / Ç'sinden tasarruf etmek için kalıcı depolamadan okumaktan kaçınmak için önbelleğe almayı kullanır.

Diyelim ki okuma isteklerimizin% 60'ını önbellekte depolamak istiyoruz, bu nedenle yıl boyunca her giriş için gerekli olan x bayt üzerinden toplam okumaların% 60'ını zorunlu kılacaktır.

=> (60/100) x 100000 x 365 x (50/1024x1024) => 1045 MB ~ 1GB

Dolayısıyla, kapasite sayılarımıza göre, bu sistem yaklaşık 1 GB fiziksel bellek gerektirecektir.

d) Bant Genişliği Tahminleri

Bant genişliği tahminleri, bir sistemin gerçekleştirilmesi için gerekli olan bayt cinsinden okuma ve yazma hızını analiz etmek için gereklidir. Aldığımız kapasite sayılarına karşı tahminler yapalım.

Misal: Her kısaltılmış URL 50 bayt tüketirse, ihtiyacımız olan toplam okuma ve yazma hızları aşağıdaki gibi olacaktır:

WRITE - 1.15 x 50bytes = 57.5 bytes/s READS - 1157 x 50bytes = 57500 bytes/s => 57500 / 1024 => 56.15 Kb/s

e) Sistem tasarımı ve Algoritma
Bu, esasen fonksiyonel gereksinimleri karşılamak için kullanılacak ana iş mantığı veya algoritmasıdır. Bu durumda, belirli bir URL için benzersiz kısaltılmış URL'ler oluşturmak istiyoruz.

Kısaltılmış URL'ler oluşturmak için kullanılabilecek farklı yaklaşımlar şunlardır:

Hashing: Giriş URL'sinin bir karmasını oluşturarak ve kısaltılmış URL olarak karma anahtarı atayarak kısaltılmış URL'ler oluşturmayı düşünebiliriz.

Hashing

Bu yaklaşımın, hizmetin farklı kullanıcıları olduğunda bazı sorunları olabilir ve aynı URL'yi girerlerse, aynı kısaltılmış URL'nin alınmasına neden olurlar.

Önceden oluşturulmuş kısaltılmış dizelerve hizmet çağrıldığında URL'lere atanır: Başka bir yaklaşım, önceden oluşturulmuş dizelerin havuzundan önceden tanımlanmış kısaltılmış bir dizeyi döndürmek olabilir.

Önceden oluşturulmuş kısaltılmış dizeler

Hizmet API'leri: URL kısaltıcı sistemini, aşağıdaki uç noktalara sahip olan bir dizi REST tabanlı API olarak düşünebiliriz:

  • createUrl (String Url, DateTime expiryTime): Bu uç nokta, girdide belirtildiği gibi sona erme süresi ayarlanmış kısaltılmış bir URL oluşturur ve döndürür.
  • retrieveUrl (String shortenedUrl): Bu uç nokta, verilen kısaltılmış URL'ye yeniden yönlendirilecek URL'yi alır.

f) Ölçeklendirme ve Eş Zamanlılık

Ölçeklendirme, işlevsel olmayan gereksinim açısından önemli bir husustur.

Nasıl çalışır, sistem

  • Yük altında ölçekleyin: Sistem, yük altında zarif bir şekilde ölçeklenebilmeli ve yükte beklenmedik bir ani artış meydana geldikten sonra çalışmayı durdurmamalıdır.

Önerilen Okuma => Ölçeklendirme Teknikleri

  • Sistem ne kadar performanslı olabilir, Örneğin: Sistem uzun süre sürekli kapasiteyle kullanılırsa, sistem performansı düşer mi yoksa sabit kalır mı?

Aşağıdaki gibi birçok farklı sistem tasarımı sorusu olabilir, ancak genel olarak konuşursak, bunların tümü, adayın URL kısaltma sisteminin çözümünde tartıştığımız farklı kavramlara ilişkin daha geniş anlayışını test eder.

S # 13) Youtube gibi bir video platformu tasarlayın.

Cevap: Yukarıdaki TinyUrl sorusunu tartıştığımıza benzer şekilde bu soruya da yaklaşılabilir (ve bu neredeyse tüm sistem tasarımı görüşme soruları için geçerlidir). Farklılaştıran faktörlerden biri, tasarlamak istediğiniz sisteme bakmak / detaylandırmak olacaktır.

Dolayısıyla Youtube için hepimiz bunun bir video akış uygulaması olduğunu biliyoruz ve bir kullanıcının yeni videolar yüklemesine, canlı web yayınlarını yayınlamasına vb. İzin vermek gibi pek çok özelliğe sahibiz. Bu nedenle sistemi tasarlarken gerekli Sistem tasarım bileşenlerini uygulamanız gerekir. Bu durumda, video akışı yetenekleriyle ilgili bileşenler eklememiz gerekebilir.

Gibi konuları tartışabilirsiniz:

  • Depolama: Video içeriğini, kullanıcı profillerini, oynatma listelerini vb. Depolamak için ne tür bir veritabanı seçerdiniz?
  • Güvenlik ve Kimlik Doğrulama / Yetkilendirme
  • Önbelleğe almak: Youtube gibi bir akış platformunun yüksek performanslı olması gerektiğinden, önbelleğe alma, bu tür bir sistemi tasarlamak için önemli bir faktördür.
  • Eşzamanlılık: Kaç kullanıcı paralel olarak video akışı gerçekleştirebilir?
  • Kullanıcılara izleyebilecekleri sonraki videoları öneren / öneren video öneri hizmeti gibi diğer platform işlevleri.

S # 14) 6 asansörü çalıştırmak için verimli bir sistem tasarlayın ve bir kişinin asansörün gelmesini beklerken minimum süre beklemesini sağlayın ?

Cevap: Bu tür sistem tasarımı soruları daha düşük seviyelidir ve adayın önce asansör sistemi üzerinden düşünmesini ve desteklenmesi gereken tüm olası işlevleri listelemesini ve çözüm olarak sınıflar ve DB ilişkileri / şemaları tasarlaması / yaratması beklenir.

SDET perspektifinden, görüşmeci, uygulamanızın veya sisteminizin sahip olacağını düşündüğünüz ana sınıfları bekler ve temel işlevler önerilen çözümle ele alınır.

Asansör sisteminin beklenen çeşitli işlevlerini görelim

Açıklayıcı sorular sorabilirsiniz.

  • Orada kaç kat var?
  • Kaç asansör var?
  • Tüm asansörler servis / yolcu asansörleri mi?
  • Tüm asansörler her katta durdurulacak şekilde yapılandırılmış mı?

Basit bir asansör sistemi için geçerli olan farklı kullanım durumları şunlardır:

system-design-asansör_system

Bu sistemin çekirdek sınıfları / nesneleri açısından, aşağıdakilere sahip olmayı düşünebilirsiniz:

  • Kullanıcı: Bir kullanıcının tüm özelliklerini ve Elevator Object üzerinde gerçekleştirebilecekleri eylemleri ele alır.
  • Asansör: Asansör Yükseklik, genişlik, asansör_seri_sayısı gibi belirli özellikler.
  • Asansör Kapısı: Kapısız, kapı tipi, otomatik veya manuel vb. Kapı ile ilgili her şey.
  • Elevator_Button_Control: Asansörde bulunan farklı düğme / kontroller ve bu kontrollerin olabileceği farklı durumlar.

Sınıfları ve ilişkilerini tasarlamayı bitirdikten sonra, DB şemalarını yapılandırmaktan bahsedebilirsiniz.

Asansör sisteminin bir diğer önemli bileşeni ise Etkinlik Sistemidir. Sıraları uygulamaktan veya olayların uygulanmak üzere ilgili sistemlere teslim edildiği Apache Kafka kullanarak olay akışları oluşturan daha karmaşık bir kurulumdan bahsedebilirsiniz.

Etkinlik Sistemi, asansörü aynı anda kullanan birden fazla kullanıcı (farklı katlarda) olduğu için önemli bir husustur. Bu nedenle, kullanıcının istekleri sıraya alınmalı ve Asansör denetleyicilerinde yapılandırılan mantığa göre sunulmalıdır.

S # 15) Instagram / Twitter / Facebook tasarlayın.

Cevap: Tüm bu platformlar, kullanıcıların bir şekilde veya başka şekilde bağlanmasına ve mesajlar / videolar ve sohbetler gibi farklı medya türleri aracılığıyla bir şeyler paylaşmalarına izin verdikleri için bir şekilde ilişkilidir.

Dolayısıyla, bu tür sosyal medya uygulamaları / platformları için, bu tür sistemleri tasarlarken aşağıdaki noktaları eklemelisiniz (URL kısaltıcı sistemi tasarlamak için tartıştıklarımıza ek olarak):

  • Kapasite Tahmini: Bu sistemlerin çoğu okuma ağırlıklı olacaktır, bu nedenle kapasite tahmini gereklidir ve gerekli yüke hizmet etmek için uygun sunucu ve veritabanı yapılandırmasının sağlandığından emin olmamızı sağlar.
  • DB şeması: Tartışılması gereken ana önemli DB şemaları - Kullanıcı ayrıntıları, Kullanıcı ilişkileri, Mesaj şemaları, İçerik Şemalarıdır.
  • Video ve Resim Barındırma sunucuları: Bu uygulamaların çoğu, kullanıcılar arasında paylaşılan videolara ve görüntülere sahiptir. Bu nedenle Video ve Görüntü Barındırma sunucuları ihtiyaçlara göre yapılandırılmalıdır.
  • Güvenlik: Tüm bu uygulamalar, sakladıkları kullanıcıların Kullanıcı bilgileri / Kişisel Olarak Tanımlanabilir Bilgileri sayesinde yüksek düzeyde güvenlik sağlamalıdır. Milyonlarca müşterinin verilerini kaybetmeye mal olabileceğinden, herhangi bir hackleme girişimi, SQL Injection bu platformlarda başarılı olmamalıdır.

Senaryoya dayalı sorunlar

Senaryoya dayalı sorunlar genellikle, farklı gerçek zamanlı senaryoların verildiği ve adaya böyle bir durumu nasıl ele alacaklarına dair düşüncelerinin sorulduğu üst düzey kişiler içindir.

S # 16) Kritik bir düzeltmenin mümkün olan en kısa sürede yayımlanması gerektiği düşünüldüğünde - Ne tür bir test stratejiniz olurdu?

Cevap: Şimdi, burada görüşmeci esasen anlamak istiyor

  • Nasıl ve ne tür test stratejileri düşünebilirsiniz?
  • Bir düzeltme için hangi kapsamı yapardınız?
  • Dağıtım sonrası düzeltmeyi nasıl doğrularsınız? vb.

Bu tür soruları cevaplamak için, problemle ilişkilendirebiliyorsanız gerçek hayattaki durumları kullanabilirsiniz. Ayrıca, uygun testler olmadan herhangi bir kodu üretime yayınlamaya istekli olmayacağınızı da belirtmelisiniz.

Kritik düzeltmeler için her zaman geliştiriciyle birlikte çalışmalı ve bunun hangi alanları etkileyebileceğini anlamaya çalışmalı ve senaryoyu çoğaltmak ve düzeltmeyi test etmek için üretim dışı bir ortam hazırlamalısınız.

Üretim ortamındaki herhangi bir anormal davranışı görmek ve düzeltmenin olumsuz bir etkisi olmadığından emin olmak için dağıtım sonrası düzeltmeyi (izleme araçlarını, panoları, günlükleri vb. Kullanarak) izlemeye devam edeceğinizi belirtmek de önemlidir. bitti.

Çoğunlukla adayın otomasyon testi, teslimat zaman çizelgeleri vb. Hakkındaki bakış açısını anlamaya yönelik başka sorular da olabilir (ve bu sorular şirketten şirkete ve rolün kıdemine göre değişebilir. Genellikle bu sorular kıdemli / lider seviyesi için sorulur. roller)

S # 17) Bir ürünü hızlı bir şekilde piyasaya sürmek için tam testi feda eder miydiniz?

Cevap: Bu sorular tipik olarak görüşmecinin düşüncelerinizi liderlik perspektifinden anlamasını ve ödün vereceğiniz şeylerin neler olduğunu ve daha az zaman yerine buggy ürünü piyasaya sürmek isteyip istemediğinizi içerir.

Bu soruların cevapları, adayın gerçek deneyimleriyle kanıtlanmalıdır.

Örneğin, Geçmişte bazı düzeltmeleri yayınlamak için bir çağrı almanız gerektiğini, ancak entegrasyon ortamının mevcut olmaması nedeniyle test edilemediğinden bahsedebilirsiniz. Böylece, kontrollü bir şekilde yayınladınız - daha küçük bir yüzdeye yayarak ve ardından günlükleri / olayları izleyerek ve ardından tam kullanıma sunmayı başlatarak vb.

S # 18) Hiç otomasyon testi bulunmayan bir ürün için Otomasyon Stratejisini nasıl oluşturursunuz?

Cevap: Bu tür sorular açık uçludur ve genellikle tartışmayı istediğiniz şekilde yürütmek için iyi bir yerdir. Ayrıca gücünüz olan becerilerinizi, bilginizi ve teknoloji alanlarınızı da sergileyebilirsiniz.

Örneğin, Bu tür soruları yanıtlamak için, geçmiş rolünüzde bir ürün oluştururken benimsediğiniz Otomasyon Stratejisi örneklerinden bahsedebilirsiniz.

Örneğin, aşağıdaki gibi noktalardan bahsedebilirsiniz:

  • Ürün otomasyonu sıfırdan başlatmayı gerektirdiğinden, çoğu insanın yeni bir aracı tanıtmaktan kaçınmak ve mevcut bilgilerden yararlanmak için bilgiye sahip olduğu bir dil / teknoloji seçerek uygun bir otomasyon çerçevesi için düşünmek ve tasarlamak için yeterli zamanınız oldu.
  • P1 olarak kabul edilen (olmadan hiçbir sürümün geçemeyeceği) en temel işlevsel senaryoları otomatikleştirmeye başladınız.
  • Ayrıca, JMETER, LoadRunner gibi otomatik test araçlarıyla sistemin Performansını ve Ölçeklenebilirliğini test etmeyi düşündünüz.
  • Aşağıda listelenen uygulamanın güvenlik yönlerini otomatikleştirmeyi düşündünüz. OWASP Güvenlik standartları.
  • Erken geri bildirim vb. İçin otomatik testleri derleme hattına entegre ettiniz.

Takım Uyumu ve Kültür Uyumu

Bu tur genellikle şirketten şirkete bağlıdır. Ancak bu turun gerekliliği / gerekliliği adayı ekip ve organizasyon kültürü perspektifinden anlamaktır. Bu soruların amacı aynı zamanda adayın kişiliğini ve işe / insanlara yaklaşımını vb. Anlamaktır.

Genel olarak, bu turu yönetenler İK ve İşe Alım yöneticileridir.

Bu tur sırasında tipik olarak ortaya çıkan sorular şunlardır:

S # 19) Mevcut rolünüzdeki çatışmaları nasıl çözüyorsunuz?

Cevap: Burada daha fazla açıklama şudur: patronunuzla veya yakın ekip üyelerinizle bir çatışmanız olduğunu varsayalım, bu çatışmaları çözmek için attığınız adımlar nelerdir?

Bu tür sorular için, mevcut veya önceki kuruluşlarda kariyeriniz boyunca olmuş olabilecek gerçek örneklerle elinizden geldiğince doğrulayın.

Şunun gibi şeylerden bahsedebilirsiniz:

  • Mesleki nedenlerle ortaya çıkan (ve bu nedenle kişisel ilişkilerinizi etkilemek istemeyen) her türlü çatışmayı mümkün olan en kısa sürede çözmeyi seviyorsunuz.
  • Herhangi bir farklılığı / sorunu çözmek için genellikle etkili bir şekilde iletişim kurmaya ve kişiyle bireysel olarak konuşmaya / tartışmaya çalıştığınızdan bahsedebilirsiniz.
  • İşler daha da kötüye gitmeye başlarsa, kıdemli bir kişinin / yöneticinizin yardımını alıp onun görüşlerini alacağınızı söyleyebilirsiniz.

Takım uyumu / kültür uyumu sorularının diğer örnekleri aşağıdadır (bunların çoğu, yukarıdaki soru için tartıştığımız benzer bir yaklaşımla cevaplanmalıdır. Gerçek hayat senaryoları hakkında konuşmak, görüşmeci daha iyi bir şekilde ilişkilendirebileceği için burada önemli bir noktadır. iyi.

S # 20) İşe alınmayı düşündüğünüz yeni rolden ne tür bir iş-yaşam dengesi bekliyorsunuz?

Cevap: İşe Alma Yöneticisi, rolün ne gerektirdiğini bilen biri olduğundan, bazen ne kadar ekstra çaba sarf edilmesi gerekebileceğini, bu nedenle genel olarak görüşmeci, beklentilerinizin rolün beklediğinden radikal bir şekilde farklı olup olmadığını ölçmeye çalışır.

Varsayalım ki gece toplantılarına katılmayı tercih etmediğinizi ve rolün farklı bir zaman diliminde oturan bir ekip arasında büyük bir işbirliğine sahip olmanızı beklediğini, ardından görüşmeyi yapan kişi bunların rolden beklentiler olduğuna dair bir tartışma başlatabilir - Yapabilecek misiniz? adapte olmak? vb.

Yani yine, bu daha çok gündelik bir konuşma ama görüşmecinin bakış açısından, görüşülen pozisyon için adaylığınızı değerlendirmek için beklentilerinizi anlamak istiyorlar.

S # 21) İş dışında hobileriniz nelerdir?

Cevap: Bu sorular tamamen özneldir ve kişiye özeldir ve bu sorular genellikle adayın rahat ve kolay hissetmesini sağlamak ve gündelik tartışmaları başlatmak için yararlıdır.

Genel olarak, bu soruların cevapları şöyle olabilir - belirli bir türü okumayı seviyorsunuz, müziği seviyorsunuz, bazı gönüllü / hayırseverlik faaliyetleri için ödül kazandınız, vb. Ayrıca, bu sorular genellikle İK turunda soruluyor (ve teknik bir kişi tarafından sorulma olasılığı daha düşüktür).

S # 22) Yeni araçları ve teknolojileri proaktif olarak öğrenmeye ne kadar zaman ayırmaya hazırsınız?

Cevap: Burada görüşmeci, size alışılmadık veya yeni bir şey atılırsa yeni şeyler öğrenmeye istekli olup olmadığınızı ölçüyor. Aynı zamanda görüşmecinin proaktif olduğunuzu bilmesini sağlıyor mu? Kendinize ve kariyerinize yatırım yapmaya istekli misiniz? vb.

Öyleyse, bu tür soruları yanıtlarken - dürüst olun ve yanıtlarınızı örneklerle doğrulayın - Örneğin, Geçen yıl bir Java sertifikasına katıldığınızı ve her hafta birkaç saatinizi alarak kendinizi iş dışında hazırladığınızdan bahsedebilirsiniz.

Sonuç

Bu yazıda, Yazılım Geliştirme Mühendisi ile Test görüşme sürecini tartıştık ve genellikle adaylardan farklı kuruluşlar ve profiller üzerinden sorulan örnek sorular. Genel olarak, SDET mülakatları doğası gereği çok geniştir ve büyük ölçüde şirketten şirkete bağlıdır.

Ancak görüşme süreçleri, kalite ve otomasyon çerçevelerine daha fazla vurgu yapan bir geliştirici profili için var olanlara benzer.

Günümüzde şirketlerin belirli bir dile veya teknolojiye daha az odaklandığını, ancak daha çok kavramların geniş bir anlayışına ve şirketin ihtiyaç duyduğu araçlara / teknolojilere uyum sağlama becerisine odaklandığını anlamak önemlidir.

SDET Röportajınız için en iyi dileklerimle!

Önerilen Kaynaklar

^