All our Web developments are trying to get the most of the AJAX-style application. And we feel that Internet Explorer is not prepared for the forthcoming AJAX applications: The Applications in the Browser. These applications will use the browser as Java application uses the Java Virtual Machine. And you know, it really takes a lot of resources from the desktop.
We have recently built a mash-up application with heavy use of AJAX techniques, and Internet Explorer needs special optimizations because of its poor memory management, bad performance creating objects, and poor event performance. We did not find these problems in Firefox. Firefox is more efficient than IE, even with all the problems reported of memory leaks.
I think that in the months to come a new breed of web applications will arise, and some of them will start to ask their users to not to use Internet Explorer for a better user experience.
The promising Internet Explorer version 7 should be adapted to these new applications, but I think it is not. And it can make Microsoft to be out of the new wave of Internet Applications. So, if the Operating System is not necessary anymore, and the browser that should substitute the Operating System does not perform very well with the new applications, why should I migrate to the bloated Windows Vista?
But this last assertion will take me a new post...
-- From Diego
]]>
In the first part of this I discussed the technical interview. After the technical interview, we like to examine the candidate's "soft" skills.
Some of you might argue that since the candidate passed the technical part, there are no more questions needed. I disagree with this. In our profession we are not sitting in a room alone with no human contact. Daily we interact with our team, management, and the stakeholders. If our people skills are not up to par with our technical skills, then the performance as a whole will suffer.
One important distinction between the technical and the soft skill interview is that the interviewee drives the technical while the candidate drives the soft skill. So you should find yourself doing much more listening in the soft skill interview than in the technical. This is the time that you want the candidate to be talking, and hopefully making sense.
The question I start with for every soft skill interview is "Tell me about your current project and role in that project". Now sit back, relax, and let the candidate talk. Some things to look for:
1) Does the candidate feel comfortable talking to you?
2) Do you get a sense of excitement or ownership from the candidate?
3) Imagine the candidate talking about your project, is this how you would want it portrayed?
Once the candidate is finished describing the project the interview can go in many directions. Here are some ideas of where to go next. As you do more soft interviews, you will start to get a better feel of what to ask next.
- What was your biggest success during your career?
- Describe the hardest bug you have tracked down and how you fixed it.
- If you could change something on your current team, what would it be and why?
- Tell me about your ideal work environment
After the candidate is finished there are two things left to do. First is give the candidate an opportunity to ask questions to you. Try to answer these as truthfully as you can, lying to the candidate will come back at you if you hire the person.
The last thing to do is to give the candidate a sales pitch about your company. Developers talk amongst themselves. So take this time and sell your company to the person. Maybe you won't hire the candidate, but your chances to have your name mentioned has now increased.
-- From Aaron Korver
]]>
Interviewing to me is definitely a trained skill that you have to practice with. Your goal is to extract as much information from the candidate so that you can make a useful recommendation. If you get too little information then your recommendation will contain more of a risk.
Each candidate that is interviewed is a different person and thus each interview is slightly different. For example: A candidate directly out of college will be asked different questions then a person with 10 years in the industry.
Regardless of the person, if they are wanting work as a professional programmer then they need to know a few of the basics. For the most part, it comes down to communication. When you interact with other programmers you have a basic vocabulary that is used. If the candidate doesn't have that vocabulary, then communication between the candidate and the other developers will be hindered.
I also am a strong believer that if you are going to work in the industry, you should at least have a basic understand of the underlying workings of a computer. Thus my questions are more general, yet still technical.
So this is my personal interviewing technique. One thing to note is that I try very hard to not ask trivia questions. These questions are things like "What does transient mean?". Guess what, I can look it up if I need it. I'm much more interested in if the candidate has a good solid base to grow with.
The first thing I hit on is what is a bit and a byte. From there I ask the primative types in Java and their sizes. The sizes question shouldn't be difficult if the candidate understands basic memory storage. Simply start with byte and work your way up, increasing the power of two each time.
Directly following this is a discussion about Data Structures. Remember your old friends (Map,Set,List,Array,Tree,Graph,Stack,Queue)? Hopefully you can name a couple of these, explain what makes each of them special, and have an example of when to use them. Oh, and a good side discussion regarding the equals() and hashcode() methods is good here as well.
Next is basic OO terminology. This is that vocabulary I discussed above. Polymorphism, encapsulation, interface, inheritance, overloading, overriding, pass by referrence, object, class, abstract class. If you don't know these then how can you a)communicate with your co-workers and b)create object-oriented software?
After OO I look at the resume and determine if they have database experience and if they are comfortable answering database questions. If yes then I would discuss primary keys, relationships, common database problems, and joins.
To round off the technical portion of the interview I discuss software designing. Things like coupling, cohesion, design patterns, tiered architecture. Usually I also go through a modelling question as well to see what types of behavior and attributes the candidate can come up with. The modelling question has been an item of hot debate with the team and we have yet to find a question that we are happy with.
My final technical interviewing requirement is asking the candidate to code. What? Code at an interview for a job that requires coding? That's crazy! The sad fact is that I have never been asked to code at any interview I've gone through. Would you hire a knife throwing juggler without seeing him or her juggle? NO! So why do we allow people to code without seeing them, well, code?
It doesn't take long to come up with some sort of coding exercise that can be written on the board or a piece of paper. Yikes! No IDE for help? Well, yeah, see the idea is that the exercise shouldn't really need an IDE. It should be simple enough to finish in 5 min, yet hard enough to get some sort of information from it. Currently the question has been working well.
If the candidate passes the technical portion of the interview, then it is onto Step 2, the soft skills interview.
-- From Aaron Korver
]]>