it-swarm.asia

SW mühendislik görüşmeleri neden orantısız bir şekilde zor (araştırma görüşmelerine karşı)?

İlk olarak, biraz geçmişim var. CS'de doktora derecem var ve hem yazılım mühendisi hem de Ar-Ge araştırma bilimcisi olarak, çok iyi bildiğiniz çok büyük şirketlerde çalıştım. Geçenlerde iş değiştirdim ve her iki pozisyon için de görüştüm (geçmişte yaptığım gibi).

Benim gözlemim: SW mühendisi iş görüşmeleri, CS araştırmacısı iş görüşmelerinden orantısız bir şekilde daha zordur, ancak araştırmacı işi daha yüksek ücret, daha rekabetçi, daha ödüllendirici, daha ilginç ve daha üst bir tarafa sahiptir.

İşte araştırmacı için tipik bir röportaj döngüsü:

  • Araştırmamın laboratuvarın araştırmasıyla uyumlu olup olmadığını görmek için telefon görüşmesi
  • Şahsen: son araştırmam hakkında bir saat boyunca sunum yapın (belki 9 aylık çalışmayı temsil eder) ve izleyicilerin sorularını cevaplayın
  • Çalışmam/yayınlarım/patentlerim hakkında çok makul sorular sordukları yaklaşık 5 araştırmacı ile yüz yüze görüşmeler: teknik sorular, çalışmamın ilgili işe girdiği yerler ve çalışmamı nasıl uzatabileceğim yeni alanlar

SW mühendisi için tipik bir röportaj döngüsü:

  • Bana algoritma soruları sorulan ve belki biraz kodlama telefon görüşmesi. Oldukça standart.
  • Beyaz tahtada, ezoterik C++ minutia (örneğin, polimorfik bir sanal fonksiyon çağrısı nasıl çalışır), algoritmalar (1B köşeleri için tüm çiftler-en kısa yol algoritmasının çalışmasını sağlayın) , sistem tasarımı (bir veritabanı yük dengeleyici tasarımı), vb. Bu altı veya yedi görüşme için devam eder. Saçma.

Neden kimse buna katlanmak ister? Kendinizi kanıtlamak için C++ trivia hakkında soru sormanın veya kod yazmanın anlamı nedir? Neden SE röportajını, yaptığınız şey hakkında konuştuğunuz araştırmacı röportajına benzetmiyorsunuz?

Fizik, kimya, inşaat mühendisliği, makine mühendisliği gibi diğer alanlarla ilgili teknik iş görüşmeleri nasıldır?

40

Araştırma yapmak için teknik olarak yetkin olup olmadığınızı belirlemek nispeten kolaydır - işe alma yöneticilerinin okuyabileceği yayınlarınız vardır ve bu yayınlar muhtemelen sizi kontrol etmek için konuşabilecekleri diğer insanlara ipucu verir.

Diğer yandan yazılım mühendisliği, işe alındığı kişinin aslında onu yazmayı planladığınız kodu yazabileceğinden emin olmak için çok fazla özen göstermesi gereken yetersiz alan atıklarıyla dolu bir disiplindir.

45
Wyatt Barnett

Burada bir uzuv çıkıyorum.

Doktora sahibi bir araştırmacı olarak, birçok tanınmış kuruluşa bir araştırmacı olarak değerinizi ve minimum niteliklerinizi zaten kanıtladınız. Bir tezi akranlarınızın yönetim kurulunun önünde başarılı bir şekilde savundunuz ve en az bir akran incelemesi yayınını çalışmanızı yayınlamaya ikna ettiniz.

Yazılım geliştirme ise hiçbir yeterlilik standardına sahip değildir. İnsanlar rutin olarak bilgi tabanlarını şişirirler. Sonuç olarak, yazılım geliştirme görüşmeleri, doktora savunması ve akran denetiminin akademide yaptığı tüm işleri yapmak zorundadır. Neden bahsettiğinizi gerçekten bildiğinizi kanıtlamanızı sağlarlar.

