I am in total agreement with Kevin and Jason. When I interview, I don't really want to have to answer the questions like.. "do you prefer cfscript over cf tags and why?" or what is the different between "IS" and "EQ" and then have the interviewer tell you oh. It used to matter but it doesn't since CF8, when you're interviewing for a CF9 or 10 role.
As an interviewee. I expect one or two questions on coding.. None where I know good and well you are just trying to prove you know more than I do. Because when I get asked a question like that.. (and we all know that is generally how it goes), my firm response to it is ALWAYS. "I can't even make up something that sounds like I know what you are talking about" That kind of response generally lightens the atmosphere, and tells the interviewer he's smarter than you are.. Which is what he wants anyway. "Tell me how you approach full lifecycle development", and then stop me when you realize I know what I am talking about. And I actually don't mind reading code and telling the interviewer what the routine is supposed to accomplish Don't mind that at all. I do not want to be asked where I see myself in five years My standard response, whether they like it or not is this. "In five years, I plan on working at Publix during the day, and playing poker at night" Period. I don't have a five year plan, and the person asking the question doesn't really need to know what my 5 year plan is, and really doesn't care He wants to know if you are simply taking a job, looking for the next job. What an interview boils down to this "Can you do the job can you work with me, will you communicate with me when you need guidance?" From: Kevin Bachman <kevin.bach...@activegroup.net> Reply-To: <discussion@acfug.org> Date: Tuesday, March 12, 2013 2:34 PM To: "discussion@acfug.org" <discussion@acfug.org> Subject: RE: [ACFUG Discuss] Choosing a person with adequate CF skills This may be the most accurate and real-world description of candidate selection I have ever read. I agree whole-heartedly. [Printing and filing away for future reference.] Thanks for this! From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Jason Vanhoy Sent: Tuesday, March 12, 2013 2:12 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Choosing a person with adequate CF skills My first question would be are you hiring for an entry level, mid-level, or senior position? If you're hiring a senior position, none of the questions you outline is going to be worth a hill of beans for choosing the right candidate in my opinion. I come at this problem from the point of view of having been on many hundreds of interviews, having interviewed people a significant number of times as well, and making hiring decisions based on those interviews a number of times both successfully and unsuccessfully. In my humble opinion the technology world concentrates entirely too much on technology in an interview for a developer (or, for that matter, for a network engineer, DBA, etc., etc.) A few basic questions to decide whether or not the candidate is simply lying through their teeth on their resume are certainly in order. Maybe a few things like, "What's the difference between == and ===?" or "Explain to me how a CFC differs from the Custom Tag of yore?" or something that roughly targets the functional awareness you're targeting. Also, maybe a question or three about basic, non-language specific programming techniques are helpful. Some examples might be "Can you explain to me some design patterns you've had experience with and why they were or were not the right choice in those situations?" or "Can you tell me what the difference is between a class and an object?" Beyond about 20 or 30 minutes worth of this type of discussion, however, and all you're doing is showing off, or asking the candidate to show off, arcane and trivial knowledge. Developing software (web-delivered or otherwise) is not an eyes-closed operation, and any specific knowledge an employee needs to complete a task is readily available online, or in a book, or at a co-worker's desk, or in the company wiki, or...you get my point. So, knowing that a Java candidate, for example, knows off the top of his or her head what the differences between final, finally, and finalize is, is completely immaterial to whether or not he or she would be a good fit for your team. Here are what I consider the questions that one should have answers to at the end of a job interview, from the point of view of the interviewing agent (in order of increasing importance): 1) Is the candidate basically competent in the general skill set required? That is, for a software developer, do they have experience developing software in SOME language, do they understand BASIC concepts and can they apply those concepts. 2) Can the candidate express themselves well, professionally and competently? That is, do they speak clearly, do they explain things well enough but not TOO well? Do they understand the differences between site-specific knowledge and global knowledge? Do they grasp the language I use and understand what I'm saying, or, barring that, eloquently ask for clarifications that are logical and understandable? 3) Does the candidate's personality mesh well with the team they're going to be working with and will they likely enjoy being on the team? Will the team likely enjoy them being there? The great truth, at least in my experience, is that any competent developer can fairly quickly get up to speed on a new language or platform. However, to quote a good friend of mine (pardon the language) "you can't fix asshole." I'll give you an example: It's been probably a decade since I did any significant ColdFusion work. I would seriously have to have a syntax book beside me for a week if I started writing it today. I've got a ton of Flex experience, though, and very recent experience using it. Would I be a good candidate for your position? Well, the answer is "maybe." If I came into the interview and you asked me some question like, "Can you tell me the difference between a class and an object?" and I gave you the following answer: "Well, um, [drums fingers on table] a class is like...you know...how something IS, like...you know...how like, all of them are made up and stuff...but...um...[drums fingers again] an object is like just one of them, like...just a single one, you know...like...[taps knuckles on chair arm]...you know what I'm saying?" then the answer might change from "maybe" to "no". However, if I said, "Well, a class is the how an object-oriented design defines a real-world concept in code, and then an object is a single instance of that class that one can then do work on." the answer might start looking closer to "yes". If you look at both answers closely it will become clear they ultimately say the same, or a very similar, thing. However, one shows much better communication and a much greater ability to express one's self than the other. Additionally, if you and I are sitting in the conference room with several senior members of your team, and someone cracks a joke. Let's say I mentioned something about when I was first learning to code and how I relied on a bunch of senior folks to help me along or something, and one of your team says, "Well, if you can run, you walk, and if you can't walk you find someone to carry you..." Now, if I come back with "huh?" that's one thing, but if I respond with something like, "Shiny!" then you might start thinking, "Hey...this guy might fit in around here!" (By the way, if you didn't get that joke, it's a Firefly reference, and fairly obscure at that). So, my long-winded response is really just to say, I think you're focusing too much on the details and not enough on what's truly important about a candidate. Or, maybe you're not and you just wanted some advice about the first few technical aspects of the interview, and if so, ignore ALL my rambling. I like your idea about having the candidate do some actual thinking on your whiteboard. I'd hesitate to make it actual code, it would be more useful to see pseudocode or block diagrams so you can see more of the person's thought process rather than if they know syntax without a reference close by. I love the idea of having the candidate discuss recent projects and the failures or successes each may have had (as long as they can, some stuff is going to be privileged/confidential or covered in an NDA or something). I'd steer clear of operating system and networking concepts (unless you're planning on having someone write you a networking app in a web language, why would a candidate really need to know this?), or agile programming concepts ("agile" covers a huge range of development methodologies and nobody's version of any one of them is the same as anyone else's, it's a red herring question that probably won't tell you much). Anyway, hopefully some of this helps, good luck in finding the right person for that chair. ~JV On Tue, Mar 12, 2013 at 1:32 PM, Chris <h_chris...@yahoo.com> wrote: I am with a public university and asked to interview applicants with Coldfusion(CF) and Flex skills for an opening. The position requires someone who has worked 3-4 years in CF and Flex. I was moved into this position and I picked CF/Flex after I started so do not have a first hand experience of a CF/Flex interview, though a Web search reveals dozens of websites with questions. I have worked with Coldfusion 8 and 9 and I know I can ask questions about following topics. 1. Check for CF basic understanding, ask about functions which are rarely used to test depth of knowledge in CF. 2. Ask about CFC, Bean, Gateway to test OOP understanding in CF 3. How the facade pattern is used in CF? 4. Recent CF projects of candidate. Question the design, implementation decisions and possible performance improvements in the projects 5. Ask them to develop a Bean on whiteboard. 6. Contributions to an open source CF project Since the opening expects someone with a Bachelor's in Computer Science, I can ask the typical questions(algorithms, data structures, design patterns, OOP, contract by design, agile programming concepts, Operating System and Networking concepts, information security, bit fiddling in C, RTTI idiom in C++ assuming candidate lists C,C++ on his resume). I realize a Web search can reveal lot more questions, but since I have not interviewed someone for a CF background before, I want to know if items 1-6 listed above are sufficient or do they need more additions? Are they too simple that most people who have worked 12-18 months in CF would know? I do not want to make the interview unduly hard or easy. Any suggestions would be appreciated. Thanks P.S. I went through the usual books Career cup, Programming Interviews exposed and their websites to learn how interviews are done in most places today. ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink <http://www.fusionlink.com> ------------------------------------------------------------- ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink <http://www.fusionlink.com> ------------------------------------------------------------- ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -------------------------------------------------------------
