Java 면접관 경험 : 후보자의 실제 능력을 식별하는 방법, 가치있는 기술을 보여주는 방법

    저는 몇 년 동안 Java 면접관으로 일했으며 학교에서 학생 모집부터 중학교 개발자, 건축가에 이르기까지 인터뷰했습니다. 기술적으로 말하면 후보자가 인터뷰를 통과하는 기준은 매우 다양 할 수 있지만 한 문장으로 요약됩니다. 즉, 후보자가 직업 소개 요건을 충족하고 관련 프로젝트 경험이 충분한 수년에 도달했다는 것입니다.

     프로그래머 로서도 당연히 모든 후보자가 면접에 합격 할 수 있기를 바라지 만 면접관 으로서는 항상 자신의 의무에 충실하고 후보자의 진정한 능력을 파악하려고 노력해야합니다. 인터뷰에서 후보자의 이력서가 심사됩니다. 즉, 후보자가 이력서에 설명 된대로 될 수 있다면 인터뷰에 합격 할 수 있어야합니다. 그러나 실제로 많은 후보자는 "이력서"에 불과합니다. 밖으로 "만. 이 기사에서는 선임 면접관의 관점에서 인터뷰에서 후보자를 식별하는 방법에 대한 몇 가지 핵심 사항을 설명하여 대부분의 후보자가 인터뷰 준비 방법에 대해 더 많이 배울 수 있도록합니다. 특히 여러 코스를 읽은 일부 학생의 경우이 기사에 제공된 체크 포인트를 비교하여 현재 준비가 면접관의 조사를 견딜 수 있는지 확인할 수 있습니다.

1 생존자의 일탈, 사실 많은 이력서가 면접관의 손에 닿지 않습니다

    인터뷰 전에받은 이력서는 일반적으로 좋아 보입니다. 사실 많은 이력서가 걸러졌습니다. 나 자신이 이력서를 심사했습니다. 이전 블로그 게시물에서 어떤 이력서가 당신의 승리에 도움이 될 수 있는지 분석했습니다. 인터뷰 기회를 얻기 위해 인터뷰 기회를 얻지 못하는 인터뷰에 대해 이야기합시다.

    1 관련 기술에서 충분한 작업 또는 프로젝트 연도를 보유하고 있음을 증명할 수 없습니다. 예를 들어, 3 년의 Java 개발 경험이 필요합니다. 이력서에 많은 프로젝트 설명을 제공했지만 Java 개발 경험이 3 년이라고 요약 할 수 없으므로 인터뷰 기회가있을 것으로 예상됩니다. .

    2 연수가 충분하지만이 게시물에 필요한 기술은 이력서에서 볼 수 없습니다. 예를 들어,이 게시물은 netty와 dubbo를 꺼내려면 스프링 클라우드가 필요합니다. 이력서의 프로젝트 설명은 매우 화려합니다. 프론트 엔드와 ssm은 백엔드, jvm 튜닝 경험이 있지만 핵심 기술이 없어서 인터뷰 기회가 없다.

    3 이력서에 지난 6 개월 동안 일하지 않았거나 학력이 부족하거나 컴퓨터와 관련이없는 전공자 등 명백한 결함이나 모순이 있고 기술 설명이 너무 단순하거나 프로젝트 시간과 회사의 시간이 이전에 일한 것은 호환되지 않습니다.

    사실 저는 개인적으로 자신의 능력이 아무리 좋다고해도 이력서가 다음과 같은 조건을 충족한다면 최소한 이력서를 가지고 소규모 회사의 인터뷰 기회를 얻을 수 있다고 생각합니다.

   1 사회 채용의 경우 학교, 전공, 학업 자격은 실제로 그다지 중요하지 않습니다. 일부 소규모 공장이나 외국인은 프로젝트 경험에 더 많은 관심을 기울이지 만 관련 기술 프로젝트 (예 : 자바)에 대한 충분한 경험이 있음을 명확하게 작성해야합니다. ), 회사 및 프로젝트 경험을 통해이를 더욱 입증 할 필요가 있습니다.

   2 직무 소개서의 기술에 대해 잘 알고 있음을 명확하게 적으십시오. 이것은 태도의 문제이기도합니다. 각 직무 소개서를 꼼꼼히 읽고 목표에 맞게 프로젝트 소개를 개선해야합니다.  

   3 몇 가지 부정적인 요인에 대해서는 설명을 추가해야합니다. 예를 들어, 지난 6 개월 동안 일하지 않았거나 최근에 너무 자주 이직했다면 객관적인 이유를 제시 할 수 있습니다. 주관적으로 불안정하거나 가난한 것은 아닙니다. 그러나 직업 변경, 도시 개발 또는 대학원 입학 시험과 같은 다른 객관적인 요소가 있습니다.

