본문 바로가기

영국생활 & IT

영국에서의 닷넷 인터뷰 질문들

이직을 결심하고 CV를 쓰고 여기저기 올려놨더니 헤드헌터들이 쉴새없이 전화했다. 영국은 진짜80%는 헤드헌트를 거쳐가는 모양이다. 그런데 정말 짜증나는 것은 어떤 헤드헌터가 알짜베기인지 모르니깐 친절하게 일일히 대답해 줘야 한다는 것이 굉장히 귀찮다.


영국에서 대부분의 면접 프로세스는 헤드헌터와 1:1로 충분히 내가 일해온 분야에 대해서 설명 하는 것이었다. 그럼 헤드헌터가 클라이언트를 찾아가 나에대해서 어필한다. 그러면 대부분 전화 인터뷰를 요청한다. 이때 컨퍼런스 콜로 2-3명의 개발자들과 인터뷰를 하는 경우도 있고, 아니면 아주 기본적인 질문만 시니어급 개발자가 전화를 해서 물어보곤 했었다.




빅4 회사(M, 애, 아마, 9)가 아닌 이상에서는 알고리즘 문제보다는 닷넷에 관련된 기초지식을 물어보는 경우가 많았다. 아래 질문들이 주로 나오는 단골 질문들이었다. 

C# 파트에서는
- Access Modifier가 무엇이냐?
- boxing/unboxing이 무엇이냐?
- Threading Locking이 무엇이냐? 언제 사용하냐?
- switch 가 빠르냐 if else가 빠르냐
- readonly와 const의 차이가 무엇이냐?
- interface와 abstract 클래스의 차이는 무엇이냐? 
- 오버로딩과 오버라이드의 차이는 무엇이냐?
- virtual 메서드는 뭐하는 것이냐?
- SOLID 디자인 개념이 무엇이냐?

ASP.NET MVC 파트에서는
- HTTPS가 무엇이냐?
- 크로스 사이트 스크립트가 무엇이냐?
- TDD가 무엇이냐?
- TDD에서 Mocking이 무엇인지 알고 있느냐? 
- 어떤 Mocking 프레임워크를 사용하느냐?
- ORM의 장점은 무엇이냐? 
- DI를 사용해본 적이 있느냐?

C#은 주로 기본 개념에 대한 질문들이 대부분이었고, ASP.NET 파트는 애초에 애자일이 잘 자리 잡은 탓인지 TDD가 대부분의 회사에서 주된 이슈로 질문이 오고 갔었다.


그런데 빅4 회사중 한 회사의 인터뷰는 조금 심도 깊었다. 첫면접에서 스크린 인터뷰를 진행했다. 온라인 채팅방인데 같이 코딩을 할 수 있는 에디터를 쉐어하는 웹사이트를 하나 공유해주었다. 그리고 코딩 인터뷰를 시작하기전에 먼저 간단한 패턴들에 대한 질문부터 시작했다.

- 어떤 패턴을 많이 사용하느냐?
  (싱글톤, 스트레티지, 팩토리 등을 자주 사용한다. -_-)
- 그럼 싱글톤 패턴의 장단점이 무엇이냐? 
  (뭐 그냥 대충 메모리 절약 / locking 디자인이 고려되야 한다는 단점)
- 그럼 스트레티지 패턴이 무엇이냐? 다형성이 무엇이냐?

이런 주로 패턴에 대한 질문들을 시작으로 바로 코딩 테스트에 들어갔다. 면접후기들 읽어보니 첫인터뷰는 엄청 간단하다고 하면서 기초만 알면 풀수 있다고 해서 솔직히 깊게 생각안했다. 그래서 주어진 문제를 최대한 빨리 작성해낼 수 있으면 되는 것이구나 라고 생각했었는데,, 아뿔사 반전이 있었다. 아무튼 문제는 이렇다. 

List<int> arrDummy=new List<int>{1,2,3,1,2,3,4,1};

이 List에서 가장 많이 겹치는 공통 값을 찾아내는 것이다. 눈으로 보면 1이다. 그렇다. 1을 후딱 찾아내면 된다. 아하! 하면서 아무 생각없이 코드를 작성했다.

public int MostCommonlyValue(List<int> arr)
{

  int CommonValue;

  int CommonValueCount;

  for(int i = 0 ; i< arr.Count;i++)
  {

    int CurrentCount;
    for(int y=0;y<arr.Count;y++)

    {

      if(i==y) continue;

      if(arr[i]==arr[y])

      {

         CurrentCount++;

         if(CurrentCount>CommonValueCount)

        {

             CommonValue = arr[y];

             CommonValueCount = CurrentCount;

        }

      }

    }

  }

  return CommonValue;

}

대충 이렇게 중첩 for문을 이용해서 작성했다. 뻥 조금 섞어서 1분도 안걸렸다. 그런데 왠걸, 메서드를 하나 작성하고 나서 바로 빅오 알고리즘에 대해서 물어보는 것이다. 그때서야 아차! 아뿔싸! 이런! 이 문제가 알고리즘 능력을 보려는 것이지 내 코딩이 되나 안되나를 보려는게 아니였구나! 라는 생각이 머리를 강타했고, 멘붕이 시작했다.

이 메서드의 빅오표는 당연히 O(arr.length의 제곱) 이다. OTL 만약 별도의 dictionary나 array를 만들었더라면 중첩 for를 피할 수 있었고 충분히 리니어 타임 알고리즘을 작성할 수 있었을텐데 말이다. 그리고 공간의 단점들이나 이런것들을 설명하면서 알고리즘을 얼마나 잘 이해하고 있는지 확인시켜 주면 어땠을까라는 생각이 들었다.

가뜩이나 요즘 영국 실업률도 장난 아니고, 유럽에 개발자들도 다 몰려드는 마당에 회사를 나오려고 한다는 것이 잘한 선택인가 싶으면서도 다음에 한번 더 걸리면 좀 더 바짝 긴장해서 섬세하게 임할 각오를 다시 다짐해본다.