Teknik röportaj. Web geliştirme alanında bir röportaja hazırlanmak ve röportajın kendisi

Burada pek çok şeyi tartışabilirsiniz: paketleme sorunlarından yarışlara ve etkinlikleri engellemeden çağırma sorunlarına kadar.

Aynı zamanda, adaylar sıklıkla kendilerini gömüyorlar, ellerinden "daha akıllı" yanıtlar vermeye çalışıyorlar, güçlü olmadıkları konulara değiniyorlar. Eğer aday belirli bir konuda gerçekten güçlüyse bu yöntem hızlı bir şekilde ileri konulara geçmenizi ve adayın seviyesini daha iyi belirlemenizi sağlayacaktır.

“Teknolojik” bir görüşme ne kadar etkilidir?

C# dili bilgisi ile çözme yeteneği arasında bir bağlantı var mı? üretim görevleri? Bu o kadar basit değil. İki aşırı durum ayırt edilebilir.

İlk önce, tüm teknik soruları ideal olarak yanıtlayacak, ancak iş sorunlarını çözemeyecek (veya istemeyecek) teknoloji meraklıları var. Tipik olarak, bu tür adayların çok iyi bir hafızası vardır ve birçok soruyu neredeyse hiç düşünmeden yanıtlarlar. Onları konfor alanlarının dışına çıkarmaya çalışmak (bir konuyu bir tasarıma, dile veya platforma çevirmek), bilmedikleri sorunları çözerken nasıl davranacaklarını daha iyi anlamalarını sağlayacaktır. Potansiyel müşteriler ve Proje Yöneticileri, adayın sosyal becerilerini kontrol ederek bu tür adayları ayıklamalıdır (bu kolay değildir, ancak genel olarak mümkündür).

ikinci olarak Teoride güçlü olmayan harika uygulayıcılar var. Böyle bir adayın elenme ihtimali vardır ancak deneyimli bir görüşmeci teorik alandan daha pratik bir alana geçerek böyle bir adayın yeteneklerini belirlemeye çalışabilir. Şu anki meslektaşlarımdan biri tam olarak bu kategoriye giriyor ve bir röportaj sırasında ileri düzey soruların çoğuna cesurca "bu saçmalığı bilmediğini" yanıtladı. Ancak açık sözlülüğü ve pratikliği en başından beri galip geldi, bu yüzden neredeyse bir yıldır aynı ekipte çalışıyoruz.

Genel olarak teknoloji görüşmelerine dayalı makul bir yaklaşım oldukça iyi sonuçlar. Tam teşekküllü bir imzalayanın Kart Tablosu hakkında bilgi sahibi olmasına gerek yoktur, ancak çöp toplamada nesillerin yararları hakkında nispeten kolay bir şekilde cevap verebilir ve hatta SOLID ilkelerini bilmeden bile kesinlikle uyum ve birleştirme, testlerin rolü ve hakkında konuşabiliriz. tasarım desenleri.

Yetenekli bir geliştirici mutfağını en azından ileri düzeyde bilir, dolayısıyla “teknolojik” kriter diğerleri kadar iyidir.

Mülakat iki yönlü bir süreçtir

Herhangi bir uzman için mülakat iki yönlü bir süreçtir: Görüşmeyi yapan kişi adayı değerlendirir ve aday da şirketi görüşmecinin değerlendirmesi yoluyla değerlendirir.

Bu yüzden adayın teknik bilgisini veya analitik becerilerini test etmeyen görüşmeler beni şaşırtıyor. Beni korkutan en az iki şey var: birincisi, sorular ve tartışmalar sadece adayın seviyesini değil aynı zamanda benim (aday olarak) çalışmak zorunda kalabileceğim görüşmecinin seviyesini de gösteriyor. İkinci olarak, belirsiz sorular aracılığıyla adayların zayıf bir şekilde taranması, ekibin ortalama seviyesi hakkında şüpheler uyandırır, çünkü bu durumda birçok "rastgele" kişi takıma dahil olabilir.

Bunun sadece benim kişisel gözlemim olduğunu ve her görüşmecinin bir C# MVP'sine C# dili hakkında soru sormaya hazır olmadığını düşünebilirsiniz (her ne kadar kişisel olarak bunda bir sorun görmüyorsam da). Ancak Kıdemli ve hatta Orta pozisyonlar için görüşme yapan meslektaşlarımın çoğu aynı tabloyu görüyor.

İç pazar "aşırı ısındığı" için ilginç bir teknik görüşme ek bir olumlu rol oynayabilir: onun yardımıyla adaya ilginç bir ekipte çalışacağını gösterebilirsiniz, bu da dengeyi lehinize çevirecektir.

ZY Eğer röportajlarıma katılırsanız (sonuçta Dünya kare şeklindedir;), bu konudaki fikrinizi duymak ilginç olacaktır.

Teknik görüşme hakkında
Bir ürününüz, kurulu bir ekibiniz ve finansmanınız var. Siz (ekip) iyi çalıştınız ve yönetim, buna göre gelişimi hızlandırmak, kaliteyi artırmak ve kaynakları harcayabilmek için birini işe almak için daha fazla para ödemeye hazır. teknolojik gelişmeürün. Zaten hh'de iyi bir maaş ve ilginizi çekebilecek canlı bir açıklama içeren bir ilan yayınladınız, 20 aday seçtiniz ve yarın görüşmelere başlayacaksınız. Geriye kalan tek şey tam olarak ne sorulacağını bulmak. Ortak durum? O halde kediye hoş geldiniz.

Belki durum biraz ütopik ama pek çok vaka da bu yazının kapsamına giriyor. İstisnalar, "dün insanlara ihtiyaç duyan" veya "dün insanlara ihtiyaç duyan" şirketlerdir. yeni kişi hiç ihtiyaç duyulmuyor, sadece “piyasayı gözlemliyorlar” ve (veya) “nadir bir profesyonel” bulmayı umuyorlar.
Başka bir deyişle bu, ekibini güçlendirmek için para ve çaba harcamak isteyenlere yönelik bir makaledir.

