Bir röportajda, kaba bir soruna kaba kuvvetli bir çözümü kodlamak veya röportajı soruyu dikkatle inceleyerek geçirmek daha mı iyi? [kapalı]

Bazen mülakatçı olmaları olsun ya da olmasın mülakat soruları zordur. Çirkin, verimsiz, kaba kuvvet çözümünü kodlamak veya görüşmeci ile sorunun her yönünü anlamak için zaman harcamak için sınırlı görüşme süresini kullanma seçeneğine gelebilir.

Örneğin, Project Euler'deki Problem 91, mümkün olan her üçgeni hesaplamak, bir isRightTriangle () testi yazmak ve testi bir kümeye geçiren tüm üçgenleri patlatmak için çok zor olmayan bir kaba kuvvet çözümü ile çözülebilir. Ancak iki X / Y koordinatı çifti, yüksek sabit değere sahip bir O (x ^ 4) çözümü yapar. Bir arkadaşım ve ben çok daha zarif ve verimli bir çözüm bulduk, ancak ikimiz üzerinde 3 saat geçirdik ve düzinelerce diyagram çizdik, çoklu formülleri test ettik, çoklu yaklaşımları inceledik vb.

Her görüşme sorusu adil değildir. Ayrıca bir kişi için kolay olan bir başkası için zor olabilir. Birisi bir soru ile mücadele ederse, işe yarayan kaba kuvvet çirkin bir çözümden daha çok etkilenir misiniz? Ya da mükemmel bir çözüm anlama ve zarif bir çözüme giden yollarda, ancak kodlanmış bir çözüm yok mu? 20 dakika sonra ne olursa olsun kodlamaya başlamanız gibi bir kural var mı?

Her şeyden önce, iki deneyimli geliştiriciyi zarif bir şekilde optimize etmek için üç saat süren bir soru, bir röportaj sorusu için kötü bir seçimdir. Eğer sorarsanız, mükemmel cevaplar beklememelisiniz.

Öte yandan, bazen sınırlarını aştığında birini en çok öğrenirsiniz. Bu yüzden birçok üniversite kursu zorlukları artırıyor ve eğriyi değerlendiriyor. Herkes her sınavda% 100 puan alırsa, çok fazla potansiyel öğrenim görüyorsunuz.

İdeal adayım muhtemelen ilk önce karmaşıklık hesaplamasını yapacaktır, "Oh, bu çok uzun sürmeyecek 6 milyon iterasyon" deyin, sonra hızlı bir şekilde kaba kuvvet çözümünü yazın. Daha sonra, görüşmeci istemedikçe, bunları uygulamak zorunda kalmadan, onu optimize etmek için alabilecekleri yaklaşımları tartışırlardı.

Kısmen, bunun nedeni, gerçek dünyada ortaya çıkan birçok proje euler tipi sorununun, bir kez çözmeniz ve unutmanız gereken tek adımlık problemler olmasıdır. İşe aldığım birinin yazmak için 2 dakika süren ve çalıştırmak için 10 dakika süren bir kaba kuvvet algoritmasını tanıyabileceğini bilmek istiyorum, sadece ihtiyacınız varsa, yazmak için 3 saat ve çalıştırmak için 10 saniye süren bir algoritmadan daha verimli bir kez çalıştırmak için.

Bir işe alma yöneticisi olarak, önümde kod ile ilgili bir sorunu çözmenizi istiyorsam, kodun kendisini görmek için çok fazla şey yapmıyorum (önemli olmasına rağmen) değil, nasıl ve neden olduğunu belirlemek için yaptıklarını yaptın. Yapabileceğiniz şeylerden biri kod değildir ve bunun yerine beni daha iyi çözmek için sorunun kendisinin yönleri hakkında sorgulamaktır. Bu benim için anlamlı ve genellikle kodda ortaya konan çözümden daha anlamlı. Ancak, bu herkesin yaptığı gibi değildir ve herkesin görmek istediği şey değildir (ve aslında, nadiren insanlardan bir röportaj ortamında kodlamalarını isterim ama masaya problemler koyarım ve onlarla konuşuruz ve bazen sahte kod ortaya çıkar. , ki bu benim için iyi ).

Her görüşme sorusunun adil olmadığı ve bir başkası için kolay olanın bu ortamda ve bu kısıtlamalarla zor olduğundan haklısınız ve bu yüzden anlayan bu görüşmeler genellikle kod çözümünü aramıyor ( , yine, bu önemli bir rol oynar), daha ziyade çözüm sürecidir .

"20 dakika sonra ne olursa olsun kodlamaya başlamanız gibi bir kural var mı?" Sorunu düşünmek için çok kısa bir süre içinde, en azından bir şey yapmalısınız - daha fazla soru sormanız, bir çözüm için bir çerçeve çizmeniz veya bunu yapamayacağınızı söyleyerek cevaplayacağım / nereden başlayacağımı bilmiyorum.

