Portfolio vs CV for PLC Jobs in South Africa

A portfolio and a CV do different jobs when you apply for PLC work in South Africa. Your CV summarises your education, employment and relevant experience. A portfolio gives a reviewer selected examples they can inspect and discuss. Neither guarantees an interview, an offer or a particular salary.

The useful question is not which document makes the other unnecessary. It is whether the two tell a consistent, supportable story about your background. A clear project can help explain a skill, while the vacancy's qualification and experience requirements still apply.

This guide shows how to organise both documents, describe simulator work honestly and prepare a reproducible project example. The sample project and CV wording are fictional teaching examples. They are not customer stories or measured South African recruitment outcomes.

Start with the actual PLC job requirements

Read the vacancy before choosing projects. Separate mandatory requirements, preferred experience, practical responsibilities and application instructions. Record anything that needs clarification. Do not assume that a portfolio overrides a required qualification, licence, location arrangement or level of industrial experience.

For example, a role asking for commissioning experience raises different evidence questions from a training opportunity asking for basic logic knowledge. A simulated exercise can demonstrate your reasoning within its stated environment. It cannot establish that you have commissioned a physical installation under site procedures.

When comparing opportunities in Gauteng, the Western Cape, KwaZulu-Natal or another province, use the actual employer's description. Do not invent different hiring rules for each city. Location, travel and shift expectations should be answered from the opportunity and your circumstances rather than from a generic regional stereotype.

Make a small requirement-to-evidence table. Include a gap column so that unknown or unmet requirements remain visible. A list of platform names without an explanation of where and how you used them leaves important questions unanswered.

Requirement in an example vacancy	Evidence you might actually hold	Honest limitation
Basic ladder logic	A documented virtual exercise	No production commissioning claimed
A named vendor environment	A project saved in the stated software version	Scope limited to the tools actually used
Fault diagnosis	A trace showing a reproduced defect and correction	One scenario does not cover all faults
Relevant qualification	Your awarded qualification and supporting record	A course attendance record may have a different status
Team experience	Your documented contribution to a shared task	Do not claim colleagues' work as your own

If you are still comparing learning routes, the PLC course requirements guide separates admission, prior knowledge and completion requirements. That distinction also helps you describe training accurately on an application.

02

What belongs on a PLC technician or programmer CV?

Use the CV to make your relevant background easy to find. Include accurate role titles, employment dates, qualifications, courses and a concise account of your responsibilities. Follow the requested application format and document limits where the employer supplies them.

A recent graduate and an experienced technician may need different amounts of detail. There is no evidence here that one universal page count decides every South African controls application. Prioritise relevant information and remove repetition, while preserving enough context to understand what you actually did.

Distinguish production work, supervised training, personal projects and introductory exposure. Instead of listing five PLC brands as an undifferentiated skill set, describe the tasks you performed with each relevant environment. Reading a manual, completing a simulation and maintaining installed equipment are different experiences.

Write claims that have an identifiable basis

A useful bullet connects your action to a defined task and a result you can support. For a fictional learner, this could be: “Built a virtual count display, documented reset priority and checked ten input steps against expected results.” That says more than “expert in PLC troubleshooting” without pretending the work happened on a factory line.

For an actual workplace achievement, use numbers only when records support them and you are permitted to disclose them. If several people delivered an outcome, state your contribution. “Assisted with testing” and “designed and approved the whole system” should not be used interchangeably.

Avoid inventing downtime savings, project budgets or efficiency percentages to make a bullet look stronger. If you cannot establish a result, describe the responsibility and evidence you do have. A technically precise account is more useful than a large unsupported number.

Add a descriptive portfolio reference near the relevant project or contact section. A label such as “Virtual counter project: specification and test trace” explains the destination better than “click here.” Check that the link works in the exported document, not only in your editing application.

What belongs in the portfolio?

A portfolio is a selected evidence collection, not necessarily a public website or a large source repository. It can contain a short project summary, a readable logic export, diagrams, test records and source files where sharing is appropriate. Choose a format the reviewer can actually access.

Begin with one project you can explain thoroughly. Add another when it demonstrates a meaningfully different skill or a relevant extension. Three is not a mandatory project count, and five similar examples are not automatically better than a smaller, well-documented selection.

For each project, state the problem, environment, requirements, your contribution, test method, results and limitations. Include the revision or version that the results describe. A screenshot of a successful output without its inputs or requirement gives the reviewer much less to inspect.

The portfolio should make it possible to answer a concrete question: what does this example show? If the answer is only that a screen looks attractive, consider adding the behaviour specification and a trace that explains how the displayed values are produced.

