① 程序員應該如何去請教別人問題
抽象類：使用關鍵字abstract修飾，子類使用extends繼承，介面使用interface修飾，使用implements實現，抽象類中可以有抽象方法，也可以有方法實現，也有變數，介面中只有最終常量，和抽象方法，介面可以多實現，類只能單繼承
② 我是個編程的自學者，想當程序員不知道公司寫文檔是什麼意思知道的情給我解釋一下,還有具體是怎樣工作的
以鄙人在軟體公司工作的經驗與你分享一下吧。
我們平時做項目，一般有一半以上時間都在管理文檔，包括基本設計書，詳細設計書，靜態樣式書，各種UML建模圖，單體測試書，系統測試數，結合測試書，DB設計書，DB腳本，以及各種工具類管理文檔，如資源文件管理，VBA管理等等，這還不包括項目前期的需求建設書，項目中期與客戶交流的反饋書，項目後期的BUG管理書，以及貫穿項目的工程進度表和版本控制書。當然你的代碼資源（包括注釋，圖片，腳本等）也屬於文檔，需要統一管理。
對於追求簡短快的團隊，未必會太重視文檔的組織與管理，但是一定要相信文檔看似浪費時間，其實無形中提高了很大的效率，而且在未來的開發提供了寶貴的參考資料。屬於團隊積累的一種。
③ 嵌入式程序員也要和客戶進行交流，談項目嗎
這個要看公司了， 比較規范的公司一般是由項目負責人或系統工程師去和客戶交流，從而獲得具體的需求，而程序員只需要根據需求文檔來編程。
不過小公司，或不怎麼規范的公司沒具體的崗位規定，那就是程序員直接出面了。
而且，以國內的實際情況來看，很多客戶都不知道自己到底想要什麼，需要一邊開發，一邊提出新需求，這時候，程序員去談效率高一點。
談項目嘛，一般是老闆或銷售出面，程序員就起個技術咨詢的作用。
④ 好累，程序員聽不懂產品經理提的需求，問多了，產品經理嫌煩。該怎麼辦
這個東西應該有一定經驗積累會理解比較快，也是一個過程。只有多溝通，在溝通前想想溝通的目的，這次溝通要解決什麼問題。用筆記下來。然後在實操，在實操過程中如果遇到問題先想一想，試著自己去解決一下。再去詢問，至少讓別人感受你是在用心做這件事。而且也是想做好這件事。其實你們的目的都是一致的。注意方式方法，不要讓別人覺得你一個問題重復的問還沒什麼結果。大家都有自己的事情都會比較煩。
⑤ 我一名程序員，老闆讓我寫項目的需求分析，關鍵他們還沒搞清楚想要什麼樣的功能，我無從下手，很糾結 時間
程序員是要根據項目的需求分析來寫程序的，而項目的需求分析是得根據客戶的需求寫的，如果客戶還不清楚想要什麼樣的功能，你也只能等他清楚了才能開始寫，要不然程序就白做了。如果時間緊，老闆有讓你快趕出來的話，你也只能先抓住客戶的其中一些需求來寫，以後好慢慢補充進去
⑥ 程序員有一個功能不能滿足客戶的時候,應該怎麼樣跟客戶溝通
如果能實現，那麼就還是認真完成客戶需求，如果實現起來難度很大而且會有影響比如性能啊，或是其他什麼方面的應該盡量跟客戶溝通，告訴他實現這個問題的難道，別用程序員的代碼什麼的，一般客戶都不懂代碼……
⑦ 你要面試一個程序員，應該問他什麼問題
首先面試程序員分有沒有經驗
面試沒有經驗的程序員就隨便問問點ssm，ssh五大框架問題，多線程什麼的，再問問是否會點前端技術
有經驗就看看他的簡歷，問他簡歷項目上的問題，可以圍繞著簡歷上的項目問，通過他的回答涉及到的技術點之類的，拓展出去問其他的
⑧ 程序員要怎麼考慮用戶的需求
回答之前先說一句：這不是一個程序員要明白的東西。程序員要做的就是敲代碼。
還有，你說用戶的需求似乎永遠都無法完全滿足，這是錯誤的想法
你要主動的問客戶問題，了解他們的情況。
比如說要實現什麼功能，還有客戶的硬體配置，以及客戶他們的各個部門之間的關系。
他們的業務流程，和他們各部門的許可權。
這些必須要明明白白。也許，你會說這些對軟體有什麼關系啊？
當你真正需要這些東西的時候就會明白了。
然後就是把這些在紙上打出「草稿」讓客戶瀏覽
如果他們滿意就簽字。簽字很重要。
要注意一點：他們不懂軟體。他們是客戶。
他們只要把需要實現的功能告訴你，然後就是把錢給你。
大部分的情況你是在玩一幫不懂軟體的人，所以他們不會理解做軟體需要哪些信息。