SolarSquare Energy Machine Learning Engineer Interview: Questions, Experience & Prep (2026)

SolarSquare Energy is one of India's fastest-growing rooftop solar companies, helping homes and businesses switch to clean energy. Their ML team works on problems like forecasting daily power generation, scoring and prioritising sales leads, optimising installation pricing, and monitoring panel health across thousands of installed units. With 8 open roles as of mid-2026, they are actively building out their data and ML function.

Candidates report the process typically runs in three to four stages: an initial call with HR or a recruiter, one or two technical rounds (sometimes including a take-home problem or live coding), and a final conversation with a senior engineer or hiring manager. The full process typically takes two to four weeks. Because SolarSquare is a growth-stage company, interviewers tend to value practical problem-solving and business awareness alongside technical depth.

These questions reflect patterns candidates report and the kinds of ML problems SolarSquare works on. Expect a mix of applied ML design, production thinking, and behavioural questions.

1. How would you build a model to forecast daily solar energy generation for a rooftop installation?
2. Walk me through how you would build a lead-scoring model for residential solar customers.
3. We have sensor data from thousands of installed solar panels. How would you detect anomalies or underperforming units at scale?
4. How do you handle missing or noisy data in a time-series ML pipeline?
5. How would you approach pricing optimisation for solar installation packages across different customer segments?
6. Describe a model you have deployed to production. What broke, and how did you fix it?
7. How do you evaluate whether your generation-forecast model is genuinely useful in production, beyond test-set accuracy?
8. SolarSquare operates across Indian cities with very different climates. How would you build ML models that generalise across geographies?
9. How do you keep a model accurate when the data distribution shifts over time (for example, across monsoon versus summer seasons)?
10. Tell me about a project where business requirements changed mid-way. How did you adapt?
11. How would you explain a complex model's output to a non-technical sales or operations team?
12. What do you know about SolarSquare's business, and where do you see the biggest ML opportunity in their customer journey?

Q: How would you build a model to forecast daily solar energy generation for a rooftop installation?

*Situation:* At my previous company, we monitored a fleet of small energy assets and needed accurate day-ahead generation forecasts for operations scheduling.

*Task:* I owned the forecasting pipeline end to end, from raw data ingestion through to the API used by the operations team.

*Action:* I pulled historical generation data alongside weather features (irradiance, temperature, cloud cover) from a public weather API. I cleaned the time series, handled missing sensor readings with forward-fill and interpolation, and engineered lag features and rolling averages. I started with a gradient-boosted model as a baseline, then tested an LSTM to capture daily and seasonal cycles. I used time-based cross-validation to prevent data leakage and tracked MAE and MAPE as the primary metrics.

*Result:* The LSTM outperformed the baseline on both metrics. The forecast API was used daily by the operations team, and managers reported fewer instances of unexpected shortfalls in scheduled output.

---

Q: Tell me about a project where business requirements changed mid-way. How did you adapt?

*Situation:* I was building a customer churn model for a subscription product when, halfway through the build, the product team changed the definition of 'churn' to include a new cancellation window.

*Task:* I needed to retrain on the updated label definition without losing the feature engineering work already completed.

*Action:* Because I had modularised the pipeline, relabelling the training data was straightforward. I reran the pipeline, compared the updated model's performance to the original on the corrected labels, and documented the label change clearly so the business would understand the shift in reported numbers at the next review.

*Result:* We shipped the updated model with minimal delay. The episode reinforced the value of separating feature engineering from labelling logic, and I now treat label definitions as a written contract agreed with stakeholders before I start building.

---

Q: How would you explain a complex model's output to a non-technical sales team?

*Situation:* Our lead-scoring model used a gradient-boosted classifier with many features, and the sales team was skeptical because they did not understand how scores were generated.

*Task:* I needed to build trust in the model without overwhelming the team with technical detail.

