I consider it a miracle that I got in. I thank God every day.
Did the interview matter, in terms of technically assessing for what I do day to day? Very little.
- Look at every resume, pass/fail fast. Ask the Recruiter or HR to give you more resumes, not less (they typically are not equipped to assess techncal resumes)
- 15 minute phone screen. Make sure the role fits expectations, make sure the salary range is acceptable, get and give a verbal background.
- At-home code task. Something that takes an hour or so to get functional. More if the interviewee wants to put some spit-shine on it. I ask for a git repo back, and I tell the applicant up front that the code will be used to springboard the technical interview.
- 2 hour technical interview, no live-coding. In person or virtual. This involves other engineers from the org -- we code review the git repo. For each code task I have a set of 3/4 "Product Manager" style enhancement requests, we then verbally talk through the technical changes & challenges for each ask.
- 15 minute chat with the CT or VP or whomever is my boss.
- Extend an offer.
It's all very real, and very pragmatic, and shouldn't suck more than 4-6 hours out of an applicants life, total. I want to be able to extend an offer within days, assuming everyone's schedule aligns. There is 0 reason to go deeper. If you cannot asses someone's technical chops in a 2 hour conversation, you shouldn't be involved in hiring. If you couldn't complete the coding challenges to your own satisfaction, you shouldn't be involved in hiring (there are engineers I've worked with who are no longer involved in hiring due to unneeded pedantry that they themselves would not tolerate if the shoe was on the other foot).
Sounds like a decent place!
We are currently revamping our hiring process and the questions we keep asking are “Would X, Y, Z pass this or get hung up on this coding test, question, etc”. As in taking care to think about how existing employees would do on the new process.
I sent it to almost all engineers on the team before we started using it and none could hit a 100% on it.
We still went ahead and started using it in our process. Non surprisingly, most folks would fail to get a perfect score but we still use it to see what they tried and also one of the following interviews was a review of the whole test with the applicant as we discussed their thought process and what other odeas they may have come with since they took the test.
Our intention with the test was mostly basic problem solving skills and was the first step in the process so it also worked as a filter.
We had an application developed in-house (by me) and the new hire was to take it over -- this implied needing somebody who could become productive quickly and think on their feet. The app itself wasn't insane, just pretty standard (but bespoke) PHP/MySQL/JavaScript that powered a bunch of client sites, so I put together and proctored a "code test" to probably 15 applicants over the course of a year or so.
The extent of it was sitting them down in front of a computer in the office with a couple of simple tasks to be completed (outlined on paper), and a folder of files on the desktop. The tasks themselves were then almost entirely-documented in a big comment at the top of the relevant entry file (index.[php|html|js]). It should've taken somebody experienced an hour to do a decent job at -- yet, not a single person was ever able to complete it. Very few even got close, even though 80% of the work was literally done in the opening comment section, waiting to be copied and pasted. Almost nobody asked any questions whatsoever either, which I've always found strange.
Anyways, I did end up moving on and later participated in many dozens of incoming developer interviews at a much larger place -- other interviewers had their very-technical approaches, but I never again asked anybody to complete a coding task or whiteboard anything. I would simply ask them to walk me through where they've been, what they've done (built, contributed to, etc), and what they like to do. You can tell almost instantly when somebody is full of shit if they can't talk about previous projects in-depth or with fluency (or simply admit that they have no real experience and are hungry to learn).
The interviews where I would report back "not full of shit" turned out to be a bunch of great hires (including one guy who I had actually interviewed years prior with the doomed code test!)
Take all that for what you will -- my personal opinion is that companies are missing out on some really great people specifically because of the interview process, but I also get the feeling that lots of companies aren't actually looking for the people that would be the best hires -- good-enough / "warm body" hires promote business continuity, and that's really better for the bottom line in larger organizations.
My skills have declined since I started. I've gotten older and more cynical, so they'll see way less potential. They'll also be wondering what's wrong with me that I'm still a midlevel dev after a decade of experience (hint: I have a disability).
It doesn't really matter if I'd pass today. Although many of these points come up or apply to my year end evaluations (it's not pretty).
I walked into a conference room to meet with the CTO, CFO, and lead dev. A huge whiteboard in the room, I was like _sh*t_.
But the test was basically a few sheets of paper with some technical questions, along with a conversation. There was a take-home as well, which annoyed me because I already answered ~12 meant-to-be tricky questions, drove ~45 minutes, spent 30 minutes waiting for everyone, and an hour conversation. But it was worth it in the end.
I have flat out refused a few companies interview processes in the past, telling them I don't have the time nor patience for the games. I still managed to get those jobs, surprisingly.
....sure I could pass it.
