Recently someone asked me where the business rules should go in an MVC framework. The Model or the Controller? This reminded me of a post I wrote when ASP.NET MVC was first released.
But today I want to cover a broader topic common to everyone, not just programmers. Not being able to think outside the box.
I’ve noticed a trend recently. Someone will write a post about some technical interview question and someone will write a comment about how that’s such a dumb question that they wouldn’t even bother answering it. I’ve actually been that guy recently. John Sonmez wrote about “Cracking the Coding Interview” and I responded that I don’t do coding interviews. In fact, I wrote a whole post about this. But as John pointed out, this may actually cause you to be limiting your career. You wouldn’t answer that question for a 33% raise? Really? There isn’t anything that could motivate you to consider answering a question that you feel is useless, stupid or dumb? This week, I saw another post about some technical interview question that someone said he wouldn’t answer. Sorry, I don’t have a link for that one, I wish I did.
And then add to this, the number of useless interview questions I have answered in the last year. Why did I answer them? Because I could. Because the challenge was actually fun.
And so, let’s reconsider the arrogant stance of “Thanks for your time, I’ll show myself out.” First let’s consider why we might not want to answer a particular question.
I just got back from sending my last child off to college. OK. Now that you all have some vague idea of how old I am…
The weekend had all kinds of events that would make for good blog post.
Since I think I can hit the other two by focusing on the second, we are going to go after ‘Advice to Freshman’.
The advice I am going to provide here is going to be both general in nature and specific to the IT crowd. It is what I would tell a young IT person if I were coaching or giving a speech.
A couple of weeks ago I wrote a post “7 C# Interview Questions to Weed out Losers” which was my most popular post yet. As of this writing, it has received over 13,000 views. It also got a lot of comments.
While there are a lot of things I could respond to, the one I want to focus on today is what I would call, “The fallacy of concepts over terminology.” While none of the comments actually come out and say this, several imply that knowing the concept but not knowing the proper term for it is enough. In conversations with people I’ve worked with, I’ve received similar feedback. In fact, as recent as three years ago I actually told someone, “If you want someone who can pass some sort of test, I’m probably not your guy. If you want someone who is an awesome programmer, I’m your guy.” But three more years of experience has changed my mind.
Last week, I posted 7 interview questions for C# programmers. I guess I forgot that people can’t see in my brain. So, let me be very explicit this time. The “weed out the losers” questions are meant to do just that. Weed out people who have absolutely no business even applying for the job.
You would be amazed at how many people interview for a job who have all kinds of cool buzzwords on their resume, but when you ask them about it, they know nothing about the subject. I’m not sure if this is the recruiter who is representing them trying to help them out by beefing up the resume to get them in the door or if they actually do this themselves. But, as someone who interviews, I have to have a way of making sure the applicant I’m interviewing is worth interviewing in the first place. Hopefully, I can do this over the phone in less than a half an hour.
So, with that said, if your favorite question isn’t on this list, it is probably because it is a question I would save for some future interview.
Also, to those of you who may think that a technical interview doesn’t really tell you if the programmer is a good programmer or not, I have this to say… You are right. And when I was a younger programmer and was being interviewed with technical questions, I felt the same way. But now that I’m on the other side of the table, I find that way too often, the people who can pass a technical interview are a lot more likely to be good programmers than the ones who can’t.
And finally, I would not rule out an applicant because he got a couple of questions wrong, or didn’t answer them exactly the way I expected. But if couldn’t answer most of them, that would raise a huge red flag! So, here are 7 JavaScript Interview Questions you should ask first. Otherwise, you may be wasting your time.
So, once again, the place I am currently working has been interviewing for some more programmers and we’ve had to laugh at some of the answers we’ve received on some pretty simple question.
For example, in answer to “How do you create an object in JavaScript?” One applicant responded, “I always use the WHERE keyword.” What?!!! And that naturally got us all talking about good interview questions. How can we tell that the applicant is even worth interviewing? The following questions are not meant to be THE interview. The questions are meant to shorten the interview process by ensuring the applicant has a basic understanding of the language they will be expected to work with.
I got a question this last week that I answered very briefly but I felt that to answer it completely would take a blog post. So here’s the blog post.
Should the author of a piece of code be responsible for more than just unit testing, or does peer review have a play?
For the last two years, about 99% of the work I’ve been doing has been JavaScript programming using EXTjs. The problems I’ve encountered along the way are primarily related to testing. Writing unit test using the “MVC Framework” out of the box is nearly impossible, but I did eventually put together an architecture that allows me to do that. I may blog about that in the future.
Today, what I want to offer is how I overcame various hurdles related to testing EXTjs with Selenium. The first problem nearly everyone encounters when they first use EXTjs is that the views that are created are created dynamically. If you use the recommended itemId to uniquely identify the elements on the page, you will be left with IDs that are dynamically generated and inconsistent. That is, just because the ID has one value today doesn’t mean it will have the same value tomorrow. And since the controls are dynamically created based on what browser is running, XPATH queries aren’t a good solution either.
I had this thought this past week that we tend to believe that if we are in motion, we are accomplishing something. That being busy somehow equals being productive. And then I started thinking about how this is almost universal. It doesn’t just impact how we program, which I’ll get to eventually, but it impacts all of our life.
This probably doesn’t happen all that often, but this last week I came across the need to know which browser I was running my selenium test against. I figured that buried deep in the object structure of Selenium, there MUST be a way of finding out what browser I was currently running. As it turns out, I was right. The situation that caused this requirement is that the place where I’m currently writing most of my code is upgrading all the Firefox browsers. I was asked to make sure the code we were running still works with the new browser. When I did, I found that some of my tests broke even though the test itself still succeeds when it is run manually. In fact, they only broke when running against this new version of Firefox.