Compare the deliverables, not just the titles
GitLab's solutions-architect handbook describes technical discovery, demos and customer evaluations. BLS similarly describes sales engineering as combining technical product knowledge with customer-facing work. Use those functions to interpret a posting, then confirm the intern's actual assignment.
| Question | Solutions engineering | Software engineering |
|---|---|---|
| What needs to work? | A customer-specific evaluation or demonstration | A defined product capability or system change |
| What might I deliver? | Discovery notes, a prototype and evaluation results | An implementation, tests and a maintainable handoff |
| Who reviews it? | A technical adviser or account-team partner | An engineer responsible for the code or system |
| What should I verify? | Whether the demonstration meets the actual requirements | Whether the implementation meets its contract and handles failures |
Implementation is a third possibility: configuring or integrating a system after purchase. Writing code for a customer does not automatically make a job either presales or product engineering. Ask when the team enters the customer relationship and who maintains the result.
Example: an impressive demo is not yet a purchase recommendation
A fictional customer processes 1,200 support tickets each month. Classification takes six minutes per ticket; a proposed tool takes two. If every ticket qualifies, the estimated time released is 1,200 × (6 − 2) ÷ 60 = 80 hours a month.
That is capacity, not automatically a payroll saving. Now check coverage and review effort. If only half the tickets qualify, the saving is 40 hours. If those eligible tickets also need one minute of checking each, it falls to 30 hours.
The customer also requires an audit export and a way to correct a wrong category. A demo that handles ten easy tickets does not establish either. A reasonable recommendation is to continue the evaluation while withholding purchase approval until the required functions are tested.
Build two samples using the same small project
For solutions engineering, write a one-page customer brief and demonstrate one workflow. Record the requirement, test, observed result and remaining gap. Include an unsupported input so the demo shows what the system cannot do.
For software engineering, build the small service or integration behind that workflow. Specify the input and output, test missing fields and failures, and document how someone else can run it. A mock is acceptable for practice when you identify it as a mock.
Compare which work you wanted to keep improving: understanding the customer's constraints, or making the implementation more reliable. That gives you a better basis for choosing than whether you enjoy presentations.
Practice responding to a requirement you cannot meet
Have someone interrupt with: ‘Our ticket text cannot leave our system.’ Explain what your prototype currently does, why that requirement changes the evaluation and what would need testing. Do not invent an offline feature to keep the demo moving.
Be ready to explain the 80-hour estimate and its 40- and 30-hour alternatives. For an engineering discussion, trace the request through your implementation. For solutions work, explain why that behavior matters to the customer.
Ask how much of the internship you will build, observe and present
‘Would I join discovery calls, build demo environments, write code or maintain an existing integration? Who would review that work, and what would I hand over at the end?’
Related titles include sales engineer, solution consultant, presales and implementation intern, but their responsibilities vary. Confirm travel, location and any variable pay in the internship offer; a full-time sales-engineer salary or commission plan is not evidence of intern compensation.