Tell me about Yourself






"Tell Me About Yourself" is one of the most common FIRST question in any kind of an interview, be it technical or HR round! The answer to this question plays a very major role in your selection,But since we are not used to introducing ourselves , this question makes most of us nervous and so we need to practice to answer Tell me about yourself properly as this question can help you to make the interviewer ask the questions you want him to ask you as well as to project your strengths.



If you are a fresher your answer to Tell me about yourself should start in the following way: 
  1. Tell your full name, your father's name , how many siblings you have and where is your home town.
  2. Tell about your 10th Boards Examination with percentage ans Board of Examination.
  3. Do the same about your 12th Boards.
  4. Tell about your College and the Percentage / CGPA you got.
  5. Tell about Extra Curricular Activities and Achievements.
  6. Any Extra courses/trainings and certifications that you acquired.
  7. About your Hobbies and interests.

Questions similar to "Tell me about yourself"

There are many variations to the question "Tell me about yourself", an interviewer can ask the same thing in different ways or infact split the question in to parts. Following are the variations: 
  1. Tell me something about yourself
  2. Can you tell me about your background
  3. So, where have you studied?
  4. Tell me something about your past life





C language: Question and answer







Que. >> A character variable can store  x characters at a time:

options:
A 1
B 4
C 8
D no limit

Correct answer is : A
Explanation
A character variable is of 1 byte length and can store just 1 character at a time.






C language: question and answer







Que. What is the output of:

#include<stdio.h>
int main()
{
    int x=40;
    {
        int x=20;
        printf("%d",x);
    }
    printf("%d",x);
    return 0;
}

Options:
a 40 40
b 20 40
c 40 20
d error



Answer:

b 20 40

Explainaition:

The variable declared inside the  inner block replaces the x declared in the outer block, hence it prints 20 at 1st printf.
When the inner block ends, the scope of inner x also ends and hence the value of x becomes 40 in the outer block.











A jobless man applied for the position of 'office boy' at Microsoft.





A jobless man applied for the position of 'office boy' at Microsoft.


The HR manager interviewed him, then gave him a test: clean the floor. The man passed the test with flying colors.
"You are hired," HR manager informed the applicant, "give me your e-mail address, and I'll send you the application for employment, as well as the date you should report for work.
The man replied " I don't have a computer, or an email!"
"I'm sorry," said the HR manager. "If you don't have an email, that means you do not exist. And we cannot hire persons who do not exist."
The man was very disappointed.
He didn't know what to do. He only had $10 with him. Once that is spent, he won't have any money to buy any food.
He went to the supermarket and bought a crate of tomatoes with his $10.
He went from door to door and sold the tomatoes in less than two hours. He doubled his money.
He repeated the operation three times, and returned home with $60. He realized that he can survive
this way. He started to go everyday earlier, and return late.
He doubled or tripled his money every day. Soon, he bought a cart, then a truck. In a very short time, he had his own fleet of delivery vehicles.
Five years later, the man became one of the biggest food retailers in the U. S. He started to plan his family's future, and decided to have a life insurance.
He called an insurance broker, and chose a protection plan.
At the end of the conversation, the broker asked him for his email address.
The man replied: ' I don't have an email.'
The broker was dumbfounded. "You don't have an email, and yet have succeeded in building an empire. Can you imagine what you could have been if you had an email?," he exclaimed.
The man thought for a while, and replied, "an office boy at Microsoft!"
If you just lost your Job or Just failed an Interview Don't worry be Optimistic..... Good days are on the way and something better is reserved for you.
--By: Malik Jahangir



Happy Diwali to all Technology Lovers

On Diwali, 

wishes for every joy and prosperity. 
Here's hoping, that the beauty of this festival of lights, bring a world of joy, happiness and contentment to you, to last the whole year through. 

Happy Diwali. 


--My Technology Park



Top 10 Things Every Software Engineer Should Know