03

Course exercises can be included with proper attribution

A guided exercise can show learning when you identify its origin and your contribution. Do not present supplied code as an original design. Explain what the course provided, what you implemented or changed, and which results you independently checked.

For example, a course may supply a basic counter. Your extension might define what happens when reset and a new input arrive together, then test that priority. The extension is a specific contribution, while the starting exercise remains attributed to its source.

The same principle applies to collaboration and AI assistance. Identify assistance that materially shaped the work, verify the result and be prepared to explain it. A generated explanation that you cannot connect to the program's behaviour is weak evidence of your own understanding.

Give every project a readable starting point

A README or short introductory PDF should let someone understand the project before opening specialist software. State what it does, why you built it, how to inspect it and what files or tools are required. Keep detailed traces and longer reference material in clearly linked sections.

GitHub's README guidance explains the role of this introductory document and how it is presented to repository visitors. A similar starting page is useful even when you choose a PDF folder rather than GitHub.

Use descriptive filenames and headings. A reviewer should be able to distinguish the specification from a test result and the current version from an older attempt. Avoid a folder containing several files called final, final-new and final-really-new with no explanation of which one was tested.

For vendor-specific work, record the software version and relevant target details. Consult documentation for that environment rather than assuming instructions, data types and project formats transfer unchanged. The Siemens S7-1200/1500 programming guideline, version 1.6 is one dated example of vendor guidance covering program structure, symbols and comments; check current documentation for the version you use.

Comments should explain decisions

A comment that repeats a tag name adds little. A comment explaining why reset has priority, what range is valid or which assumption a calculation uses is more helpful. Keep comments aligned with the implemented revision so that a later change does not leave a misleading explanation behind.

Do not equate extensive comments with verified correctness. Clear documentation and correct behaviour are related review tasks, but one does not prove the other. Link important decisions to the requirement and test that exercises them.

Worked portfolio example: a virtual event counter

This fictional exercise counts observed rising edges of a Boolean input. It is a small software model for learning and documentation, not a physical production counter or an equipment-control design. Its purpose is to show how a portfolio can connect a requirement to a reproducible trace.

Let Count begin at zero, with a maximum of three. At each supplied step, calculate whether Pulse changed from false at the preceding step to true now. Reset takes priority over counting. Otherwise, a rising edge increases Count by one, but Count remains at three when already at its maximum.

Update the previous Pulse value at every step, including steps where Reset is true. This matters: a pulse observed while resetting must not become a new edge merely because Reset is released while Pulse stays high. Before the example trace starts, Pulse is false and the stored previous value is false.

For an actual program startup with Pulse already high, this exercise's stated startup rule is to initialise the stored previous value from that current input. That avoids treating a held input as a newly observed edge at startup. State your chosen startup behaviour explicitly; do not assume every counter instruction implements this wrapper automatically.

04

Write expected results before running the example

The trace below uses one evaluation per row. True and false are Boolean values, not electrical voltage specifications. No pulse duration, scan frequency or physical detection guarantee is established by this table.

Step	Pulse	Reset	Expected Count after evaluation	Reason
1	false	false	0	Initial low input
2	true	false	1	First observed rising edge
3	true	false	1	Held high, no new edge
4	false	false	1	Falling edge does not count
5	true	true	0	Reset wins over the rising edge
6	true	false	0	Reset released, Pulse still held high
7	false	false	0	Low input prepares a later edge
8	true	false	1	New rising edge
9	false	false	1	Count retained
10	true	false	2	Another rising edge

This sequence deliberately contains a conflict and a held input. A demonstration that repeatedly toggles Pulse with Reset always false would miss the important reset-priority case. Explain why each selected test exists instead of presenting a long table without a purpose.

Add separate boundary cases with Count starting at three. A new rising edge should leave it at three; Reset should return it to zero. The range requirement is zero through three inclusive. A state outside that range is outside this model's declared starting conditions and needs separately specified recovery behaviour before being claimed as supported.

Show a failure and the correction without rewriting history

Suppose revision A updates the previous Pulse value only when Reset is false. It will still clear Count at step 5, but it fails to remember that Pulse is now high. At step 6, it incorrectly treats that held input as a fresh edge and produces one instead of zero.

Revision B updates the previous input every step. The same trace then gives the expected zero at step 6. Keep revision A's failed record labelled as historical and attach the passing result to revision B. A corrected source file does not retroactively make the original test pass.

This example gives you a focused explanation for an interview: the defect came from inconsistent edge memory during reset, and the correction preserved observation history while resetting the count. It does not require claiming that a larger industrial installation was fault tolerant or fully validated.

