Sample Answer:

“Well, to me there’s a difference between criticism and constructive criticism. No one responds well to criticism that is mean-spirited or unjustified. If I feel I am the target of such criticism, I try to find out the underlying cause.  Constructive criticism, on the other hand, is something I greatly value. I’m always eager to accept advice from colleagues; I feel it’s one of the best ways to learn and I am grateful to receive it.  In my current job, I designed a data validation engine on .NET platform.  In the first review meeting, I heard a lot of cristicsm.  Of course I didn’t take it personally but rather tried to find out what was behind it.  By talking to them individually, I found that they don’t have much opinion about my design, but doubt about choosing the .NET platform since it was a new technology to them.  Therefore I called second meeting to give them a detailed overview of the .NET platform and explained the advantages of using .NET for this project.  After they understood my technical approaches, my design was well accepted.”

1. What is a view and how to create one?

A view is simply the representation of a SQL statement that is stored in memory so that it can easily be re-used. For example, if you frequently use a query SELECT empid FROM emp, you may create a view as
CREATE VIEW view_emp
AS
SELECT empid FROM emp;

Then every time you query this view, Oracle will go out and execute the SQL behind the view to query the database data.

2. Can Oracle view improve performance? Why or why not?

In most cases view does improve performance because of commonality of code being used. Since a view is based on one common set of SQL, when it is called it’s less likely to require parsing. This is because the basic underlying SQL that is called is always the same. A query without parsing is faster. However, since you can add additional where clauses when calling a view, you still need to use bind variables. Additional where clauses without a bind variable can still cause a hard parse.

3. Explain how you may use view to enhance security and what are view’s limitations for security practice?

It is a two-question in one but people often miss the second one. In any database, view’s limitation for security is the issue of scalability.

Answer:

Views are commonly used to hide the tables that actually contain the data you are querying. Also, views can be used to restrict the columns that a given user has access to. Using views for security on less complex databases is probably not a bad thing. As databases become more complex, this solution becomes harder to scale and other solutions will be needed.

4. In what situation Oracle views can affect performance, and what is Oracle’s solution to this issue?

When you create complex views with many table joins to represent large subsets of query and allow many developers and end users to access these views, you may experience poor performance. In this case, you may consider Oracle’s materialized view.

5. What is materialized view and where is it used?

A materialized view is a snapshot of data that can be refreshed based on a schedule. It is a replica of a target master from a single point in time. Oracle uses materialized views to replicate data to non-master sites in a replication environment and to cache expensive queries in a data warehouse environment.

6. Can view be indexed in Oracle?

Don’t think Oracle can do everything and quickly answer ‘yes’. SQL Server offers view index, but Oracle does not do it.

Answer:

Regular Oracle view cannot be indexed, but you can utilize table level indexed to tune underlying query that generates the view.

7. Can you insert and update records in a view?

This question asks if you can execute insert or update statement directly on a view instead of on a table.

Answer:

You can only perform data manipulation language (DML) operations with simple views. Complex views don’t support DML. view is mainly used for presenting and data and simplifying query. Data insert and update should be done on table level.

8. What’s the different between GRANT CREATE VIEW and CREATE ANY VIEW?

It is not a question about view. This question checks your knowledge of controlling user privileges in Oracle database. Grant Create view gives user’s right to create new views in grantee’s schema only. GRANT CREATE ANY VIEW allow users to create views in any schema.

“I am in a situation where I have studied communication, got a distinction for my final year … its been 3 yrs and I have landed in so many unrelated jobs that I beginning to think that I will never work in communications … how can I get there and not be paid a beginners salary??”

This was my answer:

If you don’t want to get a beginner’s salary, don’t act like a beginner. Let’s cover the unrelated work experiences… Now the reason you’ve been working in unrelated fields is to get some LIFE experience right? (if it isn’t, it is now). You wanted to see how other industries worked and discover if communications was the RIGHT thing for YOU and… here’s the key… whether it was RIGHT FOR YOUR EMPLOYER TOO!!!.

You don’t want to be some “wet behind the ears” university or college graduate begging for a job in communications… You realize that communications is an ASSET to business and you feel NOW that you are ready to be an asset to not only your employer but your employer’s customers too. Do you see where I’m coming from?

Now, the money thing can be handled in two ways…

