Interviewing build/release engineers
I recently interviewed a candidate for a build engineering position. I haven't done that much interviewing, and want to know what people think are important questions. Do you focus on technical skills (if so, how)? Are strong technical types who like to hole up in their bunkers good candidates? How important are people skills? I think diplomacy has its place in this line of work - we're at the center of a bunch of (in my case, internal) customers, and managing perceptions, especially about the somewhat fuzzy area of build/release engineering, can be part of it.
[576 byte] By [
JRWa] at [2007-11-26 23:33:51]
# 1
Good question- from my experience I'd say you need someone with a good balance of technical and people skills. There's a component of build/release engineering that is heads-down, and requires a person with an extremely detail-oriented, technical aptitude (in other words, you have to have a clue). But an equally important part of this role is bringing an overall vision to the build/release area. This means seeing the big picture, understanding where this fits into the software development lifecycle, being able to communicate your vision to people at all levels - developers to executive management. And you need to make it happen, which means building working relationships with people (and groups/teams) at all levels.
zmja at 2007-7-11 14:53:49 >
# 4
There are a couple of strategies for technical questions. A colleague of mine liked to ask questions that related to a difficult problem he himself had to solve during development (in one case, it was transforming an image in computer memory to a suitable format for the video memory of a mobile phone). He also liked to ask problem-solving questions. Some of the ones I've asked, or been asked:
http://www.emicrosoftinterview.com/Puzzles-Riddles/86.aspx
(getting people across a bridge; we used the band U2)
http://www.emicrosoftinterview.com/Puzzles-Riddles/90.aspx
(five people wearing colored hats, good logic problem)
http://www.emicrosoftinterview.com/Puzzles-Riddles/85.aspx
(personally I dislike these sorts of "aha" questions, no good way to work toward the solution)
http://www.emicrosoftinterview.com/Puzzles-Riddles/78.aspx
(clock hands angle, good math questions)
And if the job involves a particular technology, asking about that is always good. For instance, I have long since been involved in web technology, so a popular question was "Explain how HTTP works." Even someone who has never written a web browser or web server should at least understand that this involves a TCP/IP connection, the client sending a request with a URL, and the server responding with HTML. If they realize that there is additional meta information that is sent in both directions, great. If they haven't a clue, they are probably not very technical. But like I said, it helps to stick with questions related to the technology you're concerned with.
My personal favorite question was for developers with a CS degree. It involves designing a suitable data structure for a text editor. Popular answers are "linked list of characters/lines/paragraphs". These are actually quite terrible solutions. A popular implementation is the "gap" array, in which the insertion point references a position in a character array in which new text may be inserted. Sufficient space is reserved for inserting some text, and this is referred to as the gap. If the insertion point moves and the user begins to enter new text, the gap is adjusted to that new location in the character array. I believe emacs uses this, as does the Java Swing text support. Of course, this is lame, too, when compared with the solution sometimes referred to as a "piece table". A very good write-up and description can be found here:
http://www.catch22.net/tuts/bigmem02.asp
A question that I have never asked, but often wanted to, was the "program an elevator control system." That is, given a sequence of user inputs, determine which direction an elevator should travel. Obviously you want to prevent the elevator from bouncing between two floors, so a full sweep from top to bottom is required to prevent starvation. While the solution is not all that difficult, asking the candidate to write the algorithm on the whiteboard will generally separate the good from the inexperienced.
Another colleague of mine liked to ask candidates to design a thread or database connection pool (in Java). The emphasis was on properly controlling multi-thread access to the pool and prevention corruption (i.e. giving the same resource to two threads).
# 5
Personally, I'd enlarge the "technical" field of questions to try to cover a general approach to solving problems and engineering methods. For example, build engineering, more than some fields, requires that solutions have stability and repeatability. A hack solution might work for a specific case, but a hack solution spread throughout a build system is a nightmare to maintain and scale.
I do think there can be a lot of value in specific technical questions and logic puzzles, but they can also be deceptive.
A long time ago (in the days of MS-DOS 5.0) I interviewed for a QA job. One of the interviewers asked me about a very specific error message that could be spit out by DOS. Through pure chance, I had had the exact problem on my personal machine a couple of weeks earlier. After a lot of research and poking around, I had solved the problem.
The interviewer was pretty much stunned when I rattled off the exact problem and syntax of the solution, as he never expected anyone to know. I certainly wouldn't have had much of an idea if I hadn't run into the problem.I did end up with the job (and ended up good friends with the interviewer, as it happens.)
My point is that sometimes knowing the answer is less important than knowing how to find the answer. In a real work situation, there are many resources (books, articles, Bigadmin) that you can consult and work toward a solution. A technical question in an interview might only reward the very quick-minded or people who've had direct experience with that specific case.
I find that someone who can consider the implications and knows how to work toward a robust solution to a problem is a better candidate for a build engineering job than someone who can come up with something off the top of their head that may or may not be suitable for use in a large software organization.
