인터뷰 시 프로젝트 경험을 어떻게 소개하나요?

"둘째, 프로젝트에 대한 세부 사항을 묻는다면 그것은 한 번도 해본 적이 없다는 뜻입니다."

일반적으로 인터뷰 전에 모두가 프로젝트 설명을 준비해야 합니다. 이 부분에 대한 최종 결정권은 당신에게 있기 때문에 연설에 더 자신감을 갖고, 완벽하게 준비한 후에 말하고 싶은 내용을 알 수 있기 때문에 더 유창하게 말할 수 있습니다. 그리고 이것은 실제 프로젝트 경험(학습 경험이나 훈련 경험이 아님)이므로 면접관이 말조차 할 수 없다고 느끼면 신뢰도가 매우 낮아질 것입니다.

많은 사람들이 "프로젝트에서 어떤 사업을 했는지, 코드 구현의 세부 사항"에 갇혀 있는데, 이는 면접관에게 직접 후속 질문을 할 수 있는 권한을 주는 것과 같습니다. 아래 표에는 몇 가지 잘못된 답변 방법이 나열되어 있습니다.

위에서 언급한 잘못된 답변을 피하면서 표에 제시된 요소를 기반으로 프로젝트 소개를 준비할 수 있습니다. 가능하다면 영어로 설명도 준비해주세요. 사실 갓 졸업한 사람이나 경력이 적은 사람도 영어 실력이 비슷한데 말씀하신 것처럼 질적인 향상이 있는 것 같아요.

면접 전에는 준비와 자신감이 있어야 하지만, 다음과 같은 상황도 피해야 합니다.

"셋째, 면접관이 듣고 싶어하는 말을 흔적도 남기지 않고 말하라"

프로젝트 소개(물론 후속 인터뷰도 포함)에서 면접관은 실제로 듣고 싶어하는 말을 오랫동안 핵심 내용을 말하고 관련 질문에 잘 답해 준다면 이는 확실히 장점이 됩니다. 다른 사람들을 인터뷰할 때 이러한 핵심 사항이 확인되면 반드시 리뷰에 코멘트를 추가하겠습니다.

다음은 면접관들이 듣고 싶어하는 5가지 핵심 포인트와 그에 따른 수사법입니다.

"넷. 적극적으로 임하세요. 면접관이 하이라이트를 캐낼 의무는 없습니다."

인터뷰에 가면 저는 종종 질문을 합니다. 프로젝트의 하이라이트가 무엇인가요? ? 아니면 후보자로서 이 직책에 성공적으로 지원하는 데 도움이 되는 다른 보너스 포인트는 무엇입니까? 이렇게 물어봐도 어떤 사람들은 직접적으로 아니라고 대답할 것이다.

이 질문을 할 때 이미 잘못된 역할을 하고 있습니다. 면접관으로서 질문을 기다리기보다는 먼저 발언해야 합니다. 하지만 일반적으로 말할 때는 능숙해야 하며 말할 기회를 찾아야 합니다. 개방형 질문으로 설명하세요.

예: 이 프로젝트에는 어떤 기술이 사용되었나요? Spring MVC, MyBatis 및 기존 데이터베이스 기술과 같은 몇 가지 기본 기술에 대해 이야기하는 것 외에도 가상 머신 메모리에 대한 부담을 줄일 수 있는 Java 메모리 관리의 사용이나 빅데이터의 사용에 대해서도 언급해야 합니다. 처리 기술 등 즉, 현재 매우 인기 있는 기술에 대해 이야기할 수 있는 모든 기회를 찾아야 합니다.

또는 다음과 같은 질문과 같이 확장된 설명을 위한 관련 질문을 찾으세요. 일대다 및 다대다를 사용해 본 적이 있나요? 기본 지식 포인트 외에도 일반적으로 필요에 따라 캐스케이드 및 역 키워드를 적절하게 설정한 다음 실제 사례를 사용하여 프로젝트에 대한 합리적인 디자인의 도움을 설명하여 확장할 수 있다고 말할 수도 있습니다. 설명 실력이 늘었어요. 반대로 말하지 않으면 면접관은 분명 단순한 일대일, 일대다 연산밖에 할 수 없다고 생각할 것입니다.

면접에서 지원자가 질문에 아주 간단하게 답변하거나, 할 말이 한 가지만 확장되지 않거나, 질문에 매우 인색한 문장으로 답변하는 경우에는 대개 깊이 있게 이야기할 기회를 제공합니다. 보장 모든 면접관이 깊이있는 질문을하는 것은 아닙니다), 대답이 간결하면 좋은 의견을 제시하는 데 인색합니다.

