detecttechnologies Software Engineer Interview: Questions, Experience & Prep (2026)

Detect Technologies is a Chennai-based AI startup building industrial inspection products using computer vision, IoT sensors, and machine learning. Their systems serve sectors like oil and gas, manufacturing, and infrastructure, helping companies automate quality checks and safety monitoring that were previously done manually. As of mid-2026, Detect Technologies has 6 open Software Engineer roles.

The interview process typically spans 3-4 rounds: a recruiter or hiring manager screening call, one or two technical rounds covering coding and system design, and a final culture or team fit conversation. Candidates report a strong focus on Python proficiency, computer vision frameworks, and the ability to ship production-ready ML systems. General SWE roles also include data structures, algorithms, and API design questions.

Software Engineer salaries across India, based on the knok jobradar dataset, fall roughly in these ranges:

Detect Technologies is a growth-stage startup, so compensation varies. Check Glassdoor for any company-specific data points, and factor in ESOPs if they appear in the offer.

Candidates report a mix of coding, ML system design, and behavioural questions. Here are 12 questions commonly encountered for Software Engineer roles at Detect Technologies:

1. Walk me through a project where you built or deployed a machine learning model in production.
2. How would you design a real-time object detection pipeline for an industrial camera feed?
3. Explain how you would handle class imbalance in a defect detection dataset.
4. Write a function to detect and skip duplicate frames in a video stream efficiently.
5. How does YOLO differ from traditional CNNs for object detection? When would you pick one over the other?
6. Describe a time you optimised a slow data pipeline. What bottlenecks did you find and how did you fix them?
7. How would you design a system that ingests sensor data from hundreds of IoT devices and triggers alerts in near real-time?
8. What is model drift, and how would you monitor a deployed vision model for it?
9. Given a large annotated image dataset, how would you set up a training and evaluation pipeline from scratch?
10. Tell me about a time you disagreed with a technical decision your team made. What happened?
11. How would you approach deploying a computer vision model on edge hardware with limited compute?
12. Describe your experience building REST APIs or gRPC services. How have you exposed ML models as microservices?

Q: Walk me through a project where you built or deployed a machine learning model in production.

*Situation:* My team needed to automate visual quality checks on a manufacturing line that was previously handled by manual inspectors.

*Task:* I was responsible for building an end-to-end defect detection system using images captured by line cameras.

*Action:* I assembled a labelled training dataset covering three defect classes, fine-tuned a ResNet classifier, and evaluated it using precision, recall, and F1 metrics. I containerised the inference service with Docker, wrote a lightweight API to accept image payloads, and added a monitoring dashboard to track inference confidence over time with alerts for drops below the target threshold.

*Result:* The model went live and reduced manual inspection time on that line. The monitoring setup caught one instance of model drift within the first month, which we corrected by retraining with fresher data before it impacted production quality.

---

Q: How would you design a real-time object detection pipeline for an industrial camera feed?

*Situation:* During a system design round, I was asked to design a pipeline that processes live RTSP camera streams from a factory floor.

*Task:* The design had to handle multiple concurrent camera feeds, run inference at low latency, and store alerts with metadata for audit.

*Action:* I proposed buffering incoming frames through a message queue (Kafka or RabbitMQ), processing them with a pool of inference workers running a quantised detection model, and writing alert events to a time-series database. I also described a frame-skipping strategy for cameras with redundant frames and explained how GPU batching improves throughput without increasing end-to-end latency proportionally.

*Result:* The interviewer followed up on failure handling and horizontal scaling, which I addressed by describing health checks on workers and auto-scaling groups tied to queue depth. The design covered all stated requirements within the time given and prompted a good technical conversation.

---

Q: Tell me about a time you disagreed with a technical decision your team made.

*Situation:* My previous team planned to store all model inference logs in a relational database. I felt this would become a write bottleneck as the system scaled.

*Task:* I needed to raise the concern without derailing a sprint that was already in progress.

*Action:* I put together a brief comparison of write throughput for a relational DB versus a time-series store using publicly available benchmark data, presented it at the next stand-up, and proposed a phased migration: ship the MVP with the relational DB, then migrate logs to a time-series store in the following sprint.

