I put candidates through coding challenges on paper. Hate me if you want, but if you can't iterate an array with a for loop on paper, I don't want you on my team. This should be muscle memory.
The truth is that I will overlook simple errors that would be caught by an IDE. What I'm looking for is how quickly you start writing. The problems I pose are extremely simple (e.g. I start with "write a function to return the area of a circle" and get slightly more challenging from there). If you can't do that on paper, you should look for a different profession.
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
If we're talking pseudo code, I see paper as valuable. But it is annoying. The reason has a lot to do with the style of coding. When I code, I sometimes decide to move functionality into own functions, delete or add lines etc. That just doesn't work the same way on paper. It completely destroys "the flow". And having watched many developers coding, I learned that such behavior is quite individual and additionally varies depending on IDE behavior, language, followed code style. So no, overall not a paper fan.
I probably should have been more clear. These are functions of 10 lines of code or less (some are 1). I don't care if you can write a bubble sort or Dykstra. It's completely useless. I just care if you can carefully read simple instructions and quickly write a loop or a couple lines of code to solve it. I don't even care what language it's in. In fact, I have prepared sheets with function definitions already written in the language they said they liked best on the phone interview to make them more comfortable with it.
Let's be honest - if you can't write a one liner on paper to solve the area of a circle given a radius, you have some work to do before you're ready for this line of work.
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Well, I don't necessarily disagree that one should know that. But what for? The way you describe it sounds more like you boiled it down to a pure math question.
So not sure if I agree about that being an indicator of whether or not that makes you ready for that line of work.
Exactly. It's easy to forget that half the purpose of screening is to weed out people who aren't right. Such a question may not be able to quantifiably prove any one candidate is qualified, but we can determine several candidates aren't.
The functions I'm talking about are simple enough that moving code to another function is overkill. None of them require more than 10 lines of code. I'd be scared if they did that.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I put candidates through coding challenges on paper. Hate me if you want, but if you can't iterate an array with a for loop on paper, I don't want you on my team. This should be muscle memory.
The truth is that I will overlook simple errors that would be caught by an IDE. What I'm looking for is how quickly you start writing. The problems I pose are extremely simple (e.g. I start with "write a function to return the area of a circle" and get slightly more challenging from there). If you can't do that on paper, you should look for a different profession.
If we're talking pseudo code, I see paper as valuable. But it is annoying. The reason has a lot to do with the style of coding. When I code, I sometimes decide to move functionality into own functions, delete or add lines etc. That just doesn't work the same way on paper. It completely destroys "the flow". And having watched many developers coding, I learned that such behavior is quite individual and additionally varies depending on IDE behavior, language, followed code style. So no, overall not a paper fan.
Yeah, I have used "on paper" a couple of times, but it really is incompatible with flow.
An analogous (and much more insightful) task is to have them flowchart a described algorithm on paper.
I probably should have been more clear. These are functions of 10 lines of code or less (some are 1). I don't care if you can write a bubble sort or Dykstra. It's completely useless. I just care if you can carefully read simple instructions and quickly write a loop or a couple lines of code to solve it. I don't even care what language it's in. In fact, I have prepared sheets with function definitions already written in the language they said they liked best on the phone interview to make them more comfortable with it.
Let's be honest - if you can't write a one liner on paper to solve the area of a circle given a radius, you have some work to do before you're ready for this line of work.
Well, I don't necessarily disagree that one should know that. But what for? The way you describe it sounds more like you boiled it down to a pure math question.
So not sure if I agree about that being an indicator of whether or not that makes you ready for that line of work.
That one is a softball question to get them loosened up. No it doesn't indicate they're ready for the job but can certainly indicate they're not
Exactly. It's easy to forget that half the purpose of screening is to weed out people who aren't right. Such a question may not be able to quantifiably prove any one candidate is qualified, but we can determine several candidates aren't.
The functions I'm talking about are simple enough that moving code to another function is overkill. None of them require more than 10 lines of code. I'd be scared if they did that.