Negotiate in the interview for a pay increase when you reach certain targets or time period. For example, you could ask for a wage review in 6 months to revise your pay because you don’t want to work for $X – you’d ideally want $Y… This means you’d work at a lower rate to reduce some of the risk for the employer in exchange for them taking a chance on employing you. If at the end of X months they don’t give you the raise find out why and if the reason’s not good enough, you can quit because you have experience now… Or,
Establish the money UP FRONT in your application. “I am looking for a starting salary of $X… a fun work environment with lots of trees and ample parking and some crazy people to creatively grow your business. If you can offer this I would love to talk.” For anyone who has read my book they will know exactly where I am coming from with this and how to use it… you may be thinking: “I’m not saying anything like that, I’ll never get a job!” But there IS a way to say it and still not blow your chances of getting a job.

But I digress… There is only upside here… Let me explain:

Someone can meet your requirements and you get an interview or job… SUCCESS!
You are not desperate… you have supported yourself for 3 years outside of the communications industry.
Every rejection you get will be coming from businesses that you probably don’t want to work in… assuming that you want lots of trees, crazy people and ample parking, etc.

Face it… there are so many bored employees working in jobs they hate, do you really want to be one of those or do you want a creative, fun work environment? I know what I would choose.

by Acland Brierty

SHAMELESS PLUG: Job Secrets Revealed will teach you how to read between the lines of any ‘situations vacant’ ad to work out how to best pitch your application, regardless of whether you meet their up-front skills or experience requirements.

Are there difficult people?  If you think they are difficult, you imply that you may not be able to get along with them well.  So, the answer this question, first deny there are any difficult people to you.

Sample Answer:

“To me people are different but not difficult.  I honestly don’t think there’s any type of people that I don’t get along with. Of course, some people are more pleasant to be around than others, but I’ve worked with all kinds of personalities and never had any problems with anyone. I understand this consulting position requires interaction with a lot of client, I am very good at this.”

But before interview you’d better do the salary research.  Check the web and ask around.  There are many online resources for IT job salary info.

Sample Answers:

“I’d rather not commit to a specific salary until the interview process is over and you make a formal offer. What is most important to me is the opportunity to work for your company. I am confident that your offer will be competitive.”

“I would expect a salary which reflects my skills and experience.  What’s the salary range for this position?”

“I’m sure you will be fair. My focus is on finding the right opportunity, and I’ll be open to discussing salary when the offer is made.”

“I am ready to consider your very best offer. What did you have in mind?”

“I’ve got extensive experience on Oracle and believe my DBA skills are a perfect match for this position. I would expect my salary to be at the upper end of your range.”

1. building Infrequently

The solution to painful dentist visits isn’t going less often, it’s going more often! The same is true of painful software integration events. Building frequently – preferably continuously – allows you to discover problems early on and nip them in the bud before they grow into big expensive disasters. Plus, building software is a critical validation step – you don’t know if something’s broken until you try putting it together. Build frequently gives you greater confidence that you know what the state of your software development project really is.

2. Not Validating Changes Against Target Environments

Customers usually aren’t too understanding when you tell them “Well, it worked on my machine.” The (often unconscious) assumption that the developer’s environment is an acceptable proxy for the “real world” is the hidden cause of many problems. It’s unrealistic to expect that developers will have the right setup on their desktops to fully validate their changes, especially when you need to build and test on multiple platforms or have test environments that require external resources. Changes should be regularly validated against all the appropriate target environments, preferably by an automated process.

3. Broken Builds

How many times have you (or one of your developers) been stuck waiting for someone to fix the build before you could continue work? For all the time developers save with visual editors and other coding productivity tools, ten times as much is wasted due to broken builds. Code needs to be successfully built before being integrated into the main code line where it can affect others. Ideally, work-in-progress should still be regularly checked into version control, but it should be kept isolated until it builds successfully.

4. Not Testing the Build

Many organizations fail to take advantage of the build process as an opportunity to test earlier and more consistently. Automated software inspection and build validation tests can help you detect regressions and other problems early, when they are easier to find and fix (not least of all because the changes in question will be recent enough for developers to remember what they were thinking when they wrote that piece of code).

5. Infrequent Check-ins

