HCLTech Software Interview Preparation: Eight Worked Questions

Editorial review: 9 October 2026

Prepare for an HCLTech software engineering interview by matching your practice to the actual role and explaining complete solutions. Knowing a definition is useful, but you should also be able to apply it, identify a defect, check an edge case and say which work you personally owned.

The questions below are original editorial practice. They are not questions reported by HCLTech, leaked assessments, a previous candidate's transcript or a prediction of your interview. The coding exercise, state example and project answer are fictional. Choose language and topic depth from the actual role description and invitation.

What does the official process page establish?

HCLTech's recruitment process page describes application and shortlisting followed by technical and HR discussions. It says technical questions may range across disciplines. Use that as a general orientation; confirm the arrangements for the programme and role you applied to. The page does not establish that the eight questions in this article will be asked, or that every candidate receives identical rounds, timings or tasks.

Before practising, identify the required language, relevant project experience and the responsibilities of the actual position. A database role and a user-interface role may need different examples. Ask the recruiting contact about unclear exercise rules rather than assuming internet access, AI assistance or a particular editor is permitted.

Keep preparing

Continue with Top 50 Interview Questions₹299 — coaching के एक महीने से काफ़ी सस्ता / far cheaper than a month of coaching

₹299

Buy this eBook

Question 1: Turn an ambiguous coding request into a contract

Original task: “Summarise repeated text tokens.” Before choosing an algorithm, ask whether repetition means adjacent runs or total frequency across the entire input. These produce different results.

For this exercise the interviewer supplies a precise contract: accept a Python list of strings; preserve input order; combine only adjacent equal strings; compare strings exactly, without trimming or changing case; keep an empty string as a valid token; return a list of (token, count) tuples; reject a non-list input or any non-string member with TypeError. Do not modify the input.

The sample input is ['up', 'up', 'down', 'up', '', '']. The complete expected output is [('up', 2), ('down', 1), ('up', 1), ('', 2)]. The separated occurrences of up belong to different runs. The two adjacent empty strings form one run.

A good explanation begins with this contract, not with a guess that all duplicates should be removed. If the task instead asks for global frequency, establish that different contract before changing the algorithm.

Question 2: Implement the adjacent-run contract

This original implementation uses Python 3 and no external packages. It is a small practice function, not an HCLTech code sample or production library.

def runs(tokens):
    if not isinstance(
        tokens, list
    ):
        raise TypeError(
            "list required"
        )
    out = []
    for token in tokens:
        if not isinstance(
            token, str
        ):
            raise TypeError(
                "text"
            )
        if out:
            p, n = out[-1]
            if p == token:
                out[-1] = (
                    p,
                    n + 1
                )
                continue
        out.append(
            (token, 1)
        )
    return out

sample = [
    "up", "up",
    "down", "up",
    "", ""
]
for token, count in runs(
    sample
):
    print(
        repr(token), count
    )

The complete printed output is:

'up' 2
'down' 1
'up' 1
'' 2

Each new token is compared with the final run. If equal, that run's count increases; otherwise a new run begins. The first token starts a run because the result is empty. An empty input never enters the loop and returns an empty result.

If an invalid member is encountered after valid members, the function raises rather than returning a partial result. The partial working list is local; the caller's input has not been changed. The function accepts list and string subclasses through isinstance; this exercise does not implement a stricter exact-type contract.

Question 3: Explain correctness and complexity

After processing a prefix of the input, the result represents exactly the adjacent runs of that prefix in order. The next string can only extend the final run or begin a new one. Earlier runs cannot change because they are separated from the new token by later input. This is the loop invariant behind the implementation.

The loop visits each token once. For tokens with bounded comparison cost, processing is linear in the number of tokens. If strings can be arbitrarily long, account for their equality-comparison cost rather than claiming all comparisons are constant time. The result stores one tuple per run, so output space grows with the number of runs and is at most one run per input token. The function does not copy the full input into a second list.

A claim that this is fast enough for a real service would require the service's workload, limits and measurements. The small sample establishes behaviour under its contract, not production performance.

Question 4: Debug the wrong global-count solution

Suppose someone counts each unique token across the whole input and produces [('up', 3), ('down', 1), ('', 2)]. That answer describes global frequencies, but it loses the boundary between the first up run and the later one. It is incorrect for the supplied contract even though the total counts add to six.

