The GTM engineer portfolio review interview

• 01 Where does this system stop, and what did you decide was somebody else's problem? Whether the edges were chosen or arrived at by accident

  Follow up with

  • What arrives at that edge in a shape you have to fix before you can use it?
  • Who did you have to tell that you were not going to handle their case?
  • What has crossed that edge since, and who told you?

  Strong answer

  A strong candidate names an edge and the conversation that put it there. The ones worth drawing sit where somebody else owns the consequence — a rep who has to be told a record is wrong, a finance number nothing here is allowed to restate — rather than where the work stopped being interesting. Push on what crosses that edge and they can describe the shape it arrives in and what they do about it when it is wrong, because a boundary you defend is one you have watched people lean on. Most will name a request they turned down and who asked for it.

  Weak answer

  A weak candidate describes the boundary as wherever the last ticket ended. Asked what they decided was not theirs, nothing comes back, and that usually means the system absorbed every request anyone made and now holds pieces of four other teams' work. They can say what it does and not what it declines to do.

• 02 Show me the join in here that gives you the most trouble, and what happens when it misses. Whether rows that fail a join have somewhere to go

  Follow up with

  • How many rows fall out of it on an ordinary run?
  • Where do the ones that miss end up?
  • What would need to change upstream for the join to go away?

  Strong answer

  A strong candidate goes straight to it, because almost anyone who has run a GTM pipeline has one: person to account, or activity to opportunity, keyed on something that was never an identifier — a company name, an email domain, a field a rep types. They know what the miss rate looks like on a normal day, and the rows that miss go somewhere a person can look at rather than nowhere. Ask what would remove the join and a senior candidate reaches upstream to whoever writes the key, instead of proposing a fuzzier match.

  Weak answer

  A weak candidate points at the join, says it is mostly fine, and cannot put a proportion on the rows that fail it. Those rows are dropped by a filter written a year ago and nobody has counted them since. The fix on offer is looser matching, which turns a visible miss into a wrong row nobody will notice.

• 03 Walk me through what this does with a record carrying a field you did not expect. Whether odd input was designed for or is being reasoned about now

  Follow up with

  • Show me where that decision is written down in here.
  • Has it happened here, and how did it show up?
  • What does the run report say the next morning?

  Strong answer

  A strong candidate can point at the place that decides, and there are only a few honest behaviours: refuse the record and say so, carry it through with the field ignored, or stop the run. Which one they picked matters less than whether it was picked. What matters more is where the answer ends — an unexpected field in a GTM feed usually means a vendor changed something, so the good version finishes with somebody being told rather than with the record being swallowed. Ask whether it has happened and most people who built this have a morning they remember.

  Weak answer

  A weak candidate has to work it out in front of you, which means nothing has ever fed this a record it did not expect. The answer arrives as what should happen rather than what does, and the code on the screen either has no branch for it or has one that quietly eats the record.

• 04 Who runs this now, and what did you have to leave behind for them? Whether the handover was a set of artifacts or a meeting

  Follow up with

  • What have they asked you about since?
  • What in here would you not hand over as it stands?
  • What have they changed that you would not have?

  Strong answer

  A strong candidate answers in specifics: a person, the thing they wrote for that person, and the two or three subjects that still come back to them. Authorship shows here more than almost anywhere. Someone who built it knows which part was fragile enough to be worth writing down and which part went undocumented because it has never once needed touching. Ask which part they would not sign off on as it stands and the honest answer names a piece held together by something only they understand. If it is still theirs, the same question works on what would have to exist before it were not.

  Weak answer

  A weak candidate says the team owns it, or that it is documented, and draws a blank on what anyone has asked them since. Someone who was near the project rather than in it tends to describe the handover as a meeting that took place, not as a list of things that had to be written down first.

• 05 What did you decide not to build into this, and who wanted it? Whether scope was defended against a named person

  Follow up with

  • What would it have cost to add?
  • Did they come back? What happened the second time?
  • What is in this that you would refuse if you were asked today?

  Strong answer

  A strong candidate has a specific request with a specific person attached, and the reason turns on what the thing would cost to keep running rather than what it would cost to write. Most of what gets asked of a GTM system is cheap to add and expensive to own: a field somebody has to maintain by hand, a branch that fires for one team, a report that was wanted once. A senior candidate can also name one they let through and regret, which is the harder half of it and the part that says they have lived with the result.

  Weak answer

  A weak candidate tells you everything asked for got built, which is either untrue or the reason the system looks the way it does. Or the refusal comes with no requester attached, which usually means it was an idea they had and dropped rather than something anyone pushed for.

