Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

While most interview questions are focused on current knowledge of a candidate or check his/her skill to solve algorithmic problems I would like to hire a developer who is passionate about programming.

What if instead of asking questions like

What do you know about technology "X"?

I will check check the knowledge that is not directly related to solving software engineering problems but shows how curious you are to IT.

For example if I look for a Java developer I can ask who are the most influential people in Java world or show a basic Scala snippet and ask a candidate to interpret the code.

I even considered to show photo of Alan Turing and let the interviewee guess who is on the photo. Does this practice make any sense?


locked by maple_shaft Jan 20 at 12:25

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as primarily opinion-based by gnat, MichaelT, GlenH7, Bart van Ingen Schenau, Dan Pichelman Jan 19 at 20:10

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Just because someone can name-drop influential programmers doesn't mean they are passionate about programming. I consider myself a fairly passionate programmer, but I couldn't tell you what Alan Turing's face looks like right this moment. Although now that I've seen your question, I'll make sure I take a quick glance at the Wikipedia page before going on any future interviews. –  Robert Harvey Jul 25 '11 at 4:35
I agree with @Robert: I've got a terrible memory when it comes to names (and faces). There are quite a few books that I could talk about for quite some time, but I could tell you the authors for very few of those. –  Joachim Sauer Jul 25 '11 at 6:31
While hiring a passionate person is realy everyones desire, you need to be careful about doing it. Interacting with someone who is passionate about something normally leads to a higher level of engagment. In an interview situation this may lead to a more favourable impression being made over a more skilled and capable but less passionate individual, especially if you're time limited and skip the technical parts. So be careful. Also passion isn't everything, a "passionate idiot" is still an idiot while a "disinterested genius" is still a genius, and I know which of the two I'd rather have. –  CdMnky Jul 25 '11 at 8:51
@Robert Harvey: I agree. Namedropping is just for show-offs. Don Knuth told me that :-) –  Jörg W Mittag Jul 25 '11 at 12:35
@yes123, I didn't start programming until college, and I consider myself to be a passionate programmer. I'm sure there are plenty of programmers with passion who started later in life. I don't think there's any correlation between when you started programming and how much you care about programming. –  zzzzBov Jul 25 '11 at 13:09

16 Answers 16

up vote 230 down vote accepted

All you have to do is ask him to tell you about one of the projects he's worked on that he most enjoyed. You'll find out more about his enthusiasm in the following 60 seconds than you ever could showing him photographs of deceased notables.

Also, you should make sure, that "project he's worked on" does include projects he was'nt hired for –  keppla Jul 25 '11 at 6:45
I agree with Keppla: especially ask for sparetime/Open Source projects. I can't imagine someone being enthusiastic about something and not having the urge to do this in his sparetime. –  LennyProgrammers Jul 25 '11 at 7:17
@Lenny222: I consider myself an enthusiastic programmer, but I simply don't have time to code in my sparetime. I have a life besides coding, also! And when I code in my free time, I am mostly hired for it as well. But I do read lots of articles and books in my free time, too, and I visit this site even on saturdays and sundays. –  Falcon Jul 25 '11 at 7:24
@Falcon: Agree, you could be a passionate programmer but after all you are human as well, you have a life, you have a family, kids etc ... in my spare time i read what's new in programming (RSS, tweater, facebook etc ...) while playing with my kid or while listen to my wife :) , so a proff that I am passionate: My wife need's to do "something" on a PC, so I wrote her a program to help her (somethimes simple JS bookmarlets, somethimes bash ...) ;) –  Radu Maris Jul 25 '11 at 8:01
@keepla, people who are passionate about their jobs often don't have to program at night. I'm enthusiastic and passionate about what I do, but I have other things to do at night. It is critical that people have other passions as well or they wil lburn out in only a few years. –  HLGEM Jul 25 '11 at 14:38

For example if I look for a Java developer I can ask who are the most influential people in Java world or show a basic Scala snippet and ask a candidate to interpret the code. I even considered to show photo of Alan Turing and let the interviewee guess who is on the photo.

