141–150 of 460 posts
> 2. Max width of 100 characters. Lines must break on natural breakpoints and not with the aim of optimizing for following the rules. Comments do not count toward this limit and would be positively valued if they are helpful.
This is the point at which I would say that I've heard enough and I'm not interested in working for their company, before I hang up the call.
I wish I could have seen the code at each step instead of just, "That was easy." Because he seems to have focused on the functionality of the code, not on the clear message that their goal is to see how robust, reliable, and readable you can make your code. I don't think this interview was actually about the code, it was about long-term maintenance and risk avoidance. So while I am not saying I love this interview me…
Would any developer be a good match for that company? My judgment is that this company has no idea of what they are doing. Not uncommon for companies with under 50 employees.
Interestingly, unlike many in this thread I would've avoided hiring this person based only on the code example. This code is almost unreadable to me, certainly to most on my team. I would request changes it if it was a PR going into production (ignoring that the problem itself is made up). The code I would've liked to see would be easy to read, easy to follow, and would make me understand the underlying rules that ma…
There is almost zero chance that a passable FizzBuzz would be produced in those interviews.
Earlier quoted context omitted.
Good leadership starts with clearly communicating expectations. If your boss can not say "I want you to use this tool" or "use whatever you seem fit", but instead hints to you as to some possible drawbacks of certain tools he is bad at his job. There are multiple ways to read that suggestion. It can also be read as the interviewer saying he does not believe in the technical depth of the candidate, which can be taken…
[flagged]
>There are not really multiple ways to read "I don't think that's a good idea" in an interview. If your "technical depth" leads you to an inappropriate solution, it doesn't matter if it's right. Just because this solution worked for FizzBuzz and all their rules does not mean it's maintainable. It's obvious to most senior people that such a weird solution is brittle and overkill, even if they can't come up with a rule to break it. But here's a simple one: Output FizzBuzz if all the rules are passed, except if there is a database entry matching the number. Good luck solving that with some bullshit type theory, and good luck to anyone who comes behind this guy to add that rule to his Rube Goldberg code.
"What set of tools would you choose to build ? And why would you choose them over alternatives?" or "We here at X make use of Y a lot, have you worked with Y or alternatives? What did you think about Y or alternatives?". Both are infinitely more telling about the candidate.
Someone's choice for a contrived joke problem will not reflect their choices for a real software project.
>For example, I worked with one mostly self-taught guy who wanted to rewrite everything in a niche compiled language, including things that really should be done in scripting languages like Python or shell. Thankfully nobody else let him do that. But deep down I think he didn't accept that he was wrong, and on multiple occasions he expressed that he thought the average person on the team was woefully inexperienced. In fact, it was him that was woefully inexperienced, because he didn't understand how inappropriate and even flat-out wrong his solutions were.
I worked with people who liked to solve silly problems in silly ways, but when it came to real projects always preferred mature languages and libraries which focused on long term support, stability and maintainability.
The problem with the interview is that instead of talking about the subjects, they themselves want to rely on subtle hints about the candidate. Which may not mean anything.
Earlier quoted context omitted.
> if an interviewer says "I don't think that will be a good idea" just take the hint that it won't be what the expect and change it. I'd like to underline this just in case the author reads the thread. He really does seem great and I wish all the best to him, but reading between the lines is a useful skill regardless of this specific situation. He says he doesn't speak English well, that might have played a role in t…
Yeah, it's an English thing. A literal translation in Dutch would mean "explain yourself here", and if you'd change tack because of the question alone, it would seem like you really lack self-confidence. But after living in the UK for a bit, in the UK that is most likely an order.
I also think the interview setup and management were poor.
I'd be nervous about an applicant that came up with a very clever solution for the hard part of a problem but completely overlooked the simple part. (Again, not sure whether this is what happened here, but the change from how the problem is usually presented makes me wonder.)
Seeing this being used in the backend is really questionable. In fact, I then question the overall skillset of the team as to why they need to use Node.js or JS-related technologies in the backend.
As soon as I see any recruiter or company mentioning any usage of Node.js or JavaScript or TypeScript in the backend in the job description, I just laugh and delete the email and never reply back.
Introducing such unsound technologies into a production system responsible for maintaining a critical service is a recipe for complete chaos and disorder and tells me that your company is a joke that exists to prepare their developers for failure.
I loved the article and would probably have hired this person. But as a suggestion to them: if an interviewer says "I don't think that will be a good idea" just take the hint that it won't be what the expect and change it. Also reminded me of my compiler class, we had some homework to write a pascal/C transpiler and a friend of mine somehow managed to implement it via bison errors(?). The teacher was not happy but ha…
I wish I could have seen the code at each step instead of just, "That was easy." Because he seems to have focused on the functionality of the code, not on the clear message that their goal is to see how robust, reliable, and readable you can make your code. I don't think this interview was actually about the code, it was about long-term maintenance and risk avoidance. So while I am not saying I love this interview me…
The rules presented show that the goal is definitely not that.
Earlier quoted context omitted.
50k EUR/year for me would be like 2900 EUR/month after all taxes. Monthly expenses in the part of Spain I live in are ~800 EUR (rent + food + electricity + water + 1Gbps internet). 2900 - 800 = 2100 EUR to do whatever I want with. Even if I decide to put half of that into savings, that's still ~1000 EUR to spend freely, and any unspent money would go into savings too at the end of the month. Or in other words: With a…
Fair enough I’m just saying I live in Germany and just entered my first software position and get 73k, and I don’t live in Berlin or anything. I suppose in Spain living expenses are much cheaper. Your monthly expenses including food are less than my rent. Tho I still think I have more than 2100 left over after expenses
More to you, but that isn't a common entry level, at least for companies whose main business isn't selling software.