Strong software tips from 2000 that are 100% valid today
joelonsoftware.com
joelonsoftware.com
Its interesting to note that other software development methods such as Agile do not mandate the use of things like source control, issue tracking and CI, and therefore make it very possible to set up completely dysfunctional development teams. Refreshingly, the "Schedules" point is in complete opposition to Agile. The Joel Test is an actual thing that you can use to make your software development run more smoothly.
There is also a more important point to be made about the Joel Test. While most software development method"ologies" seek to subtly shame, juniorify and undermine developers, Joel's writing seeks to understand, validate and empower them. For this alone he was ahead of his time, and he deserves a lot of credit for the pieces he wrote in the early 00s.
Writing code in an interview is a great way to tell if someone has social anxiety or feels pressure to get a job. It's a terrible way to tell if they're good at writing software.
Do a (paid) take-home test, ask them to review some fake code, or talk to their former coworkers instead. There are lots of shy, anxious people who are fantastic employees and never make it past a stupid whiteboard.
The take home test gives you a clearer idea of their problem solving skills, but you should probably trust that they know how to write software before getting to that point.
However, if you are looking for a team member that can communicate what she does and how she does it, then you need some interaction.
The only difference is that people being interviewed are given more control over their schedule and environment when working on the exercise.
IMHO companies who do mostly whiteboard or live coding exercises are passing on some very good candidates who don't perform well in this specific setup but are great collaborators.
> Yet, every day, programmers are hired on the basis of an impressive resumé or because the interviewer enjoyed chatting with them. Or they are asked trivia questions (“what’s the difference between CreateDialog() and DialogBox()?”) which could be answered by looking at the documentation. You don’t care if they have memorized thousands of trivia about programming, you care if they are able to produce code. Or, even worse, they are asked “AHA!” questions: the kind of questions that seem easy when you know the answer, but if you don’t know the answer, they are impossible.
> Please, just stop doing this. Do whatever you want during interviews, but make the candidate write some code.
There is soooo much setup in a modern dev process, build tools, compilers, transpilers, code formatting configs, let alone editors, languages and frameworks you are comfortable in, its not even funny.
You will be asking a candidate to understand a task completely without any prior knowledge, figure out whats the minimum setup they need to work on it successfully, implement the logic in very few iterations and no coding partners or knowledge repos to help them. Preferably with some testing setup, and to top it off you want them to do it in an hour.
As I mentioned it can be done if you are incredibly lucky and know exactly what to do, or have done this before many times in different interviews.
And what do you get in return?
Can a person work under high stress - e.g. are they ok at working in a shitty environment? If everything this should be a red flag as that person will keep shitty envs around and not go out of his way to fix things.
How good are his coding skills? Well not really, you will know that they can do interview tasks - e.g. a small bite sized problems that have easy solutions. Long term planing, refactoring, perseverance, etc. - no signal there.
And worst of all, it tells the candidate that your company/team enjoys high stress, small problem, and making each other uncomfortable. Remember an interview is both ways, and you just earned yourself a red flag too.
Btw, Adam Grant had some podcast episodes about interviewing last year that were really good and showed some companies that actually solve this in a very nice, humane _and effective_ way.
If you happen upon a company where people will judge you for writting shit code in that situation, consider yourself lucky they let you know early. And leave.
But, you do want to see if they are comfortable writing code and working through it. Really simple stuff, like reversing a linked list or fizz buzz or the like - not algorithm development, just simple coding. You want to see how they do it, how they interact with the interviewer. Ideally they will make some mistake and you'll also get a chance to see how they recover.
And yes, it's an interview and they are likely to be highly stressed. You need to take that into account as an interviewer, try to put them at ease, and help them when you see they are blocked, and see how they use that help. If as an interviewer you're just looking for them to 'solve the problem', then yes, you're doing it wrong. People will falter, they will forget an important detail etc - it doesn't prove anything in itself, even if the problem is trivial.
But if a candidate stumbles and can't recover (with help) on the easiest problem, if they are avoiding putting the code 'on paper', if they have no idea how to approach basic problems or slight complications after you get the first answer, something is definitely wrong and must be explored further.
And note, I'm not thinking of a 1h coding challenge, on the contrary, something like one or several 5-10 minute exercises, where you would explore their coding.
Not many people are able to do a 3 month interview so their long term skills can be observed. Part of a good interview process is coming to a decision without using a lot of the candidate's time. They're busy people, and if they don't get an offer, or don't like the offer, it's time they could have spent doing something productive or fun.
I've worked with people who couldn't actually demonstrate the skills I'm looking for in my coding exercise: listen to a problen description, ask clarifying questions, and discuss a solution; write down what the output should look like given an example input; write code that does what you discussed. I don't want to work with people who can't do at least those things.
Yes, writing code on a whiteboard isn't how most code is written. Yes, most problems aren't neatly packaged things that fit all that into 40 minutes. Yes, it can be stressful, which is unfortunate.
It was amazing - no contact with the people required, they know upfront that I am able to code “something” and we can now continue the interview in a more traditional setting.
There was _some_ time pressure but nothing scary, and I could use my own hardware and software to solve the problem. Awesome. Only thing missing as a signal for them was for teamwork, but it nailed the coding part for me.
if your argument is: "but i know a genius programmer who's so socially inept and anxiety ridden that they can't write a loop if someones watching!" i.e. "sum = 0; for (i=1..100) sum += i" then sorry, but good luck elsewhere.
I never saw or heard about that before.
I want every company on Earth to understand this: if you're asking candidate to do a "test" at home, please provide a small compensation/reimbursement. Otherwise it feels like slavery. They can ask 10s of candidates to come up with a solution for a problem for free, and then they use the best one in their projects.
I would like to do that. How do you put the amount in the company books? It can't be salary as they're not yet signed up, they probably won't be able to give you an invoice or any other document. Or am I just being paranoid and let my accountant handle it?
One of the best interviewees I ever had was super quiet and softly spoken initially but he shone when i gave him a laptop and a task. Moreover, he opened up afterwards.
(agree that whiteboards are terrible, but I hate take home tests - 90% of them are ridiculously overscoped. "This 16 hour test should be doable in 3 hours")
Do a (paid) take-home test, ask them to review some fake code, or talk to their former coworkers instead. There are lots of shy, anxious people who are fantastic employees and never make it past a stupid whiteboard."
PDS: First of all, that is an absolutely great comment! You nailed it! I couldn't have said it better myself!
Second (and this is the more subtle point!): If you're a programmer, and you're looking for a programming job, and you have to go through thousands of job ads; thousands of potential companies, and you need a way to "screen the employer" fast(!) -- then simply ask them what their employee screening procedures are -- and if they tell you that candidates come in and write code on a whiteboard (as opposed to a take-home test!), then you can quickly REMOVE that company from the list of companies you're applying to!
Let another candidate waste their time (and possibly a good chunk of their future programming career!) with yet another company that "doesn't get it!".
Think of it like this, for any given problem in Math, there are typically long ways to solve the problem, and then (if you know them!), there are algorithmic short-cuts!
Well, employer psychology -- is like that, too!
Being able to "screen the screener" -- as a result of their screening process(!) -- is a career "algorithmic short-cut"! (I know, how meta, right? <g>)
You don't want to spend time with people who don't understand programmers or programming as well as you do(!) -- because if you do, it will drag you and your programming career down!
Do you use source control?
Do you make daily builds?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?
Can you make a build in one step?
Do you fix bugs before writing new code?
Do you have a bug database?
This is, after all, the company that gave us Windows ME, Vista, and Windows 8, to say nothing of the Zune. Or Clippy.
MS Office is only as successful as it is because of the 1990-2010 Windows monopoly.
No, but I feel like a lot of really bad software has come out of Microsoft since Windows 95
>They're still 75% of all PCs
Purely because of marketing and abusive monopolistic practices in the early days
Even in the 90s Microsoft were known for developer evangelism - Code Complete was the book people touted all the time.