Tipik mülakat sorularında kullanılan beceriler gerçek işte nasıl uygulanır? [kapalı]


13

SQL ve C # app dev işleri için, görüşmeciler genellikle saf C ve işaretçiler kullanarak ağaç, grafik ve bağlantılı liste geçişleri hakkında sorular sorarlar. İşimde geçirdiğim 3 yıl içinde, aslında

verilen düğümün sağındaki 1. düğümün yolunu bul

Örneğin

Bu becerilerin derleyiciler, sürücüler yazmanız ve işletim sistemi çekirdeği üzerinde çalışmanız gereken işlerde kullanılabileceğini görebiliyorum. Bunların dışında, bu beceriler başka nerede kullanılır?


5
En temel veri yapıları ile mücadele ederseniz, çoğu zaman programlamayla mücadele edeceksiniz.
Mert Akcakaya

Yanıtlar:


15

Joel'in cevaplarından bazılarını aşağıda okuyun.

Özellikle ressam Schmiel gibi bir şeye dikkat edin. İşte, asla bağlantılı bir listeyi yeniden yazmak zorunda kalmayabilirsiniz , ancak kesinlikle başlık altında nasıl çalıştığını bilmelisiniz, böylece Schmiel'den kaçınabilirsiniz.

Temel olarak, doktora gidiyorsanız, o doktorun anatomi okumasını istersiniz. Her ne kadar ona sadece bazı AntiHistamin reçete ediyor olsa da, bir doktor tıp fakültesinde bazı ilaçların 'alt femur için kronik fractios diamadabada' olan insanlar için kötü olduğunu veya herhangi bir şeyi öğrenmiş olacaktır. Bu uzmanlık alanındaki HER ŞEY hakkında derinlemesine bilgi sahibi olmak bazen yaşam ve ölüm arasında ve Bilgi Teknolojisinde ürünün yaşamı ve ölümü ya da bir iş arasında farklılık yaratabilir.

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

http://www.joelonsoftware.com/articles/fog0000000319.html

"... makineye yaklaşmak için en az bir dönem harcayın yoksa üst düzey dillerde hiçbir zaman verimli kod oluşturamazsınız."

“... sen batıl inançlara göre programlıyorsun, benim kadarıyla: temel anatomiyi bilmeyen bir ilaç doktoru, ilaç satış bebeğinin ne işe yarayacağına dayanan reçeteler çıkarıyor.”

http://www.joelonsoftware.com/articles/CollegeAdvice.html


22

Onlar değil. Birçok röportaj, yetenekli geliştiricileri nasıl arayacağını bilmeyen ve hangi soruları sormaları veya sormamaları gerektiğini bilmeyenler tarafından yapılır.

Çoğu görüşmeci teknik soru sormaz ve katıldığınız proje sayısı (bu görüşmeciler için daha fazla) veya üniversite derecesi (daha yüksek onlar için daha iyidir) gibi anlamsız ancak ölçülebilir şeylere daha fazla odaklanır ). Hiçbir şey öğrenmeden beş yılını üniversitede boşa harcayan ve on yıllarını onlarca e-ticaret web sitesi yaparak geçiren bir kişiyi işe almaktan mutlu olurlar, ancak birkaç yıl sonra üniversiteyi terk eden ve birkaç kişi üzerinde çalışan bir kişiyi işe almazlar. teknik açıdan zorlu büyük projeler.

En azından teorik sorular sormak, hiç sormamaktan daha iyidir. Bu, kişinin yeterli teorik bilgiye sahip olduğunu ve programlama konusunda birkaç yıllık deneyime sahip olabilecek bir kodlayıcı olmadığını, ancak başlık altında neler olduğunu gerçekten anlamadığını doğrulamanın bir faydasına sahiptir. Bu teorik bilgiye sahip olmayan geliştiriciler genellikle list liste, bağlantılı liste arama veya karma küme arasındaki farkı bilmez ve bunları birbirlerinin yerine kullanırlar.

İyi (teknik) sorular, kötü sorular