❝

기억하세요: 면접관은 귀하의 친척이 아니며, 면접관은 매우 바쁘고, 귀하의 하이라이트를 파헤칠 수 있는 면접관이 거의 ​​없으며, 귀하의 하이라이트를 말하는 것은 귀하의 의무입니다.

❞

나는 다른 사람들을 인터뷰하는데, 보통 다양한 상황에 따라 다음과 같은 의견을 제시합니다.

1. 답은 매우 간단하지만 그 대답은 그가 실제로 프레임워크 및 기타 기술에 대해 뭔가를 했다는 것을 증명할 수 있습니다. "나는 프레임워크에 대해 전반적으로 이해하고 있지만 일부는 모릅니다. -깊은 지식(질문을 너무 많이 했습니다.) 매번 아주 간략하게 답변해주셔서 죄송합니다. 이렇게밖에 쓸 수가 없네요. 정말 기술적이시겠지만 할 수 있는 일이 없을 것 같습니다. )"라고 말하면서 동시에 "나는 표현력이 풍부하다"고 덧붙였다. 일반적으로 의사소통 능력이 뛰어나지 않은 편이다. 그래서 기술 면접을 통과하더라도 후속 인터뷰가 어렵다.

2. 답은 매우 간단합니다. 이 기술을 프로젝트에서 했는지, 아니면 그냥 일상 공부에서 배웠는지 확인할 수 없습니다. "이력서에는 XX기술을 사용했다고 적혀 있는데, 자세한 내용은 알 수 없고, 해당 기술이 해당 업무에 꼭 필요한 것인지는 알 수 없습니다."라고 적었습니다. , 그렇다면 그가 인터뷰에 합격할 가능성은 아주 적습니다.

3. 답변은 아주 간단하고, um, ah 같은 기능어로만 대답합니다. 상기시킨 후 몇 가지 형식적인 단어로 인터뷰를 마무리하고 "기술이 매우 약하고 저는 면접에 합격하지 못할 것 같아요."

4. 그의 실력을 잘 보여줄 수 있는 답변이지만 논리가 명확하지 않으면 기술 면접을 통과하게 하겠지만 "실력은 매우 좋지만 표현력은 보통 수준입니다(또는 개선이 필요합니다)), 차후 면접 매니저를 고려해 주시기 바랍니다." 이처럼 후속 종합면접에서는 합격 확률이 평균입니다. 결국 종합면접에서는 표현력, 의사소통 능력 등 비기술적 요소를 중점적으로 보게 됩니다.

"어쨌든 간단하게 대답하고 자신이 잘하는 것이 솔선해서 말해주지 않거나, 하이라이트를 명확하고 체계적으로 말하지 않으면, 면접에 합격하면 '프레임워크 세부사항'을 쓰지 않겠습니다. '데이터베이스 활용에 대한 깊은 이해와 숙련도' 등 좋은 코멘트가 있으면 기술 면접과 후속 종합 면접에 합격하더라도 연봉이 상대적으로 낮을 수 있습니다. 직접 탈락”

면접 과정에서 절대 실수하면 안 되는 부분이 있기 때문에 준비 과정에서 다음 사항에 각별히 주의해야 합니다. 다음은 게임에서 빠져나오게 만드는 몇 가지 오답입니다.

