How many times have you gotten the question “Tell me more about your work experience at …” or “Describe an experience when you had to overcome a technical challenge”? Is your answer solid and bullet-proof every single time you have to respond? If not, I have a simple but powerful 5-step approach to describing experiences in the context of a software engineering interview.

您有多少次問到“向我詳細介紹您在…的工作經歷”或“描述您必須克服技術挑戰時的經歷”這個問題？ 您每次都要回答時，您的答案是否可靠且防彈？ 如果沒有，我有一個簡單但功能強大的五步方法來描述軟件工程面試中的體驗。

The 5-Step Approach:

五步法：

1. Give background information.

   提供背景信息。

2. Why did you do the project?

   你為什么做這個項目？

3. Which tech stack did you use?

   您使用了哪個技術堆棧？

4. What was your individual contribution? What unexpected technical challenge did you have to overcome?

   您的個人貢獻是什么？ 您必須克服什么意外的技術挑戰？

5. What did your project accomplish in terms of results?

   就結果而言，您的項目完成了什么？

Let’s break down these five steps into more detail.

讓我們將這五個步驟更詳細地分解。

背景資料 (Background Information)

• Which company did you work for? For which class or organization did you build the project? Which team were you on?
  您在哪家公司工作？ 您為哪個班級或組織構建了項目？ 你在哪支球隊上？
• How long did it take to finish the project? Were you on a team or were you working solo?
  完成該項目需要多長時間？ 您是在團隊中還是獨自工作？
• What does the company do? What was the class or organization about?
  公司做什么？ 班級或組織是關于什么的？

I interned at Uber as a software engineering intern in the Fall of 2019. I was on the Order Platform team, which was responsible for ingesting and post-processing incoming data payloads. Every day, we process hundreds of thousands of terabytes of data coming from front end apps like Rides and Eats.

我于2019年秋季在Uber實習，擔任軟件工程實習生。我在Order Platform團隊工作，該團隊負責提取和后處理傳入的數據有效負載。 每天，我們都會處理來自Rides and Eats等前端應用程序的數十萬兆兆字節的數據。

為什么？ (Why?)

You have to drive home the impact of the project. Why did your company or organization want you to work on this project? Class projects are less optimal for this 5-step approach, but you can try to re-frame it around what topics the class was trying to teach. Some ideas for explaining the rationale behind the project:

您必須帶動項目的影響。 為什么您的公司或組織希望您從事此項目？ 對于這種五步方法，班級項目的最佳性較差，但是您可以嘗試圍繞班級嘗試教授的主題來重新設計課程。 解釋項目背后原理的一些想法：

• Were you trying to solve a business need? How many employees were experiencing this problem, and how frequently? How many man-hours or dollars did you save by implementing this project?
  您是否要解決業務需求？ 有多少員工遇到此問題，并且有多頻繁？ 通過實施該項目，您節省了多少工時或美元？
• Were you solving a customer pain point? How many users did your project benefit? Are there customer ratings, survey results, or other metrics that help to quantify your impact?
  您是否解決了客戶的痛點？ 您的項目使多少用戶受益？ 是否有客戶評分，調查結果或其他指標可以幫助您量化影響？
• Was your organization trying to empower a certain segment of the population, or do something good for the community?
  您的組織是在嘗試增強特定人群的能力，還是在為社區做點好事？
• Were you working on a tool that would increase developer productivity by de-duplicating coding efforts? Does your project centralize a particular functionality or feature? Is there an aesthetic redesign that makes the tool friendly to use for either employees or customers?
  您是否正在開發一種通過消除重復編碼工作來提高開發人員生產率的工具？ 您的項目是否集中了特定的功能或特性？ 是否進行了美學上的重新設計，使該工具易于員工或客戶使用？

We publish the processed data payloads onto a stream that other backend teams at Uber can subscribe to. However, most teams only require a small subset of the datastream, eg. the Risk team only cares about trips flagged with a security issue. Because of this, each team has to individually implement its own filtering logic to filter out the irrelevant data. Eventually engineers realized that there was a lot of duplicated efforts, so our team decided to launch a new centralized service to implement filtering logic. The other teams would subscribe to my service with their filtering preferences, and the service would give them only the payloads relevant to their workflow.

我們將處理后的數據有效載荷發布到Uber的其他后端團隊可以訂閱的流上。 但是，大多數團隊僅需要數據流的一小部分。 風險小組只關心標記有安全問題的旅行。 因此，每個團隊都必須單獨實施自己的過濾邏輯以過濾掉不相關的數據。 最終，工程師意識到進行了很多重復的工作，因此我們的團隊決定啟動一項新的集中式服務，以實施過濾邏輯。 其他團隊將使用其過濾首選項訂閱我的服務，并且該服務將僅向他們提供與其工作流程相關的有效負載。

科技棧 (Tech Stack)

This section should be straightforward.

本節應該很簡單。

• Which programming languages did you use for the backend, frontend, and/or middleware?
  您為后端，前端和/或中間件使用了哪種編程語言？
• Did you use frameworks or libraries?
  您是否使用框架或庫？
• What kind of database were you interacting with?
  您正在與哪種數據庫進行交互？
• Did you have to put your data into message queues or streams? Manage configurations or dependencies?
  您是否必須將數據放入消息隊列或流中？ 管理配置或依賴項？
• Did you use continuous integration? Testing libraries? Deployment frameworks?
  您是否使用了持續集成？ 測試庫？ 部署框架？
• How did you monitor for errors after deploying to production?
  部署到生產后，您如何監視錯誤？

