As a professional programmer I spend almost all of my free time NOT programming, but I do spend it taking care of my family and social obligations instead. While I love what I do I would love it less if I did too much of it.
How to Interview Engineers When You're Not Technical – Part II
11–20 of 94 posts
Re: How to Interview Engineers When You're Not Technical – Part II
#12> [From the preceding article] how were teams split, tasks delegated, and projects managed throughout Sprints?
> 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?
Re: How to Interview Engineers When You're Not Technical – Part II
#13I'm a good enough developer who has worked on enough projects that if someone tries to tell me that I need to show them personal projects I'm working on, then that ends the interview. I used to be a recruiter, I know how to conduct an interview and sit on the other end of that desk, and I know what I won't put up for in the workplace.
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.
Re: How to Interview Engineers When You're Not Technical – Part II
#14Some good questions in here, with one exception: > Programmers are unique. They're one of the few professions where outside the boundaries of their working hours they choose to do the same exact thing they do at work: programming. 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 prog…
Please read the article further down. The author explicitly says:
> 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.
Re: How to Interview Engineers When You're Not Technical – Part II
#15Earlier quoted context omitted.
> Hiring managers should definitely not be assuming that all programmers do apps in their spare time. It baffles me how much this is an assumption. Like all the developers should not have any hobby that doesn't involve coding.
but don't you think its a fair guess that someone who hobby is X might be better at X than someone whose hobby is Y.
No, because that doesn't say anything about the quality of his code. He could be sitting around writing complete chicken scratch if he doesn't have a team with good leadership and code review guidelines.
Re: How to Interview Engineers When You're Not Technical – Part II
#16Earlier quoted context omitted.
> Hiring managers should definitely not be assuming that all programmers do apps in their spare time. It baffles me how much this is an assumption. Like all the developers should not have any hobby that doesn't involve coding.
but don't you think its a fair guess that someone who hobby is X might be better at X than someone whose hobby is Y.
Not necessarily. My hobby could be, say embedded programming and I could be a front end engineer.
Re: How to Interview Engineers When You're Not Technical – Part II
#17There are some good questions here.
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.
Re: How to Interview Engineers When You're Not Technical – Part II
#18Earlier quoted context omitted.
> Hiring managers should definitely not be assuming that all programmers do apps in their spare time. It baffles me how much this is an assumption. Like all the developers should not have any hobby that doesn't involve coding.
but don't you think its a fair guess that someone who hobby is X might be better at X than someone whose hobby is Y.
I see your point, and I partly disagree. First because, they are doing it for fun, to solve things they want to make it work. That doesn't say they are learning something, or following clean code guidelines.
But let's assume they DO. They are better at coding. But are you sure coding is the only skill you want? I've seen my fair share of developers that lack "real world" experience, to the point they cannot see that what they are doing is not what a user wants, or how they want to do it.
In some cases, open source projects are made for developers, and managed/prioritized by developers, not someone with experience in project management, or with a roadmap with the users in mind. So, they might be lacking a lot of other important skills, and I would dare say that some also lack empathy towards non-programmers - the paying customers.
I'M NOT GENERALIZING GUYS!
I'm just point out things that I saw in some instances, with some people.
Re: How to Interview Engineers When You're Not Technical – Part II
#19Some good questions in here, with one exception: > Programmers are unique. They're one of the few professions where outside the boundaries of their working hours they choose to do the same exact thing they do at work: programming. 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 prog…
Please read the article further down. The author explicitly says: > 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 hirin…
fair point, I did miss that further down in the section. It's still unfortunate to lead with a generalization that plays into a common trope/assumption about developers that does play out in the hiring process, but it's good to see it called out explicitly below that it shouldn't be required. I certainly don't disagree that side projects are a good data point especially for junior developers who don't have the direct professional experience.
Re: How to Interview Engineers When You're Not Technical – Part II
#20I consider myself good at programming in general. But let's say the interviewer was hiring me for a technology stack that I'm pretty much clueless about... let's say assembly language or cobol... 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.
"What's the one thing you would not compromise on as you write code?" Its not hard to figure out the right answer to that one: "I never compromise. Must be perfect." But of course that's not true. There are always pathological conditions that can reasonably ignored especially in the first release.