Teknik görüşmelerde ne kadar yardım vermeliyim? [kapalı]

Teknik görüşmeler sırasında performans yapmam veya oturmam isteniyor. Görüşülen kişinin kağıt üzerinde çözmesi beklenen mantıksal sorular ve basit programlama problemleri soruyoruz. (Bir klavyeye erişebilmelerini tercih ederim, ama bu başka bir zaman için bir sorun.) Bazen insanların bir soruna nasıl yaklaşacaklarını bildiklerini hissediyorum, ancak endişeyle ya da soruyu ikinci olarak tahmin ederek kapatılıyorlar ( onlar hileli sorular değildir).

Patronumun yardım veya ipucu verdiğini hiç duymamıştım. Sadece yanıtlayanla görüşen kişiye teşekkür eder (ne kadar iyi veya kötü olursa olsun) ve bir sonraki soruya veya soruna devam eder. Ama ben yenen ve sinirlenen tavşan deliği hakkında sizi aşağı yönlendirebilecek ve aklınızı nasıl etkisiz hale getirebileceği hakkında bir şeyler biliyorum ve şimdi biraz yardım sağlayıp sağlamadığımızı merak edemiyorum ve sonuçta daha yetenekli programcılar için bize yardımcı olacak mıyım? daha başarısız görüşmelerden.

Kusurlu görüşmecilere ipuçları ve yardım sağlamalı mıyım (ve eğer öyleyse, daha hazırlıklı adaylara adil davranırken ne kadar ileri gitmeliyim)?

Ben de benzer bir pozisyondayken, görüşülen kişiye şöyle derdim: "Ben Google’mış gibi davranın.

Bir soruda görüşülen kişilerin bir silindirin hacmini anlayabilmeleri gerekiyordu, bu yüzden birinin "Google’ın silindir hacmi için formül alması gerektiğini" umursamadım. Soruna nasıl saldırılacağını bilip bilmediklerini bilmekle ilgilendim, formülleri ezberlemişlerse değil. İş için, gerçek dünyayı yazılıma nasıl çevireceğinin iyi bir şekilde anlaşılması gerekiyordu, bu yüzden önemli bir kavramdı.

Öte yandan, onlara bu formüle ihtiyaçları olduğunu söylemeyecektim.

Sinirlerin sorun olabileceği konusunda haklısın, ama ben hala gergin olsalar bile, insanların düşünce süreçlerini ifade edebilmelerini bekliyorum. Sadece bir cevap vermemek kabul edilemezdi.

Hem problem çözme hem de kısa teknik sorular için işe yarayan iki yaklaşımınız var:

1. İlki patronunuz tarafından kullanılır: Kişinin stresli bir ortamda nasıl davrandığını test etmek için herhangi bir yardım sağlama. Tamamen geçerli bir yaklaşımdır ve kişi hakkında bazı ipuçları verebilir. Sonuçta, bu kişiyi işe aldıktan sonra, tüm meslektaşlarından sürekli yardım alamayacak.

2. İkincisi, ipuçları ve destek sağlamaktır. Destek seviyesi çok fazla önemli değil; önemli olan tek şey, kişiye ne kadar çok yardım ederseniz, başarısını o kadar az değerlendirebilmenizdir.

Şahsen, hem bir kişinin kendi başına bir sorunu çözemediğinden hem de kişinin yardım almadan çözemediğini hissetmesini sağlamak için yeterli zaman ayırmanız gerektiğine inanıyorum. Ancak, kişiye cevabı kendisine söyleyene kadar ilerici yardım sağlayabilirsiniz.

Örnek:

- C # 'da salt okunur özellikleri nasıl yarattığınızı, yani yalnızca bir kurucu içerisinde başlatılabilen ve daha sonra değiştirilemeyen bir değeri olan özellikleri nasıl oluşturabileceğinizi söyleyebilir misiniz?
- Tabii ki. Ben sadece anahtar kelimeyi kullanıyorum readonly.
- Emin misiniz? Bir mülk ile alan arasındaki farkı açıklar mısın?
- Hm. Bir özellik ... görüyorsunuz ... olsun ve ayarlayın ...
- Tamam. Dolayısıyla bir alan bir sınıf içinde veya bir yapı içinde bildirilen ve sınıf / yapı kapsamı içinde geçerli olan ve bir özellik bir alan gibidir, ancak aynı zamanda bir değeri okumak, yazmak veya hesaplamak için bir mekanizma da sağlayan bir değişkendir. Şimdi ne hakkında readonly? Özellikleri ile kullanılıyor mu?
- Sadece tarlalarda kullanıldığına inanıyorum ...
- Doğru. Peki ya özellikleri?
- Sadece okunamıyorlar.
- Emin misiniz? Sadece alıcıları olan mülklerden ne haber?
- Sadece okunurlar.
- Değerlerinin hep aynı kalacağı anlamına mı geliyor?
- Evet.
- Hayır gerçek değil. Bir alıcıya sahip bir mülkünüzün olması, sınıfın örneğinin ömrü boyunca değerinin değişmediği anlamına gelmez. Alıcı, mülke her eriştiğinizde artan bir alanı ifade ederse, döndürülen değer sürekli olarak artar.
- Sağ.
- Yani? Asla değişmeyen bir değeri olan bir mülkü uygulayabilmenizin bir yolu var mı?
- Hayır.
- Salt okunur bir destek alanı kullanabilirsiniz. Destek alanı nedir biliyor musun?
[...]

