일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- pem
- DAU
- 정처기필기
- github
- 티스토리
- 패키지 관리자
- Wau
- classic retention
- 리텐션
- 클래식리텐션
- ssh-keygen
- passphrase
- range retention
- RPO
- N2TWinform
- MAU
- 롤링리텐션
- 파이프(|)
- GIT
- rolling retention
- 노션
- openssh
- RTO
- n2t
- stickiness
- 데이터리안
- 범위리텐션
- 하이퍼바이저
- dpkg
- 다중 암호화 키
- Today
- Total
TobeSteady
[정리] DA 구직관련 글 본문
출처 : https://derekgrey.tistory.com/8
출처의 내용을 계속 확인하고자 보다 짧게 편집할 뿐인 내용.
DA가 되는 나침반
"당신은 주체적으로 문제를 정의하는 사람인가요?
DA로서 데이터 속 인사이트를 발견하고, 액션으로 KPI를 개선한 경험이 있나요?"
회사에서 지원자에게 기대한 역할
주체적으로 문제를 정의하고, 데이터로 문제를 해결하는 사람.
그리고 비즈니스 성과를 만드는 사람
취업, 그리고 훌륭한 DA/DS가 되기 위해서 소프트/하드 스킬 모두 중요합니다.
하지만, 취업 이전에 본인이 어떤 목적을 가지고 데이터를 분석하고, 어떻게 회사 혹은 프로젝트에 기여를 하고 있는지가 가장 중요한 관문이라는 생각이 들었습니다.
01. 문제해결 능력
주체적으로 문제를 정의하고 데이터 속 인사이트를 발견할 수 있는 분석가.
발견한 인사이트를 문서화하여 내용을 효과적으로 전달하는 사람.
궁극적으로 비즈니스 임팩트를 만드는 사람.
주체적이지 않은 분석가는 도태됩니다.
- 여러분은 주체적으로 문제를 정의하고 계신가요? 반복적인 *Ad-hoc request 요청에서도 데이터 속 문제를 정의하고 해결하신 적이 있으신가요? 학생이라면, 프로젝트와 경진대회 속에서도 뻔한 코드와 프레임으로 분석하는 것이 아닌 해결하려는 문제를 명확하게 정의하고 분석을 하시나요?- 관습적으로 일한 내용에서도 제 분석과 프로젝트를 소개할 때 아래와 같은 구조로 업무를 하나씩 정리했습니다.
문제 정의 > 분석 > 인사이트 발견 > 레포트 > 액션 기획 or 알고리즘 구축 > A/B Test or 배포 > 결과 분석 > Cycle...
예를 들자면, 저는 강의 플랫폼 데이터 분석가 였기 때문에 강의 기획 MD 분으로부터 새로 오픈한 강의 구매자 성별, 연령, 구매자 수와 총 매출액을 요청받는 Ad-Hoc 리퀘스트를 받았습니다.
하지만, 저는 해당 강의 구매자들이 이전에 어떤 강의를 함께 구매했는지 궁금했습니다. 분석을 해보니, 인간관계 강의를 구매한 고객들은 요가/명상 강의도 함께 구매한 인사이트를 발견할 수 있었습니다.
해당 인사이트와 1+1 Package 및 Cross-Selling 전략에 대한 제언을 드렸습니다. 이를 통해, 과거에 오픈한 요가/명상 + 새로 오픈한 인간관계 강의를 함께 묶은 패키지 상품을 구축하였습니다. 이를 통해 매출액과 판매량을 증대시킨 경험이 있습니다.
뿐만 아니라, 후에 장바구니 분석 및 알고리즘을 활용하여 CRM 마케팅으로 CVR(구매전환율)을 개선시킨 경험이 있습니다.
*Ad-hoc 업무 : 특정 데이터 추출 솔루션(Google analyics와 같은 분석틀)로 알 수 없는 질문들에 대한 대답을 데이터 담당자에게 요청한다는 맥락
- adhoc ) 라틴어. "특별한 목적을 위해서"
- 남이 원하는 것이 무엇인지를 정확하게 캐치해야 한다는 부분에서 생각보다 어려운 업무.
02. A/B Test
여러분은 A/B Test를 얼마나 알고 계신가요?
A/B Test에 활용되는 통계적 지식과 세세한 모든 사항을 꼼꼼하게 알고 계신가요?
A/B Test에 활용되는 개념은 기초통계에서 사용되는 중요 지식들이 상당히 많이 포함되어 있습니다.
- 무작위 샘플링, 중심극한정리, 표준오차 등 단순 P-Value 만 알고 들어가면 되는 내용이 아닙니다.
- 데이터 분석가는 A/B Test를 기획부터 사후분석과 통계적 유의미성까지 판단하여 PM 혹은 의사결정자에게 의견을 전달할 줄 알 아야 합니다.
만약, 데이터 분석가로서 구직을 하고 계시다면 해당과 같은 질문을 본인에게 물어보면 좋을 것 같습니다.
1. P-Value 가 0.05 미만이면 모두 유의미한 결과인가?
2. 면접관에게 A/B Test 를 기획단계, 통계검정, 사후결과 까지 단계적으로 Report 해보는 면접 시뮬레이션을 추천드립니다.
03. SQL
너무 뻔한가요? 하지만, 진리는 언제나 뻔하다는것을 여러분은 알고 계시죠?
SQL을 평소에 잘 다루는 것과 SQL을 코테문제에 맞게 활용하여 문제를 푸는 것이 미세하게 다르다는 것을 알 수 있었습니다.
SQL 테스트에서 지원자에게 주어지는 시간은 굉장히 짧습니다.
회사마다 다르겠지만, 어떤 회사는 한 문제 당 10-15분을 주는 회사도 있습니다. 어떤 회사는 30분을 주는 경우도 있습니다. 시간과 비례하여 SQL 문제의 난이도는 올라갑니다.
예를 들어, N 회사는 DA/DS 에게 SQL로 알고리즘을 구축할 수 있는 능력 또한 요구했습니다. BI/DW 라면 해당 문제를 해결할 수 있는 방법을 빠르게 고민했겠지만 일반적인 DA 직무로 근무한 사람에게는 일반적인 문제 유형은 아니였을 것 입니다.
또한, C 회사는 SQL 로 라이브코딩을 보는 것을 선호합니다. 영어로 지문이 주어지고, 해당 문제를 짧은 시간 내에 해결해야 합니다. 영어가 익숙치 않은 사람은 아예 문제 해석 자체가 안되는 경우가 존재합니다. 이런 부분은 본인이 해당 회사와 Job Fit이 맞는지도 확인할 수 있을 것 같습니다. 나는 외국계 사람들과 소통하는데 문제가 없는 사람인가? 외국계 인재와 일하는게 맞는가?를 코테에서도 확인할 수 있는 기회라 생각됩니다.
빠른 실험문화를 자랑하는 T 회사는 짧은 시간내에 생각보다 어려운 문제를 냅니다. 지원자가 스타트업에서 많이 요구하는 분석방법, JD 기준으로 기술된 능력들을 쿼리로 빠르게 구현할 수 있는가? 를 평가합니다. 쿼리를 능숙하게 다룰 수 있는 사람을 우리는 DA로서 원합니다. 라는 것을 SQL 코테에서 알 수 있습니다.
코테를 통해, 많은 기업에서 DA에게 요구하는 능력은 SQL 함수(Between, CASE WHEN, Window 등) 을 잘 활용하는게 아니라, 여러분이 회사에서 DA에게 요구하는 JD를 SQL로 구현할 수 있는 능력을 갖춰야 합니다.
1. 여러분은 SQL을 얼마나 잘 다루시나요?
2. JD에서 요구하는 분석과 방법론을 SQL로 10분 이내에 구현할 수 있는 능력이 있으신가요?
3. 회사는 여러분이 실무에서 빠르고 정확하게 데이터를 분석하고 추출하길 원합니다. 우리의 요구사항을 여러분은 충족하실 수 있는 인재인가요?
Define yourself
본인을 정의하는게 중요합니다. 본인을 타인에게 소개할 때 어떻게 소개하실 껀가요?
여러분은 어떤 부분과 도메인에 장점이 있는 분석가인가요? 커리어의 목표는 무엇인가요? 이는 단순 면접을 대답하기 위한 질문이 아닙니다.
구체적일수록, 회사에서 오픈된 포지션과 자신을 매칭하며 본인에게 알맞는 자리를 찾아갈 수 있는 시간입니다. 본인의 강점과 지향점을 알고 자신과 잘맞는 회사를 찾는 것! 구직의 가장 중요한 시작점입니다.
- 구직의 Alpha와 Omega요. 모든것은 프로젝트 정리이다.
면접자는 여러분을 처음 보는 사람입니다. 여러분은 해당 문제에 대한 배경지식이 없는 사람에게 1-2개월의 사고력과 노력이 들어간 결과물을 1시간 이내에 전달해야 합니다.
면접이 만약 1시간이라면 자기소개, 지원동기, 아이스브레이킹, 역질문 등을 제외하면 사실상 40분정도의 시간이 남습니다. 그리고, 프로젝트 1-2개로 질문을 하다보면 대체적으로 1개 프로젝트 당 20분 정도의 면접이 소요됩니다.
프로젝트는 이 회사에서 여러분을 채용하고 싶게 만드는 포인트이자, 자신의 문제접근 방법과 사고력, 가치를 증명하는 시간입니다.
특히!
Q. 면접관 입장에서 이 프로젝트에서 왜 이렇게 문제해결을 접근했는지?
Q. 왜 이 알고리즘을 사용했는지?
Q. 해당 알고리즘의 장점과 단점은 무엇인지? 비슷한 알고리즘은 무엇이 있는지?
Q. 해당 알고리즘에 적용되는 통계적 방법과 손실함수 및 접근방법은 뭔지 알고 있는지?
Q. 개선을 위해 어떤 노력을 하셨는지?
등 면접관 시선으로 꼬리에 꼬리를 무는 질문들을 혼자 시뮬레이션 하시면서 많이 연습하셔야 합니다. 최대한 많이 할수록, 여러분은 본인이 원하는 직무와 회사에 가까워질 것 이란 걸 믿어 의심치 않습니다.
'ETC > ETC' 카테고리의 다른 글
이메일 인증 방법과 그 필요성 (0) | 2023.11.24 |
---|---|
[ETC] 이전 기록물이 담긴 Notion을 Tistory로 옮기는 과정 #최종 (0) | 2023.03.22 |
[ETC] 이전 기록물이 담긴 Notion을 Tistory로 옮기는 과정 #2 (0) | 2023.03.22 |
[ETC] 이전 기록물이 담긴 Notion을 Tistory로 옮기는 과정 #1 (0) | 2023.03.21 |
[ETC] 32bit(비트)와 64bit(비트) (0) | 2023.03.20 |