首頁>Club>
面試很多都會問Linux、容器化技術(Docker、k8s),以及伺服器相關知識
2
回覆列表
  • 1 # OpenstackOne

    一、提問之前的準備

    首先,最重要的是,你自己一開始就應該想清楚:

      1. 需要新員工完成什麼樣的任務?

      2. 怎樣的人能完成這樣的任務?

      3. 哪些途徑和方法可以發現這樣的人?

    只有明確這些根本性的問題,才能正確高效地完成面試。

    二、提問的原則

    假定你對上一節的三個問題,已經有了清晰的想法,那麼接下來就可以設計如何提問了。

    有一些提問的原則,是你應該遵循的:

      * 每一個面試問題都有明確的目的。你不僅自己瞭解,還能向其他面試官解釋清楚。

      * 不要問宗教、家庭、健康、個人隱私等方面的問題。

      * 不要問太複雜的問題。因為面試者沒有太多思考時間,所以無法周全地回答,你也就無從判斷他的能力了。

    三、考察專業能力

    為了確認面試者是勝任的,你可以問一些與職位相關的專業方面的問題。(不過通常來說,一次面試不足以看出一個人的專業能力。)

    比如,你的招聘職位是系統管理員,你可以問"如何快速地在50臺機器上部署Linux?"(提示:正確答案不是燒錄50張安裝光碟。)

    另外,你還應該向面試者瞭解他的過去,因為過去是未來的最好預測依據。不過,提問的重點不要僅僅是他過去的成果,更要關注在當時的環境中,他是如何決策和實施的。

    四、考察綜合素質

    因為人是會發展的,所以某種程度上,面試者的綜合素質要比他的專業能力更重要。

    所以,具體的技術問題(如何呼叫API、什麼是設計模式、程式語言的語法等等)可以少問一些,更應該關注面試者的事業心、對工作的熱情、進取心、自律能力、毅力等方面。

    下面是一些典型問題:

      Why did you get into development?  你為什麼開發軟體?

      How many technical books did you read in the past year?  去年你讀了幾本技術書籍?

      What was your favorite technical book in the past year? What did you learn from it?  去年你最喜歡的技術書籍是哪本?你從中學到了什麼?

      What websites do you read regularly, related to development?  平時你經常訪問哪些程式設計類網站?

      Do you maintain any open-source projects?  你有自己的開源專案嗎?

      Do you code in your spare-time?  業餘時間你程式設計嗎?

      Do you love programming, or do you do it for the money?  對於你來說,程式設計是一種愛好,還是一種謀生手段?

      Have you accomplished anything important in your career yet? Do you want to?  你的職業生涯之中有什麼重要的成就?它是你主導的嗎?

      What would make you feel that you have done something important?  什麼事情會讓你很有成就感?

    五、考察理性思維

    某些情況下,你可能需要了解面試者的分析判斷能力,看他能否全面地思考問題、客觀地評價自己。

    那麼,你可以依次提出這樣三個問題:

      What"s your favorite programming language? Why?  你最喜歡的程式語言是哪種?為什麼?

      If you could add one feature to your favorite language, what would it be? Why?  如果允許你為這種語言加一種功能,你會加什麼功能?為什麼?

      If you could remove one feature from it, what would it be? Why?  如果允許你取消一種功能,會是什麼功能?為什麼?

    這裡的重點是,讓面試者從正反兩方面評價一件自己熟悉的東西,看看他的思維是否片面。答案無所謂對錯,只要面試者有一個明確的立場,能夠從正反兩方面說出令人信服的理由,就可以了。比如,某個軟體的口碑不好,但是面試者說他很喜歡,而且說得出一大堆理由,清楚地解釋了這種軟體的優點和缺點在哪裡,這樣就很好。

    你還可以把這些問題,套用在其他東西上面,比如作業系統、文字編輯器等等

  • 2 # 都市心聲

    不會運維的程式設計師不是好程式設計師。這個信條要時刻謹記,不管是面試還是自己平時在工作中都要堅持這個準則,因為這對你以後的發展大有裨益。

    觀念問題

    一直以來,很多圈外人對我們程式設計師的觀念就是永遠的一本正經,著裝單一,了無生趣,聰明絕頂,其實這是他們對程式設計師的誤解,因為多才多藝,多姿多彩的程式設計師比比皆是,但是傳統的觀念或者說以偏概全的觀念矇蔽了他們的雙眼,而他們自己又沒有嘗試去了解,所以導致人云亦云,給程式設計師披上了一層灰。

    同樣的,我們大部分程式設計師的觀念也跟他們差不多,認為程式設計師就只是搬磚擼碼的,至於各種部署伺服器相關的工作應該是運維做的,其實非也,如果真的這樣認為的話,那就真的太不把自己當程式設計師了。為什麼這麼說呢?因為我們程式設計師是實實在在擼碼開發產品的群體,可是如果我們開發出來的東西只能自個在本地玩耍,卻不能眾樂樂,那還有什麼意義,此時,你可能會說,交給運維啊,那麼如果沒有運維呢,就沒法玩了,所以我們不能總是將希望寄託在別人身上,當自己有能力能夠將系統進行部署的時候,那就該學會部署。

    其實不僅僅是程式設計師,優秀的運維工程師也是需要會開發擼碼的,因為有時候他們也需要開發一些小工具來進行驗證,或者開發網頁來進行服務的管理,所以說程式設計師和運維都是相輔相成的。

    公司問題

    像我們現在很多的公司都沒有明確的人員分工,特別是小公司連運維都沒有,所以就談不上讓運維去部署了,那麼怎麼辦呢?肯定就是開發人員自己去部署了,如果不會部署的話就可以去網上查詢資料,其實總體來說不會很難,因為我看過很多運維其實也是在網上找資料按步聚進行操作。

    另外公司之所以這麼要求,一方面是基於人員成本的考慮,畢竟如果一個人能幹好的事為啥非得招兩個人;另一方面可能基於公司的發展問題,像一般的小公司確實沒必要專門招一個運維,不過隨著公司的發展,後期肯定會招專業運維,畢竟專人做專事,事半功倍。

    總結

    永遠記住“不會運維的程式設計師不是好程式設計師”,其實作為程式設計師不能總是把自己陷在擼碼的深淵,除了擼碼,我們還要學會產品需求分析、簡單的UI畫圖、資料庫分表分庫及效能最佳化、運維伺服器部署、單元及系統測試等等,總的來說,要想成為優秀的程式設計師,我們有必要把產品線上的每一個環節都略知一二,這是經驗收穫,一定會成為我們日後發展的資本。

  • 3 # IT人劉俊明

    這是一個非常好的問題,作為一名IT從業者,我來回答一下。

    首先,在當前的大資料、雲計算時代,程式設計師在面試的過程中,經常會遇到與運維相關的問題,尤其是有自身產品(平臺類)的企業,往往對於程式設計師的運維類知識有比較多的要求,所以當前的程式設計師,尤其是Java程式設計師,要想獲得較強的崗位競爭力,一定要重視運維類知識的學習。

    在當前的大資料時代背景下,很多程式設計師在日常開發過程中,需要與運維人員進行配合,所以程式設計師在面試過程中,經常會被問及與運維相關的問題,透過這樣的問題,也能夠全面瞭解程式設計師是否面對過大使用者的併發問題,這對於判斷程式設計師是否適合當前的招聘崗位也有一定的參考價值。

    以大資料開發崗位為例,程式設計師在進行大資料任務開發的過程中,不可避免地需要與運維人員打交道,其中大資料平臺的搭建就是比較繁瑣的過程,另外還有一系列產品的安裝和部署,這些通常都需要運維人員來完成。對於一款平臺類產品來說,運維人員的技術能力能夠在很大程度上決定軟體平臺的效能,而且運維人員與開發人員的配合也非常關鍵。

    當然,對於程式設計師來說,如果能夠自己掌握一定的運維知識,對於開發任務的開展還是很有幫助的,如果什麼問題都需要運維人員來完成,不僅需要更多的運維人員,同時也會影響專案的整體開發進度。從這個角度來看,隨著未來大資料技術的逐漸落地,程式設計師掌握一定的運維類知識,對於提升自身的工作效率,還是很有幫助的。

    在程式設計師面試過程當中,透過一些運維知識也能夠更加直觀地瞭解到程式設計師的技術棧,相對於比較複雜的開發問題來說,運維知識的脈絡還是比較清晰的,透過運維知識能夠在一定程度上擠出一些“技術水分”,這也是很多面試官比較願意問運維問題的主要原因。另外,對於一些創業型公司來說,程式設計師掌握一定的運維類知識,也會節省一些投入,尤其在產品研發的初期。

    從技術體系結構來看,要想解決大使用者的併發問題和系統擴充套件性問題,通常需要從兩個角度出發,一個角度是技術選型,比如採用擴充套件性比較強的大資料平臺,另一個角度就是硬體擴充,但是硬體擴充的前提是要有一個可擴充的平臺體系,而透過運維知識,程式設計師的交流會更明確,技術方案也比較直觀。

    從崗位任務劃分的角度來看,程式設計師的工作任務與運維人員的工作任務有比較明確的邊界,但是在雲計算技術的推動下,程式設計師接觸運維場景的情況也在不斷增加,比如透過雲計算平臺的支撐,很多傳統的運維類任務,程式設計師也會比較方便地完成,比如安全配置等等。

    最後,程式設計師在進行面試的過程中,如果遇到的運維類問題並不清楚,一定要如實回答,因為運維類知識需要一個積累的過程,而且經驗往往非常重要,所以很多運維類知識,在短期內是無法掌握的,如果盲目擴充套件自己的知識面,會為後續的工作帶來很多麻煩。

  • 4 # 仁見人愛

    我覺得很自然的事,為什麼總有人說得高大上?裝個軟體,調個引數,做個邏輯卷,調一調網路,配置一下分散式元件,搞個檔案系統程式設計師就應該不會?

    這些工作,我們公司一般運維人員搞不定的。所以用啥,自己整。

    個人觀點,計算機知識就必須全面,才能做好一個程式設計師吧?

    而且看大家回覆,我有8成猜對,有8成以上的架構師,不懂底層,知識面也沒傳說中那麼廣。

  • 5 # 沉下心來看視界

    如何在程式設計面試中取得成功

    男子被採訪的女人-3874035

    好吧,讓我們承認。編碼面試是艱難的。

    有神經參與。有不舒服。有尷尬。還有一種奇怪的恐懼,我們可能在這次採訪中"吸",並創造自己的笑柄。可能出錯的情況是無窮無盡的。

    但這給我們帶來了一個問題。

    為什麼編碼面試很難?是隻問技術的東西, 還是更深的東西?

    查爾斯·達爾文在研究進化論時也有類似的問題(不!!!程式設計師)。故事說,有一天,在倫敦動物園,達爾文決定進行一項實驗。他把臉壓得儘可能靠近厚厚的玻璃,把他從有毒的泡芙加法器裡隔開。他發現,每次蛇朝他撲來時,他都會本能地跳回幾英尺,儘管玻璃是牢不可破的,蛇不會傷害他。

    達爾文最後得出結論,人類,儘管他們的優越智力仍然繼續根據他們原始的生存動物本能作出反應。這被稱為"戰鬥或逃跑反應",一種對感知到的威脅的生理反應,旨在使動物準備逃離危險或對抗危險。

    在現代,這些威脅可以歸結為失去聲譽,成為嘲笑的物件,甚至被口無歸,所有這些都在艱難的編碼採訪中痛苦地暴露出來。這些可能性是可怕的真實, 足以讓我們摸索透過採訪, 最終失去了情節。

    也就是說,做一個好的程式設計師並不能保證在程式設計採訪中取得成功。除了技術內容之外,每次面試都是一場神經戰,你需要在脅迫下快速解決問題,並清楚地解釋你的想法。

    這裡有一些事情幫助我在職業生涯中成功地完成了面試。

    提前做好準備

    我知道這聽起來很陳詞濫調,但我看到許多程式設計師坐在面試室外,試圖在面試前的10分鐘內學習"一切可能"。這是一個災難的配方,因為這不僅會讓你不那麼自信,但更糟糕的是,你可能會在面試中混為一時的關鍵概念。

    您理想的面試準備應在面試前一週開始。一個簡單的想法是建立一張 10 到 15 張幻燈片的故事幻燈片,其中突出顯示可能詢問的關鍵領域以及您的回答。單個幻燈片可以是這樣的。

    主題 1 = 主題要點。要點– 簡言之,這些概念可以解釋。例子- 一些獨特的經驗,我的經驗您的觀點 –這是您的解決方案

    記住,你不是在這裡寫書的。你只是建立一個像簡報一樣快閃記憶體卡,它可以在你的記憶中保持強化,當面試官提問時,它會回到你這些卡片上。另一個優點是,您還可以在鏡子前排練這些幻燈片,從而進一步增強您的信心。

    是的,這看起來可能有很多準備,但當賭注很高,你需要破解你生活中的夢想工作時,沒有什麼可以稱之為"大量的準備"。

    熱情

    這聽起來可能有些陳詞濫調,但50%的程式設計師在面試中被拒絕,不是因為他們的技術技能,而是因為他們沒有表現出對這份工作的一定熱情。

    記住,面試官也從各個角度評價你為這份工作的"合適人選"。公司希望那些興奮的候選人加入他們。他們欣賞那些研究過公司產品的應聘者,並且可以在面試中發表自己獨特的意見。邏輯很簡單;興奮的程式設計師是快樂的程式設計師,快樂的程式設計師是富有成效的程式設計師。

    記住,任何面試都像約會,在約會時,隱含的資訊是,你是眾多選擇之一,如果你想處於最頂峰,你需要與眾不同。這就是為什麼仔細準備筆記,為什麼你發現一個令人興奮的公司真的會提高你的透過率。攜帶準備好的筆記可顯示您的準備,以及隨後的興奮程度

    讓面試官來幫你。

    是的,這是一個艱難的,因為面試官不會幫助每一個候選人。事實上,他會無情地烤他們中的大多數,並傾向於幫助只有一小部分程式設計師誰設法與他建立某種信任。

    是的,關鍵字是信任在這裡,並在60分鐘內建立信任是不容易的,但非常可行。訣竅是確切地瞭解他期待什麼。一旦問了面試問題,你需要絕對清楚的問題,如果這意味著問更多的細節,不要猶豫問。

    提出問題,即使你幾乎可以肯定的答案。這是有用的,因為它驗證了你的想法,也參與面試官。在回覆最終解決方案之前,您還可以獲得額外的優勢,即多找些時間收集您的想法。

    記住,關鍵是與面試官接觸,讀懂他的思想。如果你只是跳到編碼沒有任何澄清,你可能會錯過機會,你的面試官給你進一步指標或提示。

    記住,展示你對程式碼的熱情是不夠的。要建立信任,你需要是好人。人們需要感覺你能做到,並且應該感到舒服地進一步交談。

    最後,仔細選擇您的戰鬥

    從廣義上講,有兩種型別的程式設計師參加面試,推手型別和論證型別。

    名字所暗示的推天下型別與面試官所說的一切一樣一樣。解決程式設計面試問題的方法總是不止一種。總是。通常有多種方法來解決問題,其中一些可能不是最佳的。優秀的面試官希望你這樣說,即使他們在錯誤的軌道。有時候也是故意的。所以同意他說的可能不是個好主意。

    另一個極端是爭論的程式設計師,他們發現面試官的每個概念都有漏洞。雖然這在某種程度上是好的, 但不斷爭論只是為了證明你的觀點和滿足你的自我可能會把你放在錯誤的基礎上。畢竟,沒有人願意在永久衝突模式下工作,這種衝突模式在最壞的情況下是自我毀滅的行為。

    這裡的關鍵是仔細選擇你的戰鬥。你只需要選擇那些戰鬥,你可以出來贏,顯示你的專業知識。軟體開發是複雜和非常主觀的性質和一些習慣也有很多變化,從程式設計師到程式設計師。因此,改變另一個程式設計師的(閱讀,面試官)的"工作方式"只是為了證明你的觀點不會給你任何布朗尼點。

    相反,將精力集中在真正重要的問題上,並優先考慮那些能更快地將你的價值放在桌面上的戰鬥。

    結論性思考

    透過面試是一種技能。成為一個偉大的程式設計師有幫助,但這只是圖片的一部分。你還需要培養你的思維技能,才能成為贏家。

    在你的職業生涯中,你將有幾次"好",壞"和"醜陋"的採訪。但是,不要太煩惱,因為每次面試都是一次學習經歷,與大眾觀點相反(當然還有一些自助書籍),沒有確定,100%保證破解面試的靈丹妙藥。你只需要學習,準備,參加,重新學習,並改進,以越來越好。就是, 它!!

  • 中秋節和大豐收的關聯?
  • 撕了自家和對門的破對聯,可對門要賠錢。應不應該賠?