Cevap vermek her durumda iyi bir fikirdir. Görüşülen kişi cevabımı ilginç bir şekilde yorumladığında, soruyu ilk etapta cevaplayamasa bile, yine de ilgili şeyleri bildiğini gösteren birkaç durum vardı.

Ayrıca, başka bir yardımı olmayan bir soru sorarak, cevabı bildiği veya bilmediği gerçeği dışında, kişi hakkında çok fazla bilginiz yok . Aşamalı yardım sağlamak , kişinin bir sorun hakkında ne düşündüğünü görmenize izin verebilir .

Ayrıca, kişinin bilmediği başka şeyler de gösterebilir. Yukarıdaki örneği ele alalım: ilk cevapta durursam, kişinin bir alanla mülk arasındaki farkı açıklayamayacağını veya bir destek alanının ne olduğunu bilmediğini bilemezdim.

Kişi hemen cevap verirse sorun olmaz. Yardıma ihtiyacı olursa, bunda yanlış bir şey yok. Soruyu kendiniz yanıtlarsanız, bu kötü bir işarettir ve umarım görüşülen kişi diğerlerine cevap verebilir.

Her zaman basit bir şeye sıkışıp kalmışlarsa (belirli bir örüntünün adı gibi olduğunu bildikleri gibi) ve eğer bir veritabanı bağlantısı kurmanın detayları gibi şeyleri açıklığa kavuşturmalarını sağlarsanız, görüşmecilere yardım etmeyi seviyorum. Yine de bir şeyler tasarlamaya çalışıyorlarsa da pek bir şey demiyorum, çünkü onların gittiğini tahmin ettiğimden başka bir şey düşünürlerse onları yönlendirmek veya atmak istemiyorum.

Aklımda çok belirgin bir sonucu olan bir görüşmeci tarafından belirli bir problem çözme sorusu sorulduğunu hatırlıyorum, ancak soruyu net bir şekilde bana iletemedi. Bu, birçok görüşmecinin karşılaştığı durumu tanımlar. Bazen boş bakış, kişinin iyi bir problem çözücü olmadığı için değil, soruyu soran kişinin ne istediği konusunda net olmadığı içindir. Bu durumda, meslektaşınızın hiçbir şey söyleme ve yapmama yaklaşımı, adayın meslektaşınız gibi düşünmediğini veya meslektaşınızın kafasının içinde olmadığını kanıtlar. Sorunun farklı kelimelerle açıklığa kavuşturulması, katılan herkes için daha iyi sonuçlar sağlayabilir.

Programcıların (en azından çoğumuzun) bir boşlukta çalışmadığı ve görüşmelerin yapay sınırlar olmadan yeterince stresli olduğu göz önüne alındığında, görüşülen kişinin istediği veya ihtiyaç duyduğu kadar yardım sunma eğiliminde olacağım.

Ancak bir başvuru sahibinin gerçek yeterlilik seviyesi hakkında son bir yargıda bulunurken hepsini göz önünde bulundurun.

Üst düzey bir pozisyon arayan, ancak çok fazla yardıma ihtiyacı olan biri alarm zili çalar.

"Yaşlı insanlar" için kısa, açık uçlu sorular sunar ve cevaplarından çok sordukları sorulara daha fazla dikkat ederim. Dinleyen, iletişim kuran, aktif dinlemeyi kullanan, açıklığa kavuşturan, sonra da çözümler sunan kıdemli insanları buluyorum.

"Hat mühendisleri" için, bir başvuru sahibine bir bilgisayar ve bir problem verdiğiniz ve birkaç saat sonra geri döndüğünüz testlerin programlanması tekniğini kullandım. Bu durumda, başvuru sahibine, hangi işletim sistemi ve araçları tercih ettiklerini sorduk (ayrıca programcının uzmanlığının ilginç bir parçası). Tamamlandığında, bir grup olarak onlardan çözümü sunmalarını ve neden diğer çözümlerden daha iyi olduklarını sorduk - bir kod incelemesi. 1. günde deneyimli bir mühendisden beklediğim tüm beceriler.