That is trivia and technical knowledge. If you want to find out if they are passionate about programming then you need to engage their passion in some way, there are a couple of easy ways to do this:

  • Find out if they read programming blogs/magazines
  • See if they program out of work as a hobby
  • See if they are involved in any user groups or organizations
  • Ask them what drew them to programming and if that is still a motivation for them
  • Find out if they have a StackExchange account

If none if those light a spark in their eyes then you probably don't have a passionate programmer. You might hit some that are too busy with other things - but I'd bet you'll see a history or at least real regret at not hitting some of those points.

+1 engage their passion Especially by asking them what got them interested in programming. I believe that any passionate programmer will go on at length about this topic. –  George Marian Jul 25 '11 at 5:11
+1. I typically sum these up in a question like "what kinds of things do you do outside of work to keep up with technologies?" hoping to hear something about open source projects, podcasts, attending SIGs/UserGroups, etc. –  rally25rs Jul 25 '11 at 15:32

(warning, long post, only partially on topic)

Well I have been asking the same thing for ages. About 6 years ago I was trying to get recruiters to understand what we were about (they just ticked the boxes as you say).

At the time I wrote:

Do you geek like we do? (Open letter to recruiters and candidates).

Our culture is all important to us, I am not talking about race here, it is background based, how you view your job, what you intend to get out of your job, how you approach your job and dealing with others.

I have been mistaken before for meaning race so I will clarify now, this isn’t a race based thing, it is a mindset and drive thing. We have worked with people from many races that have been great. We also know many who are plainly and simply useless. So race doesn’t define what we are looking for at all, it is a “cultural” fit.

There are many sub cultures within Australia most of whom you wouldn’t pair up together, I am trying to explain ours - The Geek.

  • Many people need explicit instructions: "A>B>C>D" others you give them A and some background and they will work out B>C>D and E all on their own. We are looking for the second group.
  • People will simply agree with you because you are “senior” to them. Others will voice their opinions and contribute their ideas. We want the second one. Sub to this is if the decision goes against them they will still throw themselves into it.
  • Some people have learnt by rote: You do A then B then C which gives you X. Others have learnt how to learn and think. See beyond the immediate and solve the underlying problem.

Many of our jobs over the past 14 years have come from our clients need to cleanup and finish projects that have failed, mainly because the company has hired the wrong type of staff ... it costs far more than simply their wage if you get it wrong.

Now trying to pick these types of people we mean when we say “like us”:

  • Good inventors, great ideas, terrible and finishing off a project. This is describing myself. Need to hire people to cater for this problem.
  • Fantastic optimisers and “do”ers, if you want it to work really well get them. Flip side is narrowing focused and take a long time to get it there. Generally good techie trait but usually can’t converse with the outside world.
  • Very good at and knows “the correct way” and “end to end” work. They can see a project from start to finish and not miss stuff. “because it should be done that way”. This is an attitude we have in here; the clients know this and pay for it. Combine this with the “do”ers and they are ideal.
  • Quickest path to the immediate result. Tell everybody about it, loudly, bit hap hazard. (Don’t care get it working). Good for a start up, bad for established business that needs consistency. In a pure Support / Maintenance role this is good provided other developers are cleaning up afterwards. Prototyping and proof of concept work this is great.
  • Generally interested. What ever is going … tell us about it, what can I do, how can I add my value to it either as knowledge or sweat (getting on with something they see as required).
  • Rote learners / process workers. Where project has been planned out to the endth degree and they have “their bit” to do and that is it. Are good in very large teams. There is no danger of “tangents” being taken and unexpected results out of 1/200 people. They expect to be handed their “what to do” list and then they do that and come back for the next bit. Many cultures (both race and schooling) around the world tend toward rote learners or Boss/Underling style workers. This style of person is useless to us, send them to larger corporates.
  • Our people are equals in a team, expected to work within the team to achieve the goals set by the client.
  • You do whatever is required to land the job.
  • You give you opinions and perspective without attachment.
  • You think things through and analyse boundary cases.

Language is a barrier to working with us. We pretty much have our own language in here, you at least need English and some technical skill combined with a sense of humour.

