Most people, if not everyone, in our field think that hiring engineers is a broken process. How do you think you should be interviewed as an engineer for the company to see your skills and strengths? How do you think a company should judge whether you are suitable for the job or not?
Cheers!
There were a total of 4 interviews from various people on a perspective team, all back to back in the morning, 30 minutes each. Each interview was pillared by an algorithmic problem of varying difficulty, but there was clearly no expectation that you'd write a working program in the time. Most of the time was spent discussing the problem, comparing it to other ones you've approached before and searching for solutions. If you felt comfortable after this you could write code given time.
4 algorithmic interviews may sound like a lot, but I credit Microsoft for using this to the candidate's advantage. Each interview is an opportunity to succeed and show your best self, and I found that the one question that played to my strengths had the most impact on my hiring decision, whereas questions I did poorly on did not ruin my chances.
The rest of the interview was spent discussing past experiences, with an emphasis on the challenges of collaboration. This part was a discussion, with extensive back and forth and no expectation to be a certain way or exude some quality. Some of my discussions ended with us at unsolvable questions, and in others I got valuable feedback that I brought back to my personal projects. All in all my interviews at Microsoft helped me grow as a programmer.
Further, Microsoft makes their on-site interviews an enjoyable process, giving candidates time to learn about the company, tour the campus, and spend time in the Seattle area to get a taste of it. Their interviews are as much an enjoyable vacation as an opportunity to show your stuff. For me Microsoft's hiring process (At least the on-site part, stages before this have some issues) was an enjoyable opportunity for growth.
These reviews would be aggregated and allow a new prospective candidate to decide whether it's worth the gamble to take the time to interview with that company (a bet amounting to hundreds of dollars of lost time if they're already employed elsewhere). The goal is to encourage hiring managers to step up their game, cut out the baloney, and quit putting their own staff through breakneck quotas of pointless and feckless interviews.
It's also to draw a huge scarlet spotlight on the companies out there that do nothing but interview and never hire. These tirekicker companies are a scourge on the industry and it's a necessary public service that they be identified.
If your company is so choosey that it has to go through 100 onsite interviews to pick one candidate, fine, but candidates have a right to know that before they commit to your process.
- If I have an extensive github, and my github is on my resume, and you don't have the time to look at it, I don't have time for your coding test.
- If your coding test asks thinly veiled lateral thinking questions, I will not be accepting a job with your company.
- If you spend more than 60 seconds of the interview asking me what I think of your coding test, I will not be accepting a job with your company.
- If I'm interviewing for a position where I'm going to be mostly developing CRUD apps, don't ask me to implement a bubblesort. Interview for the job you're actually hiring for.
- Ideally, let someone else design your coding test. There's plenty of companies that do these now, and they'll be better at it than you are.
Is that a big enough deal to rule out a whole company?
What does this mean? (Genuinely curious.)
>etc... more than 60 seconds...etc..
Why do you not like this? I’ve never been asked this but I think it’s a great question from both an interviewee and interviewer perspective, allows some great meta dialogue into understanding how each other think.
IMHO a programming test is a prophylactic and nothing more. It's fine if you ask me e.g. why I used an anonymous function in one spot, or why I didn't check for a certain exception, but it shouldn't be the focus of a technical interview.
Many BigCo's assume that candidates should be dedicated enough to allocate weeks/months for preps.
Another critical point - if you have take home tests/assignments and it might take more than 10-15 minutes, always offer to pay the premium hourly rate regardless of outcome.
(And that's not even counting the awful take-home coding challenges that take multiple evenings or an entire weekend to complete.)
For a half day, allow it to be scheduled at least partly before/after standard work hours so that the candidate can just come in a bit late to their current job or leave a bit early - claiming a dentist appointment or similar.
If you don't respect my time, I'll assume that's a harbinger of how you'll treat me after hiring, and I'll walk away.
And at least half of the interview should not be about technical skills; at least half should be me finding out about the company rather than vice-versa. Talk about process. Talk about stack. Talk about interactions with non-engineers. Talk to non-engineers.
Both benefit. The engineer does not need to work on silly online tests, gets paid and gains an impression about how the company works; the company gets to see how the engineer solves a real problem, gets (most likely) a usable result in return and has provided the engineer with a headstart into the company's work culture should they decide to continue the cooperation.
Everyone wins, resumes become mostly useless and no artificial interviews
- The vast majority should be technically probing conversation that digs into the specifics of my expertise and work project history. No whiteboards, no live coding, no take-home tests. Just technical conversation.
- The interview should weight my ability to speak clearly about my technical expertise and work history highest by far. This should be weighted drastically more highly than performance on coding tests.
- Code tests should offer the candidate whatever combination of tools they feel most comfortable with, in terms of editor, mouse/trackball, language of choice, access to basic documentation.
- Code tests should mostly be about talking with the interviewer. They should involve no “gotcha” trickery to see a shortcut. Getting the naive, slow time complexity, memory-hungry solution with a clean writeup should count as a fully complete solution, not scored any lower than a solution from someone who happened to memorize a dynamic programming trick, etc. The basic fact of being observed in an interview means that if you observe someone only able to complete the naive solution, it does not tell you anything at all. In a non-interview setting, they might easily work out an advanced solution. Or, if someone overfitted their knowledge to memorize these types of interview solutions, in a real work setting they might not generalize to ambiguous, unsolved problems. Observing anything other than the basic solution truly cannot tell you anything useful. It’s sheer hubris to believe otherwise.
- The entire interview process, expectations, and precise timeline should be explained to the candidate at the start. Each interviewer should clearly explain who they are and how to contact them later if needed. And each interviewer should have knowledge about the candidate, their work history, etc., and place a higher value on learning more about those items than hurrying up to ask their favorite trivia questions.
- Rejections should always be sent out in a very timely manner after the interview. It should include meaningful feedback about all relevant factors that went into the decision, and should offer the candidate a genuinely sincere option to provide feedback. Even if the candidate feels hurt, bitter or angry at the decision, you should thank them sincerely for taking time to help you by pointing out ways your process might have been unfair or suboptimal.
One way to sum all this up is to say interviews should be humane. Use common sense about being humane to this person. Additionally, if you believe detailed code trivia or tests gives you better quality info about a candidate than technically probing their experience and skills in conversation, you are wrong, and this mistake will totally corrupt your hiring process.
A manager that I adored that I had silently chosen not to accept the offer because I didn't show up on my first day. Turns out the recruiter had told me a different start date. And this happened twice more with new people that started, just HR bungling the process and seeming to reinvent it with each new hire.
Even just a generic rejection email sent out at all... sometimes seems like the most you can expect.
When they are canned questions, there is at least one small issue and one big issue.
The small issue is that people will research and memorize solutions for common questions like “how to make Twitter” or “how to rank a newsfeed” or “how to ensure fault-tolerance in a distributed file system” (yes, the memorization even covers how to respond to questions in a ~45 minute open-ended conversation). If someone looks good on a design question about e.g. a Twitter clone, it doesn’t tell you much. If someone does bad on it, it probably also doesn’t tell you much unless they totally can’t parse the basic concepts (which should have been weeded out way earlier).
The bigger problem is “Guessing the Teacher’s Password”[0] and applies even when you ask non-standard questions that someone couldn’t have memorized ahead of time.
As the interviewer, especially if you were prepped in some interview training or team meeting, you will have preconceived expectations about what the “right” answers are and what the right progression of concepts, features, and details would be like.
As a result, you’ll favor candidates who happen to “guess” your preferred way of looking at the discussion, even though there could be many perfectly valid alternative ways to think about or discuss the problem that approach it differently, with a different sequence of questions or iterative enhancements.
At best this introduces some unnecessary arbitrariness into the pool of qualified candidates. At worst, you are unwittingly self-selecting for people who approach problem solving the same way you do, and are therefore reducing diversity of thought. If the big design question is also unrelated to the day to day job, then this arbitrariness is even worse: rejecting or self-selecting entirely based on your preferences about a toy exercise.
[0]: < https://www.lesswrong.com/posts/NMoLJuDJEms7Ku9XS/guessing-t... >
- Do read my CV
- Look at my GitHub repo.
- Ask what were the technical difficulties of whatever project calls your attention/looks relevant, both on my CV or GitHub.In theory this sounds good to me, but it might be terrible if I needed a full paycheck right away, idk.
The circumstances of a (forced) meal/drinks outing are almost certainly quite different from those you'll experience on a day to day working basis.
(Or if they aren't, run, that's a toxic environment right there.)
A short onsite interview where we discuss my previous work experience and your current needs is the best way. Programming skill should have already been proven beforehand, but FizzBuzz never hurts. It should be no more than an hour long.