Röportajlar sırasında çok iyiden son derece kötüye kadar değişen sorularla karşılaşabilirsiniz:

  1. (Zararlı) "Bu dilde yazdığınız en uzun çalışma programının satırlarındaki uzunluk nedir?"

    Bu soru açıkça yanlış. Neden başka bir cevapta açıkladım . Görüşmecilerin bu tür sorular sorduğu şirket, geliştiricilerin verimliliğini LOC / ay olarak değerlendirmek için güçlü bir şansa sahiptir. Bir tavsiyede bulunmam gerekirse: böyle bir işe ihtiyacınız yok.

    Bu örnek, cevabımın başında alıntıladığım anlamsız ama ölçülebilir şeylerden farklı . Burada, görüşmeci ayrıca zararlı olduğu bilinen bir metrik seçerek metrikleri en temel şekilde anlamadığını gösterir.

  2. (Kötü) "Dennis Ritchie kim?"

    En azından bir kültüre sahip olmak gerçekten çok faydalı, ancak bu soruyu sormak noktayı kaçırıyor. Şirket, yazılım geliştirme projelerini işleyebilen ve kod yazabilen yetenekli geliştiriciler ararsa, C ve Unix'i oluşturan kişinin adını bilmemeleri çok önemli olmamalıdır.

  3. (İyi) ".NET 4.5'in yeni özellikleri nelerdir?"

    Bu soru Dennis Ritchie ile ilgili sorudan çok daha ilginç. Aday .NET 4.5'teki yeni özellikler hakkında konuşamıyorsa, neden kendisine C # geliştiricisi diyor? Bu bilginin eksikliği:

    • Kişinin ne programlama dili ne de .NET topluluğu ile gerçekten ilgilenmeyebileceğini gösterir,

    • Kişinin C # /. NET'in özellikleri hakkında bazı önemli bilgilere sahip olmayabileceğini gösterir, diğer geliştiriciler günlük değilse, en azından sıklıkla kullanırlar.

    Ayrıca , bu tür soruların daha ayrıntılı bir analizini içeren Jerry Coffin'in cevabına da bakınız .

  4. (Ortalama) "Hangisi daha hızlı, SSD veya RAM?"

    Bu yararlı olabilir ve kişinin yeterli donanım bilgisine sahip olup olmadığını gösterir, ancak yine de, bu soruyu cevaplayamayan bir aday reddedilmemelidir.

  5. (Ortalama) "Yığın ve kuyruk nasıl uygulanır?"

    Bu, bahsettiğiniz bir tür soru. Teorik, belki de çok teoriktirler, ancak başlık altında neler olduğunu bilmek daha iyi kod yazmanıza yardımcı olabilir.

    Bu soruya cevap veremeyen bir adayı reddetmezdim, ama gerçekten bir şeyleri biliyorsa daha dikkatli bir şekilde kontrol edeceğim, örneğin ilgili ama daha az teorik bir soru sorarak:

  6. (İyi) "Özyineleme kullanmadan bir ağaçta nasıl yürüyebilirsin?"

    Aday bu soruyu cevaplarsa, FILO / FIFO ve bir yığın kullanmanın ağaçta gezinme için bir özyinelemeye karşı yararları ve dezavantajları hakkında konuşursa, önceki soruyu cevaplayamadığı gerçekten önemli değildir.

    Bu soruyu sormak, aynı zamanda CS derecelerini yaparak yıllarını harcayan, ancak alan deneyimi olmayan adayları saptamanın iyi bir yoludur.

İyi teknik sorular nasıl sorulur?

kojiro'nun yorumu ilginç ve daha uzun bir cevabı hak ediyor:

Bazen birisini tam olarak işe almanız gerekir, çünkü bir konu hakkında sizden daha fazla bilgi sahibi olmalıdırlar, bu yüzden tanım gereği röportajı yapmak için yetersiz kaldınız. Aynı nedenle röportaj yaparken bile güvenilir bir şekilde yardım alamazsınız. Yapabileceğiniz en iyi şey, anlayışınızın sorun alanıyla kesiştiği yere göre sorular sormaya çalışmaktır ve şanslı olmanızı umuyoruz.

Özellikle ilk geliştiricinizi işe aldığınızda veya şirkette çalışan tüm geliştiricilere göre daha yetenekli olması beklenen bir geliştiriciyi işe aldığınızda iyi sorular bulmak zor olabilir.

