Top 25 HR Behavioral Questions for any role

 

***************************************

  Top 25 HR Behavioral Questions for any role

***************************************

 

1. Tell me about a team project that you worked on.

2. Describe a time when you had to bring two departments together to work more effectively with each other.

3. Have you ever been in a situation where you've found that working in a team was more successful than working alone?

4. Tell me about a time you stepped up into a leadership role... 

5. Tell me about a time that you led an important meeting... 

6. Tell me about a time that you took the lead on a difficult project....

7. How do you motivate other people to work with you?

8. Tell me about a situation where you had to solve a difficult problem.

9. Describe a time when you were faced with a stressful situation that demonstrated your coping skills.

10. Describe your style in dealing with irate customers.

11. Give an example of an occasion when you used logic to solve a problem.

12. Describe a difficult decision you've had to make in your business life and how you went about doing it.

13.Tell me about a time when you made a mistake that affected a client adversely and how you coped with it.

14. Tell me about a time you had a conflict at work. 15. Tell me about a time that you disagreed with a rule or approach.

16. Describe a situation in which you were able to use persuasion to successfully convince someone to see things your way.

17. Tell Me About A Time When You Were Asked To Take Sides Regarding Another Employee And You Remained Neutral.

18. We've All Had To Work With People Who Don't Like Us. How Do You Deal With Someone Who Doesn't Like You?

19. Tell me about a time when you had to go above and beyond the call of duty in order to get a job done.

20. Give me an example of a time when you set a goal and were able to meet or achieve it.

21. Describe a time when you went beyond your job description to save your company time and money.

22. Give an example of a situation in which you took specific steps to further your career.

23. Describe a time when you anticipated potential problems and developed preventive measures

Top 25 QA Behavioral Interview Questions & Answers

*********************************************

Top 25 QA Behavioral Interview Questions & Answers

*********************************************

1. Suppose you find a bug in production. how would you make sure that the same bug is not introduced again?

• Add uncaught functionality to regression test cases If you have Automated Regression Suite, then write a new Script which validates above functionality

2. What do you do when your developer denies that what you filed IS A BUG?
• Provide Business Documentation reference to support why the existing functionality is not as per design. 

• Involve Product Owner / Business Analyst for Discussion.
• If Bug is not reproducible then Provide Screenshots of the Bug, Give Timestamp on when you reproduced this so that Developer can check in Application Logs. 

• Provide Test Data you have used for replicating issue


3. What has been one of your greatest challenges while doing regression testing?
• Test Data issue 

• Improper selection of regression test cases might skip a major regression defect to be found


4. Difference between functional and non-functional testing?
• Functional testing verifies that features/System working as expected according to requirements,
• Nonfunctional requirements: How Well the system does it within design & resource constraints


5. Enlist some of the key challenges that are faced while performing Software Testing
• Data Issues,

 • Environment Available, 

• Using right set of tools


6. What are the different levels of testing?
• Unit Testing 

• Integration Testing 

• System Testing 

• Acceptance Testing


7.What are the drawbacks of the Agile implementation/ methodology that you faced?
• Sprints are usually very deadline constrained. 

• Documentation is not the priority 

• Frequent change in requirements


8. What is your approach when you have a high priority release to be delivered in a very short time?
• Run Automation Suites 

• . Run Unit tests. 

• Manual testing on high level Priority Business test cases


9. Give an example for High Priority Low Severity Bug
• Wrong Logo Image in Application


10. What is your understanding regarding a Test plan?
• Test plan is a document that consists of scope, approach, resources, and outline of the testing project as well as the activities for tracking the progress of the project.


11. Explain what will be your reaction if a project you had been working got Sudden change in its deadline?
• As a QA Engineer, Be open on your thoughts if you can deliver the project with QA Sign off covering all testcases 

• If Pre release is must, then discuss the opportunities of increasing QA Resources or possibility of partial product delivery 

• You have the power to hold QA Sign off if you are not satisfied with quality of product which eventually stops the release date


12.What is the difference between Smoke testing and Sanity Testing?
• Sanity testing is a kind of Software Testing performed after receiving a software build, with minor changes in code, or functionality, to ascertain that the bugs have been fixed and no further issues are introduced due to these changes.
• Smoke Testing is a special type of testing performed on Software build to check the critical functionalities of the program


13. Differentiate Ad-hoc Testing and Exploratory Testing?
• Adhoc testing Includes learning the application first and then proceeding with the testing process. 

• Exploratory testing form of testing includes learning the application while testing.


14.What are your daily activities as a member of automation tester in your office?
• Running Smoke Suite on daily Basis and sending the mail to team on health of the application 

• Verify Defects Assigned to you and take appropriate Actions 

• Working on Manual and Automation testing for the stories in Current Sprint


15.How do you select regression test cases or form the regression test suite?
• Include the test cases that verify core features of the application:
• Include the test cases for functionalities that have undergone recent changes:
• Include the test cases that have frequently yielded bugs:

16. Have you ever managed writing the test cases without having any documents?

In one of my previous project, we had to redevelop our internal tool with  new Technology, But There are no testcases/Documentation for the old/existing product. As there is no documentation, Below are the steps have followed

