개발자 인터뷰 가이드

Aug 09, 2021

개발자 인터뷰 가이드

채용

고전적인 채용 절차

고전적인 채용 절차는 [채용공고] - [서류전형] - [면접] - [임원 면접]의 과정을 거친다.

고전적인 채용 절차의 문제

이력서 내용의 사실 여부 판단이 어렵다.
지원자의 코딩 실력을 알기 어렵다.
지원자가 많으면 너무 많은 서류를 검토해야 한다.
지원자당 긴 시간을 면접하게 되면 시간이 너무 많이 소비된다.
서술형 질문에 대한 답변을 암기해서 올 수 있다.
여전히 코딩 실력은 판단하기 힘들다.
비용이 발생한다.
지원자 성격에 따라 평소 실력을 발휘하지 못할 수 있다.

변하고 있는 채용 절차

기존처럼 채용공고는 이루어 지지만 지원자들이 접수하기만을 기다리는게 아니라 적극적으로 구직중인 개발자를 찾아(링크드인, 깃허브) 먼저 면접을 제의한다. 이렇게 함으로써 좀 더 직무에 안맞은 사람을 찾을 수 있다.
면접 이전에 코딩 테스트를 봄으로써 인력 비용을 최소화 하는 형태로 운영하고 이렇게 본 코딩테스트를 면접에서 다시한번 체크한다.이럴때는 문제를 푸는걸 중요하게 생각하는게 아닌 어떻게 풀었는지를 확인한다.
코딩 스킬뿐 아니라 협업능력도 체크하니 협업에서 본인이 어떤 역할을 했었는지 생각해두는것이 좋다.

대면면접의 구성

45분 면접에 15분을 휴식한다.
5분동안은 간단한 질문들로 시작한다.
15분까지는 소프트 스킬을 물어본다.
40분까지 하드 스킬 및 소프트 스킬을 검증한다.
45분까지 질문을 받는다.

채용공고 작성법

많은 잠재적인 동료가 공감할 수 있도록 작성한다.

구성

회사, 팀 업무 소개
필수 자격 요건 및 우대 사항
공지 및 지원 절차 안내

업무 소개시 원하는 인재상

고객중심의 업무, 코딩기술의 발전을 추구, 수평적인 문화 등 회사의 업무 분위기를 표현해주면 된다.

업무 소개는 간결하면서도 명료하게

단순히 시스템 유지보수, SI 등 애매모호하게 작성하면 안된다.
공공기관 홈페이지 개발 및 배포, 성능 및 구조 개선

기술 외적인 부분을 적어 지원자에게 안좋은 이미지를 주면 안된다.

사원들끼리 자주 워크숍을 간다던가 업무 외 활동에 관련된 내용을 적는다던가 하는것은 다수의 사람이 꺼리게 된다.
교육 지원비로 책 또는 온라인 강의를 지원 한다는 내용같은 복지부분은 좋게 작용할 수 있다.

이력서 검토

확인할 내용

경력 및 이력이 채용 공고의 필수 자격 요건에 준하는지 확인
이력서에 기술 및 경험을 구체적으로 서술하고 있는지 확인
회사 또는 팀에서 추구하는 중요한 가치가 드러나는 경험이 적혀있는지 확인

주의사항

편견에 주의할 것
이력서에 적힌 기술, 경험 및 가치관 이외에 사항은 철저히 무시한다.
블로그 또는 깃헙으로 편견을 가지면 안된다. 개발자가 좀 더 자신을 드러내고 싶을 수 있다 정도이지 절대적일 수 없다.
전공 학과 또한 편견이다. 요즘은 여러 교육기관이나 독학으로도 충분히 잘 할 수 있는 개발자들이 있다.

구직

면접 준비

평소에 준비하지 않았다면 3개월 정도가 필요하다.

자료구조와 알고리즘 공부
매일 코딩 퀴즈 최소 한 문제씩 풀기
예상 질문(본인이 주로 사용하는 기술)에 대한 답변 준비하기
프로그래밍 관련 서적 꾸준히 읽기(이펙티브 자바, TDD, 객체지향, 리팩토링 등)
코딩

