Code Review: Improve a Java Method That Builds a CSV String

Read the full interview experience this question came from →

Quick Overview

A Java code-reading question: review a short method that concatenates a list of rows into a CSV string and propose improvements. It tests knowledge of string-building performance, separator and escaping rules for CSV, null handling, streaming output for large exports, and risks when files are opened in spreadsheets.

Code Review: Improve a Java Method That Builds a CSV String

Company: Mercor

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Technical Screen

The interviewer shows the following Java method and asks what improvements you would make. There is no coding in this round: explain the problems you see and how you would fix them. ```java public String buildCsv(List<List<String>> rows) { String s = ""; for (List<String> row : rows) { for (String cell : row) { s += cell + ","; } s += "\n"; } return s; } ``` ```hint Count the copies Java strings are immutable. Think about how much copying the loop performs as the output grows. ``` ```hint Feed it awkward cells Try a cell that contains a comma, a double quote or a line break, and read the output the way a CSV parser would. ``` ### Clarifying Questions - Who consumes the output: a spreadsheet application, another service, a file download? Which CSV conventions and line endings does it expect? - Can cells contain commas, double quotes or line breaks? Can a cell or a row be `null`? - How large can the input be, and must the result be one `String`, or could it be written to a file or a response stream? - Do all rows have the same number of cells, and is there a header row? ### What a Strong Answer Covers - The cost of repeated string concatenation inside a loop, and the fix - Correct structure: separators between cells rather than after each one, and consistent line endings - Quoting and escaping of cells that contain separators, quotes or line breaks - Handling of `null` cells and rows, and other input validation - API and memory design for large exports, the choice between a library and hand-written code, and tests - Risks when the output is opened in a spreadsheet application ### Follow-up Questions - The export must handle tables too large to hold in memory. How do the signature and the implementation change? - Which test cases would you write for this method? - Would you write this yourself or use a CSV library, and what would decide it? - How would you protect users who open the exported file in a spreadsheet application from cells that look like formulas?

Overview: A Java code-reading question: review a short method that concatenates a list of rows into a CSV string and propose improvements. It tests knowledge of string-building performance, separator and escaping rules for CSV, null handling, streaming output for large exports, and risks when files are opened in spreadsheets.

Read the full Mercor Software Engineer interview experience this question came from

|Home/Software Engineering Fundamentals/Mercor
Mercor logo
Mercor
Oct 10, 2026
mediumSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals
0
0

The interviewer shows the following Java method and asks what improvements you would make. There is no coding in this round: explain the problems you see and how you would fix them.

public String buildCsv(List<List<String>> rows) {
    String s = "";
    for (List<String> row : rows) {
        for (String cell : row) {
            s += cell + ",";
        }
        s += "\n";
    }
    return s;
}

Clarifying Questions Guidance

  • Who consumes the output: a spreadsheet application, another service, a file download? Which CSV conventions and line endings does it expect?
  • Can cells contain commas, double quotes or line breaks? Can a cell or a row be null ?
  • How large can the input be, and must the result be one String , or could it be written to a file or a response stream?
  • Do all rows have the same number of cells, and is there a header row?

What a Strong Answer Covers Guidance

  • The cost of repeated string concatenation inside a loop, and the fix
  • Correct structure: separators between cells rather than after each one, and consistent line endings
  • Quoting and escaping of cells that contain separators, quotes or line breaks
  • Handling of null cells and rows, and other input validation
  • API and memory design for large exports, the choice between a library and hand-written code, and tests
  • Risks when the output is opened in a spreadsheet application

Follow-up Questions Guidance

  • The export must handle tables too large to hold in memory. How do the signature and the implementation change?
  • Which test cases would you write for this method?
  • Would you write this yourself or use a CSV library, and what would decide it?
  • How would you protect users who open the exported file in a spreadsheet application from cells that look like formulas?
Loading comments...