2 프로젝트 경험의 요점 및 질문 방법 심사

    면접관은 이력서를받은 후 회사 경험과 프로젝트 소개를 읽고 실제 비즈니스 프로젝트 경험을 식별 할 수 있습니다.

    1 예를 들어, 자바 개발자를 채용하고자한다면, 수강생이 교육 수업 경험이 있다면 이전 경험이 자바와 관련이 있는지 확인해야합니다. 일반적으로 후보자는 이전에 자바를 해본 적이 없으므로 응시자의 관련 업무 경험 면접이 필요합니다.

    2 소규모 기업은 대규모 프로젝트를 수행합니다. 예를 들어 회사 규모는 수십 명이지만 전자 상거래 시스템을 구축하는 데 반년이 걸렸고 그 안에있는 분산 기술이 모두 사용되었으므로 이런 종류의 프로젝트는 심사에 집중합니다.

    3 이력서에있는 가장 최근의 프로젝트 설명은 일반적으로 후보자에게 더 많은 관심을 가지고 있습니다. 또한 기술에 모순이 있는지 확인하기 위해 1 ~ 2 년 전의 프로젝트 설명도 살펴 봐야합니다. 2 년 전의 기술과 최근의 기술로 프로젝트에 사용 된 기술은 동일하며 복사하여 붙여 넣은 것으로 추정되어 드러나고 있습니다.

    상기 심사의 목적은 관련 기술 또는 경력 연수를 확인하고 자체 편집 또는 학습 한 프로젝트 경험 연수를 확인하는 것입니다. 예를 들어, 회사에서 제공하는 급여는 프로젝트 경험 3 년입니다. 잘못된 경험으로 대체하면 한편으로는 도움이되지 않으며, 프로젝트 팀은 다른 후보자에게 도움이되지 않습니다.

    이러한 의문은 기술적 인 질문보다 먼저 확인되어야합니다. 즉, 의문이 사실로 확인되면 후보자의 해당 기술 연령이 기준에 미치지 못하여 면접을 계속할 필요가 없음을 의미합니다. 확인?

    이 프로젝트 팀이나 다른 프로젝트 팀이 예비 개발이 필요하고 지원자의 이력서에 의문이있는 경우 일반적으로 귀하의 xx 프로젝트가 학습 프로젝트처럼 보인다고 분명히 말하고이 프로젝트를 말해 주면 진실을 말해줍니다. 실제 프로젝트라면 저는 고급 개발의 실제 프로젝트 측면을 따를 것입니다. 학습 프로젝트라고 말하면 주니어 개발의 표준 측면을 사용하거나 다른 프로젝트 팀의 면접관에게 맡길 것입니다. 주니어 개발의 비율은 낮아 지지만 문제는 비교적 간단합니다. 이렇게하면 대부분의 후보자가 진실을 말하게되므로 양쪽 모두에게 편리합니다.

    주니어 개발 포스트가 없다면이 의심스러운 프로젝트에 대해 다음과 같이 질문하겠습니다.

    1 프로젝트 인원, 프로젝트주기, 클라이언트 측, 프로젝트가 현재 온라인 상태인지 확인합니다. 조작 또는 학습 프로젝트의 경우 일반 프로젝트는 온라인으로 전환되지 않습니다.

    2 프로젝트를 패키징, 컴파일 및 배포하는 방법에 대해 질문합니다. 일반적으로 프로젝트는 maven 또는 gradle로 패키징되거나 ant가 사용됩니다. 일반적으로 프로젝트는 Linux에 배포됩니다. 가용성을 고려하여 여러 컴퓨터에 배포됩니다. 같은 시간. 프로젝트가 완료되면 응시자는 말할 수 있지만 학습 프로젝트 인 경우 답변이 다양 할 것입니다 .Windows 머신에 배포하는 경우도 들어 본 적이 있습니다.

    3 버전을 관리하는 데 사용되는 도구 (예 : git 또는 svn 등)와 같은 프로젝트 관리 방법에 대해 질문하고 코드 검토는 어떻게 수행됩니까? 버그를 관리하는 데 사용되는 도구 (예 : jira 등), UML 다이어그램을 그리는 데 사용되는 도구 및 단위 테스트를 수행하는 방법은 무엇입니까? (junit 등) 코드를 개발할 때주의해야 할 사양은 무엇입니까? 이것들은 알아야 할 실제 프로젝트입니다.

    4 프로젝트에서 로그를 출력하는 방법과 로그를 통해 문제를 해결하는 방법을 묻습니다. 일반적으로 온라인에 접속 한 후 로그는 리눅스에서 출력되지만 학습 프로젝트 인 경우에는 윈도우에서만 볼 수 있습니다.

    5 일반적으로 실제 프로젝트에는 테스트 용과 온라인 사용 용으로 최소 두 세트의 환경이 장착되며, 학습 프로젝트 (또는 교육 클래스 프로젝트)는 한 세트 만 사용됩니다. 따라서 그에 따라 프로젝트에서이 두 환경을 어떻게 빌드했으며 두 환경에서 구성 파일을 어떻게 구별합니까?

    위의 방법을 통해 정말 많은 학습 또는 가짜 프로젝트를 선별했습니다. 실제로 위의 심사 방법은 효과가 제한적이라는 것을 알고 있습니다. 예를 들어 후보자의 최근 프로젝트가 실제이지만 이전 프로젝트가 자체 편집 또는 학습 프로젝트 인 경우 그는 가장 최근 프로젝트의 수사를 사용할 수 있습니다. 이전 프로젝트입니다. 질문을하려면 다음과 같은 심사 방법을 사용해야합니다. 이 시점에서 나는 칭찬은 말할 것도없고 감히 운이 좋지 않을 뿐이다, 나는 내 의무 때문에 감히 회사의 신뢰를 호의로 받아들이지 않는다.