자료 구조와 알고리즘

Big O
배열, 리스트, 스택, 큐, 해시 테이블, 힙, 트리 등의 자료 구조
정렬 알고리즘(외우는게 아니고 이해를 해야한다.)
본인이 사용하는 언어의 콜렉션즈
BFS, DFS(순회 알고리즘)

면접 실전

이력서

개인정보는 요구하지 않는다면 적지 않는다.(편견을 줄 수 있어 -가 될 수 있다.)
프로젝트 경력은 자세하게 적는다.(제목만 적으면 뭘 했는지 알 수 없다.)

면접 질문에 답하기

동료와 애기하듯 편안하고 솔직하게
실제 경험했던 사례를 구체적으로 설명한다.
근거를 들어 논리적으로 설명한다.

코딩 인터뷰

아는 문제일 경우 : 좋은 내색을 구지 할 필요는 없다. 절차에 맞게 풀이를 한다.
모르는 문제일 경우 : 흔히 있을 수 있으며 업무 중에도 모르는일이 있을 수 있기 때문에 당황하지 말고 대처를 잘 해야한다. 절차에 맞게 진행하면서도 면접관에게 질문하면서 풀이를 찾아간다. 코딩 인터뷰는 같이 풀이를 한다는걸 잊으면 안된다. 만약 자신있다고 면접관의 질문을 무시한다면 협업에 문제가 있다고 생각할 수 있다.

면접 결과

결과가 좋지 않다면 실망할 필요가 없다. 기회는 많고 일자리도 많기 때문에 이번 면접을 통해 배운것을 정리하고 경험많으로도 큰 이득이다.

연봉협상

기본급
사이닝 보너스(이직 보너스) : 거의 없으니 기대하지 않는다.
성과급 : 내규를 따르기 때문에 바꿀 수 없다.
주식
스톡옵션(주식을 살 수 있는 기회를 준다.)
ESPP(사내 주식 저렴하게 살 수 있는 프로그램)

희망 연봉을 제시할 때 이전 직장의 연봉이 아니라 지원한 회사의 직급별 평균 연봉을 참고한다.

사람인
외국
연봉비교

연봉은 이직할 때 크게 올릴 수 있어도 매년 하는 연봉협상에선 크게 올릴걸 기대할 수 없으니 최대한 올려서 받아야 한다.

계약전 확인사항

본인에게 잘 맞는 부서인지 회사인지 확인해야한다.

구체적으로 본인의 직무가 어떻게 되는지 확인한다.
부서에서 본인이 같이 일을 하게 될 동료 구성
운영 업무와 개발 업무의 비중
하루 일과

이직 후 업무 적응

팀에 적응하는 속도가 빨라야 중요한 일을 맡을 수 있다.

생소한 키워드를 문맥별로 모아서 물어볼 것(기술적인 용어가 아닌것도 많으니 물어보는것이 좋다.)
간단한 질문이 아니라면 30분 ~ 1시간 가량 미팅을 잡는게 좋다.
처음부터 너무 많은 정보를 파악하려고 하지말고 나눠서 정복하는 전략을 사용할 것.

긍정적인 피드백을 받도록 노력해야 한다.

기술적인 다양성과 포용력일 키울 것
맡은 업무에 대한 책임감
결과를 만들어 내려고 최선을 다할 것
장기적으로 또는 단기적으로 개선하고 싶은 것들을 정리해서 공유

핵심역량

핵심역량 파트에서 가장 중요한건 거짓말을 하면 안된다는 것이다. 이 파트의 내용들을 모두 정리했더라도 본인이 했던것들을 거짓으로 말한다면 꼬리에 꼬리를 무는 질문에 결국 탄로날것이고 오히려 역효과가 될 것이다.

고객중심

고객 중심적인 사고를 가지고 일하는지 확인

