I got an interesting email a week or so ago (sorry folks, behind on my email again - blame CFUNITED, my cold, and a dog that required a 4 hour drive yesterday for a special vet) concerning certification. As folks know I shared my opinions on this back on June 3rd. I still haven't heard an official response from Adobe, which is a bit disappointing (hint hint, Ben, Jason, anyone? :) but hopefully that will come soon. Anyway, the reader had this to say (note I've hidden a few company names in here):
Well first off - let me address your "mind games" point. Many interviewers feel like they need to impress or even intimidate their interviewees. This is done for a variety of reasons, normally ego, but it doesn't usually help. Personally I don't want to attack someone I interview - or make them feel dumb. (I've found that every time I feel particularly smug - life tends to knock me down a few pegs.) I think you need to expect to run into people like this though. What I'd recommend is - try to talk to more people at the organization. If you find this attitude in the other people there, then it probably isn't a good place to work. At the end, it really depends on your personality. If strong willed folks tend to 'push you down', then you may not feel comfortable working there.I am a regular reader of your blog and really admire your projects and contribution towards the CF community. I started learning CF while I was still in school and continue to work on XXXXX projects as a consultant. Today, I was interviewed by someone from YYYY and only thing I realized that for some people it is very important to memorize CFML. I was so extremly excited that my resume has been short-listed at YYYY until this interview happened.
Your article that "an open letter to adobe on certification" (you can't memorize cfml) was still fresh in my mind and I said my interviewer that I am not good in memorizing. On which, he replies me with an example that if "you can do Maths 1+1=2, by regular usage of a cfml tag/function you would remember it."
Do you agree that if I could not recall cfimport or attributes of cfsetting during an interview, but only remember its uses, my years of CF experience count for null? My Flash certification and CF certifications count for nothing?
Sir, I want understand what is the best way to conduct a CF interview? Why do interviewers play mind games?
Tough I am waiting for a response from YYYY, my chances are so dim. I am so annoyed with all these development taking place.
Let me go though to the other question you brought up about memorization. I think this is a particular point that is hard to qualify. On one hand - I think it's important that a developer know the feature set of ColdFusion. They should know that functions exist for string parsing, date, image manipulation, etc. They should know how to properly abstract code, and the various ways of doing that (one of which is CFIMPORT). I'd ask you - how do you disable debugging on a per request basis. If you said "With cfsetting", I'd be happy, and if you couldn't remember SHOWDEBUGOUTPUT=FALSE, I'd forgive you. Or if you confused SHOWDEBUGOUTPUT and ENABLECFOUTPUTONLY (specifically show/enable) I'd unsderstand as well.
Memorizing the argument names though is less important to me. That's what a good IDE is for or a reference manual. Now - the flip side of that is that I'd expect you to know most of the language. If you are looking stuff up for every line of code I'd be worried. I have the memory of a bored cat, but even so I only hit up the reference guide about 10 times a day or so.
Archived Comments
I think, to a degree, knowing the attributes of a tag are important. However, I would take a person who can apply what they know but may need to look up some attributes sometimes over someone who can recite the WACK yet not really apply it anywhere.
Also, I think there are attributes of tags (and arguments of functions) that any good developer should know. For example, anyone who does not kow that 'datasource' is an attribute of <cfuery> and that it ties to a datasource defined in Cf Admin might be someone I woudl pass on. On the flip side, if someone did not know the 4 'types' that are available in <cflayout> I would not hold it against them.
Bottom line,I think its more important how someone thinks rather than how much they have memorized.
I think as an interviewer, I would be more interested to know how likely you would be to efficiently solve a problem and know what tools to reach for (which tags, whether you would need to create a component or custom tag, etc.) than to know you could recite the attributes of a tag.
Ray, I did take the CF7 Exam back in December of 06 and of course I didn't pass and only got a 61 but it was a great learning experience.
In some of the companies I worked with, they didn't use components, locking or UDFs at all and the code was definitely a spaghetti incident but wanting to be a better developer I search for a better job with people that were more into CF than other companies. I admitted right from the start what I was looking for to the interviewer and how much I enjoyed coding CF and XXXX company brought me on. After looking at their code, I totally felt like I just learned CF the day before but it was a great challenge to seeing more advanced development and I didn't need a certification. We even had a competition to see who could score highest on the exam and 3 of us failed and the other 4 scored above 85%
Couldn't agree with you more, Ray.
I have to confess in the past in the past I've been a bit guilty of giving difficult problems to interviewees and trying to put them in a tough spot. Part of it may have been my ego (which is admittedly enormous and self-deprecating at the same time), but after I got 20 candidates foisted on me by the recruiters my boss was using to find people, all of whom were completely unqualified and had minimal knowledge of CF I found my cynicism taking over.
As an interviewer I tend to be less interested in really specific knowledge (unless you purport to have it, in which case I will grill you on it) and more interested conceptually in how you program and solve problems. If you're supposed to be a pretty good SQL programmer, I'll probably give you an example table and ask how I might get the count for each record. If you misspell one of your SQL keywords I'm not going to flip out, but if you didn't realize "GROUP BY" existed then it becomes a problem.
Same for ColdFusion. Do you know what CFCs are? Do you use them? What design patterns have you used in the past? If you don't use design patterns, how would you architect a particular application of X scale? Do you understand the life of an HTTP request? (as web programmers we are often inadvertently forced to troubleshoot network issues)
I like code samples a lot and I even started using them as a pre-screening before I would interview anybody. I can usually get a pretty good idea of how good (or bad) someone actually is by looking at a sample of their work. I've seen some really lousy spaghetti code that shows me this person is just barely fluent in CF. One time I got a plagiarized copy/paste example from a candidate who even left the "this code taken from so-and-so-website" comment in the code. And then sometimes you get nicely written concise code and those are the people I then work with.
I couldn't agree with you more. Thanks for sharing your views.
Great points, Ray. I wanted to add in a little tidbit/story I learned in grad school. Apparently, an interviewer was chasing Albert Einstein down back in the day. He asked Einstein if he could call him for an interview. Einstein said yes and proceeded to walk into a phone booth, grab the phone book, find his number and read it to the interviewer.
The interviewer was shocked that the smartest man in the world did not know his own phone number. When he asked Einstein about this, Einstein responded by indicating, it's not what you know that matters but knowing how to get the answers.
Of course, I'm butchering it (grad school was a decade+ ago) but I think the larger point remains, especially in our discipline. If you can memorize tags, attributes, etc., good for you! That's awesome and you'll maybe code a little faster than some who need to look in reference guides and the like.
However, just because you memorized tags/attributes/functions, does not mean you know how to problem solve. There is no substitute for knowing how to get answers or solutions to your programming dilemmas. To me, this has nothing to do with memorization, which is what certification exams are all about.
And I say that as a CFMX 7 Certified "Advanced" developer. And that cracks me up, because I aced the test with tons of questions on CFCharts and I've never used CFCharts. Not once!
I'm not sure I would see the benefit of memorizing the syntax, when new features are added every year, changing the very syntax you memorized previously. I think its more important to know what you can do and where to look to figure out how. (what Craig said)
"Never memorize what you can look up in books." Said some guy from Austria with white fuzzy hair (-:
I remember someone on the cf-talk list said they asked an interviewee if they knew arrays. The guy answered, "Yeah, he met him in the hall"
Too funny!
I tend to be tough on interviewees simply because there tends to be a real lack of good portfolios out there to review. If all I have to go on is what the interviewee has to say sitting in a room with me, then I have no choice but to be very critical of what is being said to me.
One of the first things I ask is if the interviewee has sample code or sites that I can go out and take a look at to get a feel for their abilities. Maybe I've just had a bad run, but not one of the last 10 people I have interviewed has been able to give me anything. We can't all be working on intranet sites, can we?
And that's where the certification exam comes into play for me. If I don't have something I can look at to get a feel for how you code, having a standardized test score from what I know to be a pretty thorough test of CF knowledge (even if it is mainly knowing syntax) is something that helps. I'll be the first to admin that someone that can show me they took the effort to take the exam and pass it will be a step ahead. And if they passed it with an Advanced score, even more so.
In the end I will say that syntax is not nearly as important to me though as an understanding of best practices, both in terms of CF coding and in a general business sense. And my level of criticality will change based on the level of the position they are going for. From junior developers, I'm looking for a grasp of the basics and a willingness to learn and grow. For a senior position, not only do they need to be able and step in to be a go-to developer for difficult tasks, they also need to have an understanding of working in a team environment, be detail oriented, estimate well, and have a desire to be a mentor to junior staff. I don't need a "Cowboy Coder" on my team that knows CF inside and out but does not take direction well and is constantly falling short on basic task management details. Ultimately those people lead to projects falling behind or going over on cost because others are having to clean up the messes they leave behind.
I would aslo like to add that there are times when having the certification is required. A lot of government (US government) contracts require developers have the certification, and several I have worked on required 'Advanced'.
Personall, I have been certified since CFMX and plan to take the CF8 test soon. I do not think this shows my level of competancy, but you never know if you might need it (like for that big gov't contract)
I recently went through several interviews before finding my current job.
It was amazing how many were pretty much hard-core oral exams. It can be daunting being grilled by a company's IT team who seem to want nothing better than to stump you.
The position I found I knew from the first interview that they were the company I wanted to work for. They hit me with some conceptual questions and were impressed with my problem solving methods. I could tell they were looking for someone who could think around a project and not just a keyboard monkey.
So far it's been great here.