미국 회사에 개발자 직군으로 지원한다고 생각하면 대부분 사람들이 제일 먼저 떠올리는건 아마
릿코드 (Leetcode) 나
해커랭크 (HackerRank) 같은 플랫폼을 통해 준비할수 있는
코딩 인터뷰 준비 일것 입니다. 구글, 페이스북/메타, 마이크로소프트, 아마존 같은 지원자가 많은 회사들은 특히 이런 코딩 문제 풀기 가 거의 정석 처럼 여겨 졌으니까요. 그리고 이런 형식은 AI 의 발전이 계속 진행 되고 있는 지금도 쉽게 바뀌지 않는 형태로 한참동안 남아 있을거라고 생각합니다. 하지만 많은 회사들이 점점 기존 코딩 인터뷰에서 다른 형식으로 바꾸고 있다는 이야기는 종종 들리고 하네요.
기술 인터뷰 형식만큼 중요한 인터뷰가 있는데 바로 Behavioral Interview 즉 '행동기반 인터뷰' 입니다. 행동 기반 인터뷰는 그 사람에 관해서 알수 있는 질문을 하는 질문을 토대로 하고 있습니다. 지원하는 포지션에 따라서 레벨에 따라서 질문들이 너무나도 다양해 질수 있지만 근본적인 질문은 같은 맥락을 가지고 있습니다. '이 사람이 우리 팀에서 이 포지션에서 일하기 적합한가?' 라는 질문이 그것입니다. 기술 인터뷰가 그 팀에서 실력으로 업무를 하기에 적합 한지를 테스트 한다면 행동기반 인터뷰는 사람으로서 팀의 구성원 으로서 그리고 회사의 구성원으로서 적합 한지를 알고자 하는 것입니다. 아무리 실력이 뛰어나더라도 너무 혼자 개인 플레이 하거나 무례하거나 문제를 일으키는 팀원이 들어온다면 누구나 반기지 않을테니까요.
언급한것 처럼 이 인터뷰 형태의 질문들도 코딩 인터뷰 처럼 몇개의 질문으로 정리하기는 불가능 합니다. 다만 그래도 가장 제일 자주 나오는 질문들을 나누어 봅니다.
Behavioral Interview ('행동기반 인터뷰') 예:
•
Describe a situation in which you were able to use persuasion to successfully convince someone to see things your way.→ 설득을 사용해 상대방이 당신의 관점을 받아들이도록 성공적으로 이끌었던 상황을 설명해 주세요.
• Describe a time when you were faced with a stressful situation that demonstrated your coping skills. → 스트레스가 많은 상황에서 당신의 대처 능력이 드러났던 경험을 설명해 주세요.
• Give me a specific example of a time when you used good judgment and logic in solving a problem.
→ 좋은 판단력과 논리를 사용하여 문제를 해결했던 구체적인 사례를 알려 주세요.
• Give me an example of a time when you set a goal and were able to meet or achieve it.
→ 목표를 세우고 그것을 달성했던 사례를 알려 주세요.
• Tell me about a time when you had to use your presentation skills to influence someone's opinion.
→ 프레젠테이션 능력을 사용해 누군가의 의견에 영향을 주어야 했던 경험을 이야기해 주세요.
• Give me a specific example of a time when you had to conform to a policy with which you did not agree.
→ 동의하지 않는 정책을 따라야 했던 구체적인 사례를 알려 주세요.
• Please discuss an important written document you were required to complete.
→ 작성해야 했던 중요한 문서에 대해 설명해 주세요.
• Tell me about a time when you had to go above and beyond the call of duty in order to get a job done.
→ 일을 완료하기 위해 기대 이상으로 헌신해야 했던 경험을 이야기해 주세요.
• Tell me about a time when you had too many things to do and you were required to prioritize your tasks.
→ 해야 할 일이 너무 많아 우선순위를 정해야 했던 경험을 이야기해 주세요.
• Give me an example of a time when you had to make a split-second decision.
→ 순식간에 결정을 내려야 했던 사례를 알려 주세요.
• What is your typical way of dealing with conflict? Give me an example.
→ 갈등을 해결하는 당신의 일반적인 방식은 무엇인가요? 사례를 들어 설명해 주세요.
• Tell me about a time you were able to successfully deal with another person even when that individual may not have personally liked you (or vice versa).
→ 상대방이 당신을 좋아하지 않거나(또는 그 반대) 그런 상황에서도 성공적으로 관계를 유지했던 경험을 이야기해 주세요.
• Tell me about a difficult decision you've made in the last year.
→ 지난 1년 동안 내렸던 어려운 결정에 대해 이야기해 주세요.
• Give me an example of a time when something you tried to accomplish and failed.
→ 시도했지만 실패했던 경험을 사례로 들어 알려 주세요.
• Give me an example of when you showed initiative and took the lead.
→ 주도적으로 행동하고 리더십을 발휘했던 사례를 알려 주세요.
• Tell me about a recent situation in which you had to deal with a very upset customer or co-worker.
→ 매우 화가 난 고객이나 동료를 상대해야 했던 최근의 상황을 이야기해 주세요.
• Give me an example of a time when you motivated others.
→ 다른 사람들을 동기부여했던 사례를 알려 주세요.
• Tell me about a time when you delegated a project effectively.
→ 프로젝트를 효과적으로 위임했던 경험을 이야기해 주세요.
• Give me an example of a time when you used your fact-finding skills to solve a problem.
→ 사실 조사 능력을 활용해 문제를 해결했던 사례를 알려 주세요.
• Tell me about a time when you missed an obvious solution to a problem.
→ 문제의 명백한 해결책을 놓쳤던 경험을 이야기해 주세요.
• Describe a time when you anticipated potential problems and developed preventive measures.
→ 발생할 수 있는 문제를 미리 예상하고 예방 조치를 마련했던 경험을 설명해 주세요.
• Tell me about a time when you were forced to make an unpopular decision.
→ 사람들에게 환영받지 못하는 결정을 내려야 했던 경험을 이야기해 주세요.
• Please tell me about a time you had to fire a friend.
→ 친구를 해고해야 했던 경험에 대해 이야기해 주세요.
• Describe a time when you set your sights too high (or too low).
→ 목표를 너무 높게(또는 너무 낮게) 설정했던 경험을 설명해 주세요.
행동기반 인터뷰는 언제 나오나요?
그럼 이런 질문들은 언제쯤 나올까요? 회사마다 포지션마다 그리고 인터뷰어 (Interviewer) 마다 각자 다른 방식을 가지고 있지만 오로지 '행동기반 인터뷰' 에만 집중하는 인터뷰가 있을수 있고 기술적 인터뷰 하는 시작이나 마무리 쯤에 나오는 행동기반 인터뷰 질문이 있을수도 있습니다.
처음 지원서를 넣고 통과가 되면 거의 100% 찬스로 HR 즉 인사팀에서 제일 먼저 연락이 오는데 대략 30분 동안 간단한 몇가지 '행동기반 인터뷰' 를 통해서 그 지원자를 다음 단계로 보내는걸 선택하기도 합니다. 저 같은 경우도 OpenAI 나 Figma 같은 회사에서 HR 담당자가 연락 왔을때 몇가지 질문을 통해서 다음 단계로 보낼지 결정하는걸 보았습니다. 특히 요즘 처럼 취업이 힘들고 지원자가 너무 많을때 그 많은 지원자를 일부 몇 퍼센트로 골라내는 역할을 HR 담당자에게 맡기는 비중이 늘어난것 같습니다.
'행동기반 인터뷰' 가 어김없이 빠지지 않고 등장할때는 주로 메니져나 비기술 직원과 인터뷰할때 입니다. 메니저들도 기술적인 부분을 잘 알수도 있지만 흔하지 않고 설마 그렇다 하더라도 실제 기술 인터뷰 부분은 다른 직원에게 맡기는게 더 일반적 이라고 볼수 있습니다. 아무래도 메니저가 더 중요시 보는건 이 새로운 직원이 팀에서 과연 맞는가를 평가하는 거니까요. 비슷하게 비기술 직원도 '행동기반 인터뷰' 질문들을 더 많이 한다고 볼수 있습니다.
행동기반 인터뷰에 성공하는 방법
'행동기반 인터뷰' 를 준비 잘해서 성공할수 있는 비결이 있을까요? 준비를 할수 있는 부분도 있지만 그 사람의 성격, 품기는 이미지, 그리고 경험이 많은 부분을 차지하는것 같습니다. 불공평하게 보이는것 같아 보일수 있어도 세일즈 즉 영업이나 사람을 대하는게 중요한 사람을 뽑는데 너무 내향적이거나 조용한 사람은 잘 맞지 않을수 있으니까요. 그리고 경험이 무엇보다 중요합니다. 예를 들어 위에 예시한 질문 중 하나인 "목표를 세우고 그것을 달성했던 사례를 알려 주세요." 에서 적잘한 경험이 없다면 완전히 지어내고 거짓말 하지 않는 한 '난 이럴거다' 라고 대답은 할수 있겠지만 그걸 내가 실제로 이랬다고 증명할만한게 부족 하니까요.
그래서 다양한 경험을 쌓는게 중요합니다. 인터뷰는 완벽한 과학이 아닙니다. 운도 중요하고 그 인터뷰의 그날 기분 혹은 편견도 무시할수 없는 부분입니다. 이전 회사에서 저보다 경험이 적었지만 나중에 시니어 메니저까지 쭉쭉 올라가는 분들을 보았는데 이 분들의 경력을 보니 프로젝트 메니저나 메니저로 일찍 갔었거나 좋은 경험을 일찍 얻는 기회를 획득하게 되는 분들이 많이 보였습니다. 그리고 다른 사람에게 좋은 평판을 가지고 있다는것. 그게 인상이나 말을 잘하는 것일수도 있구요.
행동기반 인터뷰엔 이게 무조건 정답이다 하는 방식은 없지만 제일 잘 알려진 STAR 방식에 관해서 설명하고 이글을 마무리 할려고 합니다.
행동기반 인터뷰 - STAR 방식
행동기반 인터뷰에서 제일 잘 알려진 방식은 Situation (S), Action (A), Task (T), Result (R) 합쳐서 STAR 이라고 합니다.
다음은 STAR 에 관한 정의 입니다.
STAR 인터뷰 방식이란?
STAR 인터뷰 방식은 지원자의 경험 기반 행동(Behavioral) 을 구조적으로 평가하기 위해 사용하는 인터뷰 기법으로, 지원자가 과거 실제 상황에서 어떻게 행동했는지를 S.T.A.R 네 가지 요소로 설명하게 합니다.
S – Situation (상황)
무슨 일이 일어났는지, 어떤 배경에서 발생한 상황인지 설명하는 단계.
→ “어떤 맥락이었는가?”
T – Task (과제)
당시 맡았던 역할, 책임, 해결해야 했던 과제를 설명하는 단계.
→ “당신이 해야 했던 일은 무엇이었는가?”
A – Action (행동)
문제를 해결하기 위해 실제로 취한 행동을 구체적으로 설명하는 단계.
→ “당신이 어떤 행동을 했는가?”
R – Result (결과)
그 결과로 무엇이 달성되었는지, 성과는 어떠했는지 설명하는 단계.
→ “결과가 어떠했는가? 무엇을 배웠는가?”
STAR 방식이 효율적인 이유는 아무래도 제한된 시간에 정확한 메시지를 설득력있게 전하기엔 어떤 형식이 필요한데 STAR 가 그 프레임워크를 제공하기 때문입니다.
아래는 STAR 의 간단한 예시 입니다.
Q: 갈등을 해결했던 경험을 말해 주세요.
- S: 프로젝트 일정이 촉박한데 팀원 간 역할 충돌이 있었음
- T: 중재 및 일정 재조정 필요
- A: 회의를 주도해 요구사항 재정리 → 역할 다시 배분 → 매일 10분 sync 회의 진행
- R: 예정일보다 하루 먼저 프로젝트 완료, 팀 분위기 개선
제 실제 경험을 통한 STAR 예시
아래 내용은 제가 실제로 답했던 '행동기반 인터뷰' 질문에 대한 대답입니다. 원본은 영어로 적었는데 번역앱을 통해서 한글로 번역한거에 대해서 양의를 부탁합니다.
질문: 상대방을 설득하는 데 성공했던 상황을 설명해 주세요 (Describe a situation in which you were able to use persuasion to successfully convince someone to see things your way)
⭐ SITUATION (상황)
In my previous role as a Senior Solutions Architect at GitHub, I was working with an enterprise customer whose business specialized in automotive industry automation. The customer had a multi-year, multi-product engagement with GitHub, so they heavily relied on automation scripts through GitHub Actions and other application integrations. To do that, they needed an authentication mechanism to invoke GitHub APIs and perform permission-related tasks.
During our weekly calls, I noticed the way they were handling authentication:
they created a mock GitHub account and generated a “super-user” Personal Access Token, which they used across many scripts and API calls. This was a dangerous practice. I tried to address the issue, but the customer felt comfortable because “it works fine.”
한국어 번역:
이전 GitHub 시니어 솔루션즈 아키텍트 역할에서, 저는 자동차 산업 자동화에 특화된 대기업 고객과 협업하고 있었습니다. 이 고객은 GitHub과 여러 해에 걸친 다양한 제품 계약을 맺고 있어 GitHub Actions와 여러 애플리케이션 통합을 통한 자동화 스크립트에 크게 의존하고 있었습니다. 이 과정에서 GitHub API 호출이나 승인 작업 등을 수행하기 위해 인증 메커니즘이 필요했습니다.
주간 미팅 중에 저는 그들의 인증 방식에 문제가 있음을 발견했습니다. 고객은 모의 GitHub 계정을 생성하고 ‘슈퍼 유저’ 권한을 가진 Personal Access Token(PAT)을 만들어 여러 스크립트와 API 호출에 공유하고 있었습니다. 이는 매우 위험한 방식이었습니다. 이 문제를 처음 제기했지만 고객은 "잘 작동하고 있으니" 불편함을 느끼지 못하고 있었습니다.
⭐ TASK (과제)
My task was to convince them to stop using Personal Access Tokens and switch to a more secure method—GitHub App tokens. However, this required additional maintenance responsibilities, so the customer was reluctant. But moving them in this direction aligned with their long-term security strategy.
한국어 번역:
저의 과제는 고객이 Personal Access Token 사용을 중단하고 훨씬 안전한 GitHub App 토큰으로 전환하도록 설득하는 것이었습니다. 하지만 GitHub App 방식은 유지보수 부담이 추가되기 때문에 고객은 처음에 매우 소극적이었습니다. 그럼에도 이 전환은 고객의 장기적인 보안 전략과도 맞닿아 있었기 때문에 중요한 일이었습니다.
⭐ ACTION (행동)
I approached this in several phases:
1. Understanding their reluctance:
I listened to why they resisted—current solution works, GitHub App requires additional maintenance, etc.
2. Researching and reinforcing facts:
I gathered evidence: vulnerabilities of PAT, benefits of GitHub App tokens, GitHub recommendations, other customer case studies. I shared the documents beforehand and walked them through the risks and benefits.
3. Bringing in more stakeholders:
I suggested discussing with more group leaders, and we brought in more engineers to evaluate concerns collaboratively.
4. Tailored demo:
Their biggest concern was maintainability. So I prepared a 10-minute demo showing that GitHub App tokens could be used without installing or managing a separate app.
The demo addressed their questions, and they loved it.
한국어 번역:
저는 다음과 같은 단계로 접근했습니다:
1. 변화에 대한 저항 이유 파악:
현재 방식이 잘 동작하고 있고, GitHub App 도입 시 유지보수 부담이 생긴다는 이유로 변화에 소극적인 점을 경청했습니다.
2. 사실 기반 자료 조사와 근거 강화:
PAT의 취약점, GitHub App 토큰의 보안적·운영상 이점, GitHub의 공식 권장사항, 다른 고객 사례 등을 조사해 문서로 제공하고 미팅에서 함께 검토했습니다.
3. 추가 이해관계자 참여 유도:
그룹 리더들과의 논의를 제안하고, 더 많은 엔지니어와 이해관계자를 모아 우려 사항을 함께 검토했습니다.
4. 맞춤형 데모 제공:
가장 큰 우려가 유지보수 부담이었기에, 별도 앱 설치 없이 GitHub App 토큰을 활용하는 10분짜리 데모를 제작했습니다.
고객은 데모를 매우 긍정적으로 평가했습니다.
⭐ RESULT (결과)
The engineers strongly supported the new approach, and the customer eventually adopted GitHub App tokens. After this win, they expanded their GitHub usage—GitHub Copilot pilots, GitHub App integrations, and more. It became one of my most successful customer engagements.
한국어 번역:
엔지니어들을 중심으로 새로운 방식에 대한 지지가 크게 늘었고, 고객은 결국 GitHub App 토큰 방식을 채택했습니다. 이 성공 이후 고객은 GitHub Copilot 도입, GitHub App 통합 등 더 많은 GitHub 활용을 확대했습니다. 이 프로젝트는 제가 진행했던 가장 성공적인 고객 사례 중 하나가 되었습니다.
그 외에도 여러가지 방식이 있겠지만 코딩 인터뷰 준비 에서도 꾸준한 준비가 중요한 것 처럼 '행동기반 인터뷰' 준비에서도 다양한 질문을 보면서 대답을 해보는 준비가 중요하다고 봅니다. 글을 읽어 주셔서 감사하며 조금이라도 도움이 되었길 바래요.
댓글 0
아직 댓글이 없습니다. 첫 댓글을 남겨보세요.