고객의 이슈 파악 및 해결
고객의 요구 파악 및 기대치 만족 또는 뛰어 넘기
꼭 기업 외부 고객일 필요는 없고 사내 다른 팀의 직원도 고객일 수 있다.

고객 중심 역량 파악 질문 예

외부 또는 내부 고객의 요구를 만족 시켰던 서비스를 제공한 경험이 있나요?
또는 반대로 외부 또는 내부 고객의 기대에 만족하는 서비스를 제공하기 힘들었던 경험이 있나요?
고객이 가지고 있는 문제를 해결하는 업무를 해본 경험이 있나요?

후속질문

어떻게 해당 업무에 참여했으며 결과는 어땠는지?
(성공적이었다면)그 업무가 성공적일 수 있었던 핵심적인 이유는?
(실했었다면)다시 그런 업무를 하게 된다면 어떻게 다르게 접근할 수 있는지?

좋지 못한 답변 특징

해당 경험이 없어 사례를 제공하지 못한다.
해당 업무에 적극적으로 참여하지 않았다.
스스로 고객의 이슈를 해결하지 못하고 도움을 받거나 다른 팀원에게 일을 넘겼다.

좋은 답변 특징

책임감을 가지고 주기적으로 고객의 요구와 이슈를 파악하려는 시도를 했던 경험이 있다.
고객의 요구와 기대를 조사하기 위한 피드백 시스템을 구축하거나 운영했다.
고객의 요구와 기대를 조사해 제품이나 서비스에 적용한 경험이 있다.

결과 도출

비지니스에 필수적으로 필요한 업무에 집중하고 적절한 품질과 기간 내에 결과를 만들어 내는 역량

문제를 효율적으로 해결할 것
책임감을 가지고 일할 것
비지니스에 필요하며 도전적인 업무를 맡을 것.
동료가 신뢰할 수 있는 행동을 할 것

결과 도출 역량 파악 질문 예

프로젝트 목표를 달성하기 어려웠던 경험에 대해 설명해 주세요.
장기적인 프로젝트에서 오너쉽을 가지고 일한 경험이 있는지? 각각의 마일스톤을 제때 맞추기 위해 어떤 노력을 했었나요?
도전적인 프로젝트였지만 동료들과 함계 해낸 경험이 있나요?

후속 질문

해당 프로젝트에는 어떻게 참여하게 되었나?
과정중에 생긴 문제점을 어떻게 해결했는지?
다시 돌아봤을 때, 어떤 점 때문에 해당 프로젝트를 성공적으로 마무리 할 수 있었는지? 아니면 다르게 시도해 보고 싶은 것이 있는지?

좋지 못한 답변 특징

주도적인 다른 동료의 지시에 따르기만 한 경우
충분한 회의나 분석을 거치지 않고 문제 해결을 시도하는데 급급한 경우
프로젝트 또는 업무의 기한을 맞추는데 필요한 중요한 의사소통의 결여

좋은 답변 특징

예정됐던 일정 안에 긍정적인 결과를 만들어 낸 경우
문제를 해결하는데 필요한 정량적인 데이터를 수집해 본 경험
목표를 달성하는데 필요한 업무를 주관적으로 제안하고 실행에 옮긴 경험
지속적으로 목표 달성에 필요한 데이터를 모니터해 본 경험

영향력

다른 동료 또는 팀을 설득하고 좋은 영향을 주는 능력

커뮤니케이션을 효율적이고 논리적으로 하는 능력
긍정적인 관계 형성으로 업무 효율을 높이는 능력

영향력 파악 질문 예

업무를 위해 누군가를 설득하거나 당신의 입장을 이해시켜야하만 했던 경험이 있나요?
같이 일하는 동료와의 좋은 관계 형성으로 프로젝트에 긍정적인 영향을 끼친 경험이 있나요?
다양한 견해를 가지고 있는 주요 관계자들의 요구를 성공적으로 만족시킨 경험이 있나요?
동료나 다른 팀을 설득해 프로세스를 개선해야 했던 경험이 있나요?