İşte size yardımcı olabilecek üç ipucu:

  1. Eğer yetenekli olduğuna inandığınız ve sormak arkadaş / iş arkadaşı bulun onu değerlendirmeleri yapmak. Bu çok güven gerektirir, ancak şirketinize çok fayda sağlayabilir.

  2. Yetenekli olduğuna inandığınız bir danışman bulun ve ondan size yardım etmesini veya röportajın teknik kısmını yapmasını isteyin.

  3. Google'a "röportaj soruları" yazın. Oldukça iyi çalışıyor ve genellikle olası cevapları açıklıyor. Misal:

    • Python : Bu on soru oldukça iyi görünüyor. Belki biraz temeldir, ancak yine de işe almak istemediğiniz% 95 adayların filtrelenmesine yardımcı olacaktır.

    • Dave Pinal SQL , her zamanki gibi mükemmel.

    • C # : biraz fazla temel, ama yine,% 95 adayı filtreleyecekler,

    • JavaScript : sorular daha açık uçlu, röportajın kısa olmasını ve açık uçlu teknik olmayan sorular için daha fazla zaman ayırmanızı istiyorsanız teknik sorular için iyi bir şey olmayabilir. Liste, JavaScript'teki temel kavramları anlamayan adayların kolayca filtrelenmesine yardımcı oluyor.

    Bu yaklaşımın dezavantajı, adayın görüşme için eğitim vermek üzere aynı tekniği kullanabilmesidir. Google'da bulduğu ilk web sitesinin her sorusunu incelediyse, gerekli becerilere sahip olmadan iyi bir puan alabilir.


B Bir B ağacının ne olduğunu açıklayamayacak ("bazı veri yapısı" dışında), ancak yine de doğru şekilde gelişebilen bazı geliştiriciler var.


Sevmiyorum, ama doğru. Bazen birisini tam olarak işe almanız gerekir, çünkü bir konu hakkında sizden daha fazla bilgi sahibi olmalıdırlar, bu yüzden tanım gereği röportajı yapmak için yetersiz kaldınız. Aynı nedenle röportaj yaparken bile güvenilir bir şekilde yardım alamazsınız. Yapabileceğiniz en iyi şey, anlayışınızın sorun alanıyla kesiştiği yere göre sorular sormaya çalışmaktır ve şanslı olmanızı umuyoruz.
kojiro

Veya bir danışmana veya diğer geliştiricileri işe almak için yetenekli olduğuna inandığınız birine yardım isteyebilirsiniz. Tabii ki, bu bir soru doğuruyor: danışman / arkadaşın bu görev için yeterince nitelikli olduğunu nasıl biliyorsunuz?
Arseni Mourzenko

“üniversitede geçirdiğiniz yıl sayısı (daha fazlası daha iyidir)” ... bu nasıl iyi?!? Eğer lisans derecesi almak 15 yıl alırsa, 3 yıl içinde alan birinden daha iyiyim? Üniversiteyi düzenli olarak bitirebilenlere göre "başarısız öğrenciler" tercih edilmemelidir ("başarısız öğrenci" terimini buradan aldım , umarım çeviri doğrudur.) Bunu demek istemediyseniz, belki açıklığa kavuşturmalısınız çünkü orada ne ifade etmek istediğiniz belli değil.
Bakuriu

@Bakuriu: gerçekten, bu demek istediğimin tam tersi. Cevabı daha açık hale getirmek için düzenledim.
Arseni Mourzenko

2
FWIW Size .NET 4.5'in tüm yeni özelliklerine yakın bir yerde anlatamadım ve bazılarını yazdım. Bu şeyleri bilmek istersem, bir arama motoruna ".NET 4.5'in yeni özelliklerini" yazıyorum ve bana bir liste veriyor.
Eric Lippert

6