A minimal counterexample is ['x', 'y', 'x']. The required result is [('x', 1), ('y', 1), ('x', 1)], not a merged x count of two. Explain the lost ordering distinction before proposing a fix.

Python's itertools documentation also distinguishes consecutive grouping from grouping equal keys across all input. The function above is an original manual implementation; it does not copy the documentation's implementation or sort the data. Sorting would change the input order and therefore change the task.

Question 5: Design checks that test the contract

Use expected outputs that could catch the wrong approach:

• Empty input [] must return [].
• One token ['a'] must return [('a', 1)].
• An adjacent pair ['a', 'a'] must return [('a', 2)].
• A separated repeat ['a', 'b', 'a'] must retain three runs.
• Case difference ['A', 'a'] must retain two runs.
• Whitespace difference ['a', 'a '] must retain two runs.
• Two empty strings must return [('', 2)].
• A tuple input and a list containing a number must raise TypeError.

Also preserve a copy of a valid input and compare it after the call. Reconstruct the original list by expanding each returned tuple's token by its count; the reconstruction should equal the original valid input. That check complements the explicit cases, but does not replace them: a result with needless adjacent duplicate runs could still reconstruct the input.

The printed example and these boundary checks were executed for this editorial revision. They do not test arbitrary custom subclasses, hostile inputs or a deployed application.

Question 6: Explain retries with a defined state example

Here is a separate fictional service-design question. A record starts at version 4 with value “off.” Request E7 asks to set it to “on,” expecting version 4. For this exercise, a successful change increases the version once, and the service retains the request identifier, payload and result atomically with that change. Repeating the same retained identifier and payload returns the recorded result without changing state. Reusing that identifier with a different payload is rejected. A different request with an outdated expected version is rejected.

Under those supplied rules, the first E7 succeeds: value “on,” version 5. An identical E7 retry returns the recorded version-5 result and leaves the state unchanged. E7 with value “off” is rejected because its payload differs. New request E8 expecting version 4 is rejected because the record is now at version 5.

The explanation demonstrates why a retry must not accidentally apply a change twice. It also explains why checking only the current version before recognising an identical retained retry would conflict with this particular contract. This is a conceptual exercise, not an implemented HTTP endpoint or a universal database recipe.

For production, ask about transaction boundaries, simultaneous requests, retention, authorisation and failure recovery. The exercise assumes atomic recording; it does not demonstrate it. Do not claim that adding an in-memory dictionary alone provides durable behaviour across processes or crashes.

Question 7: Discuss a project defect with clear ownership

The following answer is fictional, included to demonstrate structure. Do not present it as your own experience.

In a personal practice project, I wrote the adjacent-run function. My first draft merged all occurrences of a token. I noticed that the supplied order-sensitive example required two separate up runs. I added the x, y, x counterexample, changed the loop to compare only the final run and checked empty, case-sensitive and invalid-input cases. I owned that practice function and its checks. I did not deploy a service or measure a business improvement.

For your answer, substitute a genuine project and your own evidence. State whether you wrote the code, reviewed a change or merely observed the defect. Describe the checked result and any remaining limitation. You do not need to invent a customer, a production incident or a percentage improvement to make a small real example useful.

Use the problem-solving guide for another complete example of separating an explanation from the evidence that supports it.

Question 8: Explain your interest and ask about the role

A useful preparation answer links the actual responsibilities to genuine work you can discuss. For example, if the verified role description emphasises a language and testing practice you have used, explain the relevant project and what you want to learn. Do not claim knowledge of a particular customer, team culture or assignment that the employer has not supplied.

Questions you could adapt include: “What responsibilities would this role own initially?” and “What evidence would help you assess my experience with the specified technology?” Ask about unclear working arrangements and the next step in this actual process. The answers belong to that conversation, not to a universal HCLTech interview script.

Check your resume evidence before rehearsing. The project dates, tools and results you discuss should agree with the document you submitted.

Common questions

Are these questions actually asked by HCLTech?

They are original practice questions. No claim is made that they appeared in a real HCLTech assessment or predict your interview.

Should I memorise the code?

Practise explaining the contract, tracing the example and changing the solution when the requirement changes. Memorising a run counter is not preparation for every software role.

Does passing these checks mean I am interview-ready?

It establishes that this small function passed the listed checks. Review the actual role requirements and practise relevant topics and genuine project explanations as well.

Can I claim the fictional service design is implemented?

No. It is a defined reasoning example with explicit assumptions. Implementation, concurrency behaviour and durability would require additional work and verification.