좋지 못한 답변 특징

설득에 필요한 정량적인 데이터를 활용하지 못한 경험
주요 관계자와 신뢰를 쌓지 못한 경험
개인 관심사를 중심으로 업무를 진행한 경험
비효율적이거나 논리적이지 않은 방법으로 관계를 형성하려 했던 경험

좋은 답변 특징

데이터를 근거삼아 설득한 경험
주요 관계자와 강한 신뢰를 쌓은 경험
주요 관계자들의 견해와 입장을 이해하고 그런 이해를 바탕으로 업무에 도움을 준 경험
설득을 통해 본인의 팀 또는 다른 팀까지 좋은 영향을 주었던 경험

적응력

변화하는 환경에 효율적으로 반응하는 능력

끈임없이 탐구하고 학습한다.
스트레스가 심한 상황에서도 건설적인 자세를 유지한다.

적응력 파악 질문 예

조직 개편 (새로운 팀장이 오거나, 팀을 이동하거나) 등으로 스트레스를 받았던 경험이 있나요?
업무 처리 방법에 변화를 시도했던 경험이 있나요?
가이드나 정보가 거의 없이 시작했던 프로젝트를 완료했던 경험이 있나요?

부적절한 답변

스트레스를 잘 처리하지 못한 경험
정보가 부족한 경우 비효율적으로 일을 처리한 경험
변하는 상황에 맞추려는 노력이 부족했던 경험

적절한 답변

변화하는 상황에 효율적으로 또는 즉각적으로 대응했던 경험
정보가 부족한 경우에도 효율적으로 일을 하거나, 그 자체를 새로운 기회로 삼았던 경험
스트레스가 심한 상황에서도 건설적인 자세를 유지했던 경험

판단력

여러 대안과 관점을 고려하여 결정

해결하려는 문제의 볌위를 정의한다.
가정하지 않고 근거를 가지고 증명한다.

판단력 파악 질문 예

업무에서 치명적인 실수를 했던 경험이 있나요?
여러가지 대안이 있는 상황에서 어떤 과정을 통해 가장 적절한 방법을 선택했나요?
복잡했던 문제를 해결하기 전에 필요한 지식을 습득해야 했던 경험이 있나요?

부적절한 답변

여러 대안을 충분히 검토하지 않고 결정했던 경험
서두르거나 충분한 정보없이 섯부른 판단을 했던 경험
동료 또는 다른팀의 도움이 필요한 상황인데도 도움을 요청하지 않았던 경험

적절한 답변

판단에 필요한 정보를 다양한 방법으로 수집하고 검토한 다음 결정했던 경험
필요한 정보를 기반으로 적절한 시간 내에 좋은 판단을 했던 경험
필요한 상황에서 적절한 도움을 요청했던 경험

협업

동료 또는 다른 팀간의 팀웍 또는 공조를 통해 업무를 해내는 능력

여러 동료 또는 팀의 리소스와 노력을 조합하여 일을 한다.
개인의 목표가 아닌 공동의 목표를 달성하려 노력한다.

협업 파악 질문 예

치명적인 이슈를 해결하는데 필요한 다른 팀과 같이 일헀던 경험이 있나요?
여러 팀이 함께 일해야 했던 프로젝트가 잘 돠지 않았던 경험이 있나요?
동료와 마찰이 생겼던 경험이 있나요?

부적절한 답변

협업이 필요한 상황에서 최소한의 기여만 했던 경험
요청 받은 경우에만 협업했던 경험
협업을 증진시켰던 좋은 사례를 들지 못하는 경우

적절한 답변

협업에서 의미있고 중요한 업무를 했던 경험
필요한 경우 헙엽을 제시하거나 주도했던 경험
협업을 증신시켰던 좋은 사례를 제시한 경우

STAR 프레임워크

S(Situation): 어떠한 상황에서 T(Task) : 어떤 업무를 하거나 또는 목표를 달성했는지 A(Action) : 본인이 무엇을 어떻게 했는지 R(Result) : 결과는 어떠했는지? 실패했다면 배운것은?