• 06 This is running now. What would go backwards if you switched it off tomorrow, and what tells you that? Whether a claimed improvement has a baseline behind it

  Follow up with

  • What else changed while this was going in?
  • Do you still have the reading from before it went live?
  • Who else claims credit for the same movement?

  Strong answer

  Naming what would go backwards means naming what it moved, so a strong candidate has to keep what they can show apart from what they believe. The honest version comes with a before, an after, and an admission that two other things went live in the same window, and they say which part of the movement they would put down to this one with the person who owns that number listening. Whether a reading was taken beforehand decides the rest. Somebody who ran the thing took one, because they wanted to be able to answer this exact question afterwards.

  Weak answer

  A weak candidate gives a percentage with no baseline and no period, or credits the system with a rise that had other causes sitting in the same three months — a price change, a new segment, three reps who joined. Asked what else was in flight, nothing comes back, and the number stays attached to the work by nothing more than the order the two happened in.

• 07 Which parts of this did a model write, and what did you change afterwards? Whether model output was reviewed or accepted

  Follow up with

  • Show me somewhere you took what it gave you and threw it away.
  • What does it get wrong every time in work like this?
  • Which part of this would you not have let it near?

  Strong answer

  A strong candidate is not defensive in either direction, because this is not a test of how much they used. They can point at something on the screen, say what it produced, and say what they rewrote, and the rewrites cluster: error handling, the parts that touch a live system, and anything that depended on how a vendor actually behaves rather than on how it is documented. Ask what it gets wrong every time and someone who works this way daily will have an answer ready, and it is a pattern in their own work rather than an opinion about models.

  Weak answer

  A weak candidate either claims none of it, which is easy to press on by asking about the parts that read as generated, or cannot say where the model's output stopped and theirs began. Asked what they changed afterwards, they say they read it through. The parts they cannot account for are the ones to spend the rest of the round on.

• 08 What did the first version look like, and what made you change it? Whether the design has a history or is described as it stands

  Follow up with

  • What was still true from the first version when you finished?
  • How long was it live before you knew it was wrong?
  • What did you have to migrate when you changed it?

  Strong answer

  A strong candidate describes something noticeably worse than what is on the screen, and names what forced the change: a volume the first shape could not carry, something it got wrong while a customer was watching, a person it could not grant access to. The migration follow-up is where the author separates. Changing a system that is already running means moving data that already exists into the new shape, and whoever did that can tell you what would not move cleanly and what they left behind in the old shape on purpose.

  Weak answer

  A weak candidate makes the first version a rough draft of this one, same shape and fewer features. Nothing forced a change, so nothing was learned, and the migration follow-up comes back as there having been nothing to migrate. Someone who arrived after the rewrite tends to answer this without ever saying who decided.

• 09 What around this is still done by hand, and why did you leave it there? Whether the manual step is a decision or a gap nobody costed

  Follow up with

  • How long does it take, and who does it?
  • What would break if you automated it tomorrow?
  • What has gone wrong the times it was skipped?

  Strong answer

  A strong candidate produces one without hesitating and then defends it, because there is nearly always a step cheaper to keep human: an approval, a judgment call on a handful of records a week, a vendor whose API is not worth the trouble. What makes it a good answer is that the cost is known — who does it, how long it takes, and what an automated version would have to get right before the build was worth doing. Ask what has gone wrong when the step got skipped and someone who lives with it will have an example.

  Weak answer

  A weak candidate says none of it, which nearly always means there is a step somebody else does that they never counted. Or the manual step is named as an item on a backlog with no reason attached, which comes to the same thing: nobody worked out whether automating it was worth doing.

• 10 What does this cost to run, and what happens to that if volume triples? Whether the bill splits into what scales and what does not

  Follow up with

  • Which line of that grows with volume and which does not?
  • Who sees that bill, and what do they do when it moves?
  • Where would you cut it first if you had to?

  Strong answer

  A strong candidate splits the bill before answering the second half, because these systems mix a flat platform fee with per-record charges for enrichment, verification and model calls, and only the second kind triples. Getting that split right is the bulk of the answer. Expect them to know roughly what one record costs to put through and to name the line that would hurt at three times the volume, usually whichever vendor charges per match. A senior candidate also knows whether anyone would notice in time, since a usage bill that arrives monthly can run at three times its expected size for weeks before a human sees the figure.

  Weak answer

  A weak candidate gives one number for the whole thing, usually the subscriptions, and says cost scales with volume without saying which parts of it do. Or they have never seen an invoice for any of it, which is a fair answer from someone who did not own the system and says something about the artifact they chose to bring.

