Görüşmeden önce kuru gıda hazırlama
Geçen hafta, 3 ila 5 yıl arasında değişen iş deneyimleri ile Java back-end için birkaç aday ile yoğun bir şekilde görüştüm. Benim standardım karmaşık değil: birincisi çalışabilirim, ikincisi Java'da iyi bir temele sahip olmak daha iyidir ve üçüncüsü, bazı dağıtılmış çerçevelere aşina olmak daha iyidir. Diğer şirketler yeni geliştiricileri işe alırken bu standardı da takip etmeleri gerektiğine inanıyorum.
Ayrıca birçok adayın yetenek açısından kötü olmadığını biliyorum, ancak görüşme sırasında hazırlıklı değiller veya söyleyemiyorlar. Bu tür insanlar gerçekten takıma katıldıktan sonra beklentilerini karşılayabilirler, ancak görüşmeyi geçemeyebilirler, ancak görüşmeci her zaman Sadece görüşme durumuna göre yargıç.
Ancak gerçek şu ki çoğu insan görüşmeden önce hazırlanamayabilir veya hazırlık yöntemi uygun değildir. Biliyorsunuz, genellikle iş üzerine çalışıyoruz ve görüşmelerde sorulması gereken algoritmalar, veri yapıları ve altta yatan kodlarla çok fazla temas kurmak imkansız, yani görüşme hazırlık noktaları ve normal çalışma noktaları çok az eşleşiyor.
Bir görüşmeci olarak, görüşmenin sonucunu ancak adayların cevaplarına göre belirleyebilirim. Bununla birlikte, başkalarıyla birlikte olmanız sizin için uygundur, bu nedenle bu makalede, bazı ortak sorular aracılığıyla mülakata hazırlık becerilerini tanıtacağım. Okuduktan sonra herkes iç çekecek: yöntem doğru olduğu sürece, önce görüşmeye hazırlanmak zor değil, ikincisi çok fazla olmayacak.
1. Çerçeve odak noktasıdır, ancak insanlara yalnızca başkalarının kodunu kopyalayabileceğinizi hissettirmeyin
Görüşmeden önce, adayın çerçevedeki proje deneyimini kontrol etmek için özgeçmişi okuyacağım Adayın proje tanıtımı sırasında, adayın yakın zamandaki çerçeve deneyimine de odaklanacağım.En popüler olanı SSM.
Ancak, genellikle 5 yıl içinde çalışan adaylar çoğunlukla diğer kişilerin kodunu "kopyalayabilir", bu da mevcut çerçeveye dayalı yeni işlevsel modülleri genişletebilecekleri ve başkaları tarafından yazılan süreci takip edebilecekleri anlamına gelir. Örneğin, bir hisse senedi bekleyen emir için işlevsel bir modül yazmak istiyorsanız, mevcut sipariş sürecini taklit edecek ve ardından ön uçtan arka uca veri tabanına aynı şekilde yazacak ve en çok fonksiyonla ilgili kod noktalarını değiştireceksiniz.
Aslında hepimiz buraya böyle geldik ama röportajda sadece bu yeteneği gösterirseniz çoğu insanla aynı seviyede olacaksınız, bu noktada avantajınızı gösteremeyeceksiniz.
Yalnızca SSM çerçevesini kullanırsanız, çoğu projenin sorunlu noktaları olacağını biliyoruz. Örneğin, veritabanı performansı zayıf veya iş modülü daha karmaşık ve eşzamanlılık miktarı nispeten yüksek Spring MVC'deki Controller atlama ihtiyaçlarını karşılayamıyor. Bu yüzden genellikle şunu soruyorum: Mevcut çerçeveye göre iş kodu yazmanın yanı sıra, ne gibi değişiklikler yaptınız?
Duyduğum yanıt şu: Sabit verilere sık sık çağrı yapılmasını önlemek için Redis önbelleği eklendi. Veya MyBitas xml'de, koşulun boş olduğu select deyimi, yani değer varsa, nerede koşulu eklenir.Bunun için, ifadenin parametre olarak kullanılmasının engelleneceği herhangi bir yere isnull içermeyen bir sorgu koşulu eklenir. Boş olduğunda, tam bir tablo taraması gerçekleştirin. Ya da basitçe ifade etmek gerekirse, arka uçtan eşzamansız olarak döndürülen veri miktarı çok büyük ve uzun zaman alıyor Projede, eşzamansız dönüş için maksimum süreyi artırdım ya da ağ aktarım performansını artırmak için döndürülen bilgileri sıkıştırdım.
Bu soru için hangi cevabı duyduğum umrumda değil, sadece cevabın mantıklı olmaması umurumda. Genel olarak, cevap doğru olduğu sürece "Çerçeve seviyesinde kendi tecrübem ve belirli bir anlayışım var" vereceğim, aksi takdirde sadece "Çerçeve kodu sadece proje yöneticisinin önderliğinde yazılabilir ve çerçevenin kendisi hakkında fazla bir şey bilmiyorum. ".
Aslında bir röportaj için hazırlanırken çerçevedeki ana noktaları özetlemek zor değil, herkesin proje yaparken hiçbir şey biriktirmediğine inanmıyorum, anlattığınız sürece rekabetin yaklaşık% 70'ini bu konuda ezdiğinizi söyleyebilirsiniz. Tarafından.
2. Sadece çerçevenin bağımsız sürümüne bakmayın, biraz dağıtılmış
Ek olarak, projedeki çerçeve teknolojisini açıklarken, en iyisi biraz dağıtılmış teknoloji getirmenizdir. Aşağıda, hazırlayabileceğiniz bazı dağıtılmış teknolojileri listeliyorum.
1. Ters vekil sunucu açısından, lua dili aracılığıyla kuralların nasıl ayarlanacağı ve oturum yapışkanlığının nasıl ayarlanacağı gibi nginx'in temel yapılandırması. Yapabiliyorsanız, protokol, küme ayarları, yük devretme vb. Gibi temel nginx'e bakın.
2. Dubbo'yu uzaktan arama açısından, dubbo ve zookeeper entegrasyonunun bilgi noktalarına bakabilir ve ardından dubbo'nun temel iletim protokolünü ve serileştirme yöntemini anlamak için daha derin bir adım atabilirsiniz.
3. Mesaj kuyrukları açısından Kafka veya bileşenlerden herhangi birinin kullanımına bakabilirsiniz.Basitleştirmek için konfigürasyon ve çalışma grubu ayarlarına bakabilirsiniz.Daha derine inerseniz Kafka kümesine, kalıcılık yöntemine ve nasıl mesaj gönderileceğine bakabilirsiniz. Uzun bağlantılar veya kısa kesişimler kullanın.
Yukarıdakiler sadece 3 bileşenli bir örnektir.Ayrıca Redis önbelleğine, günlük çerçevesine, MyCAT alt veritabanına ve tabloya vb. Bakabilirsiniz. İki tür hazırlama yöntemi vardır: Birincisi, nasıl kullanılacağını bilmektir. Bu nispeten basittir. Konfigürasyon dosyası aracılığıyla işlevsel bir modüle yerleştirilebilir. İkincisi, protokolü ve kümeyi anlamak için bazı düşük seviyeli kodları uygun şekilde okumaktır. Yük devretme ve yük devretme gibi gelişmiş bilgi noktaları.
Bir röportajda dağıtılmış bileşenlerin alt katmanından bahsedebilirseniz, "çerçevenin alt katmanını anlama" veya "çerçevede deneyimlenmiş" gibi daha iyi değerlendirmeler alırsınız, böylece mimarla görüşmeye bile gidebilirsiniz. Gelişmiş geliştirmeden bahsetmeye bile gerek yok.
3. Veritabanına gelince, sadece eklemeler, silmeler, değişiklikler ve sorgular hakkında bilgi sahibi olmayın, performans optimizasyonunu da anlamanız gerekir
Gerçek projelerde, çoğu programcı yalnızca eklemeler, silmeler, değişiklikler ve kontroller kullanabilir.Bu durum Mybatis kullandığımızda daha yaygındır. Ancak görüşme sırasında bu şekilde davranırsanız, yeteneğinizin diğer rakiplerinkiyle hemen hemen aynı olduğu tahmin edilmektedir.
Bu bağlamda aşağıdaki becerileri hazırlayabilirsiniz.
1. SQL gelişmiş yönleri, gruplama, sahip olma, sol birleştirme, alt sorgu (içeride), satırdan sütuna ve diğer gelişmiş kullanımlar gibi.
2. Tablo oluşturma açısından, projenizin üç paradigma mı yoksa anti-paradigma mı kullandığını düşünebilirsiniz.Nedenler nelerdir?
3. Özellikle optimizasyon için, yürütme planı aracılığıyla SQL ifadelerinin iyileştirme noktalarını nasıl görüntüleyeceğinizi veya SQL performansını artırmanın diğer yollarını (dizin oluşturma vb.) Hazırlayabilirsiniz.
4. Yeterli hissediyorsanız, bazı MySQL kümesi, MyCAT alt veritabanı ve alt tablo becerilerini de hazırlayabilirsiniz. Örneğin, MySQL yük dengeleme, MyCAT yapılandırması elde etmek için LVS + Keepalived aracılığıyla. Benzer şekilde, eğer yapabiliyorsanız, ilgili temel koda da bakın.
İlk üç puandaki performansınız ortalama olsa bile, en azından ortalamaya yakın adayları geçebilirsiniz, özellikle SQL optimizasyonunda çok iyi performans gösteriyorsanız, o zaman gelişmiş geliştirme için görüşme yaparken, veritabanı seviyesinin standartlarda olması gerekir. Dört noktanın cevabı çok iyi, o zaman tebrikler, veri tabanındaki yeteneğiniz birincil mimari seviyesine bile ulaştı.
4. Java'nın merkezinde, veri yapısı ve performans optimizasyonu ile ilgili mülakat soruları hazırlayın
Java çekirdeği ile ilgili pek çok mülakat sorusu vardır, ancak buna ek olarak, koleksiyona (yani veri yapısı) ve çok iş parçacıklı eşzamanlılığa da odaklanmalısınız.Bu temelde, bazı tasarım kalıpları ve sanal makineler hazırlayabilirsiniz. Retorik.
İşte genellikle sorduğum sorulardan bazıları:
1. Dize a = "123"; Dize b = "123"; a == b'nin sonucu nedir? Bu, bellek ve Dize depolama gibi birçok bilgi noktasını içerir.
2. HashMap'teki hashcode ve eşit yöntemlerin ne zaman yeniden yazılması gerekir? Yeniden yazılmazsa sonuçları nelerdir? HashMap'in (hatta ConcurrentHashMap'in) temelindeki uygulaması hakkında daha fazla bilgi edinebilirsiniz.
3. ArrayList ve LinkedList'in temeldeki uygulaması arasındaki fark nedir? Hangi durumlar için uygundurlar? Ayrıca temel kod hakkında bilgi edinebilirsiniz.
4. Uçucu anahtar kelimenin işlevi nedir? Bundan herkes iş parçacığı belleği ile yığın bellek arasındaki farkı anlayabilir.
5. CompletableFuture, bu JDK1.8'deki yeni bir özelliktir, bunun aracılığıyla çok iş parçacıklı eşzamanlılık kontrolü nasıl gerçekleştirilebilir?
6. JVM'de yeni nesne hangi alandadır? Daha derine inin ve JVM sanal makine belleğinin nasıl görüntüleneceğini ve optimize edileceğini sorun.
7. Java'daki statik proxy ile dinamik proxy arasındaki fark nedir? Temeldeki kodu birleştirmek en iyisidir.
Yukarıdaki soru noktalarında, sadece "yararlı" seviyede kalmıyorum, örneğin, bir ArrayList'e elemanların nasıl yerleştirileceğini sormuyorum. Gördüğünüz gibi, yukarıdaki sorular "çok iş parçacıklı eşzamanlılık", "JVM optimizasyonu" ve "veri yapısı nesnelerinin düşük seviyeli kodu" gibi ayrıntıları içermektedir. Ayrıca, birbirinizden çıkarımlar yapabilir ve bazı ileri bilgilere bakarak daha benzer mülakat soruları hazırlayabilirsiniz.
Mevcut Java geliştirmesinin Web çerçevesine dayandığını biliyoruz, öyleyse neden Java'nın temel bilgilerini sormamız gerekiyor? İlk elden biliyorum.
Ekibimde daha önce iki kişiyle tanıştım, biri işte iyi, özel performans Java temel temel API'sini kullanmaktı ve derinlemesine anlamak için hiçbir istek yok (derinlemesine nasıl anlayacağımı bilmiyorum), diğeri Genellikle Java eşzamanlılığı ve sanal makine ile ilgili bazı ileri düzey bilgileri okurum. Yarım yıl sonra, ikincisinin yeteneği hızlı bir şekilde ileri gelişime yükseltildi JAVA'nın temel bilgilerinin tam olarak anlaşılması nedeniyle, bazı dağıtılmış bileşenlerin temelindeki uygulamada büyük bir sorun yoktur. İlki tekrarlayan işti ve yetenek sadece "çalışabilme" düzeyinde kaldı.
Gerçek bir röportajda, Java'nın temel bilgisine aşina değilseniz, mimar düzeyinde bir pozisyon için görüşmeyi bırakın, gelişmiş gelişime ilerlemenin zor olduğu tahmin edilmektedir.
5. Linux'ta, sorunları gidermek için en azından günlüğe nasıl bakılacağını bilin
Bir aday "sorunları çözme" ve "sorunları çözme" yeteneğine sahip olduğunu kanıtlayabilirse, bu kesinlikle bir bonus, ama nasıl kanıtlanır?
Şu anda çoğu İnternet projesi Linux üzerinde konuşlandırılmıştır, yani günlüklerin tümü Linux üzerindedir ve bazı gerçek Linux işlemleri aşağıda özetlenmiştir.
1. Dosyayı less komutuyla açabilir, Shift + G ile dosyanın altına ulaşabilir ve ardından? + Anahtar sözcüğü ile anahtara göre bilgi arayabilirsiniz.
2. Anahtar kelimeleri grep ile kontrol edebilirsiniz. Spesifik kullanım grep anahtar kelime dosya adıdır.Sonuçları iki kez aramak istiyorsanız, grep anahtar kelime 1 dosya adı | anahtar kelime 2 --renk'i kullanın. Son olarak --color, vurgulanan anahtar kelimedir.
3. vi ile dosyaları düzenleyebilir.
4. Dosya izinleri chmod aracılığıyla ayarlanabilir.
Elbette daha pratik Linux komutları var, ancak gerçek görüşme sürecinde birçok aday bir Linux komutunu bile bilmiyor. Yine de bu cümle, çok basit bir şey bilseniz bile, ortalama bir insandan daha iyisiniz.
6. Bonus öğe olarak düşük seviyeli bir kod parçasını okuyun
Bir bilgi noktasını iyi anladığımı nasıl kanıtlayabilirim? Temel kod aracılığıyla bunu açıklamanın daha iyi bir yolu yoktur. 5 yıl içinde çalışmış birçok programcı ile iletişim kurduğumda, birçok kişi bunun zor olduğunu mu düşünüyor? Aslında, temeldeki kodu okuyarak dağıtılmış bileşenleri anlamak istiyorsanız, küçük değildir, ancak aşağıdaki bölümdeki temel kodu anlamak zor değilse.
1. ArrayList ve LinkedList'in temel kodu, dizilere ve bağlantılı listelere dayalı uygulama yöntemlerini içerir.Eğer genişletmeyi, "numaralandırıcıdan geçişi" ve diğer yöntemleri açık bir şekilde açıklayabilirseniz, kendinizi kesinlikle kanıtlayabilirsiniz.
2. HashMap, doğrudan Hash tablosunun veri yapısına karşılık gelir.HashMap'in temel kodu, hashcode'un put ve get işlemlerini içerir ve hatta ConcurrentHashMap'te, Lock mantığını da içerir. Görüşme sırasında ConcurrentHashMap'e bakıp daha sonra bunu kağıt üzerinde konuşmak ve çizmekle birleştirirseniz, görüşmeciyi kesinlikle fethedeceğine inanıyorum.
3. Statik proxy ve dinamik proxy uygulamasına bakabilir ve Spring AOP'deki uygulama koduna daha yakından bakabilirsiniz.
4. Belki Spirng IOC ve MVC'nin temel uygulama kodunu anlamak zordur, ancak bazı anahtar sınıflar ve bunların anahtar sürece göre nasıl uygulanacağı hakkında konuşabilirsiniz.
Aslında, temel kodun hazırlanması gerekli değildir ve koleksiyondaki Kırmızı-siyah ağaç tabanlı TreeSet, NIO tabanlı açık kaynak çerçevesi ve hatta dağıtılmış bileşenlerin Dubbo'su gibi herhangi bir yönle sınırlı değildir. Ve bazı önemli sınıfları ve yöntemleri birleştirebildiğiniz ve fikirleri netleştirebildiğiniz sürece (örneğin, HashMap'in hashCode aracılığıyla hızlı bir şekilde nasıl bulunabileceğini açık bir şekilde açıklayın), hazırlanırken (aslında yapmak zordur) tüm temel katmanları ezberlemek gerekli değildir.
Öyleyse röportajda, hazırladığınız yukarıda belirtilen düşük seviyeli kodu anlatmak için nasıl iyi bir fırsat buluyorsunuz? Röportajda, her zaman koleksiyonlar, Spring MVC çerçevesi ve diğer ilgili bilgi noktaları hakkında sorular sorulacak. Bu arada, "Bu parçanın temelindeki uygulamayı hala biliyorum" diye yanıtladığınızda, görüşmeci kesinlikle soracaktır, sonra yapabilirsiniz Konuş.
Adaylara bu yardımı küçümsemeyin. Bunun hakkında konuştuktan sonra, anlamı yerinde olduğu sürece, en azından "proaktif ve profesyonel" bir değerlendirme alabilirsiniz. Açıklama netse, değerlendirme Java temel becerilerine aşina "(veya Spring MVC) ve temel beceriler sağlam ". Biliyorsunuz, röportajda çok az kişi altta yatan kodu net bir şekilde açıklayabilir, bu yüzden bu konuyu atarsınız, sonunda beklenen sonuçlara ulaşılmasa bile görüşmeci değerlendirmenizi düşürmez. Bu nedenle, bu parçayı hazırlamak para kazanmak için kesinlikle "karlı ama zararlı olmayan" bir iştir.
7. Her şey, yukarıdaki becerileri yaptığınız projelere dahil edin
Görüşme sürecinde sık sık bazı pişmanlık verici cevaplar duyarım.Örneğin, aday SQL optimizasyon becerileri hakkında çok iyi konuşur, ancak sonunda kendi kendine çalışma sırasında ustalaştığı şeyin bu olduğunu ve gerçek projelerde kullanılmadığını öğrendi.
Elbette bu hiç yoktan iyidir, bu yüzden "Barış zamanında kendime SQL optimizasyon becerilerini öğrettim" yazacağım, ancak bunu bir projede uyguladıysam, "Pratik veritabanı SQL optimizasyon becerilerine sahibim" yazacağım. İkisi arasındaki farkları karşılaştırabilirsiniz: Biri daha teorik, diğeri ise doğrudan bir şeyler yapabilir. Aslında birçok senaryoda, SQL optimizasyon becerilerinin gerçek projelerde uygulanmamış olması gerektiğine inanmıyorum.
Bu durumda herkese söylemek istediğim, daha önce hazırladığınız birçok beceri ve söylemin (aslında yöntem yönü elde edilmiştir ve çok fazla enerji gerektirmez) gerçek projenizde uygulanması gerektiğidir.
Örneğin, sorunları gidermek için Linux günlüğünde anahtar sözcükleri sorgulama deneyiminiz varsa, bunu açıklarken bir cümle getirebilirsiniz.Bunu önceki projede yaptım. Başka bir örnek olarak, temel koda bakarak, TreeSet ve HashSet arasındaki farkı ve bunların uygulama kapsamını anlıyorsunuz, daha sonra yaptığınız projeyi hatırlayabilirsiniz.Sadece TreeSet için geçerli bir senaryo var mı? Öyleyse, projenin ihtiyaçlarını uygun şekilde tanımlayabilir ve ardından temeldeki kodu okuyarak ikisi arasındaki farkı anladığımı ve bu gerçek talepte TreeSet'i kullandım ve ayrıca özel bir karşılaştırma yaptım diyebilirsiniz. Seks testi, TreeSet kullanmanın HashSet'ten% xx daha yüksek olduğunu buldu.
Lütfen "pratik deneyim" in "teorik deneyimden" daha değerli olması gerektiğini ve bildiğiniz teorik deneyimin çoğunun projenizde kullanılmış olması gerektiğini unutmayın. Öyleyse, görüşmeciye sadece "teorik deneyime" sahip olduğunuzu hissettirirseniz, bu utanç verici olur.
8. Özet: Bu makale, bir görüşmeye hazırlanmak için daha fazla yöntem açıklar
Bu makale çok fazla röportaj sorusu vermiyor, ancak bu makale çok fazla röportaj sorusu verme niyetinde değil. Bu makaleden, herkesin daha çok gördüğü şey, görüşmeciler tarafından keşfedilen birçok adayın acı noktalarıdır.
Bu makalenin amacı, herkesin başkalarının hatalarını tekrar etmesine son vermektir. Durum bu değil. Bu makale ayrıca röportajlara hazırlanmanın birçok yolunu da veriyor. Yetenekleriniz başkalarından üstün olabilir, ancak mülakata diğerleriyle aynı şekilde hazırlanırsanız veya projenizdeki önemli noktaları özetlemeden projedeki çalışmanızı örnek olarak kullanırsanız, mülakatçı gerçekten iyidir. Size aşağı bakacak.
Bu makalede bahsedilen yöntemler ve beceriler herkese yardımcı olabilirse, lütfen onları iletmeye yardım edin veya "bu makaleyi önermek" için aşağıdaki düğmeyi tıklayın veya yorumlar yoluyla tartışmaya katılın.