Note: - To be honest – I try to “walk the talk”, but I’m not perfect. This is the reason why the title of the article includes the word ‘should’. 
(Article written by Experienced Professional)

               1)  Fundamentals of Emotional Intelligence

My favorite breakdown of emotional intelligence is:
  • Intrapersonal intelligence describes the ability to have positive relationships and/or good communication between people. This means that you understand what people fell and need. The key competences of intrapersonal intelligence are:
    • Sense of Self:
      – recognize the own feelings, emotions and reactions
      – mindfulness to get a better awareness
    • Self-regulation
      – controlling the current inner state
      – bring own automatic reactions to mind and interrupt
    • Personal leadership
      – know and lead the parts of your own personalty
      – care about own strengths and weaknesses
  • Interpersonal intelligence describes the introspective and self-reflective capacities. Know your self, your emotions and what your weaknesses or strengths are, being able to control your own reactions. The key competences of interpersonal intelligence are:
    • Empathy
      – recognize the feelings and emotions of others
      – express sympathy in anappropriate way
    • Reduction of Automatic Reciprocal Effects
      – bring automatic reactionswith othersto mind and interrupt (if needed)
    • Creating Relationships
      – create mid- and long-term relations with others
          2) Understand the Business of your Customer
How can you design and implement good software without deep understanding of the purpose or use? The answer is easy: “If you don’t know the WHAT, you can’t decide about the HOW.” A deep understanding of your customer’s and/or users’sbusinesswill lead tobetter requirements, designs, implementations and tests.Most of the software’s functionality creates no business value. The challenge is to select the functionality which creates business value. The better you know the business the higher is the probability to implement the best system.

3) Minimum One Programming Language for each Mainstream Development Paradigm
The discussion what is the best programming language has a religious character, it’s more a question of belief. I don’t like to preach my personal belief about the best languages here, but one thing is important: “Learn more programming languages, at least one for each mainstream development paradigms.”
  • Procedural programming languages (C, COBOL, PL/I, FORTAN, etc.)
  • Object-oriented programming languages (Smalltalk, Java, C++, etc.)
  • Functional programming languages (Erlang, Clojure, F#, etc.)
  • Declarative programming languages (SQL, XSLT, regular expressions, etc.)
Its a good idea to know at least one multi-paradigm programming languages like Python, Java, C++ or C#. You find many lists of programming languages by type or other categoriesin the web
Dependent of your industry, personal preferences and daily tasks you should select your individual top 1o list of programming languages. Learn them and try to use at least 3 of them on a regular base. The old saying “If your only tool is a hammer, all your problems will look like nails” is particularly true for development paradigms.

4) Know your Tools
There is a huge number of tools specializing indifferent disciplines like: requirements management, software & database design, software configuration management, build & deploy, continuous integration, development, debugging, profiling, code analysis or testing.
It should be mentioned that specialist from infrastructure/operations have also toolboxes with interesting capabilities, e.g. network monitoring, network analysis, operation system analytics, penetration testing, log file analysis, database performance tuning.
A software engineer can’t know all tools in detail, but he/she should know the key concepts and underlying technologies. Knowing the right tool and how to use can increase the productivity and quality.Spend some time to learn about tools.

5) Standard Data Structures, Algorithms and Big-O-Notation
When I stated to develop software it was absolutely necessary to know a lot about data structures and algorithms. The reason for that was the missing availability of standard implementations. Today most languages have comprehensive libraries for container, sorting and other operations.
Still it makes sense to know more. There are two main reasons:
  • correct use of the standard libraries and
  • sometimes you need individual solutions.
You should be able to analyse your own or others code. TheBig-O-Notation is the standard method to describe the expected consumption of time or memory depending from the number of data.
If a manual analysis is too difficult, just make a micro benchmark and measure with test data of different size. Draw it in a plot and find a good fit of a possible model function. This is always better than nothing.

