DevRecruitmentThoughts
One of the frustrating things with the current state if tech recruitment is the repetition in interviews with different companies.
In the couple of interviews that I went through I ended up explaining the garbage collector in Java in at least 4 companies and had to answer: what are generics in Java? at least 3 times.
This problem is not easy solvable because each company needs to check if the candidate is competent.
One solution might be having some sort of knowledge / skill proof that you do once and just show it to the company, so that the interviewers can focus on the more specific question.
One caveat: I don't mean here a certification or a state exam but more like a real skills vetting process. (perhaps a coding session)
Now, there are a few problems with such an approach:
- who should organize it and how the companies could trust this organization
- should one be allowed to repeat the test more times?
- how do you make sure that it verifies the skills that are important?
They are not easy to solve but if they would be, the industry would benefit from it immensely.
What is your opinion?
Top comments (4)
I think this depends a lot on the stage of your career. If you're just out of university, you're probably right.
If you're more advanced in your career, there are ways to avoid these types of questions: Make your knowledge as public as possible.
Two easy ways come to mind: Blog about your ideas, and contribute to open-source projects.
To make it more concrete:
Next time you're asked a less technical interview question twice, blog your answer (I wrote Simple Go Mocks in response to being asked how I do mocks in Go, 3 times, in recent interviews). Most interviewers will browse your web site before interviewing you. If they see answers to their questions, they probably won't bother asking those questions, and will instead ask more interesting questions during your interview.
And for the more technical questions, open-source code can do wonders. If you have an open-source project that uses generics in Java, then the next time someone asks you, point them to that project. I once filled out a job application, which asked "Describe the lifecycle of an HTTP request" by pointing to a GitHub repository where I had written an HTTP REST API. The recruiter apparently thought that was sufficient, because they invited me for an interview.
Even if the interviewer fails to read your code or contributions, the fact that you can preface each answer with "I've written about that on my blog" or "I do exactly that in my open-source project" will do two things: It demonstrates that you're credible (you've thought about this before), and it also demonstrates that you're more prepared for the interview than the interviewer, which will force them to up their game a bit more, and start asking more meaningful questions.
And in the best case, being prepared like this will let you skip entire segments of an interview. I recently had an interview where the interviewer said "Normally we do a technical assignment, but considering that we're using one of your open-source projects, we already know you're a good coder, so we won't do that this time."
It's an interesting one.
I'm not a fan of asking questions like explain GC in Java, what are generics, what does volatile mean, etc; more than anything because I find it equally boring myself. My preferred way is to have a candidate show/talk about/demonstrate a project they're proud of and the majority of the time we can gleam competancy from that.
I've already blogged about how I think tech challenges in interviews should look like. The dev post is the shortened version - the full version can be found on What the # do I know?
What if your interview coding challenge would look like this?
Zohar Peled γ» Sep 26 γ» 1 min read
This is the purpose of the cs degree but companies rarely verify esp. after 9/11.