Making large, infrequent check-ins is not only a recipe for losing lots of work when you accidentally corrupt your hard drive or your laptop’s battery explodes, it also limits the value of other best practices like frequently executing and testing the build. Continuous integration is really only as continuous as the version control activity driving it – if you only commit your changes once a day, there’s no point in doing anything faster than daily builds (if you check-in your changes less than once a day, seek professional help immediately). Checking in smaller revisions more often also makes it easier to keep track of your work and track down the cause of any problems that are discovered.

6. Not Publishing Builds

Collaboration is the key to successful software projects and working code is the best artifact around which to collaborate. Giving other developers and QA engineers easy access to the latest builds helps keep everyone in sync. Make sure your build system can automatically publish successful builds so you don’t have to deal with managing distributions manually. And be sure to also archive your build configurations, so you can reliably reproduce customer issues on older versions of your software.

7. Interpreting Code Coverage in Isolation

The most frequently cited code coverage related blunder is probably “wasting time trying to get all the way to 100% coverage”, or “believing that very high coverage means your code works”. A commonly overlooked issue, however, is the importance of relative code coverage. If you can’t compare coverage between different projects, then you don’t know where scarce testing resources will be best spent. If you don’t know (or can’t remember) what your code coverage was last week, last month, or on the previous version of the software, it’s hard to evaluate today’s number. Code coverage is far more useful when you can view it in context.

8. Lack of Transparency

While it’s very common to see businesses adopt open source software today, it’s fairly rare to see those businesses adopt any of the practices that help make open source software successful. One key characteristic of open source development projects is transparency – everyone can see what everyone else is doing, fixing, or breaking – and this encourages bother peer accountability and recognition of individual contributions. This is especially important with distributed development teams where the right hand often doesn’t know what the left hand is doing (because it’s asleep when the other one’s working). commercial software development organizations would be well served by adopting practice to improve transparency among developers and, just as importantly, to give QA and management better and earlier visibility into development.

9. Relying Only on Unit Tests

Automating unit tests in your builds is a good start, but if you limit yourself to only doing unit testing, you’re missing an opportunity to catch a much wider range of potential problems. From simple static analysis tools like findbugs or checkstyle, to enterprise products for security analysis, license compliance audits, or functional testing, the build event provides and excellent opportunity for early detection of a variety of issues. Combined with a defect isolation mechanism, this can also become a valuable tool for enforcing software development policies or best practices.

10. Ignoring History

If you regularly build and test your software, but don’t persist the results in a database, you’re missing out on the opportunity to gain valuable insights into your development process and software projects. There’s a wealth of information in the form of build reports, test output, and other artifacts just waiting to be mined if only they were stored in a convenient way. Even relatively simple queries could uncover previously unknown relationships or dependencies – finding out that half of your build failures occurred after someone touched an obscure configuration file would give you a pretty simple way to optimize your build process!

Then, how to overcome these blunders? Borland offers whole bunch of tools to help. No kidding, from Lifecycle Quality Management to Performance Testing, Borland’s development tools are still the best.

The second best way to miss out on the job is to ask how much you will be paid in the first interview. Either wait for the final interview or until you have received a job offer. Besides, your research of the industry should already give you an indication of how much to expect.

How to ask for more…

Once you’ve been offered the job it’s now time to talk money. Depending on the job you’ve applied for and the organization there may be no room for negotiating. You simply have to take what’s being offered. The 2 choices open to you are to put up with it or find a company that is willing to pay more for your skills.

The next section only applies if you think you are worth more, or want to earn more, than what you are currently being paid.

If you were an employer and you have $40,000 allocated as a wage for a new employee, would you offer the potential employee all of your $40,000? Or would you offer them $30,000 to see if they take it, in which case you’ve just saved yourself $10,000?

Now you’re ready to proceed…

If asked how much you were earning in your last position, answer truthfully, then explain part of your reason for leaving was because you wanted a chance to earn more. That you felt your skills and contributions to the company weren’t being rewarded hence the reason for you applying to this job.

It’s important to demonstrate why you think you are worth more. Bring up case histories of saving the company X% or increasing sales or service while you were there.

“We were thinking of a salary package of $30,000. How does that sound…?” You’ll hear this when you ask them what the salary for the job is or they may simply say it up front. The 3 ways to handle this are:

