인터뷰는 한편으로 communication skill을 보는 측면도 있으니까, 계속 질문하면서 인터뷰하세요. clarification questions을 하면서 인터뷰어가 원하는 답이 어떤 것인지 확실하고, 원하는 방향으로 답변을 해 나가면 됩니다. 가끔은 인터뷰어가 잘못된 답을 가지고 압박하는 경우도 있는데, 자신의 답을 강하게 주장하기 보다는 여러가지 방법을 (답안을) 말해주는 것도 방법입니다. 엔지니어가 정답을 찾는게 아니기 때문에 (원글님이 두번째 질문에서 답한 것 처럼) 다양한 방법론을 이야기 해 주는게 좋습니다.

저는 소프트웨어 쪽이긴 한데 시스템 디자인 쪽에서 상당히 비슷한 류의 질문이 있을 수 있습니다.
A-B 중 하나를 교체하는 문제의 경우라면, 제 경우에는 과거에 그 비슷한 경험을 설명하고, 왜 A 또는 B를 선택했는지 그 상황을 잘 설명할 것 같습니다. 그 상황과 로직에 따라 A 를 선택했고, 그 결과가 이러이러했다. 향후 결과는 1) 괜찮았다면 어떤식으로 성과가 나왔는지, 2) 좋지 않았다면 어떤 점을 간과해서 그런 결과가 되었는지 잘 설명하는 방식으로 접근할 것 같습니다. 주니어 레벨에서는 답이 좀 확실한 문제가 많을 거고, 시니어로 갈수록 open ended 문제가 많은데, 그럴 때는 하나가 정답이라고 하기보다 그 결정을 내리게 된 상황과 논리를 차근차근 잘 설명하는 게 좋습니다.

케이스 중에 기억이 잘 안나거나 모르는 부분이 포함되어 있는 경우, 1) 다른 정보를 이용해서 그것을 알아내는 것이 문제의 핵심인지, 2) 아니면 그 부분은 인터뷰어와 상의하에 가정하고 그 다음 더 큰 문제를 푸는게 핵심인지를 판단할 수 있으면 좋습니다. 굳이 improvise하자면, 예전에 비슷한 문제를 풀 때는 그 분야의 전문가가 팀에 있어서 함께 협업하면서 해결했었다. 이 부분을 이런 식으로 가정하고 넘어가면 되겠느냐라고 물을 것 같습니다.

HW case 1의 경우는 비일 비재한데
대강 대답하려다가 보면 오히려 잘모르는데 아는척하는것으로 오해하기 딱 좋습니다.
그냥 솔까, 오래되서 기억이 잘안난다고 하고 질문을 구체적으로 다시 해달라고 하는게 방법입니다.

조금 딴 이야기지만, 뭐 하나 빼먹고 이야기했더니 뭐 빼먹은거 없는지 잘 찾아보라고 하는 인터뷰어도 있습니다.

case 2는 내 경험상/내 분야에선 존재하지 않는것 같은데
그냥 자신의 의견을 이유와 함께 “소신” 있게 강하게 이야기 하면 충분합니다.