İlkbaharda işe alım tamamlandı! Kıdemli bir teknik mülakatçı size bir Java mülakatına nasıl hazırlanacağınızı öğretir! | CSDN blog seçimi
Yazar | hsm_computer
Sorumlu Editör | Wu Xingling
Üretildi | CSDN Blogu
Java yeteneği ve mülakat yeteneği, becerilerin iki yönüdür Hazırlanmazsanız bazı büyük tanrıların mülakatı geçebileceği, ancak yetenek ve maaşın hafife alınabileceği söylenebilir. Nedenlerini dikkatlice analiz edin Mülakatta sorulan soruların kapsamı iş tanımında verilmiş olsa da, her nokta için görüşmecinin soruları rastgele düşünülür ve hatta iki benzer görüşmede aynı görüşmeci Soru aynı olmayabilir.
Başka bir deyişle, görüşmecinin özgürce soru sormasına izin verilirse, size aşina olmadığınız bir şey sorulduğunda cevap veremeyebilirsiniz.Eğer şanssızsanız, ayrıca görüşme rehberlik becerilerini ve diğer faktörleri bilmiyorsanız, görüşmecinin soru sorması gerçekten mümkündür. Tanıdık olmayan aralığınıza girmesi üzücü. Bunun yerine, önceden bir mülakat rehberi hazırlamak daha iyidir, böylece yeteneğiniz gerekli olmayabilir, ancak önemli noktalarınızı kılavuz aracılığıyla olabildiğince gösterebilir, böylece röportajı geçme olasılığını artırabilirsiniz. Bu makalede, Java vurgularını önceden hazırlama ve görüşmeciyi görüşme sırasında soru sorma konusunda rehberlik etme tekniklerini anlatacağım.
Bir mülakat fırsatı olup olmadığı ile ilgili olan iş tanımına göre özgeçmişinizi ince ayarlayın.
Bu noktanın bu makalenin konusu ile hiçbir ilgisi olmasa da mülakat fırsatı yoksa rehberlik becerilerini bile gösteremeyecektir, hadi konuşalım. Özgeçmişi görüntüleyen kişi, sadece akademik yeterlilikler gibi zor koşullara değil, aynı zamanda ilgili deneyime sahip iş projesi deneyimine de bakacaktır, bu da iş başlangıcına kesinlikle yansıyacaktır, birincil gelişim gibi, genellikle SSM ve diğer çerçevelerde 1 yıllık deneyim gerektirir, ileri Geliştirme genellikle 3 yıl sürer ve ardından Netty, veritabanı ayarlama gibi bazı beceriler vb.
İlgili iş projelerinde belirgin bir deneyime sahip olmayan (öğrenme projelerini saymayan) bir özgeçmiş görürseniz, o zaman bu özgeçmişin bir görüşme fırsatı bile yoktur, bu yüzden birçok genç gelişim özgeçmişi çoğunlukla dikkate değer değildir. Aslında, iş tanımında bahsedilen beceriler için, birçok genç geliştiricinin bile proje deneyimine sahip olması gerekir, ancak bu insanlar açıkça yazmazlar, bu sadece kendilerine atılabilir. Bu parçada verilen deneyim aşağıdaki gibidir.
1. Özgeçmişinizde daha fazla ticari proje deneyimi biriktirin ve içinde kullanılan teknoloji olabildiğince Java olmalıdır.Yarım yıllık ticari proje deneyimi telafi edebiliyorsanız, o zaman asla 5 ay yazmayın. Mezunların ticari proje deneyimi yoksa, özgeçmişlerine yazacakları bazı öğrenme projeleri bulmaları gerekir.Öğretmenlere ve stajlara yardımcı olacak projeler ise ticari proje olarak yazılmalıdır.
2. Genel iş tanımlarında, çoğu SSM, Oracle ve diğer teknolojilerden bahsediyor.Bu teknolojiler en azından projenizdeki diğer benzer teknolojilerde kullanılmalıdır, bu yüzden hoş geldiniz. Bu teknik anahtar kelimeler, özgeçmişinizdeki proje girişinde olabildiğince çok görünür. Örneğin, birisi Oracle deneyimine sahipse, MySQL'iniz olsa bile yazın, yazmazsanız veritabanı geliştirme deneyiminiz olmadığı anlamına gelir.İlgili deneyiminiz olsa bile benzer teknik noktalar için aynısını yapmalısınız.
3. Her işin teknik gereksinimleri farklı olmalıdır, bu nedenle özgeçmişinizi göndermeden önce ince ayar yapmalısınız.Projenizde yaptığınız öncülde, ilgili teknolojiyi mümkün olduğunca özgeçmişinize yansıtmaya çalışın.
4. Genel olarak konuşursak, Java'da (veya SSM ve diğer çerçevelerde) ticari projelerde en az yarım yıllık deneyiminiz yoksa ve özgeçmişinizdeki iş tanımında veritabanı, çerçeve ve diğer beceri anahtar kelimelerini göremiyorsanız, bu özgeçmiş temeldir Şans yok, ileri geliştirme genellikle 3 yıllık ilgili deneyim gerektirir.
5. Proje düzenleme burada savunulmamaktadır, düzenleme teknolojisini savunmamaktadır, yani projenizde kullanılmayan teknoloji için özgeçmişinize yazıyorsunuz ama sonra yine genel firmanın ihtiyaç duyduğu teknoloji, projede yapmamış olsanız bile çok sıradan. Her neyse, birisi bunu daha önce yaptı, ilgili koda bakabilirsiniz ya da bu tür sorunların ayıklanmasına katıldınız.
Yani genç gelişim için bile, Becerileriniz çoğu pozisyon için uygun olmalıdır , Okula gitmezseniz, bunu kısa sürede yapabilirsiniz. Özgeçmişinizde yeterince Java iş projesi deneyiminiz olduğu ve çoğu teknik anahtar kelime göründüğü sürece, en azından bir görüşme fırsatınız olabilir.
Projeleri ve çevrimiçi sorunları birleştirerek, dağıtılmış bileşenlerin önemli noktalarının hazırlanmasına öncelik verin
Röportajlar genellikle projenin tanıtımı ile başlar.Mülakatta kendi proje deneyimimi nasıl tanıtacağımla ilgili blog yazımda konuyla ilgili içerik verilir.Ancak bu makalenin konusu, hazır mülakata hazırlanırken size yol göstermektir, öyleyse mülakattan önce ne yapmalıyım Vurgulamaya hazır mısınız? En değerli dağıtılmış bileşen vurgularının hazırlanmasına başlayın.
Örneğin, günlüğe bakarak Redis, Dubbo, vb .'deki çevrimiçi sorunları çözebilirsiniz. Bu alan aslında genç geliştirmeyle bağlantı kurma şansına sahip.Örneğin, Dubbo'da zaman aşımı süresi ayarlanmadı.Örneğin, 10 saniyeye ayarlandı.Genellikle iyi, ancak sipariş modülü risk kontrol modülünü bir hata yapacak şekilde ayarladığında, 10 saniye sonra hataya geri döner. Bir bağlantı (Http'ye dayalı) uzun süre korunur ve birikme kaynakların tükenmesine ve sonunda bir sistem çökmesine neden olur veya Redis zaman aşımı süresi uzun bir süre (1 hafta) ayarlanamaz veya ayarlanamaz, bu da bellekte çok fazla Redis içeriğinin önbelleğe alınmasına neden olur. OOM sorunlarına neden olur. Bu konular, bir ön gelişme olsa bile, temas kurma imkanına sahip olmalıdır.
Buna nasıl hazırlanılır?
1. Özgeçmişinize projenizde Redis veya Dubbo bileşenlerini kullandığınızı ve benzer sorunları kontrol ettiğinizi yazın.
2. Bazı temel Redis ve Dubbo arayüz yöntemlerine bakın.
3. Özellikle, zaman aşımı süresinin nasıl ayarlanacağı gibi sorunlara neden olabilecek yapılandırmaya bakın.
4. Linux komutlarını inceleyin ve günlüklere bakmak ve sorunları gidermek için Linux komutlarını nasıl kullanacağınızı öğrenin.
Yukarıdakiler en temel olanıdır.Mycat, Netty ve Kafka konusunda Mycat alt veritabanı alanlarının nasıl ayarlanacağı, Netty yarı paket ve yapışkan paket problemlerinin nasıl çözüleceği gibi deneyimleriniz varsa, Kakfa mesajın yeniden iletiminin neden olduğu idempotent olmayan sorunu çözmüştür. Özgeçmişinize vurgu olarak yazabilirsiniz. Ancak, zaman aşımlarından kaynaklanan Redis ve Dubbo sorunlarının giderilmesi gibi bu makalede verilen sermaye koruma becerilerinin önemli noktaları herkesin kullanımına açık olmalıdır.
Sorulara geri dönmeyin, çözdüğünüz projeler veya çevrimiçi sorunlar hakkında konuşmayın
İnternette Netty veya Dubbo'nun düşük seviyeli ayrıntıları gibi birçok dağıtılmış (ve diğer yönleri) mülakat soruları vardır Bunlar yararlıdır, ancak bunlara aşinaysanız, röportajdaki en yaygın değerlendirme, hiç yoktan iyidir "dağıtılmış bileşen teorisini anlamaktır". Dağıtılmış bileşenlerle ilgili deneyiminiz olması gerekiyorsa, takılıyorsunuz. Dağıtılmış bileşenler için, uygulamaya nasıl hazırlanmalısınız? (Aslında, daha sonra bahsedilen önemli noktalar da aynıdır)
1. Projede uygulanmalıdır, çünkü görüşmeci yalnızca ilgili ticari proje deneyimine önem verir.Örneğin, Dubbo'nuz üyelik sistemini ayarlamak için sipariş sisteminde kullanılır ve MyCat, Netty vb. Hangi senaryolarda kullanılır, bu özgeçmiş Yukarıdakilere yansıtılmayabilir, ancak bunu kullandığınızı kanıtlayabilmesi için görüşme sırasında söylemelisiniz.
2. Sorunları analiz etme yeteneği, geliştirme yeteneğinden daha iyidir, bu nedenle bir senaryo açıklamasını birleştirmeniz daha iyi olur, örneğin projeyi tanıttığınızda, bir cümle alırsınız, Dubbo, zaman aşımının neden olduğu sorunu çözdüm ve sonra görüşmecinin sormasını bekleyin , Sorduğunuzda, kabaca bir fikir verebilirsiniz ve sonra görüşmeci Linux günlüklerini görüntüleme komutunuza, Dubbo'nun zaman aşımı süresi ve sorunun bağlamına bakacaktır.Bunda yanlış bir şey yoksa, inanmalısınız.
3. Şu anda, Netty yığın dışı bellek, iş parçacığı modeli ve Redis veri yapısı gibi ayrıntılara hazırlanmak için bazı görüşme sorularını birleştirebilirsiniz. Bazı görüşmeciler sorunu çözmek için bir şey söylediğinizi duyduktan sonra sormayabilir ve bazıları daha düşük düzeyde sorular sorabilir, böylece şimdi konuşabilirsiniz.
4. Burada aşağıdaki iki ifade yöntemini karşılaştırabilirsiniz: Birincisi hiçbir şey hazırlamamak ya da sadece internette soruları ezberlemeye hazırlanmak. Mülakatı yapan kişinin sormasını bekleyin, o zaman mülakatı yapan kişi kaba olmalı, nerede düşünürseniz sorun Örneğin, Netty çok dikkatli bir şekilde soracaktır.Genel proje deneyiminiz kapsanmayabilir.Uygulama ile bunu netleştiremezseniz, görüşmeci yalnızca teorik deneyime sahip olduğunuzu düşünebilir.
Diğeri, proje tanıtımı sırasında bir kenara atmak ve çözülen gerçek sorunları gözden geçirmek için fırsatlar bulmak ve ayrıntıları biraz anlamak, böylece görüşmeyi yapan kişinin gerçek proje deneyimine sahip olduğunuzu hissetmesi kolay olmakla kalmaz, aynı zamanda "günlüğü gör Pratik problemleri çözme yeteneği. İkisi arasındaki fark bir bakışta görülebilir, yöntem elde edildiği sürece hazırlığın aslında zor olmadığından bahsetmiyorum bile.
Veritabanı ayarı, sanal makine ayarı ve OOM sorunlarını giderme hakkında konuşmak
Değerli becerilere göre sıralanmıştır. Genel birincil ve gelişmiş geliştirme için, dağıtılmış bileşenlere ek olarak, aşağıdakiler ayarlama yetenekleridir. Özellikle, dağıtılmış ayarlamalar yapılabilir. Daha önce belirtildiği gibi, veritabanı ayarlama ve sanal Makine ayarı. Özgeçmişinize net bir şekilde yazmanın yanı sıra, başka hangi hazırlıkları yapmalısınız?
Veritabanı ayarı:
1. İndeks yapısı, bileşik indeks ve arka tablo dahil indekse aşina olan bu, proje vakalarıyla birlikte herkes tarafından söylenmelidir.
2. Bağımsız sürüm için, yürütme planına bakarak ve SQL deyimini ayarlayarak bu parça nasıl hazırlanır? Projede, Linux'ta ayarlanacaktır. 10 saniyeden fazla SQL varsa, onu yazdırın ve zaman alıcı noktayı görmek için yürütme planını kullanın.Örneğin, çoğu tam tablo taramalarıdır veya dizinler kullanılmaz veya alt SQL çalışır. Çoğu zaman, daha da ileri gitmek Oracle'daki bağlantı yönteminin yanlış olmasıdır. Sorunu yürütme planı aracılığıyla gördükten sonra, bir bileşik dizin oluşturmak veya alt sorguyu with ifadesi aracılığıyla çıkarmak gibi uygun şekilde değiştirebilirsiniz.
Kısacası, burada uzun SQL'i günlük aracılığıyla ve zaman alıcı noktayı yürütme planı aracılığıyla yansıtmanız gerekir. Nasıl değiştirileceğine gelince, çoğu aday söyleyebilir, ancak ilk iki noktayı biliyorsanız, diğerlerinden daha iyisiniz.
3. Hala yetenekli olduğunuzu düşünüyorsanız, MyCAT alt veritabanı, alt tablo ve Redis'in ayarlama yetenekleri hakkında konuşabilirsiniz, sonuçta bu dağıtılmış bileşenleri içerir. Bu bağlamda hazırlanabilecek proje bildirimi şöyledir: Örneğin iş taleplerinde, şirket kimliği genellikle risk kontrol modülünde risk durumunu görüntülemek için kullanılır, daha sonra ID anahtar olarak, risk kontrol alanı değer olarak kullanılabilir ve ardından anahtar olarak kullanılabilir. Önbellek dökümü.
Buna ek olarak, on milyonlarca seviyeden oluşan büyük bir tablo için kimliği alt tablo alanı olarak kullanabilir, 10 tabloyu bölebilir ve son basamağın değerine göre belirli tabloları bulabilirsiniz. Aynı zamanda, tüm SQL ifadelerini kontrol edin ve gruplama ve çoklu tablo ilişkilendirme gibi tüm tablolarla ilişkili olabilecek bazı SQL ifadelerini ilişkilendirin veya Java işinde yazın veya optimize edin. Aynı zamanda, MyCAT ve Redis ile ilgili bazı gramer retorikleri hazırlamak için çevrimiçi bazı mülakat sorularını okuyun. Bu şekilde "dağıtılmış performans ayarı" konusunda ek deneyime sahip olacaksınız.
Sanal makineler açısından, "Görüşmelerde Sanal Makine ve Bellek Ayarlama Becerileri Nasıl Gösterilir" başlıklı bir blog yazım var. Buna göre hazırlayabilirsiniz.Kısacası, önce proje ile başlayın, sonra sanal makine yapısı etrafında ayarlama becerilerini genişletin. Bu makaleye göre, iç sınıflar, final ve çöp toplama, görüşmeci görüşme sırasında bunun hakkında ne zaman konuştuğunuzu bilecek ve yeteneğinizi daha da gösterecek ve aynı zamanda aşağıdaki örneğe göre neyi çözdüğünüzü de anlatabileceksiniz. OOM sorunu:
İlk adım, sistemin takılı kaldığını veya OOM istisnalarının sık sık günlükte göründüğünü bulmaktır.
İkinci adım, OOM'un bellek ikizlemesini görmek için döküm dosyasını kullanmaktır Araç JMAT olabilir. Bu iki adım yaygındır.
Üçüncü adımda, döküm dosyası aracılığıyla, günlük bağlamıyla birlikte OOM'un nedenini buldum. Daha basit neden, Redis önbellek zaman aşımının çok uzun olması veya ThreadLocal'daki nesnenin kaldırılmadan iyi kullanılmasıdır (bu parça aynı zamanda zayıf referansları da içerir, Kendiniz kontrol edebilirsiniz, bu makale genişletilmeyecektir) veya iş parçacığı havuzu oluşturulduğunda, bekleme kuyruğu sınırsız olarak ayarlanır.
Ya da koşulların tümünün if ile olduğu Mybatis'teyseniz, yani, id ve name olarak geçerseniz ve sonra bir senaryoda, hiçbir koşul geçilmez, yani nerede sonra koşul yoktur. Veritabanındaki tüm kayıtlar alındı ve OOM'ye yol açtı.
Netty yığın dışı belleğin zayıf yönetiminin neden olduğu sorunlardan bahsedebilirseniz, bu düzeyde konuşabilirseniz, bir mimarla röportaj bile yapabilirsiniz.
Dördüncü adım, çözmektir. Sorunu keşfettikten sonra, Redis zaman aşımı süresini azaltmak veya karşılık gelen kodu değiştirmek gibi doğru çözümü belirlemek kolaydır. Ancak bunun çevrimiçi problem sınıflandırmasına dayandığını söylediğiniz için, nasıl çözeceğinizi ve iyi bir şekilde bitireceğinizi söylemelisiniz.
Kısacası, bu çevrimiçi problemlerle bağlantılı olarak bulunur, bu nedenle bağlantı nesnesinin kapalı olmaması, büyük HashMap'in net olmaması, bu nedenlerin OOM sorunlarına neden olmayacağı gibi sorunlardan bahsetmeyin, ancak bu sorunların çoğu Bunları lansman öncesi test aşamasında çözerseniz, bunları çevrimiçi sorunlar olarak tanımlarsanız, proje ekibinizin becerisini açığa çıkarabilir.
Java'nın temel özellikleri: Koleksiyon, ileti dizisi ve istisna işlemeyi hazırlamanın önemli noktaları
Yukarıda belirtilen dağıtım bileşenleri ve ayarlama özellikleri sayesinde, gösterme yeteneğiniz diğerlerinden çok daha güçlüdür.Karşılaştırıldığında, Java'nın temel yönleri bağımsız sürümün becerileridir, ancak sonuçta bunlar, temel problemler dışında temel becerilere aittir. Ek olarak, parlak noktalar da uygun şekilde hazırlanmalıdır. İşte birincil geliştirme için de geçerli olan bazı önemli noktalar.
1, Ayarlamak Bir yandan, HashMap ve HashCode'un düşük seviyeli kodunun yanı sıra düşük seviyeli ArrayList kodunu hazırlayabilir ve hızlı başarısız olabilir ve ardından ConcurrentHashMap'in okuma ve yazma eşzamanlılık yönetimi bölümünün koduna daha yakından bakabilirsiniz, çünkü uçucu, hash tablosu içerir. Veri yapısı ve iş parçacığı eşzamanlılığı becerileri.
Ve JDK1.7 ve 1.8 ConcurrentHashMap'in temel kodunun uygulanması farklıdır.Bu nesne aracılığıyla, belki de Java'nın temel yönü olan çoklu okuma ve veri yapısının yeteneğini gösterme fırsatı bulursanız, görüşmeci başka sorular sormayacaktır.
2, Konu Bir yandan, kilit, uçucu, iş parçacığı havuzu ve ThreadLocal hakkında konuşmaya hazırlanın ve ConcurrentHashMap aracılığıyla kilit (1.7) sürümü ve senkronize + uçucu (sürüm 1.8) kullanımının yanı sıra ThreadLocal'da bellek sızıntısı sorunu hakkında bilgi edinin. Bunların tümü çevrimiçi Evet, bu makale genişletilmeyecek hatta çok fazla olmayabilir, sadece açıklığa kavuşturun.
3. İstisnalar açısından, projenizdeki istisna işleme yöntemlerini uygulamaya hazırlanın.Örneğin, try ... catch'in kapsamını daraltmaya çalışın, kaynakları serbest bırakmak için kodu final cümlesine koyun, istisnaları olabildiğince fazla işleyin ve önce IOException'ı kullanın. İstisna işleme ve ardından istisnanın kapsamını mümkün olduğunca azaltmak için İstisna'yı kullanın ve bir istisna ile karşılaştığında programın hemen çökmesine izin vermeyin.
Java çekirdeği açısından, aslında String, son anahtar kelimeler vb. Gibi keşfedilebilecek pek çok nokta var ve Java çekirdeğinde çok fazla çevrimiçi görüşme sorusu var, bu yüzden burada genişletmeyeceğim.
Proje durumu da burada birleştirilmelidir.Örneğin, test aşamasında koleksiyonun geçişinden kaynaklanan sorunlar bulundu ve aynı zamanda hızlı arıza oluştu veya stres testi aşamasında, HashMap yüksek eşzamanlılık senaryolarında veri kaybettiği için ConcurrentHashMap kullanıldı ve aynı anda değişken içerik görüntülendi. Ve eşzamanlılık ve diğer ayrıntılar.
Aslında, yukarıdaki beceriler karmaşık değildir ve temel gelişim hala söylenebilir, ancak temelde yatan kodu içerir, özellikle ThreadLocal aynı zamanda zayıf referansları ve OOM sorunlarını da içerir, bu da gücünüzü daha iyi yansıtabilir, diğerlerinden daha fazla deneyime sahip olmasanız bile, ancak görüşmede altta yatan kodu birleştirebilirsiniz. Gösterin, bunu düşünmeden bile, görüşmeci sizin hakkınızda iyimser olmalıdır.
Projeyi tanıtırken, hazırlanmış olan önemli noktaları atın, genişletmeyin
Yukarıdakiler mülakata hazırlık becerileridir, değer perspektifinden analiz edilir ve dağıtılmış bileşenler, veritabanı ve JVM ayarlama ve Java temel becerileri hakkında konuşulur.Daha da önemlisi, gerçek proje için hazırlanıyorsunuz.
Sahnede bir dakika ve sahnede bir yıl kapalı, iyi hazırlanırsanız röportajda oynayabilirsiniz. İlk olarak, kendi kendini tanıtma bölümünde, okul derecesi ile ilgili temel bilgileri tanıtmanın yanı sıra, Redis bileşenlerini kullanma, veritabanı ve JVM ayarlama deneyimine sahip olma, stres testinde deneyim sahibi olma (aşağıda açıklanmıştır) ve OOM'de sorun giderme gibi kapsamlı bir açıklama da verebilirsiniz. Kısacası sorunlar vb. Deneyim, kibar olmayın, sadece hazır olduğunuzda söyleyin.
Ardından proje tanıtım bağlantısına girin.Proje arka planını ve geliştirme durumunu tanıtmanın yanı sıra, iş görüşmelerini de birleştirebilirsiniz.İşte bazı retorik örnekleri.
1. Bu projede Dubbo'yu modüller arası çağrı olarak kullandık.Kod yazmanın yanı sıra Dubbo zaman aşımından kaynaklanan sorunu da çözdüm (genişletmeyin)
2. Veri tabanı açısından, uygulama becerilerine ek olarak, veri tabanı ayarlaması yaptım, özellikle indeksler, yürütme planı, Redis önbelleği ve MyCAT alt veri tabanı ve alt tablosu kullandım.Son iki nokta benim düşüncem.
3. Projede, uygun olmayan ThreadLocal ve iş parçacığı havuzu ayarlarının neden olduğu OOM sorununu da çözdüğüm ThreadLocal nesnesini kullanan (ThreadLocal'a yönlendirecek iş ile birlikte) her isteği işlemek için bir iş parçacığı kullanacağız. Aynı zamanda, hazırladığım diğer OOM sorularını da atabilirim.
4. Bu projede stres testine katıldım ve stres testi sürecinde OOM problemlerini çözdüm ve loglara bakarak kodu optimize ederek sistemin yanıt süresini iyileştirdim.
5. Bu projede Cat sistemi ile uzun SQL problemini izleyeceğim, oluştuğunda problemi Linux günlüğüne bakarak kontrol edeceğim. (Sorunları gidermek için günlüğe bakma becerisini gösterin ve hazırladığınız becerileri daha fazla gösterin).
Gördüğünüz gibi, yukarıdaki birleştirilmiş proje tarafından atılan vurgular, proje tanıtım aşamasına ait oldukları için genişletilmedi.Eğer genişletilmişlerse, görüşmeci sizin net olmadığınızı ve vurguların tümünün dağıtıldığını ve ayarlandığını hissedebilir. Mükemmel ileri beceriler. Java'nın bağımsız becerilerinin bazı temel yönleri için, diğerleri hazine olarak kabul edilebilir ve hiçbir şey olmayan çok fazla değerli beceriye sahip olabilirsiniz. Elbette, daha sonra fırsatlar var, yine de Java'nın temel bölümlerinin önemli noktalarını göstermeniz gerekiyor, ancak daha değerli olanlara öncelik vermelisiniz.
Teknik soruları cevapladıktan sonra hazırladığınız önemli noktalara yönlendirebilirsiniz.
Projeyi tanıttığınızda, yeterince vurgu atıldığından, görüşmeci doğal olarak bu konuda sorular soracak ve böylece yol gösterici etkiye ulaşacaktır. Örneğin, Redis önbelleğe alma hakkında konuşurken, doğal olarak şunu soracaksınız: Asıl soru nasıl kullanılacağı? Bu, projenizin gerçek gerçekleriyle birleştirilebilir, altta yatan ayrıntılar, bu çevrimiçi bilgi parçası çok fazla. Diğer bir deyişle, proje tanıtımı yoluyla, görüşmeciyi hazırladığınız konuya yönlendirebilirsiniz, durum böyle değildir.Soruları cevaplarken, yine de rehberlik edebilirsiniz.İşte bazı yol gösterici beceriler.
1. Örneğin, Redis ile ilgili soruları yanıtlarken, daha önce "çok uzun zaman aşımının neden olduğu OOM sorunlarını kontrol etme" hakkında konuşma fırsatınız olmadıysa, Redis için xx problemlerini çözdüğümü ve görüşmecinin doğal olarak olacağını söylemeye başlayabilirsiniz. Soracak ve sonra başlayacak.
2. Redis sorusunu cevapladıktan sonra sorunsuz bir şekilde bir şeyler söyleyebilirsiniz Projemizde Redis'e ek olarak Dubbo bileşenleri de kullanılmıştır.Bunun sonucunda aşırı uzun Dubbo zaman aşımından kaynaklanan sorunlar yaşanmıştır. Daha sonra görüşmeci doğal olarak bunu soracaktır.Ayrıca Dubbo'nun altında yatan detaylar hakkında bazı sorular da hazırlayabilirsiniz.Bu alanda ayrıca birçok bilgi vardır.
3. Bu arada, indeksler, JDBC, vb. Gibi veritabanı ile ilgili soruları cevapladıktan sonra, projedeki yürütme planı (veya Mycat) aracılığıyla SQL becerilerini optimize ettim ve sonra onu açtım.
4. Herhangi bir koleksiyon (ArrayList gibi) ile ilgili soruları yanıtlarken, koleksiyonda gezinirken projemizin hızlı başarısızlık sorununa çok dikkat edeceğini ve daha sonra genişleyeceğini söyleyebilirsiniz.
5. Herhangi bir iş parçacığı bellek modelini yanıtladıktan sonra ya da uçucu hakkında sorulduğunda, sadece ConcurrentHashMap'te uçucu kullanıldığını biliyorum diyorsunuz, detaylandırabilir miyim? Bu nesne ile birleştirildiğinde, iş parçacığı eşzamanlılığı konusuna genişletilir ve bu yine de temeldeki kodla birleştirilir.
6. Çalışma zamanı istisnaları, istisnaların nasıl özelleştirileceği gibi istisna işleme sorunları sorulduğunda, istisna işleme en iyi uygulamalarına kılavuzluk edin.
7. ThreadLocal'dan, altta yatan Zayıf alıntı konusuna gidin ve ardından JVM yapısı ve OOM ayarı konusuna gidin.
Buraya yazmaya bile zahmet etmiyorum. Yukarıda birçok önemli noktayı listeledim. Bunlar yatay olarak birbirleriyle ilişkilidir. Birinin diğeriyle ilişkili olduğunu kabul ederseniz, becerilerinizi tüm yönleriyle göstermeniz yeterlidir.
Ama genişlerken dikkat etmeniz gerekiyor, Mülakatı yapan kişinin soruyu cevaplamaması durumunda derhal durmalı veya size rehberlik edecek başka bir fırsat bulmalısınız, bu sırada konuşmaya devam ederseniz, kendinizden bahsediyorsunuz. Ve herhangi bir iz bırakmadan rehberlik etmeye çalışın.Örneğin, yukarıdaki örnekte, rehber kelimelerin çoğu, xx teknolojisine ek olarak, projemiz de xx (çok alakalı) teknolojisini kullanıyor ve sonra görüşmecinin sormasını bekleyin.
Başka bir deyişle, kendini düşünmeyen bazı görüşmecilerle karşılaştığınızda, kullanıma hazır görüşme rehberliğine hazırlanarak tüm görüşmenin hızını bile kontrol edebilirsiniz.Büyük fabrikalardan bazı görüşmecilerle tanışsanız bile, soruları ona göre yönlendirebilirsiniz. Kapsama aşina iseniz, en fazla çevrimiçi mülakat sorularını temel alan bazı ayrıntılı sorular (Dubbo, iplik modeli vb.) Hazırlamalısınız. Sonuçta, insanların düşünme stilleri birbirine çok benziyor. "Kayıtsız" dediğinizi duyarsanız, muhtemelen "Devam et" sordu.
Stres testi ve çevrimiçi sorun giderme deneyimi gibi değerli konular için kılavuz
Dağıtılmış pratik becerilerle karşılaştırıldığında, daha değerli olan, stres testi ve çevrimiçi sorunların giderilmesi ve proje başlatmalarındaki deneyimdir. Bu, bir veya iki cümle meselesi olan görüşmeler sırasında yönlendirmesi çok kolaydır. Örneğin, rasgele söylerseniz: Bu projede stres testi yaptım ve sistemi stres testi sonuçlarına göre ayarlama konusunda deneyimim var. "Başka bir deyişle, Dubbo ve diğer alanlarda çevrimiçi sorunları kontrol ettim. Doğal öncül, bunu daha önce yapmış olmanızdır.Mülakatı yapan kişi soru sorduğunda, stres testi açısından aşağıdaki açıklamaları verebilirsiniz.
1. Tam bağlantılı stres testine katılırsınız, yani ilgili sınıf arkadaşları birlikte oturur, istekleri göndermek için Jmeter'i kullanır, CPU bellek göstergelerini izlemek için zabbix'i kullanır ve günlük izleme sorunlarını izlersiniz.
2. Stres testi bir test ortamıdır.Tabii ki online bir ortam da diyebilirsiniz.Online bir ortam ise mutlaka izlenmelidir CPU yükü çok yüksek olduğunda hemen sonlandırılacaktır.
3. Örneğin, 500 iş parçacığı göndermek için Jmeter kullanıldığında, her iş parçacığı 5 işlem başlatır ve bu işlemler 2 saniyede tamamlanır, ardından saniyedeki basınç 1250 olur.
4. En önemli şey, basınç testi sonuçlarına göre performansı iyileştirmeniz gerekmesidir.Örneğin, basınç testi aracılığıyla iş parçacığı havuzu ayar parametrelerini bulduğunuzda, bekleme kuyruğunu sınırsız olarak ayarladığınızda veya kapalı olmayan modül GÇ nesneleri varsa veya ArrayList açık değilse, Bu, OOM'ye yol açtı veya uzun SQL'in yüksek eşzamanlılık senaryolarının veritabanında göründüğünü ve ardından bunu yürütme planıyla analiz edip çözdüğünü veya sistem günlüğünün orijinal olarak eşzamanlı olarak çıktığını, bu da bir performans darboğazına yol açtığını ve nihayet eşzamansız bir günlüğe dönüştüğünü buldu. Veya veritabanının darboğaz olduğunu bulun, bu yüzden MyCAT ve Redis'i tanıtıyorum.
Kısacası, Stres testi açısından, görüşmeci problemleri analiz etme ve çözme deneyiminize daha fazla önem verir. Keşfedilen ve çözülen problemlere gelince, gerekçelendirilebildiği sürece ve bunu dağıtım ve ayarlama becerilerinizi göstermek için de kullanabilirsiniz. Çevrimiçi sorunları giderme deneyimine gelince, bir açıklama yapmak için aşağıdaki adımları kullanabilirsiniz.
1. Nasıl öğrenilir? CAT izleme yoluyla uzun SQL'i keşfetmekten veya Kibana gibi araçlar aracılığıyla keşfetmekten başka bir şey değildir. Veya erken bir iş gömme noktası olduğu ve bir işlemin anormal olduğu tespit edildiğinde bir bildirim atıldığı söylenebilir.
2. Sorunu keşfettikten sonraki tavrınız Cep telefonunuz aracılığı ile sorunu keşfettikten sonra en kısa sürede göreceksiniz, kapsamınız dahilinde olmasa da en kısa sürede raporlayacaksınız.
3. Sorunlar nasıl giderilir: günlükleri görüntülemek için Linux komutlarını kullanın veya OOM görüntülerini görüntülemek için dökümü kullanın.
4. Yukarıda verilen önemli becerileri gösterebilmek ve uygun şekilde çözebilmek için nedenleri analiz edin.
Küçük bir geliştirici olsanız bile stres testine katılmaya hakkınız olduğunu ve her zaman çevrimiçi sorunlarla karşılaşacağınızı söylemiştim.Mülakat sırasında bunun hakkında konuşmazsanız, görüşmeci doğal olarak bilmeyecektir, ancak kesinlikle yapacak çok şeyiniz var.
Önce pratik fırsatları araştırın ve ardından becerileri geliştirin, programcılar daha gelişmiş pozisyonlara meydan okumalı
Özetle, bu makalenin temaları iki içerir, birincisi kendi gerçekliğinizi birleştirmek, röportajdan önce önemli noktaları ortaya çıkarmak ve ikinci görüşmede rehberlik yoluyla soruyu aşina olduğunuz alana yönlendirmeye çalışmak. Uygulamada teknoloji proje ile birleştirilmeli, kontrol edip çözdüğünüz çevrimiçi problemleri birleştirmek en iyisidir.Aynı zamanda bir soruyu cevapladıktan sonra problem benzer ve ince ayarlı konulara yönlendirilmelidir.
Örneğin Redis, projeler, stres testleri ve çevrimiçi sorularla birlikte temel kullanım ve çözülen problemler hakkında konuştuktan sonra, görüşmeci veri yapısı, yüksek kullanılabilirlik kümeleri ve işlemler hakkında sorular sorabilir, bu sorular önceden hazırlanabilir.
Temel geliştirme için lütfen retoriğin ilk bölümünü söyleyin Detaylar cevaplanmasa bile görüşmeci "Redis detaylarının derinlemesine anlaşılması" konusunda bir değerlendirme yapamasa da en azından "Redis'i projede kullandım ve Redis'i kontrol ettim" diyebilir. "İlgili sorular" değerlendirmesi, projeyi bu makalede gösterildiği gibi birleştirirseniz, ayarlama becerilerini, Java çekirdeğini ve diğer yönleri tam olarak gösterirseniz, o zaman kıdemli ve kıdemli gelişim ile görüşmeniz yeterlidir. Küçük gelişim için röportaj fazlasıyla yeterlidir. Daha fazla deneyime sahipseniz Daha zengin olmak ve ardından küçük bir şirketteki bir pozisyon için mülakat yapmak için kendimi daha da mağdur hissediyorum.
Bu makalede anlatıldığı gibi ilgili becerileri hazırladığınızda ve daha sonra bir yüz uzmanı olmak için bazı mülakat uygulamalarından geçtiğinizde, büyük olasılıkla hangi şirketle röportaj yapmak istediğiniz sorusuyla karşı karşıya değilsiniz, ancak "Görüşmeyi geçtikten sonra daha yüksek bir pozisyona uyum sağlayabilir misiniz? "Sorun.
Bununla birlikte, iyileştirmeden önce uygulama için her zaman fırsatlar vardır.Örneğin, genç bir geliştirici olduğunuzda, ilk gelişmiş geliştirme çalışmasına dahil olmak çok zor olmalı ve hatta kişinin yüzüne bakacaksınız, ancak daha gelişmiş pozisyonlar peşinde koşmazsanız, her zaman alt seviyeye düşeceksiniz. Kendinizi konumunuzun konfor bölgesinden ayıramazsanız, rekabet gücünüz aydan aya azalacaktır.
Dolayısıyla, gerektiğinde, bu makalede verilen önerilere dayanarak daha üst düzey pozisyonlara meydan okumaya devam etmelisiniz. Ayrıca, bu makalenin başında da belirtildiği gibi, teknik yetenek ve görüşme yeteneği iki boyuttur.Bu makalede verilen görüşme becerileri, olağan becerilerin birikimine dayanmaktadır.Bu makalede verilen görüşme önerileri görüşmede size daha iyi yardımcı olabilir. Vurguları göster.
Umarım bu makale sadece kendi proje deneyiminizi daha iyi keşfetmenize yardımcı olmaz, aynı zamanda en sevdiğiniz işi verimli bir şekilde bulmanıza da yardımcı olur.Son olarak, uzun makaleyi okuduğunuz için hepinize teşekkür ederim. Bu makale 5 saattir yazılmıştır.Eğer iyi hissediyorsanız, lütfen Çok beğenin ve herhangi bir sorunuz varsa daha fazla yorum yazın.
Yazar hakkında: Tanınmış bir yabancı şirketten kıdemli bir mimar, 8 yılda yüzlerce Java mühendisi ile röportaj yaptı ve Java eğitim öğretim görevlisi olarak 5 yıllık deneyime sahip, birçok yeni başlayan kişinin favori tekliflerini başarıyla almasına yardımcı oldu. "Java Core Technology and Interview Guide" yazarı. CSDN blog uzmanı.
Orijinal bağlantı: https://blog.csdn.net/sxeric/article/details/104278962