1. Say NOTHING. This tactic added $50 a week to my paycheck once. OK, that’s not a lot but it’s an extra $2,500 a year and I didn’t have to ask for it. A good 2 minutes work. The reason this tactic works is because people generally don’t like silences. When you say nothing the employer can tell that their offer is less than you were expecting. By saying nothing forces the employer to offer something closer to what you had in mind.

2. Explain that you were earning more in your last position and would expect at least that. If that doesn’t apply to you, tell them the salary you want plus a few thousand dollars more. The reason for this is — if you ask for too little you can’t negotiate up, you can only get what you’ve asked for or negotiate down. You’ve got no room to move in. But, if you ask for more than you want you have room to move down. Chances are that you may get what you asked for which is more than you originally wanted.

3. Accept the offer on the condition that you meet again in 3 or 6 months for a wage review. Explain that you have skills that will really benefit the company and you are willing to work for less than you would ordinarily accept on the proviso that in X months time you meet again to renegotiate your salary package. You’re taking a little of the risk away from them.

Now here’s a lateral thought for you — you can always get paid on a results basis… Depending on the sort of position you’ve applied for, if the salary is not up to your standard then ask for a share of profits, increased sales in a certain area or a share of savings made. If the company is spending $50,000 in a certain area and you can save them $15,000 (for example) you could ask for a one-off fee of half the savings ($7,500). (After all, they’re better off by $15,000 every year because of your idea.)

The same thing could apply if you can help to increase sales or productivity. You don’t have to be a salesman to do this.

I remember a story of a secretary in the USA who worked for a sausage making company. She thought it would be neat to sell sausages by mail order so she brought the idea to her boss. The boss said OK and she now heads up a multimillion dollar mail order sausage business. Oh yes, she gets paid a lot more than when she was a secretary.

Use them as an example for you being paid more…

If the money they’re offering is less than you want or need and it doesn’t look like you’re going to get what you’re asking for, try saying something like this:

“I’ve researched your firm and I know that the widgets you sell and the services you provide aren’t the cheapest on the market. Why is that?” …..(they will go ahead and tell you about their quality and service and expertise and how it’s superior to the rest, etc… )

To which you would reply: “Well, the same thing applies in my case. I’m not saying that other people can’t do my job for less. All I’m saying is that like you, I offer (insert your skills & experience etc… here) and I’m always learning and improving those skills so that I can be of maximum value to you and your customers.”

Then say nothing and see what follows.

You can always accept what they’re offering with a review in 3 months or so if this tactic fails.

If the company is the cheapest on the market then you may be in trouble with the example above so you might have to point out that if you can work more quickly and efficiently, etc… then you’ll save the company money. They may pay you more for that.

The last resort…

If all else fails and they won’t meet your salary expectations, don’t take the job. This might get them to pay what you want or else it won’t. The fact is you have to be happy with the salary you’re being offered otherwise there is little point in working there is there.

If you can show the employer why you’re worth the money and they can see that there is no way you’ll do it for less, refusing the job may be what it takes for them to meet your demands. It shows them that you are serious about what you can do and the money you think you’re worth.

If they think you are being unrealistic they’ll let you go. Maybe one of their competitors will appreciate your skills and pay you the money you want.

But remember this: You don’t get what you deserve. You get what you negotiate.

SHAMELESS PLUG: Job Secrets Revealed comes with a special ‘interview secrets’ report that will give you – more secrets of the experts including sections on “behavioral interviewing”, an expanded section on understanding the mind of the employer and the Top 10 list of the “Things Interviewers Fear,” as well as the complete list of the toughest interview questions you’ll ever get, including advice on how to side-step the ones you won’t want to answer. Plus, we give you powerful techniques to let you take control of the interview.

“I have extensive DBA experience in configuring database server for both OLTP and OLAP systems.  I worked on many transaction-oriented database, I also had the opportunity to setup database for decision support systems.  Nowadays most of the RDBMS provide options to setup OLAP for you during installation, you simply select this option and the installation process will configure your database suitable for OLAP and DDS applications.  Of course I can always change my database configuration manually when necessary.  The major difference of OLAP comparing to transaction database is that OLAP requires fast data retrieval and concurrent access.  Many DSS applications run very complicated queries.  In general, there are every few data manipulation activities such as insert, update, and delete.  Therefore in OLAP configuration I use indexes heavily to speed up data query process.  Oracle’s bitmap index and materialized views are also helpful.  I would also configure table partitions based on the analysis of data structure.  I would design tablespaces on different data files put on different hard disks and build tables across. That would increase concurrent access and reduce I/O bottleneck.  For DSS system, I may consider de-normalize the data structure and build dement ional database for reporting and BI purpose.  Depending on the specific project, I may implement other options such as configuring the database cache to meet the OLAP and DSS needs.”

