The Best Way to Perform A Technical Interview

After twenty plus years of working in information technology, I've given, and been given, a lot more than my share of technical interviews. Often being the one who will give prompt and detailed feedback to a recruiter has cause most of the extra interviews. While I actually do not need an exact count, I have easily been on the question-asking side of over 200 technical interviews.

As time has passed, I have changed what and how I ask questions during a complex interview.

The default, and most frequent, move to make in a complex interview would be to grill anyone about constraints of variable types, memory allocation, when to utilize "having" vs. "where" clauses in SQL and other forms of questions linked to these.

To be a successful it jobs in london, one does need correct basic syntax and a knowledge base about what applies when. There is no arguing this. The is "several method to skin a cat ".

Inevitably, the interviewer is asking thing from their point of reference and how they've done things before. In the same way inevitable they are going to genuinely believe that those who do things like they've done them are correct and people who have done something else are wrong. Put another way "my trivia is better than your trivia."

Too many times I have found someone who could answer every technical little bit of trivia I could throw their way. After dealing with a few of these people for months or years later and having them become unproductive or even draining resources on a project, I realized I wanted an improved method of asking questions and better questions to ask.

I am aware start my technical interviews by asking them about their projects. How big? Just how many developers? Did they be involved in the architecture or were they just given design patterns to follow along with? What were those design patterns? What were one other options besides the manner in which you achieved it? How can you improve to them?

That which you start seeing is how well the in-patient understood the technical environment in that they worked. Did they create the environmental surroundings or simply a cog of a more impressive bit of machinery? Not everybody on every project creates the technical architecture. Often it is one person and thirty individuals have to call home with it. Sometimes this 1 person had no business creating the architecture.

Must be candidate has spent the final couple of years working together with certain technical handcuffs that you would not need created, does not cause them to become a bad candidate. In reality they could be better because they've seen the way of how not to complete something.

The questions in the above list will give you some insight into how they conform to the technical environment they live in. Someone who has the mental capacity to know the way in which things work, even if they're different, and who strives to find a better way, is a lot more valuable to possess on a group than the person who just happened to own read the last book you did.