If you don’t understand us you won’t grasp the requirements of what you need to do or how the rest of us will go about implementing the solution ... you won't last.

Why would you want to work with us?

  • You get paid. Alright its not the same as you would earn out in the "real world" but its good money.
  • You get to participate in decisions. While the directors have final say we want to hear from all, what they think, how and why the think it. It all helps.
  • You get to research your own stuff. Interested in geek stuff, coding, new products, latest MS vs Linux war developments, Design techniques. All these things you are given time every week to research and discover what you want to. You just have to share it with everyone else.
  • You get to try out new technologies. Either through research or through new projects we want to try new things and design new things. The projects are there to allow us to do so. (provided it helps the client and doesn't cost more than the project to do so)
  • You aren't required to wear suits. Unless the situation requires it, like visiting clients or events.
  • We want you to learn more and will put you through targeted training to improve what you know.
  • You aren't usually requried to run 9-5. If you are running support for an agreement that is 9-5 then you do, otherwise get the job done and don't abuse the priviledge.
  • Great team to work with. Well we think so anyway, we laugh at each other jokes out of politeness and have a no stabbing in the back policy. 
  • We are geeks as well. Some of us have girl friends and kids but don't let that fool you.
  • We enjoy the respect of some very big companies and can walk in without question.
  • Our client base is spread around Australia and across the globe. Leaves a lot of scope for travel and
  • We build very good relationships with our clients and their employees which means we have lots of people we can go drinking with.
  • If you have a need or problem we don't mind you taking the time off to sort it out. So long as you make up the difference with a few extra hours later on.
  • Your ideas are valued and you get to see a greater reward for those ideas.
  • You share in the success of Redgum.

Now, do you still want to work for us? Why?


I wrote that in 2004/05, I have done some 50 or 60 interviews myself, worked with 14 or so recruitement agencies who threw anyone who ticked the boxes at me ... most of this was a waste of time and I suck at picking people from an interview.

So far the most success I have had is in finding one single recruiter who understood the meaning behind the above and what I was looking for and could filter down the list to people who fitted.

Now I have 1 recruiter who I trust knows my business, knows my needs, we have lunch every other month to catch up ... I let him go, give him the time and trust that he will only show me appropriate candidates.

Recruitment is a specilist area, and while at the end of the day you have final say ... if you have the money, let the people with skillset do their thing.

Once they have found someone, I interview them, ask them about their experience, their interests, the things that motivate them, the coolest projects they have done, hear their answer to the above ... once I am convinced I bring them in for a second interview with the team over lunch, everyone else in the team asks them questions and lets me know the thumbs up or down ... then we hire.

+1 for mentioning "(warning, long post, only partially on topic)" :) –  treecoder Jul 25 '11 at 7:48

Alan Turing is a bit too much, but naming an influential person sounds alright to me. If I were asked this question, I would say , the guy wrote Effective Java...

Hiring is a two-way street. You need to know your talent pool first. If you want to hire passionate programmer, you need to ask a few questions first. Do you have exciting problems for them to solve? Secondly, do you offer competitive compensation?

If, in reality, you can't offer both, then it would be better to focus more on skills and professionalism.

+1 You can't hire passionate programmers unless you have a job requiring and rewarding that passion as much or more than all the competing alternatives available to that type of programmer. –  hotpaw2 Jul 25 '11 at 6:32

The people at 37 Signals wrote a great post that deals with hiring great programmers.

