개발자 면접에서 떨어지고 나서야 알게 된 것들

첫 개발자 면접에서 떨어졌을 때 저는 결과보다 그 이유를 빨리 알고 싶었습니다. 준비한 질문에는 대부분 대답할 수 있다고 생각했고, 이력서에 적은 기술도 실제로 사용해 본 경험이 있었기 때문에 최소한 좋은 인상은 남겼다고 믿었습니다. 하지만 면접이 끝난 뒤 돌아보니 저는 제가 무엇을 했는지는 설명했어도 왜 그렇게 했는지, 다른 방법과 비교해 어떤 판단을 내렸는지는 제대로 말하지 못했습니다. 당시에는 면접관의 질문이 너무 어렵다고만 생각했지만, 며칠 동안 면접 장면을 되짚으면서 부족했던 것은 지식의 양보다 설명하는 태도와 사고 과정이라는 사실을 깨달았습니다.

첫 번째 탈락에서 놓친 질문

첫 번째 면접에서는 제가 맡았던 웹 서비스 개선 경험을 중심으로 이야기했습니다. 화면 응답 속도를 줄이기 위해 특정 기능의 처리 순서를 바꾸었고, 불필요하게 반복되던 작업을 한 번만 수행하도록 수정했다고 설명했습니다. 그런데 면접관은 곧바로 왜 그 문제가 발생했는지, 변경 전후를 어떻게 비교했는지, 예상하지 못한 부작용은 없었는지를 물었습니다. 저는 당시 작업을 빨리 끝내는 데 집중한 나머지 수치를 꼼꼼히 기록하지 않았고, 기억에 의존해 대답하다 보니 설명이 자꾸 흔들렸습니다. 제가 한 일을 말하는 것과 제가 한 일을 이해하고 있다는 인상을 주는 것은 전혀 다른 문제였습니다.
그 면접에서 특히 아쉬웠던 대목은 모르는 질문을 받았을 때의 반응이었습니다. 저는 정확히 알지 못하는 내용을 틀리게 말하고 싶지 않아 잠시 침묵했고, 결국 짧게 모르겠다고 답했습니다. 모른다는 사실 자체가 문제라기보다, 어디까지 알고 무엇을 확인해야 하는지 보여주지 못한 것이 더 큰 문제였다고 생각합니다. 예를 들어 비슷한 상황을 겪어 본 경험을 연결하거나, 제가 먼저 확인할 조건을 정리했다면 적어도 문제를 풀어 가는 방식은 전달할 수 있었습니다. 그때의 저는 정답을 맞히는 사람만 좋은 개발자가 될 수 있다고 착각하고 있었습니다.

경험을 목록으로만 정리했던 이유

이후 이력서를 다시 읽으면서 저는 기술 이름과 담당 업무를 지나치게 많이 적어 놓았다는 것을 발견했습니다. 여러 도구를 다뤘다는 문장은 많았지만, 실제로 어떤 상황에서 선택했고 결과가 어땠는지는 거의 남아 있지 않았습니다. 그래서 면접 준비 방식을 바꾸어 각각의 경험을 문제, 판단, 행동, 결과의 순서로 다시 적었습니다. 당시 사용자가 어떤 불편을 겪었는지, 팀 안에서 어떤 의견 차이가 있었는지, 제가 직접 결정한 부분은 무엇인지 하나씩 구분했습니다. 숫자를 남겨 두지 않은 경험은 변화의 정도를 솔직하게 적었고, 성과가 크지 않았던 작업도 그 과정에서 무엇을 배웠는지 정리했습니다.
그렇게 정리하다 보니 제가 맡았다고 생각했던 일 중에는 사실상 지시받은 내용을 수행한 것에 가까운 경우도 있었습니다. 예전에는 그 사실을 숨기고 싶어서 모든 일을 주도적으로 진행한 것처럼 표현했지만, 오히려 구체적인 질문이 들어오면 금방 빈틈이 드러났습니다. 두 번째 준비부터는 제가 결정한 부분과 다른 사람이 방향을 정한 부분을 분명히 나누어 말했습니다. 대신 제가 맡은 범위 안에서 어떤 판단을 했고, 모르는 부분을 누구에게 어떻게 물어봤는지를 설명했습니다. 과장하지 않고 역할의 경계를 인정하니 말이 훨씬 자연스러워졌고, 면접관의 추가 질문에도 덜 흔들렸습니다.

두 번째 면접에서 반복한 실수

