If you are an Oleh Hadash from Russia, the hardest part of writing a CV for Israeli high tech is usually not the English. It is the structure.
A literal translation of an old resume often keeps the original titles, sequence, and context, which can make a strong background feel scattered. Recruiters and ATS both need a faster read: role, stack, scope, and evidence that is easy to follow.
The better approach is to rebuild the CV around the role you want in Israel, keep one truthful master profile, and then tailor only what is supported by the vacancy and your own history.
Why a literal translation is not enough
A straight translation usually preserves the logic of the old document, and that logic may not match the job you want now. If your previous CV was built for a different market, different title conventions, or different hiring expectations, translating it word for word can leave the reader with a fragmented story instead of a role-shaped one.
For a recruiter, the first question is simple: can I see what this person does and whether it matches the vacancy? For an ATS, the first challenge is equally simple: can the system identify the role, the specialty, and the chronology without guessing? Clarity is the goal, not a promise that any format will “beat” the system. ATS behavior varies by employer and vendor.
That is why the opening of the CV matters so much. Put the role you want, the stack or specialty that fits it, and the most relevant outcomes near the top. Keep chronology readable, but do not let it dominate the page if it buries the answer to the main question.
This is especially important for Olim Hadashim from Russia whose history may include Russian job titles, short-term contracts, startup projects, and freelance work across different countries. The CV needs to make that background legible at a glance without erasing the real sequence of work. What a recruiter sees before they read your bullet points helps explain why the first scan is so decisive.
If you want a practical rule, use the vacancy as a signal for what matters, but do not copy the vacancy into the CV. A job ad tells you what the role requires; it does not give you license to claim unsupported experience.
Build one truthful master story from scattered experience
The cleanest way to handle contracts, startup work, and mixed-language projects is to collect everything into one source profile first. That master profile should hold the full history, even when you later trim or reorder it for a specific role. The point is to preserve truth before you optimize for scanability.
A useful way to think about the content is in three buckets: supported, adjacent, and unsupported. Supported means you can defend it with actual responsibilities, tools, decisions, or outcomes. Adjacent means it is related and may help, but it is not the core of the role. Unsupported means it sounds attractive but cannot be defended yet, so it should stay out of the public CV.
Take a backend engineer who has worked as a contractor, a startup employee, and a freelance consultant. If those roles are translated literally and left in source order, the recruiter may see three unrelated titles. If they are consolidated into one coherent story with stack, scope, and outcomes, the pattern becomes much easier to read: the person builds backend systems, works across environments, and has delivered concrete work in different settings.
The same logic applies to a product designer who has mixed-language documents and only partial project records. In that case, it is better to keep the exact history in the source profile and present only what can be defended in interview. Clean-looking claims that cannot be supported are worse than slightly less polished wording, because they make the application fragile.
This is the main distinction newcomers often miss. The goal is not to hide foreign experience; it is to translate it into a local story that still matches the facts. A local-recognizable role label can help, but only if the underlying evidence is real.
For general guidance on matching the CV to the role and using job-relevant evidence, the U.S. Department of Labor’s Tips for Writing a Federal Resume and the NACE resume guide are both useful reminders that tailoring should stay tied to what you can prove.
Use CVZilla to keep the source profile and tailor from it
CVZilla’s Profile area is the place to keep that master story. It is the reusable source of truth for experience, projects, skills, tools, languages, layout, template, font, and role-variation controls. If you are importing an old CV, the create-from-CV flow can upload PDF, DOC, or DOCX, extract the content, and translate non-English material into English before opening Profile.
That matters because the source profile is where you decide what is factual, what is adjacent, and what still needs support. Once the master is clean, Job Tailoring can start from a real vacancy instead of from a generic template. You can begin from a job link or from pasted job description text, then review the tailored result and correct anything that overreaches.
This workflow is especially helpful when your past work spans different countries or contract types. Instead of rewriting your history from scratch for every application, you maintain one truthful baseline and shape it to the role you actually want. That saves time and reduces the chance of forgetting an important project or overstating a weak one. It also keeps the public CV closer to the facts in the master profile.
The product pages show the same logic in action. The Profile area is where the source CV lives, and Job Tailoring is where you adapt it to the vacancy. If you want a deeper walkthrough of starting from the job itself, see The vacancy is the brief: start tailoring from the real job.
One important caveat: the tailored version is not a finished truth by default. You still need to review it. The safest habit is to check whether every skill, tool, and outcome in the final draft can be traced back to the master profile or to clearly supported evidence in your history.
Check the final scan path before you send
Before you submit, read the CV the way a busy recruiter would. The best scan path is obvious: role first, relevant experience second, skills and tools next, then the rest in a chronology that is easy to follow. If the reader has to rebuild the story in their head, the structure is doing too much work.
Cut extra context that does not help the role decision. Remove untranslated jargon, overly long explanations of Russian titles, and copied vacancy phrases that you cannot support. Clean wording is better than keyword stuffing because it helps both people and automated systems understand the same story without creating trust problems.
The final review should also catch the difference between a local adaptation and an unsupported rewrite. If a metric, responsibility, or tool is not backed by real experience, leave it out. That is the safest rule for newcomers with limited documentation, and it is more sustainable than trying to make every CV sound maximally complete.
In the tailored editor, you can compare the draft against the vacancy context, inspect the result, and preview the rendered CV before export. The What a recruiter sees before they read your bullet points article is a good companion if you want to sharpen that first impression, and The vacancy is the brief: start tailoring from the real job is the right mental model for keeping the edit grounded in the actual job.
The preview stage matters because layout problems are easiest to fix before you send anything. Use it to check spacing, section order, and readability, then export only when the page reads smoothly from top to bottom. That does not guarantee an interview, but it does make the application easier to scan, easier to defend, and easier to tailor again next time.
For Olim Hadashim from Russia, the best Israeli high-tech CV is usually not a translated archive of past jobs. It is a local, role-shaped document built from one truthful source profile.
Start with the master profile, keep only supported evidence in the public version, and tailor to the real vacancy instead of to a generic idea of what high tech wants. If you do that, the story becomes easier to read and easier to defend.
Open Profile to build that source version, then move into tailoring when you have a real job in hand.