Birçok röportaj yaptığım şirketimdeki tecrübelerime göre, görüşen kişinin bunu nasıl doğru yapabileceğine dair hiçbir fikri yok. Böylece bir dizi teknik soru hazırladılar ve bunun bir puanını hesapladılar ve özgeçmişinizi yapın. Ancak bunun birçok dezavantajı vardır ve aşağıdaki nedenlerle yapılmamalıdır:

  • Nokta bilgisi istersiniz. Programcı bu alanda hiçbir zaman bir şey yapmadıysa, hala mükemmel bir iş arkadaşı olabilir, ancak bu belirli cevabı bilmiyor olabilir. Aksine: Birisi röportaj için hazırlamış ve internetteki bu sorunun cevabını bulmuşsa, doğru cevabı alırsınız, ancak o kişinin asıl konu hakkında hiç bir fikri olmayabilir.

  • İş görüşmelerinde insanlar gergin. Beyin panikteyse birçok üst düzey alanı (mantık gibi) kapatmak için bu harika özelliğe sahiptir, yani: Eğer gerginseniz, günlük durumda yapacağınız cevapların kalitesini sunamayabilirsiniz. Bazı insanlar röportaj gibi stresli bir durumla başa çıkabilir, çoğu yapamaz.

  • Tek ve doğru bir cevapla, kişilerin belirli bir cevabı bulma becerisini test edersiniz. Bu, bir iş arkadaşının ihtiyaç duyduğu birçok beceriden biridir, ancak gerekli olan tek şey değildir. Bu nedenle, bu sorulardan biri veya ikisi bu bilgi alanını test etmek için yeterli olmalı ve daha sonra diğer beceriler sorgulanmalıdır. Sadece problem çözme soruları içeren bir röportaj aynı beceriyi tekrar tekrar test eder.

İyi programlama görevleri soruları nelerdir?

Bu ünlü "Kısa bir program yazabilir misiniz?" Soruları, çoğu programcının IDE'si onlara yardımcı olmadan tek bir kod satırı yazamayacağı kadar büyük bir soruna sahiptir. Ancak bu günlük çalışma koşullarında hiçbir sorun yoktur, çünkü programcı her zaman IDE'sine yardımcı olur. Bu nedenle, "Hatayı bulun", "50 kod satırı yazın ..." gibi soruları sormak veya hatta basit soruların dikkate alınması gerekir; başvuranın araçlarının (IDE, Google) mevcut olmaması gerekir.

Örneğin, Google'ın bana yardım etmesi durumunda 1 dakika içinde size herhangi bir soruyu cevaplayabilirim, ancak İnternet bağlantısı olmadan çaresiz görünüyorum. Buna dış kaynaklı bellek diyorum ve beni engellemekten ziyade, gerçekten önemli olana, altta yatan mekaniği anlamaya - odaklanmamda çok yardımcı oluyor çünkü diğer her şey aranabilir. Ancak bana herhangi bir rastgele API'den ayrıntı sorma, çünkü bunları bilmiyorum, bunun için Google'ım var.

Bu iyi bir programlama görev soru gerektiğini söyledi değil bu iş için mutlak bir gereklilik olmadığı sürece bilerek API'ler veya özel kodlama becerilerine odaklanır. Bilgi edinilebilir, bu yüzden o kişinin bilgi edinmede ne kadar iyi olduğunu bulmak, zaten ne bildiğini sormaktan daha iyidir.

Bir programlama görevi için iyi bir soru kısa, basit, her dilde sadece birkaç satır kodla kodlanabilmeli ve özellikle de kişinin nasıl çalıştığı ve cevapları bulduğu hakkında mümkün olduğunca fazla bilgi vermelidir . Misal:

"Seçtiğiniz dilde bir tamsayı dizisi alan bir işlevi yazın ve bunları ilk tamsayı sonradan son olacak şekilde yeniden sıralayın ve diğerleri buna göre değişir."

Herhangi bir başvuranın bu noktada sorması gereken ilk soru şudur: "Üzgünüm ... lütfen görevi açıklayabilir misiniz?". Çünkü hiçbir programcıya ne yapılacağı konusunda net bir açıklama yapılmamıştır. Bunu, sorulardaki kodun, taşma sağa eklenecek şekilde dizinin içeriğinin sola kaydırılması gerektiği açıklaması gelir.

Bu görev o kadar basit ki, herhangi bir programlama seviyesinden mezun olan herkes düzgün cevap verebilmelidir. Bu, programcının araçları olmadan çalışması gerektiğini ve gergin olmanın mantıksal düşünme yeteneğini azalttığını dikkate alır. Ancak yine de insanların problemleri sorunun nasıl ifade edildiğinden ve insanların yaklaşımına göre nasıl çözdüklerini anlatıyor, çünkü bir sola kaydırma ortak 'soldan sağa' içgüdüsüne karşı ve insanları düşünmeye zorlıyor bir saniye.

