5 ms·
> Then they rejected me because I used GET instead of POST. OK, I'm honestly curious here. What was the request, and why did you make such a decision? Do you t
by golergka 6y ago
> Then they rejected me because I used GET instead of POST.
OK, I'm honestly curious here. What was the request, and why did you make such a decision? Do you think it is the right approach in this case, or that it's an insignificant mistake that does not represent a person's understanding of HTTP protocol?
I remember hearing about at least one story where using GET instead of POST lead to disastrous consequences, as some robot crawled all over the "delete" links - but I have to admit, I can't imagine how it would happen without other significant design flaws happening as well (as "delete" links being public or robot being able to crawl under authenticated user's identity). This sounds like an error that can cause irrational irritation by the reviewer, but I can't imagine it being the sole reason to decide that the author can't code.
- hysan 6y agoNot the OP, but from my experience teaching web dev, one possible reason is nerves. I’ve seen some of the smartest students make that mistake on an assessment simply because they were under pressure. A simple conversation afterwards shows that they do understand the difference (as expected). In the moment though, sometimes you just have a brain fart.
- bitten 6y agoYep! I have been in similar situations where you make a mistake and you get out right rejected. Surely it's better to explain the mistake to me and then we can discuss it. This can also be a nice cultural check too, how well do I respond to my own mistakes? It's a shame most people don't follow your idea here.
- wool_gather 6y agoThis really can't be understated. The difference between your how your brain works when you're under the clock and know you're being observed vs. the "natural" flow of a calm working environment is tremendous. Anyone of us who's conducting the interview must do some kind of double-checking of obvious mistakes to fairly account for the limitations of the process.
- johnfn 6y agoI was definitely in the wrong about GET/POST. The company I had previously worked for simply didn't really care too much about getting the verbs right, so I didn't really fret about them. And the company I'm currently at (multiple thousands of employees, strong engineering culture if I dare say so myself) just does everything as a POST. So it really is somewhat cultural whether you care about GET/POST or not. But, IMO, even if you don't know, it's the kind of thing you learn once in code review and then don't worry about again.
- cameronh90 6y agoFor E2E encrypted APIs, one could well argue that worrying about HTTP verbs is just wasting time for no good reason. POST (consistently) lets you attach a body too. Just using POST for everything is a pattern I've seen becoming more popular recently.
- deleted 6y ago[deleted]
- chrisandchris 6y agoNo we can get into an endless argument whether verbs are abused or not... IMHO, GET (as of today) gas the issue that it does not support a body. If I‘m executing a search (an idempodent action), how can I nicely pass a JSON object configuring the search? I‘ll just use POST for that... So then we‘re at the point where the url does not work anymore because we have a POST /findEmployee; POST /findContract; ... instead of GET /employee and GET /contract. Maybe I‘m wrong here, but it doesn‘t like nice in my eyes using POST in that way.
- ulucs 6y agoThe JS API's I used to develop in used a mix of query strings (for exact matches) mixed with JSON (for more complicated queries) all in the url parameters
- andreareina 6y agoGoogle Places API puts the key in a query parameter. Still don't know how I feel about that.