면접관에게 질문하기

면접이 끝나기 전에 면접관에게 궁금한 것을 물어볼 수 있는 시간이 주어진다.

좋은 질문을 남기면 면접관의 인상에 남는다.
여기서도 핵심역량을 드러낼 수 있다.

좋은 질문의 예

이곳에서 일하며 배우거나 경험한 가장 중요하거나 가치있는 것은 무엇인가요?
이 회사 또는 팀에서 현재 직면한 기술적인 이슈는 무었인가?
새로운 팀원이 합류하면 업무 적응은 어떤식으로 이루어 지는지? 참고할 문서가 있거나 멘토가 있는지?
사외 또는 사내 고객과 주기적인 회의나 모임을 갖는지? 고객과 어떤 방법으로 소통하는지?
어떤 업무의 해결책이 여러개일 때 어떤 과정을 통해 결정하는지?
일정은 그대로인데 프로젝트의 요구사항이 계속 바뀐적이 있는지? 이 팀이나 회사에서는 보통 어떻게 대처하는지?

나의 질문

프로젝트가 시작되면 일정은 어떻게 관리되는지? 기존회사는 WBS 엑셀 문서를 통해 관리하였다.
일정을 진행하면서 클라이언트의 요구사항이 변화가 생길 경우 어떻게 해결되는지 이런 고객과의 의논을 개발팀에서 직접하는지 한다면 메일로? 직접 만나서? 전화로?
이직을 하게 된다면 인수인계를 위한 문서나 멘토가 있는지?
기존에는 서버나 DB, 산출물들을 직접 관리했는데 관리해주는 사람들이 따로 있는지?
학습을 위해 지원을 얼마나 해주는지?
주요하는일의 특징은?

코딩 인터뷰

일반적인 환경에서 코딩 -> 손코딩 -> 입으로 설명하면서 코딩 순으로 연습한다.
개발환경에서도 못하는 코딩이 갑자기 손으로 써지지는 않는다. 인터뷰에서 설명을 해야하기 때문에 입으로 설명하는 연습도 빼먹으면 안된다.
문제를 보고 다짜고짜 문제부터 푸는게 아닌 문제에 대한 정의를 내리고 어떤 절차로 진행할지 설명한 후 문제를 푸는것이 좋다. 문제를 푸는 중 해결이 되지 않을 때 면접관이 힌트를 제공한다면 그 힌트를 이용해서 어떻게 적용시킬지 대답해주어야 한다.

코딩 인터뷰 프레임워크

문제를 해결함에 있어 면접관과 인터뷰를 한다는 느낌보다는 동료와 같이 해결한다는 관점으로 접근해야하고 문제를 푸는 주체가 본인이라고 생각해야한다. 중요한건 동료이기 때문에 같이 풀어나간다고 접근해야한다.

가장 먼저 해당 문제를 정리하고 본인이 이해한것이 맞는지 면접관에게 확인한다.
입력, 출력 범위, 타입같은것 등 문제에서 명확하지 않은것을 체크한다.
위에 내용들을 실제 예를 들어가며 다시 한번 체크한다.
이제 문제에 대한 고민을 하고 어떤 방식으로 구현할지 결정한다.
해당 로직을 설명하고 해당 시간과 공간 알고리즘 복잡도를 설명
로직대로 코드를 작성한다.
3번에 예시를 케이스로 테스트한다.

알고리즘 복잡도

빅 오 노테이션: O(n), O(logN), O(1), O(n제곱)

