Software Engineering: Beyond the Buzzwords

What does Brooks's law say about adding people to a late software project?

It makes the project later still

It speeds it up roughly in proportion

It speeds it up only with microservices

It mainly increases technical debt

or press Enter ⏎

That's right!

Right. New people need ramp-up time, and communication paths grow quickly, so a late project slips further.

Not quite

Brooks's law says it makes a late project later: onboarding costs and communication overhead outweigh the extra hands at first.

To get feedback you first need to answer the question above.

or press Enter ⏎

Under semantic versioning, which version change signals a breaking API change?

2.3.1 to 2.4.0

2.3.1 to 2.3.2

2.3.1 to 3.0.0

2.3.1 to 2.3.1-rc1

or press Enter ⏎

That's right!

Correct. In MAJOR.MINOR.PATCH, only a major bump announces incompatible API changes.

Not quite

The answer is 2.3.1 to 3.0.0. Minor bumps add backward-compatible features and patch bumps fix bugs; only a major bump may break the API.

To get feedback you first need to answer the question above.

or press Enter ⏎

Which HTTP method is defined as idempotent but not safe?

GET

POST

PATCH

PUT

or press Enter ⏎

That's right!

Right. PUT changes state, so it isn't safe, but repeating the same PUT leaves the same result, so it's idempotent.

Not quite

The answer is PUT. Idempotent doesn't mean side-effect free: PUT modifies data, yet repeating it has the same effect as doing it once. GET is safe; POST and PATCH aren't guaranteed idempotent.

To get feedback you first need to answer the question above.

or press Enter ⏎

A test suite reaches 100% line coverage. What does that guarantee?

Every line ran during the tests

Every branch combination was tested

The code contains no logic errors

Every edge case has an assertion

or press Enter ⏎

That's right!

Correct. Line coverage only shows each line executed; it says nothing about whether the results were checked or all paths tried.

Not quite

It only guarantees that every line ran. Untested branch combinations, missing assertions and wrong logic can all survive 100% line coverage.

To get feedback you first need to answer the question above.

or press Enter ⏎

What best distinguishes continuous delivery from continuous deployment?

Delivery skips automated testing

In delivery, release to production is a manual decision

Delivery requires fixed release plans

Deployment needs no build pipeline

or press Enter ⏎

That's right!

Right. Continuous delivery keeps every change releasable; continuous deployment goes further and ships each passing change automatically.

Not quite

In continuous delivery, release to production is a manual decision. Every change is kept deployable, but only continuous deployment pushes it to production automatically.

To get feedback you first need to answer the question above.

or press Enter ⏎

What is the key difference between a mock and a stub in testing?

A stub verifies calls; a mock returns data

They are two names for one thing

A mock is used only in integration tests

A mock verifies the calls made to it

or press Enter ⏎

That's right!

Correct. Stubs supply canned answers; mocks hold expectations and check how they were called.

Not quite

A mock verifies the calls made to it, testing behavior, while a stub just returns canned data so the test can run, testing state.

To get feedback you first need to answer the question above.

or press Enter ⏎

An algorithm is O(n) and another O(n²). What can you conclude for n = 100?

The O(n) one is always faster

Nothing certain about which is faster

The O(n²) one takes 100 times longer

The O(n) one uses less memory

or press Enter ⏎

That's right!

Right. Big O describes growth rate as n increases and hides constant factors, so at a fixed small n either could win.

Not quite

Nothing certain can be concluded. Big O ignores constants and lower-order terms; it describes how cost grows, not actual time at a given n.

To get feedback you first need to answer the question above.

or press Enter ⏎

According to the CAP theorem, what must a distributed system give up during a network partition?

Partition tolerance or durability

Any two of the three properties

Either consistency or availability

Latency guarantees under heavy load

or press Enter ⏎

That's right!

Correct. Partitions can't be wished away, so when one occurs a system must choose between staying consistent and staying available.

Not quite

It must give up either consistency or availability. "Pick two of three" is misleading: the trade-off only bites during a partition.

To get feedback you first need to answer the question above.

or press Enter ⏎

What happens to commit hashes when you rebase a branch onto a new base?

They stay the same

Only the newest commit changes

They change only if conflicts occur

The rebased commits get new hashes

or press Enter ⏎

That's right!

Right. A commit's hash depends on its parent, so replaying commits on a new base creates new commits.

Not quite

The rebased commits get new hashes, because each hash covers the parent commit. That's why rebasing shared branches causes trouble.

To get feedback you first need to answer the question above.

or press Enter ⏎

A single-core CPU runs two tasks by switching between them. This is an example of what?

Concurrency without parallelism

Parallelism without concurrency

Both concurrency and parallelism

Neither concurrency nor parallelism

or press Enter ⏎