30
Ryan Michela

Bunu bir an için düşünün.

Bu CS araştırmacısı işi için başvurmaya çalışırsam CV/Özgeçmişime bakmazdım. İlk etapta röportaj yapmam. Özgeçmişime bakmaya bile yetkin olmadığımı söyleyen standart bir "ileri derece yok" mektubu alırım.

Sorularım şu: "Doktora almak neden bu kadar zor?" Ve "CS araştırmacısı olmak için neden bir doktora ihtiyacım var?" "Neden bu kadar çok engel ve engel var?"

Neden kimse buna katlanmak ister?

Tüm bu ders çalışmasını yapmanın ve dergilerde ve konferanslarda araştırmaların basılmasının anlamı nedir? Neden sadece araştırmayı yapıp mühendislik için benden daha fazla ödeme alamıyorum?

Kimlik bilgileri oluşturmak için neden lisansüstü okullara ve yayınlara güvenmelisiniz? Neden araştırma röportajını, röportaj sırasında her şeyin şu anda hatırlayabileceğinize bağlı olduğu SE röportajları gibi daha fazla yapmıyorsunuz?

17
S.Lott

Bir teorim var. Araştırmalar genellikle hibelerle ödenir, bu nedenle nakit arzı yüksektir. Harcamak için bir kova paraları var ve sadece harcayacak birini bulmaları gerekiyor. Bu pozisyonda gerçekten bir şey başarsanız da başaramasanız da, şirket/kurum zaten hesaplanmış bir gider olduğu için net zarar kaydetmez. Yanlış kişiyi işe alma konusunda çok az risk vardır. En kötü senaryo, yaptığınız her şeyi atmalarıdır.

Öte yandan, mevcut ürünlerin başarısı veya başarısızlığı günlük geliştiricilerin omuzlarına dayanmaktadır. Özellikle ürün geliştirme aşamasındaysanız, şirket için bir kâr merkezisiniz. İyi veya kötü geliştiricilerin maaş maliyetlerinin çok ötesinde büyük bir etkisi vardır. Kötü bir geliştirici aslında hasara neden olur. Bir takımı, ürün lansmanını vb. Geri alabilirler. Kötü bir SW mühendisini işe almanın sonuçları çok daha yüksektir.

6
Scott Whitlock

Kısa cevap: Piyasada programlamayı bildiğini iddia eden, ancak programlayamayan çok sayıda insan var.

Yan açıklama: Kimsenin FizzBuzz denemesi için bir bağlantı yayınlamadığı için şaşırdım.

5
Nikita Barsukov

Firmamız ayrıca "çok sayıda zor soru soruyor" ve nedenini açıklayacağım. Sanal bir işlev çağrısının nasıl yapıldığını gerçekten bilip bilmediğinize önem veriyoruz, ancak yapacağınız iş için çok kritik bir şekilde gerekli olduğu için değil.

Bunun yerine önemsiyoruz çünkü temel şeyleri ne kadar hızlı öğrenebileceğinizi bilmemiz gerekiyor. X yıllık tecrübe mi talep ediyorsunuz? Tamam, sağlam bilgiye sahip olup olmadığınızı öğrenmek için zor sorular soracağız.

Sanal işlev çağrısının kaputun altında nasıl yapıldığını bilmiyorsunuz, ancak profil oluşturma ve optimize etme hakkında her şeyi biliyor musunuz? Harika, muhtemelen sizi işe alıyoruz - bir alanda sağlam bilgi edindiniz ve böylece başka bir alanda kesinlikle sağlam bilgi kazanacaksınız.

X yıllık deneyimini "C++ kodunu geliştirme, hata ayıklama ve düzeltme" iddiasında bulunuyorsunuz. Üzgünüz, sizi işe alamayız - bunu yapamazsanız karmaşık teknik kararlar almamız gerektiğinde daha zor sorunları nasıl açıklayacaksınız?

