Hot answers tagged

150

Hire the inexperienced programmer with a passion for the craft. A passionate programmer will learn quickly, care about his work and enjoy doing it. I've worked with both types of programmers and I would always hire the passionate type over the experienced. People who don't care about their work eventually lead to problems in quality as well as in meeting ...


113

Whilst no one posting here is in a position to tell you which to hire, I'd like to offer a little counterpoint to the proceedings... One of our most recent new starters is the absolute image of professional experience. In at 9, out at 5, one hour for lunch. No lates, no weekends. Which probibly sounds terrible to most of the people who have responded so ...


90

Great developers once had no experience, too. Great developers are not only expensive but also hard to find. So, if you have a high-quality screening and hiring process, hiring entry-level developers can be a great way to find those up-and-comers and turn them into great developers.


65

I regularly end up working 50+ hours a week To me thats all you need to tell your manager. "Im working 50+ hours a week to make sure the work gets done. Im a hard worker but this is unsustainable long term, you should hire another developer". If that dosent work then I suggest you start looking for a new job.


49

I would say it depends on the rest of the team: if you have a lot of experienced programmers already, then pick the passionate if, on the other hand, you have only one or two experienced programmers plus many students/cheap-labor-with-little-experience-but-that-don't-cost-much, then the experienced one will be more useful.


45

Pay lots of money. If they can't do that they offer stock options and nice perks like free food, drink, nice working environment with latest equipment and good benefits. Basically you have to give them something worthwhile, no one is interested in making you rich for their toil.


44

Ask about what tech blogs they read, ask what the applicant finds interesting in current tech and why. Essentially, for a phone interview you want to figure out if this is someone who is enthusiastic about technology and programming and is interested in learning and knowing more. Since this is a junior, you can't expect that they know many advanced topics, ...


41

A book that I really like is First break all the rules. It has a lot of information about the differences between average managers and good managers. One of the key insights that good managers said over and over again was summed up by one of them in the sentence, I've never waited too long to find the right hire, and I've never fired the wrong hire fast ...


41

How do you know that (s)he will have trouble adapting? Just because they use a different coding style? That's pretty presumptuous. I have been a contractor for a long time, and no matter what coding style is used, you adapt. It may take some time, but the habits form pretty quickly. I do hope that by coding style you do not just mean indentation and layout ...


40

Experience is (Often) Key Unfortunately, while this may be very frustrating, your skills and the knowledge of project management that you acquired at university or during your previous projects appears insufficient to a lot of people; I know I would be cautious. I can understand the frustration, but there's always the danger that, while you seem like a ...


38

How can I check if he will get the programming skills he needs You can't. It's impossible to accurately test for a skill he doesn't have yet. You have to make a judgment call based on his intelligence and attitude. It's ultimately always going to be a risk. From personal experience I can say it's very possible to transition from science to programming. ...


33

The purpose of fizzbuzz isn't to find good programmers, it's to find a certain class of bad programmers, which is people who can't implement a simple algorithm. Your question is sort of like asking how many Nascar champions are identified during their driver license exams. There's a lot of middle ground between someone you definitely don't want to hire and ...


32

More than you realize. Think about it, if you have to fight with someone every day, it gets exhausting. When that happens, only a few options are available to you: Give up and let the bad fit do what they want all the time, even if it destroys the project. Leave the team/company to avoid the bad fit. Fire the bad fit and hire someone you can work with. ...


30

I have worked as, and managed staff in both situations, and combinations of both. I've made the following observations: Junior staff do not work remotely. They require a good and personal working relationship with a mentor. I find my junior staff would rather wait for me to be available than to ask the rather senior (and good) remote developer anything. ...


30

The only thing I know for sure is that there's a correlation between obfuscating, avoidant, yet overly confident answers and my desire to not hire the candidate. This is my personal "red flag". Some candidates don't fully answer questions in a satisfactory way and instead they will verbally dance around a psuedo-answer. Above all the goal of these ...


