Sorry, but you are being scammed. You are selecting for sales skills, not technical skills. Read what you've written. You're judging someone based on how they presents themselves - not anything about technical ability.
I have interviewed many people who are great at doing this impassioned sales speech, but are terrible at actual engineering. And in fact, many good engineers are not good at selling themselves in this way - they have spent most of their lives deep in code, not working on their social skills like normal people.
Why not actually test them similar to what they're going to be doing? If it's a sales or advocate role at your tech consultancy, well then sure, your approach works.
You're asking the parent commenter to set aside eight years of personal hiring experience, over which time "every person I've ever hired who has passed that part has ended up in my 'great hire' category" (assuming, that is, that you've read what he/she's written).
Can a candidate lacking the technical skills go deep into details the way the parent commenter describes?
Here's the fundamental asymmetry: what makes a good programmer great is their ability to build a cathedral brick by brick, alongside the architect, the other builders, despite the external circumstances, accounting for complications along the way. Ignoring the connotations of waterfall design that "cathedral" might invoke.
Building a complex system with many components takes weeks, even months, whether or not you're talking about MVP's, or service oriented architectures, and whether or not you're iterating rapidly.
A weak engineer will be fine for a few weeks, but the complexity will catch up to them. A strong engineer pushes that bar much, much further out. Possibly indefinitely.
Problem is, how do you tell that you're talking to that kind of person when you have only a few hours? It's an extremely difficult task because you must evaluate a person for a > 6 month job in under 6 hours. No matter what you do, you're going to have trouble.
I withdraw this somewhat rhetorical question. I should never have asked it because it's not the point (and it invites answers out of the original context that overlook "the way the parent commenter describes").
Here we have two ways of evaluating technical candidates, just two of perhaps many: One seems to be more arbitrary and unreliable than many have assumed, and the other is very time-consuming, doesn't reduce to graphable data and requires a really good interviewer.
Please just recognize that having candidates jump through technical hoops is not as solid and objective a method of evaluation as it might seem to you, and could even filter out certain kinds of great candidates. Where at all possible, please try to treat the human being under evaluation more like a human being and less like a horse.
That's what most bosses/salesmen excel at doing everyday.
I've found that most people who have poor communication skills are not good engineers either* and the two might actually be related.
*Except for substack
More often than you'd think, alas. I'm going by about fifteen years of personal hiring experience, for whatever that's worth.
Coding exercises might not be a great measure, but as far as I have experienced, they are better than other items out there.
On the other hand if you mean that you've discovered during your interviews that candidates more often that we'd think had been trying to fool you -- and that's why you didn't hire them -- well then that doesn't sound much different from the above person's eight years of experience.
I don't think anyone here would argue that there isn't a significant number of candidates for technical positions who BS about their technical skills.
Frequently people do well on the technical-not-actually-coding portions and very badly on the please-write-code portions. That is, if we didn't ask the specific coding questions, we'd be hiring people they disqualify.
At those places we less frequently hire people that just can't code -- though I've been around for that too, usually when we look at a resume and say, "oh, we don't need a coding test for him, he's been writing important code for years in a way where he couldn't hide lack of ability."
It would appear that a resume is a poor way to verify that.
Positions for things like security, as another commenter mentioned, are very much experience driven. Java is another simply because it has a very high learning curve to become really adept with it. It's doable, but I'd extend the expected ramp up time to longer than 2 weeks.
There's nuance to everything. I didn't mean it to come across as if that was the only factor in hiring.
Great engineers think beyond "how" and ask the "should" questions as well. Mediocre engineers glue things together in a haphazard way with little thought about what's the best way to write things. Caring about maintainability, comprehensibility and extensibility is partially a function of experience, but I've met plenty of experienced engineers who still write bad code and design systems poorly. It has no correlation to how much of a tinkerer and curious person they are, in my experience.
I also ask candidates to code on a realistic problem. It doesn't involve any "fancy" algorithms or "tricks". What I want to see are the coding style, attention to details, and of course, if the candidate is comfortable at coding.
This approach has been working well for senior candidates. It is much harder to interview new graduates.
I have been reading a quora answer about why most of the developers fail FizzBuzz test and the author differentiates between Programming and Engineering and he says that programming is aimed at making the machine work, where as engineering is more about the artistic aspect of building software (which is highly dependent upon experience and tenacity to get the job done). That people wanna hire Engineers, but they test for Programmers.
This got me thinking about a common pattern I have been observing. Most of the algorithms I implement in a real world code are very basic. Most of the work I do, revolves around the fact that my code should be easily understandable to other people (and sophisticated algorithms prevent that), that people should be easily be able to modify it, repurpose it or expand it
In real world, if I ever was asked to implement FizzBuzz, I wouldn't even open my editor until I understood what is it going to be used for, what future features it will have, and what existing code will it work with. Once I understand it all, I might never write the code which most people write (or I myself write) during a fizzbuzz interview.
Maybe it's time to create a Software engineering fizz buzz rather than programming fizzbuzz.
I like the "Software engineering fizz buzz" idea. For backend engineers, I usually ask the candidate to implement a commonly used API in a language she/he is most proficient at.
The interviewer will give a simple user story to the user. "As a user I want to be able to add two numbers".
After the candidate implements that, "As a user I want to be able to subtract two numbers". At this point look how the candidate continues. If he implements a class Calc with two methods as Add and Subtract, then give him 5 points, if he just writes another method then zero points.
Then ask him to add multiplication functionality. If at this point he encapsulates the code as a class, good, if not then make him do that and let him choose the encapsulation(with no bonus points).
Now the point of this exercise is how good of a job does a developer do of figuring out what does the client want especially when client himself doesn't know what he wants.
Somehow once the Calculator class is implemented, the next user story is to "create an interest rate calculation method which offers different interest rate based on credit rating", the idea is the new user requirement is a client asking for to do something quite weird. You can't JUST add this method to the Calculator class. This is the point where the candidate shows how good he is in being an artist with the code.
Sorry I typed it all on mobile, so laziness got to me. But it seems like that you missed the point of the test by a fair margin. The test allows you to judge overengineering too. The whole idea is, give them scenarios like this, suitable to your values and business needs. Every language has abstractions, and it is the decision to figure out good abstraction vs bad abstraction vs no abstraction.
Making a calculator class is an overkill IMHO, and this is precisely why the next task is to "create an interest rate calculation method which offers different interest rate based on credit rating", the whole idea is, that here any developer worth their salt, will be separated from the chafe. Of course, you will need to help them a bit to steer in the right direction, but the test isn't about knowledge, but of their perspective.
> If he implements a class Calc with two methods as Add and Subtract, then give him 5 points, if he just writes another method then zero points.
Sorry for misunderstanding your whole point (no sarcasm, my english is not ideal)
The fundamental point is, who can best figure out the requirements of the customer, and write code which makes most sense with least amount of 'future problems'.
Do you do that on the spot or is it a "take home" assignment? I've known many solid programmers (myself included) that could code anything you want, but if you put them in a room, sit there and watch them do it, they'd freeze up. On the other hand, if you give them a project, give them a timeframe to develop it, then have them walk you through what/why they did, they would absolutely excel. It's sitting there in front of someone(s) and the expectation, that would just cause them to freeze up.
As long as the candidates get the logic flow on the solution, can write code down in well-formatted manner, pay attention to corner cases, it doesn't matter if the candidates actually complete the coding, if I think given enough time in a real work environment that the candidate has no problem in doing it.
There are some red flags I pay attention to. For example, readable code is very important to me since we work in a team and we spend more time reading code than actually writing it. Once we had a candidate. he got the coding right, but his code was very hard to read. It reminded me of some obscure C code in the past that one statement was trying to do many things so that it became very convoluted. For me, it is not "smart". It is bad engineering.
I just ask them to bring code, and tell them we're going to talk about it.
It doesn't have to be their own (it normally is though). It doesn't have to be good code (nobody has yet brought bad code, but I wouldn't really care).
I would rather talk to somebody in their own code and language. If they can't explain it to me, then that's a data point, too.
I think one possible phrase closer to the heart of things would be "aesthetically focused" as well as detail focused -- they care not only about the details of the functionality, but about the "technical beauty" of their solution.
It still takes a village to get to this point, which means even in the best case, we're all going to contribute some shitty code to the world because that's just the learning curve.
You can, of course, go a long time without peer review or having ever been shown a better way to do the stuff you just did.
I would not hire someone that has a list of a hundred 'shoulds' which need to be met for any project to be shipped. That's a recipe for never shipping.
Can they really be considered experienced then? Or are they basically just people who are first year engineers repeated for 5, 10, 15, etc years.
They may be able to hack around, write a for loop, track down a bug....but you're not going to get the same caliber of work from someone who first saw python two weeks ago compared to someone whose been using the language for 5 years on real projects.
I don't mean to be combative, but so many job recs and interviews expect X years of Y. How do you get that time it? You learn it, right? I didn't used to know Python, but it was obviously useful for my job. So, I installed it and learned it. I was producing useful results for my company very rapidly. Sure, a few years later my skills are more well rounded and 'pythonic', but really, so what? This is how every. single. one. of. us. learns.
My job is only interesting to the extent I am learning new things. You are only going to hire drudges if you require the applicant already know everything needed for the job. How boring. Obviously I'm not arguing for hiring a janitor to rewrite Google's deep learning from scratch; some ability is required. But picking up basic skills in a new language? Easy peasy. Nothing to it. That's our job.
By having commits on Github numbering in the middle five digits, of course! The only downside is eventually employers will move on to some other arbitrary bullshit metric, and you'll have to start over.
In a small company, everyone wears a bunch of different hats and you will often be asked to do new things outside your official role.
In a large company with bad management, staff turnover will ensure that they regularly find themselves short on skills, at which point you can stick your hand up to pick up the slack.
Either way, if you consistently deliver the goods then they'll keep coming to you with new challenges.
Luckily this is >75% of large companies, IMHE.
Careful. You probably need to define your terms more clearly.
A CS student who knows Java (4+ years of experience) is going to turn out very different programs from a 20 year veteran of Erlang who is just learning Java.
Even with bad Java idioms, the veteran is very likely to be turning out much better code because he is thinking about the underlying architectural issues (failure modes, recovery, concurrency) with far more experience.
Yeah, I watched this play out in real time when I paired them. It was actually really enlightening and entertaining.
I also found out I didn't know as much about either Java or Erlang as I thought I did.
Careful with that assumption. While there may be instances where this is true, I've met many veterans that couldn't think outside the small specialty they had become locked into.
Idioms are powerful in that the shape how you think about a solution within a fixed language. They shape your thinking and the shape of your thinking changes what solutions you can conceive of. A veteran that shows interest in a broad range of topics will have more failure experience and will be able to offer better results.
It's the difference between 10 years of experience, and 1 year of experience repeated 10 times
[1]http://archinte.jamanetwork.com/article.aspx?articleid=20389...
Perhaps. But I would take contention with a CS student claiming 4+ years "experience" with Java unless they were referring to something outside of class work.
When filling a position though, you're usually not comparing "was handed my degree yesterday" candidates with 20 year veterans. . . they're demanding much different compensation and degrees of responsibility.
A more apt comparison of my point would be a 20 year veteran of of Erlang who says "oh, yeah, I can pick Java up. Never seen it, but it'll just take me a couple of weeks." is not, in any way, going to produce the same quality code as a 20 year veteran of Java of relatively comparable experience and general skill.
> A CS student is going to turn out very different programs from a 20 year veteran.
I have seen a company pay someone 100$/hour to learn a new language as part of a 6 month contract. They were producing better code than the company's staff within 3 weeks and finished the project ahead of time.
Granted, he was an EE not a software developer. But, deep knowledge of a platform is often more dangerous than helpful. The surface layer tends to be the least buggy parts of most systems.
PS: I wish more people heard "Let's use reflection!" as "Let's use regular expressions!" for similar reasons. Yes, it can help, but you can also dig a ditch using grenades...
Everytime I've seen it used, it turned into a quagmire of subtle regressions, strange effects at a distance and extremely brittle code.
I think the best pattern there are:
1. Thou shalt never write code that uses reflection on its own code base.
2. Thou shalt never use reflection unless all other options have been proven worse.
Which leaves mostly unit test frameworks for some reason...
But then, my opinion may be unduly influenced by Java vs Ruby.
Most job fills aren't going to be putting the new employee in charge of "greenfielding" the architecture of a brand new app, they'll be doing maintenance or build-out of an existing codebase, giving them plenty of time to ramp up on the fine details of a language while still being productive working with the existing code.
Someone who has been programming for a while but is learning a new language will have a ramp-up period when their code is ugly or unidiomatic, and they will take longer to write it, but it will capture the correct algorithms and abstractions. Compare that to someone who is inexperienced and writes a pile of exponential-time spaghetti that is slow and unmaintainable in any language.
From the opposite side of things, someone who's only been using the same tools for 5 years is probably going to struggle picking up new tools. For the projects I work on, it's rare to use the same languages and tools for every project. I'd rather have someone that understands how to write good code in general and knows multiple programming paradigms instead of someone claiming to be a guru in a single language.
If someone knows Java and JavaScript well for example, is it really going to take them more than a few weeks to be productive in Python (especially if you have someone on the team helping with picking the appropriate libraries to use)?
Therefore, a hiring manager should have the ability to tell which engineers are good interviewers, and give more weights to their opinions. Pay extra attention to those interviewers who is more of a big talker and less of a listener, if you have to ask him/her to interview. If one can't be a good listener to his/her teammates, I can't imagine he/she would listen to and observe a stranger with any substantial effort. Unless he/she is a genius in reading people, his/her feedback can be mostly ignored.
I had a HR interview team recently ask me about a particular rule governing the admission of evidence in administrative or arbiter proceedings. I started by asking whether they wanted me to explain admission generally or specifically how it differed between the two.... total blank faces. I asked whether I should first explain relevance ... they all nodded.
"Explain it as you would explain it to your students."
"That's at least a three hour lecture."
"Ok, can you do a 10 minute version?"
"Yup."
People who have natural abilities chronically underestimate their effects. Some, regardless of interests, will always struggle more with certain physical or mental tasks.
Interest is important, but ignoring ability is not the right way to interview.
The only real differentiating factor is your tolerance for ramp up time. I expect a programmer to be able to pick up a new language or database within a couple of weeks (tops) in most cases. If I'm hiring full time, that's something I'll tolerate. If I'm hiring a contractor, I'm going to be uneasy about paying high hourly rates for him to learn the job.
The single most effective way that I've found to interview for "interest" is to just get them talking about something they've done before and ask them to go deep into the details. You get everything you need from watching somebody talk, with a smile on their face, about how they solved some problem in a creative way that makes them show some pride. Doesn't really matter what the problem was, if it was a business problem, code problem or hardware problem. The important thing is the level of attention to detail in addressing it.
I've been using this technique for about 8 years now and while I don't make it the exclusive criteria for hiring, every person I've ever hired who has passed that part has ended up in my "great hire" category.