> > You can't have a guy dragging the office around just because he knew the > right answers at one specific time.
This has been a bum deal for me over the past 5 months. I've sat in on 3 interviews for a flash/flex developer and have told the rest in the interview that the person was not qualified yet they still hired them based on some canned responses (hell... one knew a little about silverlight and no Actionscript what so ever!!!!). All three either quit or was moved to a different team in under a month and yours truly had to take up their work. If you are going to hire some one they need to be able to do the dang job! Hence why my last day is Friday!!! ;) As for the questions. When thinking about flash and the many ways to do a single task, I feel the concept of how to think the problem through is a lot more important than having the person sit and write code. The understanding of what needs to be done and the steps to take to get it done with a side of excitement goes a long way for me. A lot of good points and perspectives have come up in this thread! Keep it coming! :) B. On Wed, Jul 30, 2008 at 8:21 AM, Zeh Fernando <[EMAIL PROTECTED]> wrote: > This is something I forgot - a trial period of 1-3 months is a real > necessity. There's just so much you had to know about an employee on Flash > development, that just an interview doesn't cut it; seeing how the person > works once he/she settles down is a must. You can't have a guy dragging the > office around just because he knew the right answers at one specific time. > > So no, it does not sound sad to me, sorry if I sounded harsh or anything > (that wasn't my intention). What made me kind of down was just focusing too > much on a questionnaire. I understand the rationale and I've applied > something similar on interviews I've done or helped doing in the past, but I > just think stuff like that need to be considered with some real caution. It > may guide but it can't lead. Getting to know how the guy/gal works and > what's his or her pace is more important than having them fill in the blanks > successfully (but also more difficult). > > > Zeh > > Sidney de Koning wrote: > >> So where it all comes down to is that everybody has its own personal >> preferences of doing. >> A personal set of things to do and how to spot a good coder or an opinion >> on what makes a good flash developer, whether this is by showing code, >> letting them do some questions, shoing some work or all of the above. >> >> If somebody steps into our office and understands the concept of >> programming, knows its syntax but is not that good in AS coding, i'll give >> him / her a shot, treat that person as a junior and see what they do in >> their trial period(mostly it is 1 or 2 months, depending what country you >> are in). Depending on the questions they ask you kindof know what they are >> like. >> If they've proven them selfs usefull and are willing to learn, i'll invest >> in that person with a contract. >> >> Does that still sound sad to you Zeh? >> >> Sid >> >> >> On Jul 30, 2008, at 3:47 PM, Zeh Fernando wrote: >> >> I don't know about you guys, but that checklist of skills and the >>> possibility of getting that on an interview make me depressed. >>> >>> Of that list, I'm pretty sure I can do it all, but most of that are not >>> something I do all the time every day so I may have the gist of it, but not >>> know the syntax down to its every comma. I personally use the reference >>> *and* the internet every tie when writing code - for example, I never use >>> cue points, and while I know perfectly well how it works, I'd have to see >>> how the event works and do a few tests before applying it to my code. >>> Nothing huge that takes day of research, but still. That's I think just >>> shooting a lot of questions to the interviewee may help filter out the crap >>> but also won't help you find the best candidates; I honestly think good >>> developers, specially in the Flash world, are the ones who can quickly find >>> the answer to a new question before having to ask around, be it by using the >>> reference, be using by using the internet, or by testing. Remember this >>> technology changes at a fast pace. Having a catalog of techniques in your >>> mind may show experience, but there'll be gaping holes if the guy's work was >>> focused somewhere else or if he's not very formally trained. >>> >>> Personally, on an interview, I'd ask to see the candidate's previous work >>> that's online (doing so next to him). Ask him what kind of techniques were >>> in place on that particular website, question him about interface elements. >>> Give hints on how you'd do something he has done and see his reaction, >>> whether he gets "into" it and start discussing code with a peer or whether >>> he shows he's full of shit. Ask how long that particular work took, and >>> whether someone helped him, and what external classes or frameworks he used. >>> Ask him what kind of work he liked the most, and why. Which was the most >>> difficult one he did recently, and why. Ask what kind of work he doesn't >>> like doing. Try to get a hang of how he works, and try to understand what >>> motivates and unmotivates him. If possible, ask to see some real-life code >>> he's produced, and then see what kind of techniques he does apply on real >>> code more than just knowing the number of a dozen design patterns. >>> >>> I don't know if you guys get too many interviewees or something that >>> warrants a list like that to make things faster. But for website development >>> in Flash, I think there's so much more that's necessary than just schoolbook >>> knowledge that focusing too much on the checklist really seems >>> counterproductive and sad to me. >>> >>> Zeh >>> >>> Sidney de Koning wrote: >>> >>>> The list of questions i always ask interviewees are the following, and >>>> this gives me a pretty good example of what they are like and what their >>>> skillset is. >>>> Test is always accompanied with a practical test we make up on the spot. >>>> The XML in Q16 is made up, you can create your own for this. >>>> Feel free to use this, >>>> Cheers, >>>> Sid >>>> 1 - write an event listener (normal and weak referenced) and handling >>>> function for a Sprite >>>> named 'beginQuestions' and listen for a mouse click. >>>> 2 - what does weak referenced mean in regards to event listeners? >>>> 3 - what is the difference between an object an an array? >>>> 4 - how doe you get cue point from vidio in AS3? And in AS2? >>>> 5 - briefly explain the various datatypes for numbers. >>>> 6 - how do you load an external file? >>>> 7 - draw a 20px by 20px Rectangle using the graphics API. >>>> 8 - which of the following cannot contain other display objects? >>>> Sprite, Shape, MovieClip, DisplayObjectContainer. >>>> 9 - which properties can you use to change the size of DisplayObjects? >>>> 10 - ENTER_FRAME is independant of an SWF's frame rate? True or false? >>>> 11 - XP is a type of which programming methology? >>>> 12 - why would you use a Singleton? >>>> 13 - what is the Document Class? >>>> 14 - create a new TextField instance, then add text it, then add some >>>> more text. >>>> 15 - what is the difference between public, private and protected. >>>> 16 - look at the piece of XML (see other sheet). How do i: >>>> - Get all of the page nodes as an XMLList. >>>> - Get node in showcase where the attribute id=1. 17 - listen for >>>> when the 'enter key' is pressed and >>>> trace out "all questions are now done" when the event happens. >>>> Sidney de Koning >>>> Flash / AIR Developer @ www.funky-monkey.nl >>>> Technical Writer @ www.insideria.com >>>> _______________________________________________ >>>> Flashcoders mailing list >>>> Flashcoders@chattyfig.figleaf.com >>>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>>> >>> _______________________________________________ >>> Flashcoders mailing list >>> Flashcoders@chattyfig.figleaf.com >>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >>> >>> >> Sidney de Koning >> Flash / AIR Developer @ www.funky-monkey.nl >> Technical Writer @ www.insideria.com >> >> >> >> >> >> >> _______________________________________________ >> Flashcoders mailing list >> Flashcoders@chattyfig.figleaf.com >> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >> >> _______________________________________________ > Flashcoders mailing list > Flashcoders@chattyfig.figleaf.com > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
