'Kötü kod' röportajı nasıl yapılır? [kapalı]

'Kötü kod' mülakatı, mülakat yapılan kişiye 'kötü kod' pasajı gösterildiği ve düzeltmesi veya yanlış olan şeyleri belirtmesinin istendiği bir röportajdır. Bu röportajlarda sorun yaşıyorum çünkü kodu okumak, ne yaptığını anlamak ve kusurları göstermek biraz zaman alıyor. Zaman baskısı olan bir durumda, donma eğilimindeyim ve kodun 'yapması' gerektiğini, görmediği zamanlarda bile çalıştığını görüyorum.

Bu tür röportajları halletmenin iyi bir yolu nedir ve daha genel olarak, kodu hızlı bir şekilde okumak ve anlamak için bazı iyi teknikler nelerdir?

Hatalı Kod Röportajları (düzgün bir şekilde yapılırsa) size aşağıdakileri içeren kodu göstermelidir:

• Hatalı dil tekniği ( usinggerektiğinde C # deyimini kullanmamak veya ArrayListyerine a kullanmak yerine List<T>)
• Kötü bir tasarım kararı (neden her yerde dizeleri geçiyoruz ya da refve outparametreleri çok fazla kullanıyoruz?)
• Sözdizimi hataları (Bu bile derlenmemelidir!)
• Çalışma zamanı hataları (C # 'da kendisine atıfta bulunan bir özelliğin neden olduğu Yığın Taşması gibi)

Yukarıdaki noktaların her birine vurarak zihinsel bir kontrol listesi var. Eğer koda bakıp bunu yapamıyorsanız, bu bir gelişme noktasıdır. Hangi dilde "uzman" olduğunu iddia ederseniz edin, bir kod bloğuna bakabilmeniz ve bu dört hata türüne dikkat çekebilmeniz gerekir.

Son zamanlarda tüm bu sorunları sergileyen bir kod parçası hakkında blog yazdım , aynı zihinsel süreçten geçmenize yardımcı olmalı.

Ayende , Günahın Ücretleri dizisiyle daha derine iner .

Hızlı bir şekilde anlamaya çalışmayın. Buradaki amaç, kodu bir guru gibi anlayabileceğinizi değil, nasıl düşündüğünüzü görmektir.

Temel IMO sadece yüksek sesle düşünmektir. Donmuş olsanız bile - o zaman sadece "Ben burada stresliyim, ama yavaşça yüksek sesle geçmeme izin verin" deyin.

Yüksek sesle düşünme yeteneğine sahip olduğunuzu varsayarsak, zihninizi doğru alacak kadar yavaşlatır. Röportajlar yeterince bilgili ise, durumunuzu görecek ve siz net bir şekilde düşünene kadar size yardımcı olacaktır. Sizi aptal görünmek için kandırmaya değiller - sadece nasıl düşündüğünüzü görmek için güçlü bir teknik.

Oranlar, hissettiğiniz 'zaman baskısı' tamamen kendini dayamıştır. Kendi güvensizlik duygularınızla ve ne kadar iyi ölçtüğünüz konusunda endişelenmenizle daha fazla ilgilidir.

Herkesin verebileceği en iyi tavsiye şudur: Rahatlayın. Acele etmeyin, koda bakın ve gördüğünüz şey hakkında konuşun. İyi kısımların yanı sıra kötü kısımlar hakkında da konuşmaktan çekinmeyin; sinirliliğinizi azaltmaya yardımcı olur ve çok fazla zamanın geçtiğinden endişe eder.

Ayrıca, farklı 'geçişlerden' geçmek, belirli ayrıntıları bulmayı biraz daha kolaylaştırabilir. Eşleşmeyen parantez veya yazım hataları için bir geçiş yapın. Gizlenmiş hatları aramak için başka bir geçiş yapın. Anlamsal simit arayan bir tane daha alın. Bir tür "yanlış şeye" odaklanmak, bu ayrıntıların fark edilmesini kolaylaştırabilir ve (tekrar) iç sesinizi hızlı / iyi yapıp yapmadığınızı sorgulayarak azaltabilir.

Her şeyden önce, ne yaptığınızı ve ne düşündüğünüzü konuşun - bu size ve görüşmeciye yardımcı olacaktır.

Bu tür bir röportajda hiç bulunmadım, ama kötü olduğundan şüphelenebileceğim zor bir kod parçası üzerinde çalışmaya çalışırken , bazen kendimle sessizce konuşurum. Seslendirmenin bazen problem çözmeye yardımcı olduğunu düşünüyorum. Ayrıca bir röportajda, bir kalem veya kağıtla yürütme adımlarını bir şema veya bir şey olarak izlemeyi deneyebilirsiniz. Bu benim için okulda çalışırdı, yine de bazen iş yerinde. YMMV, elbette ...

(Açık bir şey görmüyorsanız) başlamak için iyi bir yer "hata ayıklama" olacağını düşünürdüm. Hemen yarasa dışında olası sorunları görmüyorsanız, başlamak için iyi bir yer küçük bir test değerleri listesi yapmaktır. İyi değerler bir 'mutlu yol' (normal) değer, 'sıfır' veya 'boş' değer, boş değer, çok küçük bir değerdir (1 karakterli dize, int 1 vb.), Çok büyük veya çok uzun değer ve türe özgü 'garip' değerler (ör. dizeler için Unicode karakterler, girişler için negatif sayılar vb.). Normalde kodu test etmek için bu değerleri kullanarak birim testleri yazacağınızı ve sadece işlevi doğrulamak için bunları çalıştıracağınızı belirtmek acı vermez.

Mutlu yol değerlerinizle başlayarak başlayın. Ekleme işlevi için 3 veya 4 ile başlayabilirsiniz. Her satırı yazarken yerel değişkenlerin değerlerini izleyerek yazım hataları ve mantık hataları açısından inceleyin. Umarım birkaç hata bulursunuz. Mutlu yolu bitirdiğinizde, kod için daha iyi bir his olacak ve umarım biraz daha az bunalmış hissedeceksiniz - bu yüzden, "Şimdi bu kodun ne yaptığı için daha iyi bir his var, ben geri adım atıp ona bir bakacaksınız, "o zaman bunu yapın - farklı yaptığınız şeyler olarak göze çarpan şeyleri aramak (kötü tasarım kararları, kötü adlandırılmış değişkenler, olası hataları araştırmak, vb.).

Bu sizi herhangi bir yere götürmezse veya söyleyecekleriniz bittiğini düşünüyorsanız, test değerleri listenize geri dönün ve sorunlara yol açacağını düşündüğünüz yenisiyle tekrar gözden geçirin.

Bu en azından seni harekete geçirecek.

Stephen Bailey'in söylediği gibi, yüksek sesle düşünmek bu durumda mükemmel bir tekniktir, çünkü görüşmecilerinizin düşünce sürecinizi görmesini sağlar. Neyi çözmeye çalıştığınızı açıklayın. Yapabileceğiniz bir diğer şey, görüşmecilere, koddaki kötülük hakkında bir teşhis vermeden önce kodu doğru bir şekilde okuyacağınızı bilmelerini sağlamaktır. Ben masanın her iki tarafında olmuştur ve bu durumlarda her iki tarafı için sinir bozucu olabileceğini biliyorum.

Yazılı bir test olarak daha az baskı hissediyorsanız, not defterinizi çıkarın ve not almaya başlayın. Bir defter çıkardım ve bir röportajda düşünme sürecimin bir parçası olarak notlar yazmaya başladım. Bir deftere ve kaleme sahip olmak bile düzenli görünmenizi sağlar. Aranacak şeylerin birkaç mermi noktasını yazabilirsiniz, sözdizimi, mantık hataları, veri türü uyuşmazlıkları, yerel değişkenlerin değerleri (liste, sahip olduğunuz kodun türüne bağlı olarak değişebilir, karmaşık bir SQL parçası için listem veri merkezli olmayan bir kod parçası olan birinden farklı olun) işlemden geçtiğinizde, vb. bunlardan birkaçını yazdıktan sonra bunları aramaya başlayın. Bu şekilde, görüşmeci devam etmek istemeden tüm sorunları bulamasanız bile, kontrol edeceğiniz şeylerin bir listesini görebilecektir. Aramak isteyebileceğiniz şeylerden önce bir kontrol listesi oluşturursanız, hangi şeylere bakmayı planladığınızı bilerek işleme başlamadan daha emin hissedeceksiniz. Genellikle bu sorular, hataları nasıl bulacağınızla ilgilidir.

Bu partiye biraz geç kaldım, ancak kullanabileceğiniz bir teknik söz konusu kod için birim testleri yazmak olacaktır. Daha sonra kodla neyin yanlış gittiğine daha az ve aradığınız beklenen sonuçlara daha fazla konsantre olabilirsiniz. Bir kod parçasıyla neyin yanlış olduğunu hemen fark edebilen birinden daha iyi testler yazabilen birini işe almak istiyorum.

İki sorun olabilir:

Bir "stres görüşmesi" olabilir http://en.wikipedia.org/wiki/Job_interview#Stress . Görüşmeci, çalışma ortamları böyle olduğu için stresle nasıl başa çıktığınızı görmeye çalışıyor.

VEYA

Kendinizi stresli hissediyor olabilirsiniz. Bu durumda, bu stresi yönetmeniz gerekecek, örneğin introspect ve nasıl sakin kalacağınızı görün.