[]
software engineer interview
bir yazılım mülakatı yönetiyor olsaydınız adaylara nasıl sorular yöneltirdiniz?
aklınıza gelen ilk soruyu yazabilirsiniz.
aklınıza gelen ilk soruyu yazabilirsiniz.
genelde biz bildigi dilleri soruyoruz sonra da sohbet eder gibi konusuyoruz. cunku software engineer isi icin, eger junior alacaksan, ne bildigi degil, bir ekipe ne kadar uyumlu ve motive oldugu onemli
- beriberi (10.11.16 00:12:16)
Şunu sorardım ben olsam.
İşin içinden çıkmanın zorlaştığı durumlarda ne yaparsınız?
Bana sordukları soruyu söylüyorum şimdi de.
Elinde bir sihirli değnek olsa neyi değiştirirsin?
İşin içinden çıkmanın zorlaştığı durumlarda ne yaparsınız?
Bana sordukları soruyu söylüyorum şimdi de.
Elinde bir sihirli değnek olsa neyi değiştirirsin?
- cok joleli ozgur (10.11.16 00:12:22 ~ 11:16:03)
stackoverflow hesabının olup olmadığını sorardım.
- ocanal (10.11.16 00:16:24)
@cok joleli ozgur böyle s*kimsonik sorulara nasıl yanıt verileceğini de söylesen keske:)
pozisyon: mid-senior seviyesi.
pozisyon: mid-senior seviyesi.
- dellydenis (10.11.16 00:18:25 ~ 11:16:12)
Bir stringi ters çeirmeyi fonskyiyonsuz nasıl yaparsın? tmp kullanmadan nasıl yaparsın.
- Cursed Chico (10.11.16 00:19:41)
@Cursed Chico nasıl yaparız?
- dellydenis (10.11.16 00:21:46)
@dellydenis
stringlerden birisini digerine ekliyorsun sonra return ederken parametrelerdeki stringlerin length'lerine gore ters sekilde substring yapiyorsun.
edit: fonksiyonda tmp kullanmadan
stringlerden birisini digerine ekliyorsun sonra return ederken parametrelerdeki stringlerin length'lerine gore ters sekilde substring yapiyorsun.
edit: fonksiyonda tmp kullanmadan
- jedilance (10.11.16 00:24:08 ~ 00:26:27)
mid senior icin github hesabi, calistigi projeler ve eski isinde gunluk ya da cok sik yaptigi seyleri sorardim. mesela su siralar bizdeki stajer devamli integration testing yapiyor, burdan ciktiginda artik usta olacak.
- beriberi (10.11.16 00:26:11)
+ daha önce hiç yazılımla neler yapabileceğinin farkında oldun mu? dünyada keşfedilmemiş onca fikir varken, neden onları yapmak yerine bizimle çalışmak istiyorsun?
- ee, öhöm, şey, siz neden yapmadınız?
+ bazıları üretmek için doğar, bazılarıysa seçmek. ben seçmek için doğmuşum ve seni seçmek veya seçmemek için burdayım. oysa gördüğüm kadarıyla sen ikisi için de doğmamışsın. (-tercihen- o zaman ne için doğdun?)
not: troll değil, ciddidir.
- ee, öhöm, şey, siz neden yapmadınız?
+ bazıları üretmek için doğar, bazılarıysa seçmek. ben seçmek için doğmuşum ve seni seçmek veya seçmemek için burdayım. oysa gördüğüm kadarıyla sen ikisi için de doğmamışsın. (-tercihen- o zaman ne için doğdun?)
not: troll değil, ciddidir.
- tosiba (10.11.16 00:31:35 ~ 00:33:04)
polymorphism nedir nerde kullanılır? aday junior ise object oriented hakkında bilgi verir misin?
- yüzyıllık yalnızlık (10.11.16 00:37:24)
peki size soru.
.net core'da crl ve just in time kullanımı kısaca anlatır mısınız?
.net core'da crl ve just in time kullanımı kısaca anlatır mısınız?
- dellydenis (10.11.16 00:49:59)
utf8'i oku blog postu'u yaz link'ini gönder (en çok karşılaştığım problemlerden biri dil/karakter seti problemleri)
bir listedeki elemanların kombinasyonunu çıkartan kodu yaz, github'a koy, link'ini gönder, ne kadar zamanda yazdığını söyle
Not: ne kadar kısa o kadar iyi,
tail call nedir oku blog post yaz link'ini gönder. (size neden fibionacci yazdırıyorlar sanıyorsunuz ki?)
bir tane daha vardı unuttum.
bunlar harici bölüm mezunu ise neden o bölümü seçtiğini, başka bölümden ise neden yazılıma geçtiğini, oturduğu yeri ve işe nasıl gidip geleceğini ne kadar süre yolda harcayacağını falan soruyorum.
blog postu sorularında içerik değişebilir, önemli olan bir konuda faydalandığı kaynaklar ve okuduğunu ne kadar iyi anlayabildiğini ve anlatabildiğini ölçüyorum.
kod yazma (her hangi bir konuda ve ofiste değil, evinde falan yazıyor zaten), burada ise hangi kütüphaneleri seçtiğini, dile ne kadar hakim olduğunu veya konuda ne kadar araştırma yapabileceğini görüyorum. ne kadar kısa yazarsa o kadar isi, ne kadar az dış bağımlılık yaratırsa o kadar iyi, dilin sunduğu standart kütüphanesini ne kadar etkin kullandığına falan bakıyorum. süre çok önemli değil, bu araştırma hızını ölçmek için gerekli bişi.
bir dişi istediğim kodu yazılımcı 6 saatte 1 satır olarak yazıp göndermişti mesela, bir erkek yazılımcı ise 2 saatten az sürece 150 satır gibi bişiy de yazmıştı, ben birincisini seçtim, az kod çok iş, aynı zamanda daha az bakım demektir.
bir listedeki elemanların kombinasyonunu çıkartan kodu yaz, github'a koy, link'ini gönder, ne kadar zamanda yazdığını söyle
Not: ne kadar kısa o kadar iyi,
tail call nedir oku blog post yaz link'ini gönder. (size neden fibionacci yazdırıyorlar sanıyorsunuz ki?)
bir tane daha vardı unuttum.
bunlar harici bölüm mezunu ise neden o bölümü seçtiğini, başka bölümden ise neden yazılıma geçtiğini, oturduğu yeri ve işe nasıl gidip geleceğini ne kadar süre yolda harcayacağını falan soruyorum.
blog postu sorularında içerik değişebilir, önemli olan bir konuda faydalandığı kaynaklar ve okuduğunu ne kadar iyi anlayabildiğini ve anlatabildiğini ölçüyorum.
kod yazma (her hangi bir konuda ve ofiste değil, evinde falan yazıyor zaten), burada ise hangi kütüphaneleri seçtiğini, dile ne kadar hakim olduğunu veya konuda ne kadar araştırma yapabileceğini görüyorum. ne kadar kısa yazarsa o kadar isi, ne kadar az dış bağımlılık yaratırsa o kadar iyi, dilin sunduğu standart kütüphanesini ne kadar etkin kullandığına falan bakıyorum. süre çok önemli değil, bu araştırma hızını ölçmek için gerekli bişi.
bir dişi istediğim kodu yazılımcı 6 saatte 1 satır olarak yazıp göndermişti mesela, bir erkek yazılımcı ise 2 saatten az sürece 150 satır gibi bişiy de yazmıştı, ben birincisini seçtim, az kod çok iş, aynı zamanda daha az bakım demektir.
- selam (10.11.16 10:38:43 ~ 10:42:01)
- hangi tarz gelistiricisin, 1. cok konsantre, is sirasinda bilgisayarla arana birsey girmesini istemeyen mi? 2. iletisime dayali, diger gelistiriciler ile cok fikir alisverisi yapan, problemleri is birligi ile mi cözersin.
(bir takimda bu iki tarzdandan da calisanlar bulunmali benim fikrimce. 1. tarz is bitirici, sonuca kolay ulasir. 2.tarz yaratici olur genelde.)
- ne tarz gelistirme yaparsin? Test Driven Development mi, Behavioral Driven Development mi, ya da bir baska sekilde mi?
- Object Oriented Programlamanin gerekliliklerine inaniyor musun? neden? Yoksa fonksiyonel programlama mi daha mantikli geliyor? (yapilan ise göre sirketlerin sececegi gelistiriciler farkli olur)
- bilgini Horizontal mi tanimlarsin yani cok konu bilip az mi uzmanlasirsin? yoksa Vertical mi yani daha az konuda bilgin vardir ama bildigin konuda cok derinlesmissindir. (Bir takimda bu iki tarzda da uzmanlasmis insana ihtiyac vardir. bazi sorunlar uzmanlasma gerektirir, bazi sorunlar da cok disiplidir yani cok alanda bilgi gerektirir, cok derinlesmeye gerek yoktur)
- bir problemle karsilastiginda hangi yöntemi kullanirsin, o konuda kitaplari mi okursun, stackoverflow dan mi bakarsin, github dan mi kodlari incelersin, yoksa o konuyu cözen bir kütüphane/arac var mi bakarsin, yoksa kendin mi cözüm bulmaya yönelirsin (bir takimda her tipde gelistirici olmalidir, duruma sarta göre her bir yöntem avantajli veya dezavantajli olabilir)
- test kod yazarken ne gibi araclar/kütüphaneler/diller kullaniyorsun.
- bunlarin yaninda gelistiricinin algoritma yazma becerisini, kullanilacak dil konusunda yeteneklerini ölcecek temel sorular sorulmali. ama bunda sorular minimum ezber gerektirecek akil yürütme gerektirecek sorular olmali.
kisisel görüsüme göre bir gelistirici takimi olustururken güzel bir karma, güzel bir harmoni yapmak gerekir. sirketlerin en cok düstügü hata hep ayni tarz gelistiricileri ise almalari, bu da farkli sorunlarda takilmalarina cözüm üretememelerine neden oluyor. bir futbol takimi gibi düsünmek gerekir 11 kisinin 11i de golcü olmaz, kaleci de lazim, defans da. takim lideri de bu farkli yeteneklerin tarzlarin arasindaki uyumu da bilmeli hangi durumda kimin daha verimli olacagini idrak etmis olmali. her problem hep ayni tarz gelistirici ile cözülemez. problemin yada isin tipine, gereksinimlerine, zamanin darligina/genisligine göre uygun gelistirici secilir ve cözüme o sekilde ulasilir. bilisim alandinda calisan insan kaynaklari personeli ve gelistirici takim liderlerinin de gelistirici tiplerine hakim olmasi gerekir.
(bir takimda bu iki tarzdandan da calisanlar bulunmali benim fikrimce. 1. tarz is bitirici, sonuca kolay ulasir. 2.tarz yaratici olur genelde.)
- ne tarz gelistirme yaparsin? Test Driven Development mi, Behavioral Driven Development mi, ya da bir baska sekilde mi?
- Object Oriented Programlamanin gerekliliklerine inaniyor musun? neden? Yoksa fonksiyonel programlama mi daha mantikli geliyor? (yapilan ise göre sirketlerin sececegi gelistiriciler farkli olur)
- bilgini Horizontal mi tanimlarsin yani cok konu bilip az mi uzmanlasirsin? yoksa Vertical mi yani daha az konuda bilgin vardir ama bildigin konuda cok derinlesmissindir. (Bir takimda bu iki tarzda da uzmanlasmis insana ihtiyac vardir. bazi sorunlar uzmanlasma gerektirir, bazi sorunlar da cok disiplidir yani cok alanda bilgi gerektirir, cok derinlesmeye gerek yoktur)
- bir problemle karsilastiginda hangi yöntemi kullanirsin, o konuda kitaplari mi okursun, stackoverflow dan mi bakarsin, github dan mi kodlari incelersin, yoksa o konuyu cözen bir kütüphane/arac var mi bakarsin, yoksa kendin mi cözüm bulmaya yönelirsin (bir takimda her tipde gelistirici olmalidir, duruma sarta göre her bir yöntem avantajli veya dezavantajli olabilir)
- test kod yazarken ne gibi araclar/kütüphaneler/diller kullaniyorsun.
- bunlarin yaninda gelistiricinin algoritma yazma becerisini, kullanilacak dil konusunda yeteneklerini ölcecek temel sorular sorulmali. ama bunda sorular minimum ezber gerektirecek akil yürütme gerektirecek sorular olmali.
kisisel görüsüme göre bir gelistirici takimi olustururken güzel bir karma, güzel bir harmoni yapmak gerekir. sirketlerin en cok düstügü hata hep ayni tarz gelistiricileri ise almalari, bu da farkli sorunlarda takilmalarina cözüm üretememelerine neden oluyor. bir futbol takimi gibi düsünmek gerekir 11 kisinin 11i de golcü olmaz, kaleci de lazim, defans da. takim lideri de bu farkli yeteneklerin tarzlarin arasindaki uyumu da bilmeli hangi durumda kimin daha verimli olacagini idrak etmis olmali. her problem hep ayni tarz gelistirici ile cözülemez. problemin yada isin tipine, gereksinimlerine, zamanin darligina/genisligine göre uygun gelistirici secilir ve cözüme o sekilde ulasilir. bilisim alandinda calisan insan kaynaklari personeli ve gelistirici takim liderlerinin de gelistirici tiplerine hakim olmasi gerekir.
- emrahday (10.11.16 13:33:34 ~ 13:36:29)
1