Explain the limits of the evidence

The ten-step trace demonstrates selected behaviours, not every possible history. You can strengthen the model check by evaluating all valid single-step combinations: four starting counts, two previous input values, two current input values and two reset values. That is 32 combinations under the declared Boolean and range assumptions.

Even complete coverage of those combinations would only support this small transition rule. It would not establish sensor response, pulse capture between scans, hardware suitability or commissioning competence. The PLC counter reference provides further context for distinguishing a learning model from a particular instruction's behaviour.

05

Package evidence so it can be reviewed

Include a short result summary alongside the trace. State the requirement revision, program revision, starting conditions, expected result, observed result and outcome. If a test has not been run, label it planned or pending rather than filling the observed column with the expected answer.

Use screenshots to support the record, with enough context to identify the relevant state. Do not depend on tiny text inside an image as the only explanation. A text table can make the inputs and results accessible even when a reviewer cannot open the original engineering tool.

If you share a native project file, explain the required software and version. Offer a readable summary when practical so the reviewer can decide whether to investigate further. Do not imply a PDF export can be executed or that a screenshot proves the uploaded archive matches the tested version.

For a broader choice of exercises, use the PLC programming examples guide. Choose a project that fits the skill you need to demonstrate rather than adding unrelated examples solely to increase the page count of your portfolio.

Decide what you can share before publishing

Build fictional or personal examples when you do not have permission to share workplace material. Do not upload a customer project just because you wrote part of it. A private repository is still a form of sharing with its authorised viewers, and changing a project name alone does not establish that its contents are suitable to disclose.

Review files, images, logs and embedded details before sharing. Remove material you are not authorised to distribute, including access credentials and identifying operational information. Where permission is uncertain, use a new educational example that demonstrates the same general concept without copying the original installation.

GitHub's repository visibility documentation explains that public code can be viewed and forked, and that existing public forks are not made private when the original repository becomes private. Decide the appropriate audience before publication rather than relying on a later visibility change to recall distributed copies.

A controlled private review or an approved redacted summary can be appropriate where public sharing is unsuitable. Make the access arrangement clear and check that it works for the intended reviewer. There is no universal requirement here to publish everything openly.

Rehearse an explanation that matches your evidence

Prepare to explain the problem, one important design decision, one test and one limitation. In the counter example, you could describe reset priority, show the held-input failure and identify why the correction works. This demonstrates a connected explanation rather than memorisation of a polished project description.

If asked about a behaviour you have not tested, say so and describe how you would investigate it. Do not improvise a successful result. A clear distinction between observation and hypothesis helps keep the technical discussion grounded.

Use PLC program testing resources when planning small practice cases. The PLC curriculum overview can help identify supporting topics. Check current access and environment capabilities for the work you intend to do.

Describe results from that learning environment as such. They do not automatically demonstrate use of a vendor-native engineering package, award an industrial qualification or guarantee an employment outcome. Your portfolio should preserve those distinctions rather than conceal them behind brand names.

06

Questions about PLC portfolios and CVs in South Africa

Do I need GitHub to apply for PLC technician jobs?

Follow the application's requirements. A readable PDF, permitted source archive or accessible project page may be suitable, depending on the review process. GitHub is one possible hosting format, not a universal admission ticket to PLC employment.

Can a beginner include simulator projects on a CV?

Yes, describe them as learning projects and state your contribution and environment. Do not put them under employment experience in a way that implies production responsibility. A small documented example can show specific learning without claiming a level of experience you have not gained.

Should I include course certificates in the portfolio?

Relevant training can be listed on the CV, with supporting records supplied as requested. A portfolio can also reference that learning context. Keep the certificate's actual title and status clear, and distinguish completion or attendance from any separately assessed professional credential.

How many projects should I build before applying?

There is no universal number established here. Compare your evidence with the role and choose examples you can explain. Do not delay an otherwise appropriate application solely to reach an arbitrary project count, and do not claim that a single project satisfies every requirement.

Will a portfolio increase my salary or double interview success?

This guide has no verified South African hiring dataset supporting those claims. A portfolio can make selected work easier to inspect, but an outcome depends on the opportunity and assessment. Track your own applications without treating a small personal sample as proof of a universal causal effect.

What should I improve first if my project is hard to explain?

Start with its requirement and one reproducible test. Identify the inputs, expected behaviour, actual result and revision. Then revise the summary and comments to match. Improving that connection is more useful than adding decorative screenshots to a project whose behaviour remains unclear.