두 번째 면접은 첫 번째보다 준비를 많이 했다고 느꼈지만 결과는 또 탈락이었습니다. 이번에는 기술 질문에 답하는 데 지나치게 힘을 주다 보니 질문의 의도에서 벗어나는 문제가 생겼습니다. 면접관이 협업 중 의견이 달랐던 상황을 물었는데, 저는 제가 사용한 기술의 장점을 길게 설명했습니다. 상대방과 어떻게 대화했는지보다 결과적으로 어떤 구조를 선택했는지만 강조한 셈입니다. 면접이 끝난 뒤 녹음해 둔 메모를 다시 보면서, 저는 사람과 함께 일한 경험을 말하면서도 계속 혼자 해결한 이야기만 하고 있다는 사실을 알게 되었습니다.
그 후부터는 답변을 시작하기 전에 질문의 핵심을 짧게 되짚는 습관을 들였습니다. 의견 충돌에 대한 질문이라면 먼저 상황과 상대의 우려를 설명하고, 제가 어떤 기준으로 대안을 비교했는지 이야기했습니다. 제 주장을 관철했다는 식으로 끝내지 않고, 일정과 유지 가능성을 고려해 처음 생각과 다른 선택을 받아들였던 경험도 덧붙였습니다. 이 연습을 하면서 면접은 내가 얼마나 많이 아는지 보여주는 자리가 아니라, 함께 문제를 다룰 때 어떤 사람인지 전달하는 자리라는 생각이 조금씩 자리 잡았습니다.

탈락 통보를 대하는 방법

세 번째로 지원한 회사에서는 면접 결과를 알려 주면서 피드백을 짧게 보내 주었습니다. 기본기가 부족하다기보다 답변이 길고 핵심이 늦게 나온다는 내용이었습니다. 처음에는 서운했습니다. 저는 자세히 설명하는 것이 성실함이라고 생각했기 때문입니다. 하지만 실제로 제 답변을 글로 옮겨 보니 결론을 맨 마지막에 말하고, 관련 없는 배경을 너무 많이 붙이고 있었습니다. 이후에는 먼저 결론을 말한 뒤 근거와 사례를 덧붙이는 방식으로 답변을 바꾸었습니다. 모든 질문에 완벽히 답하려 하기보다 질문 하나에 경험 하나만 연결하니 오히려 제가 가진 장점과 부족한 점이 더 선명하게 보였습니다.
물론 모든 탈락을 제 노력 부족으로만 해석하지는 않았습니다. 채용에는 팀의 시기와 필요한 역할, 경력 수준 같은 제가 통제할 수 없는 요소도 분명히 있습니다. 다만 그 사실이 준비를 대충 해도 된다는 뜻은 아니었습니다. 저는 탈락 통보를 받을 때마다 감정적으로 회사를 평가하기보다, 다시 답한다면 어느 부분을 다르게 말할지 세 줄로 적었습니다. 어떤 질문에서 막혔는지, 어떤 사례가 부족했는지, 다음에 확인할 지식은 무엇인지 기록했습니다. 결과를 바꿀 수는 없어도 다음 면접에서 같은 실수를 반복하지 않는 데는 이 기록이 꽤 큰 도움이 되었습니다.

면접 이후 달라진 준비 방식

몇 번의 실패 뒤에는 예상 질문을 외우는 대신 제 경험에서 질문이 나올 만한 지점을 찾았습니다. 한 기능을 바꾼 이유, 일정이 늦어진 원인, 동료와 의견이 달랐던 순간, 사용자 반응이 기대와 달랐던 장면을 각각 적어 보았습니다. 그리고 한 사례를 두세 문장으로 설명하는 연습과 오 분 정도 자세히 설명하는 연습을 따로 했습니다. 실제 면접에서는 질문의 깊이에 따라 답변 길이를 조절해야 했기 때문입니다. 가족이나 동료에게 질문을 부탁해 보니 제가 당연하게 여겼던 표현이 다른 사람에게는 모호하게 들린다는 것도 알게 되었습니다.
제가 면접을 통해 가장 크게 배운 것은 떨어지는 일이 제 실력을 한 문장으로 결정하지 않는다는 점입니다. 동시에 탈락을 단순한 운이나 면접관의 취향으로만 돌리면 같은 문제가 계속 남는다는 점도 배웠습니다. 저는 부족한 부분을 인정한 뒤 경험을 다시 해석하고, 실제로 모르는 것은 공부하며, 말하는 방식을 조금씩 고쳤습니다. 아직도 긴장하면 설명이 길어지고 예상하지 못한 질문 앞에서 머릿속이 하얘질 때가 있지만, 예전처럼 결과만 보고 스스로를 단정하지는 않습니다. 면접에서 한 번 떨어진 경험은 끝이라는 판정이 아니라, 제가 어떤 개발자로 일하고 싶은지 더 정확히 확인하게 만든 계기였습니다.
지금 면접을 준비하는 분이라면 합격한 사람처럼 보이기 위해 모든 답을 꾸미기보다, 자신이 실제로 겪은 장면을 정직하게 들여다보셨으면 합니다. 잘한 일만 골라 말할 필요도 없고, 작은 작업을 크게 포장할 필요도 없습니다. 무엇이 어려웠고 어떤 선택을 했으며 그 선택이 어떤 결과로 이어졌는지를 차분히 설명할 수 있다면 그 안에 이미 충분한 이야기가 있습니다. 저도 여러 번 떨어진 뒤에야 그 사실을 이해했습니다. 이번 결과가 기대와 다르더라도 그것을 다음 대답을 더 나아지게 만드는 자료로 남긴다면, 실패한 면접도 결국 자신의 방식과 방향을 다듬는 경험이 될 수 있습니다.