Bu sorunun birçok olası cevabı vardır, bu nedenle kodun geliştirilme şekline yakından bakmak, çözümün gerçekten işe yarayıp yaramayacağı önemli bir parçadır. Başvuru sahibi null için test yapıyor mu? Taşma nasıl saklanır? Bir döngü veya bir mem kümesi kullanılıyor mu? Başvuru sahibi kod doğruluğunu nasıl doğrular? Bu basit soru size bu kişinin nasıl çalıştığı hakkında tüm bir biyografiyi anlatır.

İyi genel bilgi soruları nelerdir?

İyi soruları cevaplamak kolaydır, çok sayıda cevaba izin verin ('açık sorular' olarak adlandırılır) ve başvuru sahibi hakkında kısa sürede olabildiğince çok şey öğrenmenizi sağlar.

Örnekler:

(Bir C ++ programcısına sormak): "C ++ dışında başka hangi dilleri biliyorsun?"

Bu, giriş seviyesi soruları olup, başvuru sahibine, sorulan konu hakkında hiçbir şey bilmemesi durumunda, şu anda kefalet etme şansını verir. Bu noktada bir 'hayır', herkesin cevaplaması gereken birkaç soru ile ona işkence etmekten daha iyidir: "Üzgünüm, bunun hakkında hiçbir şey bilmiyorum."

Buna ek olarak, öncelikle size o kişinin bildiği diğer dilleri söyler, ayrıca o kişinin programlama dünyasını daha geniş bir şekilde görmek için ne kadar ilgilendiğini veya yalnızca tek bir dile (ve dolayısıyla özellik / tekniklere sahip) ) görünüm.

(Bundan sonra Java bildiğini söyleyelim): Düşüncenizde C ++ ve Java arasındaki ilk üç fark nedir? "

Bu, birçok cevaba izin veren açık bir sorudur, bu nedenle başvuru sahibinin en az üç tane bulma şansı yüksektir. İlk üç (kişisel görüş) istemek sadece olası cevapları sınırlamakla kalmaz, aynı zamanda başvurucuyu önceliğe göre sıralamaya zorlar. Yine de cevaplaması kolaydır (veya olmalıdır).

Bu, farklı programlama dilleri hakkında çok sayıda derinlemesine bilgiyi test eden basit bir sorudur. Bu konuların bilgisi gerçekten ne kadar derin? Bu cevaplardan, programlama dillerinin temel mekaniklerinin bilgisi ve gerçek anlayışı hakkında çok şey anlatabilirsiniz. Bu kişinin kirli ayrıntılarla ne kadar harcadığı veya o sadece çeşitli API işlevlerini gerçek bir ipucu olmadan birbirine bağlayan bir kişi ise, bunların altında ne olduğuna dair.

Bu giriş seviyesi sorular ve ardından basit derinlemesine bilgi soruları kavramı diğer birçok konu için de kullanılabilir. Her zaman bu şemada: kefalet sorusu, doğrulama sorusu, derinlemesine soru. Başka bir örnek (Java röportajından):

  1. "Çok iş parçacıklı geliştirme deneyiminizi nasıl değerlendirirsiniz?"
  2. "Lütfen çok iş parçacıklı bir uygulama geliştirirken göz önünde bulundurmanız gereken en önemli üç şey olduğunu düşündüğünüzü belirtin."
  3. "Lütfen Java API'sından bu uygulamaları geliştirmenize yardımcı olabilecek üç sınıfı adlandırın ve ne için kullanıldıklarına dair kısa bir açıklama verin."

Bu üç soru, başvuru sahibinin bu konular hakkında gerçekten bildikleri teknik sorudan daha fazlasını söylerken, nokta bilgisi ve stres düzeyini göz önünde bulundurarak cevaplamak için adil olacaktır.

Birisi size arka arkaya 20 kodlama sorusu sorduğunda, birisiyle düzgün bir şekilde nasıl röportaj yapılacağına dair temel bir fikri olmadığını biliyorsunuz. ;)


Bu aslında imo ile röportaj hakkında gerçekten iyi bir tavsiye. Gerçekten daha fazla insanın bunu takip etmesini diliyorum.
Evicatos

5

Uyarı .