실제 프로젝트에 "접목 된"가치있는 기술을 식별하는 3 가지 방법

    실제로 교육 학교에서의 개발 경험에 대한 이전 블로그 게시물 에서 "반 참 및 반 거짓"프로젝트 경험이 가장 구분하기 어렵다고 언급했는데 어떻게 생각하십니까?

    후보자의 회사는 실제이고 프로젝트는 실제이지만 후보자는이 실제 "쉘"을 사용하고 거짓 기술을 추가했습니다. 예를 들어, 최근 프로젝트에서 후보자는 가장 기본적인 추가, 삭제 및 수정 만 수행했지만 프로젝트 배경 및 비즈니스 응용 프로그램과 결합하여 분산 구성 요소, 성능 조정 및 JVM 조정을 추가했습니다. 비디오 클래스. 일부 프로그래머는 자신의 프로젝트 경험이없는 시니어 개발자 또는 설계자로 업그레이드하기 위해이 기술에 의존한다고 말할 수 있습니다.

    면접관으로서 후보자가 이력서에 배부되는 등 귀중한 경험이 있다는 것을 알게되면 그 경험이 실제로 프로젝트를 통해 축적되었는지 아니면 이론적 경험 만 가지고 있는지 평가해야합니다. 후보자가 이력서에 "훈련반", "소기업", "경력 변경"과 같은 요소가 여전히 남아있는 경우 후보자를 평가하는 것이 더 중요하며 구체적인 식별 방법은 아래와 같습니다.

    먼저 높은 동시성에서의 분산 사용, 대용량 데이터에 사용되는 하위 데이터베이스 하위 테이블 및 데이터베이스 튜닝과 같은 기술의 배경에 대해 질문하고 이러한 귀중한 기술을 사용해야하는 비즈니스 지점을 알려주십시오. 일부 응시자는 온라인 강의 비디오를 통해서만 귀중한 기술을 배우고 프로젝트에 대한 실제 경험이 없습니다.이 질문을 할 수 있습니다.

    두 번째 질문은 Redis 캐싱과 같은 가장 기본적인 기술 사용에 관한 것입니다. 해시 테이블 모드에서 데이터를 읽는 방법. Dubbo의 경우 시간 초과 기간을 설정하는 방법과 Kafka에서 메시지 재전송을 설정하는 방법입니다. 이러한 문제는 어렵지 않습니다. 사용하는 한 나중에 알게 되겠지만, 많은 후보가이 말도 못하면 나중에 다시 묻지 않겠습니다.

    2 단계 질문에 잘 답할 수 있다면 적어도 응시자가 사용했음을 의미하고 3 단계 질문이 이어질 것입니다. 프로젝트에서 어떤 실제 문제가 해결되었는지 물어보고 더 구체적으로 말하십시오. 분산 기술을 사용할 때는 항상 해결해야합니다. 높은 동시성과 같은 문제의 경우 프로젝트의 동시성 양은 얼마입니까? 이 양의 동시성에 대처하기 위해 프로젝트에서 사용되는 구성 요소는 무엇이며 이러한 구성 요소는 클러스터를 어떻게 형성하며 Linux에 배포되는 방법은 무엇입니까?

    Redis를 예로 들어 위의 3 단계 질문 방법에 따라 일반적으로 다음과 같은 질문을합니다.

    1 프로젝트 비즈니스의 동시성은 무엇입니까? 비즈니스 시나리오를 결합하여 프로젝트에 어떤 Redis 데이터 구조가 사용되는지 알려주세요. 이것은 결국 기술 사용에 대한 질문입니다.

    2 프로젝트에서 Redis 객체의 일반적인 캐시 시간은 얼마입니까? (일반적으로 프로젝트가 설정되고 그렇지 않으면 개체가 메모리에 누적되어 OOM이 발생합니다)

    3 일반적으로 Redis 클러스터를 어떻게 구축합니까? (프로젝트에서는 재사용 성을 고려하여 일반적으로 독립형 버전 대신 클러스터가 사용됩니다.) 

    4 Redis 지속성을 수행하는 방법은 무엇입니까? 메시지 통신 메커니즘을 수행하는 방법은 무엇입니까? 압력 테스트 방법? 이 장면은 프로젝트에서 사용될 가능성이 높습니다.

    위의 2 ~ 4 점은 테크놀로지 사용에 관한 것입니다. 일반적으로 프로젝트에서 사용했다면 여러 개를 사용하게됩니다. 말할 수 없다면 이론 만 사용할 수 있지만 사용할 수 없다고 말할 수 있습니다. 과학 기술.

    5 프로젝트에서 발생한 문제와 결합하여 프로젝트에서 Redis 문제를 어떻게 해결합니까? 구체적으로 어떻게 문제를 발견 했습니까? (모니터링, 로그 또는 사용자 불만에 불과합니다.) 문제를 분석하는 방법은 무엇입니까? (보통 로그 참조) 문제를 찾고 해결하는 방법.

    dubbo, mycat, netty, kafka 등과 같은 다른 구성 요소의 경우 유사한 질문이 사용됩니다. 첫 번째 질문은 프로젝트에서 사용 방법, 두 번째 질문은 세부 정보, 세 번째 질문은 문제 해결 방법입니다. 문제를 해결하십시오. 이 단계에서는 응시자가 아직 응시자의 능력을 확인하는 단계에 있기 때문에 기본 코드에 대해 묻지 않습니다. 응시자가이 수준을 통과하지 못하면 이론적 경험이 있다고 말할 수만 있으므로 영상을보고 정보를 보면서 준비한 귀중한 기술은 기본적으로 헛된 업입니다. 프로젝트 경험으로 자신을 증명할 수있을 때만 기본 코드 튜닝 기술 및 기타 세부 사항을 사용하여 케이크를 장식 할 수 있습니다.  

