I just want to point out that is ridiculous some questions asked in this tests. The aim is to verify your knowledge but it seems they were designed to confuse. For example one of the questions was:
Which code goes after this method 'check_user_login' in the controller?
A. respond_to do |format|
B. verify_user(email, password)
C. add.errors('unexpected error')
D. before_action :check_user
I mean the probably answer could be B, but how I am going to decide, if I can't see the controller file, model, routes, params... I need to know the context of how the application works to make a decision.
Have you been in a similar situation? Do You have an advice? I feel really angry and frustrated, I think I have the knowledge and really need the job. But with this type of tests is getting really difficult to show my skills.
I am reluctant to look for a new dev job bc of ‘ish like this. Who cares if you know the answer? Will a “lack” of knowledge here really prevent you from delivering a new feature, optimizing a process, and/or fixing a bug!?! good luck
Was this test designed by a recruiter, or a dev at the company?
If the former: good recruiters are hard to find. Keep looking.
If the latter: sometimes devs at companies like to create entrance tests that just reaffirm how much they know about stuff. It doesn’t always reflect how good a potential employee will fit or succeed.
The CTO at the last startup I worked for FT used to ask candidates questions with multiple answers and whatever answer they picked he told them it was wrong, just to see how they’d react. At first I thought that was a little fucked up until I worked with someone who lost their temper every time someone thought that there might be a better way to do things than their way.
Anyway, don’t beat yourself up. Have some confidence in your skills being apparent without having to work extra hard to prove them. If a potential employer can’t tell actual skills from bullshit, that’s a reflection on the employer and maybe you *don’t* really want to work for them? Just a thought
That is a terrible question.
However there is enough ambiguity here to speak out loud and justify your answer while discussing other parts of rails you are familiar with.
Also not all rails interviews are this bad. We do rails interviews and I feel our interview is pretty fair, we ask candidates to design one API end point and ask them to discuss challenges around modeling, querying, performance, etc.
Thank you guys for all your kind answers and support. I couldn’t sleep thinking , or this test is wrong OR I am really really really stupid . haha
**Which code goes after this method ‘check\_user\_login’ in the controller?**
First, what does this method do? Did someone create this as a private method that is used in a before\_action? If so, A is out. If not, if this is an action, why are they breaking CRUD styling and then D is out. Is this method just a return true, so it’s not actually implemented yet? In that case the answer is perhaps B unless this is a before\_action in which case B doesn’t make sense. If not a before\_action then C wouldn’t make sense. So, the real answer is **E**.
**A. respond\_to do |format|**
Is this an API only app? If so, in general, why even respond to anything other than JSON?
**B. verify\_user(email, password)**
What does verify\_user do that check\_user\_login doesn’t? What are you verifying?
**C. add.errors(‘unexpected error’)**
What’s so unexpected?
**D. before\_action :check\_user**
What does check\_user do that verify\_user or check\_user\_login don’t do?
**Inserted -> E. sent back to Business Analyst (recruiter) as not enough information provided.**
This would be the only appropriate answer as the method names are not clear. The context is not clear. Without knowing what the methods are actually doing, you may be duplicating code for no reason.
Regardless of what answer is correct. I would stop the test and have a verbal conversation about the test with the recruiter and/or hiring manager. Doing so will either
\- make them see you as someone who cannot do the job without having your hand held
or
\- they will see you as someone who thinks of the bigger picture and will congratulate you for thinking “outside of the box” or seeing problems before they occur.
If the former, the interview process should end immediately as this is not a company that you will want to work for. If the latter, the interview process continues without silly and poorly written tests.
Sounds like a shite company.
I actually think this question was designed to see if you’d do error handling or not. A lot of these questions are really emotional and written because someone fucked up in the past and there is a scar left over from their own learning process.
I had a question few years back that was “given the following collection (it was a mix of hashes and arrays that would actually not parse due to syntax errors) within a single function, order the collection removing duplicate data, and capitalize all data identification structures. You cannot use unreliable shortcuts like, map, or uppercase”.
It was obvious they had some serious problems in the past with map reduce or etl and they all are new to ruby and/or rails. All of the questions on their test were similar.
I wrote back to the recruiter that if hired, my first order of business would be to have a long conversation with whomever wrote the test to schedule their departure from the company or retraining starting at hello world. Never heard back.
I’m at the point where I won’t take tests, I’ll write or share some sample code, I’ll solve a problem they had previously, I’ll simulate getting a crazy bug ticket, but I won’t react to someone else’s own little hell.
For those that are interested here are a list of companies that hire without the so called “whiteboard testing”.
[https://github.com/poteto/hiring-without-whiteboards](https://github.com/poteto/hiring-without-whiteboards)
Not in the Rails world, but I think it’s still relevant… The company I used to work for had a lot of trouble finding good contractors to hire for automated testing. We were getting flack from upper managers and recruiters for rejecting all the candidates. And we felt we were wasting our time on interviews.
I was part of the team that devised a test to try to screen candidates. The particular skillset we were looking for was difficult to find at that time (automation testers who can write code). Our test consisted of questions related advanced features of the testing tool we used (features which we did make extensive use of in our framework), as well as more general programming questions.
Questions we thought were reasonable basic but should show if candidates are able to develop code.
Don’t know the tool’s scripting language? No problem, use a language you do know. Aren’t sure about syntax? Not a problem, if the intent of your code can be deciphered by humans. Can’t figure out the code to do it? No problem, describe how you would go about solving it.
Our argument was that we wanted to see how they go about trying to solve problems / how they think.
Over time the test got modified and expanded for a variety of reasons. By the time I left, around 10 years later, I looked at the current test we were using and I don’t know that I could have passed it.
The questions were getting more abstract and some felt like they were just there so one of the senior architects (who had passed one of the earlier tests before being hired) could feel smart.
I think the tests can be useful, but only up to a point and it’s really easy / tempting to go too far. To me the test should be used to filter out candidates who clearly don’t meet the minimum skills we need.
I had a negative ‘Rails test’ experience I will share to see if it helps you. A small tech company contacted me out of the blue via a recruiting firm (I wasn’t actively seeking Rails employment, but it’s on my LinkedIn profile). They had no visible presence as a company. I agreed to an interview with all devs present, and it seemed to go well so I became interested in what they might offer (my main concern is they wanted me to move to a small town in Colorado within a year). They then asked me to spend five hours building a small Rails app. They gave me a brief, one page spec. I was a bit rusty so I spent more time than they asked, learning what’s new in Rails 6, but I also went above and beyond on certain parts and even pushed it up to Heroku so they could interact with it rather than just review my code. I went for speed over other factors and got it done in a day. I asked them to provide feedback and let me know if they didn’t see something they expected and what direction to go further if needed. I waited at least a week and heard nothing. I had to follow up with the recruiter to get feedback, and she played intermediary with the company (even though I had a direct contact at that point). Ultimately, I didn’t get a job offer. I asked the recruiter where I went wrong. She said everything was a good fit but the code was a bit weak. I was like “Where?!” I was also angry and frustrated with them, to the point that I would put a warning on GlassDoor (they had no reviews there) that you should not waste your time on their stupid 5 hour app. I just built them something for free on their request, and they didn’t have the decency to give me direct feedback or a second iteration if their spec was unclear. I wouldn’t want to work for someone with that much hubris and inability to communicate or treat me with respect as an autonomous agent. We are not chattel. It inspired me to remain a contractor so I can always fire a client that becomes an unbearable, demanding asshole.
I’ve failed a number of Recruitment exams and I have 17+ years as a programmer. My point is – don’t be too harsh on yourself. We’ve all been there.
That’s patently absurd. For all you know `check_user_login` could shell out `rm -rf /`.
I think you dodged a bullet.
I’ve been working with Rails since 2007 and bombed…and I mean BOMBED…an in person tech screen with a reputable company in our area a few years back. I didn’t know it was called “duck-typing” and I had never had to build a checkers game before. I’ve been a product manager, QA lead, and/or senior dev since 2000. I can code in 5 languages.
I don’t memorize the small semantic differences, and given 2 requirements have nothing but questions.
I spent five years at a way-too-easy job licking my wounds.
Don’t be like me.
Brush yourself off, take the next interview, and look forward to two years later. That’s when I heard the same company that weeded me out had such a massive data breach they lost 50% of their client-base in the span of two weeks.
I’ve been building with Rails since 2005, and I’m sure I would fail any of these silly exams. Unless all you do is Rails, and all you do is back-end, all day, there is just too much to know in modern software development.
I have to keep in my head Ruby, Rails, JavaScript, SQL, Swift, version control, systems administration, project management, UI/UX, years of Photoshop muscle memory, sales, and everything else that goes into modern development. I would fail any test on any of those, but I’ve built amazing things for lots of people.
If you haven’t explored this route, I think one of the best places to work is a local digital agency. You generally build things that are consumer or marketing focused, and clients get excited about having the latest and best. There’s always something new to learn and build.
I have a friend who is a senior Rails developer with over 12 years experience.
His company closed down during Covid and he was left out of a job. He failed more than a dozen interviews before finding his next job.
Every recruiter will tell you “It’s a developer’s market!”
And in the very next breath… “but be prepared to bomb out of more than half your interviews because of ridiculous technical questions that have nothing to do with the job”
Yeah, probably this. I’m not one to trash how different companies do interviewing/hiring/etc—everyone does it differently.
But I will say, if you didn’t get a good feeling, didn’t like the competency questions then yeah, probably not a right fit for anyone involved.
I see a lot of people get down on themselves because things didn’t work out. I know there could be a lot of pressure to find work, but the worst thing you could do IMO is land a job you’ll hate.
Don’t take it personally, try to learn from each interview, and keep going. You’ll know a good fit if you find one.
Unless the company is writing quizzes as a service, making you do quizzes for assessing you is silly.
What level was the position they were interviewing for?
I’ll probably sound out of line, but it is honestly very difficult to find good software developers. There are many people out there that claim to be software developer (and even claim to have developed some website/game/application which they simply copied) but can’t write a single line of code or write down a single algorithm. Putting in place some tests have proven necessary for the greater good.
This being said, I don’t really agree with this exercise: the question above seems quite straightforward (B) but I don’t think it validates much of your programming skills. It just means you understand a but which A/B/C/D do…
I haven’t looked for a job in 8 years. But in those 8 years, I have not recruited anyone with stupid questions like that.
First step is get to know the person and gauge wether or not he’ll be a fit with me and my other developers. No point in hiring someone, no matter how good he is, if I don’t like him or I think he’ll be adjust.
Second and final is to send a test, usually consume an api and create an app. This is just to see how the candidate approaches the problem. We never expect a finished test within the time limit because we also never deliver a feature by our deadlines. Software is never exact.
Never failed me so far and we hired 3 people and they fit absolutely fine.
There are as many opinions about how a recruiting process should go as there are candidates, it seems. You just cannot do well for everyone.
Having interviewed hundreds of candidates, I empathise with the difficulties of recruiting, and the hundred-and-one opinions from (more often than not very entitled) engineers on how it should work. I’ve built processes that have gotten feedback on exactly the same process as variant as “this is not representative of day-to-day work” over “you’re asking such bad questions, I refuse to answer them” to “I’ve never experienced such a friendly, on-point recruiting process, thank you”. Unfortunately each candidate believes they know how to do recruiting best, and the blog-o-sphere further enforces a lot of (even contradicting) beliefs about how to do it, yet it seems it’s always from the candidates side and never from the recruiter’s side.
The question OP illustrates out of context seems bad, but it’s possible the intention was OK and the recruiters are trying their best to design a system that works for the people they need, considering the constraints and resources that they have.
It’s also almost never obvious what the actual intention of a question is. Possibly the person designing the test is aware that the question is not really answerable, and is looking to see how the candidate handles that. Do they ask for further clarification? Do they select an answer but suggest that they need more info? Or do they just throw their hands up and quit the process?
It may seem quaint to play these “mind-games”, but if you need to asses a candidate in a short amount of time, you kind of need to take some shortcuts, and instead of asking “In the face of a poorly described requirement, how would you handle that?” which all candidates would faithfully answer with what they think you want to hear, you try to put them in a situation that naturally surfaces this reflex (or doesn’t).
Zero candidates would answer “I give up confused” to the question “What do you do if you run into an unsolvable problem”, yet I know there are more than zero engineers that would actually “give up confusedly”.
And maybe OP is indeed an engineer that does not meet their standards, because we also don’t know what other context the OP has received. Perhaps if looking at the full process, an engineer that does meet their standards would have been able to answer that question, considering a holistic view of everything that they’ve learned during the process.
About a question “Here’s the task, you can ask me any questions you want” where the task was poorly described and the candidate failed, I’ve later received the feedback “the task was poorly described”. As if that wasn’t the whole point of the exercise (the candidate should have asked my clarifying questions). It’s very hard for candidates to properly asses what a good or bad question is without knowing what the recruiting people are actually looking for with that question; especially if they failed.
More often than not, it’s the extremely entitled “rock star” engineer that refuse to answer questions because they think the question is designed to assess something else than what I’m actually evaluating. In this sense, the test works perfectly – people like that, who are so confident that they are correct in their interpretation that they are willing to criticize the interviewer over it on what constitutes “a first date”, I definitely don’t need on my team. Give me the enthusiastic, wholesome and humble engineer that writes simple code and takes twice as long to do it over the entitled, cynical, overly-confident and arrogantly stubborn engineer that can write amazing code in half the time any day of the week.
Perhaps you even answered the question “correctly”, and failed on a different part of the process.
You probably dodged a bullet. If they do dumb crap like that at hiring time, God knows what working there is like.