*Action:* I used SHAP values to generate a short list of 'top reasons this lead scored high or low' for each record, then worked with a designer to surface those reasons as plain-language tags inside the CRM. I also ran a short session showing the sales team that leads in the model's top decile converted at a far higher rate than the rest, using only their own historical data as proof.

*Result:* Adoption went from near zero to consistent daily use within a month. Managers reported that the team felt more confident prioritising their outreach based on the scores.

For ML design questions (questions 1, 2, 3, 5, 7, 8, 9): Structure your answer in four steps. First, clarify the problem: what is the prediction target, what does success look like for the business, and what data is available? Second, describe the data pipeline: sources, cleaning, and feature engineering. Third, explain model selection and why you chose it over simpler alternatives. Fourth, cover evaluation and production concerns including metrics, retraining triggers, and monitoring.

For production and debugging questions (questions 4, 6, 9): Lead with the failure mode you are addressing, explain how you would detect it, and then describe the fix. Showing that you think about what happens after deployment, not just during training, is what separates strong candidates at a product company.

For behavioural questions (questions 10, 11): Use the STAR structure (Situation, Task, Action, Result). Keep the Situation and Task brief. Spend most of your time on the Action, specifically the choices you made and why. Always quantify the Result if you can.

For the business awareness question (question 12): Research SolarSquare's product (residential and commercial rooftop solar), their sales model (direct sales team), and their recent city expansions. Then connect a specific ML technique to a real pain point in their funnel, such as lead scoring to improve sales conversion or generation forecasting to improve customer confidence in savings estimates.

Domain curiosity, not just domain expertise. Most candidates will not have worked in solar energy before, and that is expected. Interviewers look for people who can quickly map ML techniques to a new domain. Showing that you have thought about what makes solar generation forecasting different from generic time-series work (irradiance data, weather APIs, rooftop panel orientation) signals the right kind of curiosity.

A production mindset. SolarSquare is past the research-lab stage. They want engineers who think about how a model behaves six months after deployment. Bring up monitoring, retraining triggers, and data drift without being prompted.

Clear communication. ML outputs at SolarSquare need to reach sales reps, operations teams, and sometimes customers. Interviewers notice whether you can explain your reasoning simply and confidently.

Ownership and speed. Growth-stage companies value people who can define a problem, build a solution, and ship it without waiting for perfect conditions. In behavioural questions, show moments where you made a reasonable call under uncertainty and then iterated from there.

Genuine interest in the mission. Clean energy is a values-driven space. Candidates who can connect their technical work to making solar affordable for more Indian households tend to leave a stronger impression than those who treat it as just another ML role.

Work through this plan in the week before your interview.

If you have extra preparation time, look into SHAP or LIME for model explainability, as explaining outputs to non-technical teams is a recurring theme in SolarSquare ML interviews. If you are also running a broader ML Engineer search in parallel, knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR for you, so you can focus your energy on preparing rather than hunting for openings.

Giving generic answers without grounding them in SolarSquare's context. Saying 'I would use an LSTM for time series' is weaker than 'I would use an LSTM to capture daily and seasonal cycles in solar irradiance, and I would validate it on data spanning at least one full monsoon season.' Specificity signals domain thinking.

Skipping the business framing. Candidates who jump straight to model architecture without clarifying what the output will be used for often struggle when the interviewer probes on success metrics. Always state what success looks like before describing the solution.

Overselling test-set performance. Interviewers at product companies are skeptical of candidates who claim their model 'improved accuracy by X%' without mentioning how it performed after deployment. Be honest about what you measured and what you did not.

Ignoring data quality issues. Solar sensor data is messy because of hardware faults, communication dropouts, and calibration drift. Candidates who present a clean, ideal-data solution without acknowledging these realities can appear inexperienced.

Not asking clarifying questions. In design questions, jumping straight to a solution without clarifying the prediction target, data availability, or latency requirements is a red flag. Interviewers often leave questions deliberately vague to see if you will ask.

Underestimating the business question. Question 12 ('what do you know about SolarSquare?') is not a warm-up. Candidates who have not researched the company miss an easy opportunity to stand out.