We recently started putting sales candidates on the phone to cold call. The most critical thing we measure is how many minutes they spend on the phone. It's been a pretty strong signal of how they would perform if we were to hire them.
If you need 2 sales guys, hire 3, give them a month and fire the worst one.
That is horrifying to me as a developer, but apparently this is fairly standard for sales.
For an inside sales position, you're not all that far off though.
As I've seen it put in another discussion, "sales managers don't have any trouble firing people."
In other words, is the success of the sales people about spending more time on the phone in total? Or is it about spending more or less time per call?
Thanks in advance!
Our sales process is based on our reps cold calling businesses. We learned after a couple of mishirings that the most difficult part of the job is being able to manage emotion and taking rejection. For example, as a rep it is completely normal to be rejected in some manner 50 times a day. So if you get discouraged or upset after your third rejection, it is unlikely that you would have the motivation or drive to make more calls and therefore, you're likely not the right fit. All of this is usually summed up in the metric time spent talking across all calls.
While ultimately the time on the phone translates into revenue, we like to emphasize factors that is in our control. We can't control whether someone ultimately signs up or not but we do control how much break we take in between calls.
* Got into Ruby and Go (trying to get a feel for what language felt most comfortable for bit manip.)
* Got into assembly (for fun so far)
* Got a good appreciation for bit-level operations
* A bazillion more little facts and insights that help in daily work life
I bet if you polled how it's helped other people there'd be all kinds of great examples. For work, I'd say the best impact has been a personal drive to pentest our own product, resulting in a lot of bugs found and fixed. That included managing to root our servers via a product flaw, which was scary and amazingly fun.
So yeah, thumbs up, don't stop now (please).
As for the above catering to newcomers, sure but it ramps up incredibly and pushes some boundaries if you've never touched that stuff before.
I'm assuming you are not interviewing every or even most.NET developers and trying your luck to find the one who can write that great exploit. So, from all the candidates with resumes that would be considered subpar before the process overhaul, how do you determine which ones have potential to write that great exploit?