Google

Java Interview Questions

1. Difference between Java and C++.
Hint: i) Java is purely object oriented ii) Java is Platform Independent

2. Difference between JDK, JRE, and JVM. Which one is required only to run Java Application

3. How Java is robust?

4. What are access modifiers in Java and what is default modifer?

5. Why there are no destructors in Java?

6. Explain various uses of static keyword.

7. What are abstract classes and how do they differ from interfaces?

8. How is multiple inheritance problem handled by Java?

9. Explain lifecycle of an Applet.

10. What are JDBC steps for connecting to database?

11. What are different types of JDBC drivers and what is thin driver?

12. How Swing is different from AWT?

13. Difference between class and object?

14. What are major characteristics of Object Orientation? Hint: Encapsulation, Inheritance, Polymorphism, Data Hiding, Abstraction.

15. Explain above characteristics with example.

Note: Study Java Swing for GUI development and JDBC for databases

Extreme Programming (XP)

Introduction
XP originated in mid 1990s by Kent Beck in collaboration with Ward Cunningham. It was first used in project Daimler Chrysler in 1996. XP practice is not new but how they interact is.

Extreme comes from taking the principles and practices to extreme lengths.

In a survey, it was found that 40% of the projects were late by 67% and 30% were over budget by an average of 127%. It is because of false assumptions about development process:

  • all requirements can be captured at start
  • requirements will not change significantly
  • complete architectural design can be specified start
  • developers will not take shortcuts in the process
  • developers must be rigidly controlled
XP improves a software project by addressing:
  • communication
  • simplicity
  • feedback
  • courageness
XP - New Terms
  • User Stories - functional requirements
  • Spikes - throwaway prototype
  • Velocity - measure of how much work is being done
  • CRC - Class, Responsibility, Collaboration cards
  • Re-factoring - evolving software architecture
  • Metaphor - picture of the system
  • Test Driven Development
XP Core Practices
  1. small and frequent releases
  2. continual planning of software release
  3. use of metaphor
  4. simple design
  5. continual testing (Test Driven Development)
  6. pair programming
  7. constant refactoring
  8. collective ownership
  9. continuous integration
  10. sustainable pace - max 40 hours/week
  11. use of coding standards
  12. collective coding

XP Roles
  • Manager - Overall Project Manager
  • Tracker - Monitor estimates and iteration progress
  • Consultant - external technical expert
  • Coach - expert in XP Process
  • Customer - writes stories, tests, and decides priorities
  • Programmer - design, write and test code
  • Tester - assist customer to write functional tests, run tests, maintain testing tools
XP Evaluation
  • Bottom-Up - design evolves through refactoring
  • designed for projects where requirements are initially unknown and/or continually changing
  • only suitable for small, co-located teams (2-10 developers)
  • testing is paramount - Test Driven Development
  • collective code ownership
  • minimal documentation e.g. no requirement specs
  • relies on the user knowing what they want
  • constant small software releases
  • emphasis on people and realistic timelines
References
  • www.extremeprogramming.org/rules/collective.html
  • ftp://ftp.sei.cmu.edu/pub/documents/.../xp-from-a-cmm-perspective.pdf



Agile Software Development

Background
In spring 2000, conference of gurus organised by Kent Beck agreed the need of Light methodologies. First meeting of Lightweight Method leaders were held in September, 2000. Later, in Feb 2001, second meeting was held at which they agreed the need for an alternative to document driven heavyweight process.

Agile processes when compared to their counterparts are often called lightweight, light, lean, internet speed while rigorous processes are called heavyweight, disciplined, bureaucratic, industrial strengths, plan-driven, document-driven.

Manifesto Statement
We are uncovering better ways of developing software and helping others to do so.
We value:

  • people and interactions over processes and tools
  • working software over comprehensive documentation
  • customer collaboration over contract negotiations
  • responding to change over following a plan
Misconceptions Addressed by Agile Manifesto
  • process is skill
  • documentation is understanding
  • formality is disciplined
  • in small teams, individuals are interchangeable
Principles of Manifesto
  • satisfy customer with frequent delivery (upto 6 weeks) of quality tested software ==> Measure of Progress
  • build projects around motivated individuals. Give them environment and support they need and trust them to do job
  • quality work is from self organising teams who communicate face-to-face regularly and monitor and adjust behaviour
  • welcome changing requirements, even in late development stages
Summary
  • short increments
  • experienced developer
  • onsite user experts
  • 2-8 people in a room
  • fully automated regression testing tools
  • agile methods are adaptive rather than predictive, people oriented rather than process oriented
A development method is agile when it is incremental, cooperative, adaptive, straight forward

Examples
XP, Scrum, DSDM

Salient Features of Windows 10

