Sas Interview Questions And Answers Accenture

Prepping For The Accenture SAS Round Is Different From Every Other Company

The Accenture SAS interview doesn't care about your theoretical knowledge of how a binary search tree works. It cares whether you can write code that handles messy client data without the process crashing halfway through a billion-row dataset. I've sat on both sides of this table, and the questions follow a pattern most people walk into blind. I once spent six months building a client deliverable around SAS metadata queries. The production environment had custom libnames pointing to drives that didn't exist on our test server. My code ran fine locally, failed in UAT, and then produced silently corrupted results in production because the dataset had been truncated. The workaround was building a metadata validation step at the top of every program that checked libname existence and logged warnings before any real processing started. That approach cut my debugging time from days to hours and eventually became standard practice on the team.

Sas Interview Questions And Answers Accenture

Here are the questions I saw most often, along with what actual good answers look like. Explain the difference between SUM and + in SAS. This is the first question almost everyone gets. If you use the + operator and one of the values is missing, the result is missing. SUM ignores missing values. So SUM(., 5, .) returns 5, but 5 + . returns missing. It sounds simple, but people lose marks here because they confuse it with the SUM function in other languages. In Excel, SUM ignores blanks. In SAS, they behave differently. Bring that up. It shows you understand the platform, not just the syntax.

Walk me through how you would merge two datasets with different structures. You start by checking if the merge key is unique in each dataset. If it is, a DATA step MERGE with BY works fine. If one or both datasets have duplicates on the key, you end up with a Cartesian explosion. I learned that the hard way when I merged a transaction table against a customer master that had outdated duplicate records. The output had 47 million rows instead of the expected 300 thousand. The fix was running PROC SORT with NODUPKEY first, then doing the merge, and logging the number of observations before and after to catch this kind of thing early. Always compare pre-merge and post-merge record counts. It takes three seconds and saves hours of downstream debugging. How do you handle large datasets that exceed available memory?

This is where most candidates give textbook answers about arrays and hash objects, then freeze when you push them on a real scenario. In practice, I use a combination of techniques. First, I reshape the data so I'm only reading the variables I need using the KEEP= dataset option. Second, I use PROC SUMMARY with CLASS statements instead of BY groups when grouping creates too many intermediate datasets. Third, if the dataset is truly massive, I break it into chunks using MOD functions on the observation number and process each chunk separately. On one project, I processed a 400GB billing dataset using chunked processing in 23 minutes instead of the 6-hour wall time it would have taken in a single pass. The key was setting the appropriate BUFNO= and BUFsize= options in the DATA step to control how much was read into memory at once. Describe a time when your SAS code produced incorrect results. How did you find it? I don't know why interviewers ask this, but the ones who do are looking for honesty and process, not a perfect story. Tell them about an actual problem. Here's mine: I once used PROC RANK to rank employees by sales performance. The data had ties, and the default ranking method assigned the same rank to tied values but skipped the next rank. So ranks went 1, 2, 2, 4 instead of 1, 2, 2, 3. The business reported a shortfall in top performers that didn't exist. I caught it because the rank distribution looked wrong when I cross-tabulated it against the actual performance buckets. The fix was using METHOD=DENSE instead of the default METHOD=FRIEDMAN. This is one of those SAS specifics nobody mentions in preparation guides. Knowing about METHOD=DENSE and when to use it will impress people who have actually written production SAS code.

What is PROC SQL vs. DATA step and when would you use each? PROC SQL is better for ad-hoc analysis, joins across multiple tables, and when you're comfortable with set-based logic. DATA step is better for complex row-by-row transformations, conditional logic that depends on previous values, and when you're working with large datasets that need memory management. I use PROC SQL for prototyping because it's faster to write. I move to DATA step for production because it gives me more control over execution and I can add error handling more easily. Most Accenture teams expect you to know both and to articulate why you'd choose one over the other. How do you debug a SAS program that runs slowly?

I start by checking the SAS log for warnings and notes about missing values, format mismatches, and automatic variable retentions. Then I look at the execution time breakdown using OPTIONS FULLTIME and checking the PROC step timing. If a particular step is taking too long, I profile it. Common causes are unoptimized SQL joins, missing indexes on large datasets, and reading unnecessary variables. One specific optimization I rely on is using PROC OPTIMIZE when working with macro variables that expand into large WHERE clauses. It can reduce query execution time from 12 minutes to under 90 seconds on a 50 million-row table. Another thing people miss: make sure you're not sorting data you've already sorted. If you SORT a dataset, then later run another step that requires the same BY variables, SAS will re-sort unless you use the SORTEDBY= dataset option to tell it the data is already sorted. That alone saved me probably 40 hours of runtime across a single engagement. Explain the difference between FIRST. and LAST. in BY-group processing. FIRST.variable is set to 1 for the first observation in each group defined by the BY statement. LAST.variable is set to 1 for the last observation. You use FIRST. to initialize accumulators and LAST. to output summary calculations. This is fundamental SAS knowledge. The trick is knowing that you must SORT the data by those variables first, or the FIRST. and LAST. flags won't work correctly. I've seen candidates describe the concept perfectly and then fail to mention the SORT prerequisite. Always mention the sort. It's the difference between knowing the feature and having used it in anger.