That's right!

Correct. The tasks make progress in overlapping periods (concurrency) but never execute at the same instant (parallelism).

Not quite

It's concurrency without parallelism. Concurrency is structuring work to overlap in time; parallelism needs simultaneous execution, e.g. on multiple cores.

To get feedback you first need to answer the question above.

or press Enter ⏎

Perfect! Every answer right!

10 of 10 right

Challenge your fellow developers to take the quiz!

Your nickname, if you want

Without one, it says “A friend.”

See your answers · all right

Question 1:
What does Brooks's law say about adding people to a late software project?
It makes the project later still
It speeds it up roughly in proportion
It speeds it up only with microservices
It mainly increases technical debt
Right. New people need ramp-up time, and communication paths grow quickly, so a late project slips further.
Brooks's law says it makes a late project later: onboarding costs and communication overhead outweigh the extra hands at first.
Question 2:
Under semantic versioning, which version change signals a breaking API change?
2.3.1 to 2.4.0
2.3.1 to 2.3.2
2.3.1 to 3.0.0
2.3.1 to 2.3.1-rc1
Correct. In MAJOR.MINOR.PATCH, only a major bump announces incompatible API changes.
The answer is 2.3.1 to 3.0.0. Minor bumps add backward-compatible features and patch bumps fix bugs; only a major bump may break the API.
Question 3:
Which HTTP method is defined as idempotent but not safe?
GET
POST
PATCH
PUT
Right. PUT changes state, so it isn't safe, but repeating the same PUT leaves the same result, so it's idempotent.
The answer is PUT. Idempotent doesn't mean side-effect free: PUT modifies data, yet repeating it has the same effect as doing it once. GET is safe; POST and PATCH aren't guaranteed idempotent.
Question 4:
A test suite reaches 100% line coverage. What does that guarantee?
Every line ran during the tests
Every branch combination was tested
The code contains no logic errors
Every edge case has an assertion
Correct. Line coverage only shows each line executed; it says nothing about whether the results were checked or all paths tried.
It only guarantees that every line ran. Untested branch combinations, missing assertions and wrong logic can all survive 100% line coverage.
Question 5:
What best distinguishes continuous delivery from continuous deployment?
Delivery skips automated testing
In delivery, release to production is a manual decision
Delivery requires fixed release plans
Deployment needs no build pipeline
Right. Continuous delivery keeps every change releasable; continuous deployment goes further and ships each passing change automatically.
In continuous delivery, release to production is a manual decision. Every change is kept deployable, but only continuous deployment pushes it to production automatically.
Question 6:
What is the key difference between a mock and a stub in testing?
A stub verifies calls; a mock returns data
They are two names for one thing
A mock is used only in integration tests
A mock verifies the calls made to it
Correct. Stubs supply canned answers; mocks hold expectations and check how they were called.
A mock verifies the calls made to it, testing behavior, while a stub just returns canned data so the test can run, testing state.
Question 7:
An algorithm is O(n) and another O(n²). What can you conclude for n = 100?
The O(n) one is always faster
Nothing certain about which is faster
The O(n²) one takes 100 times longer
The O(n) one uses less memory
Right. Big O describes growth rate as n increases and hides constant factors, so at a fixed small n either could win.
Nothing certain can be concluded. Big O ignores constants and lower-order terms; it describes how cost grows, not actual time at a given n.
Question 8:
According to the CAP theorem, what must a distributed system give up during a network partition?
Partition tolerance or durability
Any two of the three properties
Either consistency or availability
Latency guarantees under heavy load
Correct. Partitions can't be wished away, so when one occurs a system must choose between staying consistent and staying available.
It must give up either consistency or availability. "Pick two of three" is misleading: the trade-off only bites during a partition.
Question 9:
What happens to commit hashes when you rebase a branch onto a new base?
They stay the same
Only the newest commit changes
They change only if conflicts occur
The rebased commits get new hashes
Right. A commit's hash depends on its parent, so replaying commits on a new base creates new commits.
The rebased commits get new hashes, because each hash covers the parent commit. That's why rebasing shared branches causes trouble.
Question 10:
A single-core CPU runs two tasks by switching between them. This is an example of what?
Concurrency without parallelism
Parallelism without concurrency
Both concurrency and parallelism
Neither concurrency nor parallelism
Correct. The tasks make progress in overlapping periods (concurrency) but never execute at the same instant (parallelism).
It's concurrency without parallelism. Concurrency is structuring work to overlap in time; parallelism needs simultaneous execution, e.g. on multiple cores.

Play another quiz

Play in 3D

Make your own quiz—it takes 20 seconds

Make your own version Report quiz Help and feedback Privacy and termsMade with Tjaz in 20 seconds

Help and feedback Privacy and terms