solarsquare Data Analyst Interview: Questions, Experience & Prep (2026)

Solarsquare is a rooftop solar company helping Indian homeowners and businesses switch to clean energy. Their teams handle everything from lead generation and site surveys to installation, performance monitoring, and customer support. That means data analysts work daily with a broad mix of sales funnel data, operational metrics, and energy yield figures.

Solarsquare currently has 177 open roles, reflecting active expansion. Data Analyst positions are part of this hiring push. Candidates report the process typically involves a take-home or live technical task (SQL and Python are common), followed by one or two conversation rounds with a data lead or business stakeholder.

Salary ranges for Data Analyst roles, based on the knok jobradar:

Across the broader market, 319 Data Analyst roles were active as of July 2026. Bangalore leads with 41 openings, followed by Delhi (22) and Mumbai (19). Solarsquare roles are typically concentrated in cities where their installation operations are active.

1. Walk us through a time you worked with messy or incomplete data. How did you clean it and what did you learn?
2. How would you build a dashboard to track the health of Solarsquare's solar installation pipeline across cities?
3. A cluster of customers is reporting lower energy yield from their solar panels. How would you investigate the root cause?
4. Write a SQL query to list customers who had a solar system installed more than a year ago but have not logged any service request since. (Assume relevant tables exist.)
5. How would you measure whether a new customer onboarding process is actually working?
6. Solarsquare sells on EMI as well as outright purchase. How would you compare the long-term value of customers on each payment model?
7. One city's installation teams are consistently slower than others. How do you determine whether the data shows a real problem or just noise?
8. Tell us about a report or dashboard you built that led to a real business decision.
9. What is the difference between a cohort analysis and a funnel analysis? Give an example of when you would use each.
10. How do you handle a situation where two teams give you conflicting data that should be the same number?
11. How would you segment Solarsquare's customer base to prioritise a referral programme outreach?
12. You have five analysis requests from different teams and time for only two. How do you decide which ones to take?

Q: Walk us through a time you worked with messy or incomplete data.

*Situation:* At my previous role, our sales team used two separate tools, one for leads and one for closed deals, and the two systems had never been linked. When asked to build a conversion funnel report, I found that customer names and phone numbers were entered inconsistently across both tools, so a simple join produced wrong numbers.

*Task:* My goal was to produce an accurate lead-to-close conversion rate that the sales head could present to leadership with confidence.

*Action:* I wrote a Python script using pandas to standardise phone numbers to a single format, strip extra spaces from names, and fuzzy-match records that still did not join cleanly. I flagged a small subset I could not match confidently and escalated those to the ops team for manual review. I also documented every cleaning step in a log so anyone could audit the work later.

*Result:* The final report covered a much higher share of records than the raw join. The sales head used it to spot that one city was converting leads at a significantly lower rate than the others, which led to a targeted coaching session for that team. I also handed over the cleaning script so future reports could run the same checks automatically.

---

Q: Tell us about a dashboard or report you built that changed a business decision.

*Situation:* My team was sending a weekly report as a PDF email attachment. It had been running for over a year, but nobody was sure if stakeholders actually read it or acted on it.

*Task:* I was asked to rebuild it as an interactive dashboard and make it genuinely useful to the people who needed it.

*Action:* I spoke with the three main stakeholders to find out which two or three numbers they actually cared about each week. I built a dashboard in a BI tool that showed just those metrics with a week-on-week comparison and one drill-down view for the operations team. The weekly email became a snapshot of the dashboard instead of a separate document.

*Result:* Within a month, the operations head was using the drill-down view every Monday to reassign workloads before the week started. The team dropped two manual processes that had existed only to feed the old report. A small format change made the data a real part of the weekly routine.

---

Q: Describe a time you explained a complex data finding to a non-technical stakeholder.

*Situation:* I ran a cohort analysis showing that customers who completed an onboarding call within the first week after purchase had significantly higher long-term engagement than those who did not. The finding was clear in the data but involved cohort retention concepts my audience was not comfortable with.

*Task:* I needed the customer success head to understand the finding well enough to make an internal case for adding a dedicated onboarding caller to the team.

*Action:* Instead of showing the cohort table, I reframed the finding as a plain comparison: 'customers who got a call in the first week behaved like this, and customers who did not behaved like that.' I used a bar chart with two bars, no jargon, and a plain-language headline at the top of the slide. I also prepared a short note on sample size in case there was pushback.