4 귀중한 기술에 프로젝트 경험이 있음을 증명하기 위해 응시자가 말할 수있는 점 (귀중한 기술을 준비하는 방법을 가르쳐줍니다)

    내 경험에 따르면 실제로 시니어 개발 또는 건축가 수준에 도달하면 대부분의 인터뷰는 인터뷰를 통과 할 수있는 능력에 의존 할 수 있습니다. 그들이 수행 한 프로젝트와 확인 된 문제를 결합하는 한 인터뷰를 할 수 있기 때문에 기술적 세부 사항을 준비 할 수 있습니다. 자신을 보여주기에는 너무 많은 하이라이트가 있습니다. 기본 개발 만 추가, 삭제, 수정 및 확인하는 일부 프로그래머 또는 프로젝트 경험과 장점 부족으로 분산 구성 요소를 연습 할 기회가없는 프로그래머의 경우 이러한 사람들은 상위 레벨에 도전하는 데 큰 어려움을 겪습니다. 많은 사람들이 30 ~ 35 세까지 낮은 직위 나 중소기업에 오래 머물러 있습니다.

    이른바 어려운 사람은 안되며, 회의는 어렵지 않습니다.이 부분에서는 일반적인 기술 통합 프로젝트 경험이 제공됩니다.이를 바탕으로 인터뷰 준비는 어떻게하나요? 면접관이 할 가능성이 큽니다. 실무 경험이 있다고 생각합니다. 결국 인터뷰는 1 시간 밖에되지 않습니다.

    기술과 프로젝트 요구 사항을 결합하여 xx 기술이 xx 시나리오에서 사용됨을 분명히합니다.

    1이 프로젝트의 xx 모듈에서는 Redis (또는 다른 분산 구성 요소)를 사용했습니다. 이유는이 모듈의 동시성이 xx에 도달했기 때문입니다. 단순히 데이터베이스에 요청을 누르는 것만으로는 충분하지 않으므로 사용해야합니다. Redis 캐시 또는 기타 Must use 분산 이유를 제공합니다.

   2 본 프로젝트의 주문 처리 모듈에서는 일부 플로우 테이블의 데이터 양이 많기 때문에 Mycat 서브 데이터베이스와 서브 테이블을 사용하는데 구체적인 방법은 백만 레벨 xx 테이블을 10 개의 테이블로 분할하는 것입니다. xx를 누르십시오. 필드의 마지막 비트는 데이터를 다른 하위 테이블에 삽입합니다.

   몇 가지 기술적 세부 사항을 준비하고 프로젝트 요구 사항과 연계하여 제시하십시오. netty 수사는 다음과 같습니다. 다른 기술에 대해서도 유사한 방식으로 구성하십시오.

   오프라인 몰 프로젝트에서 획득 모듈과 쿠폰 모듈 사이에 netty를 사용하여 획득 모듈의 메시지를 전달해야합니다. 사용 과정에서 netty의 직렬화 프로토콜로 protobuf를 사용하여 인코딩 및 디코딩 방법에 사용합니다. 직렬화 코드가 정의되고 netty는 스레드 풀 접근 방식을 통합합니다.

    실제 문제를 해결하기 위해 수사학을 준비하십시오.

    1 테스트 환경에서 cat 구성 요소를 통해 order 모듈은 종종 메모리 사용량이 너무 높다는 것을 발견하고 oom 동안 일부 덤프 파일을 통해 메모리가 오버플로되면 Redis 관련 메모리 사용량이 너무 많음 분석 결과 Redis가 데이터 캐싱시 타임 아웃을 설정하지 않는 것으로 확인되었으며 나중에 해결 방법에 대해 설명하겠습니다.

    2 우리 프로젝트의 테스트 환경에서 느린 SQL 모니터링을 자주 볼 수 있습니다. 로그를 살펴본 결과 Redis가 비어 있거나 존재하지 않는 데이터를 캐시하지 않았기 때문에 모든 요청이 데이터베이스로 전송 된 다음 캐싱 규칙을 변경하는 방법.

    다음은 문제를 일으킬 수있는 몇 가지 사항입니다. 스레드 풀을 잘못 설정하면 OOM이 발생하고 Dubbo 호출 시간 초과 시간을 설정하면 다운 스트림 모듈이 너무 느리게 반환되어 전체 링크가 중단되고 Kafka가 재전송 메커니즘이 설정되지 않았습니다. 이로 인해 아무리 나쁘더라도 Java의 트랜잭션 격리 수준이 너무 높게 설정되어 데이터베이스 연결이 꽉 찼거나 컬렉션 및 기타 개체가 꽉 찼다 고 할 수 있습니다. 제대로 사용되지 않아 OOM 문제가 발생합니다. 언제든지 프로젝트 사례 설명과 함께 "모니터링을 통한 문제 찾기", "리눅스 로그를보고 문제 찾기"및 "문제 해결을위한 솔루션 제공"에 초점을 맞출 수 있습니다. 

