I recently completed another round of interviews for my company in the search for BizTalk consultants. Yet again, it was a fairly depressing experience. I offer a few humble tips to folks claiming to be BizTalk architects/developers.
My first pet peeve is gigantic resumes. I know that headhunters often beef these things up, but if your resume has more pages than you have years of job experience, that’s a red flag. Brevity, people. If you’re still listing the top 14 accomplishments from your college internship in 1999, it’s time to reevaluate your resume building skills.
In terms of the interview itself, I do NOT favor the types of questions that can be answered with one word or sentence (e.g. “tell me all the options when right-clicking a functoid” or “list me all the BizTalk adapters”). That doesn’t tell me anything about your skills. Tell me why you’d choose the HTTP adapter over the SOAP adapter. THAT’S a question.
A few tips if you’re out there selling yourself as a BizTalk person …
- Don’t list every possible subsystem/feature in BizTalk on your resume and claim experience. I simply don’t believe that EVERY person has used BAS. Come on. FYI, if you throw “Enterprise Single Sign On” on your resume, be ready for a question from me.
- When you claim to be a BizTalk architect, and I ask you to explain the concept of “promoted values”, and you tell me that “I like to just promote any values in a schema that feel important”, the next sound you will hear is me stabbing myself in the neck.
- When I see “experience building complicated orchestrations” on your resume, but my questions about “patterns” or “exception handling strategies” completely befuddle you, you’ve destroyed a piece of my soul.
- When you tell me that you’ve participated in full lifecycle implementations (design –> test) on BizTalk projects, and I ask you what your next step is after requirements have been gathered by the business, and your answer is “start coding” … you’re not getting the job.
- If you claim extensive experience with BizTalk application deployment, but you can’t tell me what artifacts may go into an MSI package, you’re not scoring any points.
- While I appreciate honestly when I ask you for your BizTalk strengths and weaknesses, your chosen weakness should not be listed on your resume as an “expert with …”
- If you tell me that you’ve spent significant time building BizTalk solutions that integrate with a database, and I ask how you poll for database records to kick off a process, the answer I’m looking for does not include “I build lots of custom data access classes.”
- Finally, an interviewer can tell when you’re simply regurgitating an answer from a book or website. I want to hear answers in your own words. If you’ve stammered through the entire interview, but when I ask about the Business Rules Engine you provide an sweeping, poetic answer, I know you’re faking it.
Sigh. I go into virtually every interview wanting to love the candidate, and roughly 75% of the time, I complete the interview sitting in a pool of my own tears. Any other tips you want to throw out there for BizTalk job candidates?
Technorati Tags: BizTalk
“I like to just promote any values in a schema that feel important.”
Please tell me someone didn’t actually say that… at least not with a straight face! LOL!
to add another line from a self claimed BizTalk architect and CEO.
“im customer x’s main architect on BizTalk… oh yeah, would you be so kind and email me the changes from BizTalk 2004 to 2006 ?”.
Chris, yes, that was the verbatim quote.
Michael, that’s a great question for me to add. Someone positioning themselves as an architect should really be familiar with the roadmap of the product they are recommending/implementing.
Great post Richard, I definitely share your fraustration (and as I find it hard even repeating some of the things I’ve heard on interviews I’ll excuse myself from posting any).
Great article Richard.
The main problem for me is the BizTalk too broad tool and I think nobody ever touch all its sides.
I use different kind of interview (“BizTalk interview questions and principle” http://geekswithblogs.net/LeonidGaneline/archive/2007/07/03/113663.aspx)
Like the article, been having some of the same pain myself. I usually use the same approach as you. My favourite interview questions at the minute are as follows:
1. How would you describe BizTalk to a non BizTalk developer?
You would be amazed how many people have talked them self out of the job just on this question. My favourite response so far is “orchestration”. Yes a one word answer. I encouraged the candidate to elaborate but apparently that was a suffucient answer
2. Tell me about a time problem you needed to solve during BizTalk development. We all come across a problem where need to refactor the design at some point. Im looking for the candidate to explain the problem, why the original design didnt work, what alternatives they considered, why they chose the approach they took, and how they tested it
This question tells me a lot about a candidates thought process and problem solving skills.
3. How do you test your BizTalk solutions?
It amazes me the responses I sometimes get, the right answer involves a mixture of the following words:
– Test Stubs
It does not involve things like
– “we have a dedicated team that do all of our testing”
– “there was a developer on the team who wrote all of the BizUnit tests”
– Anything involving doing it all by hand
Great additions. The best part is that even if someone comes across this post when preparing for a BizTalk interview, knowing these questions alone doesn’t help. There are enough valid follow-up questions that you could ask to ensure that someone not only anticipated the question, but also had the practical experience to answer correctly.
It’s true, I’ve seen people claiming to be more than they are a lot.
But it seems that you if you don’t do it then you simply won’t get an interview in the first place 🙂 Because if client has 5 great architects (team leads/etc, stuffed with technologies as a Thanksgiving turkeys) on his hands (according to their resumes), who would call a developer?
Saying this, I’m going myself to add some pretty looking bubbling in my resume: when agents submit your resume, you have decent experience but you’re getting no calls from employers – I think this is wrong. To appear not good enough during the test(interview) is one thing and another one is not get calls because you resume is not flushy enough.
Couple more things. I, for instance, can’t “think on my feet”. And I don’t need it in the real world situation, right? But on interview, in best case, you’d have: “Take your time”. Yeah, rihgt. Would anyone take the answer “OK, let me sit down and relax, think about it and I’ll come back to you in 10-15 minutes”?
The other thing, I just don’t remember many things. Let me quote Mike: “Im looking for the candidate to explain the problem, why the original design didnt work, what alternatives they considered, why they chose the approach they took, and how they tested it.”(c) Is the answer “Do you expect me to remember that 2 years back” correct?
That’s where those 1 word/1 sentence are coming in the picture. As an appropriate ones, in my opinion.
Btw, don’t get me wrong: I found this blog and following comments were interesting and useful. And I’m sorry that my comments came lengthy and kind of bitter 🙂
Thanks for taking the time to share your thoughts on the matter. It can be difficult to get noticed in the resume stack and embellishment seems the easiest way to go. However, any interviewer worth their paycheck can tell when someone has oversold themselves and isn’t a right fit for the role.
For me, I don’t care if you know the deepest details about something, but I care more if, in the words of Joel Spolsky, you are “smart and get things done.” If during an interview I see that you’ve pitched yourself as an expert on something you know nothing about, then you fail the first part of Joel’s criteria!
Yes the pages of the resume are being more than the years of experience… and one of the reason for that is that lack of resume building skills and some part of the blame also goes to requirements going over one full page, asking for everything in biztalk,sharepoint,wcf,.net,silverlight,AJAX,WPF,workflow,monitoring tools,Oracle,Sqlserver,SSIS,SSRS,Database administration etc. ( sometime they want java skills also ) OMG ALL skills in one guy…?
You have discussed about the problem.
Can you please guide us by giving some solution or tips.
True, that many job postings contain a wish list of skills that few people exactly match. However, I’d suspect that there are CORE skills for each position, and you can often detect these from the description itself. I would personally much rather be honest about my depth/breadth than get an interview and spend the entire time back-peddling on my overblown resume. So, I guess the best advice is to clearly highlight your core strengths, and clearly identify which are skills that are advanced vs. basic.
🙂 A view from another side, from the BizTalk Developer:
The worst thing with the BizTalk developer recruitment when the interviewer knows so little about BizTalk. Frequently the job description is disaster. Sometimes recruiters use the online tests like Kenexa Prove It!. BizTalk tests are awful, just compilation from documentation with errors and ambiguity in many question.
Once I was asked to develop some simple object oriented code. It is good for the last part of the interview, when the programmer skills are checked, but this code was the main requirement. Stupid.
Another bad thing is when the customer doesn’t have real reasons to use BizTalk or have the wrong expectations. So, now I have a habit to ask a lot of questions about project, team, environment, timeline.
Its nice post.!
Usually when I take BizTalk interview, I usually ask senerio based questions, that can involve Orchestration desinging, orchestration patters, custom pipeline, BRE, BAM etc.