views:

5947

answers:

9

I am responsible for creating a team, which will build a Flex application. Unfortunately I have zero experience with Flex. So I found an expert within our company to interview candidates. Our expert came up with the following questions:

  1. how to write item renderers
  2. explain methods commitProperties, updateDisplayList, measure
  3. binding positive / negative parts, problems with binding
  4. what is ClassFactory ? And why is it needed ?
  5. how callLater works ?
  6. what is layoutChrome ?
  7. what is skin ?
  8. did you use autogeneration for Java backend ?
  9. how to override managers ? like PopupManager .

These sound a little too specific for my taste. Would you say they are decent questions? Is it fair to say, for example, that if Flex developer does not know how to write item renderer, he has very little knowledge of Flex?

A: 

I do not have extensive flex experience, but I do have quite a bit of experience interviewing (Java/J2EE) developers. I would suggest that you develop a list of questions that targets both the specifics of the language (which is what your expert provided) as well as questions that allow you to see how the candidate thinks and exposes their understanding of software engineering. An example of this type of question could be: "Can you explain the concept of decoupling, and why it is important?".

Rich Kroll
+1  A: 

I think you are on the right track, but an interview that asks only Flex questions will be incomplete and you may not get the whole story.

Here are some interview topics that you can consider.

  1. Flex Questions (done and done)
  2. personality questions (how will this person fit on your team?)
  3. generic programming questions (do you understand the basics)
  4. problem solving questions (language agnostic, but lets you assess their problem solving skills.)

The wider range of questions you ask the better, this will give you a better overall feel for the candidate, not just whether or not they know some random Flex facts and buzzwords.

Robert Greiner
+5  A: 

I think these questions are useful, but the best future employee may not be the one who has technical answers for these. For instance, I've written itemRenderers, but I don't have a clue how to write one right now-- I don't have excess space in my brain for stuff that is easy to look up. I'd answer "I'd review the relevant section in devguide_flex3.pdf then look at flexexamples.com and our existing codebase for examples that match our situation."

Knowing something about callLater, binding, and updateDisplayList would indicate the candidate has a grip on the idiosyncrasies of flex, which is important.

Gregory Cosmo Haun
A: 

I'm all for asking questions but people know how to blow smoke. Go ahead and ask those questions you listed, which are great questions by the way, but the most important question is "Can you show me some code?"

I take code over resumes on every hire I make.

johncblandii
+4  A: 

I would say that these questions are too specific. If you're looking for flex pro's (not even mid-level specialists), then these questions will work OK. Otherwise I think they're too hard and it'll be very difficult to find such specialists. By hard I mean the following questions:

  1. explain methods commitProperties, updateDisplayList, measure (dedicated solely to sophisticated custom components)
  2. how callLater works? (it involves knowledge of flash player specifics and not really neccesarry for doing good flex job.
  3. what is layoutChrome? (too container-specific. Even I (3 years of flex experience) can't answer this question without looking into reference)
  4. how to override managers ? like PopupManager. (actually, don't know the answer myself, will be glad to see one).

I believe these problems are not that frequent in developing flex apps.

Hrundik
+1  A: 

I think these questions are good to evaluate a candidate who is currently using/studying flex. But like Gregory said.. if he has used it a long time ago he may not remember at the time of the interview the correct answer, so these questions would be used cautiously.

Some questions that would be good to see if the candidate really knows how Flex works (and add the ones you already have) are the ones which asks about the flex mechanism... examples below:

  • How the flex event system works? And how is it different from the request and response paradigm?

  • What is the difference between components and modules? How does the modules works and when is it good to use it?

Also some questions about languages differences, design patterns commonly used on flex (like the ModelLocator of Cairngorm) and third party flex tools (this one is to see if the candidate knows what is being developed in flex). Some examples..

  • What is the difference between Action based and component based languages?
  • Give examples of 3 third party tools you used and how do you like it.
Diego Dias
A: 

Doing interview is art and need lot of experince not list of questions. I have 10 years teaching experience in the fields of enginerring where we do lost of oral examination each semester and also almost 10 years of IT experience with c++, java, flex, j2ee, oracle and Black berry development. Best way to judge a person is ask him what he did and how he did. Based on that you can ask some specifc questions but, that required interviewer has good understanding of field too. He/she should be able to think about dynamic questions related to candidate's experience.

I feel these questions are too specifc and a good candiadte may not be able to anwsers these question incase he/she is working on different tiers at same time.

amarjit
A: 

Please have a look at look, this may help you out:

http://www.interviewhelper.org/categorydetail.php?Cat=142&level=1&title=Flex

Nisha
A: 

These questions are probably good for UI developer. If you're looking for such, then those are good. I would ask more generic questions about ActionScript. Person may know what Chrome is, but may miss important parts about memory management for instance. So you should ask about garbage collection, object lifecycle. How do you implement property getters and setters? Bindings are actually evil. They may look good for old school Flash developers though.