Stage 5: Marathon Legend

Enable learners to master full interview simulations by enduring long sessions with diverse technical and behavioral questions. Build confidence, resilience, and adaptability to perform like legends in real interviews.

Hackbook Overview

• Full Marathon Simulation: Extended interview with 25–30 questions across technical and behavioral domains.
• Multi‑Round Format: Technical round → troubleshooting round → behavioral round → panel Q&A.
• Stamina & Focus: Stay sharp across multiple rounds without losing clarity.
• Delivery Excellence: Structured answers, confident tone, and outcome‑focused storytelling.
• Why It Matters: This is the closest practice to a real interview marathon, preparing learners for high‑pressure scenarios.

Hands‑On Practice

• Attempt a complete mock interview marathon:
  • Round 1: 10 technical Linux questions.
  • Round 2: 5 troubleshooting scenarios.
  • Round 3: 10 behavioral questions.
  • Round 4: Panel‑style follow‑ups.
• Record the entire session and review pacing, confidence, and adaptability.
• Identify weak areas and refine with STAR + stronger technical clarity.
• Deliver one signature story that highlights unique strengths.

Interview Question Bank

Technical (Round 1)

• Q1. How do you check CPU, memory, and disk usage?
  A1. top, htop, free -h, df -h.
• Q2. How do you find and kill a process?
  A2. ps aux | grep <process> then kill -9 <PID>.
• Q3. How do you troubleshoot a service that won’t start?
  A3. Check systemctl status, logs via journalctl -u <service>, verify configs.
• Q4. How do you secure SSH access?
  A4. Disable root login, use key‑based authentication, restrict users in /etc/ssh/sshd_config.
• Q5. How do you schedule recurring jobs?
  A5. Use crontab -e.
• Q6. How do you check failed login attempts?
  A6. Review /var/log/auth.log.
• Q7. How do you monitor real‑time logs?
  A7. tail -f /var/log/syslog or journalctl -f.
• Q8. How do you check which process is using a port?
  A8. lsof -i :<port> or ss -tulnp.
• Q9. How do you check system uptime?
  A9. uptime.
• Q10. How do you check which services start at boot?
  A10. systemctl list-unit-files --type=service.

Troubleshooting (Round 2)

• Q11. A server is slow — what steps do you take?
  A11. Check CPU/memory usage, disk I/O, logs, and running processes.
• Q12. A service keeps crashing — how do you debug?
  A12. Review logs, check configs, test dependencies, restart with monitoring.
• Q13. Disk space is full — what do you do?
  A13. Use du -sh, clean logs, implement rotation, archive old files.
• Q14. Network connectivity is failing — how do you troubleshoot?
  A14. Check ping, traceroute, firewall rules, and service configs.
• Q15. A cron job isn’t running — how do you fix it?
  A15. Verify syntax, check cron logs, ensure permissions.

Behavioral (Round 3)

• Q16. Tell me about a time you solved a problem under pressure.
  A16. STAR example: Production outage → fixed config → restored service in 10 minutes.
• Q17. Describe a time you worked with a difficult teammate.
  A17. “I listened to their concerns, clarified misunderstandings, and focused on shared goals.”
• Q18. Give an example of when you showed leadership.
  A18. “I led a small team to automate deployments, assigning tasks clearly and ensuring everyone contributed.”
• Q19. Tell me about a time you improved a process.
  A19. “I implemented log rotation, reducing manual cleanup and preventing recurring disk space issues.”
• Q20. Describe a time you learned from failure.
  A20. “I misconfigured a firewall rule, documented the mistake, corrected it, and improved my checklist.”
• Q21. Tell me about a time you adapted quickly to change.
  A21. “When our team switched to Docker, I learned it hands‑on and helped teammates adapt.”
• Q22. How do you handle conflicts in a team?
  A22. “I listen actively, clarify misunderstandings, and focus on shared goals.”
• Q23. Tell me about a time you balanced multiple responsibilities.
  A23. “I managed coursework and freelance projects by scheduling tasks and communicating progress clearly.”
• Q24. Tell me about a time you mentored someone.
  A24. “I guided a junior teammate by simplifying Linux concepts and sharing cheatsheets, boosting their confidence.”
• Q25. Tell me about a time you explained a technical concept clearly.
  A25. “I explained Linux permissions using a house analogy — owner, family, and guests — which made it easy to understand.”

Panel Follow‑Ups (Round 4)

• Q26. What’s your biggest strength as an engineer?
  A26. “Problem‑solving under pressure and clear communication.”
• Q27. What’s your biggest weakness and how do you manage it?
  A27. “I used to over‑explain technical details; now I focus on clarity and outcomes.”
• Q28. Why should we hire you?
  A28. “I combine technical expertise with teamwork and adaptability, ensuring reliable results.”
• Q29. Where do you see yourself in 5 years?
  A29. “Leading projects, mentoring juniors, and contributing to scalable DevOps solutions.”
• Q30. How do you prepare for interviews?
  A30. “I practice technical commands, refine STAR stories, and simulate real interview conditions.”

Cheatsheet (Quick Notes)

• Technical Prep: top, ps, df, systemctl, journalctl, crontab, lsof, tail.
• Troubleshooting Prep: CPU/memory, logs, configs, disk cleanup, network checks.
• Behavioral Prep: STAR stories for teamwork, leadership, adaptability, problem‑solving, failure.
• Panel Prep: Strengths, weaknesses, career goals, hiring pitch.
• Time Discipline: Technical answers: 60–90 sec; Behavioral answers: 90–120 sec.