Önemli olarak, tüm görüşme ekibi aynı testi yapmak için öğleden sonra aldı, bu yüzden testin adil olduğunu biliyorduk. Her birimizin yaklaşımını incelemek için bir saat harcadık, görüşülen kişiyle görüşerek, bize farklı yaklaşımlar hissettirdi.

Bu ikinci teknik bize şimdiye kadar bulduğum en iyi "unsung" programcılarından (berbat özgeçmiş, berbat röportaj becerileri) bazılarını buldu.

Adayı süreçte rahat ettirmek için görüşmeleri kolay bir güven artırıcı soru ile başlatmayı tercih ederim. Bu işe yaradığında, beden dilini işle ilgili materyallerden daha iyi anlayan adaylara avantaj vermeden, sonraki sorulardan mümkün olduğunca fazla bilgi toplamanıza izin verir.

Bazen minor hintssözlü görüşme sırasında adayın konuyu / konuları ne kadar iyi anladığını görmek için yardımcı olur. Ancak, no hintsher adayın yapması istenen standart testler yapılmalıdır .

Temel olarak, two main thingspotansiyel aday hakkında bilmek isteyebilirsiniz:

a) Kişisel özellikler - şirketinize veya ekibinize uygun mu?

b) Teknik beceriler - yeni şeyler toplama konusunda iyi bir teknik geçmişe ve ilgiye sahip mi?

Bu belirtilen noktaları öğrenmek için potansiyel adayı bir sohbete dahil etmeniz gerekmektedir. Ayrıca adayın comfortable during the interviewmevcut becerilerini (hem yumuşak hem de teknoloji) ve iş yapma potansiyelini en iyi şekilde anlayabilmek için olduğundan emin olmak önemlidir .

Ayrıca, potansiyel adayın iletişim becerileri de teknik becerileri ve problemleri çözme yeterlilikleri kadar önemlidir .

Bakılması gerekenlerin bir kısmı iletişim becerileridir. Aday soru hakkında net değilse, netleştirmek için sorular sorması gerekir. Bu bence iyi bir şey. Çok sık olarak, kötü kararlar verilir; çünkü spesifikasyonları okurken veya bu durumda bir görüşme sorusu işlenirken bazı varsayımlar yapılır. Aday bu varsayımlara dayanarak cevap verebilir ve amaçlanan noktayı tamamen kaçırabilir. Soru hatalı olabilir veya aday olabilir. Her iki durumda da iletişim yoluyla netleşmeye izin vermek, işverenlerin araması gereken değerli bir beceri olduğunu göstermektedir.

Sonunda bunun bir görüşmeci olarak kişiliğinize geldiğini ve ne düşündüğünüzün önemli olduğunu ve bu nedenle adayı gerçekten değerlendirdiğini düşünüyorum.

Şahsen ben akademik / ezoterik önemsiz şeyler üzerine pratik / pragmatik yeteneğe değer veriyorum. Çalıştığı, işe alınabileceği ve üzerinde çalışacakları hangi projeye / projelere katılacakları için ne kadar değerli bir şekilde verimli bir şekilde katkıda bulunacak bir adayla ilgileniyorum.

Bu yüzden, aday ezoterik bir şeye, nadiren kullanılan bir nüansa veya telafi edilmiş bir röportajda soruna konu olabilecek ancak nadiren gerçek hayatta ilgiliyse bir olaya sıkışmışsa biraz koçluk yapacağım. Özellikle Google’da birkaç dakika içinde veya kullanışlı bir masa referansıyla elde edebilecekleri veya “ayarla ve unut” türünden şeyler yazabilecekleri herhangi bir şey.

Ancak, onları gerçek dünya, ortak, yaygın, temel, günlük iş konularında koçluk etmeyeceğim. Bunlar şeylerdir ben onlara doğuştan olmak istiyorum.

Görüşme durumuna ve sorulara bağlı olduğunu düşünüyorum. Her iki tekniği de kullandım.

Neden takip soruları sormamak isteyeyim? Kişinin strese verdiği cevabı bulmaya çalışırken. Çok stresli ortamlardaki bazı işler ve insanlarla stresi ne kadar iyi karşılayabilecekleri hakkında değerlendirmelerimizde insanlarla röportaj yaptım, bu yüzden hiç kimsenin stres olmadan cevaplayamayacağı bazı zor sorular sorduk.

