technical question
- Thread starter psd99
- Start date
Associate
Would depend a lot on the type of technical, eg is it mechanical, or electrical etc?
But for me, basically, I would start by observing the result of the issue to narrow down the cause of it, then if I had a good idea what was wrong, I would start by taking a close look (opening up & probing with a multimeter/oscilloscope for example). If I didn't have any idea, I would probably google it to see if anyone else had come across the problem. (although they're probably not looking for that last bit in an interview question, but they might like you saying you would consult with people you know that might have come across something similar)
But for me, basically, I would start by observing the result of the issue to narrow down the cause of it, then if I had a good idea what was wrong, I would start by taking a close look (opening up & probing with a multimeter/oscilloscope for example). If I didn't have any idea, I would probably google it to see if anyone else had come across the problem. (although they're probably not looking for that last bit in an interview question, but they might like you saying you would consult with people you know that might have come across something similar)
Man of Honour
I would fix the problem and go about it in a logical manner.
Simples!
Start off with a flowchart.... then go and ask someone for help....
Permabanned
Pay someone else to do it then charge the client double for the work. Sit back and order pizza.
Caporegime
1. Make sure I understood the problem, observing the failure in person if possible.
2. Obtain as much relevant information as possible, debug logs, screen shots etc.
3. Attempt to reproduce the problem in a development/test environment.
4. Identify and fix the defect using the appropriate tools e.g. debuggers, packet sniffers, code analysis, internet resources
5. Deploy the fix and test that the original failure no longer occurs. Suppose you'd better make sure you haven't broken anything else too
2. Obtain as much relevant information as possible, debug logs, screen shots etc.
3. Attempt to reproduce the problem in a development/test environment.
4. Identify and fix the defect using the appropriate tools e.g. debuggers, packet sniffers, code analysis, internet resources
5. Deploy the fix and test that the original failure no longer occurs. Suppose you'd better make sure you haven't broken anything else too
Associate
If the computer has sata connection it should work fine but you wont get sata3(6gbs) transfer speed
Not bad
1. Make sure I understood the problem, observing the failure in person if possible.
2. Obtain as much relevant information as possible, debug logs, screen shots etc.
3. Attempt to reproduce the problem in a development/test environment.
4. Identify and fix the defect using the appropriate tools e.g. debuggers, packet sniffers, code analysis, internet resources
5. Deploy the fix and test that the original failure no longer occurs. Suppose you'd better make sure you haven't broken anything else too
Not bad
Associate
- Joined
- 11 Aug 2010
- Posts
- 486
Seriously the number of people in interviews who refuse to name Google as a resource are always off to a bad start in IT.
Soldato
- Joined
- 31 May 2009
- Posts
- 21,456
I would setup the answerphone to ask people if they turned it off and turned it on again.