Let’s face it. Rejection is an unfortunate part of the job-hunting journey everyone gets, so don’t take it personally. You don’t lose anything by follow-up but you have a lot to gain even if you get rejection in return. If the answer is no, forget it and move on. By all means, you used this opportunity to practice you communication skills, which would benefit you in the long run.

How to follow up, then?

Right after interview, send thank-you letters or cards to every interviewer to think them for interviewing you. You should ask for business cards at the interview so you get their names and titles correctly.

Call the one who is in charge after couple of days. You should have known who is the decision maker from the interview. Ask if decision has been made. If they are still considering, remind them that your skills and experience can be a big help to them. If they have pick up one who is not you, you should thank them and express your willingness to be considered for other positions and future openings. In either situation, you should speak with confidence and enthusiasm.

A few days later, write to the hiring manager to state your availability and ability for this position if you know from the follow-up call that decision is not make yet. Or write to thank them again for interviewing you, and ask for been considered for later opportunities. Write with positive attitude and leave a last impression.

That’s it. It’s easy and wouldn’t take a lot of your time. So, do it.

Computer-Aided Software Engineering (CASE) tools are used by system analysts, designers, and developers to capture information about business requirements, create a design for the data structures to fulfill those requirements, and generate front-end and server program code. CASE tools can automate much of the manual, repetitive, and error-prone work needed for system development, and can greatly increase the productivity, accuracy of the design, and robustness of the implementation.

System Development Life-Cycle

CASE Application Development Method (CADM) – 7 phases:
1. Strategy
2. Analysis
3. Design
4. Build
5. Test
6. Implementation
7. Maintenance

1. Strategy

The purpose of the Strategy phase is to formulate a basic description of the overall scope of the project and how the project will proceed. The entire focus is on the business. The goal is to gain a clear understanding of the business area’s goals, objectives, processes, direction, and needs in order to structure and document the vision of project. Results of this phase include strategy ERD, process flows, strategy document, cost-benefit analysis, and workplan.

Strategy Document is also referred as project charter, project definition document, and scope document. Strategy document outlines the scope of a project and defines an agreement about what the project is committed to deliver. It also includes the estimated budget, time frame, resources, controls, and standards within which the project must be completed.

2. Analysis

The analysis phase breaks logically into two parts: information gathering and requirement analysis.

Within the information gathering portion, techniques for getting at user requirements include interviews, questionnaires, and joint application development (JAD) sessions, along with reviews of the current system, the report audit, and user and system documentation.

In requirements analysis, we extract the system requirements form the information gathered and place them in an organized structure. This can be done at both the unit level and, ultimately, at the system level.

3. Design

The Design phase includes two broad subphases:
- Database Design
- Application Design

You should already have a complete ERD from the Analysis phase, but need to do the physical database design. The basic strategy of database design is to map entities to tables, making adjustments fo subsets, denormalization, aggregation, and summary tables.

At the simplest level, application design is the design of software, including the creation of structures that address modules, programs, procedures, navigation, internal controls, and security.

4. Build

In the Build phase, you build the database and application. The Build phase deliverables consist of the following:

- Unit tested application system
- Populated databases
- System documentation
- User documentation
- Help system and online documents

5. Test

In the Test phase, you develop a test plan that should describe not only test to be run but also how test failures or variances will be handled. Tests include unit testing, system testing, user acceptance tests, and training and documentation. Through this phase, the new system is formally tested.

6. Implementation

In this phase, the project team will rollout a system to production environment and provide adequate user support. The rollout/migration process involves transition period where the system is closely monitored and support is transferred from the project team to the system operation group.

7. Maintenance

Maintenance is a process that continues throughout the life of the system. A predefined process must be put into place to handle ongoing problems, modifications, and enhancements.