Good points. If you really care about being impartial, maybe have the 2 week period and a blind submission method in which the interviewer does not see when the assignment was completed.
But my rent is due the Friday after next and I need to know if I should send out another wave of resumes.
It isn't but it strikes me we are looking very hard to find a new way to do things, when the old way was pretty damn good.
Sit me down and talk about technology for ~thirty minutes. If I don't have the social skills to successfully do this (minority issue) I likely would not be able to communicate well with a team and thus should not be a candidate anyways. You will then know immediately whether you want to hire me (or progress me to another round) or not.
I then get a call two days later and can progress with my life.
People pretend like all this hiring strategy is for the good of the candidate. It's not. As with everything else its for the good of the company and its investors.
Here's a thought:
Invest in a competent hiring manager who can see through applicant bull shit and identify talent within a reasonable range. Includes basic negotiation skills. And assume the rightful risk that is employing another human being.
> Sit me down and talk about technology for ~thirty minutes.
This is an efficient way to hire a team of good bullshitters. I've interviewed people who did extremely well when we were "talking like professionals" but were unable to do even very simple coding problems.
My bar for coding is really not that high. I don't expect perfect syntax. I don't pick the language. I don't expect "the one answer". I expect people to write code that could work after syntax and small bugs are fixed, and most critically, I expect people to be able to discuss their code meaningfully.
Unfortunately, "ability to write basic code" and "ability to talk like professionals" are not tightly correlated. And I expect both of these things from dev candidates.
I disagree. I have yet to meet anyone who is faking it and cannot be cracked in 5-10 minutes of carefully-directed prodding. In fact, I don't see how it is possible to do extremely well on the "talk like a professional" part and not be able to write basic programs, unless you and I have very different concepts of what "talk like a professional" means.
> I have yet to meet anyone who is faking it and cannot be cracked in 5-10 minutes of carefully-directed prodding.
Coding is a skill largely separate from other critical dev skills, e.g. design. Someone can legitimately have deep knowledge of, e.g., how to build a 3-tier service architecture without actually being able to code. This isn't "faking it". It's a different skill. You can study database partitioning strategies and learn about the latest and greatest frameworks for writing web pages and APIs without ever writing a single line of code. And sure, you can try to probe deeply enough to expose where their knowledge stops, but you're still not probing for coding skill. There's actually a decent chance that you'll end up probing for trivia which is not a very useful filter. "Oh, you don't don't know the auto-generated C++ class members? You clearly haven't actually worked in C++!" Yeah, right. Anything known broadly-enough known that it's reasonable to assume all coders would know it is broadly-enough known that non-coders could learn it, too.
Even if you could probe deeply enough in conversation to expose that they can't code, you could do the same with a few minutes of actual coding. When someone can't code, it becomes clear pretty quickly when you ask them to code.
> Coding is a skill largely separate from other critical dev skills, e.g. design.
I do not believe coding is largely separate from engineering. There are, of course, other skills that are necessary or desirable.
> Someone can legitimately have deep knowledge of, e.g., how to build a 3-tier service architecture without actually being able to code. This isn't "faking it". It's a different skill.
Absolutely. It is also a level of skill I would only expect or look for in a position that was not going to be doing daily coding, such as a systems engineer.
> You can ... learn about the latest and greatest frameworks for writing web pages and APIs without ever writing a single line of code.
Here I disagree. If you have never used a framework or API, you don't know it. I don't care that you can regurgitate the Javadocs; I care that you know things like its pitfalls, quirks, and runtime oddities.
> There's actually a decent chance that you'll end up probing for trivia which is not a very useful filter.
To be clear, I abhor trivia-based interviewing. What I am talking about is practical engineering tradeoffs between one course of action versus another, preferably supported by direct personal experience in the past.
> Even if you could probe deeply enough in conversation to expose that they can't code, you could do the same with a few minutes of actual coding. When someone can't code, it becomes clear pretty quickly when you ask them to code.
Exposing the level of competence a five-minute coding problem can is trivial to do in parallel with a deep engineering discussion. In fact, I think some sort of code should be part of that discussion. I just don't think it should be the "implement this" CLRS problem. It should be something two-way, more representative of what the job is like on a daily basis.
> I do not believe coding is largely separate from engineering.
I could pick up a cookbook and study how to cook a souffle. I could learn enough about this academically that I could answer basically any questions you might ask. Having this academic knowledge is a good thing, but it doesn't mean I've ever even separated an egg. If you really want to know if I can make a souffle, your best bet is to hand me the stuff and ask me to do it.
> Here I disagree. If you have never used a framework or API, you don't know it. I don't care that you can regurgitate the Javadocs; I care that you know things like its pitfalls, quirks, and runtime oddities.
And here I assert that you're either probing on trivia or probing on things that can be learned without using
the framework (actually, probably both). The pitfalls, quirks, and oddities are well documented in thousands of blogs.
> To be clear, I abhor trivia-based interviewing. What I am talking about is practical engineering tradeoffs between one course of action versus another, preferably supported by direct personal experience in the past.*
So this is an entirely different thing than pitfalls. Now you're talking about designing systems and dealing with tradeoffs. This isn't coding, and I don't believe you can always discover coding gaps by probing on this.
> Exposing the level of competence a five-minute coding problem can is trivial to do in parallel with a deep engineering discussion. In fact, I think some sort of code should be part of that discussion.
I guess I'm confused about what you're asking in an interview, then. Are your candidates coding or not?
> It should be something two-way, more representative of what the job is like on a daily basis.
I think it's unrealistic to try to get the candidate to solve real-world, day-to-day problems in an hour. This isn't what the job is like. "Design and implement this feature" is not a 45-minute task typically. It's typically days or weeks, so asking a "representative" problem in an interview is infeasible unless you're just doing high-level design, in which case it's not predictive for coding ability.
I worked with a team of these before. You can rule our certain types of people with tech questions (i.e. never coded before, only coded hacked, etc.). You cannot rule out
* People who read a lot of blogs so know the lingo, but never code
* People who get the theory but can't actually implement something that works without bugs
> People who read a lot of blogs so know the lingo, but never code
I think this is where my definition of "talk like a professional" may be more strict. I'm interested in understanding, in opinions, in the actual engineering.
> People who get the theory but can't actually implement something that works without bugs
Having spent most of my career working with PhDs trying to design and implement signal processing and NLP algorithms, I have experienced a lot of that. Given the proper attitude, it is fairly easy to correct coding deficiencies if someone really understands what they are supposed to be doing.
> People that over-engineer simple things
The greater offenders are fairly easy to detect in a directed technical discussion. The lesser offenders are fairly easy to correct in code review, again given the proper attitude, as they are unlikely to be doing things that require major refactoring.
In short, I think I place much more emphasis on engineering as opposed to coding. My experience has been that any coding issues people with good engineering skills and an attitude worth hiring have are quickly and easily corrected. You cannot really understand the engineering of a system without being able to code it. You might not be as efficient as someone else, but you are capable.
* People who have been on a team long enough to learn how things should work but lack the skills to really do the coding.
I phone screened a guy fairly recent who had a very long background (~20 years) in a pretty security-conscious field. He did very well in open-ended design discussions and was able to explain his prior work very well. He couldn't code trivial binary tree operations, though. I can only assume that someone else on his team is carrying most of the coding burden. This guy might be great at a PM-type job (or not, I don't interview for those jobs), but not as a dev.
I feel like there is some detail missing here. What constituted doing "very well" on the open-ended questions? How deep into the engineering did you get? Since you mentioned he "might be great at a PM-type job" it sounds like you didn't go very deep on int.
>Invest in a competent hiring manager who can see through applicant bull shit and identify talent within a reasonable range. Includes basic negotiation skills. And assume the rightful risk that is employing another human being.
Problem with that is it's hard to find one. It's gotta be someone with pretty good coding skills. This person would then have to share their time between either coding head-down or managing coders, either of which are time-consuming and intolerant of disruption.
One idea I had was you could have mutual feedback. A bunch of people would after a while have anonymous input on each other, giving you say 10 coder's impressions of a fellow coder. This wouldn't have to be quizzes, half hour coffees could do.
It isn't but it strikes me we are looking very hard to find a new way to do things, when the old way was pretty damn good.
Sit me down and talk about technology for ~thirty minutes. If I don't have the social skills to successfully do this (minority issue) I likely would not be able to communicate well with a team and thus should not be a candidate anyways. You will then know immediately whether you want to hire me (or progress me to another round) or not.
I then get a call two days later and can progress with my life.
People pretend like all this hiring strategy is for the good of the candidate. It's not. As with everything else its for the good of the company and its investors.
Here's a thought:
Invest in a competent hiring manager who can see through applicant bull shit and identify talent within a reasonable range. Includes basic negotiation skills. And assume the rightful risk that is employing another human being.