211–220 of 289 posts
1) Casual talk. Does this person have basic communication skills and are they someone you want to deal with regularly for a long time?
2) Give them an actual coding project to do. Pay them for it. Pretend it's just like real work (it should be).
3) Review their code with them. (both to make sure they are the ones who wrote it and to explore their thinking process)
I think the most useful interviews are ones with three parts: 1) Casual talk. Does this person have basic communication skills and are they someone you want to deal with regularly for a long time? 2) Give them an actual coding project to do. Pay them for it. Pretend it's just like real work (it should be). 3) Review their code with them. (both to make sure they are the ones who wrote it and to explore their thinking…
I’ve been doing my tech stack long enough that I can smell bullshit and for me I need to know that you can be a good communicator (tech stack is teachable).
I don't often interview developers, but when I do, I try to get into a situation where the candidate leads us through solving a programming problem, and the issues that come up. The most satisfactory case was where the candidate and I jointly investigated an issue that neither of us had the answer to.
Unfortunately, this is not an approach that many people have much experience with, and it seems unfair to penalize people who find it disconcerting, but when it works, I think it is most satisfactory approach for all concerned. It is not easy to automate either the practicing for or execution of this style of interview, which may or may not be a disadvantage.
Earlier quoted context omitted.
When we were looking for a developer for our team, we created a set of small coding challenges testing the candidate's knowledge of the most relevant aspects of the language. We wrote automated tests for these challenges, and the main bulk of our interview was having the candidate solve them. The advantages to that approach, as I see it, are: - the developer is tested for knowledge that is most relevant for their cur…
The advantage of using something like codility, or making it a take-home thing, is that they can do it in their own time, free from the stressful environment of an interview.
Many people here will disagree with what I'm about to say, but if you're going to give a coding challenge... I like hackerrank/codility style coding challenges. gasp They're timed. They're run against a standardized test suite. And they have support for many languages. It's really unfortunate the number of companies that give custom take home coding challenges that run the gamut. The problems with which are manifold:…
When we were looking for a developer for our team, we created a set of small coding challenges testing the candidate's knowledge of the most relevant aspects of the language. We wrote automated tests for these challenges, and the main bulk of our interview was having the candidate solve them. The advantages to that approach, as I see it, are: - the developer is tested for knowledge that is most relevant for their cur…
I get the advantages, I guess everybody does, but there are disadvantages too.
I think the most useful interviews are ones with three parts: 1) Casual talk. Does this person have basic communication skills and are they someone you want to deal with regularly for a long time? 2) Give them an actual coding project to do. Pay them for it. Pretend it's just like real work (it should be). 3) Review their code with them. (both to make sure they are the ones who wrote it and to explore their thinking…
I think the most useful interviews are ones with three parts: 1) Casual talk. Does this person have basic communication skills and are they someone you want to deal with regularly for a long time? 2) Give them an actual coding project to do. Pay them for it. Pretend it's just like real work (it should be). 3) Review their code with them. (both to make sure they are the ones who wrote it and to explore their thinking…
I really like the idea of #2. I've never actually seen this done before but it seems like micro-internships (1 month) would be invaluable. Bring the candidate onboard for 1 month and start paying them their real salary. At the end of 1 month it should be clear whether they are a good fit for your team or not.
Earlier quoted context omitted.
Yeah, those challenges are explicitly timeboxed, and I know there is a relatively objective grading criteria (which is often as simple as “passes enough of the hidden test cases”). I refuse to do other types of take home challenges, but am fine with these.
The hidden test cases can be super frustrating, especially when you're passing 7/10 and the timer keeps ticking down. It's impossible to debug besides just staring at the code and guessing what else they might be looking for. Then to ultimately have the company immediately go, "Sorry you didn't check enough green boxes. You've failed. Goodbye."
Earlier quoted context omitted.
I really like the idea of #2. I've never actually seen this done before but it seems like micro-internships (1 month) would be invaluable. Bring the candidate onboard for 1 month and start paying them their real salary. At the end of 1 month it should be clear whether they are a good fit for your team or not.
What you're proposing is basically the same as a notice period (at least in the UK), and neglects that it's still high risk for the candidate. To be able to come in and work for a month they have to leave their existing job. I'd have to be pretty damn sure I'd have no difficulty passing my probation in order to risk being out of work.