Programming language: GoInterface definition language: ThriftConfiguration management: FliprDependency injection: UberFXDatabase: Uber Schemaless (distributed key-value storage, sharded mySQL)Message queues: KafkaData serialization format: Protobuf

編程語言：GoInterface定義語言：Thrift配置管理：FliprDependency注入：UberFX數據庫：Uber Schemaless(分布式鍵值存儲，分片mySQL)消息隊列：Kafka數據序列化格式：Protobuf

個人貢獻+意外的技術挑戰 (Individual Contribution + Unexpected Technical Challenge)

This is really the meat of your entire description. You have to make it very clear which part was your work, instead of the work of your teammates and classmates. Use pronouns to clearly denote which part was your individual contribution.

這確實是您整個描述的內容。 您必須非常清楚地說明工作是哪一部分，而不是隊友和同學的工作。 用代詞清楚地表明哪一部分是您的個人貢獻。

On the unexpected technical challenge — make sure this is a real challenge. Learning a new language or framework is not the best example. Try to think deeper than that. Did you have to deal with inconsistent data models? Legacy code whose developers left the company long ago? Non-existing documentation? Pre-existing code that is buggy and untested? Working cross-functionally with many other roles or teams? Working on a different part of the stack than your usual expertise? Changing the architecture for scaling purposes? Doing a lot of independent research to discover solutions to unsolved problems? Really sink into the details here.

應對意外的技術挑戰-確保這是一個真正的挑戰。 學習新的語言或框架不是最好的例子。 嘗試更深入地思考。 您是否必須處理不一致的數據模型？ 誰的開發人員很久以前離開公司的遺留代碼？ 不存在的文檔？ 先前存在錯誤且未經測試的代碼？ 與許多其他角色或團隊進行跨職能合作？ 與您通常的專業知識在堆棧的不同部分上工作？ 為擴展目的而更改架構？ 做大量的獨立研究來發現未解決問題的解決方案？ 真的在這里陷入細節。

At the time, the Uber Engineering organization was in the middle of a data model migration from the Trips model to the Orders model. Instead of the Trips model which just consists of a single trip, we wanted the new Orders model which consists of 1 trip to the restaurant, 1 trip to the customer’s house, and an associated job (delivering food to the customer). This was to account for Eats becoming a much more prevalent part of the business. Different teams were in different stages of implementing the migration, so data schemas often didn’t line up from team to team, or from the documentation to the actuality. I had to go in and talk to multiple teams to clarify their assumptions about the data model and make sure my service worked for them in an agnostic way. Even though many backend engineering teams were in a state of flux in regards to the Trips -> Orders data model transition, I was able to successfully complete my project to subscribe and filter the incoming data stream.

當時，Uber工程組織正處于從Trips模型到Orders模型的數據模型遷移的中間。 而不是僅由一次旅行組成的“旅行”模型，我們希望使用新的“訂單”模型，該模型包括到餐廳的一次旅行，到客戶的房屋的一次旅行以及與之相關的工作(向客戶提供食物)。 這是因為Eats成為業務中更為普遍的部分。 不同的團隊處于實施遷移的不同階段，因此，數據模式通常不會在團隊之間，從文檔到實際情況下保持一致。 我不得不與多個團隊進行交談，以澄清他們對數據模型的假設，并確保我的服務以不可知的方式為他們服務。 即使許多后端工程團隊在Trips-> Orders數據模型轉換方面處于不斷變化的狀態，我仍然能夠成功完成我的項目，以訂閱和過濾傳入的數據流。

結果 (Result)

Ideally your project was completely finished, tested, deployed, and saved the company millions of dollars. In the absence of any of the above, try to focus on the successful completion of the project and positive feedback from senior management. Talk about any opportunities you had to present the work to a panel. Did you improve the performance of a particular functionality? Write up the documentation and/or blog post? Complete the project ahead of deadline? Help out with extra tasks during your internship or project? Gave a live demo of the project to a large group of people? Anything that indicates your ability to both write about and verbally communicate about your project to a group of people is a positive signal to your interviewer.

理想情況下，您的項目已完全完成，測試，部署并為公司節省了數百萬美元。 如果沒有上述任何條件，請嘗試著重于項目的成功完成和高層管理人員的積極反饋。 討論您需要向小組展示作品的任何機會。 您是否改善了特定功能的性能？ 寫文檔和/或博客文章？ 提前完成項目？ 在實習或項目期間幫忙其他任務嗎？ 向大量人員進行了項目的現場演示？ 任何表明您有能力向一群人撰寫和口頭交流您的項目的信息，都對面試官發出了積極的信號。

By the end of my 3-month internship, I successfully integrated my datastream selection service with the Risk team to help them reduce engineering efforts needed to filter their input stream. My project also helped them to reduce their query execution time for input collection by close to 50%.

在結束為期3個月的實習后，我成功地將我的數據流選擇服務與Risk團隊集成在一起，以幫助他們減少過濾輸入流所需的工程工作量。 我的項目還幫助他們將輸入集合的查詢執行時間減少了近50％。

Try using this 5-part approach on any of the work experiences or projects on your resume today! Feel free to jot down some bullet points for each of the 5 parts, and practice going through them fluidly as if you are in a real interview situation. I can guarantee that this formula will help you to achieve more detailed descriptions and better storytelling.

立即嘗試將這種5部分方法用于簡歷上的任何工作經驗或項目！ 隨意記下這5個部分中的每個要點，并練習流暢地遍歷它們，就好像您處于真實的采訪環境中一樣。 我可以保證，該公式將幫助您獲得更詳細的描述和更好的故事講述。