6) Don’t Trust Code without Adequate Test
Ten years ago, I trusted my code. Why not? After 8 years C++ with excellent skills and a lot of experiences. I just coded, tested and everything was working well. But over the years I made and saw a lot of errors. Because of these errors, I lost the trust in my own and others code.
Today, I don’t trust code until it passed:
  • unit test,
  • integration & system tests,
  • checks of performance and memory with real world data,
  • static code analysis,
  • measure code coverage of test,
  • load & stress tests and
  • peer review.
This sounds over engineered, but you have to spend the time either during development or during maintenance. I favor to do the work once with good quality and not to spend my time with troubleshooting.

7) Basics of Project Management, Lean Management and Agile Concepts
Even you don’t like to work as a project manager; you work in teams and at least have to organize your own work. To get along with technical leads you should understand their wording and way of thinking. Today everybody can work as project manager, scrum master or technical lead. Spend time to learn about management, because sometimes you should manage these guys.
A good example is effort estimation. My personal experiences say, that if you ask a software engineer about the effort of a task you get in 80% of the cases a dramatic underestimation of the effort. A software engineer tends to estimate just the good case without unexpected problems. This causes delays and/or poor quality because quite often the unexpected problems just happen.An other problem is the Definition of Done. The project manger means everything is done and often the developer estimates just the technical stuff.
Last week I had such a case. The developer estimated just one week of work. And after a complete planning, we saw several months’ effort. The developer estimated the time for implementation and forgot to estimate documentation, security concept, data protection issues, alignment with workers councils, reviews, project management efforts, deployment, etc.

8) Key Metrics of Software Development
Know what happens in your software, process, team and your own work. It is very difficult to control something what you can’t count. I encourage you to have question and try to find a real world measure as answer. Then you can have target values, do your work and find out if it worked out. Important is the word “real world measure”.
In software engineering we find a lot of obscure measures and/or derived metrics. E.g. the so calledmaintainability index (MI)
MI = 171 – 5.2 x ln(avgHV) – 0.23 x avgCC(g‘) – 16.2 x ln (avgLOC) + 50 x sin (sqrt(2.4 x perCM))
where HV is the Halstead Volume, CC is the Cyclomatic Complexity, LOC is the lines of code and perCM is the percentage of comment lines. This is not what I call a real world measure and I don’t understand this.
My advice is easy: “Never use a measure and/or metric you don’t understand 100%. Sometimes it is enough to take some glasnuggets and count them

9) The Root Cause of the Last Defect
Maybe your last error was not as severe, but to learn more about the root cause and negative effects   you should analyse it.
  • What was the root cause?
  • In what development phase came the error in the software?
  • How could it be detected earlier?
  • Would a tool help to avoid it?
  • Would a rule help to avoid it?
  • Was it a qualification problem?
  • Is the working environment (lot of interruptions, etc.) the root cause?
  • Is it an documentation problem? Or maybe a communication problem?
  • What are the costs to fix it?
  • Are in the affected component more errors?
  • Are the test cases good/complete enough?
You see a lot of question and the list is still not complete. The most important point is, to find the root cause to get better over the time. This works for your own qualification and way of working. And it works for your team. You just have to ask some question.

10) Understand the Infrastructure
I spend the first 10 years in IT without thinking more than a minute about infrastructure. It was not necessary, because I didn’t work in an enterprise environment. At the moment I work for a bank (sorry for these Lehman Brothers stocks, nobody asked me). In a bank you have a lot of these infrastructure people. They are really different form software engineers. But, I don’t like to discuss here the differences and possibilities to get along with them.
Important is their language. Infrastructure peoples talk in “Information Technology Infrastructure Library (ITIL)”. Spend at least some days to learn this ITIL terminology.
 The second important thing is, that in infrastructure the people are much more specialized than developers. Sometimes a developer has just one question and needs five infrastructure guys for the answer. The ITIL stuff is maybe the glue between the people in infrastructure

(English is not Author's native language, So please ignore grammaticle mistakes, if any)