cswork / libraryOpen practice workspace

Interview guides · Techila Global Services

Techila Global Services Software Engineer Interview Guide

Techila Global Services Software Engineer interview guide: reported rounds, questions and how candidates describe the process.

The 60-second brief

As a Software Engineer at Techila Global Services, you are at the heart of delivering high-impact digital solutions for a diverse global clientele. The company specializes in cloud-based platforms and enterprise software, meaning your work directly influences the efficiency and scalability of business-critical systems. Whether you are developing complex Salesforce integrations, building responsive front-end interfaces, or architecting robust back-end services, your contributions are vital to the firm's reputation for technical excellence. This role is both intellectually demanding and strategically significant. You will often work in fast-paced, collaborative environments where the ability to translate business requirements into clean, maintainable code is paramount.

This guide is scoped to a Software Engineer candidate at Techila Global Services.

Focus areas

  • Salesforce
  • Apex (Salesforce)
  • Governor Limits

The Techila Global Services interview process

Techila Global Services candidates report 3 rounds over 3-5 weeks. The stages below are what candidates describe, not a published process.

Application Review

Initial screening of your background and project history.

What to demonstrate

  • Initial screening of your background and project history
  • Depth in Salesforce

How to prepare

  • Be able to walk your CV end to end in two minutes, and say why this company specifically.
  • Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.

Technical Evaluations

Rigorous assessments focusing on technical competency and practical coding scenarios.

What to demonstrate

  • Rigorous assessments focusing on technical competency and practical coding scenarios
  • Depth in Salesforce

How to prepare

  • Answer aloud and timed: How do you manage asynchronous processes in your preferred programming language?
  • Answer aloud and timed: What are the advantages and trade-offs of using a specific framework (e.g., Node.js, Angular, React) versus a native approach?

Interaction with Stakeholders

Engagement with various stakeholders, including technical leads and management.

What to demonstrate

  • Engagement with various stakeholders
  • Including technical leads and management

How to prepare

  • Answer aloud and timed: How do you handle Governor Limits when writing Apex triggers or batch processes?
  • Answer aloud and timed: Describe your process for building and deploying Lightning Web Components (LWC).

Where candidates lose points

Prepare for follow-up questions

Interviewers at Techila Global Services often drill down into your answers. If you mention a technology or concept, be ready to explain it in detail.

Practice your project walk-through

Be prepared to discuss the architecture, the challenges you faced, and the specific impact of the projects you mention on your resume.

Clarify doubts early

If a question seems ambiguous, ask for clarification before you begin answering to ensure you are addressing the interviewer's intent.

Master the basics

Do not neglect fundamental concepts like OOPS, data structures, and basic algorithms, as these are frequently used to test your core engineering logic.

Questions & practice

How do you manage asynchronous processes in your preferred programming language?

Medium · Technical Fundamentals and Programming

Approach

  1. Say what the runtime actually does before reasoning about the code.
  2. Name what is shared across threads and what owns each piece of state.
  3. Identify the window where an invariant is briefly untrue.
  4. Distinguish a value from a reference to it, and say which one you handed out.

Follow-up

  • What happens if two callers reach this at the same time?
  • Where could this allocate more than you expect?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

  1. Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
  2. For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
  3. For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
  4. Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

  • A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
  • Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.

Approach

  1. Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
  2. Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
  3. Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
  4. Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.

Follow-up

  • The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
  • The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?

How do you optimize queries in SQL, PostgreSQL, or MongoDB?

Medium · Database and System Design

Approach

  1. Name the grain you start from and join outward from it.
  2. Check whether any join is one-to-many before aggregating, or the sums inflate.
  3. Say which index the query would use, and what makes it unusable.
  4. Handle the rows that do not match: that is usually the actual question.

Follow-up

  • How does the query change if that join becomes one-to-many?
  • What happens to this when the table is ten times larger?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

  1. One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
  2. Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
  3. State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
  4. Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

  • A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
  • Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

Explain the key differences between various OOPS concepts and how you implement them in your daily work.