Eğer önünüzde ve verdiğiniz çözümde - zaman kısıtlamaları ve neye sahipseniz - kaba bir güç ve çirkin olsaydım, zor bir problem koyarsam, size durumun neden olduğuna dair bir dizi soru soracaktım, ve daha zarif bir şeye ne değiştirebilir: daha fazla bilgi? daha fazla zaman? farklı bir ortam? Being kendinin farkında ve temasa neden yaptığını ve kadarıyla ne değildir yapılır ve rasyonel bunu açıklamak mümkün, kitabımda büyük bir altın yıldız, ancak bu geliştiricilerin türlü I aramak. Bu yüzden, "mükemmel problem anlayışı ve zarif bir çözüme giden yollarda" benim için de işe yarar, ama herkes için işe yaramaz.

Her ikisini de isterim, ancak bir çözümde "sadece çalışan bir kod" görüntüleyebilir ve muhtemelen bir veya başka bir sorunda iyileştirme için olası çözümleri tartışabilirler.

Birinden kod yazmasını isterseniz ve sadece sıfır kodlu olası çözümler hakkında konuşmak isterse, bu bir endişe olacaktır.

Söylediğiniz gibi, herhangi bir sebepten ötürü birisi belirli bir problemle mücadele edebilir, ancak bunları nasıl çözeceğini öğrenmelisiniz. Şanslı olabilirler ve benzer bir sorunun çözümünü zaten duymuş olabilirler. Olur.

Birisinin yeterli kod yazma ve tartışma hakkında gitmesini izleyin ve iş için doğru olup olmadığını anlayabilirsiniz.

20 dakika sonra ne olursa olsun kodlamaya başlamanız gibi bir kural var mı?

Hayır, ancak işe başlamadan önce sorunu analiz etmek için 20 dakikanızı harcarsanız, muhtemelen başınız belada demektir. Size belirttiğiniz gibi bir soru soran bir işveren çoğunlukla bir soruna nasıl yaklaştığınızla ilgilenir, ancak bir kodlama sorunu olarak soruyorlarsa da bazı kodları görmek isteyeceklerdir. Düşünce süreciniz boyunca onlarla konuşun ...

Buradaki bariz yaklaşım kaba kuvvettir. Üç köşeyi göz önünde bulundurarak bir dik üçgeni tanımak için bir yolum olsaydı, iki noktanın tüm kombinasyonlarını ve doğru üçgenleri arayan kökenleri geçebilirdim. Bu zor olmamalı - Dik üçgenleri tanımlamak için Pisagor Teoremini kullanan bir işlev yazabilirim. Bunu kolaylaştırmak için, mesafe formülü kullanarak iki nokta arasındaki mesafeyi belirleyen bir işlev de yazacağım ...

Bu işlevlerin yazılması yaklaşık üç dakika sürecektir. Şimdi, soruya sadece birkaç dakika içinde, temel geometriyi hatırladığınızı ve kod yazmayı gerçekten bildiğinizi zaten gösterdiniz. Ayrıca size konuşacağınız bir şey de verir:

Böylece, isRightTriangle(p1, p2, p3)işlevi dört fordöngünün ortasına koyabiliriz ve iki değişken noktanın her biri için olası tüm seçenekleri tekrarlayabiliriz. Bakalım ... sorun, 50x50 ızgara üzerindeki başlangıç ​​noktası da dahil olmak üzere sağ üçgen sayısını soruyor, bu yüzden kaba kuvvet yöntemini kullanmak her noktanın her koordinatı için 50 olasılığı kontrol etmemizi sağlıyor. Bu 50 ^ 4 kontroller ... Eminim daha iyisini yapabiliriz, ama kod açık, bu yüzden yazayım ...

Şimdi iç içe fordöngüler kullanan bir işlev ve isRightTriangle()az önce yazdığınız işlevi yazıyorsunuz. Sorunu çözdünüz, ancak görüşmecinin nereye gittiğinizi görmesine de izin verdiniz. Amaçları sadece kod yazabileceğinizi görmekse, durmanızı söyleyebilirler. Büyük olasılıkla, ne yaptığını bilen biriyle konuşmaktan mutluluk duyarlar ve bunu ne kadar uzağa götürdüğünüzü görmek isterler. Yani devam et ...

Ben yazarken simetriden faydalanabileceğimi anladım. 45 ° çizgisi etrafındaki herhangi bir sağ üçgeni yansıtabiliriz, bu nedenle bu çizginin yalnızca bir tarafındaki noktalardan birini kontrol etmeyi seçersek, iki kez bulduğumuz herhangi bir sağ üçgeni sayabiliriz ... bir kez üçgen için ve bir kez yansıması için. Bu, çek sayısını yarıya indirir. Ayrıca, şimdi baktığımızda, iki nokta arasındaki mesafeyi bulmak için kare bir kök alıyoruz, ama sonra tekrar tekrar kare isRightTriangle()...

Ve bunun gibi. Yine, genellikle mükemmel bir çözüm görmek istemiyorlar, bir çözüme nasıl ulaştığınızı görmek istiyorlar. Düşünce süreciniz yukarıdaki gibi bir şey olmak zorunda değildir - sadece yüksek sesle düşünmek için güven duymak çok şey olacaktır. Bir hata yaparsanız terlemeyin - sadece "hmmm, sanırım burada raylardan çıktım - bir adım geri döneyim ..." deyin.

