competency based interviews

[FishThrower]

Hi,

Can someone tell me whats the best answer to the below two questions? They are negative points which you have to turn out to be positive ones. I have a job interview tomorrow and im just reading up some example questions.

-------------------------

What area do you think could improve on most?

If you could change something about yourself what would it be?

Have you ever had to deal with conflict in work, how did you deal with this, what was the outcome

--------------------------

Thanks!

 

[FishThrower]

What's the interview for ?

MW

for a IT Support job

thanks

 

[FishThrower]

An an engineer-type, always state that I see paperwork as my main weakness (it's commonly accepted that most IT/engineer types have this as their weakest area). State that you constantly strive to improve this area - that's all they are looking for.

Change something about yourself - something like "sometimes I use too many technical terms when explaining a technical concept to a non-tech person. I'm aware of this and actively looking to improve on my non-technical communication"

Conflict - make something up that sounds good. Honestly.

Thanks a lot, not reading documentation before heading into something is a great answer

 

[FishThrower]

That's not what he means, that would be a bad answer.

Not really, all of the techies I have worked with always attempts to fix a problem, and then resort to the documentation when they get stuck.

If its installing a piece of software then everyone should consult the documentation first.

Any answer that you give to a negative competency based question will sound bad unless you accept it and also explain a solution to the weakness

 

[FishThrower]

I guess it depends what the job is, if you fix printers maybe.

If your an engineer or developer not reading the spec will result in weeks of wasted work as you are doing completely the wrong thing.

In that situation bad at paperwork means you're a little slack on documenting the project milestones, user documentation, basically anything *you* write, not reading a user manual.

You have to indeed read the spec, or pre installation requirements if you are doing project work, or implementing a system. If its incidents on the other hand then its very rare for a techie to check out documention on a system they arent too familiar with, before they visit a user to fix their issue.

You couls say that paperwork (timesheets, updating documention) is a much worse answer than I originally gave, as most companies rely on timesheets to bill other departments or companies. If you forget to enter timesheets, your department will not get any money for your time.

Documentation is a funny thing, as if you work in a large team, everybody HAS to update it, otherwise it will make it worthless, and when theres out of date documention (or multiple versions), its a complete pig to work with. A lot of companies should be really anal on documentation , or not bother at all with it.

Thanks for the input Rathbone, you have been a big help