Tell me about my thinking when interviewing others,
and understand it in reverse, that is, what should be paid attention to during the interview; the bold part is marked
The general interview is divided into the following parts:
1. Self-introduction
Most people like to talk a lot about this part, but it is not necessary. Just explain your professional experience, your core competencies or the tool framework you use well within about 5 minutes.
If you talk too much, the interviewer will be very irritable.
2. Project experience
I will ask about some project experiences that I am interested in, and I will not ask if I am not interested.
There are a lot of resumes here that exaggerate what they have done. I think it is okay to exaggerate, but pay attention to:
1. For all the things that are really made by you, you must be prepared for the interviewer's digging questions.
For example, if you wrote an automated test Q, then I will definitely ask about the actual benefits of automated testing, interception rate, how long it takes to run a round, and what is the false positive rate. For example, if you wrote the pytest framework, then I will ask about its concurrency, filter a, etc. usage.
2. Everything is not entirely done by you, but by the team. You must answer honestly and don't pretend to be stupid.
Because since the interviewer asked, it means that he knows it well here, and you can't get it wrong.
3. Don't put anything that has nothing to do with you in your resume. Same reason as above
There may be several free questions here.
One is, what do you think are the key and difficult points of this project?
The answer to this question is very important. You must understand that testing ability is universal, if you can test item a, you should be able to test item b.
But if you think there is no difference between a and b, it means that you have the same way of thinking about testing a and b, so you can't test a and b well, so you can't test
c well either.
Think about the projects you have done, what is the difference between them, and what special tests you have designed for them. This question is very
important.
One is, what is the most impressive bug in your memory?
Many students will not answer this question, so I will think that you are not distracted in your actual work, or you have not detected any important bugs.
It is recommended to prepare 1-2 classic bugs; it is best to have a certain complexity, such as performance, consistency, long troubleshooting links, etc.
One is, given enough time and resources, what would you like to do?
This question can be prepared in advance.
3. Basic knowledge
School admissions may focus on this.
There is nothing to say, I still have to recite it.
4. Code questions
For positions that do not require code, generally do not investigate.
For positions that require code, there is a simple investigation of single-loop topics and complex double-loop topics. Some people like to come up with kmp, front-middle-back order traversal a, dynamic programming a and so on, which are more difficult, and I think it is boring to take the test.
Nothing to say, let's get ready.
The point is actually that if you are quality assurance, then your own code quality awareness must be high. You have to carefully consider
issues such as boundary values, abnormal input, and data type overflow; don't write code yourself that is full of loopholes.
V. Test Design
There may be two design topics here.
One is to come up with an abstract design like "how to test a pen". It is best to practice this kind of topic in advance.
One is the actual test design of a scene, which is the actual application of the ability of the previous question. So don't look down on topics like "how to test a pen", it can effectively help exercise your ability.
6. Others
There are two soft qualities in the interview process, communication and initiative.
Communication is all about clarity and organization. I personally recommend answering all questions, if there are multiple subitems, in list form (first
, second, third), or in a tree structure Q (first level, second level).
The initiative is that you can talk about something other than the interviewer's questions, but more relevant things, instead of letting the interviewer
ask questions unilaterally.
Finally, let's talk about today's focus
"Tricky" questions you may encounter
(A total of 800 courses +, some examples)
Technical questions
1. What kind of projects have you done before? Tell me about your testing process? What kind of work did you do in the project team?
2. The situation of the project, what type of test are you mainly doing?
3. What do you do if you think it is a bug, but the development disagrees?
4. Given you a website, how do you test it?
5. Are you familiar with database? Do you usually use the database a lot? (About 1/4 of the test process is checking the database)
6. What command does Linux use to view files, and what command does it use to view processes?
7. What commands are commonly used to view logs, and what are the main contents to be viewed?
8. Software test case design/test case content/management tools?
9. How to judge that a problem is a bug?
10. What design methods are usually used in writing test cases?
11. What are the different test plan a activities?
12. What information should be included in a bug or bug report for development?
13. What do you think is the value of automated testing? Why does your company need automated testing?
14. Give an example to explain the abnormalities you have encountered
15. What is PO mode Q and why should I use it
16. Can you encapsulate the automated testing framework Q?
career development questions
1. Where is your greatest interest in testing? Why?
2. What is your testing career development?
3. What qualities do you think testers need to possess?
4. Why are you able to do this line of testing?
5. What qualities and skills should a test engineer possess?
6. What do you think is the key to doing a good job in test case design?
7. What do you think is the key to doing a good job in test planning?
buried pit problem
1. How do you view overtime issues?
2. Based on the current national conditions in China, most companies have tight project schedules, fewer personnel, and no or very irregular requirements documents
. How do you think to ensure the quality of software in this situation?
3. Why try not to allow employees who have time to do some testing?
4. How to reduce the losses caused by testers’ job-hopping?
5. You found a bug in the test, but the development manager thinks it is not a bug, how should you solve it?
For the above knowledge points, after a long period of sorting out, documents and explanation videos have been formed, and some screenshots are given below:
This document should be of great help to those who are preparing for the Gold, Three, Silver and Four interviews this year . I hope everyone can receive a satisfactory offer. If you find it useful, please remember to like and bookmark me. Click on the small card below can be shared .