"오류 유형"	"결과"
Inconsistency. 예를 들어 처음에는 Spring MVC를 사용했다고 나와 있지만, 나중에는 그렇지 않았습니다. 가장 기본적인 구현을 말하는 것은 불가능합니다. 예를 들어 Spring에 어떤 클래스가 있는지 모르거나 프로젝트의 세부 사항을 말할 수 없습니다.	저는 이 프로젝트의 진정성을 의심할 것이며, 추가적으로 질문할 것입니다: 사용된 데이터베이스는 무엇이며, 데이터의 양은 얼마나 됩니까? 얼마나 많은 사람들이 작업했고 시간이 얼마나 걸렸습니까? 시간이 많이 걸리는 소규모 프로젝트와 같이 명백한 허점이 발견되면 이는 단순한 기술적 문제가 아니라 작업 중에 "무리"하려는 시도입니다. 인터뷰 과정.
프로젝트에서 반드시 사용하게 될 기본적인 개념 질문에는 답변을 드릴 수가 없습니다. Spring의 의존성 주입 개념이 무엇이고 어떻게 사용하는지, MyBatis에서는 어떤 디자인 패턴이 사용되는지?	개념을 모른다는 걸 알게 되면 추가 질문을 통해 확인하겠습니다. 약한 것으로 확인되면 심각한 수준입니다. 부족한 기술력과 사용하지 않는 기술은 완전히 다르기 때문입니다. 상황에 따라 사용하면 직접 제거됩니다.
면접에서 언급한 경력과 이력서에 불일치가 있는 경우	이력서가 조작된 것으로 의심하고, 이력서라고 하더라도 지원자에게 설명을 요구할 것입니다. 잘못 쓰여진 경우, 그의 기술과 능력을 확인하기 위해 더 심층적인 질문을 하도록 하겠습니다.
이력서에 적힌 스킬 설명은 당연히 답변과 일치하지 않습니다. 예를 들어 제가 간단한 리눅스만 알고 있는 것이 당연하지만 자랑하고 있습니다.	다른 스킬은 몇 가지 더 깊은 질문을 통해 검증하고 찾아보겠습니다. 다른 측면에서 자랑하는 정도. 따라서 적절하게 과장하되 너무 지나치지 않게 하는 것이 좋습니다. 예를 들어 프로젝트에서 프레임워크를 구축하지 않았지만 일상 학습 중에 구축한 경우 "XX 프로젝트의 프레임워크는 귀하가 구축했습니다."라고 쓸 수 있습니다. "하지만 당신이 건축가라고 말할 수는 없습니다. , 프로젝트의 낮은 수준의 측면을 매우 잘 이해합니다.
예를 들어 인터뷰 중에 엄숙하게 말하지 않거나 매우 격식을 차리지 않는 옷차림으로 면접관이 불안정하고 성급하다는 느낌을 갖게 한다면 조끼를 입으면 됩니다.	아무리 실력이 좋아도 이로 인해 바로 탈락할 수도 있습니다. 저는 말투가 매끄럽지 못한 지원자에게 직접 악플을 쓰는 경우가 많아서 나중에 프로젝트 매니저가 인터뷰하기가 어렵습니다. 이력서에 6개월에 한 번씩 이직한다고 적힌 사람을 만났는데, 왜 그렇게 자주 이직을 했는지 물어보니 그 사람은 단순히 급여 문제 때문이라고 직접 말했습니다.
야근과 출장은 안 된다고 분명히 명시되어 있어요	사실 이런 질문이 있긴 하지만 회사에서 실제로는 야근이나 출장을 안 할 수도 있어요. 하지만 이런 대답을 듣는다는 것은 그 사람이 과중한 업무를 견딜 수 없거나 책임감이 약하다는 것을 의미합니다. 대부분의 회사는 그런 사람을 원하지 않을 것입니다.

"여섯. 소개:"몇 가지 보너스 포인트를 준비하고 소개에서 의도적으로 언급하되 모두 언급하지는 마세요

프로젝트 소개 시 일부를 삽입할 수 있습니다. 하지만 프로젝트를 소개하든 질문에 답하든 현재 귀하의 책임은 하이라이트를 설명하는 것이 아니라 프로젝트를 자세히 설명하는 것입니다. 그러면 면접관이 주제에서 벗어났다고 느낄 수 있습니다. .

이번에는 한 획으로 설명할 수 있습니다. 예를 들어 "우리 프로젝트는 상대적으로 큰 데이터 요구 사항을 가지고 있습니다. 우리가 바쁠 때는 평균 시간당 수십만 개의 데이터를 처리해야 합니다."라고 말할 수 있습니다. 이렇게 하면 면접관에게 "빅 데이터" 방향을 소개할 수 있습니다.

면접 전 포지션의 필요에 따라 이런 '통과' 단어를 준비하시면 됩니다. 예를 들어 이 직책의 요구 사항은 Spring MVC 프레임워크, 높은 빅데이터 동시성, 데이터베이스 튜닝 경험입니다. 그런 다음 과거 프로젝트를 소개할 때 이러한 측면에 대한 실제 기술을 강조하는 것이 좋습니다.

또 다른 예를 들어 보겠습니다. Java 가상 머신 메모리 관리와 데이터베이스 최적화는 대부분의 프로젝트에서 직면하게 되는 두 가지 주요 문제입니다. 프로젝트 경험을 설명할 때 누구나 이 프로젝트에서는 메모리 요소를 고려해야 한다고 말할 수 있습니다. , 우리 코드는 2G 메모리 환경에서만 실행이 허용되고 데이터베이스 성능 요구 사항이 상대적으로 높기 때문에 데이터베이스의 메모리 및 SQL 문을 모니터링하고 최적화해야 하는 경우가 많습니다. 이런 식으로 면접관이 심층적인 질문을 할 때 그는 가상머신 메모리 최적화와 데이터베이스 최적화에 대해 미리 준비한 발언을 던질 수 있습니다.