• Understand and exploring the existing Product to come up with Scenarios.
• Spending time with Product owner or Seniors to understand the Business of the tool.
• Going through production Bugs which found previously for product so that edge testcases are not missed in writing the tests for Upgraded product


17. What is the first action you perform as a tester when application throws any weird Errors?
• Open Developer tools-> Check in Console for any Java Script Errors 

• Open Network Tab -> And see if any request Responses are failed • Verify Application logs to understand the actual issue


18. How do you solve if there is any conflict with your peer QA on any technical aspect?
• There should be argument only up to certain extent with your Peer on why you are correct 

• If it is still conflict, 

• Involve team and discuss the conflict issue with larger Audience. Open to take suggestions from your Team. 

• Accept any decision made from Team meeting with Smile.


19. How do you solve if there is any conflict with your peer QA on any technical aspect?
• There should be argument only up to certain extent with your Peer on why you are correct 

• If it is still conflict, 

• Involve team and discuss the conflict issue with larger Audience. Open to take suggestions from your Team. 

• Accept any decision made from Team meeting with Smile.


20. How do we decide if test case Is not ideal candidate for Automation?
• Tests which are highly dependent on Data with frequent changes every time 

• Tests which cannot be automated due to technical challenges 

• Tests which are unstable due to complex nature of Application.


21. Difference between retesting and regression testing?
• Retesting is done to make sure that the tests cases which failed in last execution are passed after the defects are fixed. 

• Regression testing is to ensure that changes have not affected unchanged part. 

• Regression testing is not carried out for specific defect fixes


22. What's the most interesting bug that you've found recently?

Mention the unique bug which you could detect which shows the huge impact on the System.

23. In Agile Environments, in case you have any doubts regarding your project, how do you approach?
• As a tester, For Domain related queries, You should reach out to Business Analyst, Product Owner

24. How Will You Tell If Enough Test Cases Have Been Created To Test A Product?
• Each Business requirement is mapped to at least one test Scenario 

• Each Test Scenario should have positive and negative test cases 

• Using traceability Metrix to check whether these testcases are covering all the requirement specification

What is SOLID Principle in computer programming?

*************************************

What is SOLID Principle?

*************************************

The SOLID Principles:

SOLID is a popular set of design principles that are used in object-oriented software development. SOLID is an acronym that stands for five key design principles: single responsibility principle, open-closed principle, Liskov substitution principle, interface segregation principle, and dependency inversion principle. All five are commonly used by software engineers and provide some important benefits for developers.


S — Single Responsibility
O — Open-Closed
L — Liskov Substitution
I — Interface Segregation
D — Dependency Inversion


S — Single Responsibility
A class should have a single responsibility

If a Class has many responsibilities, it increases the possibility of bugs because making changes to one of its responsibilities, could affect the other ones without you knowing.

Goal

This principle aims to separate behaviors so that if bugs arise as a result of your change, it won’t affect other unrelated behaviors.


O — Open-Closed

Classes should be open for extension, but closed for modification
Changing the current behavior of a Class will affect all the systems using that Class.

If you want the Class to perform more functions, the ideal approach is to add to the functions that already exist NOT change them.

Goal
This principle aims to extend a Class’s behavior without changing the existing behavior of that Class. This is to avoid causing bugs wherever the Class is being used.


L — Liskov Substitution
What is wanted here is something like the following substitution property:

if for each object O1 of type S there is an object O2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when O1 is substituted for O2 then S is a subtype of T.

While this can be a difficult principle to internalize, in a lot of ways it’s simply an extension of open-closed principle, as it’s a way of ensuring that derived classes extend the base class without changing behavior.

Following this principle helps to avoid unexpected consequences of changes and avoids having to open a closed class in order to make changes. It leads to easy extensions of software, and, while it might slow down the development process, following this principle during development can avoid lots of issues during updates and extensions.

Goal
This principle aims to enforce consistency so that the parent Class or its child Class can be used in the same way without any errors.


I — Interface Segregation
Clients should not be forced to depend on methods that they do not use.

When a Class is required to perform actions that are not useful, it is wasteful and may produce unexpected bugs if the Class does not have the ability to perform those actions.

A Class should perform only actions that are needed to fulfil its role. Any other action should be removed completely or moved somewhere else if it might be used by another Class in the future.

Goal

This principle aims at splitting a set of actions into smaller sets so that a Class executes ONLY the set of actions it requires.


D — Dependency Inversion
- High-level modules should not depend on low-level modules. Both should depend on the abstraction.

- Abstractions should not depend on details. Details should depend on abstractions.


Firstly, let’s define the terms used here more simply

High-level Module (or Class): Class that executes an action with a tool.
Low-level Module (or Class): The tool that is needed to execute the action
Abstraction: Represents an interface that connects the two Classes.

Details: How the tool works
This principle says a Class should not be fused with the tool it uses to execute an action. Rather, it should be fused to the interface that will allow the tool to connect to the Class.

It also says that both the Class and the interface should not know how the tool works. However, the tool needs to meet the specification of the interface.

Goal
This principle aims at reducing the dependency of a high-level Class on the low-level Class by introducing an interface.

Top interview programming questions: Arrays

**************************************************

Java Programs for programming and coding interview

**************************************************

1. Write a program to swap elements in given array