Medium · Technical Fundamentals and Programming

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Can you walk me through the logic behind this specific code snippet? (Be prepared to find the output or identi

Medium · Technical Fundamentals and Programming

Can you walk me through the logic behind this specific code snippet? (Be prepared to find the output or identify a bug.)

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

What are the advantages and trade-offs of using a specific framework (e.g., Node.js, Angular, React) versus a

Medium · Technical Fundamentals and Programming

What are the advantages and trade-offs of using a specific framework (e.g., Node.js, Angular, React) versus a native approach?

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Describe your process for building and deploying Lightning Web Components (LWC).

Medium · Salesforce and Ecosystem Expertise

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

How do you approach complex integrations between Salesforce and external systems?

Medium · Salesforce and Ecosystem Expertise

Approach

  1. Say who the caller is and what they do when the call fails halfway.
  2. Define the identity of a request so a retry cannot double-apply it.
  3. Separate accepted, pending, failed and confirmed; they are different facts.
  4. Design the error taxonomy before the success shape; callers branch on it.

Follow-up

  • What happens if the caller retries after a timeout?
  • How does a client discover it is on an old version of this contract?

Can you explain the difference between a trigger and a flow, and when you would choose one over the other?

Medium · Salesforce and Ecosystem Expertise

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Explain your approach to designing a REST API.

Medium · Database and System Design

Approach

  1. Say who the caller is and what they do when the call fails halfway.
  2. Define the identity of a request so a retry cannot double-apply it.
  3. Separate accepted, pending, failed and confirmed; they are different facts.
  4. Design the error taxonomy before the success shape; callers branch on it.

Follow-up

  • What happens if the caller retries after a timeout?
  • How does a client discover it is on an old version of this contract?

What steps do you take to troubleshoot a performance bottleneck in a production database?

Medium · Database and System Design

Approach

  1. Establish what changed and when, before forming any theory.
  2. Pick a bisection that eliminates candidates whichever way it turns out.
  3. Check the instrumentation before believing the symptom.
  4. Separate the trigger from the cause; the deploy is rarely the bug.

Follow-up

  • What would you look at first, and what would it rule out?
  • How would you tell a cause from a coincidence here?

Suggested practice checklist

Built from the rounds and topics Techila Global Services candidates report.

Day 1 — Map the Techila Global Services loop

  • Write out the reported sequence: Application Review, Technical Evaluations, Interaction with Stakeholders.
  • For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 3 reported rounds, with the weakest marked.

Day 2 — Work Salesforce

  • Spend the session on Salesforce, which Techila Global Services candidates report being tested on.
  • Write one worked example in Salesforce and time yourself on it.

Deliverable: One timed worked example in Salesforce.

Day 3 — Work Apex (Salesforce)

  • Spend the session on Apex (Salesforce), which Techila Global Services candidates report being tested on.
  • Write one worked example in Apex (Salesforce) and time yourself on it.

Deliverable: One timed worked example in Apex (Salesforce).

Day 4 — Work Governor Limits

  • Spend the session on Governor Limits, which Techila Global Services candidates report being tested on.
  • Write one worked example in Governor Limits and time yourself on it.

Deliverable: One timed worked example in Governor Limits.

Day 5 — Answer out loud: Technical Fundamentals and Programming

  • Answer aloud, timed: Explain the key differences between various OOPS concepts and how you implement them in your daily work.
  • Answer aloud, timed: Can you walk me through the logic behind this specific code snippet? (Be prepared to find the output or identify a bug.)

Deliverable: Spoken answers to 2 reported Technical Fundamentals and Programming question(s), under time.

Day 6 — Answer out loud: Salesforce and Ecosystem Expertise

  • Answer aloud, timed: How do you handle Governor Limits when writing Apex triggers or batch processes?
  • Answer aloud, timed: Describe your process for building and deploying Lightning Web Components (LWC).

Deliverable: Spoken answers to 2 reported Salesforce and Ecosystem Expertise question(s), under time.

Day 7 — Answer out loud: Database and System Design

  • Answer aloud, timed: How do you optimize queries in SQL, PostgreSQL, or MongoDB?
  • Answer aloud, timed: Explain your approach to designing a REST API.

Deliverable: Spoken answers to 2 reported Database and System Design question(s), under time.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

How do you handle Governor Limits when writing Apex triggers or batch processes?

Medium · Salesforce and Ecosystem Expertise

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

How do you handle data consistency in a distributed system?

Medium · Database and System Design

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

Ship under a deadline and bound the debt you chose

Medium · pagination · technical debt · tradeoffs

You have four days to ship a tenant-facing listing endpoint. The version you would defend uses keyset pagination over (tenant_id, status, updated_at DESC, resource_id DESC); the version you can finish uses LIMIT/OFFSET with no matching index. Describe a deadline call you actually made of this shape: what you shipped, what you knowingly deferred, how you bounded the damage with a mechanism rather than an intention, and the specific numeric condition that would force the follow-up. Name who you told and where you wrote it down.

Approach

  1. Name the deferred failure precisely instead of calling it slow. OFFSET n makes the database produce and discard n rows, so cost grows with page depth; without an index matching the sort, every matching row is read and sorted before the limit applies; and rows inserted between two page fetches shift across the boundary so items are skipped or repeated with nothing in the response to signal it.
  2. Bound the blast radius with something mechanical rather than a promise: cap maximum page depth, cap page size, restrict the endpoint to one internal caller, or keep it behind a flag. State which failure each cap removes and which it leaves standing.
  3. Attach a number to the trigger and wire it to an alarm: the first tenant crossing N resources, or the endpoint's p99 crossing its share of the 400 ms budget, so the debt announces itself instead of waiting to be remembered.
  4. Write it where the next engineer looks, which is the code and the ticket, not a chat message: what was deferred, why, the cap, and the trigger.

Follow-up

  • At what page depth does the offset version breach your latency budget, given your page size and row counts?
  • What breaks first when you switch to keyset pagination later, and what does a client holding an old page token see?