The application process for Sales Engineers has evolved over the years. And the area with the most change in a good way has been the Technical Exercise section. A hiring firm will typically do this for at least one of the following three reasons:

1. To see how familiar you are with the space or key technologies. This often extends into “random” questions worked into other parts of the process. It can also be a defined list of specific questions such as “name two types of DNS records” or “what ports is HTTP and HTTPS served on?”
2. To see how well you can work from documentation and solve technical problems. Hopefully this is an exercise where you actually use the technology of the firm for which you are applying. I’ll explain in a bit why you really want to see this as part of the exercise if reasonable and possible.
3. Lastly to see how well you can convey technical issues. This is an area that separates a great SE from one that can get by. It could be as simple as a few questions like “how do you explain ‘the cloud’ to your non-technical friends?” It often boils down to being asked to provide a technical demonstration of your choosing. I’ll have pointers in that area farther along also.

Application Process

The application process can be daunting. I’ve seen them involve 7 or more interviews and extend literally into months on a few occasions which in itself can be taken as a warning sign. Attrition is high in the current economy, especially in areas concentrated in the tech space. Sometimes this is because companies are running either out of money or at break-neck speed and think they can’t take chances someone will make the grade. Often it is because there is so much opportunity out there that employees will bounce around for better compensation.

This highlights where that long process is a warning sign. If you are a candidate, when a teammate leaves how long will it take to build back up the team? If you are coming on to build up or maintain the team, how hard and long will the process be when you are running it? And if so, how many great candidates will you miss out on because the process is too slow?

One difference to keep in mind – often the SE Director role is so critical that the vetting process is more complex. This is especially true for a newer or smaller organization. If you’ve got concerns find out how the process goes for a more mainstream role like Developers.  If a company can tell you that for Developers it is typically two weeks from first conversation to an offer being extended you can probably trust there won’t be a timing or speed hindrance. A small firm that can properly evaluate and move like this is truly nimble and knows what they are doing. And if you come from the “trust but verify” mindset, just check the tenure of current employees in that role via LinkedIn.

Technical Exercises

And over the years I’ve done more than a half dozen technical exercises. Some of the experiences I’ve had that I’ve learned from:

• For one firm they had you implement the technology and answer several detailed questions. As part of this process you would branch a document in a public repository to store your answers. The drawback here was that it wasn’t hard to see the answers of every other candidate. The external recruiter pushed hard that I look at a specific candidate’s answers – one that had “shined brightly” to the hiring firm. I did resist up until the end where just prior to submission I did take a peak. No, I didn’t change any of my answers but I did learn a different important tip which I’ll include farther down.
• Another firm said they were not looking for CIS majors, but the exercise with their solution (product) required very current development skills. I found out later from the external recruiter that they really wanted to see how hard one would work for the role. But I hadn’t seen anything super motivating about the firm’s technology. And the fact that a general DevOps person or SysAdmin couldn’t get through the install spoke poorly about their process and documentation – which would mean fewer overall sales opportunities. (An overworked DevOps engineer will have multiple solutions to try out when wanting to solve a problem. Almost all have free trials. If one can’t be made to work in an hour or two at most then they are on to another product.) Then factor in that many candidates have multiple job options there is a limit to how much time and effort they would allocate to this opportunity. In the end I spent a day trying to get their jar file to import and then respectfully bowed out. It wasn’t worth it for me to understand how that one facet of being a developer had evolved since my time at Cisco.
• For one in the APM space I was asked if I was going to want to talk about Java or .NET. I selected Java and an appropriate employee was selected to run the interview. Having spent several years developing internal web based Java applications for Cisco, as well as learning to monitor it for two years at Dynatrace I went in feeling comfortable. The interviewer instead had an interest in a facet of Big Data and wanted to talk architecturally about storing data in complex monitoring. I hadn’t read whatever articles had sparked his interest (no pun intended) and it really made for an irrelevant and disconnected conversation since Java never came up. Needless to say my interest in the team, firm and technology waned. Their process wasn’t mature and I was skeptical of those that had made it through.
• At one the instructions were not clear. There was wording about setting up multiple environments, which I took as the environments to monitor and organize the alerts from. It turns out that “environments” was a section of the solution and I missed it when looking at the documentation. I also made the mistake of not clarifying the intended audience of the demo. I came at it as “I tried out your solution and this is what I saw and experienced” when they wanted me to actually demo the solution (product) as though I were an SE already working there. Yes, I made two mistakes, but that hampered me being able to truly demonstrate my skills. How many other candidates did they not get a clear picture of?