Başlangıç ​​olarak, bir insanı anlık bir ihtiyaç için işe almanın son derece zararlı olduğunu belirtelim. Diyelim ki şu sıralar sizin için sunucu kısmının gelişimi biraz yavaşlıyor. Bu, sunucu tarafı bir programcı tutmanız gerektiği anlamına mı geliyor? Aslında hayır. Oldukça aktif bir gelişiminiz varsa farklı parçaların önceliği kaçınılmaz olarak değişecektir. Bu anlamda bir kişiyi bir sonraki ay için bir görev için işe almak aptallıktır. Sonuçta bir ay geçecek ama yine de o kişiye sahip olacaksınız. Ve eğer bu ay sunucu tarafı geliştirmede bir delik açarsanız, gelecek ay sunucu tarafının arayüzün perçinlendiğinden daha hızlı yazıldığı ortaya çıkacak. Peki gelecek ay bir kullanıcı arayüzü programcısı mı tutmamız gerekiyor? Veya sunucu tarafındaki "zayıf bağlantıyı" mı tetikleyeceksiniz? Hayır, buna farklı şekilde yaklaşmak gerekiyor. Ürün geliştirmede daha önce neler yaptığınıza bakın. Satış görevlilerine, yatırımcılara veya gelişim hedeflerini kim belirlerse ona sorun ve örneğin bir yıl öncesinde sizi nelerin beklediğine dair bir resim oluşturmaya çalışın. Şimdi geçmişte ve gelecekte ne tür bir kişinin daha verimli çalışmanıza yardımcı olacağını hayal edin. Umarım kendinizi birden fazla kişiye tanıtmışsınızdır. Büyük olasılıkla takımı burada ve burada güçlendirmenin mümkün olduğu ortaya çıkacak. Ve eğer bir yerde çok güçlü (ve buna bağlı olarak çok zayıf) ortaya çıkarsa, mevcut ekipten biri faaliyetlerini "değiştirmeyi" kabul edebilir.

Yani, “ideal” adayların birkaç portresini çizdiniz. Teknik bir görüşme yapmanın zamanı geldi. Bu arada, umarım şirketinizde çalışanları işe alma kararını etkileyen şey teknik görüşmedir? Genellikle bir şirketten “aile” veya “iyi vakit geçirebileceğiniz bir ekip” olarak bahsederler. Yani bir şirket hâlâ bir aile değildir. Ve bowlinge gittiğin arkadaşların değil. Elbette bir kişi kleptomani veya cüzzam hastasıysa, teknik mülakatı en iyi o geçse bile onu işe almak tehlikelidir. Ancak kişisel niteliklere fazla takılıp kalmayın. Prensip olarak, teknik bir görüşmeden önce veya sonra, kişinin bir tür numara yapıp yapmayacağını öğrenmek gerekir ve bu anlamda böyle "teknik olmayan" bir görüşme "eşik" rolüne sahip olacaktır - geçemeyen kişi kesinlikle şirkette çalışmayacaktır, ancak geçerse o zaman "şirketin canı" mı yoksa sadece vicdanlı bir çalışan mı olduğu önemli değildir. Ama hepsi bu, aslında diğer tüm kararların teknik görüşmeyle belirlenmesi gerekiyor. Şirketinizin İK'sı, adayları kariyer hedefleri ve "kendilerini 10 yıl sonra nerede gördükleri" veya "şirketin sizi neden işe alması gerektiği" gibi sorularla rahatsız ediyorsa, o zaman teknik yetenek aramak için henüz çok erken. Öncelikle yeni bir İK bulmanız gerekiyor.

Peki teknik bir röportajda ne sormalısınız? Test oluşturulsun mu? Kişinin önceki işinde ne yaptığını öğrendiniz mi? Ayarlamak Zor bir soru? Bana braingames.ru'dan bir sorun mu verdin?
Bu seçeneklere sırasıyla bakalım.

Test görünebilir kullanışlı şey zaman kazanma. Ancak iyi bir test oluşturmak oldukça zordur - bu görevin kendisi çok zaman harcamayı gerektirir. Kötü bir sınav, yalnızca çok fazla görüşmeye gitmeyen ve "standart" soruların yanıtlarını bilmeyen adayları eleyebilir. Çok kötü bir test, biraz farklı şeyler yapmış olan gerçekten harika adayları eleyebilir. Genel olarak test yalnızca bir tür birincil filtredir. Önemsiz olduğunu düşündüğünüz beş soruya cevap veremeyen birini işe alamazsınız. Ama kesinlikle bir kişiyi testten sonra ona tek kelime sormadan işe almamalısınız.

Son işinizde ne yaptınız? Biliyorsunuz, başvuran önceki işinde yaptığını artık sizinle yapamayacak. Prensip olarak, sohbet için bir konu bulmak amacıyla böyle bir soru sorabilirsiniz. Ama dürüst olmak gerekirse, zaman kaybı gibi görünüyor. Uygulamamdan bir örnek vereceğim.


- Son işinde ne yaptın?
- Kentsel iletişim sistemini en uygun rota arayışıyla simüle eden karmaşık bir sistem vardı ve (...)
- Dijkstra'nın algoritması nedir?
- Evet, ben de buna benzer bir şey duydum.

