Home / Blog / Build a skill Q&A bank: prep for the questions recruiters actually ask

Build a skill Q&A bank: prep for the questions recruiters actually ask

PrepHike · 6 min read

Most engineers prepare for interviews by reading random question lists. That is backwards. The questions you will actually face come from your own resume. This post shows you how to build a skill Q&A bank: a focused set of recruiter-perspective questions for every skill you claim, at the depth a real interviewer probes.

Why generic question lists fail you

Search "how to prepare for technical interview" and you get thousand-item lists. You read them, feel productive, and then freeze in the actual room because the interviewer asked something specific about a line on your resume. That gap is the real problem. Interviewers do not ask abstract trivia. They read what you wrote, pick a skill you listed, and push on it until they hit the edge of your understanding. Your job is to find that edge first.

This is the Interrogate phase of preparation. Before you practice answers, you build the question set. And the right question set is not generic. It is built from your resume, skill by skill, at the depth that matches the level you are targeting. An engineer applying for a 35 LPA backend role gets harder Redis questions than one applying for 12 LPA. Same skill, different floor.

Start from your resume, not a question bank

Open your resume. Highlight every concrete technical skill: languages, databases, queues, frameworks, cloud services, anything an interviewer could point at and say "tell me about this." For a typical 2-6 year engineer that is usually 12 to 20 items. Postgres, Redis, Kafka, Docker, React, whatever you actually shipped with.

Now flip your perspective. You are no longer the candidate. You are the interviewer who has 30 minutes and wants to know if you really used this or just touched it. For each skill, write the questions that person would ask. Three layers per skill works well:

• Layer 1, did you use it: basic usage, what problem it solved on your project. Anyone can pass this if they are honest.
• Layer 2, do you understand it: how it works under the hood, trade-offs, why you chose it over alternatives. This is where most underprepared candidates wobble.
• Layer 3, where are the limits: failure modes, when not to use it, what you would change at 10x scale. This is what separates a 20 LPA answer from a 35 LPA answer.

If you cannot honestly write Layer 2 and Layer 3 questions for a skill, that is a signal. Either you go learn it properly before the interview, or you soften how you list it on the resume. Listing "expert in Kafka" when you ran one consumer group is how interviews fall apart in minute four. The same honesty principle runs through our market value audit: you cannot price yourself accurately if you have not measured what you actually know.

A worked example: Redis

Redis shows up on a huge number of Indian backend resumes, usually as "used Redis for caching." That single phrase invites a predictable chain of redis interview questions. Here is the bank a competent interviewer would build, by layer.

Layer 1: usage

• What did you use Redis for on your project?
• What was your cache hit ratio, roughly? What were you caching?
• How did you set expiry on keys?

If you say "caching" and cannot name what you cached or give a rough hit ratio, the interviewer already knows the depth is shallow. Have a real number. "We cached user session and product-listing responses, hit ratio sat around 85 percent, TTL of 10 minutes on listings" is a complete Layer 1 answer.

Layer 2: understanding

• What happens when Redis memory fills up? Walk me through eviction.
• Which eviction policy did you run, and why? Difference between allkeys-lru, volatile-lru, and noeviction?
• Redis is single-threaded for command execution. Why is it still fast, and what does that mean for a slow command like KEYS *?
• How is your cache invalidated when the underlying data changes?

The eviction question is the classic filter. A strong answer: Redis enforces maxmemory, and when it is hit, behavior depends on policy. noeviction rejects writes with an error, which surprises people in production. allkeys-lru evicts the least recently used key across the whole keyspace. volatile-lru only evicts among keys that have a TTL set, so if you forgot to set TTLs, it can behave like noeviction and start erroring. Knowing that distinction is the difference between sounding read-up and sounding experienced.

Layer 3: limits and trade-offs

• Pub/sub versus streams: when would you pick one over the other?
• When would you not use Redis?
• What are the consistency risks of using Redis as a cache in front of a database?
• How do you handle a cache stampede when a hot key expires?

The pub/sub versus streams question is excellent because it catches people who treat Redis as one undifferentiated tool. Honest answer: pub/sub is fire-and-forget. If no subscriber is connected when a message is published, that message is gone, there is no persistence and no replay. Redis streams persist messages, support consumer groups, and let a consumer acknowledge and resume from where it left off. So pub/sub fits live notifications where a missed message does not matter, and streams fit work queues or event logs where you cannot afford to drop anything. The "when not to use Redis" question is even simpler to get right and almost everyone fumbles it: you do not use Redis as your primary store for data you cannot afford to lose without understanding its persistence trade-offs, and you do not reach for it when a simpler in-process cache would do.

Notice the pattern. Three layers, roughly ten questions, one skill. You now know exactly where your Redis knowledge ends, and you can close that gap before someone else finds it for you.

Scoping depth to the role and salary

You do not build all three layers equally for every skill. Two things set the depth. First, how central the skill is to the role: if the JD lists Kafka five times, build it to Layer 3 and rehearse it. If you mention Docker once, Layer 1 and a light Layer 2 are enough. Second, the salary band. A 30 to 40 LPA role expects you to reason about trade-offs and scale unprompted. That is Layer 3 territory across your core stack. Be honest with yourself about which band you are targeting and prep to that floor.

This same depth-scoping logic shows up in system design interviews, where the questions are open-ended and the interviewer watches how far your reasoning goes. The skill Q&A bank is the foundation: if your component-level knowledge is solid, your system design answers stop being hand-wavy.

Turn the bank into practice

A question bank you only read is half-finished. Once you have your questions per skill, answer them out loud, ideally to another person. Saying "eviction policy" in your head is easy. Explaining volatile-lru cleanly to someone who is pushing back is where the real preparation happens. For project-level questions, pair this with the 30-second project method so your skill answers connect to the work you actually did, not floating theory.

Build the bank once and it pays off across every interview in your search. The skills do not change between companies. Postgres is Postgres at Razorpay and at a Series A startup. You refine the bank after each round, adding the questions you got hit with and did not expect. That compounding is exactly how serious candidates pull ahead.

This interrogate-then-rehearse approach is the core of how we work with engineers at PrepHike. If you want a second set of eyes building the question bank for your specific resume and target band, that is what a session is for. See the method and pricing to decide if it fits.