I once had an interview for a front-end midlevel position. I had some prior front-end experience in another framework, but mostly worked on midteir and vendor products. I was notified the morning of my interview that it wasn't just a regular interview but a code screen and I could use any language/tools/etc that I wanted. I got there and found out that was not the case - he was not following HR's procedures. So he hands me a Mac (which I'm not familiar with), tells me to use Angular (which I've never used), in Webstorm (I played around with it once), and tells me to build a page to upload a CSV file and display the contents in a table on the page. I have 30 minutes to do it, and then I'll get 30 minutes to dress it up in CSS. Needless to say, I bombed it. I was sort of impressed with myself that I had it almost functional, but yet ashamed at my abysmal evaluation. He said I didn't do well and that he was looking for an expert. Shouldn't you open a senior posting if you want an expert? I asked him why he gave me an interview if my resume listed none of the technologies, with my cover letter stating that I was looking for a change and wanted to learn new technologies. His answer was that maybe I knew the tech from personal projects. I had Android personal projects listed on my resume, so why would I have left off other ones more pertainate to the position? My guess is he was too lazy to read and understand the resume and cover letter, not to mention ignoring HR's instructions. What a waste of both our time (moreso mine since he was on his laptop most of the time).
The phrases "can't code" and can't pass "fizz-buzz" are loosely used. What exactly is fizz-buzz? To me, it's writing a for loop to reverse a string, but to someone else, it's implementing Dijkstra's algorithm in a 40 minute period to solve some made up problem.
A few years back I was working at a company that had a policy that they didn't have recruiters do any pre-screening of candidates who had prior development experience listed on their resumes. I was a frequent stage 1 interviewer for our team, and we gave the candidate an hour to write a function to count the occurrence of words in a string (e.g. "the old man and the sea" -> {"the":2, "old": 1, "man": 1, and" 1, "sea": 1}. Candidates were allowed to select any language they wanted, use their own editor/environment or use a cloud based IDE if they preferred. They were allowed to search any API documentation they wanted, to use any libraries, and were explicitly told to not worry about any edge cases like punctuation, capitalization, etc.
I'd guess about 1/2 of the candidates I interviewed were able to complete the assignment in the provided time, with about 1/4 of them finishing it almost immediately, and another 1/4 unable to even write a single syntactically valid statement or line of code. Some candidates claiming years of experience with a language couldn't even write something that looked at all like the syntax of the language.
Interviewing is a two-way street. Especially with senior engineers. You're trying to convince the candidate to work with you. After all, they could say no, and walk away. Moreover, nobody wants to work for an incompetent boss, and we know there are a ton of incompetent bosses out there. What if I, the job candidate, want to give you, the interviewer, a test to make sure you know what you're doing? Don't worry, I can give you a take-home test to do in your "spare time". ;-)
I don't think companies realize how many potential senior candidates they drive away with audition-style interviews. I've religiously avoided them, just never applying to companies who do them. I'll walk away if I don't like the hiring process.
As an interviewer, we always allow for that! Our standard procedure is to leave last 10-15 minutes for "questions for the interviewer".
People usually ask things like "which stack do you use" and "how many hours per day you work", but once I had candidate ask me programming question, related to the one I just asked them. We've had a nice conversation about algorithms and runtime performance.
The organization of their code tells way more about their skills, than some stupid L33T coding problem that they must solve in 5 minutes.
I’ve interviewed candidates who were clearly not the person on the phone screen, for example.
Given 10 positions you need to fill anticipating these hires will stick around for 3-5 years each.
Pick one:
- [ ] 10 "less experienced" developers for 3-5 years
- [ ] 9 "very experienced" developers for 3-5 years + 1 "no experience" developer for a few months which you'll then have a 90% chance of replacing with a "very experienced" developer
I don't want to hire people who think coding is beneath them or are so far removed from the actual tech that they can't code anymore.