Don’t ask a potential candidate to “speak” code over the phone. I’ve had interviews like this before and they’re terrible. Any programmer worth their salt can see it’s very easy to write code like this:
|
1 2 3 4 |
if (x % 5 == 0) { System.out.println("Buzz"); } |
But, it’s another thing to say it. “if space open parenthesis x percent five equal sign equal sign…”, you get the picture. You’d think it’d be obvious, but I’ve been asked to speak code on far too many interviews.
There is this saying that “A’s hire A’s and B’s hire C’s”. The idea is that the best employees (A’s) are smart and want to be smarter. They also don’t want to be babysitting a bunch of bad employees (C’s) and cleaning up their messes. That’s why you can trust A’s to hire other A’s. The problem with average employees (B’s) is they feel insecure about their position on the totem pole. They are really concerned that their job is in jeopardy. That’s why, if given the chance, B’s would hire a bad employee (C’s) because it makes them look better. That’s the theory, at least.
I go to a lot of networking events where non-technical people have an idea, but they don’t have the technical know-how to build it themselves. They want to hire a CTO or a developer, but they don’t know how to evaluate their skills.
I am going to provide some ways you can vet these people. None of these methods will be perfect because the best way to vet a software engineer is to work with them. But it can make you more confident in your decision.
