[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"me":3,"catalog:en:qa-test-automation\u002Fsenior":4,"config":126},null,{"field_key":5,"field_name":6,"seniority":7,"topic_key":8,"topic_name":8,"spec_key":8,"spec_name":8,"locale":9,"cell_total":10,"field_total":11,"seniorities":12,"topics":15,"specs":41,"samples":42},"qa-test-automation","QA \u002F Test Automation","senior","","en",394,600,[13,14,7],"junior","mid",[16,20,23,26,29,32,35,38],{"key":17,"name":18,"count":19},"qa-api-testing","Qa Api Testing",75,{"key":21,"name":22,"count":19},"qa-automation-fundamentals","Qa Automation Fundamentals",{"key":24,"name":25,"count":19},"qa-ci-cd-testing","Qa Ci Cd Testing",{"key":27,"name":28,"count":19},"qa-defect-management","Qa Defect Management",{"key":30,"name":31,"count":19},"qa-exploratory-manual-testing","Qa Exploratory Manual Testing",{"key":33,"name":34,"count":19},"qa-performance-testing","Qa Performance Testing",{"key":36,"name":37,"count":19},"qa-test-case-design","Qa Test Case Design",{"key":39,"name":40,"count":19},"qa-test-strategy","Qa Test Strategy",[],[43,61,74,87,100,113],{"id":44,"topic":18,"difficulty":45,"body":46,"options":47,"correct_key":49,"explanation":60},"019f68ba-2388-7e64-835a-7be00e9825f4",3,"A test sends `POST \u002Faccounts` with an invalid email format and receives:\n```json\n{\"status\": 200, \"body\": {\"id\": null, \"error\": \"invalid email\"}}\n```\nWhy is this response poorly designed from an API testing point of view?",[48,51,54,57],{"key":49,"text":50},"a","A 200 status signals success to any client checking status first, hiding the failure inside the body",{"key":52,"text":53},"b","The response body should never contain the word \"error\" in it, regardless of what actually went wrong",{"key":55,"text":56},"c","The `id` field should contain a randomly generated placeholder value instead of `null` when creation fails",{"key":58,"text":59},"d","JSON responses are not allowed to describe validation failures; only HTTP headers may carry error information","Many clients (and simple monitoring) branch on the status code first; a 200 says \"this worked\", so a client that doesn't dig into the body will treat a rejected, invalid request as a success. The fix is a 4xx status (e.g. 400\u002F422) that matches what actually happened, with the body detail on top. Avoiding the word \"error\" (b) is cosmetic and irrelevant, a fake placeholder id (c) would make a failure look even more like success, and error detail belongs naturally in the body regardless of headers (d).",{"id":62,"topic":18,"difficulty":45,"body":63,"options":64,"correct_key":55,"explanation":73},"019f68ba-238d-7154-a75f-b889d41cbe31","A test needs to confirm not just that a notification service returns success, but that it was actually invoked exactly once with the correct recipient. Which kind of test double is the right fit, and why?",[65,67,69,71],{"key":49,"text":66},"A stub, because stubs record every call automatically as a side effect of returning a response",{"key":52,"text":68},"The real service, because only the real dependency can prove that the recipient value was correct",{"key":55,"text":70},"A mock, because a mock lets the test assert on the interaction itself — that it was called once, with the expected recipient",{"key":58,"text":72},"No test double is suitable here; this kind of check can only be performed by manual inspection of production logs","This requirement is about behavior verification (was the call made, how many times, with what arguments) rather than just supplying a canned result — that's precisely what a mock is for. A plain stub (a) returns a response but isn't designed to make call-count and argument checks part of the test's assertions. The real service (b) isn't needed to verify what arguments your own code passed to it, and a manual log check (d) is unnecessary when the same thing can be asserted automatically and repeatably.",{"id":75,"topic":18,"difficulty":45,"body":76,"options":77,"correct_key":58,"explanation":86},"019f68ba-238d-7a04-a219-4dc71a6c04ec","A test creates a resource, checks it, and never deletes it. Run a hundred times in the shared test environment, the resource list grows to thousands of entries, and an unrelated `GET \u002Fresources` test starts timing out. What is the underlying problem?",[78,80,82,84],{"key":49,"text":79},"The `GET \u002Fresources` endpoint has a bug and should be rewritten to ignore how many resources actually exist",{"key":52,"text":81},"The test environment's server needs more memory, since any endpoint will eventually slow down as data grows",{"key":55,"text":83},"Nothing is wrong; a growing resource count is a normal and expected side effect of running tests repeatedly",{"key":58,"text":85},"The creating test leaves data behind with no cleanup, polluting the shared environment for other tests","A test that creates data but never removes it leaves permanent residue in a shared environment; over many runs that residue accumulates and starts affecting tests that have nothing to do with the original one — a symptom of tests not being properly isolated and self-cleaning. The fix is to tear down what was created (or use dedicated, disposable data) after each run. The listing endpoint isn't necessarily buggy for slowing down under a genuinely larger dataset (a), more memory (b) only delays the same underlying accumulation, and letting this continue unchecked (c) is exactly the practice to avoid.",{"id":88,"topic":18,"difficulty":45,"body":89,"options":90,"correct_key":55,"explanation":99},"019f68ba-238f-7610-bb69-7ab38a2ade37","A response is expected to satisfy: `id` is an integer, `name` is a non-empty string, `price` is a number greater than zero. Given this response:\n```json\n{\"id\": \"7\", \"name\": \"\", \"price\": 12.5}\n```\nWhich statement about schema validation of this response is correct?",[91,93,95,97],{"key":49,"text":92},"The response passes, because `\"7\"` can be automatically converted to the integer `7` in every schema validator",{"key":52,"text":94},"The response passes, because `price` being positive is the only rule schema validation is able to check",{"key":55,"text":96},"The response fails, because `id` is a string rather than an integer and `name` is empty rather than non-empty",{"key":58,"text":98},"The response fails only because of `id`'s type; an empty string still counts as a valid non-empty string","Against the stated rules, two things are wrong at once: `id` arrives as the string `\"7\"` instead of an integer, and `name` is an empty string, which does not satisfy \"non-empty\". A schema validator does not silently coerce types by default (a) — that would hide a real type mismatch — and schema validation checks structure and type constraints generally, not only numeric ranges (b); both listed violations are real, not just one of them (d).",{"id":101,"topic":18,"difficulty":45,"body":102,"options":103,"correct_key":49,"explanation":112},"019f68ba-2390-7ae1-beec-39a004b1c330","A backend adds a new optional field `discountCode` to an existing response. The consumer's tests were written with a schema that marks unknown fields as invalid (`additionalProperties: false`, or equivalent). What happens, and what does this reveal?",[104,106,108,110],{"key":49,"text":105},"The consumer's tests fail on a purely additive change, revealing the schema is stricter than intended",{"key":52,"text":107},"Nothing happens, because schema validation only ever checks for fields that are missing, never for fields that are unexpectedly present",{"key":55,"text":109},"The provider's own tests fail immediately, since adding any field to a response is always a breaking API change",{"key":58,"text":111},"The consumer automatically starts using `discountCode` in its own logic, since schemas propagate new fields to consumers directly","A schema that rejects any field it doesn't already know about treats a harmless, additive change as a break — the version compatibility problem here is in the test's own strictness, not in the API change. Loosening the schema to allow (and simply ignore) unknown additional fields lets genuinely compatible changes pass while still catching real contract violations like a missing or mistyped required field. Schema validation absolutely can flag unexpected extra fields when configured to (b), adding an optional field is additive, not inherently breaking (c), and a schema doesn't make a consumer start consuming a field on its own (d).",{"id":114,"topic":22,"difficulty":45,"body":115,"options":116,"correct_key":55,"explanation":125},"019f68ba-2398-70b1-9c9f-dc238ceb12de","A test suite passes when tests run in a fixed alphabetical order but fails when run in a randomized order, which many CI tools use to surface flaky tests. Each test passes fine on its own. What does this most strongly indicate?",[117,119,121,123],{"key":49,"text":118},"The CI tool's randomization feature itself is malfunctioning",{"key":52,"text":120},"The tests are flaky purely due to network timing, unrelated to order",{"key":55,"text":122},"Some tests depend on state left by tests run earlier alphabetically",{"key":58,"text":124},"The suite simply contains too many tests to run safely at all","Passing in one fixed order but failing under randomization, while each test is fine alone, is the signature of an order-dependency bug rather than a tooling defect. a assumes the tool is broken, which is far less likely than a real dependency; b and d don't explain why order specifically matters.",{"fields":127,"seniorities":312,"interview_shapes":313,"locales":318,"oauth":320,"question_count":323,"coach_enabled":324,"jd_match_enabled":324},[128,154,175,191,215,228,247,266,288,293,299,306],{"key":129,"name_tr":130,"name_en":130,"sort":131,"specializations":132},"backend","Backend",1,[133,136,139,142,145,148,151],{"key":134,"name":135,"field":129},"general","Genel",{"key":137,"name":138,"field":129},"go","Go",{"key":140,"name":141,"field":129},"python","Python",{"key":143,"name":144,"field":129},"java","Java",{"key":146,"name":147,"field":129},"csharp","C#\u002F.NET",{"key":149,"name":150,"field":129},"nodejs","Node.js",{"key":152,"name":153,"field":129},"php","PHP",{"key":155,"name_tr":156,"name_en":156,"sort":157,"specializations":158},"frontend","Frontend",2,[159,160,163,166,169,172],{"key":134,"name":135,"field":155},{"key":161,"name":162,"field":155},"javascript","JavaScript",{"key":164,"name":165,"field":155},"typescript","TypeScript",{"key":167,"name":168,"field":155},"react","React",{"key":170,"name":171,"field":155},"vue","Vue",{"key":173,"name":174,"field":155},"angular","Angular",{"key":176,"name_tr":177,"name_en":177,"sort":45,"specializations":178},"fullstack","Fullstack",[179,180,181,182,183,184,185,186,187,188,189,190],{"key":134,"name":135,"field":176},{"key":137,"name":138,"field":129},{"key":140,"name":141,"field":129},{"key":143,"name":144,"field":129},{"key":146,"name":147,"field":129},{"key":149,"name":150,"field":129},{"key":152,"name":153,"field":129},{"key":161,"name":162,"field":155},{"key":164,"name":165,"field":155},{"key":167,"name":168,"field":155},{"key":170,"name":171,"field":155},{"key":173,"name":174,"field":155},{"key":192,"name_tr":193,"name_en":193,"sort":194,"specializations":195},"devops-cloud","DevOps \u002F Cloud",4,[196,197,200,203,206,209,212],{"key":134,"name":135,"field":192},{"key":198,"name":199,"field":192},"aws","AWS",{"key":201,"name":202,"field":192},"gcp","GCP",{"key":204,"name":205,"field":192},"azure","Azure",{"key":207,"name":208,"field":192},"kubernetes","Kubernetes",{"key":210,"name":211,"field":192},"terraform","Terraform",{"key":213,"name":214,"field":192},"linux","Linux",{"key":216,"name_tr":217,"name_en":217,"sort":218,"specializations":219},"ai-engineer","AI Engineer",5,[220,221,222,225],{"key":134,"name":135,"field":216},{"key":140,"name":141,"field":216},{"key":223,"name":224,"field":216},"llm-rag","LLM\u002FRAG",{"key":226,"name":227,"field":216},"mlops","MLOps",{"key":229,"name_tr":230,"name_en":231,"sort":232,"specializations":233},"database","Veritabanı","Database",6,[234,235,238,241,244],{"key":134,"name":135,"field":229},{"key":236,"name":237,"field":229},"postgresql","PostgreSQL",{"key":239,"name":240,"field":229},"mysql","MySQL",{"key":242,"name":243,"field":229},"mongodb","MongoDB",{"key":245,"name":246,"field":229},"redis","Redis",{"key":248,"name_tr":249,"name_en":250,"sort":251,"specializations":252},"mobile","Mobil","Mobile",7,[253,254,257,260,263],{"key":134,"name":135,"field":248},{"key":255,"name":256,"field":248},"ios-swift","iOS (Swift)",{"key":258,"name":259,"field":248},"android-kotlin","Android (Kotlin)",{"key":261,"name":262,"field":248},"flutter","Flutter",{"key":264,"name":265,"field":248},"react-native","React Native",{"key":267,"name_tr":268,"name_en":269,"sort":270,"specializations":271},"security","Güvenlik","Security",8,[272,273,276,279,282,285],{"key":134,"name":135,"field":267},{"key":274,"name":275,"field":267},"appsec","AppSec",{"key":277,"name":278,"field":267},"offensive-pentest","Offensive \u002F Pentest",{"key":280,"name":281,"field":267},"cloud-security","Cloud Security",{"key":283,"name":284,"field":267},"devsecops","DevSecOps",{"key":286,"name":287,"field":267},"blue-team-incident","Blue Team \u002F Incident",{"key":5,"name_tr":289,"name_en":6,"sort":290,"specializations":291},"QA \u002F Test Otomasyonu",9,[292],{"key":134,"name":135,"field":5},{"key":294,"name_tr":295,"name_en":295,"sort":296,"specializations":297},"data-engineer","Data Engineer",10,[298],{"key":134,"name":135,"field":294},{"key":300,"name_tr":301,"name_en":302,"sort":303,"specializations":304},"game-dev","Oyun Geliştirme","Game Development",11,[305],{"key":134,"name":135,"field":300},{"key":307,"name_tr":308,"name_en":308,"sort":309,"specializations":310},"ml-engineer","ML Engineer",12,[311],{"key":134,"name":135,"field":307},[13,14,7],{"junior":314,"mid":316,"senior":317},{"questions":315,"median_sec":3},20,{"questions":315,"median_sec":3},{"questions":315,"median_sec":3},[319,9],"tr",[321,322],"google","github",21750,true]