Katıldığım son röportajda, sırayla kapasitelere sahip iki kova olan filan litre suyu ölçmem beklenen bir bulmacayı çözmem istendi - sırasıyla falan ve falan litre. Bulmacayı verilen sürede (~ 5 dakika) çözemedim.
Görüşmeci biraz hayal kırıklığına uğradı ve bir programcının "bu" becerilere sahip olması gerektiğini söyledi. Ne hakkında konuştuğunu anlamadım.
İş röportajlarında normal olarak sorulan bu tür bulmacalar hakkında her zaman garip hissettim. Böyle bulmacalar ve programlama arasındaki bağlantının ne olduğunu anlamıyorum. Görüşmeciler bu tür bulmacalarla hangi becerileri değerlendirmeyi planlıyor?
Bazı insanlar, problemleri çözme yeteneğinizi ve yaklaşımınızı ölçmek için onlara soruyorlar. Şahsen, bu tür bulmacaların doğru bir gösterge sağladığını düşünmüyorum. "Gerçek dünyada", örneğin bir bin ambalaj vs sırt paketi sorunuyla uğraştığınızı anlamak için beş dakikadan fazla zamanınız var. Başlangıçta, bazen yanlış çözümü uygulayana kadar problemi yanlış anlamak kolaydır. Bu, 1, 5, 10 hatta 20 yıllık deneyime sahip insanlara olur.
En iyi röportaj 'bulmacalar', uzmanlık iddiasında bulunduğunuz alandaki bir sorunu çözmek için bir bilgisayarda oturduğunuzlardır. Ben de "Peki, bir programcı yapabilmek gerekir ..." düşünme sevmiyorum çünkü insanların vurulduğunda endişeli olsun dikkate almaz zaten stresli bir ortamda beklenmedik bir şeyle. Elbette, düşünmek için zamanınız olsaydı çözebilirsiniz .. ve belki de hayatınızın biteceğini fark ederseniz daha hızlı çözebilirsiniz. eğer yapmazsan. Beş dakika içinde sorunları çözemezseniz, hayatınızın biteceği bir yerde çalışmak ister misiniz? yapamazsanız kovulur musunuz?
Tüm büyük programcılar ayrıca şampiyon sudoku çözücüleri olmalı mı? Eminim pek çok şey var, ama bu yetkinlik için bir tür ön koşul gibi değil.
Sorunlara nasıl yaklaştığınız konusunda test edilmemeniz gerektiğini söylemiyorum, ancak testler eğlenceli olmalı ve başvuru sahibinin 'en iyisini' davet etmelidir. uzmanlık alanları göz önüne alındığında, vermek zorundadır. Bruce Willis'nin tasvir ettiği bir karakter kadar akıllı olduğunuzu kanıtlamak, yapımcıların o sahneyi doğru doğru bir şekilde elde etmek için oldukça fazla para harcadıklarını düşünürsek, anlamsız görünüyor.
Başka bir deyişle, gerçekte ne yapacağınızı ne yaptığınızı çok az anlayan biri tarafından röportaj yaptığınızı tespit ederseniz, kendinize izin verin tuvalete ve asla geri dönmeyin.
Microsoft bu soruları 1980'lerin başında kullanmaya başladı. Microsoft önemli ölçüde başarılı olduktan sonra, diğer şirketler bunları kopyalamaya başladı, ancak çeviri sırasında birkaç önemli nokta kayboldu.
O zamanlar Microsoft, birçok teknik ama programlama dışı pozisyonu doldurmaya çalışıyordu: teknik yazarlar, test ediciler, telefon desteği, vb. Bunlar gün içinde ortak işler değildi ve bu alanlarda gerçek deneyime sahip olanların bulabilirsiniz. Alternatif olarak Microsoft, gerçekten akıllı, zeki, esnek insanlar işe alabileceklerini ve onları işte eğitebileceklerini düşündü. Bu kişilerin programlama geçmişi olmadığı için röportajda programlama soruları sormak anlamsızdı. Bilmeceler, zeki ve son derece iyi analitik becerilere sahip olanları belirlemek ve belirlemek için seçildi. Programcılara genellikle beyaz tahta programlama sorunları verildi, ancak öğle veya akşam yemeklerinde bilmeceler de istenebilir.
Bu sorular hiçbir zaman başarılı olmadı. Sorunla nasıl başa çıkacağınız ve daha önce hiç görmediğiniz sorunları nasıl düşündüğünüz hakkında bir konuşmanın başlangıcı olacaklardı. "Başarısız" olmanın tek kesin yolu, sorunu çözmeye çalışmayı reddetmekti. O zamanlar bu yeni bir stratejiydi ve Google'daki soruları arayamazdınız.
Düzenle:
Bu cevabı yazdıktan sonra, 1950'lerde ve 1960'larda kurumsal bilgi işlem tarihi olan The Computer Boys Take Over okudum. Görünüşe göre, zeka oyunları ve adayların bilmeceleri programlama için sorma uygulaması 1950'lere kadar uzanıyor. ABD hava savunma sistemini bilgisayarlaştırmaya çalışıyordu ve IBM bu işi yapmak için birkaç bin programcıya ihtiyaç duyacağını tahmin ediyordu. Yanıt şok ve şaşkınlıktı: tüm dünyada sadece birkaç düzinelerce "profesyonel programcı" vardı. Çeşitli yaklaşımlar denendi: soyut programlama yetenek testleri, matematikçileri programcı olarak işe almak, satranç oyuncuları ve bulmaca çözücüleri işe almak ve başvuru sahiplerini bilmeceler ve zeka oyunları ile taramak.
Sonunda projeyi tamamlamak için yeterli programcı işe alma konusunda başarılı oldular, ancak sonuç, tarama yöntemlerinin hiçbirinin, programcılar olarak özellikle başarılı olan işe alımları belirleme şansından daha iyi olmadığıydı.
Yararlı mı? Hayır gerçek değil. Bir zamanlar Microsoft'ta çok yaygındılar, hatta "Microsoft soruları" bile deniyorlardı ve onlar hakkında yazılmış kitaplar var, b aslında oldukça iyi bir okuma.
Onlarla 2 problem var. Birincisi, başvuru sahibi araştırma yaparsa (ve kitabı okursa), her neyse ve ikincisini bilir, hatta çözebilseler bile, bu nasıl iyi bir geliştirici/test/PM olacağını gösterir.
Bu nedenlerden ötürü artık Microsoft'ta nadiren sorulmaktadır. Kodlama soruları veya "hile" cevabı gerektirmeyen problem çözme soruları sormak çok daha iyidir. Başka bir deyişle, başvuru sahibinin problemi çözmeye çalışırken becerilerini ve davranışlarını keşfetmenizi sağlayacak sorular sormanız gerekir - görüşmeci olarak soru sormalarını, çözüm bulmalarını ve sonra anladıkları zaman geri izleme yapmalarını istiyorum bir sorun, belki de sahip oldukları zamanda bir çözüm bulamazlar, en azından mantıklı bir şekilde çözerler. Bu gerçek yaşamı yansıtır. Asla 2 kova ve bir tavuk (veya soru ne olursa olsun) kullanarak 3 pint ölçmek zorunda kaldım.
Bununla birlikte, zamanımda birkaç hile sorusu soruldu ve şimdi kendimi küçük teknelerde tavuk ve tilki taşıma ve bir trende yaşayan bir sinek ömrünü hesaplama konusunda bir uzman olarak görüyorum. Bu bilgiyi hiç kullanmak zorunda kalmadım, ama kim bilir, belki bir gün ....
Kitabı okumak isteyebilirsiniz Fuji Dağı'nı Nasıl Taşıyacaksınız? . Birçok insanın röportajda bilmeceleri kullanmasının mantığına giriyor ve bence bunun kargo kült davranışının bir kombinasyonu olması ( "Microsoft bunu yapıyor ve eğer başarılı olmak istiyorsak onlar, o zaman ne yapsak iyi olur ") ve kardeşlik taciz (" gosh !, Bu soruları cevaplamak zorunda kaldım ve bir sonraki adam onlara cevap vermek zorunda kalacak! ").
Bu soruların mülakat pratiği olarak tarihi 1950'lerde William Shockley ile başladı. Bunlar, görüşmecilerin sorduğu oldukça yaygın bir Silikon Vadisi tür röportaj sorusuydu çünkü diğer görüşmeciler bunu yapıyorlardı (ve belki de bu görüşmecinin bilmediği bir şey biliyorlardı?). Shockley onları bir zeka testi olarak tasarladı ve 2 kova ile ilgili soru, orijinalinden biriydi Stanford Binet IQ testi 1916'da.
Muhtemelen, röportajı yapan insanlar aslında cevapları nasıl aradığınızı görmek isterler, bu nedenle şehrinizde kaç tane benzin pompası olduğu gibi soruları hesaplamak imkansız olacaktır. Bu tür sorunlar Fermi Problemleri . Bu konuda Jeff 'den iki ilginç blog yazısı Şimdiye kadarki En Zor Mülakat Bulmaca Sorus ve Bir Tahmincisi Ne Kadar İyi? Bölüm III .
Şahsen, bu tür sorular hakkında genel bir fikrim var, çünkü genellikle ne yaptığını bilmeyen veya geliştiricileri nasıl arayacaklarını bilmeyen görüşmeciler tarafından kullanılıyorlar. Eğer bulmaca/bilmeceler yapan bir şirket için çalışmayacaksanız, "en büyük zayıflığınız nedir" (bunun gerçeğine cevap verin ve röportajınızı kötü bir şekilde bitirirsiniz) veya "neden menhol kapakları yuvarlaktır "(hepsi değildir).
Diğerleri gerekir bir konu olarak iptal var cevaplar sağladı. Başka bir cevap yazmamın nedeni, söylemek istediğim şeyin muhtemelen bir yoruma uymayacağı ve iyi bir programlama iş görüşmesinin nasıl olabileceği hakkında bir şeyler söylenmesi gerektiğidir.
Hatırladığım ilk güzel röportajda acele etmeden çok konuştuk. İlk olarak bir saat, telefonda, nesne yönelimli tasarım ve C++ 'da uygulamanın artıları ve eksileri hakkında. Daha sonra, sitede, birkaç kişi ile yazılım geliştirme uygulamaları, entegrasyon, test, sürüm kontrolü ve konfigürasyon yönetimi, ekipler ve sorumluluklar, teknoloji ve tasarım hakkında konuştum. Benimle röportaj yapan kişilerle öğle yemeğini içeren bütün gün bir röportajdı. Geriye dönüp baktığımda, her şey zaten yaptıklarına verimli bir şekilde uyup uymayacağımla ilgiliydi.
O zamandan beri, iyi röportajlar uzun sürdü, yazılım geliştirme hakkında bir ila iki saatlik konuşma. Problem çözme soruları, bulmacalar ve kodlama zorlukları olmadı.
Bugün bir programlama işi için birisiyle röportaj yapsaydım, beğenilere devam ederdim. Geniş bir konu hakkında görüş isterdim ve derinliği bir kenara bırakırdım:
Bunlar birden fazla yanıtı olan sorulardır ve hepsi bir yazılım geliştiricisinin bilgilendirilmiş bir görüşü olması gereken konularla ilgilidir. Bir konuşma konusu (soru olarak değil) olarak yaşanan önceki gerçek sorunlardan bahseden cevaplara gönülden katılıyorum.
Etkili yazılım geliştirme hakkında daha bilimsel çalışmalar Peopleware en iyi programcıların, en yüksek IQ'lara sahip olmasalar bile, yazılım geliştirme dinamiklerini anlayanlar olduğunu söylüyor.
n yıllık deneyimi olan
1 Yıllık deneyimi
n kez kaybolan birinden daha öğrenmeye hevesli bir çaylak almayı tercih ederim. Kişisel önyargım, kutunun dışında düşünmeye eğilimli olan ve aynı zamanda mevcut (benim) kutuma nasıl sığacağını bilen adaylara yönelik.
Tabii ki programlamanın temel yönlerinden biri olan problem çözme becerilerini değerlendirmede yararlı olabilirler.
Yıllar boyunca birçok insanın röportajcısı olarak, genellikle tanımladığınız gibi gotcha tipi sorular sormuyorum, ama bir şey sorabilir ve "nasıl çözersiniz .. . ".
Bu durumda beklentilerim, soruna yaklaşımınızı dile getirdiğinizi duymak. Başka hangi verileri toplamayı denersiniz? Varsayımlarınızı vb. Nasıl test edersiniz?.
Bunlar sadece voodoo işe alım uygulamaları. Diğer insanlar bu soruları soruyorlar, böylece olması gerektiği gibi hissediyorlar. Soruyu cevaplamamanın "kötü" olduğunu ve cevaplamanın "iyi" olduğunu biliyorlar, ancak "geliştiricinin bu becerilere ihtiyacı" gibi cevapların ötesinde nedenini söyleyemiyorlar. Bunlar zaman kaybıdır ve görüşmecinin yetkili görüşmeci olmadığının bir göstergesidir.
Temel mantık becerilerine sahip olmanız gereken eski skool mantığı bu; başka her şey öğretilebilir. Ama bu tamamen doğru değil. Boolean logic, koşullar ve döngüler okumak, mantık bulmacası çözmekle aynı şey değildir.
Bununla birlikte, prosedürel diller günlerinde, bu problemleri çözebilecek bir kişinin anahtarlar açısından herhangi bir problemi uygulayabilme eğiliminin yüksek olduğu doğrudur. Ama bence, OO/Fonksiyonel programlama, oldukça farklı olan (çelişkili olmasa da) bir mühendislik zihniyeti gerektirir.
Şahsen, mantığın pratik programlama becerilerinden daha önemli olduğunu düşünen bir şirkette iş isteyeceğimden emin değilim.
Feragatname: Mantık bulmacalarında çok iyiyim ve muhtemelen bu mantık olmadan bu işe başlamam mümkün olmazdı.
Görüşmeci, bir programcının günlük çalışmasının bir parçası olan problem çözme ve mantık becerilerine atıfta bulunmuş olmalıdır. Bir problem verildiğinde, en uygun yaklaşımı kullanarak analiz edebilmeniz, alt bölümlere ayırmanız ve bunun için bir çözüm yazmanız gerekir.
Böyle bir bulmacanın bunu yapma yeteneğinizi ne kadar iyi temsil ettiğini tartışabilirsiniz. Gerçek hayattaki programlama problemini sormak yerine bir bulmaca sorusu yapmanın değerini görmüyorum.
Programlama kod satırları yazmakla ilgili değildir, diğer insanlar için (müşteri, kullanıcı, vb.) Ve problemleri çözmekle ilgilidir.
Programcılar için çözüm bir program şeklini alır.
Bu yüzden problem çözme yeteneklerine sahip olmak ve neden test edildiğinden önemlidir.
Bununla birlikte, zor bulmacayı çözmenin birini değerlendirmenin en iyi yolu olduğundan emin değilim.
İki puan:
Programlama temel olarak bulmaca çözmekten farklıdır. Steve McConnell tarafından "Kod Tamamlandı" bölümünde açık bir şekilde açıklanmıştır:
Ne? Süper akıllı olmak zorunda değil misin? Hayır. Kimse bilgisayar programlayacak kadar zeki değil. Ortalama bir programı tam olarak anlamak, ayrıntıları emmek için neredeyse sınırsız bir kapasite ve hepsini aynı anda kavramak için eşit bir kapasite gerektirir. Zekanıza odaklanma şekliniz ne kadar zekaya sahip olduğunuzdan daha önemlidir. Bölüm 5'in de belirttiği gibi, 1972 Turing Award Dersinde Edsger Dijkstra “Humble Programmer” başlıklı bir bildiri sundu. Programlamanın çoğunun kafataslarımızın kesinlikle sınırlı boyutunu telafi etme çabası olduğunu savundu. Programlamada en iyi olan insanlar, beyinlerinin ne kadar küçük olduğunu fark eden insanlardır. Onlar alçakgönüllüler. Programlamada en kötü olan insanlar, beyinlerinin göreve eşit olmadığı gerçeğini kabul etmeyi reddeden insanlardır. Egoları onları büyük programcılardan uzak tutar. Ne kadar çok küçük beyninizi telafi etmeyi öğrenin, o kadar iyi bir programcı olacaksınız. Ne kadar mütevazi olursanız, o kadar hızlı gelişirsiniz.
Bu tür bulmacalar röportaj sırasında yararlı olabilir, ancak Sadece görüşmeci Süreç 'e bakarsa, sonucun kendisi değil.
Ama ideal olarak, bulmacalar daha karmaşık ve programlama ile ilgili olmalıdır (küçük 2 saatlik proje gibi), bence. Mesele şu ki, görüşmeciler insanlardır ve mükemmel "görüşme becerilerine" sahip değildirler.
Röportajlardaki bulmacalar iki kategoriye ayrılır: "mantıksal bulmacalar" (size sorulduğu gibi) ve "farklı düşün" kategorisi. Farklı düşünün kategorisi (onlar da yanal bulmaca denir emin değilim?) Genellikle bu tür: Bu ağaçta kaç yaprak var? veya Şehrinizde kaç tane terzi var?
"Mantıksal bulmaca" ile iyiyim çünkü en fazla bir ya da belki iki çözümü var ve basit bir mantıkla ulaşılabilirler. Ve mantıksal bulmacaların bir dereceye kadar iyi olduğuna inanıyorum çünkü bunları çözmek için gereken süreç, bir kodlayıcının gerçek hayatta düşünmesi gereken yöntemdir.
"Farklı düşün" türünün bana sonu gelmez çünkü sizi varsayımlar yapmaya zorlarlar ve sonra varsayımlara dayalı bazı hesaplamalar yaparlar. Basitçe söylemek gerekirse, görüşmeci mantığınıza katılırsa, ancak varsayımlarınıza uymazsa ya da tam tersi, kaybedersiniz. Görüşmecinin çözümünüze katılmaması için çok fazla alan var.
Röportaj yaptığımda mantıksal bulmaca sormuyorum. Sebep: Çoğu aday 3-4 yıllık deneyime sahip olanlar bile, Fibonacci serisi veya palindromlar gibi basit ders kitabı sorunlarını kodlamalarını istediğimde başarısız oluyor veya pes ediyorlar.
Bulmacalar ile ilgili sorun, her iki şekilde de, o kadar iyi olmayan programcıların, internetteki bu tür ortak bulmacalara çözüm arayarak görüşmecileri etkileyebileceklerini bilmeleridir. Çok az insan çözümü zaten bildiğini söyleyecek kadar dürüst olacak.
Bu tür sorunları incelemenin birkaç farklı yolu vardır:
Önceki bir çözümü bilmek. Filmde ... İntikamla Sıkı Öldür ... bunu bana açıkla ...? falanların sırasıyla 4,3 ve 5 olduğu durum için bir çözümün bilinmesi örneği. Bazı insanlar, geçmiş bir çözüm hakkındaki iç bilgilerine hızla dokunabilir ve gerekirse uyarlayabilirler. Bu genellikle bir görüşmecinin iyi bir fikir olabilecek ya da olmayabilecek bir şey olacağına inandığım şeydir.
Yaratıcı doğaçlama becerileri. Eğer önceki bir çözümü bilmiyorsanız ya da sorunu bir Diophantine denklemi olarak modelleyebilecek bir şey olarak tanımıyorsanız bu durum söz konusudur. Dolayısıyla soru, verileni ne kadar hızlı kullanabileceğiniz ve soruna yaratıcı bir şekilde nasıl bir çözüm bulabileceğinizin yanı sıra, sahip olduğunuz sorunun neden geçerli bir çözüm olduğunu açıklayabileceğinizdir.
Ya soruyu geçmişten tatmin edici bir şekilde alan şey olabilir, ancak her durumda bir kişinin iletişim becerilerinin bir testi de vardır, çünkü biri de cevap vermeyi deneyebilir, "Bu gerçekten benim konumumla alakalı mı? Bu beceriler en son ne zaman kullanıldı? " görüşmeci, alternatif bir yaklaşımın burada daha etkili görülebileceğini görmek istediklerini tam olarak görmek istediklerinde ilginç bir diyaloga yol açabilir.
Bu özellikle zor bir sorun değil. Sadece üç adım gereklidir ve her adımda sadece iki seçenek vardır. İş arkadaşlarımdan herhangi biri bunu çok kısa bir sürede çözemezse şaşırırdım. Görüşmelerde bu tür problemler sunmuyoruz, ancak bence bu tür sorular sormanın makul olduğunu düşünüyorum. Sözdizimi veya kitaplıklar hakkında ayrıntılı sorulardan kesinlikle daha yararlıdırlar.
OTOH, programlama problemlerinin daha faydalı olduğunu düşünüyorum.
Birisinin bir işte iyi olacağını kesin olarak kesin olarak bilmenin bir yolu olmadığını hatırlamak zorundasınız. Özellikle bir CS işi, işin mağazada karşılaşabileceği pek çok zorluğun öngörülmesi mümkün değildir.
Dolayısıyla potansiyel işveren gelecekteki performansınızı tahmin etmelidir.
Dereceler, öneriler ve GPA'lar zaman/çaba ve sosyal mühendislik ile elde edilebilir, iş deneyimi süslenebilir ve/veya yanlış olabilir ve standart testler açıkça yeteneklerin çok fazla gösterilemeyeceği kadar temeldir. Bu yüzden özgeçmişiniz, tarihinizde bazı çaba/bağlılık seviyeleri göstergesi verebilir, ancak bunların hiçbiri bilgisayar bilimi dünyasında ortaya çıkan zor sorunları çözme yeteneğinizden bahsetmeyecektir. Bu tür yetenekleri tahmin etmenin birkaç iyi mantık/mathy/CSy bulmacasından daha iyi bir yol olduğunu düşünemiyorum.
Unutmayın ki bu bir tahmin oyunu ve gerçek şu ki, her birimize eşit olan her şey, bu bulmacaları çözemeyen birini işe yaramayacak birinden tutmayı tercih eder.
Evet, röportaj bulmacaları çalışabilirsiniz, ancak verilen bulmaca çalıştığınızlarla eşleşmezse kendinizi yanmış bulacaksınız ... ve bulmacaları ve çözümlerini ezberlemediğiniz sürece, belki de bulmacaları inceliyorsunuz kendilerini gerçek bir şekilde, daha gerçek bir eğitim gibi, daha akıllı bir insan yapar.