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 <[email protected]> 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>
> -------------------------------------------------------------
