3 ms·

Technical interviews are two-way assessments. If you're not going to put your best effort by representing the work fairly through the technical interview, it ce

Technical interviews are two-way assessments. If you're not going to put your best effort by representing the work fairly through the technical interview, it certainly says something about how you view and respect potential candidates' time and maybe it indicates the quality of code you run. I have nothing else to go on unless you have public repos. I personally don't think it's a wild extrapolation based on the code quality compared to interviews I've gotten and I quickly reject companies that don't put forth fair tests. At worst, I'm wrong about the code quality, but I'm still selecting based on bad interview questions, which I'm perfectly fine with and I think more people should do if only to generate some kind of rejection signal to get interviewers to stop asking mundane questions like this. It's not like companies don't also reject candidates for equally small bullshit or extrapolating conclusions about candidates based on the interview anyway.

lucideer 9y ago
> Technical interviews are two-way assessments. If you're not going to put your best effort by representing the work fairly through the technical interview Interviews (technical or otherwise) are an opportunity for both parties to ask questions and discuss what each is looking for. In that sense, interview questions should ideally elicit discussion. This gives the interviewer an opportunity to assess how the candidate approaches problems and gives the candidate an opportunity to explore their perspective on those problems (again, in discussion -- dialogue) I don't think the questions need to be "representative" as you say. The primary purpose is not too represent the company, it's to allow the candidate to best represent themselves. I'd actually say distilled problems may do this more effectively and efficiently than ones "lifted" from prod. Also, in terms of putting "effort" into interview questions, lifting from prod seems much lazier tbh. > I have nothing else to go on unless you have public repos I've generally just asked, which has in my experience been received as a normal request.

lucideer 9y ago

> Technical interviews are two-way assessments. If you're not going to put your best effort by representing the work fairly through the technical interview Interviews (technical or otherwise) are an opportunity for both parties to ask questions and discuss what each is looking for. In that sense, interview questions should ideally elicit discussion. This gives the interviewer an opportunity to assess how the candidate approaches problems and gives the candidate an opportunity to explore their perspective on those problems (again, in discussion -- dialogue) I don't think the questions need to be "representative" as you say. The primary purpose is not too represent the company, it's to allow the candidate to best represent themselves. I'd actually say distilled problems may do this more effectively and efficiently than ones "lifted" from prod. Also, in terms of putting "effort" into interview questions, lifting from prod seems much lazier tbh. > I have nothing else to go on unless you have public repos I've generally just asked, which has in my experience been received as a normal request.