• 11 How do you find out when this is broken, and who gets told? Whether silence is read as evidence the system is working

  Follow up with

  • What is the last thing that broke without an alert firing?
  • What does the message actually say when it arrives?
  • How many fired last month, and what did anyone do about them?

  Strong answer

  A strong candidate distinguishes the run failing from the run succeeding with nothing in it, and it is the second that goes unnoticed: a job that completes over an empty source writes nothing, raises nothing, and starves whoever reads the output. The good answers include a check on volume or freshness and not only on exceptions. The count is worth asking for. An alert firing several times a week is one nobody reads any more, and somebody who has lived with it will say so before you have to.

  Weak answer

  A weak candidate says errors go to a channel, with nothing to say about what the message contains or who acts on it. Asked what last broke without an alert, either nothing comes to mind or the example is something a person downstream reported, which amounts to having no alert. A successful run over an empty source never comes up.

• 12 Whose access did this need, and what did you have to argue for? Whether access was scoped or arrived with the seat

  Follow up with

  • What did you ask for first, and what did you end up with?
  • What can this do today that you would take away if you were granting it?
  • What happens to that access when whoever granted it leaves?

  Strong answer

  A strong candidate remembers the negotiation, because write access into a CRM or onto a sending domain is rarely a ticket somebody just approves. They know who owns that access, what the objection was, and what they conceded to get past it — a narrower scope than they asked for, or a sandbox first. The question about taking access away is the one that sorts people: somebody who has held that access for a year can point at a permission on there that is broader than the job needs. The last follow-up settles whether the access hangs off a person or off a service account.

  Weak answer

  A weak candidate had admin and does not remember asking for it, which usually means it came with the seat. There is nothing to say about scope because nothing was scoped, and revoking access is answered as though nobody would ever want to.

• 13 Which data source in here have you stopped trusting, and what did you do about it? Whether distrust came from a sample or from a reputation

  Follow up with

  • What made you check?
  • How wrong was it, and on which kind of record?
  • What is still running on it?

  Strong answer

  A strong candidate names a vendor or a feed and the thing that made them look, which is more often a complaint from someone downstream than a monitor. What follows is the senior part: they checked a sample against something they could verify, so what comes back has a shape to it — wrong on this class of record, fine on that one — instead of being a general loss of faith. The last follow-up is meant to be uncomfortable. Pulling a source out of a live system is expensive, and the honest answer is often that it still runs with its output marked or weighted down rather than removed.

  Weak answer

  A weak candidate rates the vendors as all much the same, or calls one bad without saying what it was compared against. Nothing was sampled, so the distrust is a reputation rather than a measurement, and whatever it feeds is either still fully believed downstream or was torn out on a hunch.

• 14 What did you do about sending reputation here, and what would you check first if replies fell? Whether a reply drop gets diagnosed before the copy is rewritten

  Follow up with

  • Where is this actually sending from?
  • How many inboxes are behind it, and how much does each one send a day?
  • What does this do with a bounce?

  Strong answer

  Weight the second half. A reply drop has a short list of causes and a strong candidate works them in an order: what got changed that week, then whether the messages are landing, then the list, then the wording. Editing the sequence before that is settled buys a second bad week. The figures they ask for are the ones that tell those apart — bounces split into hard and soft, whether the fall sits on one sending domain or across all of them, whether it begins on a date something was touched. On the first half they can say which domains send, what authenticates them, and why the per-inbox number is the number it is.

  Weak answer

  A weak candidate answers the first half with the sending tool's warmup toggle, as though reputation were a setting the platform maintains for them. On the second half they open the sequence, because it is the part they can change without asking anyone, and whether the messages were landing never gets settled. Bounces come back as one rate with no split behind it.

• 15 What is the strangest thing this has done in production? Whether they watched this system misbehave for long enough

  Follow up with

  • How did it come to light?
  • How far back did it go?
  • What is in here now because of it?

  Strong answer

  This is the hardest one to borrow. Somebody who ran a system for a year can give you one with texture: a duplicate that only appeared for accounts created on one particular day, a rep who typed something nobody had considered typing, a vendor that started returning a valid-looking answer to every query. The good version says how it surfaced, which is rarely the monitoring, and points at a line on the screen that exists because of it. Ask how far back it went and someone who was there gives you a number they are not proud of.

  Weak answer

  A weak candidate offers a generic failure, an API outage or a field that changed, with no detail about how it showed up or what it cost anyone. Somebody who was in the room rather than in the code can describe what the incident looked like from outside and not what it looked like in the data.