*Result:* The team agreed to the phased approach. The initial deadline was met, and the log migration happened smoothly three weeks later with no regressions in the existing features.

For coding questions: think out loud before writing code. State the brute-force approach first, estimate its time and space complexity, then explain the optimised solution. Detect Technologies engineers work with real-time data, so show awareness of latency and memory constraints even in algorithmic answers.

For ML system design questions: use a clear structure: data ingestion, preprocessing, model selection and training, evaluation, deployment, and monitoring. Always mention how you would handle edge cases like corrupt sensor readings, low-light images, or sudden distribution shifts in production data.

For behavioural questions: use the STAR format (Situation, Task, Action, Result). Keep the Situation brief (one or two sentences), spend most of your answer on Action, and make the Result concrete. If you have no metric, describe a qualitative outcome: 'the team adopted the approach' or 'no further incidents were reported in that quarter.'

For 'how does X work' questions: explain from first principles, then connect to a practical use case. If asked about attention mechanisms, explain the core idea in plain terms and then mention where you have seen it matter in a real project or paper you have read.

Strong Python fundamentals. Almost all engineering at Detect Technologies involves Python. Expect questions on list comprehensions, generators, decorators, and writing clean, testable functions. Knowing how to profile and optimise Python code is a plus.

Computer vision and ML depth. Even for general SWE roles, familiarity with OpenCV, PyTorch or TensorFlow, and common detection architectures like YOLO or Faster R-CNN is valued. Interviewers want to see that you understand what happens inside the model, not just how to call a library function.

Systems thinking for real-world data. Industrial AI deals with noisy sensors, intermittent camera feeds, and hardware constraints. Candidates who reason about fault tolerance, edge deployment, and data quality stand out from those who only think about accuracy on clean benchmarks.

Ownership and communication. As a startup, Detect Technologies expects engineers to own problems end to end. Interviewers look for examples where you drove something from idea to production, communicated trade-offs clearly, and iterated based on real feedback.

Curiosity and learning agility. The field moves fast. Candidates who can speak to recent work in vision transformers, model quantisation, or MLOps tooling signal that they stay current and do not wait to be told what to learn.

Week 1: Coding and algorithms. Practise array, string, tree, and graph problems at a medium difficulty level. Focus on patterns like sliding window, two pointers, and BFS or DFS, which come up in data pipeline and traversal questions. Aim for clean Python solutions, not just correct ones.

Week 2: Machine learning and computer vision. Review core concepts: loss functions, evaluation metrics (precision, recall, F1, IoU), and common architectures for detection and segmentation. Set up a small project using OpenCV or a YOLO variant if you have not touched one recently.

Week 3: System design. Study how to design data ingestion pipelines, model serving infrastructure, and monitoring systems. Practise drawing and explaining a full ML pipeline out loud, covering data flow, failure points, and scaling decisions. Include edge deployment scenarios.

Week 4: Behavioural prep and company research. Read about Detect Technologies' products and the sectors they serve. Prepare 5-6 STAR stories covering: ownership of a shipped project, a technical conflict, a failure and what you learnt, and a time you improved a process or team practice.

Knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you, so while you are deep in interview prep, your applications keep moving in the background.

Jumping to code without clarifying the problem. Interviewers at product-focused AI companies want to see structured thinking. Restate the problem, confirm constraints, and name your approach before writing a single line.

Treating ML as a black box. Saying 'I used a pre-trained model and fine-tuned it' without explaining why you chose that architecture or how you evaluated it signals shallow understanding. Go one level deeper on your choices.

Ignoring production concerns in system design. A design that works on a clean demo dataset is not enough. Mention data validation, logging, model versioning, and rollback strategies. Interviewers at Detect Technologies care about what happens when things go wrong in the field.

Generic behavioural answers. 'I am a team player' without a specific story wastes interview time. Every behavioural answer needs a concrete situation with a measurable or observable outcome.

Skipping the question round at the end. Asking nothing reads as low interest. Prepare two or three genuine questions about the team's current technical challenges, deployment stack, or how they measure model performance in real industrial environments.