Dataford
Interview QuestionsInterview GuidesExperiencesCoaching
New
Pricing
Get started
Dataford
Popular roles
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Browse
Browse All RolesEvery role hub, from analyst to MLBrowse All CompaniesCompany-specific interview loopsAll Interview GuidesThe full guide library
Top questions by role
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Top questions by skill
SQLPythonStatisticsMachine LearningA/B TestingSystem DesignGenerative AIProduct SenseMetricsBehavioral
Browse all questions →Try a mock interview
Experiences
Practice
Mock InterviewsTimed interview simulations with feedbackCoaching1:1 coaching with people at your target companiesSuccess PathYour 6-week structured planModulesCurated lessons by topicWebinarsTalks from ex-Big Tech data leadsPlaygroundA free-form scratch editor
Learn
BlogInterview strategy and career adviceTech Job Market ReportHiring trends across data and AI rolesFor UniversitiesDataford for career centersAbout DatafordWho we are and how we build
Pricing
Build my plan

Optimize Code Performance

HardCoding00:00
Practice interviewer
In session
5 left
00:00

Your question is Optimize Code Performance. Take a moment with it on the right.

Talk me through your thinking if you like. When you're confident, submit your answer and I'll grade it like a real screen (7/10 or better passes).

You need to log in / sign up to chat or submit.

Problem

Vertafore's insurance operations team runs a nightly batch job that recalculates rating and pricing for every policy up for renewal, calling an internal rating service and writing results back to Postgres. The batch used to finish in under twenty minutes; now that renewal volume has grown, it regularly runs for most of the night, and the on-call engineer has started killing it before it finishes.

package main

import "database/sql"
import "fmt"
import "net/http"
import "sync"

type PolicyRow struct {
	PolicyID string
}

type Result struct {
	PolicyID string
	Rating   float64
}

var mu sync.Mutex
var connString = buildConnString()
var ratingAPIURL = buildRatingURL()

func processRenewals(rows []PolicyRow) []Result {
	var results []Result
	var wg sync.WaitGroup
	var reportLog string

	for _, row := range rows {
		wg.Add(1)
		go func(r PolicyRow) {
			defer wg.Done()
			mu.Lock()
			defer mu.Unlock()

			db, err := sql.Open("postgres", connString)
			if err != nil {
				return
			}
			defer db.Close()

			resp, err := http.Get(ratingAPIURL + "?policy=" + r.PolicyID)
			if err != nil {
				return
			}
			defer resp.Body.Close()

			rating := parseRating(resp)
			db.Exec("UPDATE policies SET rating = \$1 WHERE id = \$2", rating, r.PolicyID)

			results = append(results, Result{PolicyID: r.PolicyID, Rating: rating})
			reportLog += fmt.Sprintf("processed %s: %v
", r.PolicyID, rating)
		}(row)
	}

	wg.Wait()
	fmt.Println(reportLog)
	return results
}

The team suspects the goroutines here aren't actually buying any real concurrency. Explain where the real bottlenecks are and how you would restructure this so it scales with renewal volume.