I enjoyed reading Thomas Ptacek's hiring post: <a href="https://sockpuppet.org/blog/2015/03/06/the-hiring-post/" rel="nofollow">https://sockpuppet.org/blog/2015/03/06/the-hiring-post/</a><p>I've never had an interview like that personally, but I have had interviews that were a bit more practical. Like instead of solving an algorithmic problem, it was: how would you lay out the database for a clone of popular website X, how would you handle stuff like pagination. Those are a bit less nervewracking than the typical "implement binary search in a chamber slowly filling with sand" interviews.
Ideally a company would have an open source code base and very clear issues with tags. With this, any sufficiently good pull request would automatically get you the job (a pull request to an appropriately difficult issue).
Sometimes, I'm just told there is a problem, here's a bit of code. Can I fix it? About 30 minutes later, I have a solution or I cry uncle.<p>If I don't have a solution, I have no work from the company.
I would love to be judged by my references earlier in the interview process, however this is not meritocratic.<p>In fact it's the opposite since it favors nepotism and disadvantages people from historically disadvantaged backgrounds. This is the same reason CA introduced the recent law prohibiting employers from asking about salary history.<p>But what is a "reference"? Often, it's a free-form phone call from the hiring manager to a person you've previously worked with. I think there's a lot of room to improve LinkedIn's "recommendations" feature--they clearly de-prioritized it, as well as endorsements.<p>In a nutshell, I want my social proof to precede me in my job search.<p>Why do fizz buzz when you can get several of your friends to confirm "this person can do fizz buzz, and also these things that you are expressly hiring for."
I had an idea a while back around inverting the interview/recruitment process, but a lack of resource/willpower/ability means I won't ever follow through with it. Regardless, I like the idea of it.<p>If a third-party recruiter is involved, they will get in contact with a developer that they deem to be sellable. Once they've got his/her details, they'll pass them on to an employer, who will then interview them for the role.<p>The flaws with this approach are:<p>1. The recruiter doesn't know if you're any good or not. They probably don't care, but a good developer can be sold for a high commission.<p>2. The interviewee has to interview when it is convenient for the employer<p>3. The employer has to run a ton of interviews to find a viable candidate, and (probably) come up with a proper interview process to replace their crappy one.<p>If, instead of having a skills-based interview with the employer, you had one with the recruiter, who would only take you on as a client if you matches a certain level of skill/talent, in theory everyone's problems are solved.<p>Recruiter: Adds real value to the developer, can sell a provable talent to a company quickly, and ideally with no worry about commission being lost by an employer rejecting an obvious dud.<p>Developer: Gets to "interview" whenever is convenient for them. Can be evaluated in multiple ways (take home test, face-to-face interview, etc), and can be given real technical feedback as the interview is not for employment, but to sign up for a service.<p>Employer: Can hold a shorter interview process, and get someone in quickly.<p>In terms of actual technical interviews, there are so many different ways of doing them that all I ever really want from an employer is some heads-up on what I'll be asked. Interviews are convenient at the best of times, so if I'm going to try and make time when I should be working I want to at least be prepared for the experience.
Ask me about what I've accomplished in the past, and have a technical conversation with me about the subject matter that's directly relevant to the role right now.
I want the interview be a form similar to hackathon. Given a software request (or a topic), design and implement it within 8 hours.<p>For example, implementing a chat app.
I'm still a fan of technical questions that don't involve low level implementation of code.<p>Things like "How would you create minesweeper on the iPhone" or "How would you make an app that's Airbnb for dogsitters?"<p>Just try to see how people would approach the question.
Conceptual problem questions that test my knowledge of data structure and algorithm _application_ rather than detailed implementation. Do I know how computers work? Can I apply Big-O conceptually in this problem space? Can I discuss how this problem changes when n goes from 1Kb to 1Tb?
Programming. Blank file or modify something existing, I don’t really mind. Ideally something reasonably open-ended, though. Evaluation which emphasises results more than “ways of working” stuff.