Windows 10 = Best features of Windows 7 and Windows 8 - Troublesome aspects of Windows 8


  1. Come back of Start Menu of Windows7 with switch-off/resizable tiles of Windows 8
  2. Transition from keyboard to touch
  3. Search including web results built into Start Menu
  4. Virtual Desktops i.e. multiple desktops for multi-tasking
  5. Improved Command Prompt - cut, copy, paste
  6. Cortana - personal digital assistant
  7. Hello - Face/Voice recognition for login
  8. Continuum - Seamless utilisation of devices - Start Menu changing to full screen mode when keyboard disconnected from Surface
  9. Revamped apps like Mail, Calendar, Photos etc
  10. Neat browser Edge with Curtana and note taking mode with draw on webpage capabilities
  11. Action Centre - Organised notifications from apps/settings etc
  12. Xbox Streaming with recording

Deep Linking

Deep linking occurs when one web page includes a hyperlink to a web page that is buried deep within another site, i.e. not to the other site's homepage. 

In the early stages of web development, linking was embraced as essential and recognized as an indispensable guide to mapping cyberspace. As the Web has matured, however, deep linking has become controversial.

While many companies welcome visitors who stumble upon one of their pages, regardless of whether or not it is their homepage, other companies feel that deep linking is illegitimate, a technique that unfairly bypasses a site's front door.

Popular cases include Microsoft sued by Ticketmaster.com in 1997. Ticketmaster.com suing Ticket.com. E-bay and Universal Studios have also declared deep linking to their webpages as illegal.

(Excerpted from: Computer Science Illuminated by Nell Dale and John Lewis)

Architectural Styles


  • Data Centered Architecture
    • Client software communicate through shared data store
    • Repository Approach: Data store is passive that is client software access data independent of any changes to data or actions of other client software
    • Blackboard Approach: Sends notification to client software when data of interest to client changes
    • Advantages:
      • Promotes integrability i.e. addition/deletion of clients
      • Components co-ordinate transfer of information using blackboard architecture
      • Client components execute independent processes
  • Data Flow Architecture
    • Input data is transformed through a series of computational / manipulative components into output data
    • e.g. Pipe and Filter
    • Filter need not know working of neighbouring filters
    • Batch Sequential: If data flow degenerates into a single line of transforms i.e. batch of data applied to sequential filters
  • Call and Return Architecture
    • Gives a program structure that is relatively easy to modify and scale
    • Two types are:
      • Main program/sub program architecture
      • Remote Procedure Call architecture: Distributed across multiple computers on a network
  • Object Oriented Architecture
    • Components of a system encapsulate data and the operations that must be applied to manipulate the data. Communication and co-ordination between components is accomplished via message passing
  • Layered Architecture
    • Each layer accomplishes operations that progressively becomes closer to machine instruction set
    • In tiered architecture, these functionalities are physically distributed
  • Client Server Architecture
    • Single application at service is made available to number of users (clients)
    • Client may be thick or thin depending upon the amount of processing performed by client processor
  • Peer-to-Peer Architecture
    • Applications are duplicated on partaking processors
    • Used for sharing information among users e.g. napster
    • Has two parts - one for sending request and another for receiving service requests from other peers
  • Tiered Architecture
    • Used by enterprise systems
    • 2 Tier: One for UI and another holds database. Business processing is tied to UI => changes impact each other. Solution is 3 Tier.
    • 3 Tier: Introduce one middle business processing layer
    • 4 Tier: Adds one more layer just above database layer, allowing database to change without affecting business layer. Suitable for business activities.
    • Complexity and independence increases with increase in number of layers
  • Embedded System Architecture
    • Two Types:
      • Star Architecture: Several service processors attached to single control process
      • Bus Architecture (1593 bus): All processors are attached to a common bus to communicate with each other
    • If high reliability is required then use fault-tolerant architecture to make system resistant to hardware and software failures. 
      • Achieved by duplicating processing on different processors so that a local incident does not take out the whole system. 
      • Such decisions apply to non-embedded  systems as well like bank duplicate their database in different geographical locations to avoid loss of data due to local flooding or terrorist attack
    • Concerns can be number and type of processors - processing power, in built memory, level of robustness, specialised use
      • Try to keep number of processors as low as possible as interprocessor communication
      • However, if redundancy is for fault-tolerance then decision is acceptable
      • Buy faster processors as fast software is costly

Major Design Decisions in Architectural Design


  • Which high level design and architecture to follow?
  • Which processors (type and number) to run the system on?
  • Computer language for implementation
  • Level of reuse --> lib routines, OS, DBMS etc
  • Use of Patterns


These decisions are very important, otherwise you may have to discard and re-do the system leading to elevated costs