Thanks Jason,
One thing I would like to mention is focusing on algorithms, data structures,
concurrency is useful since we all need people who use the right tool for the
task in hand. I feel, to some extent, a CS degree gives you an advantage in
that. Yes, I realize there are gazillion folks who do not have a CS degree and
are doing well, but in a university environment they expect that.
I appreciate your suggestions, wishes and time.
________________________________
From: Jason Vanhoy <jpvan...@gmail.com>
To: discussion@acfug.org
Sent: Tuesday, March 12, 2013 3:33 PM
Subject: Re: [ACFUG Discuss] Choosing a person with adequate CF skills
To answer the question directly, I would say that the most use from those more
nuts & bolts-oriented interviews is gained during interviews for entry-level
folks. Folks who are the most likely to be in denial about their own abilities,
and folks most likely to have serious deficiencies in their skill set.
To answer it in a more lengthy fashion I'd say that your point that "[you]
estimate most companies do that(focus on language competence, algorithms,
data-structures, Computer Science concepts like concurrency etc)" is
absoloutely true, and, in fact, the very thing I find problematic about
interviewing in general. I think focusing on that type of interview is likely
to get you an employee who is well-versed in interviewing, rather than someone
who's a good fit for your team and a skilled, problem-solving developer.
You go on to state that "if someone has worked in CF for 3-4 years, he/she can
get things done lot quickly in CF than someone who is a skilled developer in
C/C++, but new to CF" is generally only true for the first 2-4 weeks. After
that the developer who was skilled in another language/platform is probably not
even having to look at syntax documentation any more. So, if we all agree that
the first month to 90 days of an employee's time on your team is the time
period where they're relatively unproductive and a "cost" rather than an
"asset" then it becomes an irrelevant distinction. Of course, if we don't agree
on that timespan between hiring and actual productivity, your mileage will vary.
I like Frank's point a lot about writing actual code versus looking at code on
a page. I've used that technique a number of times to weed out candidates for
entry-level or mid-level positions who were...let's call it "optimistic" about
their skill set.
Ultimately you've got to do whatever you feel is best for your team, and what
you can feel confident about within the parameters your superiors have given
you. For example, the CS degree requirement, which I didn't mention earlier (I
assumed it came from "on high"), but one I feel is egregiously short-sighted as
Dawn alluded to. My approach may not work well for you in the structured,
vetted, everything-provable-on-paper environment at a University, but hopefully
there was some insight there that helps in some way.
At the very least, what I'd most like to see you take away from the discussion
is that exposing a candidate to your whole team, or at least senior members of
it, and getting their gut-feeling reactions afterwards is pretty important. The
last thing you want to do is spend several thousand dollars hiring someone,
then spend several MORE thousand on their salary and benefits and access cards
and so forth, only to find out that that person grates on the very last nerve
of five other employees and, while being able to quote the Gang of Four chapter
and verse, lowers your overall productivity by virtue of incompatibility.
At any rate, good luck to you!
~Jason
On Tue, Mar 12, 2013 at 3:02 PM, Chris <h_chris...@yahoo.com> wrote:
Thanks Jason.
>
>Position would be a bit mid-level since it expects 3-4 years in
>Flex/Coldfusion. Do you feel the questions are pointless now or are they too
>easy for mid-level position?
>
>1, 2, 3 you listed are something most applicants might have today since each
>opening in the technology field attracts lot of well qualified candidates in
>today's market.
>
>I went through the books by Careercup, programming interviews exposed to get a
>feel of how developer interviews are done today and I estimate most companies
>do that(focus on language competence, algorithms, data-structures, Computer
>Science concepts like concurrency etc).
>
>The idea of language competence comes from if someone has worked in CF for 3-4
>years, he/she can get things done lot quickly in CF than someone who is a
>skilled developer in C/C++, but
new to CF. I imagine this is why lot of start-ups want people with "N" years
of experience in the language/tool/database they are using.
>
>I appreciate your comments and suggestions.
>
>
>
>________________________________
> From: Jason Vanhoy <jpvan...@gmail.com>
>To: discussion@acfug.org
>Sent: Tuesday, March 12, 2013 2:11 PM
>
>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
>>-------------------------------------------------------------
>
>
>
>
>-------------------------------------------------------------
>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
>-------------------------------------------------------------
-------------------------------------------------------------
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
-------------------------------------------------------------