5 요약, 기술 사례 수사 + 결합 된 프로젝트 경험 설명 = 성공적인 인터뷰

    분산 기술 및 인터뷰와 같은 온라인 관련 과정이 많기 때문에 MySQL 클러스터, Redis 캐시, 스파이크 시스템 통합과 같은 일부 귀중한 기술 수사학은 준비하기 어렵지 않습니다. Java 초보자도 지적 할 수 있지만 많은 것들이 있습니다. 지원자는 기술 자체의 수사학을 선호하고, 프로젝트 준비를 결합하지 않거나, 심지어 프로젝트 준비와 결합해야한다는 것을 알고 있습니다. 이것은 인터뷰에서 후보자의 공통적 인 문제라고 말할 수 있습니다. 잘못된 방법으로 인해 일부 응시자는 아무리 준비해도 면접에 합격하지 못하거나 면접 기회가 없습니다. 다른 것들과는 별개로, 저는이 기사에 제공된 인터뷰 질문 방법을 사용하여 말만 할 수 있지만 할 수없는 많은 후보자를 실제로 식별했습니다.

    이와 관련하여이 기사에서 "선별 방법"을 도입 한 후 주어진 인터뷰 수사법과 수사 뒤에 "프로젝트 준비를 결합"하는 방법조차도 인터뷰 준비에서 "핵심 소수"라고 할 수 있습니다. 많은 시간과 노력이 필요하지만이 분야의 수사에 대한 준비가되지 않은 활기찬 준비는 면담 될 가능성이 높습니다. 이 "four-two-two-weight"인터뷰 기법이이 기사의 가치라고 말할 수 있으며, 모든 사람이 인터뷰 중에이 기사에 제공된 루틴을 따르고 프로젝트 요구 사항과 결합하여 기법을 설명 할 수 있다면 모든 사람의 인터뷰를 확실히 향상시킬 수 있습니다.

    내 공식 계정에 주목 해주세요 : 함께 발전하고 함께 돈을 벌어보세요.이 공식 계정에는 멋진 기사가 많이있을 것입니다.

추천

출처blog.csdn.net/sxeric/article/details/113173521