3 ms·

I am new to interviewing, but I have two working hypotheses: 1. Hire based on the resume, gut check on the interview. Is it plausible that they played the role

I am new to interviewing, but I have two working hypotheses: 1. Hire based on the resume, gut check on the interview. Is it plausible that they played the role that they said they did? If you were a major contributor to an RPC framework in C, but you can't walk a linked list... Maybe your resume is too inflated. This means that the questions are basic because their purpose is not to rank candidates but to ensure the validity of the resume. 2. Focus on reading over writing. I would rather a candidate who can read code someone else wrote, articulate what it does, and maybe plan for how to extend it than someone who can pretend to invent something new.

tucif 6y ago
#1 is good, but I’d suggest always using the same set of questions to have a good baseline against which you can compare candidates. #2 I have mixed feelings about. it may make sense if you’re after an expert on that language but may evaluate wrongly candidates that would be great reading code once they get just a bit more familiar with and get the overall architecture. In many companies, you’d be forbidden from sharing actual code with non employees, so the excerpt shown in the interview would have to be purposely crafted and loose value. I propose a more interesting exercise could be to examine a random piece of opensource that Both the interviewer and interviewee are unfamiliar with and trying to get a good discussion from it, but it’s a risky move leaving the interviewer exposed.