Peki ne öğrendik? Boş ver. Bir tür karmaşık proje. Ne tür bir proje olduğu, bu çalışanın tam olarak ne yaptığı, sonunda neyi iyi yapmayı öğrendiği gerçekten belli değil. Kişi hakkında hiçbir şey öğrenemeden 5 dakikamızı boşa harcadık. Elbette yarım saat ayırıp her şeyi halledebilirsiniz. Ama iki "ama" var.
Öncelikle zamanınıza değer verin. Her adaya 4 saat ayırırsanız gerçekten değerli olana ulaşamayabilirsiniz. Genel olarak, benim görüşüme göre, görüşme kesinlikle bir zaman dilimiyle, örneğin bir saatle sınırlı olmalıdır. Ve bu saatte, karar vermek için ihtiyacınız olan her şeyi kişiden atmaya çalışın.
İkincisi, kişinin kim olduğuna fazla takılmayın. Şirketinizde kim olabileceğini değerlendirmeye çalışın. Adayınız son işinde sizin bir ayda tamamladığınız bir modülü bir haftada tamamladığını mı söylüyor? Belki son işimde de öyle harika iş süreçler ve bir yığın hazır kod ve onun da bu modülü tam olarak sizin kadar yapmasını ister miydiniz? Yoksa adayın son işinde dikkate değer hiçbir şey yapmadığını mı düşünüyorsunuz? Pekâlâ olabilir. Ama belki de bu, üçüncü sınıf "boynuz ve toynaklarla" bitki örtüsüne sahip yetenekli bir kişidir ve tüm potansiyeliniz ortaya çıkacaktır! İnanın bana, birçok durumda böyle bir kişi için, başarılı bir uzmandan çok daha fazla savaşmaya değer.