You can read the post for details (it's worth it!), but it can be roughly summarized as follows: there are things you can look into and ask about during the interview, such as

  1. How opinionated are they?
  2. How much do they contribute to open source projects?
  3. How much do they enjoy programming?
  4. Do they actually ship?
  5. What have they mastered?
  6. How well do they communicate?

You can further mitigate the risk of hiring someone by taking them on for a small project to see how they work. This will show you how they handle tasks, manage their time, communicate, and so on.

Copying the entire blog post and posting it in a way that makes it look like it's your own work based on that post, even with a link, is not permitted. The post you copied is under copyright and you cannot repost it in full. I've updated your answer to only provide a summary of the article and a link to it. –  Anna Lear Jul 25 '11 at 17:05
  • start a casual conversation about design patterns/anti-patterns/programming practices -- and see how informed the candidate is. How interesting or refreshing their views are. And, whether or not they have ideas of their own about these things
  • talk about a real world problem and see how the candidate starts proposing the solutions
  • see how much (and how long) a candidate can talk about programming (the philosophy NOT the mechanics) without referring to a particular technology or language. See if the candidate is a visionary or is all about nuts and bolts
  • ask them to talk about their most fantasized feature(s) in a programming language -- a passionate programmer will always have feature fantasies
  • ask them programming quotes and see if they know some of the popular ones
  • test their sense of humor on programming

No, that approach makes absolutely no sense. I'd recognise a photograph of Alan Turing and I could name some leading lights in the development of Java but that tells you nothing about how passionate I am about what programming can offer us. Nor would I go down the road of List all the open source projects you worked on. Some of that is easily acquired knowledge and some of it is very often used for CV/resumé dressing.

Ask them to describe a real world problem - no matter how trivial - that could be fixed by programming a solution. It doesn't have to be something so practical as identifying the infrastructure behind. Just have you thought about how you could program your way into a better way of doing something. The languages used are of secondary importance. By attaching to a particular language, you're not necessarily getting someone who is passionate about programming.


The definition of passion is a broad here. I have seen several kind of programmers. We can't just call them programmers. For me I define a passionate programmer,

  1. Who knows the fundamental of programming (I mean the real fundamentals). Seriously it shows the attitude and capabilities of learning new things on the fly though we're not directly using the fundamentals in the production code.
  2. He must have ability to deep dive in to the problems and technologies. Most of the programmers is expert in using ready-made things but that helps only to an extend.
  3. He must be update with the technologies and industrial updates he have. I really hate programmers who are not ready to put some time to read stuffs. Most of the people out here are smart the they're ready to sort out the problems. Have seen smart people spending hours and hours for the commonly known problems. What they truly lacks is the ability to read.
  4. A passionate programmer will equally passionate about the user than his code. He do everything in a user perspective.
  5. Should show the abilities to to use/create good software architecture gradually over the period.

Do you want "passionate" people or competent ones? I'd rather have people who know their business but can distinguish between it and reality than the kids who don't know anything outside their computer screen, have no hobbies except some open source thingy they're contributing to 16 hours a day (half of it while nominally working for me), etc.


Ask him real-world problem solving questions

In addition to telling you about what this candidate's skills are, if you pay attention to how enthusiastically he approaches the real-world problem solving questions you ask him, you can get a very good sense of how passionate he is about programming. And if you ask him different types of problem solving questions (some coding questions, some algorithm design questions, some system design questions), you can get a sense for which areas of programming he's most enthusiastic about.

I suggest reading Joel on Software's Guerilla Guide to Interviews not only does he tell you how to find that passion, he tells you that passion isn't one of the most important things you're looking for -- you're looking for "smart" and "gets things done". (He does mention passion, but I think that his intention is that it's a sign of the other two things you are looking for).


I'd say if you're passionate about programming, you'll be able to spot others. All you have to do is talk about programming which shouldn't be difficult during an interview. And focus on the candidate doing the talking. Make sure you qualify their level of competency regardless of their passion. Otherwise, this could cloud your judgement.


Ask if:

  • They answer questions on StackExchange sites
  • They have a blog or a website?
  • They do side projects (possibly commercial)
  • They contribute to open source projects.
I do little of that because my current job demands 50+ hrs per week, but I still think I am passionate. –  Job Jul 25 '11 at 14:22

Before you can hire passionate programmers you need to determine what you mean by that.

When I look for passion in programmers it has to do with the enthusiasm in thier voice as they discuss a difficult work problem thy had to solve. It has to do with being passionate enough to get some depth of knowledge and stepping up to solve the hard problems. What is has nothing to do with is whether they program outside of work or can name three famous programmers from the past by looking at their pictures.

When interviewing you can hear passion in the way they answer questions. They go into greater depth than the non-passionate people and they tend to be enthusisatic in what they say. They understand the business domain they have been programming in and are able to talk about how they solve problems and what suggestions they have made in their jobs to improve the programming processes or design of the application. They talk about refactoring and design patterns without being asked specifically about them.

When they talk about their achievements, they talk about things that go beyond basic coding of a module. They talk about how they saw a problem in the design and refactored or they talk about how they found a new technique to use to solve a difficult problem and they talk with enthusiasm. A passionate person is difficult to shut up. They really want to describe their achievements and goals for the future. They may have things they specifically would like to work on that your job offers and their current one doesn't. They show a pattern of growth in skill and complexity of what they do.


Ask what he does in his spare time, if it's coding and working on his personal project's it's a pretty sure sign of a passionate programmers. Not all passionate programmers program in their spare but most who do are passionate

Another thing is to ask him to estimate the number of hours he has spent programming, the more hours the more passionate (adjusting for age)

PS. I'm not saying that you should spend all your time coding. You need to have life, hobbies etc etc. We do however tend to spend time on the things we love (spending time on a spouse and children is accteptable :) so putting in extra time coding is a good indicator DS.

...and yeah yeah, you un-passionate programmers can downvote me all you want ;)


I'm interested in people what are passionate about what they are being paid to do, not hobbyists. Passion is more about learning in depth and being excited to do your job than working open source which is often a detriment to professional behavior becasue people are more interested in thier fun stuff than your work stuff. –  HLGEM Jul 25 '11 at 14:44
programming on Open source is a hobby. I could care less about your hobbies and legally I probably shouldn't even be asking about them. I want someone who is going to bring the passion to work. So I look for people who are passionate about what they do during work hours. I'm not going to think people aren't passionate because they don't do Open Source. –  HLGEM Jul 25 '11 at 19:34

Before the interview, you can tell the difference between a passionate developer and the rest by the resume. The passionate developer talks about what they did, the rest talk about how they did it. The passionate developer lists their blog, personal projects, etc. the rest don't have them.

My manager sat in on my first few interviews and was almost floored when I didn't even tech screen a candidate during the interview. He asked me later why I skipped it. "I had already read his code on his blog, I know he can code."

During the interview a single question identifies passion "what got you into technology" to a person you'll probably have to cut a passionate developer short as they start going off on tangents about the first time they used a computer, wrote a program, and so forth and so on. I find myself having to stifle a yawn when hearing an answer from the rest.

Finally, my tech screen starts with questions that a passionate developer might get offended by (and I preface it as such), the non-passionate developer might answer a few or even all of them correctly; the passionate developer will rattle them off as if they had a cheat sheet.

My bias is toward hiring a passionate developer with less experience than an experienced developer who isn't eager to learn and grow. The plain and simple fact is that technology changes too rapidly to hire someone who won't stay abreast of upcoming trends without the job requiring it.

I fully acknowledge this isn't fool proof. Some quality talent might slip through my fingers because of my method. I know there are people who are highly skilled but turn of the computer at 5. On the other hand I have been regularly impressed by the passionate programmer and regardless of years of experience, I quickly find that I'm learning as much from them as they are from me.


All great answers here - I'd add that I often ask if the candidate has worked with other people's code (sometimes fresh out of college hasn't), and if so, what is the biggest pet peeve they have with that old code. Sometimes they will go off and describe bad patterns and how they fix them. I take that as a good sign. Other answers may show you a very laid back programmer or one is pedantic....something you may or may not want.

wrong attitude on your part. IMO someone who goes out and changes code seemingly at random because he doesn't like the patterns used in it is a rogue who does more harm than good. All change to existing code should serve a specific purpose, and that purpose should be directly related to either fixing identified problems or implementing new functionality, never "I don't like how the previous guy did things so I'm going to rewrite the lot of it" (which is a common attitude among juniors who've had their heads filled with theory but never programmed themselves out of a clutch in reality. –  jwenting Jul 26 '11 at 11:40

protected by gnat Jan 18 at 12:36

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.