It's possible you work for a very small, highly profitable enterprise company that is using Salesforce as a platform for business software. It's more likely, however, that you're part of a team of developers working on the platform for your large to enterprise-sized business. If you truly work alone, then this section is more about what to look for in a company when evaluating a job offer. On the other hand, if you work on a team.
Finding new teammates is a daunting challenge. It's likely an internal recruiter (or increasingly likely a software program) has sifted through countless résumés looking for keywords such as Force.com or Visualforce. In striving to find the subjective best of that bunch, the résumés are given over to the hiring manager who chuckles over them before his or her first cup of coffee, and determines through some internal calculus who to interview. I think it's safe to say we've all gone through this process once or twice. The process, however, is inherently broken. People are more complex than keywords and numbers on a sheet of paper (have you ever noticed that everyone inevitably prints out résumés?) Résumés can't capture a person's experience, and an hour-long interview spread across numerous groups of people can't do the person justice or capture experience either. Instead of bringing the candidates into a room and having them write a Visualforce page to display a Fibonacci sequence backwards from its 100th character or whatever your company's standard software test is, ask them to do a project with you.
When I say do a project, I don't mean come in for an hour and work through a mostly completed trigger or some unit tests for code the candidate has never seen. I mean take a well-defined piece of actual work from the backlog and ask the candidate to do that work, with you, over a set period of hours. Additionally, pay them for their work. It doesn't have to be a huge sum of money, but it helps everyone to understand that they're doing real work, for a real company, not just fizz-buzzing their way through an interview. Give them autonomy over the project's architecture and engineering in accordance with the job level you're hiring at. An architect should be able to fully envision the solution and interactions all the way down to writing the methods. A junior developer, on the other hand, should probably be given more guidance.
Working a project with a candidate helps everyone feel out the culture, the expectations, and the style of both the existing team and the candidate. You'll learn how he or she writes tests, how quickly he or she picks up your org's API, and whether or not he or she pairs well with other teammates. It may be after working on the project that the candidate says, "No thanks, I don't want to work in this industry." It is equally likely that after working the project, you say I really liked the candidate, but we need a more advanced developer for this role. Either way, both parties have much more information before making their decisions. In order for this to work, however, it has to meet two criteria. First, it has to fulfill a real business need for the team, with no projects pulled from thin air. Pull something from your backlog and work it with the same processes you always do, especially code reviews. Secondly, your team cannot simply dictate to the candidate what to do. You're presumably looking to hire a peer, not a mindless drone. Even if the candidate ends up making a mistake, let them make that mistake and teach them the better way. Doing so highlights how a candidate accepts technical correction, even before the code review.
Finding new teammates is almost a purely subjective exercise. Feelings matter and should be taken into account. However, don't judge candidates too harshly on things such as style and naming conventions. They are undoubtedly indoctrinated to their existing employer's style and naming conventions. Be generous and charitable for things that can be taught.
At times, you may find yourself looking to hire not just a new team member but an entire team. Perhaps you're the code-speaking admin of a medium-sized company with no headcount for Salesforce developers. In these situations, inevitably management's mind drifts off to the land of unicorns, where staff augmentation consulting firms offer champagne and steak to anyone who'll listen to their pitch. Picking the right partner, however, requires far more diligence than one might assume. A bad doctor can, through action or inaction, cause great bodily harm. Likewise, a bad coding partner can leave your org with a legacy of problems and hurt. Even when following best practices, the nature of the job demands a coding partner's time be split amongst several projects (and clients) at a time. There simply isn't time for such consultants to learn your org's API. It's crucial that you're careful and methodical about whom you partner with.
Some partners will give you sample code or internal style guides their developers follow. Those are good signs, but inadequate. I advocate coworking a project with a potential new member instead of whiteboard tests. Conversely, when looking for a coding partner, I strongly recommend testing them. Paying them to cowork a project is likely not a sensible option; if you're hiring a coding partner, you might not be comfortable enough with code to know right from wrong (and that's OK). Instead of a project, give them a test—not a long one, but a meaningful one. Ask them to deliver functionality, but don't specify how it should work. For instance, I like to ask for a trio of triggers. The first trigger needs to do a simple cross-object field update. The second trigger needs to manipulate pricebook entries in two pricebooks. The third trigger needs to ensure it's not accidently run recursively.
The first trigger is a trick. If I'm given a trigger back, the code partner is either unable or unwilling to use platform tools such as cross-object workflow rules or processes to provide the same functionality. The problem with this situation is if you're always responsible for dictating the exact method of implementation, you'll most likely end up in a cycle of tweak, test, tweak, test because you're not a dedicated coder. How you specify functionality may not only be inefficient, but unworkable. This isn't your fault, and when you hire a coding partner, you're not only hiring X number of Apex developers; you're hiring their knowledge, and they should feel comfortable pushing back on your requests if there's a better way to do it.
The second trigger is a zinger. Manipulating pricebooks in triggers is full of potential problems, and is in general a questionable idea to start with. Nevertheless, it provides an excellent way to see how they write tests. Note that I'm simply expecting tests to be returned with these triggers, not asking for them. Testing with pricebooks is hard, and testing with multiple pricebooks is even harder. To do so in the context of a trigger complicates matters one step further. Looking at how they write and then test a trigger that manipulates pricebooks shows you if they're current on platform technologies (if they use @isTest(SeeAllData=true) then they're not current), the patterns of tests they use, and the number and types of assertions they're using. The tests for this trigger are almost always the determining factor I use when helping others determine who to hire as a code partner. If the tests are well done and were returned without being explicitly asked for, the code-partner gets my blessing.
Lastly, the third trigger exposes the partner's ability to understand and prevent recursive updates to records. The pattern for avoiding this is well-documented and easy to implement. If the trigger utilizes a static Boolean variable to determine if it's already run once, it gets a pass. If the trigger(s) utilize a trigger framework that handles recursion prevention without a framework being specified, they get a glowing review.
Regardless of the contents of your test, give one to potential code partners. Ask them to do their work in a developer edition. Make the test as open-ended as you can, but with clear goals of what you want to see. You want push back and questions from them before they start. When they're done, get their results peer-reviewed on the Salesforce Success Community website, the StackExchange website, or the developer forums. Developers in all three places will gladly let you know what they think of the code you were given. Better yet, go to a local developer meetup group, and have the code peer-reviewed there. You'll be able to ask questions in real time and gather many opinions.