Editorial review: 9 October 2026
Build technical skill through a complete checked task
Technical skills are abilities you can apply to a defined task: writing a query, checking a calculation, using a design tool, diagnosing a device or explaining a program's behaviour. The relevant skill depends on the role. Listing popular software names does not show what you can do with them, and finishing one exercise does not establish readiness for every technical job.
Start with an actual role requirement and a small demonstration you can explain. This guide uses an original Python exercise to turn messy, invented workshop records into an ordered report. It includes the inputs, acceptance rules, complete program, expected output, an error case and a changed requirement. No real customer, employer or personal data is involved.
The official Python sorting guide explains that sorted() produces a new sorted list, supports key functions and preserves input order among equal keys. Those specific behaviours support the exercise below. The records and program are original, rather than copied documentation examples.
Keep preparing
Continue with Sarkari Resume Templates₹299 — coaching के एक महीने से काफ़ी सस्ता / far cheaper than a month of coachingChoose an observable requirement
The fictional task brief is: “Read supplied practice records, accept quantities written as nonnegative whole-number digit strings, reject other quantities, and report valid records from largest quantity to smallest. Preserve original order when quantities tie. Do not modify the input.”
That brief makes the skill testable. “Know Python” would leave the expected behaviour unclear. The requirement here combines input checking, numeric conversion, sorting and output explanation. It does not include database work, deployment, permissions or a claim that this program handles every kind of real-world data.
For this exercise, each supplied row is already a dictionary with a string name and string quantity. The quantities must contain only the ASCII characters 0–9 and must not be empty. Leading zeroes are permitted. Negative signs, spaces, decimals and other characters are rejected. These are explicit exercise rules, not a universal definition of valid quantities.
Inspect the complete input
records = [
{
"name": "Station C",
"quantity": "9",
},
{
"name": "Station A",
"quantity": "12",
},
{
"name": "Station B",
"quantity": "12",
},
{
"name": "Station D",
"quantity": "4.5",
},
{
"name": "Station E",
"quantity": "03",
},
{
"name": "Station F",
"quantity": "-2",
},
{
"name": "Station G",
"quantity": "",
},
]
Station A and Station B have equal numeric quantities and appear in that order. Station E's string 03 represents the permitted integer 3. D, F and G fail different parts of the supplied rule: decimal point, negative sign and empty value.
Before programming, write down the expected valid order: A, B, C, E. The numeric quantities should be 12, 12, 9 and 3. Rejected rows should be reported in their original order: D, F, G. Predicting these outputs gives you a check that is independent of merely reading your code.
Explain why sorting the strings fails
A tempting shortcut is sorting the original quantity strings in descending order. That does not implement numeric quantity order. With valid strings 9, 12, 12 and 03, descending string order places 9 before 12 because string comparison compares characters.
The requested report instead needs numeric conversion after validation. Keeping 03 as a display string would also obscure whether it was interpreted as three. Separate the source representation from the parsed value and use the parsed integer as the sort key.
Validation should happen before conversion so that a known-invalid decimal does not cause an unhandled conversion error halfway through the report. The rejection record should say which input was rejected; silently dropping it could make an incomplete report look complete.
Write the complete original program
from pprint import pprint
def quantity_report(records):
valid = []
rejected = []
for row in records:
name = row["name"]
text = row["quantity"]
digits = "0123456789"
bad = any(
c not in digits
for c in text
)
if not text or bad:
rejected.append(
(name, text)
)
continue
valid.append(
(name, int(text))
)
ordered = sorted(
valid,
key=lambda item: item[1],
reverse=True,
)
return ordered, rejected
ordered, rejected = (
quantity_report(records)
)
pprint(ordered, width=28)
pprint(rejected, width=28)
The loop builds new lists instead of editing the input dictionaries. The empty-string check is necessary because a check over zero characters would not itself find an invalid character. The explicit character membership rule implements the supplied ASCII-only requirement.
The key function selects the numeric quantity. reverse=True gives descending order. Python's stable sorting keeps A before B because their keys are equal and A was appended first. The program returns both the valid report and the rejected rows, allowing the caller to inspect each outcome.
This program assumes the already-supplied dictionary and string structure. It does not validate missing keys, non-string values or untrusted file sizes. State those boundaries instead of presenting a short learning exercise as a complete production ingestion tool.
Check the output and account for every row
The pprint calls format the output over short lines. The expected printed output is:
[('Station A', 12),
('Station B', 12),
('Station C', 9),
('Station E', 3)]
[('Station D', '4.5'),
('Station F', '-2'),
('Station G', '')]
Four accepted rows plus three rejected rows account for all seven supplied records. The accepted quantities total 12 + 12 + 9 + 3 = 36. This is a check on these invented values, not an inventory certification.
| Acceptance condition | Checked result |
|---|---|
| Numeric descending order | 12, 12, 9, 3 |
| Stable tie order | Station A before Station B |
| Leading zero permitted | 03 converted to 3 |
| Invalid quantities visible | D, F and G in rejection record |
| No lost rows | Four accepted plus three rejected equals seven |
| Input preserved | Original strings and dictionaries remain unchanged |
A correct order alone is insufficient. The report could still be wrong if it hid rejected rows or altered the source. Check each acceptance condition separately.
Apply a changed requirement deliberately
For a new, separate task, suppose the owner now permits surrounding whitespace but keeps all other rules. The row {"name": "Station H", "quantity": " 8 "} was invalid under the original brief. Under the changed brief, strip surrounding whitespace before checking its characters and converting it.
The revised loop would keep both values:
original = row["quantity"]
text = original.strip()
bad = any(
c not in "0123456789"
for c in text
)
if not text or bad:
rejected.append(
(row["name"], original)
)
continue
valid.append(
(row["name"], int(text))
)
This variation accepts H as 8, placing it between C's 9 and E's 3 if appended to the original input. It still rejects 4.5, -2 and an empty or whitespace-only string. Preserve the original rejected text so the record remains explainable.
Do not introduce this normalization into the original answer silently. A changed rule is a changed requirement, and your demonstration should identify which version it implements. The whitespace variation is not an actual employer change or a claim that all files should be normalized this way.
Describe the skill honestly in a portfolio or interview
A precise practice description is: “Built an original seven-row Python exercise that validates ASCII whole-number strings, reports rejected rows, sorts parsed quantities stably in descending order and preserves the source.” That identifies the work and its limits.
Avoid replacing it with “Built an enterprise data platform” or “Improved company efficiency by 40%.” Neither outcome exists in this record. If you publish your practice code, include the invented inputs, requirements and expected outputs so someone else can reproduce the check.
For explaining your own contribution, see interview communication. For a finite hardware-oriented practice set, see embedded-systems interview questions. These are different learning tasks, rather than evidence that one Python report proves every technical capability.
Plan the next practice from the remaining gap
Once this task is checked, choose one new requirement: missing-key handling, reading a small practice file, or producing an explicitly defined report format. Write the expected behaviour before extending the program. Keep an error case alongside the successful case.
Choose learning resources for that gap and check their applicable version. Course completion, profile views and interview invitations are different observations from task correctness. Track the thing you are actually learning rather than treating a hiring outcome as a technical test score.
Frequently asked questions
Does every technical role require programming? No. The relevant task depends on the role. This guide demonstrates one programming skill, not a universal curriculum.
Why not sort the strings directly? The brief requires numeric quantity order, and the representation 9 sorts differently from the numeric relation between 9 and 12.
Does stable sorting mean equal records disappear? No. A and B are both retained; their relative order is preserved.
Does passing this exercise prove job readiness? It demonstrates the defined behaviour on the supplied cases. Other role requirements and larger or different inputs need separate evidence.