I thought recruiting was an experience you’d have only after becoming a senior developer with 10+ years of experience, but I had forgotten that I work at a startup. (It’s now past tense though..) Because my team needed backend developers, we opened 1-2 positions and I briefly had the special experience of participating in recruiting as a sub. It was an experience made possible because the company was small, and I’m not sure when I’ll do it again in my career. After being in the recruiting position, I remembered several things I had thought wrong when I was job hunting, both recently and in the past. So here’s a summary of resumes-assignments-interviews from the recruiter’s perspective.

(These are subjective thoughts recorded because I probably won’t remember when I become a job seeker again or an interviewer later, and I’m not sure if it’s okay for a 5-year nobody like me to publicly write such things…)

Resumes

Resumes I Found Unfortunate

  • Resumes where important and good experiences are written on pages 1-2 and beyond
    • If the hiring manager is too busy, they might not read that far… (But I did read everything. What if I miss a really good person?) Just as a resume consultant once told me, I also continued to read resumes with focused attention if the beginning was interesting, otherwise I skimmed. Conversely, it was frustrating when education or experiences unrelated to development that I didn’t want to see were written at the front.
  • Vaguely written experiences
    • It was most disappointing when experiences were expressed in abstract terms like ‘xx team coupon domain maintenance’. I couldn’t tell what kind of person they were who had fixed what and how. Even if they had done similar work to what our team does from a domain perspective, I couldn’t be confident that they were someone who could do it well.
    • In the past, I sometimes put super brief summaries to reduce resume size (I thought it all had to fit in one or two pages at the time), or thinking “They’ll ask in detail during the interview anyway??” But summarization varies by how you do it.
    • To give more confidence to the person reviewing documents, I think it’s better to express experiences as clearly as possible, focused on achievements. - However, if there’s too much text it’s burdensome for the reader, and it’s good to abstract enough that what you want to emphasize is emphasized.
  • Resumes that are jarring
    • ex. Submitted with completely broken formatting, photos you don’t want to see 🥲 (like eating something - definitely not for profiles), resumes where careers unrelated to development are written too long
    • In the past, I thought photos were necessary for resumes and paid attention to photos, but looking at photos attached to resumes this time, most of my thoughts were just ‘They attached a photo’.

Resumes I Admired

  • Resumes with strings of good achievements like proactive improvement experiences or new technology introductions for each project
  • Resumes with side projects that are operating/made to operate on actual websites and could be checked by following links
  • Resumes that give confidence that it’s not a resume being blasted to multiple companies through hiring platforms - resumes with even a brief reason for applying to our company

Thoughts That Changed a Bit from the Past

  • Past me thought that if I failed at the resume screening stage, it was 100% because I wrote the resume poorly + I was lacking something. That could be true. But I don’t think it’s 100%. Job applicants don’t know the situation of the company they’re applying to. When I was recruiting, our company wasn’t in a situation with abundant resources, so we couldn’t take the risk of hiring and onboarding someone with no practical experience or virtually none. (If we had been a bit bigger with more positions, there were quite a few people who would have moved on to the assignment stage.) Even with really great resumes, I tearfully voted for rejection. For similar reasons, it was difficult to pass the resume screening when the grain of accumulated experience didn’t match. Because there were more applicants than expected compared to positions, the criteria became higher than initially thought.
    • ⇒ Conclusion: Don’t worry too much about resume rejection. No need to cry rivers about mass rejection…

Assignments

  • ‘How this person usually works’ seems to be revealed a lot through assignments.
  • It might have been trying too hard beyond the requirements, but using excessive technology compared to requirements only increased complexity, and people whose background for such choices was also unclear didn’t look good. Maybe they just wanted to try that technology…
  • It’s good to write basic things like ERD and tech stack in the readme when submitting assignments, but I thought it would be good to summarize what concerns you had and what points you paid attention to while doing the assignment. - Wouldn’t it be an appeal point? However, I didn’t see many people like this.

Interviews

  • You don’t need to be extremely good at self-introduction, but at minimum it would be good not to be unable to speak due to nervousness.
    • I’ve also failed like this - I prepared too hard for self-introduction and was overwhelmed by the interviewers for no reason. But being nervous like that seems to ruin everything. From the interviewer’s perspective, we try to help them relax as much as possible to see their true value, but there’s nothing more we can do beyond that.
  • We look at ‘Can they do well when they come to our team’ < ‘Are they an excellent developer’.
    • When job hunting, I think I spent too much time only trying to appeal that I’m an ’excellent person’. But when recruiting, I kept thinking ‘Will that person be okay when they come to our team, how will they communicate in problem situations, can they have a good influence on the development team’ etc., and if I couldn’t judge, I asked more questions.
  • When asking basic things, looking at how they explain shows the depth of that person to some extent. So even for experienced people, we sometimes ask basic things… I need to become someone who can explain well.
  • Talk specifically about problem-solving experiences
    • To form context with the interviewer about the problem and solution, you provide various information. The situation at the time, why this work had to be done, why the technology was chosen, results, and if results weren’t good, lessons learned. In that process, if something isn’t understood, additional questions are asked. First succeed in making the interviewer understand, then you can discuss.

—

Memo for Future Recruitment Responsibility

  • Lesson learned 1: Recruiting is also a place to brand the company and team.
  • Lesson learned 2: Must clarify what we expect from the person being recruited.
  • It would be good to do more research on good questions and what it means to interview before entering the interview.
    • Putting intention into each question and thinking about how the other person will receive this question
    • Considering various situational flows, such as additional questions that can be asked when capacity isn’t clear even after asking prepared questions