• 16 What does the person on the receiving end of this actually see? Whether the output was ever watched being used

  Follow up with

  • When did you last watch one of them use it?
  • What do they ignore?
  • What do they have to do before it is any use to them?

  Strong answer

  A strong candidate describes the screen rather than the payload: which fields land where, what the notification says, what the rep has to click. The part worth pressing on is what gets ignored. Anything a system writes that nobody reads is cost with no return, and someone who has watched a rep work knows which of their own outputs falls in that category. Expect them to have sat with one person — sat with them, not surveyed the team — and to be able to say what that person was doing immediately before this thing arrived.

  Weak answer

  A weak candidate walks you through the write instead of the view, listing fields and sync direction. Asked what the rep ignores, there is nothing, because nobody ever looked. The system gets judged on whether it delivered rather than on whether anything happened next.

• 17 What in this shape did you inherit and would not have chosen? Whether the cost of a bad shape is known per write

  Follow up with

  • What does that cost you every time you write against it?
  • What would it take to change now?
  • What did you build on top of it rather than fixing?

  Strong answer

  A strong candidate points at a specific field or object and says why it is wrong: a picklist doing the work of a relationship, a field whose meaning drifted two years ago while its name stayed, one object holding two things that needed to be separate. What makes it a senior answer is the third follow-up. They built around it, and they can tell you what that workaround costs on every write. Someone who understands the object model can also price the fix, and the price is nearly always the reports and integrations reading that field rather than the field itself.

  Weak answer

  A weak candidate finds nothing wrong with the shape, or picks out something they would have given a different name. The costs of the inherited shape are invisible to them, which tends to mean they have only ever read from it. Asked what changing it would take, the answer stops at altering the field.

• 18 What in this breaks first at ten times the volume? Whether a specific limit is known or scale is answered in general

  Follow up with

  • Is the first thing you would hit a limit or a window?
  • How long is the run today, and does that time grow in step with the rows?
  • What would you want in place before anyone tried?

  Strong answer

  A strong candidate gives you one thing rather than a claim that the whole lot would need rewriting, and the one thing is usually a limit rather than the code: a vendor's per-minute quota, a page size, a nightly window already using most of the night. They know whether run time grows in a straight line with the rows or faster, because a call made once per record inside a loop is the common reason it is faster. Expect some evidence behind the answer: a backfill, a day a list arrived bigger than anyone expected, a rerun over a full year.

  Weak answer

  A weak candidate answers with the database, or with a general statement that it would have to be rebuilt as a proper pipeline. No limit is named and no run time is known, so the answer never tells apart what would fail at ten times the volume from what would fail at a hundred.

• 19 Who reviewed this before it went live, and what did they catch? Whether they were in the review or heard about it afterwards

  Follow up with

  • What did you and they disagree about?
  • What went live without anyone looking at it?
  • What would you want reviewed if you built it again?

  Strong answer

  A strong candidate names a person and something specific that person caught, and the specificity is what marks the author. Reviews catch dull things: a wrong default, a case in the data nobody had considered, a permission wider than the job needed. Whoever sat through it remembers what the argument was about. That second question is worth asking of any real system, because parts of it went out unreviewed, and a good candidate says which parts, and usually they were the urgent ones, and usually the ones that came back later.

  Weak answer

  A weak candidate reports that it was reviewed without naming anyone, or offers a process instead of a person. Nothing was caught, which means either the review was a formality or they were not in it. Asked what went out unreviewed, the answer is nothing, and very little that ships against a date has nothing in that category.

• 20 With the same constraints again, what would you do differently? Whether the alternative was ever tried or is hindsight

  Follow up with

  • Which of those constraints would you push back on now?
  • What did you already try that did not work?
  • What would you keep exactly as it is?

  Strong answer

  The constraint clause is what makes this answerable. A strong candidate turns down the invitation to wish those constraints away; they take the same budget, the same access, the same people, and name a decision inside them they would make differently. The second question separates hindsight from experience, because whoever ran the thing tried a version of the better idea already and can say why it did not survive. They can also name a part they would keep, which is harder than it sounds and stops the answer sliding into a general apology for the work.

  Weak answer

  A weak candidate spends the answer on the tools they would use now, or on more time and more budget, which is exactly what the constraint clause was written to rule out. Nothing was tried and abandoned, so the alternative on offer has never met anything. Asked what they would keep, nothing comes back, which is usually a sign no part of it was a decision at the time.

No question carries that tag.