페어 프로그래밍 면접: 혼자가 아닐 때 평가되는 것
기본 전제는 “나는 관찰당하고 있다”입니다. 실제로는 누군가가 당신과 함께 일하고 있고, 점수가 잘 나오는 거의 모든 행동은 이 차이를 알아차리는 데서 나옵니다.
가장 비싼 착각
대부분은 면접관을 마침 같은 방에 있는 심사자라고 가정하고 들어옵니다. 그러면 올바른 행동은 유능해 보이게 연기하고 빈틈을 드러내지 않는 것이 됩니다. 그 가정 아래서는 질문을 하지 않습니다. 묻는 건 모르는 것처럼 보이니까요. 생각을 소리 내어 말하지도 않습니다. 반쯤 만들어진 생각은 다듬어지지 않아 보이니까요.
정확히 반대입니다. 페어 라운드에서 면접관은 40분 동안 동료이고, 측정되는 것은 “당신과 함께 일하면 어떤가”입니다. 당신의 침묵은 침착함이 아니라, 같이 짜기 힘든 사람이라는 뜻입니다.
상대를 쓰세요, 소리 내어
페어 세션은 혼자 하는 라운드에 없는 것을 줍니다. 이미 답을 아는 두 번째 두뇌입니다. 이걸 잘 쓰는 지원자는 세 가지를 반복합니다.
가정 위에 쌓기 전에 가정을 확인합니다. “이 ID들이 유일하다고 가정하고 있는데, 그래도 되나요?” 10초면, 잘못된 방향으로 가는 20분을 막습니다.
추측하는 대신 선택지를 제시합니다. “딕셔너리로 할 수도 있고 먼저 정렬할 수도 있습니다. 정렬이 읽기 쉽고, 딕셔너리가 빠릅니다. 여기서는 어느 쪽이 중요할까요?” 이건 우유부단함이 아니라 실제 일이 굴러가는 방식입니다.
그리고 힌트를 따지지 않고 받습니다. 누군가 “리스트가 비어 있으면요?”라고 하면, 답은 변명이 아닙니다. “좋은 지적입니다”와 가드 절입니다.
타이핑은 일이 아닙니다
흔한 패턴이 있습니다. 지원자가 30분 동안 꾸준히 타이핑해서 거의 동작하는 무언가를 만들고, 부정적인 피드백을 받습니다. 면접관이 사고 과정을 따라갈 수 없었으니 결과물 말고는 평가할 게 없었고, 그 결과물은 미완성이었습니다.
반대 패턴이 점수가 더 좋습니다. 코드는 적게, 설명은 많이, 체크포인트는 자주. “네, 여기까지가 메인 경로입니다. 더 가기 전에 — 잘못된 입력을 처리할까요, 아니면 지금은 정상 경로만으로 충분할까요?”
이 질문은 실제로 일을 합니다. 그 케이스를 안다는 걸 보여주고, 시계를 존중하고, 면접관을 구경꾼이 아니라 범위 결정의 참여자로 만듭니다.
상대와 의견이 다를 때
일어납니다. 면접관이 틀렸다고 생각되는 방향을 제안합니다. 양쪽 극단 모두 손해입니다. 말없이 따르면 의견이 없는 사람으로 읽히고, 버티면 팀에서 피곤할 사람으로 읽힙니다.
해야 할 일은 이견을 구체적이고 값싸게 만드는 것입니다. “입력이 이미 정렬돼 있으면 그게 깨질 것 같은데, 그 케이스로 한번 해봐도 될까요?” 이제 논쟁이 아니라 2분짜리 실험이 되고, 누가 맞았든 당신은 기술적 이견을 어떻게 푸는지 보여준 셈입니다. 그게 사실 이 라운드가 묻고 있는 것에 가장 가깝습니다.
마지막 5분
대부분은 마지막 구간을 더 빨리 타이핑하는 데 씁니다. 끝내기를 바라면서요. 못 끝내는 건 흔한 일이고 치명적인 경우도 드뭅니다. 설명하지 않은 쪽이 더 나쁩니다.
시간을 더 잘 쓰는 법: 멈추고, 지금 어디까지 왔는지 말하세요. “표준 케이스는 동작합니다. 10분이 더 있다면 중복을 처리하겠고, 여기에 본 적 있는 집합을 두는 방식으로 하겠습니다.”
이로써 무엇이 빠졌는지, 어떻게 마무리할지 안다는 걸 보여준 겁니다. 그게 어차피 끝냈을 때 증명됐을 것의 대부분입니다.
그들이 적고 있는 것
페어 라운드의 면접관은 보통 짧은 평가표에 따라 점수를 매기고, 그 항목은 알고리즘에 관한 것이 거의 아닙니다. 반복해서 나오는 항목은 의사소통, 협업, 피드백 처리, 압박 속 디버깅입니다.
의사소통은 말솜씨가 아닙니다. 지켜보는 사람이 당신의 다음 수를 예측할 수 있느냐입니다. 예측할 수 있으면 당신은 읽히는 사람이고, 못 하면 당신이 하는 모든 게 추측처럼 보입니다. 실제로는 아니더라도요.
피드백 처리는 지원자들이 가장 과소평가하는 항목입니다. 면접관은 최소 한 번은 끼어들고, 대개 당신이 이미 알던 내용으로 끼어듭니다. 기록되는 건 그 끼어듦이 당신을 방어적으로 만들었는지, 그리고 대화가 얼마나 빨리 일로 돌아왔는지입니다.
디버깅이 그들이 보고 싶어 하는 부분입니다
페어 라운드에는 거의 항상 코드가 예상대로 동작하지 않는 순간이 있습니다. 그 순간은 면접의 차질이 아니라, 흔히 면접의 목적입니다.
약한 버전은 출력이 맞아 보일 때까지 이것저것 바꾸는 것입니다. 강한 버전은 무엇도 건드리기 전에 가설을 세우는 것입니다. “카운트가 하나 많고, 루프가 0부터 n까지 포함이네요. 경계 문제인 것 같습니다. n이 1일 때로 확인해 보겠습니다.”
가설을 말하고, 그다음 검증하세요. 두 문장이면 반사가 아니라 방법을 보여준 것입니다.
처음 2분을 세팅하는 법
아무것도 쓰기 전에 세 가지를 소리 내어 하세요. 문제를 다시 말하고, 입력의 형태를 확인하고, 무엇부터 할지 말하는 것. 90초면 되고, 세션 전체의 분위기가 바뀝니다.
면접관에게 일찍 방향을 바로잡을 기회도 줍니다. 여지를 주면 대개 그렇게 해줍니다. 2분째의 방향 수정은 공짜지만, 같은 수정이 20분째에 오면 그 라운드를 잃습니다.
문제 설명이 모호하다면, 그 모호함은 보통 의도된 것입니다. 그에 대해 묻는 건 지연이 아니라, 가장 먼저 평가되는 항목입니다.
코파일럿이 들어갈 자리
Interview Copilot은 라운드를 실시간으로 따라가며, 상대가 아직 말하는 동안 화면에 구조를 띄웁니다. 그 질문이 실제로 무엇을 묻는지, 어떤 제약이 중요한지, 어떤 트레이드오프를 소리 내어 말할 가치가 있는지. 읽을 대본이 아니라, 당신이 자기 말로 말해 나갈 뼈대입니다.
FAQ
페어 프로그래밍 면접이란 무엇인가요?
퍼즐을 푸는 모습을 관찰당하는 대신, 면접관과 나란히 무언가를 만드는 라운드입니다. 면접관도 코드를 쓰거나 방향을 제안하거나 팀원 역할을 할 수 있습니다. 평가되는 것은 협업입니다. 설명하는지, 듣는지, 쓸모 있게 이견을 내는지, 받은 의견을 반영하는지.
페어 프로그래밍 라운드에서 실제로 무엇을 평가하나요?
당신과 함께 일하는 것이 생산적인지입니다. 구체적으로는 의도를 말로 설명하는지, 상대가 주는 것을 활용하는지, 그냥 따르거나 무시하는 대신 이유를 들어 반박하는지, 그리고 실시간으로 남이 읽을 수 있는 코드를 유지하는지입니다.
면접관이 틀렸다고 생각되면 반박해야 하나요?
네, 이유와 대안을 함께 제시하세요. “그렇게도 되지만 리스트를 한 번 더 훑습니다. 한 번에 끝낼 수 있을까요?”가 그들이 찾는 답입니다. 말없이 따르는 것과 말없이 무시하는 것 둘 다 점수가 나쁩니다.
타이핑은 얼마나 해야 하나요?
생각보다 적게. 평가 대상은 타이핑이 아니라 결정입니다. 길게 말없이 타이핑하는 구간은 아무 증거도 만들지 않으므로, 무엇을 왜 쓰고 있는지 계속 설명하세요.