Real questions that come up in MIS interviews, with the points that make an answer strong. Answer out loud first, then open the answer points and compare.
Use present → past → future in 60–90 seconds: what you study now and your strongest skill, then a project or internship that proves it, then why this role is your logical next step. Don't recite your whole CV.
Tie it to “bridging business and technology” and give a real example: a problem you saw at a company or a project you solved with technology. A specific, honest answer beats “because it's in demand”.
Answer with STAR: situation, task, the action you personally took, and the result. Show that you listened, returned to the data or the project goal, and reached a solution. Never badmouth the teammate.
Pick a genuine weakness that isn't core to the job and describe what you're actively doing about it, e.g. “I used to be nervous presenting, so I volunteer to present our university projects.” Avoid clichés like “I'm a perfectionist”.
Research the company first: its systems, news and projects. Link something specific about them to a skill of yours: “I saw you're implementing SAP S/4HANA, and I've completed an ERP track and want to learn on a real project.”
Show realistic ambition within the field: “I want to be a senior business analyst with the CBAP, leading full analysis projects.” They want to know you'll stay and grow.
Functional requirements say what the system does: “students can pay in the app”. Non-functional ones say how well: speed, security, availability, e.g. “pages load in under two seconds”. Give an example of each.
Name several techniques and when each fits: interviews, workshops, observation, document analysis, surveys, prototypes. Add that you document and validate, going back to confirm your understanding.
Don't refuse or agree on the spot. Log it as a change request, analyse its impact on time, cost and scope, prioritise it (e.g. MoSCoW), then present options to the sponsor to decide. This protects against scope creep.
STAR with a clear number in the result: “I analysed complaints, found 40% concerned delivery, and management agreed to fix delivery before the app.” Even a university project gains credibility from a number.
A DFD shows how data moves between external entities, processes and data stores. The context diagram (level 0) shows the system as one process; level 1 breaks out the main processes; each level adds detail while keeping flows balanced.
Waterfall when requirements are stable and clear upfront and change is costly, such as regulated government systems. Agile when requirements evolve and you want working increments and user feedback quickly. Many firms blend both.
Don't assume the cause. Understand it first: which screens or processes, when, for whom? Observe users, gather numbers (time per task), decide whether the cause is technical (database, network) or procedural, then propose fixes ranked by impact.
Entities: Student, Book, Copy, Loan. A book has many copies (1:N); Loan links student and copy with loan and return dates, resolving a many-to-many. State the primary and foreign keys and why Copy is separate from Book.
INNER returns only rows matching in both tables. LEFT returns every row from the left table plus matches from the right, with NULLs otherwise. Example: listing all customers, including those with no orders, needs a LEFT JOIN.
SELECT customer_id, SUM(amount) AS total FROM orders GROUP BY customer_id ORDER BY total DESC LIMIT 3; Narrate as you go: group, sort descending, limit. Mention that SQL Server uses TOP 3 instead of LIMIT.
First check the data itself (no missing loads). Then segment by region, product, channel and customer type, and compare with the same month last year (seasonality). Find where the drop concentrates, then look for causes: stock-outs, a competitor, a price change. End with a recommendation.
It depends on why and how many: first understand the cause. Then fill from the source, drop rows if few and harmless, or impute a sensible value (mean, median, or “unknown”). Most importantly, document the decision and mention it in the report.
Structuring tables so each fact lives in one place, preventing duplication and update anomalies. Explain 1NF (atomic values), 2NF (depends on the whole key) and 3NF (no transitive dependency) with an example, and note that reporting systems sometimes denormalise for speed.
An index is like a book's index: it speeds lookups instead of scanning the whole table. But it takes space and slows inserts and updates, since the index must be maintained. Add them to columns you search and join on often.
RPO is the maximum data loss we accept (say, one hour); RTO the maximum downtime. They set the type and frequency of backups (full, differential, transaction logs). Apply 3-2-1, and above all test restores regularly.
Check the execution plan: is it now scanning the whole table? Verify indexes and statistics, whether data volume jumped, and whether other processes hold locks. Change one thing at a time and measure.
Quotation, then sales order (Sales); delivery reduces stock and posts cost (Inventory); the invoice records revenue, tax and the receivable; then payment (Accounting). Stress that each step posts its entries automatically thanks to integration.
Configuration sets the system up through its options with no code; customisation changes it with code. Prefer configuration and changing the process first, since customisation raises cost and complicates upgrades. Customise only for a genuine competitive edge.
Understand the report's purpose, not its layout: what decision does it support? Show the standard report and see whether it meets the need, or adjust it through configuration. If development is truly needed, log it as a gap with its cost for the sponsor to decide.
Decide what moves (master data and open balances, often not full history), then extract, cleanse, map old fields to new, run several trial loads, reconcile balances with finance, and do the final load before go-live with a fallback plan.
Scrum is an Agile framework working in 1–4-week sprints. Roles: the Product Owner prioritises, the Scrum Master removes blockers and guards the process, and the Developers deliver. Events: planning, the daily scrum, review and retrospective.
The longest chain of dependent tasks; it sets the earliest finish date. Any delay on it delays the whole project, so these are the tasks you watch most closely.
First find the cause and whether it's on the critical path. Options: run tasks in parallel, add resources, or agree to reduce scope. Above all, tell stakeholders early and honestly with a clear plan; don't hide it.
Talk privately and ask before judging: too much work, unclear requirements, a personal issue? Agree smaller goals and closer check-ins, and document them. If it continues, escalate professionally.
Confidentiality: only authorised people see salaries (encryption, access control). Integrity: nobody changes a price without permission (permissions, logs). Availability: the store is up when needed (backups, DDoS protection).
Symmetric uses one key to encrypt and decrypt and is fast (e.g. AES). Asymmetric uses a public/private pair, is slower (e.g. RSA) and solves key exchange. HTTPS uses both: asymmetric to agree a key, then symmetric for the data.
Reset the password immediately, revoke active sessions, and confirm MFA is on. Review sign-in logs for unusual access, check whether others received the email, block the link, document the incident, and use it for blame-free awareness.
Every user or system gets only the access its job needs, for as short a time as possible. It limits damage if an account is stolen. E.g. warehouse staff can't see payroll; developers lack admin rights on production databases.
A switch connects devices within one LAN using MAC addresses (layer 2). A router connects different networks and forwards by IP address (layer 3), such as linking the office to the internet.
62 hosts: 32 − 26 = 6 host bits, 2⁶ = 64, minus the network and broadcast addresses. The mask is 255.255.255.192.
DHCP gave the device its address earlier; DNS resolves the name; traffic goes to the gateway and the router applies NAT; TCP handshake; TLS for encryption; HTTP request and response; the browser renders the page.
Work bottom-up through the layers: is the cable or Wi-Fi connected? Does the device have a valid IP (169.254 means DHCP failed)? Can it ping the gateway? An external address? Does nslookup work (maybe just DNS)? Is it one user or everyone?
A vulnerability is a weakness (an unpatched server), a threat is something that could exploit it (an attacker), and risk is likelihood of harm times impact. GRC measures and ranks risks so management can decide where to invest.
COBIT is ISACA's framework for governing and managing enterprise IT, aligning IT with business goals. ISO 27001 is the international standard for an information security management system, certified after an audit.
Extract users and their roles, compare with job titles, and look for segregation-of-duties conflicts (one person creating a vendor and approving its payment), leavers' accounts and shared accounts. Sample, collect evidence, and write findings with recommendations.
Lead with facts and evidence, not judgements; explain the business risk in plain terms; listen to their view; and agree a remediation plan with owners and dates. The goal is better controls, not embarrassment.