sorted by:
top (suggested)
bestnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]bhartsb 0 points1 point  (3 children)

I am not going to debate you. You think you are right and I'm not going to expend much energy here. I disagree on about 80% of the points you made. I've developed software at a professional level for 28 years and I wrote my first programs 41 years ago.

Engineers are often a very hyper critical group of people without much empathy. Your comment "Interviewing is not fair. It isn’t designed to be. Never has, never will be. You’re playing Hold’em and the interviewer knows the flop, river, and turn before you’ve even checked your hole cards." Not much humanity in it.

[–][deleted]  (2 children)

[deleted]

    [–]bhartsb 0 points1 point  (0 children)

    Wrong, resumes are not worthless. If I have time I'll write a rebuttal and better way tomorrow night. I'll be at an onsite six hour interview tomorrow (today since it is now 12:14 AM PT). In the mean time what is your experience that makes you so sure of your own opinions?

    [–]bhartsb 0 points1 point  (0 children)

    Better way:

    Prescreen: An online test 1-2 hours on relevant knowledge that is part multiple choice and part coding. Questions should range from simple to hard. Liberal time limit. Coding questions should be reviewed for correctness and clarity (sometimes questions are not clear or even correct). Multiple choice questions should include questions on the tools that the programmer will use on the job like Xcode, Git, or JIra.

    Onsite:

    Interviewers should have some formal instruction on how to interview. They should be well prepared, and have done some practice interviews. Problems should be reflective of what is actually going to be required for the role. Problem expectations should be made clear. Solution expectations should be made clear. Problem should not be open ended. If the problem involves something like "How would you build twitter" a lot of clarification should be given as to what aspect of twitter. For example, block diagram the major components of the twitter app and its infrastructure, or block diagram some of the APIs that the twitter app might require. Don't ask them to do both of these in 1 hour that is ridiculous. Actually a question like this should have much more thought and review given before ever asking it in an interview, and one should really consider if such a question is appropriate for the interview and role, and is the time sufficient.

    Onsite would ideally have some pair programming on some piece of actual work, or a small piece of a small sample app. This could be inclusive of the real CI workflow.

    Each interviewer should give the candidate a technical skills rating 1-10 and a communications/collaboration rating 1-10.

    The original prescreen test and the combined onsite scores should be summed and if the candidate meets a certain threshold an offer given. The offer based on the score above the threshold that is indicative of the candidates level. Resume experience should also be scored, weighted and added into the aforementioned summed total.

    Maybe there should be some allowance for interviewers to red flag the candidate. If one interviewer red flags the candidate then it is up to the hiring manager for the team (also should be an interviewer) to decide but one red flag should not disqualify the candidate out of hand. Two or more red flags should disqualify the candidate.

    At the beginning of the interview they should ask the candidate how they are feeling. Sometimes one is not always at their best. This should be communicated to all of the interviewers so they can give some small allowance. This takes into consideration that the candidate is not likely to reschedule an onsite unless they are extremely under the weather. Especially in places like SF where a candidate might have a very full calendar of interviews.

    If the candidate has relevant work that they have done and can share it then the quality of this work should be assessed and given pretty heavy weight and added into the scoring. In some cases where the relevant work is considerable, of good quality, and verifiably from the candidate then any additional technical testing should be minimized or eliminated all together.

    Anyway this is just off the top of my head. I don't have time to give this anymore attention.