함수에서 엄밀한 점근적 상한을 나타내는 표기법
수자는 다 빼고 가장 증가율이 높은 수식만 남긴다.
f(n) = 4 O(1)
f(n) = 3n + 3n + 3 O(n)
f(n) = 8n제곱 + n + 3 O(n제곱)
f(n) = 8n + log(n) +3 O(n)
O(1)은 여러개의 매개변수가 들어와도 리턴값이 고정되는걸 의미한다.
O(n)은 매개변수가 들어오는거에 비례하는 리턴값을 의미한다.
O(n제곱)은 주로 2중 포문같은것을 의미하는데 면접관은 이런 코드를 바라지 않을 확률이 높으므로 이런방식으로 답을 구하려 한다면 다시 생가해보는것이 좋다.
매개변수가 배열인 함수에서 리턴값이 고정된 인덱스 값을 호출한다면 이건 시간복잡도가 O(1)이고 메모리에 변화가 없기 때문에 공간복잡도도 (1)이다.
숫자 배열이 들어와 합을 구하는 함수라면 같은 반복문을 계속하기 때문에 시간 복잡도는 O(n)이고 더하면서 하나의 변수에만 값을 저장하기 때문에 공간복잡도는 O(1)이다.
재귀함수의 경우 반복문이 없어도 계속 본인을 호출하기 때문에 시간복잡도가 O(n)이고 재귀함수는 스택영역을 사용하기 때문에 메모리를 계속 사용하여 공간복잡도 또한 O(n)이다.
숫자 배열에서 특정 숫자를 찾기위해 보통 바이너리 서치를 사용하는데 이는 가운데 인덱스를 가져와 특정값과 비교하고 작다면 -1을 크다면 +1을 하여 총 인덱스에 절반씩 버려가며 찾을 수 있다. 이런 바이너리 서치의 경우 절반씩 날라가기 때문에 시간 복잡도가 O(logN)이다. 공간 복잡도의 경우 들어오는 값에 상관없이 저장용 변수만 선언되므로 O(1)이다.

간단한 예제

매개변수를 인트형 List로 받는데 해당 리스트에는 같은 숫자가 2개씩 있는데 오직 하나의 숫자만 한개가 있다. 하나만 있는 숫자를 리턴한다.
기본적으로 매개변수를 반복시키기 때문에 n이 존재하고 또 새로생성한 리스트에 해당 데이터가 있는지 검사하면서 반복을 하기때문에 n이 존대한다. 그래서 시간복잡도는 O(n제곱)이다.
공간 복잡도의 경우에도 해당 매개변수 리스트에 같은 숫자들이 연속으로 나온 전제가 없으므로 한번에 몇개까지 리스트에 데이터가 들어갈지 모르므로 O(n)이다.
하나의 리스트를 선언하고 매개변수로 넘어온 리스트를 반복하면서 새로 생성한 리스트에 반복문으 숫자가 들어있다면 제거하고 없다면 숫자를 추가해준다. 이렇게 반복하다보면 같은숫자들은 같은숫자가 나올경우 제거되기 때문에 하나만 있는 숫자만 리스트에 남게된다. 만약 같은 문제를 맵으로 한다면 맵의 키를 해당 리스트이 숫자로, 맵에서 해당 키가 있다면 값을 불러와 +1해주어 해당 숫자의 카운트를 값으로 넣어준다.
이럴경우 시간복잡도는 리스트와는 다르게 맵은 반복하는 형태가 아니므로 O(n)의 방식이고 공간복잡도는 여전히 매개변수에 따라 맵의 크기가 변하므로 O(n)이다.
마지막으로 xor를 활용하는 방법이 있다. xor같은 경우 같은 숫자라면 0으로 0과 다른숫자라면 원래대로 보여준다. 그렇기 때문에 하나의 변수만 선언해서 작업을 완료할 수 있다. 반복문을 사용하기 때문에 시간복잡도는 여전히 O(n)이지만 공간복잡도의 경우 O(1)이다.

배열

배열은 연속된 메모리 영역에 저장된 데이터로 조회가 O(1), 추가 및 삭제가 O(n)의 복잡도를 가지고 있다. 조회는 빠르고 추가 및 삭제는 느리다.

자바에서 배열은 만들 때 크기를 정해야 하며, 추가 및 삭제 기능은 없다.
다른 자료구조를 구현하는데 사용하는 가장 기본적인 데이터 구조다.

