Star method

개인적인 경험으로는 그냥 적당히 genuine한 얘길 하면 될 거 같습니다. 최대한 대화를 하는 것처럼 하세요. 질문에 정답을 얘기한다기보단 그냥 자연스럽게요. 꼭 모든 얘기가 마지막에 내가 결국 대단한 성공을 얻었다. 레베뉴가 50퍼 올랐다 이런 식으로 끝나지 않아도 되고요

화이팅

도움이 되련지 모르겠습니다만 제가 사용한 시나리오는

팀에 조인하고 얼마 있지 않아 이슈가 있었는데 매니저 의견이 맞지 않는것 같아서 자료를 준비해서 반대했다
알고보니 내가 모르는 도메인 날리지가 있어서 특수한 상황이라 매니저 말이 맞는 상황이었다
대화를 통해 왜 이슈에 대해서 그렇게 대처했는지 아는게 중요했음 –

실패인데 성공 스토리면 별로임. 실패했는데 다시 생각해보고 레슨을 얻고 그 레슨을 실험해본 스토리 이여아함

실패는 실수나 프로세스 문제점들과 연관시킬 수 있으면 좋고 특히 실패한 후 preventative actions and process improvements 를 통해 같은 실패의 반복을 팀 레벨에서 방지한 예시면 invent and simplify 와 bias for action 등 strong LP demo case 가 될 수 있습니다.

그냥 무조건 LP에 맞춰서 준비해가세요.
아마존 성향상 본인의 생각은 중요하지않고 LP에 부합하냐 아니냐만 따지기때문에 스토리 준비해가실때 허구를 좀 섞어서라도 LP에 맞게 대답하셔야합니다.
스토리당 2~3개의 LP에 적합하게끔 답변을 준비하세요.

대단 하시네요 저는 온사이트 전엔 준비를 거의 안했는데… 상사와의 충돌은 그냥 솔직히 말하시면 됩니다. 왜 의견이 달랐는지, 내의견이 옳다고 생각한 이유는 무었인지, 해결 하려고 어떤 노력을 했는지, 어떤식으로 해결됬는지, 해결하면서 배운건 무엇인지, 다음엔 어떻게 하는게 더 좋은 방법이라고 생각 하는지 등등 실제 생각 하셨던걸 그냥 말씀 하시면 더 쉽습니다.

저는 LP에 맞춰서 준비 하라고 권하고 싶지 않습니다. 인터뷰를 아마존에서 수십번 해봤는데 인터뷰 하는 사람들이 이 질문은 어떤 LP에 관한건가 focus를 두다 보니 질문의 취지에 맞지 않게 엉뚱하게 대답이 흘러가는 경우가 꽤 있습니다. 오히려 역효과가 나구요. 어차피 질문 자체가 LP를 알아 보려고 한거라 그걸 어떤 식으로 어떻게 어떤 데이터를 근거로 해서 해결하려고 했는지가 가장 효과 적입니다. LP에 맞춰서 스토리를 만들지 말고 본인 경험 스토리를 윗분중 한분이 말씀 하신것 처럼 STAR방식으로 준비하고 다시 한번 검토 하시면서 내가 내린 decision들이 LP에 부합 한가 아닌거 같으면 스토리를 좀 수정 하거나 다른 스토리를 준비 하는 방식으로 준비 하라고 추천 드립니다.

저도 사실 아마존 면접 앞두고 있는데 엔지니어 아니구요
엑셀 온라인 테스트는 안 보셨나요?
전 프로그램 매니져 쪽인데 보라고 하더라구요
어느 수준인지 궁금해요