*Result:* The customer success head approved a pilot with one dedicated caller. The finding became the internal justification for the role and was referenced in the team's quarterly review.

For SQL and technical questions: Think out loud before you write. State the tables you assume exist, name the columns you would expect, then build the query step by step. Interviewers at startups like Solarsquare often value your reasoning more than a perfectly optimised query on the first attempt.

For 'how would you measure' questions (the Goal-Metric-Guardrail approach): Start by clarifying the goal. Then define a primary metric (what does success look like?), secondary metrics (what else should move in the right direction?), and guardrail metrics (what must not worsen?). For Solarsquare, anchor your metrics to the solar customer journey: installation speed, energy yield, customer satisfaction, and referral rates.

For root-cause and investigation questions (the Funnel-down approach): Start broad, then narrow. Is the problem affecting all customers or just a segment? Is it new or has it been building slowly? Is it a data collection issue or a real-world operational issue? Walk the interviewer through each branch before you land on a hypothesis.

For stakeholder and prioritisation questions: Name the framework you are using (impact vs. effort, urgency vs. strategic value, or similar), apply it to the situation openly, and state the trade-off you are making. Interviewers want to see that you can confidently set aside low-value work and explain your reasoning.

Solarsquare is a fast-growing startup, so interviewers typically look for more than the ability to query a database. They want analysts who connect numbers to business outcomes and can communicate findings clearly to people who are not data experts.

Domain curiosity. You do not need prior solar industry experience. Showing genuine interest in how rooftop solar economics work, how installation operations run, or what drives customer satisfaction signals that you will ramp up faster and ask sharper questions from the start.

SQL and Python fluency. Candidates report that at least one round is hands-on. Strong candidates write clean, readable code and explain their logic without being prompted, rather than waiting for the interviewer to pull it out of them.

Business framing. For every analysis you describe, tie it back to a decision it enabled or a problem it solved. Interviewers want to know you understand why a number matters, not just how to calculate it.

Comfort with ambiguity. Data at a growth-stage company is rarely clean and requirements are rarely fully defined. Interviewers probe for candidates who ask good clarifying questions, state their assumptions openly, and move forward without waiting for perfect specs.

Clear, simple communication. Solar customers and field operations teams are not analysts. The ability to translate a complex finding into one plain-language headline is valued as much as the technical skill that produced the finding.

Week 1: Company and domain context

Learn how rooftop solar sales and installation work in India. Map the customer journey from first inquiry through site survey, proposal, installation, and ongoing performance monitoring. Think about what data each stage generates and what a data analyst might track at each step. This context makes your interview answers feel grounded rather than generic.

Week 2: Technical brush-up

Practise SQL with a focus on window functions, CTEs, date-based calculations, and multi-table joins. These are the areas candidates report coming up most often. If the role mentions Python, revise pandas-based data cleaning and basic visualisation. Review the key metrics for a sales funnel, a field operations team, and post-sale customer retention.

Week 3: Structured answer practice

Write out STAR answers for the questions in this guide. Record yourself or practise with a colleague. Do at least one timed SQL exercise under realistic conditions. Prepare one or two examples of dashboards or analyses you have built, even a screenshot, so your answers are concrete rather than abstract.

On the day: Ask at least one question about how the data team currently measures its own impact. It signals professional maturity and gives you useful information about the role. While your focus is on interview prep, knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR for you so no suitable opening slips by.

Jumping to the answer before clarifying the question. Many candidates hear 'write a SQL query' and start typing before they understand the business context or the table structure. Slow down, ask one or two clarifying questions, then start.

Describing data without describing impact. 'I built a report showing X' is a weak answer at a startup. 'I built a report showing X, which led the team to change Y' is what interviewers remember. Always close with the outcome.

Ignoring the solar context. Generic answers to questions like 'how would you measure customer success' feel thin if they could apply to any industry. Anchor your examples to what a rooftop solar business actually cares about: energy yield, installation timelines, EMI payment health, and referrals from satisfied customers.

Over-engineering the technical solution. A working, readable query beats a complex optimised one that is hard to follow. Explain your logic clearly and ask whether the interviewer wants you to optimise before you do.

Not asking any questions at the end. Solarsquare's data function is still maturing. Asking about the tool stack, how analysts collaborate with product and operations, or how success is measured for the role shows confidence and genuine interest in the work.