Teknik bilgilerini bulmaya çalışırken, aradığım şeyle ilgili ipuçları içeren takip soruları soruyorum. Herkese aynı soruları sormak zorunda olduğunuzu söyleyen yöneticinin fikrine aykırı olarak, birkaç koşul yerine getirildiği sürece bunun adil olduğuna inanıyorum. İlk önce herkes aynı temel soruyu sordu. İkincisi, yalnızca bir kişiye yardım etmek için takip soruları sormamalısınız. Başkalarının yardımsız pes etmesine izin vermişseniz, yardım etmeden tüm pisiçiye izin vermeniz gerekir. İkincisi, adayların sorudaki performanslarını, yalnızca nihai cevapları açısından değil, aynı zamanda onlardan çekmenin ne kadar zor olduğu açısından da karşılaştırmalısınız. Bu süreç hala herkese adil davranır.

Ne tür bir programcının istediğine bağlı. Kağıda 20 satırlık büyük bir kod satırı yazabilen bir içe dönük patron size iyi görünecektir. Bir ekibin içindeki milyon hat kodu bazında çalışabilen ve iyi bir yazılımı verimli bir şekilde üretmek için çalışan bir yazılım geliştirici muhtemelen çok iyi sonuç vermeyecektir. Bu tür röportajları aday olarak seviyorum - bana patronun personeline nasıl davrandığını ve iş kültürünün ne olduğunu anlatıyorlar. Aynen böyle bir durumda, röportajı bıraktığımda, "Teşekkür ederim - hadi ikimizi de biraz zamandan koruyalım, beni aramazsan, seni aramayacağım" dedim. Neden diye sorduğumda, beni başarısızlığa ayarlayan bir şirket için çalışmak istemediğime işaret ettim.

Yaklaşıyorsanız, yazılım geliştirme için daha iyi seçimler alabilirsiniz. Siz patronların yaklaşımı çöp toplayıcıları ve Stop / Go lolipoplarını yol çalışmalarında tutanlar için iyi sonuç verir.

Yazılım geliştirme bir takım çalışmasıdır, solo / zihin okuma / etkileşimli olmayan bir oyundur. Yazılım ne istedi, ne istendi değil yaptığından kaç proje başarısız oldu.

Son zamanlarda benzer bir durumdaydım. Yöneticimden ve İK'dan aldığım yön, 6 ankete katılanların tümüne tamamen adil davranmamız gerektiği için, her bir katılımcının nasıl performans gösterdiğini görmek için aynı teknik soruları en az yardımı ile sormak zorunda kaldım. Bazen cevabı biliyorlarsa ancak teknik bir terimle ya da bir şeyle takıldıklarında, dolaylı olarak onları bu terime yönlendiren bazı sorularla yardımcı oldum. Kişilik ve teknik özelliklere ilişkin teknik raundun ardından ilk raundu geçmeyi başarsa ikinci bir görüşme yapıldı.

Bir çalışanda istediklerinizin bir kısmı takımın geri kalanıyla etkileşime girebilecek birileridir. Gereken beceriye sahip birine ihtiyacınız var, doğru. Ancak, yardım için ne zaman ulaşmaları gerektiğini bilen ve bu konuda kendi bilgi ve sosyal becerisine sahip olan birine de ihtiyacınız var. Bu son eşik seti, şirketi uzun vadede herhangi bir bilgisayar dili Du-jour'dan daha iyi kuracak.

Gördüğüm gibi, bir röportaj bir deneme değil, birlikte çalışma denemesidir . Öncelikle "Bu kişiyle çalışmak nasıl bir duygu?" Sorusuna cevap vermeye çalışıyorum. Bazen alıştırmayı daha işbirlikçi hissettirmek için sorunun cevabını unuttuğumu bile iddia ediyorum .

Hiç bir sorunla konuştuğunuzda aynı sayfada göremediğiniz birisiyle hiç çalıştınız mı ? Ya da içeri atlamak ve sorunları çözmek yerine çok fazla soru isteyen biri? Bir röportajda çoğunlukla konuştuğum kişinin onlardan biri olmadığından emin oluyorum. Orada güçlü bir kimya unsuru var.

Bu süreçte elbette "temiz kod yazıyor mu", "gerekli kavramlara aşina mı" ve "zekice kavrayışlara ulaşmak için bir sorun yaratabilir mi?" Gibi şeyler de öğreneceğim. Aday hala bir "sürüş" ve yazma kodu olacak. Ama umarım yol boyunca daha rahat olacak ve onunla birlikte iş arkadaşı olarak her gün görebileceğim şeye daha yakın bir versiyonunu göreceğim.