심사 경험삼아 생각해보고 올려보는 것도?

회원 탈퇴하는 과정에서 애플에 REST API 요청을 위해 jwt를 만들어야 하던데, 이를 서버에서 해줘야하나? 로컬에서 jwt 만들 수는 있을 건데 그렇게까지 안해도 아마 통과는 될 거다. 운빨이다 ㅋ 처음할 땐 잘 모르겠다. 앱 처음 배포가 좀 빡세다. 그 이후엔 대충보고 OK 한다. 굳이 지금할 필요는 없고 나중에 리젝 당하면 하는 것도. 리젝 당하면 그 때 고민해보자

일본도 좋다. 연봉도 낮지 않다. 그래도 5-6년 되면 많이 받는 친구는 1장 정도.

앱의 컨셉이 바뀌었다. 무한 스크롤을 구현하려면 서버에서 페이징이 되서 넘어와야 가능하냐? 그게 편하다. 그게 아니면 무한 스크롤이 아니지 않나? 서버에서 페이징 안해주면 힘들다. 내려주는 대로 받는 입장이기에

Vapor 써보면 Flask 정도까지는 된다.. 서버 그 외 것들이 힘들다…

Rx에서 reentrancy anomaly was detected 가 뭐인지? 저도 잘 😅 https://velog.io/@dev-yong/RxSwift-8.MainScheduler.instance-vs-MainScheduler.asyncInstance 면접 질문에는 안나오겠네요. Rx 썼을 때 힘들었던 것이 뭐냐. 에 적어보는 것도?! → 결과와 오류로 분리해서 해결했음 async에서 dispose 같은 것을 제떄 안해줘서 발생했었음. 화면에 떠있고 다음 화면이 시트로 뜨는데 두 뷰모델이 살아 있으니 어디로 보내야 할지 몰라서 발생했음

신입은 경력 사항이 없는데, 프로젝트 완성도를 많이 보나요? 이게 일단 과제는 무조건 완성도! 빌드가 안되면 탈락임. 빌드가 되어야. 어차피 프로젝트 이력을 적는다 했을 때 볼 수 있는 건 앱스토어에 올라와 있는 것밖에 없다. 이것만 봐서는 무슨 기술을 썼고 뭘 어떻게 구현했는지 안 보임. 디자이너가 있냐 없냐에 따라 퀄리티 느낌이 엄청나기에. 프로젝트에 뭘 썼는지 보고, 업데이트 자주되는지, 유지보수 되는지. 이정도 수준 본다. 특별히 화면을 한 번 쭉 봤을 때 어려워보이는 화면이 있으면 면접 볼 때 질문 거리 정도는 되겠다. 프로젝트 보고 서탈 시키는 않는 것 같다. 잘 대답 못하면 보통 탈락

내가 강조하고 싶은 걸 위에. 싫은건 밑에. 면접 몇 번 보다보면 괜히 적었나 싶은 것들 빼셔야 하고. 일단 전 (Rx) 기대 안 한다. 없어도 된다고 봄. 보통 다 기본기를 볼 것. 자구.알고리즘은 면접준비할 땐 안하셔도 된다. 차라리 iOS 공부하는게. 회사 마다 다른데, 광고 회사(몰로코, SDK 만드는 회사)는 알고리즘 본다. 일반적인 서비스 만드는 회사들은 본인들도 알고리즘을 잘하지 못한다. → 굳이? → iOS 준비하는게 나을수도 신입 공채는 중요하죠. 굳이 공채 아니면 물어보는데 많지 않을 듯. 우리와 관련된것(프로세스/스레드, 뮤텍스/세마포어) 요정도? 거의 CS도 잘 안 물어본다. 회사마다 조금 다르겠지만 그런 iOS 조차 안물어보는데도 종종 있다. ‘니가 한 프로젝트에 대해 설명해봐라’에 대한 꼬리질문. 이는 유도한대로 만들 수 있다.

프로젝트 완성도는 돌아가고, 업데이트 꾸준히 되면 가산점 정도임. 경력직이 되면 개인 앱을 왜 계속 하고 있니 물어보는 곳도. 니가 하는 의도가 뭐니? 돈 벌려 하니?

지금 하는 거 하나 + 또 하나 정도 하면 좋게 볼 거다. 우위를 가지려면 한 두개 더하고.

블로그 하는거 안하는거 차이가 있는 건 아닌데, 똑같은 얘기들을 복붙해서 블로그 하는 분들이 많은 듯? 내용 자체도 똑같다. 짧고. 굳이 개수 의미 없다. 왜를 달고 한동안 살고, 정리해서 올리면 나름 그거는 좋게 볼 것 같다. 예시 코드를 더한다던지.

다음에 프젝 할 땐 아예 오픈 해놓고 프로젝트 만드는 것도? 서류에 내는 코드로 따졌을 땐 README 만들고, 일부러 이슈 날리고 , 풀리퀘 만들고 하는 작업 하는게 보여주기 식이지만 추천한다. 오픈 하면 깃헙 액션이 공짜니 CI/CD 해봤다고 적을 수도! Fastlane도 해보시고, 원하시는 곳에 있는 우대사항에 있는 걸 하나씩 하나씩 해본다고 생각해도 될 듯. 보통 MVVM이니 이를 어떻게 하면 깔끔하게 쓸 수 있을지 고민. 테스트도 하고 버그 생겼을 때 crash report를 organize에서 볼 수 있다. 어케 해결했는지 Instrument 쓸 줄 아시면 좋다.

지원서에는 실제 경험한 프로젝트를 어떤 방식으로, 어떻게 기여했는지 상세히 기술해 주시면 검토하는 데에 도움이 됩니다.

(예시 : 프로젝트 설명 및 구성 인원, 본인이 기여한 역할, 프로젝트 진행 시 발생했던 이슈와 해결 방법 등)

시간이 있고 여유가 되면 Rx나 Alamofire는 부담스러울 수 있는데, 작은 라이브러리에 ‘내가 이 기능이 필요해서 넣었어’ 하면 코드 리뷰도 해주고 그렇다.

새로운 라이브러리 만들어봐도. 기왕이면 UI 라이브러리 말고 다른 거. 하지만 쉽지 않아서,,

그냥 스타트업 가셔도 괜찮다. 돈바라고 가는거면 고민이 될 수 있는데, 1-2년 경력 쌓고 이를 이력 삼아 큰 회사를 가보겠다 하면 나쁜 결정은 아닐거다. 회사 규모 따라 내가 해야 하는 게 다르다. 작은 회사는 내 몸을 갈아 넣어서. 어떻게 일하고, 내 일이 다 다르기에. 작은 회사에서 열정있을 때 몸을 갈아보시는게. 초반에 몸을 갈아넣고 그를 기반으로 평생을 먹고 사는 것.

저같은 경우는 굳이 회사를 초반에 안따져도 되지 않을까 쉽다. 모바일 개발자라는게 회사 규모에 따라 크게 달라지는게 없다. 백엔드와 달리. 코드 짜는 부분에 대해선 비슷하기에 일단은 돈받으면서 성장하는게 중요하다고 생각합니다.