안녕하세요.
온사이트 일주일 남았는데 여전히 프람프에서도
떨리네요. 모르는 문제 나오면 순간 머리 정지되는 병좀 고치고 싶습니다.
다들 어떻게 극복 하셨나요?
온사이트 팁 주시면 감사하겠습니다.

onsite 버츄얼 최종 면접으로 대체 되지 않았나요?

네 리모트에요. 버츄얼로해도 떨릴거같네요.

안녕하세요, 저도 최근에 Virtual onsite 진행했습니다.
제 Review 말고도 Leetcode.com – >Discuss -> Interview experience 에 가셔서 Amazon으로 검색하시면 많은 후기가 나옵니다.
대부분 비슷합니다. Coding 문제는 NDA에 사인했기 때문에 공개하지 않겠습니다. 그리고 동일한 문제가 나오지도 않을 거라 생각됩니다.

1. Tool
Amazon Chime을 이용했습니다. 다행히 인터뷰 도중에 Technical difficulty는 없었습니다.
화상으로 얼굴보고 하니까 이질감 없었고, 목소리도 깔끔했습니다.

2. Programming language
아시겠지만, 선호하시는걸 사용하시면 됩니다. 저는 C/C++ 사용했습니다.

3. 구성
1시간씩 총 5시간으로 구성되었습니다. 중간에 쉬는시간(점심시간) 1시간 넣어주어서 총 6시간입니다.
처음에 Recruiter가 보내준거는
Coding (엔지니어)
LP (Leadership Principles) (매니저)
Coding (엔지니어)
LP (매니저)
System Design (엔지니어)
였는데, 실제로는 hiring manager를 제외하고 전부 coding을 물어봤습니다.

실제로는
첫번째: 40분 LP + 20분 코딩 (OOD – medium)
두번째: 30분 LP + 30분 코딩 (OOD – easy)
세번째: 30분 LP + 30분 코딩(Leetcode hard)
네번째: 30분 LP + 30분 코딩(Leedcode medium)
마지막: 매니저 -> 45분 LP, 나머지 15분 Open question

이러한 구성이었습니다.
첫번째는 인터뷰어가 시간을 잘못잰거 같고, 결론은 30분 LP + 30분 코딩이라 생각하시면 됩니다.

4. 무엇을 준비해야하는가
5명이 사전에 각자 무엇을 물어볼지 정해서 오는 듯합니다. 그래서 5시간의 인터뷰 구성이 겹치지 않고 알찼(?)습니다.

LP: 위에서 보시면 아시겠지만 3시간이 LP 입니다. STAR 방식을 이용해서 말해야한다고 하지만 저는 단순히 (상황/내가한것/결과) 이렇게 3단계로 말했습니다. 많은 사람들이 코딩에 중점을 두기때문에 LP에서 떨어집니다. 저는 14개 아마존 원칙을 보고 1주일 동안 각각 항목에 2개씩 예제를 만들고 갔는데도 나중에 실제 인터뷰에서 예제가 다 떨어졌고, 나중에는 1개를 재사용했습니다.
재사용은 절대 좋지 않습니다. 아마존에서 data point 를 수집하는데, 최대한 많은 정보를 줄 수 있어야 합니다.
보통 어떠한 방식이냐면,
A라는 문제가 있었는데 -> B 로 접근해서 풀었고 -> C라는 결론이 나왔다.
매니저가 그러면 D로 풀면 안됐냐? 왜 B로 풀었냐. C라는 결론에 만족하냐, 혹시 지금이라면 바꿀생각이 없냐.
정답은 없습니다. 오히려 LP도 결국 보면 thinking process를 보는 것 같습니다.

Coding: 나머지 2시간은 코딩입니다. (Easy / Medium / Hard) 가 한개씩 골고루 섞여서 나옵니다. 각각 1/2/1 개라고 생각하시면 될 것 같습니다. 단순히 푸는게 중요한게 아닙니다. 쉬운문제라도, 왜 이렇게 생각했고, 왜 이렇게 풀었는지 말을 해야 합니다.
코딩으로 바로 들어가지 마세요. 저는 항상 “제 아이디어는 이렇게 이렇게 풀면 좋을 것 같습니다” 라고 말을 꺼내 “대화”를 유도하고, 실제 이 문제를 같이 풀듯이 했습니다 .실제 일하시면서도 느끼시겠지만, 저 혼자 문제를 해결하기보다 팀원과 대화를 통해서 문제를 푸는 모습, 그리고 어떻게 문제에 접근하고 왜 그렇게 생각했는가라는 “thinking process”를 물어봅니다.
실제로 저는 hard 문제는 어려워서 완벽하게 해결하지 못했고, 인터뷰 끝나고 돌려보니 버그가 있었습니다. 하지만 다행이었던건 approach 에 대해서 잘 설명하여 인터뷰어를 납득시켰습니다.

Reverse Interview: 보통 끝에 5분 주어지는 질문하는 시간입니다. 여기서 좋은 질문을 하는 것도 방법입니다.
Compensation이나 benefit 같은 거를 물어보기보다는, 팀의 구성, manager의 나에대한 expectation, role 등을 물어봤습니다.
https://github.com/viraptor/reverse-interview/blob/master/README.md

화이팅입니다. 정답을 외우시기보다는, 차분히 자신이 지난 3-4년간 무엇을 일했고, 이 부분을 인터뷰어에게 어떻게 설명할 것인가에 대해 생각해보시기 바랍니다.

‘최근에합격’ 님이 잘 설명해 주셨네요. 전 Software Engineer포지션은 아니나 얼마전에 Architect쪽으로 면접보고 얼마전에 합격했습니다. 역시나 14가지 Leadership Principal에 중점을 둔 마지막 5시간짜리 인터뷰였습니다. 합리적, 논리적으로 생각하고 일하시는분이라면 그대로 했던걸 말씀하시면 될듯하네요, 저도 준비하지 않고 면접에 응햇지만 적어도 어떤 질문에는 이 경험을 얘기해야하겠다는 서머리는 해두었습니다. 윗분이 말씀하신대로 지금까지의 경험이 막상 인터뷰에서는 기억나지 않기때문에 겹치게 되고, 좋은 스토리텔링이 될 수 없다고 생각하네요. 화이팅

최근에합격님 감사합니다!!

저도 1주일 전에 AWS와 버추얼 온사이트 인터뷰를 보았습니다. 최근에합격님이 설명을 잘 해주셔서 두 가지만 첨언을 하자면

1. 저도 시스템 디자인 인터뷰 라운드가 하나 있었는데 AWW board (https://awwapp.com/) 에 그림그려가며 설명했습니다. 프로그램이 손에 익지 않아서 좀 고생했네요.
2. 제 경우는 일반적인 함수작성 문제 외에 간단한 Object Oriented Design 문제도 하나 있었습니다.

최근에합격님 감사합니다. 축하드립니다.
모든분들 감사합니다.
잘 보고 글 남기겠습니다.

그저께 봤는데 최근에 합격 님이 올려주신것과 거의 동일했네요.. 물론 저는 잘 못했지만요..

근데 리트코드 기준으로 미디엄인지 이지인지 하드인지는 어떻게 아는거예요?
리트코드 문제를 그대로 내는게 아닌데

참가자들이 추정하는건가요?