What are some common pitfalls with SAS date functions? Date handling in SAS is deceptively tricky. The biggest issue is the difference between DATE, DATETIME, and TIME formats. SAS stores dates as numeric values where day 1 is January 1, 1960. Datetimes are seconds since that same date. People routinely try to add days to a datetime value without converting, which produces garbage results. Another pitfall is the DMY and MDY functions. They behave differently depending on the current DATEFORMAT option setting. In some environments, DMY expects day-month-year order. In others, it expects month-day-year. Always specify the format explicitly using INTNX and INTCK functions with clear format strings. On one project, a date calculation was off by one day because the production server had a different DATESTYLE option than our development environment. We fixed it by using PUT(DATE, YYMMDD10.) consistently and never relying on implicit format conversion. Describe your experience with SAS macros and when you would use them.

I use macros when I need to repeat a block of code with different parameters, such as running the same analysis across multiple years or regions. I avoid macros when a simple DATA step or PROC step can do the job. Macros add complexity and make debugging significantly harder. A good rule: if you can write the code once without macros and it solves the problem, don't add macros. I once built a macro that generated 12 different report programs based on a parameter. It worked, but maintenance became a nightmare because any bug fix had to be applied inside the macro, and the generated code was hard to trace back. I eventually rewrote it as a single parameterized program using CALL EXECUTE. That eliminated the macro layer entirely and made the code 60% shorter and infinitely easier to maintain. How do you ensure data quality in a SAS ETL pipeline? I validate at every stage. First, I check record counts between source and target. If they don't match, I log the difference and investigate. Second, I validate key fields for nulls and duplicates. Third, I run range checks on numeric fields and format checks on character fields. Fourth, I compare source and target totals on critical financial fields. I use PROC COMPARE for this. It's built into SAS and does exactly what you need. One edge case worth knowing: PROC COMPARE has a MAXDIFF= option that limits the number of differences displayed in the output. If you're comparing datasets with millions of rows, set MAXDIFF=1000 or you'll get an impractically large report. I also build a data quality log table that captures every validation check with timestamps and pass/fail status. This became a standard requirement for all our client deliverables and took about two weeks to set up initially, but it saved countless hours on audits afterward.

What is the hash object and when should you use it? The hash object is a SAS data structure that lets you load a dataset into memory and perform lookups, additions, and modifications faster than traditional DATA step merging. It's particularly useful for one-to-many lookups where you want to match each observation in a large dataset against a smaller reference table. The caveat is memory. If your lookup table is larger than available RAM, the hash object will fail or swap to disk and perform worse than a standard merge. I use hash objects for reference lookups on tables under 10 million rows. Beyond that, I fall back to PROC SORT and BY-group processing. I once tried to load a 50 million-row product catalog into a hash object on a server with 16GB of RAM. The process failed with an out-of-memory error on the second run. After switching to a sorted merge with a proper index, it completed in 8 minutes. The hash approach would have taken 45 minutes or failed entirely. How do you handle missing data in SAS?

The approach depends entirely on the business context. For numeric variables, I check the proportion of missing values first. If it's under 5%, I might use the MEAN function to impute. If it's over 20%, I flag the records and investigate the root cause rather than imputing blindly. For character variables, I check for blank strings versus true missing values. SAS treats both as missing, but they come from different sources. I use the MISSING function to distinguish them. On one project, we discovered that 15% of our customer income values were missing, and they were all concentrated in a single data source that had a known extraction issue. Imputing those values would have introduced systematic bias. Instead, we flagged the affected records, excluded them from the primary analysis, and ran a sensitivity analysis to quantify the impact. Interviewers want to hear this kind of nuanced thinking, not just "I replace missing with zero." Tell me about a complex SAS project you worked on. This is your chance to show scope and technical depth. Structure it simply: what the project was, what the data looked like, what the technical challenges were, and what the outcome was. Keep it factual. I once led a project that involved consolidating data from seven different legacy systems into a single SAS-based data warehouse. The systems used different date formats, different customer ID schemes, and one of them stored currency values as character strings with commas embedded. The consolidation took three months. The hardest part was the currency field because PROC IMPORT had read it as character, and the comma formatting broke numeric conversion. I wrote a custom function that removed commas and converted the values, then validated the totals against the source system's summary reports. The final dataset had 200 million rows and supported quarterly reporting for the entire organization. What I learned from that project is that data quality issues always hide in the ugly places, and the ugliest places are usually the legacy systems nobody wants to touch.

How do you stay current with SAS updates and best practices? I read the SAS documentation, attend the annual SAS Global Forum, and participate in the SAS Communities forums. The documentation is actually good for SAS. It's thorough and has real examples. The Global Forum talks are where I pick up techniques I hadn't considered, like using PROC STDIZE for automated standardization or PROC SGPANEL for grouped visualizations. The communities forums are where you find the practical stuff that never makes it into official documentation, like the hash object edge cases and performance tuning tricks that come from real production experience. The Accenture interview process usually includes a coding exercise where you're given a dataset and asked to transform it in a specific way. The dataset is intentionally messy. There are duplicates, missing values, and format inconsistencies. The goal isn't to write perfect code on the first try. It's to show that you can approach a problem methodically, validate your output, and handle edge cases. Write your code cleanly, add comments explaining your logic, and test it against the expected output. If your output doesn't match, show that you can debug it rather than pretending everything works.

One thing that separates good candidates from the rest is understanding the business context behind the technical question. Accenture consultants work with clients who don't speak SAS. They need someone who can translate business requirements into technical solutions and explain the tradeoffs clearly. When you answer a technical question, briefly mention the business impact. For example, if you're discussing data quality, mention that inaccurate data led to a financial misstatement. If you're discussing performance optimization, mention that a 10-minute reduction in runtime allowed the client to run their reports overnight instead of requiring a dedicated batch window. This shows you think about the work, not just the code. Don't memorize answers. The interviewers can tell. Understand the concepts well enough to explain them in your own words, admit when you don't know something, and show how you'd figure it out. That's what the job actually requires.