5
sharptooth

Alanında 20 yılı aşkın bir süredir yazılım geliştiricisiyim (c/c ++). Şu anda rutin olarak gördüğümüz röportaj türleri (zeka oyunları, veri yapılarının uygulanması, beyaz tahta üzerinde arama algoritmaları vb.) Yeni mezunlar dışında pek bir şey yapmadı. Bir kişi saygın bir şirkette makul bir süre çalıştıysa, bu, kod yazma yeteneğinin kanıtı olarak kabul edildi. Şimdi çok okullu ve neden emin değilim. Gerçekten, kodlamalarını istedikleri tipik şeyler, ezberlenebilir, böylece beyaz tahtada yapmak gerçekten hiçbir şey kanıtlamaz. Bir iş projesinde, interneti bir şeyi araştırmak için kullanırsınız ve sıfırdan btrees veya bağlantılı listeler yazmazsınız. Şirketlerin şimdi gerçekten ihtiyaç duydukları yenilikçilerdir ve birisinden üniversitenin hafıza yapılarından yazabileceğini kanıtlamasını istemek yenilik göstermez.

Sanırım başka bir yönetim fad - tıpkı scrum gibi - bu muhtemelen google, Amazon ve Microsoft tarafından başlatılıyor. Herkes tıpkı Jack Welch'in rütbesinde olduğu gibi kopyalandı ... GE'yi hatırlıyor musunuz?

Eğer yorumlarımı okuyan bir işe alım müdürüyseniz, adaylara sormanız gereken şey, NASIL bazı sorunları çözmektir. Karma tabloyu kodlamalarını istemek yerine, karma tablo içeren bir sorun verin ve tabloyu nasıl çözeceklerini sorun.

Ben de "onlara şirketin çözmek zorunda gerçek bir dünya sorunu vermek" dedi bu yazının üzerinde geliştirici ile katılıyorum!

"ama OOP/Miras sorularını bombalama eğilimindeyim. Neden? Şablonlar için destek eklendikten sonra C++ 'ı neredeyse yalnızca Genel Programlama için kullandım."

Yukarıdakilere de katılıyorum. Bir şirket için çalışırken kod THEIR yolunu yazarsınız. Bazen C++ çağrısını kafamın üstündeki referans sözdizimi ile hatırlamak için mücadele ediyorum çünkü 15 yıldır çalıştığım şirketteki kıdemli mimar referansları değil, işaretçileri kullanmayı tercih etti. Gördüğünüz eski bir C programcısıydı. Yani hepimizin kullandığı bu.

3
guest

Farklı bir rota izleyeceğim ve sorunun yazılım mühendisliği mülakatlarının doğası gereği daha zor olmayabileceğini değil, farklı sektörlerin mülakat tarzında gösterilen farklı şeyler aradığını söyleyeceğim.

