Fundamental Information Technology Engineer Examination common mistakes
Fundamental Information Technology Engineer Examination · Understand the traps and how to avoid them.
In 科目A, reading a four-choice question once and answering from the first option that 'looks right', without eliminating the other three - especially on 用語 (terminology) items where two options differ by one word.
科目A gives 60 questions in 90 minutes, i.e. 90 seconds per question. Candidates feel the clock and treat recognition as knowledge; the exam deliberately includes near-miss distractors (e.g. リピータ vs ブリッジ vs ルータ, or 静的テスト vs 動的テスト) that punish pattern-matching.
What to do instead
Adopt a fixed routine per question: read the stem to the end, mark the key constraint (which layer, which phase, which cost is being minimised), then strike out options with a stated reason. If you cannot state why an option is wrong, flag the question and move on. Practise 20-question sets at 30 minutes so the routine becomes automatic rather than a time sink.
Memorising 科目A facts as isolated trivia (e.g. 'RAID5 tolerates one disk failure') without being able to apply them to a short scenario, so scenario questions in the same domain are answered from the memorised sentence rather than from the stated conditions.
The syllabus is broad and candidates revise with flashcard apps that reward recall. Many 科目A items are one-sentence scenarios with a changed condition (RAID6, or RAID5 with a hot spare) where the memorised sentence gives the wrong answer.
What to do instead
For every fact, write one line of 'when it applies / when it does not'. Convert each flashcard into a two-line mini-scenario and answer that instead. Before answering any scenario item, underline the numbers and constraints in the stem and re-derive the answer from them rather than recalling a label.
Skipping or under-practising 科目B pseudo-code tracing: candidates read the code, guess the output, and do not simulate variable values line by line - particularly on nested loops, recursion, and array-index boundary conditions.
科目B is 20 questions in 100 minutes, so 5 minutes per question, and the pseudo-code is written in the exam's own notation (宣言, 添字 starting at 1, 手続き/関数). Candidates who are used to a real language silently import that language's semantics (0-based arrays, short-circuit evaluation, integer division) and mis-trace.
What to do instead
Trace on paper with a table of variable values per iteration; never trace in your head. Explicitly note the array lower bound given in the 宣言 and the loop's termination condition. Practise until you can trace a 15-line double loop with an accumulator in under 4 minutes, and always verify by testing the boundary case (first and last iteration).
Treating 科目B アルゴリズム and プログラミング questions as the whole of 科目B and neglecting the 情報セキュリティ (security) questions, which are a guaranteed, heavily weighted block.
Algorithm tracing feels like the hardest part, so it absorbs all revision time. The security questions, however, are scenario-based (incident response, 標的型攻撃, アクセス制御, 暗号の用途) and reward structured reasoning about threats and countermeasures rather than coding drill.
What to do instead
Split 科目B practice roughly in proportion to the published question counts, and do at least one timed security set per week. For each scenario, write the asset, the threat, the vulnerability, and the control before looking at the options; this also makes the distractor options obviously wrong.
In 科目B アルゴリズム questions, answering with the value the code 'should' produce for a sensible input instead of the value it produces for the input actually given, including cases where the given input triggers an early exit or an unhandled condition.
Candidates pattern-match to textbook algorithms (binary search, bubble sort) and assume the standard behaviour. Exam pseudo-code often contains a deliberate variation: a swapped comparison, a loop that stops one short, or a condition that never becomes true.
What to do instead
Never name the algorithm until after tracing. Trace the given input literally, including the branch not taken. If the trace produces something odd, re-check the comparison operators and the loop bounds before concluding the question is wrong - the question is not wrong.
Spending too long on a small number of hard 科目A questions and running out of time for the final 15–20 questions, which are often easier.
The scoring is per question, so a hard question is worth exactly the same as an easy one, but candidates feel compelled to finish what they started. 科目A's 90 seconds per question leaves no slack for a five-minute puzzle.
What to do instead
Set a hard rule: if no answer is in sight after 90 seconds, mark it, put a provisional answer, and move on. Reserve the last 10 minutes for flagged items. In practice runs, record time per question and review the distribution - most candidates find their overruns cluster in 計算 (calculation) items.
Answering 科目A calculation questions (稼働率, 伝送時間, 期待値, 論理演算, 基数変換) without writing the units, and mixing bits and bytes, or 秒 and ミリ秒, in the final step.
These are short items and candidates do them mentally. Unit conversions are exactly where the exam sets traps (bps vs B/s, 10^3 vs 2^10, 百分率 vs 小数), and a mental calculation hides the error until the answer does not match any option - at which point time is lost re-deriving.
What to do instead
Write the formula, substitute with units attached, and cancel units before computing. Convert everything to base units (bit, second, byte) at the start. If your answer is not among the options, re-check the unit conversion first, not the formula.
In 科目B, writing no intermediate notes for トレース表 and then being unable to re-check an answer, so a single arithmetic slip in the middle of a trace silently corrupts the final answer.
The pseudo-code is unfamiliar, so working memory is fully occupied by syntax. Candidates believe they will remember the trace, but under exam pressure they cannot reconstruct which iteration went wrong, and there is no partial credit to fall back on.
What to do instead
Use a fixed trace table layout (iteration number, each variable, condition result) on every question, even easy ones, so checking is a matter of re-reading one column. When the final answer is among the options, verify by re-running only the last two iterations.
Revising 科目A and 科目B as separate exams with separate schedules, so 科目A knowledge (e.g. データ構造, データベースの正規化, ネットワーク層) is never connected to the 科目B scenarios that depend on it.
The two papers are sat on the same day and the syllabus overlaps heavily, but study plans often allocate 'theory weeks' and 'practice weeks'. Candidates then fail to recognise that a 科目B scenario about transaction isolation is asking for the 科目A fact they already know.
What to do instead
Study by topic, not by paper: for each syllabus topic, do the 科目A items and the corresponding 科目B scenario in the same session. Keep one notebook per topic where the left page is the 科目A fact and the right page is the 科目B application.
Not simulating full exam conditions before the test date: practising untimed, with notes, in short bursts, and never sitting a 60-question 90-minute paper followed by a 20-question 100-minute paper in one day.
Both papers are long and the second follows the first, so fatigue and attention management are part of the assessment. Untimed practice removes the very constraint that causes most lost marks, and candidates discover their stamina limit only on exam day.
What to do instead
Do at least three full dress rehearsals in the final month: same order, same durations, no notes, single sitting, with a break of the same length as the real one. Afterwards, review errors by cause (knowledge gap, misread stem, time pressure, calculation slip) and target the largest category, not the most recent mistake.