Cevabında @MainMa ".NET 4.5'in yeni özellikleri nelerdir?" "iyi" bir soru olarak.

Naçizane size katılmıyorum. İfade ettiği gibi, bunun en iyi ihtimalle oldukça vasat bir soru olduğunu söyleyebilirim. İyi bir soru şöyle olacaktır: "Bugün yazdığınız kodun N yıl önce yazdığınız koddan farkı nedir?" (özgeçmişte listelenen yılların deneyiminden daha az, tercihen yaklaşık 3 ila 5 olan N değeri için).

İfade ettiği gibi, soru ezberle ilgilidir. Bu aday özellik listesini tamamen ezberledi mi? Haklarına göre, Microsoft'un listesini en doğru şekilde veren kişi kazanan olmalıdır.

İlgilenmeniz gereken şey onun programlaması. Bu kodunu nasıl etkiledi? Bu özelliklerden hangisini gerçekten kullanıyor ? Daha da önemlisi, hangi yeni özelliklerin ne zaman kullanılacağı ve daha eski özelliklerin ne zaman mükemmel bir şekilde yeterli olduğu konusunda iyi muhakeme gösteriyor?

Sadece "LINQ" diyebilmeniz size aday hakkında neredeyse hiçbir işe yaramaz. "LINQ, kodumu çok daha kompakt ve okunabilir hale getirmeye yardımcı oldu, çünkü X, Y ve Z kavramlarını temiz ve doğrudan ifade edebilirim, burada daha önce bu şeyleri yapmak için aşağıdaki yanan halkalardan atlamak zorunda kaldım." (veya benzer bir şey) size aday hakkında, ne tür bir kod yazdığı, yargısı, esnekliği vb. hakkında çok şey anlatır. Ayrıca, bu kişinin sorunlar hakkında nasıl düşündüğü, kod yazdığı, kod hakkında düşündüğü vb.Gibi takip soruları için çok daha fazla fırsat verir. Son olarak, bunun gerçekten N yıllık tecrübesi olan bir aday mı yoksa N kez tekrarlanan bir yıllık tecrübesi olan bir aday olup olmadığı hakkında çok daha iyi bir fikir verir.

Özet: Birkaç yıl önce bir özellik listesini alıntılamak işe yaramaz ve size herhangi bir gerçek kullanımı olabilecek aday hakkında çok az şey söyler. Adayın bir programcı olarak ilerlemesi büyük olasılıkla daha fazla ilgi çekecektir, bu yüzden daha doğrudan sormak daha iyidir.


+1. Adayın yeni özellikler listesini sıralamamasını, hangi özellikleri kullandığını ve nedenini açıklamasını bekliyorum; ama cevabım bunu yeterince açıklamıyor, sizinkini açıklıyor.
Arseni Mourzenko

@MainMa: Bu beni şaşırtmıyor - bu yüzden cevabımda birkaç kez tekrarladığı gibi tekrarladım.
Jerry Coffin

3

Gerçek şu ki, geliştiricilerin çoğu profesyonel yaşamlarında günlük işlerin çoğu önemsizdir; Bu, bir iş görüşmesinde karşılaştığınız bazı soruların sizinle gerçekte asla karşılaşamayacağı anlamına gelir, ancak bu, bu soruları sormanın bir anlamı olmadığı anlamına gelmez.

Şirketinizde açık bir pozisyon olduğunu ve şu anda insanlarla görüştüğünüzü varsayalım. Kuyrukta zaten 20-30 geliştiriciniz var. Peki bu pozisyon için en iyi adayı nasıl seçersiniz? Bu işte yapmaları gereken en zorlu görevin dosya sisteminden bir dosya açmak, veriyi satır satır okumak, hafifçe değiştirmek ve orijinal dosyaya geri koymak olduğunu varsayalım.

Onlara nasıl dosya açacağınızı soracak mısınız ? Eminim cevaplar arasında gerçekten büyük bir fark göremezsiniz. Bu nedenle, sadece bir dosyayı nasıl açacağını bilen geliştiriciler ile kötü göt gerçek zamanlı bir uygulamayı nasıl geliştirebileceklerini ayırt etmek için bir çözüm bulmalısınız. Tho bile böyle bir uygulama oluşturmalarını istemiyorsunuz, ama yine de en iyi adayı işe almak istiyorsunuz.