배열문제는 우선 정렬이 되어있는지 체크한다.
인트형 배열에서 같은 숫자가 하나라도 있다면 true를 리턴해주는 문제가 출제되었을때 i,j로 2중포문으로 해결한다면 시간복잡도는 O(n제곱), 공간복잡도는 O(1)이다. 하지만 O(n제곱)의 형태는 출제자가 원하는 방향이 아닐 확률이 높으므로 다시한번 생각해보는게 좋다.
Arrays.sort를 사용하여 정렬을 한다면 구지 반복문을 2번할 필요없이 현재인덱스 값과 다음인덱스 값만 검색해도 답이 명확해진다. 반복문을 2번하는것보다 Arrays.sort를 사용하는것이 시간복잡도에서 이득이니 정렬한 뒤에 문제를 풀자
또 다른 방법으로는 set을 사용하는것이 있는데 set은 중복을 허용하지 않고 시간복잡도가 O(1)이다.

실습 소스코드

리스트

자료구조에서 리스트와 자바의 컨렉션즈의 리스트와는 조금 다르다. ArrayList는 개념적인 배열과 비슷하다. 배열은 사이즈가 고정되고 리스트는 크기가 동적으로 알아서 조절된다.
Vector와 ArrayList는 배열기반의 리스트이고 링크드 리스트는 노드기반의 리스트이다. Vector은 하나의 쓰레드만 접근할 수 있고 ArrayList는 여러 쓰레드가 접글할 수 있어 성능적으로 더 빠르고 자주 쓰인다.
ArrayList는 index기반이다. ArrayList에 데이터를 추가할 때 배열처럼 추가된다면 새로운 데이터를 추가할때 공간을 만들어주기 위해 새로운 List를 추가하여 복사하는일이 벌어질탠대 이러면 O(n)이 되지만 ArrayList는 처음 생성될때 여유공간을 만들어 놓기 때문에 O(1)방식으로 처리할 수 있다. 다만 중간의 index에 값을 넣어줘야 한다면 무조건 O(n)이 된다.
삭제의 경우도 배열이라면 중간에 삭제한 공간을 없에기 위해 다시 리스트를 만들어줘야 겠지만 ArrayList는 중간에 비어있는 공간을 두고 나중에 한번에 작업하기 때문에 O(1)이다.
ArrayList의 조회는 get을 이용할 경우 index를 사용하기 때문에 O(1)이고 contains를 사용한다면 값을 찾아 비교해야 하기 때문에 모든 데이터를 조회하므로 O(n)이다.
링크드 리스트는 개념적인 Index는 있지만 실제로는 Index는 없다. 그럼에도 index로 데이터를 가져오는것은 처음 데이터에서 해당 index만큼 연결된걸 추적해서 가져오는것이다. 만약 100번째를 가져온다면 100번 이동 후 가져온다. 그렇기 때문에 링크드 리스트는 조회가 O(n)이다. 하지만 중간에 새로 추가하거나 삭제하는 경우는 양쪽 데이터에 이어진 링크만 바꾸면 되므로 O(1)이다. 하지만 마지막 인덱스에 넣을 경우 모두 조회를 하기 때문에 O(n)이 될 수 있다. 이렇게 이론적으로는 O(1)이지만 프로그램에서는 사용자가 Node를 모르기 때문에 값으로 조회해야하기 때문에 결국 O(n)이 될 수 밖에 없다.

스택

리스트와 비슷한 구조이지만 데이터를 입출력하는 쪽이 한군데라는점이 다르다. FILO의 특징을 가지고 있다.
데이터를 넣는 작업을 push라고 하고 꺼내는것을 POP이라 한다. 현재들어가 있는 데이터 수를 peek 또는 top이라 한다. 데이터가 추가되면 top을 새로온 값으로 설정하고 pop이 되면 해당 데이터를 보여주고 그 아래 데이터를 top으로 변경해주면 된다.
java에는 stack를 제공하지만 Deque를 사용할것을 권장하고있다.

개발자 인터뷰 가이드