Oldukça geniş bir sektör yelpazesinde (örneğin, başlangıç ​​şirketi, küçük şirket, büyük şirket, dahili BT departmanı, yazılım şirketi, araştırma organizasyonu) röportaj yaptım ve hepsinin genellikle farklı bir görüşme yöntemi var aşağıdaki modeli takip edin:

  • Yeni başlayanlar, kod yazmaya başlayabileceğinizi bilmekle ilgilenme eğilimindedirler şu anda ve hızlı tempolu bir ortamla başa çıkabilirler. Bu nedenle, görünüşte "çekirdek" bilgi olarak gördükleri her şeyi ararken sizi çok fazla zaman harcadığını görmek istemedikleri için, kafanızın üst kısmından ne kadar bildiğinizle ilgilenme eğilimindedirler. Bilmenizi bekledikleri bir şeyse, bir şey bilmediğinizi kabul etmek bu ortamda bu kadar iyi bir şey olmayabilir.
  • Küçük şirketler, ne kadar bildiğinize bağlı olarak yeni başlayanlarla aynı şeyleri arama eğilimindedir, ancak hızlı tempolu ortamları (işe bağlı olarak) ne kadar iyi idare ettiğinizle ve daha ne kadar yumuşak becerilerle ilgilendiğinizle ilgili değildir. ve şirkete ne kadar iyi uyacaksınız.
  • Büyük şirketler ve dahili BT departmanları, belirli bir teknik bilgi standardına sahip olduğunuzdan emin olmakla daha fazla ilgileniyor gibi görünüyor, ancak bazılarının olacağını tahmin ettikleri için kafanızın üst kısmındaki her şeyi bilmiyorsanız endişelenmiyorlar. Şirketin beklentileri konusunda eğitim almanız için gereken süre. Böylece, bu, bir şey bilmediğinizi ancak öğrenmeye ve çalışmaya istekli olduğunuzu kabul etmenin bir fayda olarak görülebileceği bir ortamdır.
  • Araştırma ortamında (yani, deneyimlerimdeki bilim adamları için yazılım geliştirme desteği), yazılım yazabiliyorsanız endişe etme eğilimindedirler, ancak daha fazlasını yapmak istiyorsanız, ne yaptıklarını öğrenebilmeniz için gerekli olanı yapmak istiyorsanız bir sorunu çözmeye çalışırken ellerinizi tutmaları gerekmez. Aynı zamanda bir araştırma ortamı olduğundan, yeni şeyler öğrenmekle ne kadar ilgilendiğinizle de ilgileniyorlar.

Şimdi, yazılım şirketlerinden (yani Google, Microsoft) kendi şeylerini yapma eğiliminde olduklarından ve şirketin ne kadar olgun olduğuna ve hangi grupla görüştüğünüze bağlı olarak, farklı şeyler aradıklarından bahsetmeyi ihmal ettim.

Günün sonunda ve hayattaki çoğu şeyde olduğu gibi, hepsi bağlıdır. Şahsen ben bazı şirketlerin çok daha yüksek düzeyde sorunları çözme pahasına olabilir diğer kitapların daha üst düzey sorunları ne kadar iyi ele endişe gibi görünüyor "kitap bilgisi" odaklanmış bulduk (yani x için bir şema tasarlayabilir ve tamamen üretken olmadan önce sizi tam olarak hızlandırmak için üç ila altı ay yatırım yapmaya istekli oldukları varsayımı altında çalışabilir misiniz?.

3
rjzii

Yine, teknoloji mülakatı keyfi ve kaprislidir.

Minutiae'de bir kişiyi ızgara yapmakla CS'lerini bilip bilmediklerini görmek arasında büyük bir fark vardır. Yukarıda söylediğim gibi, C++ ile on yıldan fazla deneyime sahibim, ancak OOP/Miras sorularını bombalama eğilimindeydim. Neden?Şablon desteği eklendiğinde, C++ 'ı neredeyse yalnızca Generic Programming.

Bay Area & Seattle'daki birkaç BigHouseHoldNameTech şirketi ile röportaj yaptım ve en iyi röportajlardan biri gerçekişte uğraşmak zorunda kaldıkları, veri yapılarını içeren sorular ve algoritmalar [ie: XYZ'den oluşan 300 milyar veri noktanız var. Nasıl verimli bir şekilde saklar ve ararsınız?].

Bu, bir adayın nasıl devreye girebileceğini ve karşılaştığınız gerçek sorunları çözmesine yardımcı olabileceğini hemen hemen bilmenizi sağlar. Mutlak daha da kötü bir başka BigHouseHoldNameTech şirketi ile oldu, ama onlar gerçekten sadece bir el kitabında bakmak gerektiğini inanılmaz derecede gizli sorular değerinde saat sordular [ i.e. PCB - ve bu çekirdek düzeyinde bir konum için değil] arasındaki temel farkları açıklayın

Hedge fonları, işkence yapma niyetleri ile tuhaftır ... 8 saat boyunca beyaz tahtada knapsack tip problemleri çözmeyi bekleyin.

2
red-dirt