그래도 안 되면 “이 프로젝트는 상대적으로 인원이 적고 부담이 크기 때문에 개발 외에도 요구 사항 이해, 테스트, 배포 작업도 했습니다.”라고 말할 수도 있습니다. 또한 당신이 혼자 있는 경험이 있다는 것을 보여줄 수도 있습니다.

면접 과정에서 눈에 띄는 내용을 들으면 그가 현재 질문을 할 때까지 기다렸다가 아무렇지도 않게 질문합니다. 일반적으로 기술 면접은 최대 30분 정도 시간을 들여 답변해야 합니다. 준비된 질문을 하면 다른 질문을 받을 시간이 줄어듭니다.

"7. 지도할 수는 있지만 혼잣말을 할 수는 없다"

면접을 하게 되면 준비가 잘 되어있는 분들도 만나보게 되더라구요. 지원하고 싶다면 미리 준비해야 한다는 점은 이해하고 동의할 수도 있습니다. 너무 뻔한 징후를 보이지 않는 한, "준비된 것 같지만 실제 실력을 테스트할 수는 없습니다"라는 말은 쓰지 않을 것입니다. , 모든 인터뷰가 그렇지는 않을 수도 있다는 것은 말할 것도 없고 모든 사람이 당신이 준비되었다고 느낄 수 있습니다. 하지만 준비만 한다고 너무 강해질 수는 없잖아요. 결국 면접은 면접관이 주도하는 거죠.

말을 너무 많이 하고 주로 주도적으로 확장을 시도하는 인터뷰 대상자들을 만났습니다. 예를 들어 그에게 어떤 데이터베이스를 사용하는지 물었을 때 그는 데이터베이스가 무엇인지, 무엇을 했는지 대답할 뿐만 아니라 빅데이터에 대해서도 이야기했습니다. 그런데 처리 기술이 나옵니다.

실제로 너무 멀리 가면 나는 당신이 말한 모든 세부 사항에 집중할 것입니다. 왜냐하면 당신이 말한 내용은 당신이 프로젝트에서 사용한 내용이 아니라 온라인에서 읽은 내용이라고 의심하기 때문입니다. "당신이 먼저. 사실대로 말해보세요. 이 기술을 실제로 프로젝트에 사용했다면 나중에 조사에 집중하겠습니다. 일단 프로젝트에 사용하지 않은 것으로 간주되면 혼란스러운 일이 될 것입니다." 고백하려는 이니셔티브.

그렇지만, 데이터의 양이 상대적으로 많다고만 하고 거기에 그치지 않고 나머지에 대해서는 계속 이야기하지 않았다면 제가 깊이 물어봤을 것이고, 자연스럽게 표현할 기회가 생겼을 것입니다. 동시에, 일반적으로 인터뷰 과정에서 보너스 포인트를 보여줬지만 면접관이 대답하지 않으면 보너스 포인트는 프로젝트에 필요하지 않을 수도 있고 그에게 관심이 없을 수도 있으므로 다음을 수행할 수 있습니다. 이제 그것에 대해 이야기하지 마세요. 아니면 질문할 때까지 기다리세요.

「8. 요약이 끝이 아니다」

지금까지 프로젝트 소개에 대한 몇 가지 팁을 전해드렸습니다.

두 문장, 첫째, 면접 전 준비해야 합니다. 둘째, 이 글은 독단적인 것이 아닌 올바른 방법을 제시합니다. 암기하기보다는 이 글에서 제시하는 방향에 따라 준비하고 자신의 프로젝트 배경과 결합하면 됩니다. 이 기사에는 몇 가지 수사가 주어졌습니다.

모두가 프로젝트 배경을 소개하고 나면 인터뷰가 시작됩니다. 아무리 말을 잘해도, 질문을 준비한 범위로 아무리 잘 안내해도 여전히 Java Web(예: Spring MVC, ORM 등), Java Core(멀티스레딩, 컬렉션, JDBC 등) 및 데이터베이스 문제.

그렇다면 이 글의 가치는 무엇인가요? 지도가 좋지 않으면 자신의 능력을 발휘할 기회가 없습니다. 이것이 이 글에 제시된 방법의 가치입니다. 자랑스럽게도 이 글에 제시된 방법과 수사 중 일부는 생각해낸 것이 아니라 수백 명의 후보자를 인터뷰한 경험에서 발췌한 것입니다. 거기에는 많은 피와 눈물이 담겨 있으며, 사람들이 성공할 수 있는 방법도 많이 있습니다. 이 글은 모든 사람(특히 경력이 3년 미만인 학생)에게 어느 정도 도움이 될 것입니다.