These experiences have really offered a lot of learning. That learning can be broken up into two categories:

Getting Hired

For SE Candidates:

1. If the Technical Exercise includes implementing and using the technology you’d be selling – use the opportunity to get a feel for what the perspective buyer experiences. Will the product and its documentation get a prospective candidate far enough along that Sales will even have an opportunity to engage them? How is ease of use? Is the interface clear? Documentation correct and easy to follow?
2. If you aren’t sure, ask. I’ve given at least one example where I missed something and could have asked for more information or help. There is no harm in that, and true team players know when to ask for help. Wrong assumptions can torpedo your effort.
3. Add other tidbits of knowledge or fun anecdotes. Show how you keep sharing knowledge or educating fun and light. For one I was asked if I had a trillion dollar budget if I could build a network link from Sydney to New York with only a 5ms latency. This was an easy spot to joke how you can break many laws, but not the laws of physics.
4. If you are submitting your answers via github (or any other method) leverage structure and formatting. (This is what I learned from the experience where the recruiter wanted me to view another candidate’s answers.) Demonstrate communication skills! This isn’t a college exam where you just have to show your work and have the correct answer. You are being “graded” on other parameters.
5. Document your code. This helps to share why you went with certain architecture or libraries. And if you don’t normally document your code you should. End of story.
6. Don’t cheat. It is true you are cheating yourself. No matter how desperate you are, you don’t ever want to get in over your head.
7. Treat it like part of the job. Do quality effort, show the way you like to work. You don’t want to underperform, just as you don’t want to set expectations unrealistically high.
8. When doing a demo, set the stage. Provide context and relevant background details. Assign roles to folks in the room. “For this demo, I’m going to need someone to be the DevOps engineer doing the monitoring. Who is comfortable taking on that role?”
9. Remember the sales process starts off with Awareness and then Consideration phase before the Purchase phase. If your audience has no awareness of the solution you are pitching it makes the consideration phase very hard to move into. It is okay to send a link to a teaser video to get them more aware before you come in the door. In the real world at least one person in the room has awareness of the technology before the demo. And everyone else knows it is relevant to their job.
10. If you aren’t asked any technical questions, be concerned about who you will be working with. The job market is so crazy right now it is challenging to attract even mediocre talent and fakers can linger on and do damage to a team for months if not years.
11. Don’t share confidential information. It might be okay to allude to having certain knowledge. But most employers don’t want unethical employees or to take on that liability. And on the other end of the spectrum there are firms that like to interview ex-employees of their competitors for the sole purpose of plumping them for information.
12. If they ask you to do a demo on any technical process, go with a relevant technology. It is best to pick one you think there will be the most interest in or one where most of the room will have some idea of what you are talking about. (And pitch it accordingly!)
13. One very impressive Sales Engineer Director I spoke with actually does his demo of the firm’s technology. He says it makes it even easier for them to see you in the role. I do have slight concerns about missing certain facts or key points. Worse case I might ask if it is okay to do the company’s product as a demo but ask if you could see it done once first. That’s what would happen if you actually were hired anyway.

When Hiring

For those looking to hire SEs:

1. When asking the list of stock technical questions, make it clear you don’t expect them to get them all right and it covers a wide range of topics. Put the candidate at ease, not on the defensive!
2. If asking the candidate to present something, make it clear “if you were in the role”
3. Show the sizzle! I have had one opportunity stretch out to 6 weeks now. I actually made the mistake of stopping to look for other opportunities because of a single video I found. It was an amazing use case that really conveyed the value proposition. I wanted in bad! If your firm has some marketing material that you think really conveys how exciting your technology is, ask the candidate to review that material early in the process.
4. For any candidate that is reasonably qualified, don’t make them work too hard for it. It has had me put at least one role on the back burner. And right now I’ve got (no joke) 48 jobs saved in LinkedIn Jobs – of which at least 30 could be interesting and worth possibly applying for. If I haven’t seen the sizzle, I’m not going to spend too long in the kitchen.
5. Watch for candidates that share proprietary knowledge or information. This can be trouble.
6. The better organizations can actually work in at least two if not all three sections from the top of this article. Decide how you are evaluating all three realms.

The Technical Exercise during the hiring process is of value to everyone involved. Leverage it as best you can to get a feel for the firm you are considering. If you have other tips from either point (hiring or interviewing) please do share them with me.