LinkedIn SDE Phone Screen: Projects, DynamoDB, and Long Pressed Name
Updated July 17, 2026
A candidate applying for SDE roles in December 2024 ran several interview processes in parallel over the month, later writing them all up together as a monthly recap rather than as separate posts; alongside LinkedIn, the same recap also covered processes at IBS Software Solutions, Walmart, and Simplotel. The LinkedIn process consisted of a single phone screen round.
The call opened with a discussion of the candidate's project work: the most complex project worked on recently, what had been learned over the prior six months, and a question about the pros and cons of DynamoDB and when to reach for it. The interviewer then gave one coding question, Long Pressed Name. The candidate was rejected after this round and wrote a short self-review afterward, noting that the project answers were not as sharp as they could have been and that the code written under pressure had edge-case gaps.
How the process went
Job search context
The candidate began applying for SDE roles in December 2024 and ran multiple company processes over the same month, documenting them together in a single monthly recap post rather than writing each one up separately.
LinkedIn phone screen
A single round: project-focused discussion questions followed by one coding problem, all in the same call.
Outcome
The candidate was rejected after the phone screen and wrote a self-review identifying weak project answers, messy code, and missed edge cases as the likely reasons.
Phone Screen
Project discussion followed by one coding question
- What was the most complex project you worked on recently?
- What have you learned over the last six months?
- What are the pros and cons of DynamoDB, and when would you choose to use it?
- Long Pressed Name — determine whether a typed string could result from long-pressing keys while typing an intended name.
The candidate's self-review flagged that the answers to the project questions were not detailed or convincing enough to fully showcase the work done.
The candidate described the code for the coding question as messy, with edge cases missed under time pressure.
The self-review also noted a tendency to overthink instead of trusting a more straightforward first instinct, and suggested practicing working through problems silently before typing as a fix.
Key takeaways
- Prepare a concise, specific narrative for common project questions like "most complex project" and "what have you learned recently" ahead of time rather than improvising in the moment.
- Be ready to explain not just how a piece of infrastructure like DynamoDB was used in a past project, but why it fit better than the alternatives that were considered.
- Recognizing a coding question's category is not the same as writing clean code for it under time pressure; edge-case handling benefits from deliberate practice, not just pattern recognition.
- When overthinking crowds out a straightforward approach, pausing to reason through the problem quietly before writing code can help avoid rushed, error-prone solutions.
- Running several interview processes within the same month, even when most end in rejection, can still function as compounding practice rather than a single isolated pass-or-fail event.
Source
The questions and process facts come from the candidate's public write-up, linked below. The retelling above is our own summary.
Candidate's public write-up on LeetCode Discuss