Phỏng vấn Amazon khó đến mức nào?

Nếu bạn đã miệt mài luyện các bài toán thuật toán mà vẫn thấy mình chưa sẵn sàng, thì trực giác đó đúng. Phần này giải thích cái khó thêm vào đó là gì, vì nó không nằm ở các bài toán, và luyện thêm bài cũng không giải quyết được điều đó.

Amazon áp dụng một quy trình phỏng vấn có cấu trúc. Người phỏng vấn được giao những Leadership Principles cụ thể để đánh giá, họ ghi chép chi tiết trong lúc trò chuyện, và những ghi chép đó được đối chiếu sau đó trong buổi debrief. Từ đó nảy sinh hai hệ quả. Một câu chuyện nghe ổn trong phòng lại đọc lên mỏng manh trên giấy nếu nó không có quyết định và không có kết quả, và cùng một câu chuyện được kể với chi tiết khác nhau ở hai vòng sẽ lộ ra ngay khi ghi chép được đối chiếu.

Nguồn gốc khó khăn khác là ngưỡng hành vi cũng áp dụng ở cả vòng kỹ thuật. Một ứng viên giải sạch sẽ bài toán code nhưng không thể kể lại một lần bất đồng với quản lý đã trượt ở một phần mà một buổi phỏng vấn thuần kỹ thuật sẽ không bao giờ đo được.

Bar Raiser là một người phỏng vấn đến từ ngoài đội đang tuyển dụng, được đào tạo riêng cho vai trò này, với nhiệm vụ đánh giá xem bạn có nâng mức trung bình của những người đã ở cấp độ đó hay không. Họ không đánh giá xem đội có cần thêm người trong quý này hay không, và họ có thể chặn một lượt tuyển dụng mà quản lý tuyển dụng đang muốn.

Trong thực tế, điều này có nghĩa là người quyết định kết quả của bạn không có lợi ích gì trong việc lấp đầy vị trí đó. Sự cấp bách không giúp được bạn, và mối quan hệ tốt với quản lý cũng vậy. Điều thực sự hữu ích là bằng chứng có thể đứng vững sau khi được viết ra và đọc bởi một người chưa từng gặp bạn.

Bạn thường không biết ai là người phỏng vấn đó, và điều đó không quan trọng. Hãy trả lời mọi vòng như thể nó sẽ được một người lạ đọc lại sau này, vì đúng là như vậy.

Hãy chia công việc ra. Nửa kỹ thuật là phần quen thuộc: cấu trúc dữ liệu, thuật toán, và từ cấp trung trở lên là thiết kế hệ thống. Phần lớn ứng viên trượt không trượt ở đây.

Nửa hành vi cần tám đến mười hai câu chuyện trải khắp các Leadership Principles, mỗi câu chuyện có tình huống, điều chính bạn đã quyết định, và một kết quả đo lường được. Một dự án duy nhất có thể cho ra hai hoặc ba câu chuyện từ những góc nhìn khác nhau. Hãy ghi kết quả dưới dạng con số bất cứ khi nào có, vì câu hỏi tiếp theo thường đòi hỏi đúng điều đó.

Sau đó, hãy luyện nói to. Một kỹ sư back-end với chín năm kinh nghiệm đã viết ghi chép rất xuất sắc nhưng vẫn bị khựng lại ở lần luyện tập đầu tiên, vì đọc một câu chuyện và kể nó dưới câu hỏi tiếp theo là hai kỹ năng khác nhau. Hai tuần luyện nói tại /mock-interview đã thay đổi cách trình bày nhiều hơn cả một tháng đọc thêm. Bức tranh từng giai đoạn của cả quy trình nằm ở /answers/topic/company-interviews.

Bốn kiểu mẫu giải thích cho phần lớn các trường hợp, và không cái nào liên quan đến trí thông minh.

• Câu chuyện không có quyết định. Mô tả những gì một đội đã làm thay vì những gì bạn đã chọn. Ghi chép cuối cùng không còn bằng chứng nào gắn với tên bạn.
• Không có kết quả. Một câu chuyện kết thúc khi dự án ra mắt, không nói gì về việc nó có hiệu quả hay không.
• Hết chất liệu. Dùng lại cùng một dự án ở bốn vòng, điều mà buổi debrief nhìn ra dù không người phỏng vấn nào riêng lẻ nhận thấy.
• Giải bài toán trong im lặng. Xử lý một câu hỏi code mà không nói ra lập luận, khiến người phỏng vấn không có gì để ghi lại.

Cũng đáng nói thẳng rằng những kỹ sư có năng lực vẫn bị loại ở đây vì những lý do không liên quan gì đến năng lực, bao gồm sự phù hợp với đội và thành phần hội đồng phỏng vấn hôm đó. Sự chuẩn bị làm thay đổi tỷ lệ; nó không quyết định kết quả, và bị từ chối không phải là một phán quyết về năng lực của bạn.