TL;DR: OpenShift is certified Kubernetes plus an integrated registry, build system, Routes, an operator catalogue and a much stricter default security posture. The default
restrictedsecurity context constraint runs your container as an arbitrary non-root UID, and images that assume root or a fixed UID break on arrival.
How to approach it
Lead with the security difference, because it is the practical answer to "why did my manifest stop working" and it is what an interviewer on an enterprise platform team wants to hear. Then cover the additions briefly. Being able to say what to change in the Dockerfile is what makes this useful rather than descriptive.
A strong answer
OpenShift is Kubernetes underneath, certified conformant, so the API objects you know all work. What it adds is a supported distribution with opinions.
Security context constraints, the part that matters day one. An SCC is an OpenShift object that controls what a pod may do: which UID it can run as, whether it can be privileged, which capabilities and volume types it can use, whether it can use host networking. The default for ordinary workloads is restricted-v2, and it does something specific: it assigns the pod a random UID from the namespace's allocated range and runs the container as that, with group 0.
So an image that does any of these breaks:
Runs as root, or has a USER 0. Refused outright.
Writes to a directory owned by a specific user, because the random UID does not own it.
Assumes a particular UID exists in /etc/passwd, which it will not. Tools that call getpwuid() fail.
Binds a port below 1024, which needs a capability the restricted SCC does not grant.
The fixes are ordinary image hygiene and they make the image better on plain Kubernetes too. Make directories the process writes to group-writable and owned by group 0, since OpenShift runs with GID 0: RUN chgrp -R 0 /app && chmod -R g=u /app. Declare a non-root USER. Listen on 8080 rather than 80. Do not depend on a username existing.
The wrong fix, which is common, is granting the workload the anyuid SCC so it can run as root. That works and throws away the property the platform was chosen for, and on a regulated cluster it is the sort of exception that appears in an audit.
The other additions:
Routes predate Ingress and do the same job with a simpler object, including automatic TLS with the cluster's certificate and edge, passthrough or re-encrypt termination. Ingress objects also work and are converted to Routes behind the scenes.
Projects are namespaces with extra metadata and a self-service creation workflow, so a developer can request one within quota rather than filing a ticket.
BuildConfig and ImageStream are the integrated build system: source-to-image can take a git repository and produce a runnable image without a Dockerfile, and an ImageStream tracks image tags so a new push can trigger a redeploy. Useful, and something to be deliberate about, because it is OpenShift-specific and building in your normal CI keeps you portable.
Operator Hub, an integrated catalogue of operators, plus the built-in registry, monitoring stack and logging, so you inherit a working Prometheus and console rather than assembling one.
DeploymentConfig is the older OpenShift-native object with triggers and lifecycle hooks. New work should use a standard Deployment; you will meet DeploymentConfig in existing clusters.
What interviewers probe next
"How do you debug a pod that will not start on OpenShift?" Look at the events for an SCC denial, then oc get pod -o yaml to see which SCC was admitted and what UID was assigned. The annotation openshift.io/scc on the pod names the one that allowed it.
"When is OpenShift worth the licence?" When you want a supported, opinionated platform with the security posture, monitoring and lifecycle already assembled, and particularly where a vendor support relationship is a requirement. Assembling the equivalent on vanilla Kubernetes is a real team.
"Is oc different from kubectl?" A superset. Everything kubectl does plus OpenShift-specific verbs like oc new-app and oc adm.
Common mistakes
Granting anyuid to make an image work, which removes the control rather than fixing the image.
Assuming a Dockerfile that works locally will run, when running as root is the default almost everywhere else and refused here.
Using chown to a specific UID in the Dockerfile instead of making paths group-0 writable.
Adopting source-to-image and ImageStreams for everything, then finding the build process does not move to another platform.