After Interviewing 300 People, Here's What Nobody Tells You About Getting Hired
I started leading a team in 2018, first at a mid-size internet company, then later at a big tech firm. Over the years I have sat through more than 300 interviews, covering frontend, backend, new grads, and senior engineers alike.
After sitting on both sides of the table, one thing became painfully clear: most people do not fail interviews because they lack skill. They fail because they have no idea what the interviewer is actually evaluating.
This is not one of those "top 10 tips to ace any interview" listicles. These are lessons learned the hard way — from my own mistakes, from watching candidates crash and burn, and from debriefing with recruiters after the fact.
The resume filter: what HR actually looks at in those 6 seconds
I have had frank conversations with several HR colleagues about this. Their exact words: "It is not that the content is bad. It is that we cannot find the content."
The average time an HR person spends scanning a resume is six to eight seconds. Not an exaggeration — they genuinely glance at it and decide whether to keep reading. In that window, your most critical information has to be instantly visible.
What gets a resume tossed immediately?
- Cramped formatting. Tiny fonts, zero line spacing, walls of text — no recruiter is zooming in. They skip.
- Key information buried. You have been doing Java for five years, but the word "Java" does not appear until page three. Page one is all self-assessments and hobbies.
- One generic resume blasted to every opening. Recruiters spot this instantly. Applying for a backend role with a resume dominated by student club activities.
- Unexplained gaps. A blank period with no note. HR will not fill in the blanks for you — they will assume you are hiding something.
My personal habit: top of the resume, one line — name, phone, email, target role. Next line, a row of skill keywords so HR can tell in one second whether you match. Then jump straight into work experience. For each role, the first bullet is a one-sentence summary of what you did and the impact it had — then you expand.
Concrete example. Do not write "Responsible for system development and maintenance." Write "Led order system overhaul: QPS from 300 to 3,000, P99 latency from 2s to 200ms." These two sentences land completely differently with a recruiter.
"Tell me about yourself" — this is where most people start losing points
This question kicks off nearly every interview. And about 90% of people proceed to recite their own resume back to the interviewer.
The interviewer already has your resume in front of them. They do not need you to read it aloud. What they are actually looking for: your ability to summarize your experience and connect the dots.
A solid self-introduction should be 90 seconds to 2 minutes. Structure: who I am (10 seconds) → the one or two things most worth talking about from my past work (60 seconds) → why this role interests me (20 seconds).
Do not say "I am hardworking, a fast learner, and a team player." These words carry zero information. Replace them with specifics: "I led a three-person team, built the CI/CD pipeline from scratch, and took test coverage from 10% to 80% in six months." The interviewer will infer your capabilities from the facts.
Technical interviews: interviewers don't care how much you memorized
I have interviewed candidates who could recite fundamentals flawlessly — HashMap internals, JVM memory model, MySQL index structures. Zero hesitation. Then I gave them a real scenario to design, and they froze.
Interviewers ask foundational questions not because they want you to recite a textbook. They want to see whether you can apply that knowledge to real problems.
For instance, I might ask: "Why does MySQL use B+ trees for indexes instead of hash tables?" A memorization candidate says: "Because B+ trees support range queries and the leaf nodes form a sorted linked list." Correct, but then I follow up: "What if all our queries are point lookups with no range queries — would you use hash indexes then? Why does MySQL still default to B+ trees?"
That is where the scripted answers fall apart.
A candidate who genuinely understands says: "Hash is O(1) for point queries, faster than B+ tree's O(log n). But hash does not support leftmost prefix matching, so composite indexes break. And under heavy collisions, hash degrades to O(n). B+ tree performance is stable. Plus hash indexes cannot handle sorting or GROUP BY optimization."
See the difference? One is memorized. The other is understood.
One practical tip: for every concept you study, ask yourself one more "why." Why was it designed this way? In what scenario would it fail? If I had to build it myself, how would I approach it?
Here is a real technical interview scenario — the interviewer hands you this code and asks you to review it:
gofunc GetUserOrders(userID int) ([]Order, error) { orders := []Order{} rows, err := db.Query("SELECT * FROM orders WHERE user_id = ?", userID) if err != nil { return nil, err } defer rows.Close() for rows.Next() { var o Order rows.Scan(&o.ID, &o.UserID, &o.Amount, &o.Status, &o.CreatedAt) orders = append(orders, o) } return orders, nil }
A strong review hits these points: (1) `SELECT *` is a production liability — adding a column to the table breaks this code. (2) No pagination — tens of thousands of orders for one user ID means OOM. (3) `rows.Scan` errors are silently ignored. (4) `rows.Err()` is never checked after the loop. Being able to articulate these things in an interview matters more than listing them on your resume.
What HR will never tell you about their screening process
At large companies, HR screens hundreds of resumes a day. They have filtering rules.
Years of experience mismatches are automatic rejections. JD says "3-5 years" and you have one — it is not because you are not good enough. It is because HR needs to justify their pass/fail decisions to the hiring manager, and hard criteria are the easiest filter.
Job hopping is a red flag. Three companies in two years? HR is not betting on you "finding the right fit." They assume you will leave quickly again.
Industry mismatch drops your priority. Not a dealbreaker, but all else equal, the candidate with relevant industry experience goes to the top of the pile.
Education is a filter, not a bonus. A prestigious degree does not add points. A non-prestigious one subtracts them. Once you are past the resume screen, nobody cares where you went to school.
Knowing these rules is not meant to make you anxious. It is meant to explain why some applications vanish into a black hole. Sometimes it genuinely is not about you.
"Do you have any questions for me?" — this is the final test
At the end of every interview, the interviewer will ask this. It is not small talk.
When I ask this, what I am really looking for: genuine interest in the role, and whether you have thought about the challenges it involves.
Bad answer: "Nope, I think you covered everything." — Signals zero enthusiasm.
Mediocre answer: "What projects is the team working on right now?" — Passable but forgettable.
Good answer: "I noticed you have been exploring direction X recently. I worked on something similar at my last company and ran into problems A, B, and C. How has your team handled those?"
Good questions require homework. Spend 30 minutes before the interview reading the company's tech blog, product updates, or public talks. Prepare two to three genuinely thoughtful questions. The ROI on this is absurdly high.
Salary negotiation: timing matters more than the number
When do you talk about money? One rule: let them bring it up first.
If HR asks for your salary expectation during the phone screen, you can say: "I am more focused on the scope and growth potential of the role — I am happy to discuss compensation relative to the position's budget." Make them show their hand first.
If they insist, give a range. The bottom of the range is what you can genuinely accept. The top is 10-15% above your ideal. For example: "My expectation is in the 25k to 30k range, depending on the exact scope of the role."
Also: salary is not just monthly base pay. Annual bonus, equity, allowances, whether the probation period is fully paid, the base used for social insurance contributions — these can add up to significant differences. Confirm every line item when you get to the formal offer stage.
What to do after the interview
Send a thank-you email the same day — not a template. Reference a specific topic from the conversation. Something like: "I kept thinking about the system architecture problem we discussed, and I wanted to share an additional thought..." This makes you memorable.
If you have not heard back after a week, one polite follow-up is fine. Two follow-ups with no response, stop.
Getting rejected stings, but do not spiral. I have seen too many cases of "rejected by Company A, went to Company B, and Company B ended up being the better outcome." Luck plays a real role in interviews — the interviewer's mood that day, whether the role already had an internal candidate, whether your competition happened to be unusually strong. None of that is within your control.
FAQ
Should I wear a suit to an interview?
Depends on the industry. Finance and consulting — suit required. Tech — clean and neat is fine, a suit actually looks out of place. When in doubt, dress half a notch more formal than the company's daily dress code.
Should I include a photo on my resume?
In China, yes — a clean, professional headshot. No selfies, no casual photos. For pure tech roles abroad, it is unnecessary and sometimes discouraged due to anti-bias policies.
What if I get asked something I genuinely do not know?
Do not bluff. Say: "I am not deeply familiar with that, but my understanding is roughly X — I would want to research it properly." Honesty beats pretending. The interviewer is more senior than you; they can tell when you are making things up.
How do I explain an employment gap?
Tell the truth, but frame it differently. Instead of "I could not find a job," say: "I spent that period systematically studying X / building personal projects / handling a family matter — and now I am ready to jump back in."
Should I put my expected salary on my resume?
No. Salary is negotiated. Putting a number on your resume locks you into a corner before the conversation even starts.
How do I answer "what is your greatest weakness?"
Do not say "I am a perfectionist" — everyone sees through that. Name a real but non-fatal weakness, and explain what you are doing about it. Example: "I used to avoid public speaking and technical presentations. In the last six months I have volunteered to present at team meetings a few times, and I am getting more comfortable with it."