Skip to main content
Announcements
Join us at Qlik Connect for 3 magical days of learning, networking,and inspiration! REGISTER TODAY and save!
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Qlikview interview

Hi,

I am new to Qlikview and need your help in answering below questions I am expecting in an interview, I am also going through core technical questions or FAQS available on community and other internet links

,

1. How you are handling data load in your project and what is the frequency of data load?

2. What is the size of dashboard?

4.Describe any challenge you faced while designing dashboards?

5.Which Qlikview Server license you are using in your project?

6. How to handle large data display in dashboard?

7. How you are handling dashboard access security in your project?

1 Solution

Accepted Solutions
oknotsen
Master III
Master III

1:

If you receive the data daily, you schedule a reload script daily.

I would by-pass this useless load into that SQL server database (unless it actually is also used for other systems) and directly load it into Qlik.

Size of the file does not matter in this process.

If the reload takes (too) long, consider storing the historical data into QVD files (do your own research on what that means; loads and loads of topics about that).

2:

Unless you go mental and start storing complete Hollywood movies into your dashboard, the few bytes that a dashboard uses compared to the data stored in serious applications can be ignored.

3:

A lot of people have the habit to dump as many visualizations as possible on one dashboard. That is a rooky mistake. Follow the DAR method (again, do your own research on that) and the concept of "less is more".

4:

Existing customer: Existing server license.

New customer: Well, since a few months we no longer sell the Small Business Edition so you will end up with the Enterprise Edition for that scenario.

You might even be able to do it with just a few licensed local client, but you will have to talk with a real sales for that if that is still possible.

5:

I would not call a thousand record a large amount of data. Actually, that is nothing. Maybe the software of our competition has problems with that, but below 10 million rows of data it is not a serious amount of data. I have seen applications work fine with 2 billion rows of data in there.

Showing a thousand rows of data on the other hand is useless. That means your analysts are not actually using the power of Qlik and are going to do all kinds of silly checks on that data. Probably exporting it to Excel or something. Confront them with that. Ask them what they ACTUALLY want to do with that data and simply build the dashboards to answer those questions.

6:

Sounds like the most basic user access you can have. Just connect the Active Directory, or whatever security system they have, to the server and assign these hand full of people a few CALs (again, do some research what they are; there are loads of topics about that).

May you live in interesting times!

View solution in original post

6 Replies
oknotsen
Master III
Master III

1: Depends on the demands of the project. Depends on the demands of the project.

2: The word "dashboard" has 9 letters. To put it in different words: What is your definition of "size"?

3: What happened to question 3?

4: Depends on the demands of the project.

5: Depends on the demands of the project.

6: Depends on the demands of the project.

7: Depends on the environment of your customer.

May you live in interesting times!
Anil_Babu_Samineni

What is your Experience on QlikView?

If possible, Can you please provide the client name???

Edit by community team member:

Please stop posting in all-bold for no reason.

Best Anil, When applicable please mark the correct/appropriate replies as "solution" (you can mark up to 3 "solutions". Please LIKE threads if the provided solution is helpful
oknotsen
Master III
Master III

I suggest the OP keeps the name of the client private. There is absolutely no reason for you to need that other then to go for the same job.

May you live in interesting times!
Not applicable
Author

Hi Onno,

Please suggest based on below information for each question

Question 1: How you are handling data load in your project and what is the frequency of data load?

We receive trades data on daily basis in flat file ,file size can vary and depends on number of trades performed for a day, user may require daily, monthly or yearly reports , we have ETL process in place to migrate data from flat files

into warehouse, we are using SQL Server 2008 as a data source

Question 2: What is the size of dashboard?

Size meaning here is in terms of kilobytes or megabytes , you can tell me any approximate standard size of dashboard

Question 3: Describe any challenge you faced while designing dashboards?

Please suggest me any typical scenario for challenge faced question

Question 4: Which Qlikview Server license you are using in your project?

There are three users who want to only view dashboard and two developers who require access for development purpose, in this scenario please suggest which license should be suitable?

Question 5: How to handle large data display in dashboard?

Let say scenario where we need to show last one month trades data where number of records can be more than 1000 then how Qlikview will handle such large data?

Question 6: How you are handling dashboard access security in your project?

All three users are available at same geographic location and users are internal (with in intranet), they should have rights to only view dashboard not modify and developer should have full access

Sorry there was typo error while numbering questions in my original post

oknotsen
Master III
Master III

1:

If you receive the data daily, you schedule a reload script daily.

I would by-pass this useless load into that SQL server database (unless it actually is also used for other systems) and directly load it into Qlik.

Size of the file does not matter in this process.

If the reload takes (too) long, consider storing the historical data into QVD files (do your own research on what that means; loads and loads of topics about that).

2:

Unless you go mental and start storing complete Hollywood movies into your dashboard, the few bytes that a dashboard uses compared to the data stored in serious applications can be ignored.

3:

A lot of people have the habit to dump as many visualizations as possible on one dashboard. That is a rooky mistake. Follow the DAR method (again, do your own research on that) and the concept of "less is more".

4:

Existing customer: Existing server license.

New customer: Well, since a few months we no longer sell the Small Business Edition so you will end up with the Enterprise Edition for that scenario.

You might even be able to do it with just a few licensed local client, but you will have to talk with a real sales for that if that is still possible.

5:

I would not call a thousand record a large amount of data. Actually, that is nothing. Maybe the software of our competition has problems with that, but below 10 million rows of data it is not a serious amount of data. I have seen applications work fine with 2 billion rows of data in there.

Showing a thousand rows of data on the other hand is useless. That means your analysts are not actually using the power of Qlik and are going to do all kinds of silly checks on that data. Probably exporting it to Excel or something. Confront them with that. Ask them what they ACTUALLY want to do with that data and simply build the dashboards to answer those questions.

6:

Sounds like the most basic user access you can have. Just connect the Active Directory, or whatever security system they have, to the server and assign these hand full of people a few CALs (again, do some research what they are; there are loads of topics about that).

May you live in interesting times!
Not applicable
Author

Hi Onno,

I am doing more research as suggested in your response and will come back for any doubts if required, please help suggest more questions which you think client may ask ( not much technical questions)