Zor bir şey mi sormalıyım? Diyelim ki dün Habré'de Java'daki karma kodun bir adres değil (her zaman düşündüğünüz gibi) rastgele bir sayı olduğunun ortaya çıktığını okudunuz ve adayın bunu bilip bilmediğini merak ettiniz. Veya geçen hafta takma adları araştırıyordunuz ve “[”nin dil olarak bir bash betiğinin parçası olmadığını, “[” adında normal bir program olduğunu öğrendiniz. Adayın bunu bilip bilmediğini öğrenmek faydalı olur mu?
Burada soru ve cevap seçeneklerini tekrar denemeye değer.
Rol yapma.

- Bu nesnenin adresi

Ve ikinci seçenek:

Object.hashCode() nedir?
- Evet, rastgele sayı üreteci var, dolayısıyla geri dönüyor.

Bu soruya 3 dakikanızı ayırdınız. Birinci ve ikinci adayı nasıl karşılaştırırsınız? Birinin diğerinden daha iyi olduğunu söyleyebilir miyiz? Belki ikincisi boş zamanlarında grep kodunu karıştırıyordu. Veya çalışmak yerine habr okuyun. Ya da belki onun yerine değil. Ama bu sana bir şey ifade ediyor mu?

Bir kişinin uygulamanın inceliklerini bilip bilmemesinin bir önemi yoktur. Tam tersine küçük şeyleri bilmenin çok önemli olduğuna inanıyorum. Java geliştiricisi ararken bile, assembler bilen bir kişi, bilmeyen birinden daha değerlidir benim için. Ancak ne yazık ki o kadar çok küçük şey var ki doğrudan "Ne olduğunu biliyor musun?" sorusu neredeyse hiçbir zaman mantıklı gelmiyor. Ama zamanımız kısıtlı olduğu için yüzlerce şeyi soramıyoruz.

Peki ne sormalıyım?

Bana öyle geliyor ki, genellikle yaptığınız şeyler bağlamında bir konuşma yapmak ve adayın sizin sıklıkla çözdüğünüz sorunları nasıl çözdüğünü izlemek en iyisi.
Diyelim ki uygulamanızın UI mantığı ve sunucu kodu var. Adaya neyin daha ilginç olduğunu düşündüğünü sorun.
Sunucu kodu? Harika. Programınızdaki tipik bir kod parçasını hayal edelim. Adayın hangi soruları olduğu ve nasıl bağlantı kurduğuyla ilgileniyoruz teorik bilgi pratik ihtiyaçlarla.
Bu soruna şunu söyleyelim:

Bir kod parçacığı var

geçersiz x(Liste A)

...bazı işlemler

Adaya soru - varsayalım ki bu kodda listeyi şu şekilde sıralamamız gerekiyor: alfabetik sıra. Ne yapacaksın? Bu arada evet, adaya hemen Collections.sort'tan bahsedebilirsiniz - biz " sözlük"Kontrol ediyoruz.
Diyelim ki adayımız şöyle bir şey yazdı

geçersiz x(Liste A)

Liste b = new ArrayList(a);

Koleksiyonlar.sort(b);

...b ile bazı işlemler yapılıyor

(Umarım adayımız bu sorunu bu şekilde çözmüş ve sıralamaya başlamamıştır).

Ancak burada asıl önemli olan sorunu çözmek değil. Önemli olan tartışmadır.
Neden yarattı? yeni liste eskisini kullanmadın mı? Bu her zaman doğru mudur?
Neden başka bir şey değil de ArrayList'i kullandınız? Orada başka ne olduğunu biliyor mu?

En ilginç şey, buradaki tartışmanın neredeyse sonsuz olabilmesidir. Aday şunu söyleyecektir: ArrayList daha iyi bunun rastgele erişim olduğunu söylüyorsunuz, ancak sıralamanın yine de verileri sıralamadan önce bir diziye kopyaladığını ve ardından geri döndürdüğünü söylüyorsunuz. Adayın görüşüne göre ArrayList şimdi daha mı iyi? Ne, artık değil mi? Yoksa hala daha mı iyi?

Bir adayla yapılan bir konuşma onun düşünce tarzını ortaya çıkarmalıdır. Bakın ne kadar ayrıntı biliyor. Yeni bir şeye nasıl tepki veriyor? Ve en önemlisi ona verdiğiniz bilgileri doğru bir şekilde kullanabilecek mi? Sonuçta, soyut "her şeyin bilgisi" genellikle çok önemli değildir; sonuçta yakınlarda meslektaşlar vardır ve sorunlu konu sıklıkla tartışılabilir. Meslektaşlarınız tavsiye verebilir, ancak yeni bir çalışanın yerine kod yazmayacaklar, bu nedenle tavsiyeyi dinledikten sonra daha iyi bir program yazıp yazamayacağını anlamaya çalışın.

Ya da başka bir örnek diyelim.

"Çöp toplayıcı nedir" diye sormayın. “Kaç nesil var?” diye sormayın. Ne fark eder? Bir kişinin size gc'nin nasıl çalıştığını anlatıp anlatamaması ne fark eder? İşiniz için önemli olan tek şey, bir kişinin bir performans sorunu ortaya çıkarsa çözüp çözemeyeceği ve onun hakkında yürek ısıtan bir hikaye anlatıp anlatamayacağı olabilir. nesiller boyu montaj veya eşzamanlı işaret taraması gc hakkında.
Kimsenin GC'nin nasıl çalıştığını bilmeden ilginç sorunları çözebileceğini söylemiyorum. Elbette bir kez şanslı olabilirsiniz. Ancak pratikte bilgi son derece önemlidir. Sorun farklı; bir şeyin nasıl çalıştığını söyleyebilen herkes o şeyle ilgili sorunu çözemez. Ve genel olarak konuşursak, sezgi ve genel teknik bilgi, bir sorunu çözmek için genellikle bir yerde okunan bir algoritmanın tanımından daha önemlidir.
Örneğin, gc için bazı pratik problemleri tekrar vermek iyi olacaktır.
Diyelim ki “2 gigabyte yığını olan bir program başlattınız ve yavaş çalışıyor, ne yapacaksınız?”

Kalçamı büyüteceğim

Daha hızlı olacak mı? Ve en ilginci şu soruyu cevaplamadan önce “daha ​​hızlı”nın benim için ne anlama geldiğini sormak gerekmez mi? Adayın aktarım hızı ile gecikme arasındaki farkı anlayıp anlamadığına bakın. Ne olduğunu veya farkın ne olduğunu sormayın. Sorunun yukarıda açıklanan formülasyonu göz önüne alındığında bir aday bu kadar önemsiz sorular sormayı düşünmüyorsa, pratikte bu soruları sormayacaktır. Ancak sohbet ettiğimizi unutmamalıyız. Aday doğrudan taş ocağına atlarsa onu durdurun ve ona durumu anlatın. farklı özelliklerüretkenlik. Aday bunları hiç duymamıştı ama hemen kalçayı büyütmenin bir şeyi iyileştirebileceğini, ama bir başkasını kesinlikle kötüleştirebileceğini mi fark etti? Peki, bu harika!

Bunun gibi sayısız örnek verilebilir. En iyi yanı, bu tür sorunların kolayca ortaya çıkabilmesi ve sayıları çok az olmasıdır; her yeni adaya farklı şeyler sorabilir ve sorunları belirli bir adaya göre uyarlayabilirsiniz.

Başarısız röportajlar hakkında internette çok fazla acı yayılıyor. Bazıları görüşmecilerin sorularını beğenmedi, bazıları alay konusu oldu, bazıları ise VKontakte sayfalarına göre değerlendirildi. Mülakatı yapanlar başvuru sahiplerini takip ediyor ve bu günlerde personel durumunun ne kadar kötü olduğu ve deneyimsiz programcıların zor teknik sorularına ne kadar aptalca cevaplar verdikleri konusunda yemin ediyorlar.

Ne yazık ki, görüşmeleri geçmek ve yürütmek için evrensel kurallar yoktur ve olamaz, çünkü çalışanlar yalnızca teknik becerilerine ve kişisel niteliklerine göre değil, aynı zamanda bazı (çoğunlukla örtülü ve çok öznel) "profil" eşleştirilerek de seçilmektedir. görüşmecilere göre, onların ekibine veya şirketine uyar. "Görüşmelerin doğru şekilde nasıl geçileceği" serisindeki rehberlere gelince, bunlar genellikle yorumlarda daha az acıya neden olmazlar çünkü bunlar çok özneldir ve birinin sorunlu noktalarına dokunacağından emindir.

Profesyonel kariyerim boyunca, çitin her iki tarafında da bulundum, ancak muhtemelen onları geçmek yerine biraz daha teknik röportajlar yapmak zorunda kaldım. Ancak bu süre zarfında, teknik bir görüşme sırasında beni korkutan ve aklımda daha fazla sohbete hemen son veren bir dizi "moda" biriktirdim. Görüşmeyi yapanın ve başvuranın bakış açısından konuşmak istediğim şey buydu. Makalenin kişisel öznel izlenimlerimi yansıttığı ve bir "röportaj rehberi" iddiası taşımadığı konusunda hemen bir çekince koymak isterim. Öte yandan, bu, başarısız bir görüşmeden kaynaklanan anlık bir öfke patlaması değil, olumsuz temelde de olsa, bana seçenekleri ayıklamama veya potansiyel olarak uygun bir adayı korkutmama izin veren uzun ağırlıklı bir kriterler dizisidir. kendim.

Mülakatlarda sizi neler rahatsız ediyor veya strese sokuyor? Yorumlarda paylaşın.

Başvuranın bakış açısından röportaj

Bir programcı her iş aradığında birçok teknik görüşmeden geçmek zorundadır. Ofislerde dolaşır veya Skype'ta konuşur, sorunları çözer veya test görevleri, zorlu teknik sorulara yanıt vererek kendini kanıtlamaya çalışıyor en iyi taraf. Ancak yarın potansiyel olarak bu insanlarla çalışmak zorunda kalacağını düşünerek kendisiyle röportaj yapan ve test yapan kişileri de kendisi değerlendiriyor. Ve teknik görüşmecilerin bir adayı ilginç bir pozisyondan korkutup uzaklaştırmasının birçok yolu vardır. Size kişisel olarak beni her zaman korkutan şeyleri ve bir görüşmeci olarak nelerden kaçınmaya çalıştığımı anlatacağım.1. "Başka hangi teknik görüşme?"
Teknik görüşme konusunda beni her zaman endişelendiren ilk ve en önemli şey onun yokluğudur. Teknik uzmanlarla (potansiyel olarak gelecekteki meslektaşlar) yapılan tüm konuşmanın mesleki deneyime ilişkin sorulara dayandığı görülüyor: nerede çalıştı, hangi projeler üzerinde çalıştı, bunlarda hangi işlevi yerine getirdi. Teknoloji veya bilgi ile ilgili - "Ders kitabı ne renk?" düzeyindeki sorular. Mesaj Aracısının ne olduğunu biliyor musun? Harika, seni götüreceğiz!

Mülakatlara yönelik bu yaklaşım beni her zaman potansiyel bir işverenin aleyhine çevirdi. Ne yaptığımı gerçekten bildiğimi kontrol etmek için bana tek bir soru bile sormadılar. Görünüşe göre benimle röportaj yapan insanlar ya konu hakkında hiçbir şey anlamıyorlar ve anlayan en az bir kişiyi arıyorlar ya da çaresiz ve herhangi biriyle mücadele etmeye hazırlar. Her halükarda, bu şekilde oluşturulmuş bir ekipte çalışmayı pek istemezdim.

2. “Peki, orada ne yapıyordun…”
Teknik görüşmeler sırasında başvuru sahiplerine karşı bu kadar sıklıkla küçümseyici tutumların ortaya çıkması şaşırtıcıdır. Evet, belki de kemerinizin altında bir dizi projeye sahip sert ve deneyimli bir programcısınız, çoğu size göre tamamen beceriksiz olan insanlarla gereksiz bazı röportajlar uğruna son derece önemli işlerden koptunuz. Ancak unutmayın ki şu anda şirketinizi ve ekibinizi temsil ediyorsunuz ve bir kişi mutlaka sizin takımdaki iklime ve bu takımda ona nasıl davranacağına ilişkin davranışınıza göre bir değerlendirme yapacaktır. İlk beş dakikadan itibaren değerli kodunuzun yanına yaklaşmasına izin verilmemesi gerektiğini anlamış olsanız bile, başvuru sahibine karşı kibar ve saygılı olun.3. “Özgeçmişinizde adınız/soyadınız/soyadınız yanlış yazılmış!”
Bu hiç de teknik değil ama yine de teknik görüşmelerde bile yaygın bir sorundur. Neyse ki oldukça basit ve yaygın bir ismim var ve bu tür sorunlar başıma gelmedi. Bununla birlikte, belirli isimlerin ve hatta soy adlarının var olmadığına kesinlikle inanan şaşırtıcı sayıda insan olduğunu biliyorum. Sizi doğru adın "Danila" değil, "Daniil" olduğuna veya "Alena" adının değil, yalnızca "Elena" olduğuna ikna edecekler. Belgelerinde düzeltmeyi ve “doğru” yazmayı teklif edecekler. Nadir veya sıradışı isimler ve inanın bana, bu inanılmaz derecede sinir bozucu. Yani basit bir kural var: Var olmayan böyle bir isim yok. Pasaportta yazıldığı gibi doğru yazın. Başvuru sahibine saygı gösterin ve onu pasaporttan özgeçmişe kopyalayamayacak kadar aptal olarak görmeyin. isim. Bir hatadan şüphelenseniz bile bunu daha incelikli bir şekilde açıklığa kavuşturabilirsiniz.4. “Tüm yuvarlak pencereleri temizlemek için kaç golf topu gerekir? okul otobüsü San Francisco'nun tahliyesi sırasında en fazla 3 tartım kullanılarak bir nikel boyutuna mı küçültüldü?
Rögar kapaklarından bahsetmeden röportajlarla ilgili hiçbir makale tamamlanmış sayılmaz. Bunu, standart dışı sorunları hızlı ve baskı altında çözememekle ilgili kişisel görüşüm olarak düşünebilirsiniz. Ancak röportajlar sırasında zeka oyunlarının kesinlikle işe yaramaz olduğuna eminim. Daha doğrusu, bu harika yol Beyin Olimpiyatları ile, çalışmak yerine gün boyu yeni zeka oyunları alışverişinde bulunacak tam bir beyin dehası departmanını işe alın. Gerçek programcı doğal çevre yaşam alanı, hatta çok havalı ve standart dışı görevler, hala nadiren stres altında kod yazıyor, ancak günün çoğunu oturup nispeten sakin bir atmosferde kodu nasıl güzel bir şekilde yöntemlere ayırabileceği hakkında düşünerek geçiriyor. Bu süreçte zor problemleri çözmek için asla “beyin kaslarını” kullanmaz.5. "Yanlış. Daha öte."
Elbette görüşmeye gelen kişileri eğitmek görüşmecinin işi değildir. Ancak başvuru sahibi soruyu cevaplayamadıysa ancak hala ilgileniyorsa, bir sonraki soruya geçmeden önce onu doğru çözüme yönlendirmek veya en azından doğru çözüme yönlendirmek mesleki etik meselesidir ve burada ona yardımcı olacaklarını ve öğreteceklerini gösterir. bir şey olursa teknik sorunlarla baş başa bırakılmayacaktır. Ona en azından birkaç kelime söyleyin, neyi Google'da arayacağını, ne okuyacağını. Sonuçta ilgi doğru karar görevler başlı başına pozitif kalite Teknik bir uzmansanız, böyle bir kişinin hatalarını ya da yanlışlıklarını küçümseyerek moralini bozmamalısınız.

Görüşmecinin bakış açısından röportaj

Her yeni bir pozisyon açıldığında, önde gelen bir uzman veya bölüm başkanının birçok teknik görüşme yapması gerekir. İnsanlar görüşmelere farklı teknik deneyim, eğitim düzeyi ve beklentilerle gelirler. Mülakat yapmak için bir konuşma planı düşünmeniz, bir soru listesi hazırlamanız ve ardından bu soruların cevaplarından kişinin pozisyona uygun olup olmadığını anlamaya çalışmanız gerekir. Ve bazen başvuru sahipleri, görüşmeler sırasında durumu hemen açıkça ortaya koyan şeyler söylerler: Hayır, bu kişiyle birlikte çalışamazsınız. Başvuru sahiplerinden beni kişisel olarak endişelendiren bazı anahtar ifadeleri aşağıda bulabilirsiniz: 1. “Sorularınızın bazıları teorik. Teoride güçlü değilim, pratikte tecrübeliyim! Daha iyi bir test yapalım!”
“Teorik” kelimesi genellikle sanki kötü bir şeymiş gibi küçümseyici bir çağrışımla telaffuz edilir. Ama sorun bu bile değil. Sizce bu cümlenin öncesinde görüşmeyi yapan kişinin Cauchy teoremini kanıtlama talebi var mı? Vermek kesin tanımüçüncü normal form? Hiç de bile. Aşağıdaki sorulara yanıt olarak bu tür ünlemler duydum:

• == ile karşılaştırmanın Java'daki eşitlerle karşılaştırmadan farkı nedir?
• karma haritasının nasıl çalıştığını bize anlatın.
• REST'in ne olduğunu kendi sözlerinizle açıklayın.
• İşlemler nedir ve neden gereklidir?

Evet, belli bir bakış açısına göre, hemen burada ve şimdi bir kod satırı yazmanızı gerektirmeyen herhangi bir programlama sorusu teoriktir. Ancak eminim ki, belirli bir alanda yeterince geniş deneyime sahip bir kişi, en temel şeyleri kendi sözleriyle açıklayabilmelidir veya en azından bunları bilmemenin normal ve doğal olduğunu iddia etmemelidir.2. “İspanyol Engizisyonu'nun burada olmasını beklemiyordum! Tıpkı enstitüde sınava girmek gibi. Genellikle nerede çalıştığını ve ne yaptığını soruyorlar.”
Teknik görüşme için geldiniz. Teknik bir röportajda, teknik becerilerinizi test etmek için size teknik sorular sorulacaktır. Test metodolojisini ve soru seçimini görüşmecinin vicdanına bırakın; sorular size her zaman yeterli gelmeyebilir ancak görüşmeci yanıtlarınızı analiz ederek hakkınızda hangi bilgileri almak istediğini tam olarak bilir. Bilginizi test etmek için değil, sizi düşünmeye ve düşünce akışınıza bakmaya zorlamak için birçok soruya ihtiyaç vardır. Ayrıca, tüm soruların tam olarak doğru bir cevap gerektirmediğini ve size sorulan soruların en az yarısını net bir şekilde yanıtlarsanız, bunun zaten iyi bir izlenim bırakacağını unutmayın.3. “Bunu bilmeme gerek yok, ben daha üst seviye görevlerde uzmanım!”
Uzmanlığı programlamanın temellerini bilmemekle karıştırmayın. Geliştiricilerden mobil uygulamalar Sıralama ve arama algoritmalarıyla ilgili sorulara yanıt olarak ön uç programcılardan TCP/IP yığın protokolleri hakkında benzer şeyler duydum. “Bunu neden bilmem gerekiyor, her şey standart kütüphanede, daha çok çalışıyorum yüksek seviye" Bu tür ifadelere yanıt olarak, uzun zaman önce, algoritma bilgisizliğinden kaynaklanan "saf" bir çözümün eleştiriye dayanmadığını gösterme umuduyla, sinsice gizlenmiş algoritmalarla ilgili birkaç küçük sorunla karşılaştım. en azından kendi kendine eğitimi teşvik edin. Üstelik bunlar yapay olarak kurgulanmış görevler değil, her gün gelişim içerisinde ortaya çıkan şeyler. Her kod bir algoritmadır. Temel algoritmaları ve veri yapılarını anlamak herhangi bir programcı için önemlidir ve İnternet protokolleri temeldir; bilgi olmadan bir bilgisayarın sınırlarını aşan herhangi bir şeyi yetkin bir şekilde yazmanın imkansız olduğu temeldir.4. "Ve kendinizi! / Bana kodunu göster! / Ama GitHub'ınıza gittim ve şu var…”
Bir görüşmecinin isteyeceği son şey, bir kişiyi işe almak ve ardından onun kod tabanını eleştirmesini dinlemek zorunda olmaktır. Evet, büyük ihtimalle kusurludur. Evet, teknik borç her yerde ve herkeste var. Her kodda eleştirilecek bir şey vardır. Ancak kendinizi gerçekten o kadar havalı buluyorsanız, kodunuzda bariz sorunlar görüyorsunuz. potansiyel işverenler- bunu yapıcı bir olumluya çevirin: Nasıl gelişebileceğimi biliyorum, bu konuda deneyimim var, size fayda sağlayabilirim.5. "Haklı değilsin!"
Elbette her şey olabilir, ancak görüşmecinin hatalı olup olmadığı veya yeterliliği konusunda şüpheleri olup olmadığı konusundaki fikrinizi görüşmenin sonuna kadar saklamanız daha iyi olur. Sonra Google'a yazın ve hanginizin haklı olduğunu bulun. Teknik görüşme, tartışma veya kendini savunma yeri değildir ve buradaki sorular öncelikle size sorulmaktadır. Görüşmeci kendisinin anlamadığı bir şeyi sormayacaktır.

Çözüm

Mülakatlarda adaylardan duyduğum en güzel şey ne biliyor musunuz? "Aslında cevap vermedim değil mi? Bana bir parça kağıt verebilir misin? Sorularınızı yazıp evde çözeceğim, beni işe almasanız bile, en azından artık biliyorum.” Gözlerinizde gurur gözyaşları doluyor - bir kişiye bir buçuk saat harcamanız boşuna değildi, kendisi bu röportajdan bir şeyler öğrendi. Şu anda bu pozisyon için çok zayıf olsa bile, belki bu onu kendini eğitmeye teşvik edebilir ve bir veya iki yıl içinde tekrar gelecek, en iyi tarafını gösterecek ve bir iş bulacak - benim kariyerimde bir kez olduğu gibi.

Bu konuyla ilgili çok fazla soru almayı bekliyordum. Ancak tam tersi sorular - "Nasıl geçilir?" - Kalite Laboratuvarı'nın posta ve forumuna çok daha fazlası döküldü. Gelen talep üzerine bir cevap yazısı ile seriye devam ediyorum.

giriiş

2. Asansörü test edin!

Denklik sınıflarının ve sınır değerlerinin ne olduğunu açıkladınız. Bunları nasıl kullanacağınızı bilip bilmediğinizi kontrol etmenin zamanı geldi. Ve böylece asansörü test etmeniz isteniyor. Veya bir kalem. Veya bir hesap makinesi, kot pantolon, bir fincan. Ne olursa olsun. Görev büyük olasılıkla alışılmadık ve standart değildir. İşveren cevabınızdan ne bekliyor?

Yaratıcı düşünme yeteneği. Bu, testçiler için inanılmaz derecede önemlidir. "Bir bardağı test edin" sorulduğunda tek bir test bile yapamayan başvuru sahipleriyle defalarca karşılaştım. Büyük ihtimalle yeni bileşeni test ederken de sorun yaşayacaklar.

Yapılanma. Hesap makinesi testi sıfıra bölmeyle başlıyorsa, başvuru sahibi büyük olasılıkla testlere nasıl öncelik vereceğini bilmiyor ve teste verilen ana görevleri çok iyi anlamıyor.

Teoride çok basit görünen teknikleri kullanma becerisi. Her kattan her kata asansörle gitmeyi planlıyorsanız denklik sınıfları anlayışı teorinin ötesine geçmemiş demektir.

Her şeyi kullanma yeteneği olası türler test yapmak. Bir asansörün yük testi (tüm katlardan çağrı), bir bardağın hacimsel testi (içine maksimum su dökün), ekleme işlemi sırasında hesap makinesinin performansı, kot pantolonun kullanılabilirliği ve bir kalem için kullanıcı belgeleri - en iyi yollar“bildiğini” göster.

Böyle bir sorunun doğru cevabı, yukarıda açıklanan cevabın gerekliliklerinden kaynaklanmaktadır. Bilgilerinizi yapılandırın. Test edilen nesne hakkında mümkün olduğunca çok şey öğrenin. İşlevsel ve işlevsel olmayan testlerde neyi test edeceğinizi belirleyin. Her şeyi test etmek zorunda kalmamak için test paketinizi nasıl optimize edebileceğinizi düşünün. Ve hiçbir durumda cevabınıza belirli testlerle başlamayın - maymun çalışması, eylemleriniz üzerinde ön düşünmeyi gerektirmesi açısından yetkin testlerden farklıdır.

3. Bize test senaryolarının nasıl oluşturulacağını anlatın

Veya bir test planının nasıl yazılacağı, bir test otomasyon çerçevesinin nasıl oluşturulacağı veya başka herhangi bir şey. Bu soruyu cevaplarken yapabileceğiniz en kötü şey, aslında hiç yapmadığınız bir şeyin nasıl yapılacağını biliyormuş gibi davranmaya çalışmaktır. Konu size tanıdık geliyorsa ve nasıl cevap vereceğinizi biliyorsanız bayrağı alın! Düşüncelerinizin doğruluğundan emin değilseniz, “Bunu hiç yapmadım ama aşağıdaki eylemler dizisi bana doğru görünüyor…” gibi bir ifadeyle görüşmeyi yapan kişiyi bu konuda mutlaka uyarın. Samimiyet her zaman büyüleyicidir ve cevaptaki hatalar ciddiye alınmayacaktır. Emin olmadan “doğru” yaklaşımı söylerseniz, saçma sapan konuşursanız kimsenin sizi işe almak istemesi pek olası değildir.

Bu konuda uzun uzun tavsiyelerde bulunmayacağım veya ayrı bir makale yazacağım. Bu felsefi soruya nasıl cevap vereceğinizi bildiğinizden emin olun.

Bir önceki soru gibi bu soru da oldukça yaygındır. Google buna hazırlanmanıza yardımcı olacaktır.

Bu yazı için planlarım DNS kurulumu ve veritabanlarının sorgulanması ile ilgili hikayeleri içermiyor. Ancak takip etmeniz gereken bazı genel ipuçları var:

Birincisi, teknik bilgi eksikliği hızla telafi ediliyor ve işverenler bu konuya nadiren çok ciddi bir ilgi gösteriyor. İkincisi, kötü bir şekilde gizlenmiş cehalet her zaman güvensizliğe neden olur: Adayın geri kalan sözlerine güvenilebilir mi? Üçüncüsü, potansiyel bir işveren, yanlış bakış açısını savunan kişilerin işlerinde hata yapma olasılıklarının daha yüksek olduğu yönündeki fikrimi paylaşabilir. En azından test konusunda bilgili bir çalışanı işe almadım, ancak "Windows'un dinamik diskleri desteklemediğini" özenle savundum. Büyük olasılıkla, bunun ne olduğunu bilmediğini dürüstçe itiraf etseydi, karar farklı olurdu.

2. Önceki soruları çok iyi cevaplamadığınızı görürseniz, cevapları kendiniz başlatın, ancak daha iyi bildiğiniz konular üzerine.

Örneğin, MS SQL ile ilgili soruyu başarısız bir şekilde yanıtladıysanız, kendinize Oracle ile çalışma deneyiminiz olduğunu ve bu nedenle hızlı bir şekilde "yeniden profil oluşturabileceğinizi" söyleyin.

Tanıdık olmayan bir teknolojiyi veya aracı hızlı ve bağımsız bir şekilde anlama becerisine, mevcut bilgiden daha fazla değer verilir. Kendinizi övmekten çekinmeyin. Rational Robot'u anlamadığınızı söyleyen sözlerinizden sonra görüşmeyi yapan kişi biraz çekinir - gururla Silk Test'i yalnızca bir hafta içinde çözdüğünüzü ve bu konuda çok şey yapmayı başardığınızı (spesifik olun) söyleyin. Doğal olarak burada da doğruyu söylemek gerekiyor!

Önemli olan korkmamak. Siz iş arıyorsunuz, işveren ise işinin ehli bir çalışan arıyor. İkiniz de sonuçla ilgileniyorsunuz. Yanlış iş için işe alınmak, reddedilmekten çok daha kötüdür. Deneyin, sinirlenmeyin, öğrenin! Ve kendiniz için geliştirin; bir röportajda "gösteriş yapmak" için değil. İyi şanlar!

Başarısız röportajlar hakkında internette çok fazla acı yayılıyor. Bazıları görüşmecilerin sorularını beğenmedi, bazıları alay konusu oldu, bazıları ise VKontakte sayfalarına göre değerlendirildi. Mülakatı yapanlar başvuru sahiplerini takip ediyor ve bu günlerde personel durumunun ne kadar kötü olduğu ve deneyimsiz programcıların zor teknik sorularına ne kadar aptalca cevaplar verdikleri konusunda yemin ediyorlar.

Ne yazık ki, görüşmeleri geçmek ve yürütmek için evrensel kurallar yoktur ve olamaz, çünkü çalışanlar yalnızca teknik becerilerine ve kişisel niteliklerine göre değil, aynı zamanda bazı (çoğunlukla örtülü ve çok öznel) "profil" eşleştirilerek de seçilmektedir. görüşmecilere göre, onların ekibine veya şirketine uyar. "Görüşmelerin doğru şekilde nasıl geçileceği" serisindeki rehberlere gelince, bunlar genellikle yorumlarda daha az acıya neden olmazlar çünkü bunlar çok özneldir ve birinin sorunlu noktalarına dokunacağından emindir.

Profesyonel kariyerim boyunca, çitin her iki tarafında da bulundum, ancak muhtemelen onları geçmek yerine biraz daha teknik röportajlar yapmak zorunda kaldım. Ancak bu süre zarfında, teknik bir görüşme sırasında beni korkutan ve aklımda daha fazla sohbete hemen son veren bir dizi "moda" biriktirdim. Görüşmeyi yapanın ve başvuranın bakış açısından konuşmak istediğim şey buydu. Makalenin kişisel öznel izlenimlerimi yansıttığı ve bir "röportaj rehberi" iddiası taşımadığı konusunda hemen bir çekince koymak isterim. Öte yandan, bu, başarısız bir görüşmeden kaynaklanan anlık bir öfke patlaması değil, olumsuz temelde de olsa, bana seçenekleri ayıklamama veya potansiyel olarak uygun bir adayı korkutmama izin veren uzun ağırlıklı bir kriterler dizisidir. kendim.

Mülakatlarda sizi neler rahatsız ediyor veya strese sokuyor? Yorumlarda paylaşın.

Başvuranın bakış açısından röportaj

1. “Başka hangi teknik görüşme?”

Mülakatlara yönelik bu yaklaşım beni her zaman potansiyel bir işverenin aleyhine çevirdi. Ne yaptığımı gerçekten bildiğimi kontrol etmek için bana tek bir soru bile sormadılar. Görünüşe göre benimle röportaj yapan insanlar ya konu hakkında hiçbir şey anlamıyorlar ve anlayan en az bir kişiyi arıyorlar ya da çaresiz ve herhangi biriyle mücadele etmeye hazırlar. Her halükarda, bu şekilde oluşturulmuş bir ekipte çalışmayı pek istemezdim.

2. “Peki, orada ne yapıyordun…”

3. “Özgeçmişinizde adınız/soyadınız/soyadınız yanlış yazılmış!”

4. "San Francisco'nun tahliyesi sırasında bir nikel boyutuna küçülen bir okul otobüsünün tüm yuvarlak pencerelerini en fazla 3 tartım kullanarak temizlemek için kaç golf topu gerekir?"

5. “Yanlış. Daha öte."

Görüşmecinin bakış açısından röportaj

1. “Sorularınızdan bazıları teorik. Teoride güçlü değilim, pratikte tecrübeliyim! Daha iyi bir test yapalım!”

• == ile karşılaştırmanın Java'daki eşitlerle karşılaştırmadan farkı nedir?
• karma haritasının nasıl çalıştığını bize anlatın.
• REST'in ne olduğunu kendi sözlerinizle açıklayın.
• İşlemler nedir ve neden gereklidir?

2. “İspanyol Engizisyonu'nun burada olmasını beklemiyordum! Tıpkı enstitüde sınava girmek gibi. Genellikle nerede çalıştığını ve ne yaptığını soruyorlar.”

3. “Bunu bilmeme gerek yok, ben daha üst seviye görevlerde uzmanım!”

4. “Ve sen kendin! / Bana kodunu göster! / Ama GitHub'ınıza gittim ve şu var...”

5. “Yanılıyorsun!”

Çözüm