Hiring managers should definitely not be assuming that all programmers do apps in their spare time. It's one thing to expect them to have a code sample (anyone should), but many strong programmers have interests and responsibilities that take them away from computers in their spare time. This doesn't make them less effective or dedicated programmers, so while it's always interesting to hear about the projects of those who have them, it shouldn't be assumed (and you shouldn't consider it 'points off' in an interview if a dev doesn't do side projects)
> It's OK too if an engineer doesn't have any side projects.
I always ask about side projects to give candidates an opportunity to highlight their side projects, not because we require candidates to have side projects.
I'm sure some hiring managers out there have side projects listed under their "must have" criteria, but in my experience the good hiring managers are just collecting as many data points as possible. In fact, I've known many hiring managers who take side projects as a potential risk factor, because they can pose a distraction to the candidate if they become too demanding.
All other things equal, a candidate with extensive side projects is going to have more experience than a candidate who has never worked on any side projects. In the real world, you never find two candidates who are identical in every way except for their side projects. The goal of an interview is to collect as much information as possible about the candidates in the limited interview time. Asking about side projects is just one more place to search for those data points. It would be equally unfair to disqualify side project experience from the consideration process.
In my experience, have side projects is largely a boost for junior candidates who haven't had enough opportunity to build a long professional resume yet. I can't remember the last time we interviewed a senior developer where side projects were the tipping point in our decision making process.
I do agree though, especially in hiring I find it weird to expect people to have their hobby being the same as their job. I'm quite curions if there is another profession where this is the case. Photographers maybe?
It baffles me how much this is an assumption. Like all the developers should not have any hobby that doesn't involve coding.
Then again, maybe those shops just don't hire me, so I don't get exposure to it...
Very bad answer: "Sure, no problem." [2]
Bad but tolerable answer: "Not possible but it's too hard to explain why."
Good answer: best attempt to explain why it's not possible, and the nearest solvable version or what you would need to change to make it solvable.
There's a great Better Call Saul episode (s4e5) where an expert is idenified as a unsuitable (in part) because he insists a project could have a firm maximum duration without caveats about what could go wrong, and he could do it without something it obviously needs.
[1] That's arguably what the unnamed MP was doing when he asked Babbage if he'd get the right answer if he put the wrong numbers in the machine:
https://en.wikiquote.org/wiki/Charles_Babbage#Passages_from_...
[2] At best they might silently replace it with the possible version, but that's still hiding the tradeoffs from you and means they could be misrepresenting other answers.
Or it could simply be thinly disguised ageism. "Hey, I am not saying we shouldn't hire people who have kids... I am just saying I don't trust people who are not passionate enough to write code in their free time!"
You can't rely on a "The very best engineers have a checklist they apply depending on the type of bug." type of framework here -- each "very best" engineer might have a completely different way of doing things.
You have to have at least some questions that are difficult to answer but have a countable range of responses, and watch for specific lapses that can show how well a candidate demonstrates specific experience required in your job description.
For example, if you require some experience in distributed systems or scaling things to many users, have them talk about "Could you talk about an or program you built to scale to n users, what performance or reliability issues did you see (or foresee), and how did you solve them?" Have a loose set of industry specific things to watch out for, like caches, load balancers, monitoring/observability, etc.... You don't have to have the specific knowledge yourself, but if the candidate can explain to you what they did, and how/why, in the framework of the specific experience you're looking for, that's good signal!
This is misleading at best.
Masters do less work than beginners. They have years of intuition built up that let them apply heuristics extremely cheaply and save their energy for solving the novel parts of the problem. There is no 'list'. There is only the verbal part of the brain trying to introspect on what just happened. Sometimes accurately, but quite often not. The ones who get it even close to right become mentors, instructors.
I can spend as long as you like explaining my debugging process and the first time we sit in a war room you'll call me out for not following my own 'list'. Every situation is either unique or the result of a lack of self-reflection (why do we keep solving the same problem over and over? Are we not programmers?)
The biggest danger to people who can't explain at all is when advances in their field arrive and they can't introspect enough to adjust their behavior. There are limits to how much you need to address this in an interview process. For many of these people, they'll already be in that space when you meet them and easy enough to spot.
Having a checklist does help masters. It helps make sure they don’t miss the obvious issue in front of their face.
Checklist manifesto is good reading on this.
Yes, not their references or resume (at a certain stage) or what they're able to prove that they coded, but the things that they are able to come up with to say. Doesn't that strike you as sometimes amazing?
Now, that may be a crazy notion and flawed in many ways, but I came to realize the following. The reason that that is often acceptable is that it frequently is a good proxy for weeding out the unqualified. In this sense:
If someone doesn't even know to say that something is important, or that they solved a problem a certain way (regardless of whether you have proof the actually did it), they probably have never even thought about those things being important.
If someone tells you (just offhandedly) that they solved something by jumping right in to doing x,y,z at the detailed level and coming up with the technical solution (the algorithm), but not the project planning or scoping part of it -- they probably have no idea or experience about what's necessary to plan out a project. They may not be good at estimating or communicating. They may be someone who gets lost in the details. If they have no pitfalls to warn against, probably they haven't even seen how a project has gone wrong before. They are probably not a good candidate for a senior developer role.
Whereas, if someone knows to say that they had to do some top level estimating or quick pass of which solutions would be the best from a cost/resource standpoint, consider the timelines to implement and risk of doing so, how to decide who on the team would be put on the project and in what sequence, etc... Then I know that they at least realize these things are important.
(Yes of course you should probe deeper. And I know that this applies to some kinds of roles and not others, but since the article is about interviewing for non-technical people and is often about hiring for a role requiring a higher-level hiring decision)
It's called off hours for a reason. Being a tutor or a freelancer is a second job.
> Did they use Agile, Kanban, or Scrum? How long was their Sprint?
How about asking whether they used sprints, or formal agile methodologies, at all? Why assume that every engineering org has drunk the kool aid?
Code that works.
I'll take a gordian knot that works over an over-engineered system that fails or never ships. Some of the worst code I've seen comes from engineers who focus on "unit tests, documentation, and refactoring code." Those are all good things, but they aren't #1.
The "done" question is a very good one.
Step 1 - regular interviews.
Step 2 - group interviews including memory check with coding task
Step 3 - this thunderdome you just created.
Still, if you're non technical when interviewing, how would you know the right answers to technical questions?
Eliciting underlying thoughts about problem solving is important, but is more than just saying the right keywords.
If interviewing is not much more than a game of keyword DDR, it makes successful outcomes even more challenging.
Maybe hiring is broken because it is designed for linear working paths, but engineering is not linear.
My reaction to the article was similar. My answer to the title question would be: "Find a technical cofounder you can trust."
I find a much better success rate in not hiring he traditional HR ways. Tech folks are not linear workers with floors and ceilings, they are growing much faster and on multiple layers at the same time.
It’s humorous when non technical ppl try to manage things they don’t understand.
That table seems to be currently being turning in society because of covid, if you ask me.
Technologists will have to move into each area of management, because maybe it’s technologists turn to learn and manage business after such a long time of business trying to manage tech.
Even then I can bullshit my way past all of those questions, and I'm sure most people who can't program can also do the same too.
I suppose very easy things like consistent indentation width might be done perfectly in a codebase, but any non-trivial thing always could be "more X" or "less Y".
edit: Given it's a non-technical interviewer I'd say something like "I never compromise on making sure the business objective is met. I value code quality and documentation but sometimes trade offs need to be made especially in a company this size."
That is actually the worst possible answer I can think of. Pretty much any answer would be better than that. It demonstrates that the person either:
1. isn't honest or
2. doesn't understand basic engineering concepts
That bullshit will work for both technical and non-technical people. Of course do I do follow my own mantra all the time? Does anyone follow it at at all times? No.
You need some kind of coding question at the very least to measure coding ability and a non-technical person just can't do that.
My personal time is my personal time. If there's a good work-related reason for me to put in more hours, fine. But you get none of them that you don't pay me for.
I have had great conversations with someone who has built an automatic pet feeder that lead to the work.
It shows a different facet of one's personality. This, in turn may come in to play when creative problem solving is involved. Quite often even non-technical problem solving around the home can transfer to work
It can delineate the difference between a developer who sees what they do as a profession, vs those who started with it as a passion and continue to solve problems.
There is no talent shortage, and if there is, it's of management, not the ability to write code. The difference between a good developer and a code monkey is that the first is self-managing. They have to be, to do their job. But even they can't do it without clear communication about the project---and cash, of course.
That the shortage is of management, not developer talent (if you protest that there is a developer shortage, I have bad news for you about where the shortage of management ability is), means that the interviewer is generally in the power position.
Ergo:
How great can the conversation be on such unequal terms? I'm not saying I haven't had good conversations with interviewers or interviewees, but it can't be expected to be a regular thing. What I really think is a smorgasbord of hunches, folk wisdom, and Alan Kay quotes---but I would never be so rude as to express such in an interview.
Buy the girl a drink first, sheesh.