Yönetici olarak, bir test olarak kod yazmanızı istersem, en çok ilgilendiğim şey:

• Kod yazıp yazamayacağınız
• Kodlama stiliniz
• Seçtiğiniz algoritma
• Deneme, sorunu anladığınızı gösteriyor mu?
• Belirli bir teknoloji konusunda gerçekten çok sıcakysam, az çok bildiğinizi gösterdiniz mi?

İlk öğe çılgın görünebilir, ancak şaşıracaksınız ...

Kodlama stili - bununla birlikte sadece parantezlerinizi nereye koyduğunuzu değil,

• Bu sorunu çözmek için kompozisyon veya miras seçtiniz mi? Neden?
• Bu değer için, neden int yerine dize (veya ne olursa olsun permütasyon) yerine bir numaralandırma kullanmayı seçtiniz?
• Bu değer için özellikler, alanlar veya get / set yöntemleri kullandınız mı? Neden?
• Sınıflarınızdaki durumu nasıl ele aldınız?
• Kalıtım, arayüzler ve lambdaların nasıl çalıştığını anlıyor musunuz?
• Dilin parametre kurallarını anlıyor musunuz (ref ile değere göre nedir?)
• Birim testleri yazmayı biliyor musunuz?

İşte gerçekten umrumda değil :

• Derlediğini (size sadece not defteri verdiğimi ve derleyici olmadığını varsayarak)
• Bir fonksiyonda hafızadaki bu 2 parametrenin sırasını bildiğiniz
• Bir SQL Server veya Oracle bağlantı dizesini ezberden okuyabileceğiniz
• Ben her hatayı izlerken omzunun üzerinde dururken mükemmel kodlayabilirsiniz.

Dürüst olmak gerekirse, hiçbir zaman kodlama testlerinin hayranı değildim - stili analiz etmek için bir araç hariç.

Bu durumda zarif bir çözüme giden yol, daha kötü ama eksiksiz bir çözümden daha iyidir. Her iki durum da iyi. Sorunu ve programı gerçekten kodlamak için hiç vaktiniz olmasa bile nasıl çözmeyi düşündüğünüzü gösteren pusdocode yazmanız kesinlikle iyi.

Sanırım aslında cevabı olmayan, daha az 'doğru' cevap olan bir soru soruyorsunuz. Bunu söylememin nedeni, tamamen soru soran kişinin ne olduğuna bağlı olmasıdır.

Görüşmeci, bir şeyin hızlı bir şekilde çalışacağını görmek ve daha sonra zamanınız varsa daha düşük öncelikli bir etkinlik olarak optimize edeceğinizi görmek isteyen hardcore bir pragmatist olabilir. Görüşmeci, Google'ın işe alım uygulamaları hakkında en iyi izlenimini vermekte ve en seksi, en zarif algoritmadan başka bir şeyle ilgilenmemekte ve bunu "kaba" ve " birbirini 5 kelime içinde zorlar. Ayrıca görüşmeci "röportaj soruları" nı aradı ve sizden 5 dakika önce bu sorunu internette buldu ve ne istediğini bilmiyor.

Her durumda, görüşmecinin istediği bağlam bilgisine dayanarak çıkarım yapamıyorsanız, muhtemelen en iyi bahsiniz açıklık istemektir. Tüm röportaj sorularının adil olmadığını ve aslında hepsinin iyi sorular, hatta mantıklı sorular olmadığı konusunda haklısınız. Bir röportaj doğal olarak indirgemeci bir aktivitedir, tıpkı biriyle bir iki saat geçirdiğiniz ve ikiniz de bir sonraki saatte birlikte iyi çalışıp çalışmayacağınızı tahmin etmeye çalıştığınız "hız buluşması" gibi 5 yıl ya da değil. Bu perspektiften incelendiğinde, umarım bir 'kural' hakkındaki sorunuzun gerçekten cevabı olmadığını söylediğim daha açıktır.

Birisi size yetkinliğinize ilişkin fikir kazandıracak ve ekibine uygun olacağını düşündükleri bir soru soruyor. Onların takımına, onlar hakkında bildiklerinize, görüşmecinin kişiliğine ve diğer onlarca faktöre bakmalı ve hangi cevaplara, yaklaşımlara ve süreçlere değer verebilecekleri konusunda en iyi tahminde bulunmalısınız. Şahsen, en iyi fikir olduğunu düşündüğünüz şekilde ona yaklaşmanız gerektiğini söyleyebilirim. Sizinle aynı fikirde değillerse, yine de iyi bir uyum olarak yaralanmış olmayabilir - bunu daha sonradan daha kolay anlamak daha kolaydır.

Görüşmeciler sizden çözümünüzü geliştirmenizi isteyecektir.

Ve "önce kaba kuvvet çözümü" yaklaşımının tartışılmaz bir avantajı vardır: ideal bir çözüm bulmayı başaramazsanız, bunları göstermek için hala tamamlanmış bir şeyiniz vardır.