30

I think there are a few places you're wasting time. Drop the HR interview beyond just a simple first contact to setup follow-up interviews. Having HR people ask technical questions is a waste of time. For example, I had one ask me some unclear question about MVC and they couldn't clarify what was being asked. Drop the online test, especially if you're ...


28

Consider the following truth: you will get exactly what you measure and monitor. With that in mind: Terrible things to measure Lines of code - Elegant code has a concise nature to it. Lines of code encourages bloat, copy and paste, or even worse, code for the sake of code. Time-to-solution - Code done quickly contains lots of bugs. Bug fixes - This goes ...


28

Which door represents your code? Which door represents your team or your company? Why are we in that room? Is this just a normal code review or have we found a stream of horrible problems shortly after going live? Are we debugging in a panic, poring over code that we thought worked? Are customers leaving in droves and managers breathing down our necks.. (...


28

What do you think? I think that each team can take a person with speech impairment with a positive net effect. I would consider incapability to handle one such person in a team as either a management or an ethical failure. Just take a look around. Both PhD and college graduates, good or mediocre programmers have problems with communicating their ...


27

There are plenty of other reasons: Growing your own talent. Sometimes it's easier to hire an entry level person and train them in the technologies and tasks you require. It takes less time to find an entry level person than a Sr. person. Replenish your work force. As many developers move up in a company, they often times don't write as much code. Someone ...


27

Having been programming at hundreds of different projects for almost a hundred different customers, let me emphasize one point. Coding style (and quibbling over coding style) is a complete waste of time. Get over it. I've read a lot of code from a lot of different programmers. (Assume a median team size of 5 and 100 different teams. That's 500 co-...


26

An in-house team will be more responsive to your needs, since they're actually part of your company, so they have a better idea of what you want. An in-house team is easier to communicate with- nothing beats regular face-to-face contact. Your in-house team will have more domain-specific knowledge that an external team would have to learn. You're investing ...


26

Everyone claims to "hire only the top 1 percentile". If that were true, 100% of employed people would all be in the "top 1 percentile" of all people, so 99% of all people would be unemployed (in any given field). As this is clearly not the case, and we've all experienced people who're clearly not in that group (why else do you ask this question at all...) we ...


26

Frankly, good PMs have spent time in the "trenches". They've experienced enough process and management failures as developers to know what not to do as a manager. I personally would find it difficult to justify hiring a PM who doesn't have any experience as a developer. I realize that you won't like the answer, but I really don't think there's any ...


26

I've been in a similar boat. A very similar boat. The one thing that really helped me make the "we need to expand the team" argument stick was how high our bus factor was -- if I got hit by one, there was no one who had any clue about the entire stack we relied upon. Getting someone else on the team was crucial for operations if nothing else.


26

When (if ever) is this a win win situation? About the only time when it would make sense is when all of the following is true: You are a co-owner with a double-digit percentage stake in the equity of the company You have other means to sustain yourself and your family for at least a couple of years You love the idea behind the start-up, and you see a ...


25

The first thing you need to ask is why you're getting resumes that aren't up to the standards you want. I've worked with a lot of good people, so they're out there, and the application sounds very interesting to me. If you can't get people who can do Fibonacci sequences and binary search (which is more difficult than it seems; according to Knuth it was ...


24

To be blunt: No, No, No, No and No! Get the candidate in to do some coding with you, it's the only way you'll know how they think their way through problems and how they might fit into your team. As an aside I'd try to avoid recruiting via the CV lottery technique :-), instead find good people through word of mouth, conferences, technical community ...


24

I know why you want this. For every hundred candidates you get, you receive 90 from people who can't code for beans. They probably have no idea what a compiler is. Now consider their side. For every hundred companies those 10 real programmers apply for, they find that 90 of them fail to score a single point on the Joel Test. They want programmers to fix ...



Only top voted, non community-wiki answers of a minimum length are eligible