Hayatımızdaki diğer her şey gibi, daha fazla bilgi edinmeniz gerektiğini fark ettiğiniz bazı noktalar vardır. Bağlantılı bir listenin ne olduğunu bilmiyorsanız, bana bir programcı olarak, bu kelimenin tam anlamıyla profesyonel hayatınızda o noktaya ulaşıp o şeyi öğrenmeniz gerektiğini hissetmediğiniz anlamına gelir. Neden? Çünkü becerilerinizi bu seviyeye kadar geliştirmenizi gerektirecek kadar büyük bir projeye hiç katılmadınız. Eğer giriş seviyesindeyseniz, bu iş için gerçekten hiçbir çalışma deneyimim yok diyebilirsin, ama yine de bunu biliyorsan, kendini ortalamanın üzerinde kesecek kadar kendini motive ettiğin anlamına gelir. en azından.


2

Bu görevleri yerine getirmek için gerekli beceriler nadiren önemlidir. Soruyu cevaplama yaklaşımında ve sonraki diyalogda gösterilen beceriler bütün mesele.

Geliştiricilerle görüştüğümde (a) akıllı (b) işleri hallediyor (c) sığacak. Herhangi bir rolü doldurmak için gerekli olan, yeni öğrenme ve edinme isteği ile gitmek zorunda olan temel bir teknik bilgi seviyesi var. Beceriler. Röportaj, bu kutuları işaretlemekle ilgilidir.

Benim tercihim bir başvuru sahibi tarafından yazılan kodu okumaktır. Konserve mülakat sorularını sevmiyorum, ancak kod yokluğunda konuşacakları bir şey sağlıyorlar. Liste ve koleksiyonlardan ziyade RAII veya IOC veya IDisposable'ın uygulanmasını sormayı tercih ediyorum, ancak yeterince teknik alabildiğimiz sürece her şey yapılacaktır .

Görüşmecinin en büyük korkusu, kodlama hakkında fazla bir şey bilmeyen birini işe almaktır. Sahteleri ayıklamak için iş tecrübesinden başka bir şey hakkında konuşmalısınız.


1

Bu sorular programlayamayan insanları taramak içindir. Bazen program yapamayan ancak çok fazla önemsiz şey bilen insanlar geliştirme işleri için başvururlar ve yararlı ve önemsiz bir şey yazmalarını sağlamak bir röportaj için çok zaman alır.


1

Bu becerilerin derleyiciler, sürücüler yazmanız ve işletim sistemi çekirdeği üzerinde çalışmanız gereken işlerde kullanılabileceğini görebiliyorum. Bunların dışında, bu beceriler başka nerede kullanılır?

Arama motorları, web sunucuları, web tarayıcıları, kelime işlemciler, tablolar, görüntü editörleri, çizim programları, veritabanı sunucuları, biyoinformatik, ticaret programları, oyunlar, fizik simülatörleri vb. Yazmaya ne dersiniz?

Yazılım işlerinin çoğunun bir veritabanından veri çekmesini, bir ekrana koymasını, düzenlemesini, ekrandan kazınmasını ve bir veritabanına geri koymayı içerdiğini size söyleyeceğim. Ancak, o zaman bile, sonunda bir platformun yerleşik özellikleri tarafından kısıtlamaların karşılanamayacağı bir uygulama ile karşılaşabilirsiniz. Bu noktada, vazgeçebilir veya algoritmalar ve veri yapıları araç kutunuza ulaşabilir ve sorunu çözmede bir çekim yapabilirsiniz.


0

Teorik nesneler kolaylık sağlamak için kullanılır, çünkü ortalama bir ağaç / grafik / liste uygulamasının ne olduğunu bilmeniz gerekir, böylece rastgele bir çaprazlama probleminin nasıl çözüleceğini bilirsiniz, ancak bu sorular teorik nesnelerle ilgili değildir.

Soyutlanmış bir modelle çalışabilmek, soyut bir problemi anlamak ve her türlü algoritma ile çözmekle ilgilidir. Bu orada saf bir geliştirme becerisidir, bu yüzden önemlidir. Bu yüzden bu soru mantıklıdır, doğru gerçek yaşam durumları olması gerektiği için değil.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.