Skip to main content

As was mentioned in an earlier answer, these are not mutually exclusive.

My "ideal" interview (and now that I'm in the other chair, it's something I'm trying to implement) is to screen an applicant based on the following items:

  1. Experience. Go over the resumerésumé with the applicant and if they say they've done stuff with technology X, ask a pointed question about technology X to make sure they didn't "pad" their resume.

  2. Panel interview. Here I'm asking mainly technical questions that are theory based to make sure the applicant knows what they are talking about. Also, it's a great way to assess the applicantsapplicant's personality. I want to make sure they aren't a jerk or racist.

  3. Tour of the facilities and project overview. Show them what they will be working on. An interview is a two-way street and they should see the project first hand to help better guagegauge their interest in the position. Nothing is worse then having to restart the hiring process after someone leaves in a month after realizing that they are more passionate about something else and we didn't do a good job explaining what they'd be working on.

  4. Code. All applicants have to write code, but it should be short and sweet to help determine if they really know what they are doing. The question should take no longer than half an hour to complete and maybe you can allocate a whole hour. The panel will then (after the candidate has left) do a code review and see if the candidate is worth keeping on.

I think this way, it covers alot of bases and makes sure that the candidate is competent, would mesh well with the team, and also interested in the position and company.

As was mentioned in an earlier answer, these are not mutually exclusive.

My "ideal" interview (and now that I'm in the other chair, it's something I'm trying to implement) is to screen an applicant based on the following items:

  1. Experience. Go over the resume with the applicant and if they say they've done stuff with technology X, ask a pointed question about technology X to make sure they didn't "pad" their resume.

  2. Panel interview. Here I'm asking mainly technical questions that are theory based to make sure the applicant knows what they are talking about. Also, it's a great way to assess the applicants personality. I want to make sure they aren't a jerk or racist.

  3. Tour of the facilities and project overview. Show them what they will be working on. An interview is a two-way street and they should see the project first hand to help better guage their interest in the position. Nothing is worse then having to restart the hiring process after someone leaves in a month after realizing that they are more passionate about something else and we didn't do a good job explaining what they'd be working on.

  4. Code. All applicants have to write code, but it should be short and sweet to help determine if they really know what they are doing. The question should take no longer than half an hour to complete and maybe you can allocate a whole hour. The panel will then (after the candidate has left) do a code review and see if the candidate is worth keeping on.

I think this way, it covers alot of bases and makes sure that the candidate is competent, would mesh well with the team, and also interested in the position and company.

As was mentioned in an earlier answer, these are not mutually exclusive.

My "ideal" interview (and now that I'm in the other chair, it's something I'm trying to implement) is to screen an applicant based on the following items:

  1. Experience. Go over the résumé with the applicant and if they say they've done stuff with technology X, ask a pointed question about technology X to make sure they didn't "pad" their resume.

  2. Panel interview. Here I'm asking mainly technical questions that are theory based to make sure the applicant knows what they are talking about. Also, it's a great way to assess the applicant's personality. I want to make sure they aren't a jerk or racist.

  3. Tour of the facilities and project overview. Show them what they will be working on. An interview is a two-way street and they should see the project first hand to help better gauge their interest in the position. Nothing is worse then having to restart the hiring process after someone leaves in a month after realizing that they are more passionate about something else and we didn't do a good job explaining what they'd be working on.

  4. Code. All applicants have to write code, but it should be short and sweet to help determine if they really know what they are doing. The question should take no longer than half an hour to complete and maybe you can allocate a whole hour. The panel will then (after the candidate has left) do a code review and see if the candidate is worth keeping on.

I think this way, it covers alot of bases and makes sure that the candidate is competent, would mesh well with the team, and also interested in the position and company.

Source Link
It'sPete
  • 629
  • 5
  • 11

As was mentioned in an earlier answer, these are not mutually exclusive.

My "ideal" interview (and now that I'm in the other chair, it's something I'm trying to implement) is to screen an applicant based on the following items:

  1. Experience. Go over the resume with the applicant and if they say they've done stuff with technology X, ask a pointed question about technology X to make sure they didn't "pad" their resume.

  2. Panel interview. Here I'm asking mainly technical questions that are theory based to make sure the applicant knows what they are talking about. Also, it's a great way to assess the applicants personality. I want to make sure they aren't a jerk or racist.

  3. Tour of the facilities and project overview. Show them what they will be working on. An interview is a two-way street and they should see the project first hand to help better guage their interest in the position. Nothing is worse then having to restart the hiring process after someone leaves in a month after realizing that they are more passionate about something else and we didn't do a good job explaining what they'd be working on.

  4. Code. All applicants have to write code, but it should be short and sweet to help determine if they really know what they are doing. The question should take no longer than half an hour to complete and maybe you can allocate a whole hour. The panel will then (after the candidate has left) do a code review and see if the candidate is worth keeping on.

I think this way, it covers alot of bases and makes sure that the candidate is competent, would mesh well with the team, and also interested in the position and company.